Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

D3|\||\|!$ wrote, On 2008-03-05 20:32: >> If so, here's a hint: regardless of the value of i, the expression >> (i<10,000) always has a value of zero. > > Well!! I believe you're mistaking C code for some-alien-programming- > language... Try running/debugging the code below: should clarify your

Re: FF2 passed Signed XPI file fails verification in FF3

Please ignore this message. I did not realize that I have imported the signing certificate and its trust bits were not set to true. -- Subrata Subrata Mazumdar wrote: > HI, > I have a signed XPI file that passes the signature verification during > installation in FF2 but verification fails in

FF2 passed Signed XPI file fails verification in FF3

HI, I have a signed XPI file that passes the signature verification during installation in FF2 but verification fails in FF3 (running on Fedora7 Linux). The signing certificate is signed by our own CA and the CA cert's trust flags are set to true. The XPI file is signed with NSS version of sig

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

> If so, here's a hint: regardless of the value of i, the expression >  (i<10,000)  always has a value of zero. Well!! I believe you're mistaking C code for some-alien-programming- language... Try running/debugging the code below: should clarify your confusion... *

Re: Questions about NSS PKCS#11 module configuration

Hi Robert, thanks a lot for your response. I will definitely use it and see if I can uncover/fix the memory leak. BTW, what is name of the DLL for CAPI PKCS#11 module that I should use to configure the device manager? Is it nsscapi.dll? I did a global build for NSS and I do not see it in the li

Re: SPNEGO and MDNS

Michael Ströder wrote: > > If I configure the KDC in /etc/krb5.conf in section [realms] everything > works fine. But I'd like to let the clients lookup the KDC in DNS SRV > records. This works fine for the MIT utils like kinit etc. but not for > Firefox and/or Seamonkey. > > Observing the netw

Re: GeoTrust request for EV root inclusion

Nelson Bolyard: > I'd like to suggest that every time there is a state change in a request, > a comment should be added, documenting the state change. > +1 This should be done at the bug AND the pending page if I understand you correctly. Very much agreed. -- Regards Signer: Eddy

Re: GeoTrust request for EV root inclusion

Frank Hecker: > Actually, KISA indeed entered the public discussion stage, in the sense > that I gave preliminary approval. What happened then was that Eddy and I > think others raised a number of issues, and I haven't gone back to do a > final evaluation in light of the new material provided by

Re: GeoTrust request for EV root inclusion

Frank Hecker: > Eddy Nigg (StartCom Ltd.) wrote: > >> Perhaps it's just a coincident that a representative of Verisign alarms >> a bunch of mailing lists at Mozilla about their CA certificates and a >> day later the relevant CAs are updated and ready for inclusionyou >> see what I mean? >

Re: GeoTrust request for EV root inclusion

Nelson Bolyard: > Eddy, I haven't pushed for the inclusion of any CA or any CA cert. > OK Nelson, again I apologize for any inconvenience my previous post may have caused you. > Then I went and looked at the "pending" page, > http://www.mozilla.org/projects/security/certs/pending/index.xml > An

Re: GeoTrust request for EV root inclusion

Eddy Nigg (StartCom Ltd.) wrote: > Perhaps it's just a coincident that a representative of Verisign alarms > a bunch of mailing lists at Mozilla about their CA certificates and a > day later the relevant CAs are updated and ready for inclusionyou > see what I mean? Actually, it is a coincid

Re: GeoTrust request for EV root inclusion

Frank Hecker wrote, On 2008-03-05 13:12: > Nelson Bolyard wrote: >> 1) When I look at the bugzilla bug list of open root CA requests, at >>> https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=mozilla.org&component=CA+Certificates&bug_status=UNCONFIRMED&bug_status=NEW&bug_status

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

D3|\||\|!$ wrote, On 2008-03-05 03:02: > for (int i =0; ((i<10,000) && (err_status != PR_SUCCESS)); i++) { Is that literally an exact copy of the code in your program? If so, here's a hint: regardless of the value of i, the expression (i<10,000) always has a value of zero. > The client on

Re: GeoTrust request for EV root inclusion

Wowowow, slowly! Nelson, I didn't meant to attack you in any way. I apologize if this what you understood from my previous post! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: Join the Revolution!

Re: GeoTrust request for EV root inclusion

Frank Hecker: > > Is your concern that the CPS is dated after the audit? Not really, but just the fact that the audit was performed at a period prior to the CPS publishing and KPMG confirming it. It's a little bit hard to imagine that they covered the CPS during that period - somehow the statem

Re: GeoTrust request for EV root inclusion

Nelson Bolyard wrote: > I wanted, but did not find, a summary table. So I made one, using bugzilla. > I took the status information in the pending page and updated the > individual bugzilla bugs with it. For every CA listed on the pending page > whose request bug is still open, I updated it with

Re: GeoTrust request for EV root inclusion

(Back from errand...) Frank Hecker wrote: > Is your concern that the CPS is dated after the audit? First, feel free > to ask in the bug what changes were made between the audit and the date > of publication of the 1.0 CPS. (I'll do it as well if you don't do it > first.) Don't bother, I alread

Re: GeoTrust request for EV root inclusion

Eddy Nigg (StartCom Ltd.) wrote, On 2008-03-05 11:01: > Second I wonder what's the deal with Thawte's and GeoTrust's inclusion > requests. As Gerv mentioned yesterday, there are about 40 others in the > queue, why do they get a preferential treatment? Others wait for half a > year and more just

Re: GeoTrust request for EV root inclusion

Eddy Nigg (StartCom Ltd.) wrote: > Just scratching on the surface of this request and I have to make the > following observations: > > /The audit report (https://cert.webtrust.org/SealFile?seal=650&file=pdf > ) says: > > We have examinedduring the period from *July 21, 2007 through > Novem

Re: Microsoft root CA cert requirements updated

At 6:21 PM +0100 3/5/08, Jean-Marc Desperrier wrote: >Paul Hoffman wrote: >> [...] >> For this to work, Microsoft path validation also checks that the end >> certificate is consistent with the EKU property of the root. This part >> adds to X.509 and rfc 3280bis. > >:s/adds to/conflicts with/ A

Re: GeoTrust request for EV root inclusion

Frank Hecker: > GeoTrust has applied to add a new EV root CA certificate to the Mozilla > root store, as documented in the following bug: > >https://bugzilla.mozilla.org/show_bug.cgi?id=407168 > > and in the pending certificates list: > >http://www.mozilla.org/projects/security/certs/pendi

SPNEGO and MDNS

HI! I hope I'm right here with a question regarding SPNEGO-based authentication and locating the Kerberos KDC via DNS. All the DNS zones and forwarding is correctly set up. If I configure the KDC in /etc/krb5.conf in section [realms] everything works fine. But I'd like to let the clients looku

Re: Including all root certs in FF3

Andrews, Rick wrote: > VeriSign has a number of root certificates (not just EV certs) pending > approval to be included in the trust store. It's pretty important to us > that all these roots make it into FF3. > > Can anyone tell me if it's likely that these certs will be approved in > time for FF3?

Re: Microsoft root CA cert requirements updated

Paul Hoffman wrote: > [...] > For this to work, Microsoft path validation also checks that the end > certificate is consistent with the EKU property of the root. This part > adds to X.509 and rfc 3280bis. :s/adds to/conflicts with/ > [...] > The normal case is that the root certificate does not

Re: SSL_ConfigServerSessionIDCache re-initializing nickname string.

On Mar 4, 5:50 pm, Nelson Bolyard <[EMAIL PROTECTED]> wrote: > D3|\||\|!$ wrote, On 2008-03-04 04:19: > > >> selfserv uses blocking sockets. > > > I tried turning the PR_SockOpt_Nonblocking given at the below link to > > PR_TRUE to see if the clien't behaviour changed but now the PR_Accept > > func