Re: Compilation error of NSS
Karsten Ohme wrote: I have used the command line gmake nss_build_all which is mentioned in the documentation on http://www.mozilla.org/projects/security/pki/nss/nss-3.9/nss-3.9-build.html (By the way, it should be mentioned that this also applies to the current release 3.10) it should be changed to make nss_build_all because this is much more common. The official Windows builds of NSS are made with gmake from moztools and the MKS toolkit, not cygwin . This is why the instructions talk about gmake rather than make. cygwin is supported too, but you need to use all the tools from cygwin if you do, not a mix of tools from different sources. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: certificate trust settings gui
Nelson, Nelson Bolyard wrote: David Stutzman wrote: I don't know if this has been covered here before. I did a quick search through bugzilla and didn't find anything so here goes. If this isn't an existing issue I'll be happy to file a feature request bug. I was thinking about how the certificate trust settings gui works and if you select all the trust settings for a root CA you do not have to select any options at all for any subordinate CAs. If you open the trust dialog for a subordinate CA whose root CA is fully trusted then usually all the check boxes are left blank. What would be nice to see is a grayed out check box for all the trust settings that are being inherited from above the current CA you are looking at so you can tell that this CA *IS* being trusted. Dave AFAIK, no one has previously requested an indicator of inherited trust, but it seems reasonable to me. Please file an RFE in bugzilla. Thanks. But trust actually is not inherited. Trust to NSS means that the cert validation ends at the trusted certificate - no other issuing certificates are searched. In the above case, the CA is not trusted, so the NSS cert validation algorithm has to keep looking for certs until it finds a trusted one - or not, and it must verify the larger chain that includes all the certs up to a trust anchor. But there are also many things other than trust/lack of trust that can prematurely abort the cert validation - for example constraints, key usage / extended key usage extension values in the issuing certs. All that you really have is a trust anchor that may be part of the same chain as your CA cert, which means there is a possibility that some certs from that CA may be validated. Showing a tree of trust would be useful, but this only makes sense in the context of a given cert chain, not in the context of the trust properties of an isolated CA cert. Without a cert chain, there will be no trusted cert to get trust bits from, since the particular CA is untrusted. One must consider that cert chains are not static, and even for a unique CA cert, there can be several chains to be considered. A CA cert can have multiple issuer certs that match it, the most common case being if the issuing cert is renewed with a different date. But other cert attribute may change too in the renewed cert, such as constraints or key usage extensions. The current cert validation in NSS always chains a cert to the newest issuer cert, even though that may not have trust set, for example because that second issuer cert came over SSL or in an S/MIME message. Lack of trust may in turn cause cert validation to fail. Since the certs from the peer may be only temporary decoded and destroyed by the application during the processing of the SSL connection or S/MIME message, there would be no opportunity for a mozilla browser user to see in the GUI that any of this happened - the second issuer cert wouldn't show at the time the user clicks. So, this type of UI may create as many problems as it will resolve. The right place to deal with this type of problem is when the application encounters a cert chain it can't verify. Then it can display the whole cert chain, including any trust properties - but we already know implicitly that any cert part of the invalid chain isn't trusted for the purpose being tested, or the validation would have succeeded. Note that in the near future, NSS will be able to explore many more cert trees, and will not always select the newest cert as the issuing cert anymore. If the cert validation with the newest cert fails, other cert trees will be explored. This means there may be several chains considered during the validation - each with cert containing different trust. That makes the validation algorithm much more forgiving, but it also outlines the need for selecting a cert chain to use to get original trust from. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: SSL cert trustargs issue
[EMAIL PROTECTED] wrote: Any clues as to what do I need to do to set the trustargs to u,u,u ? Yes. You would need to install the private key for that certificate. NSS doesn't let you set the user trust bit anymore. Rather, it is automatically sets it based on whether or not a matching private key is available for that certificate. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: On Thu, 3 Nov 2005, Julien Pierre wrote: Ka-Ping Yee wrote: On Wed, 2 Nov 2005, Julien Pierre wrote: The account (or other relationship) you previously established at the website you wanted -- the one truly intended as you put it. The phisher wants to fool you into believing you are participating in that relationship when in reality you are dealing with an impostor. By keeping note of the certificate information, your browser can tell you reliably whether you are dealing with the same site and not an impostor. No. A party is allowed to use more than one certificate, for reasons such as renewal, or many other. There is nothing in X.509 or SSL that says one party only has one cert, quite the contrary. The fact that the certificate has changed since your last communication does not tell you that you aren't dealing still with the same site . But that is not under control of the phisher. Only the legitimate party can produce the correct certificate, and that is what matters. When you are phished, someone is trying to make you believe that you are at the SAME site when in reality you are at a DIFFERENT site. The situation you're describing is not phishing; it's backwards (you think you are at a different site when you are at the same site), and it can only occur with consent of the legitimate site. The point I was trying to make is that there is not one unique correct certificate. The fact that the certificate changed or didn't change tells you nothing about its validity. In fact the certificate could be the same both times, but it could have been revoked by the CA between the two communications, eg. for reason of key compromise, and you could in fact be dealing with a phisher the second time . The fact is that the information about which certificate was used in a previous communication is not relevant to the problem of authenticating the site the 2nd time around. To provide security, the certificate needs to be fully verified and validated again. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
cdr wrote: Peter Gutmann wrote: Treat it as an unrecoverable error... ...in the same format as [...] a Server not found-type message. If only it was so simple... If this was to be done, it would quickly become the best known example of simple-minded, ill suited for real world I-know-best attitude on the part of programmer. We know users have choice, and the net result, I predict, would be their migration to other browsers. Regardless, it is the right thing to do. If non-technical users want to shoot themselves in the foot, they should certainly be free to do so - using another browser. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: phishing web sites using self-signed certs
Ka-Ping Yee wrote: Refusing to accept self-signed certificates is *not* the right thing to do. That would only further the notion that buying a certificate from one of dozens of approved CAs is what makes a website legitimate, which is false. What fraction of the 30 to 50 root CAs on your root CA list do you know or have ever heard of? Do you know their policies? Do you know their management? Why should you trust them? What makes a website legitimate is the fact that it is the website you truly intended, not the fact that it happens to have paid a member of the CA extortion ring. What other way does the average non-technical user have to know that the secure website is the one truly intended and not a fake, except than to rely upon a third party to do the verification for them ? Self-signed certs certainly don't provide any of that type of assurance. The only valid exception may be when you are connecting to your own hosts over a very controlled private network. In this case no third party verification is necessary. But most non-technical users don't do that. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: upgrading to TLS within HTTP (rfc2817)
Aleksey Sanin wrote: Indeed. It should be easy to implement the HTTP TLS upgrade with NSS. You can start your connection with regular NSPR sockets, and then upgrade the socket to TLS with SSL_ImportFD at the time your HTTP engine determines it is needed . Thanks for the answer! My question was exactly that: can SSL_ImportFD upgrade to SSL on-the-fly :) You may also need to call SSL_ResetHandshake . And another question (related) to this. Is it possible with NSS to setup a socket to accept both plain text and encrypted TLS connections? No, NSS doesn't have code that attempts to differentiate plaintext and SSL . Application protocols I'm aware of specify either different ports for plaintext and SSL/TLS, or a method that starts in plaintext mode and then switches to SSL/TLS - eg. STARTTLS and HTTP TLS upgrade. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: upgrading to TLS within HTTP (rfc2817)
Bob, Bob Relyea wrote: Aleksey Sanin wrote: Hi! Is it possible to support rfc2817 (upgrade to TLS within http) using NSS on the client and/or server side? I found a couple topics about this but none have exact answer: http://groups.google.com/group/netscape.public.mozilla.crypto/browse_thread/thread/c4a57f79737ed71d/e3649467ff9f3b6d?q=rfc+2817rnum=1hl=en#e3649467ff9f3b6d http://groups.google.com/group/netscape.public.mozilla.crypto/browse_thread/thread/1e0cec54eb872308/1949a07e185966f2?q=rfc+2817rnum=4hl=en#1949a07e185966f2 Note that I clearly understand Julien's concerns from the second topic but this is not for a regular http server and web browser :) This spec is an http spec, telling how the http protocol decides to initiate an SSL or TLS connection. NSS only implements the SSL or TLS transport, so there is nothing in NSS that I know of that needs to be done to make this work The work to implement this would be in your http engine. Indeed. It should be easy to implement the HTTP TLS upgrade with NSS. You can start your connection with regular NSPR sockets, and then upgrade the socket to TLS with SSL_ImportFD at the time your HTTP engine determines it is needed . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Connecting to Firefox PKCS#11 implementation
Enzo, Enzo Motta wrote: I'm trying to connect to firefox's PKCS#11 implementation using the new sun PKCS#11 Provider. My code looks like: String configName = c:\\pkcs11.config; Provider p = new sun.security.pkcs11.SunPKCS11(configName); Security.addProvider(p); My pkcs11.config is: name = Firefox library = C:\Mozilla\softokn3.dll And I always got the error: Exception in thread main java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:153) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:74) at Main.main(Main.java:15) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD at sun.security.pkcs11.wrapper.PKCS11.C_Initialize(Native Method) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:143) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) Does anyone know what is wrong? Or where can I found a solution? Thanks, Enzo Motta. Are you trying to do this in your own process, or from an applet running within the Mozilla browser ? If from your own process, be aware that the NSS softoken requires some arguments to be passed in to the CK_C_INITIALIZE_ARGS structure. Check the source for softoken to see what these are. If from within mozilla, I would currently recommend against you doing this (see bugzilla 292809 for the reasons why) . However, if you do try, you sohuld let Mozilla initialize NSS for you, and then the SunPKCS11 provider can load the softoken, which is already initialized, and use it. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow()
Petar, Petar Popara wrote: This proves that NSS is doing what it should (except the nicknames generated for your certs are really ugly - I don't know why that is). Thank you very much for the time you spent analyzing thise certs/crls. If the first cert isn't showing as revoked in Firefox or Mozilla, that is probably due to the trust having been set incorrectly by that product. I have tried next: I have deleted revoked cert from Firefox cert store (using Firefox GUI). Then I have called CERT_VerifyCertificateNow() passing revoked cert as argument. It still doesn't recognize this cert as revoked. :( I don't think this is related with Firefox. Please reproduce the steps I listed first, then copy the resulting security databases - cert8.db, key3.db , and cert8.dir, over to your mozilla / firefox profile . Let me know what result you get . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow()
Petar, Petar Popara wrote: If that's not it, then you will need to step through the code in the CRL cache. Assuming you are using NSS 3.10 (NSS_3_10_RTM) I suggest you start with DPCache_FetchFromTokens and find out if the CRL is found during the verification. I have downloaded NSS 3.10 precompiled debug binaries for Windows (VC6 compiler). By using VC6 debugger I have noticed that CERT_VerifyCertificate() (and CERT_VerifyCertificateNow()) never calls DPCache_FetchFromTokens(). For example, SEC_FindCrlByName() which I also use to find CRL and check its time validity (before attempting to download it from web) calls DPCache_FetchFromTokens(). Did you mark your own certificate as trusted ? If so, the chain validation ends at your own cert, and thus no revocation check is performed. In order for revocation checks to be performed, the only certs that should be trusted are the root certs. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow()
Petar Popara wrote:
What date are you verifying your certificate against ?
Current date and time. CERT_VerifyCertificateNow() (should) use current date
and time and that is what I need.
This is my code sample:
SECStatus s = CERT_VerifyCertificateNow(
CERT_GetDefaultCertDB(),
pCertContext,
PR_TRUE,
certificateUsageAnyCA,
NULL,
out);
if (s == SECFailure) {
//an error occured
}
Actually, that's the wong test.
You should test for
if (s != SECSuccess)
The reason is because some APIs , including CERT_VerifyCertificate, may
return SECWouldBlock .
If that's not it, then you will need to step through the code in the CRL
cache. Assuming you are using NSS 3.10 (NSS_3_10_RTM) I suggest you start
with DPCache_FetchFromTokens and find out if the CRL is found during the
verification.
I haven't compiled NSS by myself. I'm using Windows precompiled binaries. :(
Doing that would help. Before that, you could list the content of your
database with crlutil -d dir -n YourCA -L
And also the details of your end-entity and CA certs with
certutil -d dir -n YourCA -L
certutil -d dir -n YourEE -L
The primary check involved is that the subject of the CRL should match
the subject of the CA and the issuer field of the EE .
If not, then NSS cannot correlate the certs and the CRL . That would
indicate an invalid CRL most probably.
If you are using your own CA, you might want to try with real public
certs and CRL to convince yourself that it works, ie. Thawte or Verisign
certs .
___
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow()
Petar Popara wrote:
What date are you verifying your certificate against ?
Current date and time. CERT_VerifyCertificateNow() (should) use current date
and time and that is what I need.
This is my code sample:
SECStatus s = CERT_VerifyCertificateNow(
CERT_GetDefaultCertDB(),
pCertContext,
PR_TRUE,
certificateUsageAnyCA,
NULL,
out);
if (s == SECFailure) {
//an error occured
}
Actually, that's the wong test.
You should test for
if (s != SECSuccess)
The reason is because some APIs , including CERT_VerifyCertificate, may
return SECWouldBlock .
If that's not it, then you will need to step through the code in the CRL
cache. Assuming you are using NSS 3.10 (NSS_3_10_RTM) I suggest you start
with DPCache_FetchFromTokens and find out if the CRL is found during the
verification.
I haven't compiled NSS by myself. I'm using Windows precompiled binaries. :(
Doing that would help. Before that, you could list the content of your
database with crlutil -d dir -n YourCA -L
And also the details of your end-entity and CA certs with
certutil -d dir -n YourCA -L
certutil -d dir -n YourEE -L
The primary check involved is that the subject of the CRL should match
the subject of the CA and the issuer field of the EE .
If not, then NSS cannot correlate the certs and the CRL . That would
indicate an invalid CRL most probably.
If you are using your own CA, you might want to try with real public
certs and CRL to convince yourself that it works, ie. Thawte or Verisign
certs .
___
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow()
Petar, Petar Popara wrote: I have imported CRL into Firefox, but CERT_VerifyCertificateNow() doesn't report that my certificate is revoked. It should, because my (test) certificate IS revoked. :( Which certUsage I should specify (for CERT_VerifyCertificateNow()) if user is signing or encrypting something? P.S. I'm writting plugin for Firefox 1.0.4. What date are you verifying your certificate against ? The CRL cache uses the entry revocation date . If you check for revocation as of 1pm yesterday, but the cert was revoked today, then the verification will pass . This is just one guess as to what could be wrong. Your CRL also needs to be valid and issued by the same CA as the certificate you are verifying, with the same signing key. It needs to be a full CRL. This is the only case that's currently supported. If that's not it, then you will need to step through the code in the CRL cache. Assuming you are using NSS 3.10 (NSS_3_10_RTM) I suggest you start with DPCache_FetchFromTokens and find out if the CRL is found during the verification. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_DecodeCRLDistributionPoints unresolved external
Petar, Petar Popara wrote: It was a discussion about CERT_FindCRLDistributionPoints() unresolved external, but I am having problems with CERT_DecodeCRLDistributionPoints() which should be already public (exported). :( It doesn't matter. The issue about exporting any distribution point APIs is in question due to the patent at this time. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CERT_VerifyCertificate increments Pk11 slot reference counter?
Alex,
alex21 wrote:
res =
CERT_VerifyCertificate(handle,cert,PR_TRUE,0,pTime,myStruc,log,returnedUsages);
// slot-refCount = 3 at this point for the signer certificate.
The signer certificate may be added to the CRL cache, and gets refcounted
as a result.
NSS_Shutdown() should take care of releasing that reference when it calls
ShutdownCRLCache();
That's my point - NSS_Shutdown _doesn't_ release that extra reference...
It does. Otherwise, none of our NSS test QA would pass. The NSS QA sets
the NSS_STRICT_SHUTDOWN variable to 1 . On debug builds of NSS, this
causes NSS_Shutdown() to fail if there are any leftover slot references.
The code that frees the cert reference in the CRL cache is in a function
called DPCache_Destroy . This is done in a CERT_DestroyCertificate call
. You can set a breakpoint and verify that this is happening .
I just checked this with the certutil -V command, which calls
CERT_VerifyCertificate .
(dbx) r
Running: certutil -d . -V -n server-cert -u S
(process id 402)
certutil: certificate is valid
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in DPCache_Destroy at line 1184 in file
crl.c
1184 CERT_DestroyCertificate(cache-issuer);
(dbx) w
current thread: [EMAIL PROTECTED]
=[1] DPCache_Destroy(cache = 0x85c20), line 1184 in crl.c
[2] IssuerCache_Destroy(cache = 0x51008), line 1231 in crl.c
[3] FreeIssuer(he = 0x85478, i = 0, arg = 0xffbfed90), line 1255 in
crl.c
[4] PL_HashTableEnumerateEntries(ht = 0x518d8, f = 0xff200bc0 =
`libnss3.so`crl.c`FreeIssuer(struct PLHashEntry *he, PRIntn i, void
*arg), arg = 0xffbfed90), line 432 in plhash.c
[5] ShutdownCRLCache(), line 1291 in crl.c
[6] NSS_Shutdown(), line 555 in nssinit.c
[7] certutil_main(argc = 8, argv = 0xffbff60c, initialize = 1), line
3090 in certutil.c
[8] main(argc = 8, argv = 0xffbff60c), line 3104 in certutil.c
(dbx) p cache-issuer-slot
cache-issuer-slot = 0x7d808
(dbx) p (*(`pk11slot.c`PK11SlotInfoStr*) 0x7d808)-refCount
(*((struct PK11SlotInfoStr *) 0x7d808)).refCount = 2
(dbx) stop in PK11_FreeSlot
(4) stop in PK11_FreeSlot
(dbx) c
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in PK11_FreeSlot at line 441 in file
pk11slot.c
441 if (PR_AtomicDecrement(slot-refCount) == 0) {
(dbx) w
current thread: [EMAIL PROTECTED]
=[1] PK11_FreeSlot(slot = 0x7d808), line 441 in pk11slot.c
[2] nssDecodedPKIXCertificate_Destroy(dc = 0x92300), line 535 in
pki3hack.c
[3] nssDecodedCert_Destroy(dc = 0x92300), line 112 in certdecode.c
[4] nssCertificate_Destroy(c = 0x85dc0), line 152 in certificate.c
[5] NSSCertificate_Destroy(c = 0x85dc0), line 170 in certificate.c
[6] CERT_DestroyCertificate(cert = 0x90228), line 612 in stanpcertdb.c
[7] DPCache_Destroy(cache = 0x85c20), line 1184 in crl.c
[8] IssuerCache_Destroy(cache = 0x51008), line 1231 in crl.c
[9] FreeIssuer(he = 0x85478, i = 0, arg = 0xffbfed90), line 1255 in
crl.c
[10] PL_HashTableEnumerateEntries(ht = 0x518d8, f = 0xff200bc0 =
`libnss3.so`crl.c`FreeIssuer(struct PLHashEntry *he, PRIntn i, void
*arg), arg = 0xffbfed90), line 432 in plhash.c
[11] ShutdownCRLCache(), line 1291 in crl.c
[12] NSS_Shutdown(), line 555 in nssinit.c
[13] certutil_main(argc = 8, argv = 0xffbff60c, initialize = 1), line
3090 in certutil.c
[14] main(argc = 8, argv = 0xffbff60c), line 3104 in certutil.c
(dbx) c
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in PK11_FreeSlot at line 441 in file
pk11slot.c
441 if (PR_AtomicDecrement(slot-refCount) == 0) {
(dbx) w
current thread: [EMAIL PROTECTED]
=[1] PK11_FreeSlot(slot = 0x7d2c0), line 441 in pk11slot.c
[2] pk11_FreeListElement(list = 0xff28aac4, le = 0x56b28), line 159
in pk11slot.c
[3] PK11_ClearSlotList(slot = 0x7d2c0), line 958 in pk11slot.c
[4] SECMOD_DestroyModule(module = 0x58ab8), line 776 in pk11util.c
[5] SECMOD_DestroyModuleListElement(element = 0x51028), line 824 in
pk11util.c
[6] SECMOD_DestroyModuleList(list = 0x51028), line 840 in pk11util.c
[7] SECMOD_Shutdown(), line 98 in pk11util.c
[8] NSS_Shutdown(), line 559 in nssinit.c
[9] certutil_main(argc = 8, argv = 0xffbff60c, initialize = 1), line
3090 in certutil.c
[10] main(argc = 8, argv = 0xffbff60c), line 3104 in certutil.c
(dbx) c
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in PK11_FreeSlot at line 441 in file
pk11slot.c
441 if (PR_AtomicDecrement(slot-refCount) == 0) {
(dbx) w
current thread: [EMAIL PROTECTED]
=[1] PK11_FreeSlot(slot = 0x7d2c0), line 441 in pk11slot.c
[2] pk11_FreeListElement(list = 0xff28aadc, le = 0x56b58), line 159
in pk11slot.c
[3] PK11_ClearSlotList(slot = 0x7d2c0), line 958 in pk11slot.c
[4] SECMOD_DestroyModule(module = 0x58ab8), line 776 in pk11util.c
[5] SECMOD_DestroyModuleListElement(element = 0x51028), line 824 in
pk11util.c
[6] SECMOD_DestroyModuleList(list = 0x51028), line 840 in pk11util.c
[7] SECMOD_Shutdown(), line 98 in pk11util.c
[8] NSS_Shutdown(), line 559 in nssinit.c
[9] certutil_main(argc =
Re: [nss] CERT_DecodeCRLDistributionPoints unresolved external
Petar, Petar Popara wrote: It seems CERT_DecodeCRLDistributionPoints is not exported? This was discussed just a couple weeks ago in this newsgroup. Check the archives. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: [nss] CERT_VerifyCertificateNow
Petar Popara wrote: First, decode the CRL with CERT_DecodeDERCrl or CERT_DecodeDERCrlWithFlags . Seems I don't need this because PK11_ImportCRL() takes CRL in DER format/encoding as input? That's true, I forgot about that. Look at NSS tool crlutil . It seems there also exists CERT_ImportCRL(). Will try to use it first. CERT_ImportCRL just calls PK11_ImportCRL with a default set of options . It might be what you want, or not. Decoding entries takes a long time on large CRLs, and it's beneficial to skip that and do a partial decoding . You can do that by passing the CRL_DECODE_SKIP_ENTRIES flag in the decode options of APIs that take them. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: problem retrieving CRL DP URI
Jean-Marc, Jean-Marc Desperrier wrote: Nelson B wrote: Some of us are trying to find out if doing so would infringe or be contributory or indirect infringement. If not, then I think it would be reasonable to export that function. I don't know why exactly the NSS team considers the statement by the owner of the patent that any implementation of X509 is safe is not clear enough. I think everybody else does. A pointer to the statement you are referring to would be appreciated. The info that I have is that one needs to sign a license with the patent holder in order to use it. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Developer documentation on the Mozilla S/MIME Tookit API?
Michael, Michael wrote: Hello everyone, I was wondering if anybody knows where the developer documentation is for the Mozilla S/MIME Tookit API? Any help would make my day. :) Michael It is in the NSS header files under mozilla/security/nss/lib/smime, and in the sample tool cmsutil under mozilla/security/nss/cmd/smimetools . You can also look at some PSM source code in mozilla/security/manager. I'm not aware of any doc for this part of the NSS API . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: More Phishing scams, still no SSL being used...
Duane wrote: Jean-Marc Desperrier wrote: I rather agree about that problem description, I just don't understand why Ram declares that OCSP solves it. I tend to believe it can help in some situations, but make it worse in other, in fact make it worse for In any case MS is turning OCSP on by default in their next version of windows, one of the problems with OCSP is the fact that if you can't verify a certificate it's assumed to be revoked, and while MS is planning to create some form of OCSP caching, I'm waiting to see how well it will work on a plane, or any other place where you have no connectivity... Instead of waiting , why not contribute OCSP caching code to Mozilla / NSS ? See bugs 205406 and 48597 . It's been on our to-do list for years, just never a priority . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: More Phishing scams, still no SSL being used...
Ian, Ian G wrote: but if it is anything like any of a dozen other signing techs out there, it will probably surprise in how vulnerable it is. Most signing applications were put together with so many false assumptions that they are either unusable or not worth using. Included in that list is cousins like S/MIME. You could accuse me of spreading doom and gloom and pessimism that there is no solution to our woes but not FUD. Your quote above was the textbook definition of FUD . Negative, vague, with no actual information regarding the technology you don't like [S/MIME], only general, unprovable opinion. I could take your quote verbatim and say PGP, and you couldn't prove me wrong one way or the other . See http://en.wikipedia.org/wiki/FUD FUD is an abbreviation for Fear, Uncertainty, and Doubt, a sales or marketing strategy of disseminating negative but vague or inaccurate information on a competitor's product. The term originated to describe misinformation tactics in the computer software industry and has since been used more broadly. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: multiple certs server leads to Firefox confusion in status bar
Jean-Marc Desperrier wrote: Openssl ca tool is not a CA, it's a toy, it's author would be the first to confirm that. applause The world would be a lot better if all the OpenSSL users knew that ! ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: More Phishing scams, still no SSL being used...
Jean-Marc, Jean-Marc Desperrier wrote: What do you do with a piece of code signed by a certificate that you have as revoked once the certificate has expired? And how do you solve that with OCSP ? You keep certs indefinitly in the OCSP responder ? Anyway the current signature implementation in Mozilla has no way of verifying signatures after the cert has expired. FYI, this case doesn't work for CRLs either, because softoken only keeps one CRL per issuer - the newest one. There is a bugzilla RFE on that . Even if if the token supported older CRLs, or if multiple CRLs were available from different tokens, currently the CRL cache algorithm always uses the latest CRL also for the lookup. Both could be changed, but this still would offer no guarantee that a proper revocation check was done. To make sure one has the latest revocation information for a particular expired cert, one needs to acquire the latest CRL issued before or at the expiration date of that cert. That means the client has to keep one full CRL for each expired cert he is interested in checking - and clearly it's not affordable, as the cert database will grow without bounds. This requirement could be relaxed if the client had a way to know how long the CA keeps certs on its CRL after the certs expire. The default according to specs is that they get dropped off the CRL immediately at expiration. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: multiple certs server leads to Firefox confusion in status bar
Jean-Marc, Jean-Marc Desperrier wrote: Nelson described how 'SSLv3/TLS only' SSL handshake (but not the SSLv2 compatible handshake method) supports sending the identification of the server the client intends to talk to. But is it enough to disable SSLv2 to make Firefox send a SSLv3 only handshake with that info ? No. Currently, NSS will not add the server name indication to the client helo. See bugzilla 116168 and 116169 . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Problems importing CA with certutil
Ronin, To completely take care of this problem, you need to upgrade your Sun products to the versions recently released in Solaris 10 and the Java Enterprise System release 3 (2005Q1), which both ship with NSS 3.9.5 and use the standard cert8.db format. Is there a way to avoid upgrading? I think I could use the binaries built by Sun, as you said, but where can I find them? I use Sun ONE Application Server 7 Upgrade 4 on Linux platform. I'm not sure of the download URL, I'm not a Sun support person - I'm on the development side -, and this isn't a Sun support forum. However, nobody is forcing you to upgrade the product version you have. The NSS 3.3 branch is still supported for Sun products. The current version is 3.3.11 . If you want to use NSS 3.9 with a Sun product however, then you must upgrade to the Sun product that supports this version of the libraries, ie. JES3 / Solaris 10 . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: QuickDER restriction wrt BER
Lev, Lev Walkin wrote: P.S. The code passes the NISCC test suite. FYI, so do both of the ASN.1 decoders in NSS (classic and QuickDER). I might add that QuickDER didn't even need a single fix to pass that test suite - it just worked :) The much more complex classic decoder had to have several fixes made to it a few years ago to pass NISCC . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Problems importing CA with certutil
Ronin, Ronin wrote: I saw all the issues about cert7/8.db and older/newer versions of Sun One and nss. My Sun One version is using cert7.db because it was upgraded from an older version using it. But, if I access to the web interface, cert8.db is created and used. My last try was to delete all certX.db and reimport everything using nss-3.9, creating only cert8.db. But the result is still the same! :( As already said, I open the web interface, remove the CA imported with nss, reimport it through the interface... and it works. Please do *not* use your own NSS binaries to manipulate cert databases in Sun products. Only the binaries built by Sun are supported. There are reasons for that. In this particular instance, there was a backporting error of the cert8.db format into NSS 3.3.5 through 3.3.11 . Even though these versions of NSS generate cert db files named cert8.db, the code is not compatible with cert8.db files generated from NSS 3.7 and up . So, you may not be able to use NSS 3.9 to create cert8.db that will work in old Sun products that ship with NSS 3.3.x . The Sun cert8.db are readable by NSS 3.9, but as soon as they are written to with NSS 3.9, NSS 3.3.x will no longer be able to read it correctly. To completely take care of this problem, you need to upgrade your Sun products to the versions recently released in Solaris 10 and the Java Enterprise System release 3 (2005Q1), which both ship with NSS 3.9.5 and use the standard cert8.db format. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: QuickDER restriction wrt BER
Jean-Marc, Nelson, Nelson B wrote: Jean-Marc, Julien should really answer this question, because he's the author of the newer QuickDER decoder. But here's what I recall. After writing QuickDER, I wrote a technote about the use of the decoders, which is at http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn1.html . In fact, my guessing is that this incompatibility refers mostly about things like breaking OCTET STRING in several parts that must be reattached together when decoding, and the possibility of outputing an element with no explicit length at the start, but an end of element marker at the end. Right. The quick DER decoder does not decode indefinite length encoding of any type. I believe it also does not decode constructed primitive types (which you described above as an OCTET STRING in several parts). I think those are the only major restrictions. Yes, these are the main limitations I'm aware of in the area of BER vs DER that are supported by the classic decoder but not by QuickDER . This information should probably be added to the technote . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How many X509 extensions are supported by NSS?
Kyle, Kyle Hamilton wrote: On 4/26/05, Bob Relyea [EMAIL PROTECTED] wrote: NSS can parse any extension that you supply the template for with SEC_ASN1DecodeItem() and CERT_FindCertExtension(). In NSS 3.10 several internal functions NSS uses to decode these extensions were (are being) exported: Can I add an ASN.1 template to the certificate store? Or is that asking too much? ASN.1 templates are stored in data structures within your application or library, not in the certificate store. You can create as many templates as memory allows for any extensions oyu need. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How many X509 extensions are supported by NSS?
Hashim, You may have missed a couple of certificate extensions, in particular Netscape extensions - I don't have the full list . Your findings are correct for CRLs. I didn't have time to review OCSP. Note that Sun has funded a project to get NSS up to RFC3280 compliance. I can't get into any more specifics at this time. Hashim Saleem wrote: Hi, Well, according to my RD, NSS only supports to decode (i.e. to print them in readable format not the hex dump) the following extensions for the following cryptographics objects. Certificate -- BasicConstraint. Certificate Policies. AuthKeyID. KeyUsage. ExtKeyUsage. CRL Distribution Point. AuthInfoAccess. CRL - Nothing CRL Entry --- InvalidityDate. OCSPRequest --- Nothing OCSPResponse - Nothing Please if someone can verify me on this. I couldnt find any NSS APIs to decode other X509 extensions. Regards, ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: possible memory leak in NSS? (valgrind)
David, David wrote: This is only snippet that I can put, but the real problem is that I am callind FreeCertNicknames on the memory allocated here. Is there anything else that I am doing wrong? I have actually run a test where I used a pointer retrieved by this function and immediately called FreeCertNicknames on it and valgrind pointed to that as a leak. -David FreeCertNicknames isn't an NSS function. Do you mean CERT_FreeNickNames ? What version of NSS are you using ? Can you show the exact arguments you used with CERT_GetCertNicknames ? ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Can SSL_ConfigSecureServer be safely used more than once for a machine that listens to multiple ports?
DAVID, David wrote: Thank you for your response. :) Unfortunately, I don't think I gave enough initial info for you to go on... :( My app has a initial listening socket on which SSL_ConfigSecureServer is called... children threads may also launch separate listening sockets, but when they call SSL_ConfigSecureServer on their own separate listening sockets... I get a SegFault... This only seems to happen on Solaris 8 though... The code seems to run perfectly fine on Linux. I am pretty perplexed by this one... Can anyone throw me a bone? You are right, you aren't giving us enough information. How about a crash stack of your segfault ? ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: possible memory leak in NSS? (valgrind)
David, David wrote: I currently have an application based on NSS and I am trying to track down a small, but significant memory leak. I am using valgrind at the moment to help and upon termination. I get the following traceback to a function as a memory leak. Anyone have any suggestions about what could be going on here? I have confirmed that there is a leak and opened bugzilla 291228 at https://bugzilla.mozilla.org/show_bug.cgi?id=291228 to track this bug. Thanks for the report. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Can SSL_ConfigSecureServer be safely used more than once for a machine that listens to multiple ports?
David, David wrote: I am writing a program that uses NSS as a proxy for some other protocols. I have a mult-threaded single-process app. It is calling SSL_ConfigSecureServer in the top thread and in some child theads... The child thread seems to crash only on Solaris 8 when this is called. Gdb is claiming it is in the function mul_add(). This same behavior is not exhibited on Linux where the application runs flawlessly... Anyone have any ideas? SSL_ConfigSecureServer can be called more than once, but not on the same socket. Why would you want to do that ? When using multiple ports, you can call SSL_ConfigSecureServer once for each individual listen socket. If you need to dynamically change the SSL configuration of one of the ports you are listening on, use the model socket feature of NSS . See the selfserv code sample on the model socket option for details. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: can't find memory leak in application based on NSS
David, David Butler Jr. wrote: I currently have an application that is based on NSS. Unfortunately, I cannot post any of the code, but it seems to have a memory leak. It uses thread pools and seems to leak about 2K per connection. I have run valgrind against the binaries on linux and there seems to be a leak surrounding the CERT_GetCertNicknames function. The real problem is that this function is only called once inside of my program, but never again. Valgrind is giving hints about still reachable blocks and possible leaks but the only definite seems to be from that function. Does anyone have a clue of some tricks I might be able to use or anything else that might be going on? You really aren't giving us much to work with. Are you certain your program is leaking, or are you taking the word of a single tool ? Please confirm it from multiple sources (eg. memory usage in top, vmstat, etc.). Is your program a server or client program ? Either way, perhaps you can run it single-threaded, or with a very low number of threads, and try to isolate the problem with your tools. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Peter, Peter Gutmann wrote: Nelson B [EMAIL PROTECTED] writes: Ram A M wrote: Building on this as a phase-in approach, perhaps if a CDP (CRL pointer) is present in a certificate a button saying check CRL could appear somewhere appropriate, and if an OCSP AIA (OCSP pointer) is present ... The problem with CRL DPs is the patent issue. I thought Entrust made it freely usable by anyone implementing a PKIX- compliant PKI? Perhaps, but the MPL is a very liberal license and imposes very few conditions on mozilla users. As it currently stands, the Entrust CRL DP issue hasn't been sorted out and it may unfortunately remain outside of the open-source Mozilla/NSS codebase . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Ian, Ian G wrote: OCSP is unsuitable for many servers' use for performance reasons. The server usually can't afford to make an outgoing OCSP request and process an OCSP response for every incoming connections. This process roughly doubles the overhead of the server per incoming connection, and therefore more than doubles the cost of running it. You'll basically need twice as much server hardware if you use OCSP vs not using it. This is not even taking into account the cost of running the responder. I'm guessing here you are referring to servers set up to accept client side certificates? Yes, in part. But server applications also sometimes make outgoing connections to other servers; ie. they act as clients. Eg. a secure web server may talk to an LDAPS directory server over SSL. Revocation checking is useful for those servers too. Wouldn't such servers be generally set up under fairly close system administration control? And thus take themselves out of the scope of default policies such as envisaged by the default root list distros. Indeed, the servers most likely wouldn't be using the default root list. The nssckbi root cert module would probably not be loaded. The servers would be using root and intermediate certs installed by the server administrators manually into the server's cert databases. This doesn't change the fact that revocation is still wanted in those environments. I don't know much in this area - I've not seen too much in way of servers that do client certs nor deal with CRLs, etc. Do Mozilla actually deliver a server? AFAIK, mozilla.org does not deliver any server product. However, the open-source NSS library which is used in free mozilla client products is also used under the MPL in commercial server products from Sun and RedHat, which are derived from the old Netscape/AOL server products. Nearly all of NSS development is paid for by those companies. It would be a way of simplifying the debate; It seems as if there are two potential 'sets': 1. Firefox, etc, people who are 'average users' and expected not to touch defaults. For this application, OCSP may help. Phishing is a problem with this set. 2. Servers, etc, adminstrators could be expected to be 'savvy' and capable of dealing with CRLs and root lists. Hackers may be a problem here, and phishing may be a *secondary* issue, after the info has been extracted from users, but if client side certs are in use this would be a much more sophisticated breach involving virus/trojan compromise at the minimum. Does that fly? Yes, those are definitely different types of users. But the main differences lie in the way of application administration and user interface, not in the way the underlying crypto and PKI library works. The commercial server products have staff to work on their admin security UIs. The mozilla client products don't. Until somebody steps up to work on it, most of the discussions in this newsgroup that relate to UIs will remain just wishful thinking. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Peter, Peter Gutmann wrote: You forgot the most important one: What proportion of them are of any use in SSL? Using the X.509 CRL reason codes as usage cases, key compromise is unlikely to be useful unless the attacker helpfully informs the server administrator that they've stolen their key, affiliation changed is handled by obtaining a new certificate for the changed server URL, superseded is handled in the same way, and cessation of operation is handled by shutting down the server. In none of these cases is revocation of much use. (It does however make a nice distraction from addressing security UI issues :-). From the point of view of SSL, all the reason codes are equal. If a serial number is listed on a full CRL, the cert is considered revoked, regardless of the reason code. The SSL library doesn't care why it was revoked. In fact, it was discovered 2 days ago that there isn't even an NSS public function to get at the reason code currently :-). See bug 287052 . That omission doesn't prevent revocation checking from working in NSS. It's probably a waste of time to put together a browser UI that distinguishes revocation reason codes . The concept of revocation alone is probably too much to grasp for most browser users, anyway. That doesn't mean some other applications (eg. servers) might not some day want to log the reason codes when a login attempt with a revoked client certificate occurs. As far as cases like key compromise, obviously it wouldn't be the attacker reporting that he stole the key ! But the legitimate owner of a key might at some point become aware of a risk and report it to the CA to have his own cert revoked . Eg. he has a software key on his hard drive, and the computer gets stolen . Or his smartcard gets stolen. There is no proof that the key is actually compromised in those cases (the thief would still need to crack the database or smartcard password to use the key), but there is a risk and strong suspicion, so the reason code has very valid uses. Once the cert is revoked, a server may be able to log any attempt made by the thief to login with the stolen cert and key, - it would appear in the server log as revoked cert for [EMAIL PROTECTED] - reason : key compromise and the server administrator could take action such as tracing the IP address of the thief. In many cases, the problem with a cert will be discovered after an initial attack. And in other cases not at all. If a problem is discovered, revocation is very useful to limit the damage to the (hopefully short) period of time that elapses before somebody becomes aware of the problem and reports it to the CA for revocation. Without revocation checking, nobody has any way of knowing there is a problem with certs until the cert expires. That can be a very long period of time (a year, or more) and more than enough for an attacker do a lot of bad things. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Hi, Ram A M wrote: While CRLs and OCSP are probably both fine for server use; OCSP is unsuitable for many servers' use for performance reasons. The server usually can't afford to make an outgoing OCSP request and process an OCSP response for every incoming connections. This process roughly doubles the overhead of the server per incoming connection, and therefore more than doubles the cost of running it. You'll basically need twice as much server hardware if you use OCSP vs not using it. This is not even taking into account the cost of running the responder. CRLs on the other hand don't have that problem. They can be downloaded and processed at an interval much less frequent than once per connection and locally cached. With the current NSS implementation, the additional overhead of using CRLs in an SSL server is so small compared to all other tasks as to not be measurable. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Nelson, Nelson B wrote: Which says in part: DOD searched for products to speed up the validation process, which currently requires users to download more than 30M of data and takes longer than an hour.^^ They're talking about CRLs. FYI, this could have been true with NSS prior to 3.5 . In 2002, I spent a whole summer optimizing NSS performance with CRLs, which went into NSS 3.6. The result is that today, given large amounts of RAM (say, 200 MB) it is possible to decode and use a 26 MB CRL in 10 seconds on a 500 MHz sparc machine (ultra10) . This isn't counting the time for the application to download the CRL, which is of course usually longer, but that's separate from NSS processing. TheNSS RAM requirements are still being worked on, and going down, but they weren't an issue for servers that were the original target of these optimizations. The CRL will remain in the CRL cache in the application process, and in the NSS cert8 database/subdirectory, so it will be usable later when the application is restarted (but one-time NSS CRL decoding and caching will apply if it is). One key issue is knowing where to download the CRL from. As I understand it the certificate can contain information about this (just as there's a certificate field for OCSP info) but I don't think NSS yet understands it. Again I'll defer to the developers for the complete answer. NSS never initiates the fetching of CRLs on its own, for reasons I mentioned in my previous post in this thread. Programs (mostly servers) that want to use CRLs arrange to fetch them on their own. But NSS certainly can read the cert extension that contains the CRL's URL, and PSM could ask NSS for that URL. That's right. The download of CRLs is entirely the responsibility of the application. In the case of Mozilla, that would be PSM, a component which has seen basically no maintenance since Mozilla 1.0 . That was the last time AOL/Netscape had developers assigned to PSM. People need to understand that whatever new security feature they dream of isn't going to magically appear in mozilla until that changes. So, I invite the many vocal people in this newsgroup to spend less time writing complaints about Mozilla/PSM, and more time writing the code to address them ! That said, IMO, CRLs are only suitable for servers, not for clients. This is especially true for full CRLs, which is the only type of CRL currently suppored by NSS. With full CRLs, anytime a change is made, the client has to download the entire CRL again. Obviously with large CRLs, this isn't acceptable to browsers, even if they are on broadband. Delta CRLs can help relieve this problem in part. Once a client has downloaded the initial large CRL, it can download smaller delta CRLs to get the changes in revocation information. Delta CRL aren't currently supported in NSS. See the RFE in bug 148214 . The changes to make this happen aren't that big, but right now this isn't a big priority for NSS. It will not happen in NSS 3.10 . Also, once NSS supports Delta CRLs, PSM would have to add some infrastructure to download delta CRLs as needed. IMO, OCSP checking is much more appropriate for clients. Unfortunately, as has been mentioned before in this thread, a lot of OCSP responders are setup incorrectly, which makes it impractical as a general on/off setting. NSS has other important limitations with OCSP today. - NSS doesn't provide for any local caching of OCSP responses, which could easily cause overload on the responders once OCSP was turned on by default. See bugs 205406 and 48597 about this . - NSS OCSP support currently only checks the leaf certificate of a chain, unlike the CRL checking code, which will look for CRLs at all levels of a cert chain (except for roots, which can't be revoked with a CRL - you need to unset trust to achieve that). To be effective in a client environment, OCSP support would have to be enabled for all levels of the cert chain, not just the leaf cert. See bug 155481 for an RFE on this as well. In a server environment, this is much less of a problem, as usually there is a very limited set of cert chains accepted by the server, and an intermediate CA cert is marked trusted, indicating revocation checking for that cert is unwanted. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Revocation services
Ram A M wrote: For folks with slow connections perhaps it is preferrable to perform opportune downloads using idle network time to pull data. Folks with slow connections are often also the ones that are paying for the connection by the minute. I don't think there would be much, if any, idle network time. CRLs are simply unsuitable for those users. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS Compilation problems Windows XP
Karsten, Karsten Ohme wrote: The first problem was that for some part of the compilation the slashes of /cygdrive/ confused the cl compiler. For some part there was prepended the cygwin-wrapper, but in this part it missed. Please re-read the build instructions carefully, in particular the part that says : For Windows, make your PATH include the directory that contains either the MKS Toolkit or Cygwin tools, followed by Netscape's wintools (special gmake, nsinstall, etc.) I think you are running into a problem where your cygwin installation is incomplete . You need to have cygwin's make in your path. There is no need to patch anything in the NSS build tree to get it to work . See bug https://bugzilla.mozilla.org/show_bug.cgi?id=257071 . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: multiple SSL domains over single IP
Ian, Ian G wrote: What's the state of play w.r.t. being able to have as SSL website share an IP# with several other websites? I know there is supposed to be a way to do this, but when I get down to the practical web site management sysadmin, he generally says it can't be done... I'm just musing here, that if there is a future where we can shift more traffic onto SSL as a preliminary step to separating out phishing from useful traffic, we might hit the wall of trying to get smaller sites onto SSL. iang There is a TLS extension called server name indication. It is currently not implemented by NSS . There are RFEs, you can search bugzilla. I'm not aware of any client or server that implements this extension at this time, but if you are, that might provide an incentive to add it to NSS . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Determining the appropriate CRLs to manage from within Mozilla
Dave, Dave wrote: I think I've been able to zoom in a bit closer to the problem. Bear in mind that I have limited experience debugging large applications, and I've only dabbled with Windows debuggers (e.g., WinDBG) in the past. Luckily, it seems that I was able to glean some pointers from the minimal drwtsn32.log generated after the crashes. Then again, maybe not. Whether causal or not, there is a problem with the way in which Mozilla saves the CRL specific preferences. One problem is that Mozilla appends the CA's OU (Organization Unit) name to the preference string key, but some of the CRLs downloaded have empty OU fields in the CRL manager, and the preference hash can't have duplicate keys. E.g., this is how the key-value pair is supposed to look in the prefs.js file: user_pref(security.crl.autoupdate.enable.Certification Services Division, true); If there is no OU name, the above preference looks like this: user_pref(security.crl.autoupdate.enable., true); Seems to me that this is a problem in the PSM component . Could you turn off auto-update of CRLs altogether, and see if you still get regular crashes ? If you do that, NSS will still continue to use the CRLs that were previously downloaded and are listed in the cert manager . Here is a stack back-trace from the thread in which the fault occurred. I wish I had generated export symbols for Mozilla. Unfortunately that stack wasn't helpful to the diagnosis . If you get another one with symbol names containing prefixes of NSS function names, such as CERT or PK11, please let me know . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Determining the appropriate CRLs to manage from within Mozilla
Jean-Marc Desperrier wrote: Still I understand SUN distributes server softwares using NSS that do use CRL regularly (and that it motivated the changes to the CRL storage method between cert7 and cert8 to get better stability), so it's not because there's very little use with mozilla that the code isn't well tested. But it can be the integration with mozilla that is wrong. Or something specific to one of the CRL you imported. And maybe it's the closing of the application that isn't well tested, because server software seldom exits. It would be best if you can test with a new profile if importing them again starts the same kind of crash. There was a lot of manual testing done on CRLs, but the CRL code unfortunately has no automated test coverage in NSS yet. This is currently being worked on at Sun. However, I'm not aware of any crashing bugs related to CRLs. I would be interested in anything that Dave finds out about the crashes if they are NSS related . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla Foundation's anti-free stance
Ian G wrote: I'll assume that you're not being obtuse. This is the most well known issue from Verisign; http://www.pcworld.com/news/article/0,aid,45284,00.asp This case allows anyone to make a value judgement on Verisign's services, MF included. Please don't pretend otherwise. The facts outlined in that article are not an awful lot to hang ones hat on. The made a mistake, once, and it was 4.9 years ago. So, it's not a current issue, assuming the cert has expired. Not only that, but even at the time, methods of revocation checking for certificates existed, such as CRL and OCSP. None of this was mentioned in the article. One should be able to protect from such errors retroactively after they are discovered once Verisign revokes the certificate, if the application is configured to do a revocation check. I'm not trying to defend verisign here, but this type of error needs to be kept in perspective. If a cert gets improperly issued and is found out like the above, then the risk is much lower . I'm more worried about the cases in which nobody noticed. But unfortunately there are no statistics for those . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: why one cert8.db et key3.db by application?
Pierre BOIZOT wrote: Nelson Bolyard a crit : I made some inquiries about SQLlite some time ago (as you know) and at that time was informed (or possibly misinformed) that SQLlite only allows one accessor to have the DB open at a time. The model is that, for each transaction, one opens the DB, does the transaction, and closes the DB. That didn't seem like a good choice for NSS, especially when performance is of concern. Is that limitation no longer part of the current SQLlite being considered by mozilla? (I hope so) What 's use Nss actualy? Why don't use the Berkley DB, It is on opensource Licence Unfortunately, the sleepycat license is not compatible with Mozilla MPL. This has already been discussed before . ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: why one cert8.db et key3.db by application?
Pierre, Pierre BOIZOT wrote: hello , Where i can find doc about this subject? Mozilla , firefox , thunderbird , openoffice 1.9.xxx , KDE use NSS. Are you sure about Openoffice and KDE ? Each use cert8.db and Key3.db in local environnement of the user. Why ? Because until now, these were considered application-specific databases . How change this ? Is it a technical probleme ? It would be good to change this and allow more applications to share the DBs . However, there is a technical problem at this point, which is that the database code used by NSS for managing cert and key files is not safe for writing if multiple process are accessing the database at once . So, presently, each application has to have its own security database. That's not particularly desirable . The fix can come only by someone contributing safe database code under the trilicense Mozilla MPL/GPL/LGPL . Nobody has been able to do that yet . Until that happens, NSS databases will only be shareable if all applications are opening them open read-only. ___ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
Re: pkcs11 help
smith wrote: i am a new person of pkcs11,now i use nss392 to load my pkcs11 module,my code is long lRet = NSS_NoDB_Init(F:\\mozilla\\test\\Debug); lRet = SECMOD_AddNewModule(p11, F:\\mozilla\\test\\Debug\\pkcs11.dll, SECMOD_RSA_FLAG, 0); but SECMOD_AddNewModule()return -1, and i did not know where was wrong, and i hope somebody can give me a sample code that loaded pkcs11 module use the nss. thanks in advance SECMOD_AddNewModule tries to add the module to the secmod.db, which doesn't exist since you called NSS_NoDB_Init . Either switch to NSS_Initialize to run with a db, or use SECMOD_LoadUserModule . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How to reuse NSS SSL Client session, thx
Benjamin,
In order to enable SSL session reuse, please use the call SSL_SetURL on
your client SSL socket . NSS will then reuse the session if possible,
based on the hostname of the server you are connecting to, as well as
its IP address and port .
Benjamin Zhang wrote:
In my application, using NSS to build a SSL client, every inner webpage link
will redo a full handshake, session is not usable, what's the problem?
prob.1 Despite how option set, V2 hello always be sent, no sessionid is
attached.
[Wed Dec 01 14:29:56 2004] [ssl2] ClientHelloV2 {
version = {0x03, 0x01}
cipher-specs-length = 27 (0x1b)
sid-length = 0 (0x00)
challenge-length = 16 (0x10)
cipher-suites = {
(0x04) SSL3/RSA/RC4-128/MD5.
}
session-id = { }
challenge = { 0x128c 0x645f 0x1be0 0x2696 0x19fe 0xea28 0x68c8 0x4
prob.2 Every link redo a full handshake(a new socket).
I found Mozilla Exploer have not this problem.
It seemed there are no NSS function to deal with client ssl session.
It is noting to do with the SSL server.
I call sequence of NSS is:
sslSocket = SSL_ImportFD(NULL, tcpSocket);
secStatus=SSL_OptionSet(sslSocket,...
secStatus = SSL_OptionSet(sslSocket, SSL_ENABLE_SSL2 , PR_FALSE);
secStatus = SSL_GetClientAuthDataHook(.
secStatus = SSL_ResetHandshake(sslSocket, /* asServer */ PR_FALSE);
secStatus=SSL_ForceHandshake(sslSocket);
___
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
Re: get certificate authority root certs from mozilla?
Mindy, Mindy Pereira wrote: How can I export/ backup the certificate authority root certs from Mozilla? -Mindy You can't. The current Mozilla backup function is for your own certs - the one for which you have a key, in PKCS#12 format. You don't have the key to the root certs by definition, so you can't back them up to PKCS#12. Some root certs may be included in your PKCS#12 file if you back up one of your own certs, as the entire cert chain will be backed up. To back up third party certs such as root certs, there would need to be a PKCS#7 backup function. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: pk12util, keyutil and key exporting and importing
Eric, Eric Irrgang wrote: Is there a good way to determine what version or build a compiled binary is from? There doesn't seem to be a version flag and the version does not appear as an ASCII string in all of the tools. There is no sure way to tell that I know of for Solaris. The main thing that tells you a binary requires a given higher version of NSS is that it will not run because of a missing symbol. That said, old tools are supposed to work with the newer libraries. In general, the NSS libraries you are using determine what version of the database will be written, not the tool. Some tools may have problem if they hardcode filenames, but most don't. You just need to check with ldd that the tool is dynamically linked with NSS shared libraries (some tools are still statically linked). Incidentally, the certutil that Sun is distributing these days claims to be from NSS 3.3.10. Is there such a thing or did they just go off on their own branch? Yes, there is an NSS 3.3.10, it is a Sun-specific branch, but still open-source. You can pull NSS_3_3_BRANCH if interested. This branch should not live for too much longer in Sun products, however, as NSS 3.3 is being replaced with 3.9 . $ strings /usr/sfw/bin/sparcv9/certutil |head -2 $Header: NSS 3.3.10 Mar 25 2004 01:04:11 $ @(#)NSS 3.3.10 Mar 25 2004 01:04:11 symkeyutil is built by default in the nss build, but doesn't seem to be currently working right. How so ? What type of key were you trying to use with it ? bash-2.05$ nss-3.9.2/mozilla/dist/SunOS5.9_64_DBG.OBJ/bin/certutil -N -d test Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: bash-2.05$ nss-3.9.2/mozilla/dist/SunOS5.9_64_DBG.OBJ/bin/certutil -G -n test -z /tmp/seed -d test Enter Password or Pin for NSS Certificate DB: Generating key. This may take a few moments... bash-2.05$ nss-3.9.2/mozilla/dist/SunOS5.9_64_DBG.OBJ/bin/certutil -K -d test Enter Password or Pin for NSS Certificate DB: 0 Your key got generated. I believe the default is an RSA keypair. I haven't used symkeyutil before, but I believe it's for symmetric keys, only, and therefore you can't export the RSA key with the -E command I see in the code that there may be some defines to allow doing what you want anyway if you hack and recompile it. Also, symkeyutil seems to look for libnssckbi.so in the directory specified by -d. I've never heard of such a thing... libnssckbi.so is the root cert module . It's been the behavior of NSS since 3.2 to look for it in the database directory. Export the cert and keys to PKCS#12 format, using the version of NSS and pk12util that support your original database. Is there a way to examine a database to determine which version of the tools to use with it? The key database format hasn't changed in years. The major version of the cert database is essentially determined by the file naming - cert7 or cert8.db . There is some minor differences within versions. In particular, I found that the Sun NSS 3.3.x versions didn't implement the full cert8 format. Therefore, you shouldn't manipulate DBs from Sun product with newer tools (eg. from NSS 3.9) which have the full cert8 format. If you do that, but try to use those databases with Sun products still running NSS 3.3.x, then you won't be able to use them. This is why Sun officially supports only NSS 3.3.x and recommends against using any tools not built by Sun to manipulate cert/key databases of Sun server products. You should wait for the official release of Sun products with NSS 3.9, JES3, which should be in a couple of months. NSS 3.9 is also already in Solaris 10 in the early access builds if you have that. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: cmsutil segaults when creating envelope - please help!
Mike, Mike Jackson wrote: cmsutil -E -r [EMAIL PROTECTED] -i jimi.txt -d . -p foobar -o jimi.env Segmentation fault (core dumped) If you sent us the stack of the crash in the core file, your report would be more helpful. Also, the content of your jimi.txt file is an important variable needed to reproduce your crash. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: pk12util, keyutil and key exporting and importing
Eric, Eric Irrgang wrote: It looks like pk12util is meant to handle key extraction or importing, but it works with both cert and key at the same time and only seems to support cert7.db files. pk12util will work cert8.db as well, if you use the correct build of it, which is dynamically linked to NSS. The NSS 3.9 version of pk12util will work fine. symkeyutil is built by default in the nss build, but doesn't seem to be currently working right. How so ? What type of key were you trying to use with it ? If I need to to move certs and keys from one set of databases to another, how is it done? Export the cert and keys to PKCS#12 format, using the version of NSS and pk12util that support your original database. Import the PKCS#12 file, using the version of NSS and pk12util that support your new database. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: SSL Browser behaviour/policies
Ian Grigg wrote: Nelson Bolyard wrote: Ian, the questions being asked here are vare vague and open. Please encourage your correspondent to ask his questions here in this newsgroup, and to be specific about what is wanted. OK, I sent on the reply, thanks. BTW, HTTP upgrading (running SSL/TLS on port 80) has been rather roundly rejected, IMO, for a number of good reasons. If you care, perhaps you can ask Julien to say more about this. Oh, ok! Julien? The topic comes up everytime someone starts talking about increasing utilisation of SSL/TLS. Perhaps you could point me at any doco that explains why? iang There were a number of issues with TLS upgrade that I objected to during its design phase, which never got addressed. Googling for my name in conjunction with TLS upgrade will find most of the discussions, around year 2000, back when I was working on an HTTP server (iPlanet web server), rather than on the NSS libraries. The #1 issue that caused me not to implement TLS upgrade in my HTTP server is that there is no new URL scheme specified to tell the browser to connect with HTTP and then do a TLS upgrade. The existing http:// scheme is inadequate for general web use in secure applications, as it will result in no security when used with old clients (which don't support TLS upgrade with http://), at best, and compromise of data with many web applications that use confidential data within URL fields. The URL scheme may seem like a small thing, but given that TLS upgrade needs to be implemented on both the server and client side, I felt it was very important to get the design right, and so opted not to implement the TLS upgrade draft in iPlanet web server. Note that TLS upgrade was designed specifically for use with the Internet printing protocol, and not for general HTTP use in browsers, as the authors of the draft themselves admitted. TLS upgrade indeed had the potential to increase SSL/TLS use for HTTP, and in particular of allowing SSL virtual servers on a single IP/port by way of using the Host header in the plain-text HTTP request before the TLS upgrade. However, this need is now addressed in the TLS 1.1 extensions draft through the server name indication field in client hello. This is a much cleaner and more secure way to accomplish the same goal, as well as one that can work with all protocols and not just HTTP. We haven't had requests to implement this yet, but there are RFEs on NSS. See bugzilla 116168 and 116169 . The need that TLS upgrade for HTTP filled which the TLS extensions draft doesn't is to get rid of the dual ports 80/443 for HTTP and HTTPS . However, the HTTP and HTTPS servers are already out there on two different ports by the millions, and I believe trying to get rid of one of the two ports given the situation now is bound to fail, not to mention pointless. IMO, the TLS server name indication extension makes the HTTP TLS upgrade scheme irrelevant, and the later should simply be skipped in web browsers. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Crash occurred in function FREEBL_GetVector
Yann,
Yann Nong wrote:
Hi all,
I am using Sun iPlanet Web Server v6.0 in production. Recently, we
encountered some problems with the web server and found the following
message in the errors logs:
code
[29/Aug/2004:00:55:04] info ( 7420): Crash occurred in function
FREEBL_GetVector from module
/usr/iplanet/servers/bin/https/lib/libfreebl_hybrid_3.so
/code
I am hoping someone can help me shed some light on this issue. I've
tried searching on the Sun forums but didn't get any information.
Thanks in advance
Yann Nong
You should be using the regular Sun support channels for iPlanet web
server, not Mozilla .
That said, your problem sounds like an installation issue with the NSS
libraries. The function FREEBL_GetVector just returns the address of a
variable, and cannot crash :
const FREEBLVector *
FREEBL_GetVector(void)
{
return vector;
}
However, this symbol gets loaded on-demand from either
libfreebl_pure32_3.so or libfreebl_hybrid_3.so, depending on the Sparc
chip architecture you are using. The problem might be that the library
isn't getting loaded. Please check your LD_LIBRARY_PATH to see if both
libraries can be loaded.
___
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
Re: compiling addbuiltin (nss)
Broccoli, broccoli wrote: Actually I need an nss that will work with Mozilla 1.7.3, so I'm not even sure the addbuiltin from nss3.3 would work for me if I could get it to compile. You'll need to build NSS 3.9 to work with mozilla 1.7.3 . addbuiltin wasn't compiling correctly in the NSS 3.3 branch, I believe it got fixed later. I have tried building more recent versions, nss3.9 following the instructions at http://www.mozilla.org/projects/security/pki/nss/nss-3.9/nss-3.9-build.html. With that I cannot even get nss to compile, let alone addbuiltin. It gets fairly far into the compilation, ending with errors about not finding certain dbm files: Command line warning D4002 : ignoring unknown option '/cygdrive/c/mozilla-nss-2/nss-3.9/mozilla/security/dbm/src/../../../dbm/src/db.c' Command line error D2003 : missing source filename c:\moztools\bin\gmake.exe[2]: *** [WINNT5.1_DBG.OBJ/db.obj] Error 2 c:\moztools\bin\gmake.exe[2]: Leaving directory `c:/mozilla-nss-2/nss-3.9/mozilla/security/dbm/src' cd include; c:/moztools/bin/gmake.exe libs cd src; c:/moztools/bin/gmake.exe libs c:\moztools\bin\gmake.exe[1]: *** [libs] Error 2 c:\moztools\bin\gmake.exe[1]: Leaving directory `c:/mozilla-nss-2/nss-3.9/mozilla/security/dbm' c:\moztools\bin\gmake.exe: *** [build_dbm] Error 2 Looks like you ran into http://bugzilla.mozilla.org/show_bug.cgi?id=257071 ... Bottom line is, if you are using cygwin at all, you must also use gmake from cygwin. You are using gmake from moztools . Change your path to have cygwin first, and make sure you have gmake in your cygwin distribution. This should fix your problem. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CAs with WebTrust-equivalent audits?
Robert Relyea wrote: * If we included only true root CA certificates, would it still be possible to install and use CRLs for lower-level CAs not in the CA database? This isn't an issue for typical users (since Mozilla doesn't install and use CRLs by default) but I'd still be interested in the answer. (I'm presuming the workaround for power users would be to import the lower-level CA's cert and then install the CRL.) Julian would have to verify this, but I believe we have late evaluation of the CRL. It is possible to import the CRL even if the corresponding CA isn't installed in the cert db, or present in the cache. Look at the PK11_ImportCRL and set the flag CRL_IMPORT_BYPASS_CHECKS . The browser currently uses the deprecated function Sec_NewCrl which does the same thing (no checks). The CRL only gets closely looked at when a validation happens, usually long after it has been imported to the database. Ie., it is a late evaluation. I think the browser should try to check the CRL at import time if possible. Ie, it should try the import with checks first. If the import with check fails, some decision needs to be made somehow. One could bring a dialog to the user to prompt, but that probably wouldn't be very useful. The alternative would be to persist all the valid intermediate CAs around in the DB to ensure that this situation does not occur. Another solution is if the CRL is stored on an SSL server which contains the CA . If that's the case, it would ensure that Mozilla has the CA available at the time of import, even if the CA doesn't get persisted. But obviously, we cannot dictate that anybody deploys CRLs this way. You can just as well ftp CRLs insecurely ... The reasoning for doing the check is that you don't want to silently import a rogue CRL into the browser DB, which can happen if there are no checks on it at import time. If you import a rogue CRL, then obtain the legit CA later on (say, during an SSL handhshake) , all validations for certs issued by that CA will fail, because the CRL in the DB won't match the CA cert. This would be case of poison CRL. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Question About NSPR Thread Using
liupeng wrote: Hi, I have one question about NSPR thread. I use NSS-3.9 build my server,and Use NSPR to handling my thread.When a client request arrive,I use PR_CreateThread to create a new thread like following: thr = PR_CreateThread(PR_USER_THREAD, SSLService_ThreadFun, (void*)arg, PR_PRIORITY_NORMAL, PR_LOCAL_THREAD, PR_UNJOINABLE_THREAD, 0); In Function SSLService_ThreadFun,I will deal with the client request,and the function will exit after the transaction was complete.In SunOS5.8,I use webload 6.0 to test my server,when client request arrive,it will create much more thread to deal with the request,and these thread will not exit until client request stop for a long time(use syscommand ps to check),and sometimes the threadnumber will reduce to a value that less than it's start value,but this thing will not appear in other platform,why? LiuPeng You are using user threads, which are managed by NSPR. The system command ps cannot monitor NSPR user threads. You probably want to use system threads instead. However, experience dictates that you do not want to create threads on-demand when connections arrive in the server. The thread creation will induce latency. You should instead pre-start your server threads and have some kind of queue mechanism to to process the requests. Don't have all your threads in accept as this will be inefficient. If you have dedicated accept threads, you can get away with having very few accept threads, eg. 2 to 4 times the number of physical CPUs. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Signing using a PKCS12 file
Nelson, Nelson B wrote: The challenging part would be specifying the PKCS12 file path names to the module at run time. Since PKCS11 was designed to work with hardware tokens, it doesn't provide ways to pass path names to the modules, except at initialization time. At the lower-level, this could be simply accomplished by unloading and reloading the new PKCS#11 module with a different filename argument in the library parameters. A list of filenames could be specified also, if multiple files need to be loaded, and the module could create the corresponding number of slots. But of course the UI problems still apply, and this would be a proprietary parameter. I'm surprised Mozilla doesn't give a UI to specify the library parameters when loading a PKCS#11 module. If that field existed in the UI, then it would be possible to use a module behaving as I described above without special UI (although somewhat painfully, you would have to type in the list of PKCS#12 files into the field). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Status on review of CAs root list
Ian, Ian Grigg wrote: I haven't seen any traffic for a while on the review of the CA list. Is that process complete or just quiet at the moment? iang That's because we don't report here. The process is not stalled, it's just happening in bugzilla, under the individual NSS bugs filed by each CA, and I have seen updates in the past week . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS Performance
Jean-Marc, Jean-Marc Desperrier wrote: They are some test of SSL hardware accelerator cards around. They sometime show mixed results ; if you already have a lot of CPU power on your machine, some models of accelerators do not in fact actually accelerate it. It seems that the drivers are not always enough optimized so that the time spent communicating with the card can be longer than the time needed to do the calculation. The card drivers and PKCS#11 libraries typically only become the bottleneck if you enable FIPS mode and use the crypto card for all the symmetric crypto algorithms. In this case, all the data traffic has to go to the card . This is always slower than doing the same thing in software. Sometimes it is offset by the fact that the hardware accelerates RSA, but it's often a mixed bag. You are much better off not running FIPS, using the card only for RSA operations, and letting NSS do the rest. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS Performance
liupeng wrote: Very thanks for Julien Pierre answer. I use webload 6.0 to do full SSL handshakes,SSL session can't reuse,and key size=1024bit. Could you offer us the name of SSL hardware accelerator cards which are often used(test in nss)? The latest one I have used in my testing earlier this year is the Sun Crypto Accelerator 1000, which does over 1000 RSA ops/s at 1024 bits. You'll want at least a quad CPU server to be able to take full advantage of such a card. Sun also sells the SCA4000, which does 4000 ops/s at 1024 bits. Some benchmarks were done where it was possible to peak the card from one server with NSS a couple years ago, but that was done by a different group. I do remember the hardware used being pretty beefy (12+ CPUs), but not the specifics . I think some SPECWEB SSL results were made public with that config and at the time NSS with the Netscape/Sun web server had the performance lead. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS Performance
Liu, liupeng wrote: Hi, Does someone can provide NSS performance report? I use nss-3.9 to build my ssl server,and use webload 6.0 test my server,the machine information as following: server machine: Turbolinux 2.4.18 SMP System configuration: 2 Xeon 2.4G 512kb cache 2G memory client machine:win2000*4 The performance of my server seems not good,when loadsize=50,only about 160 transaction per second,and cpu idle=0,can someone provide nss performance report or explain this? Thanks LiuPeng I have done a lot of performance work on NSS for AOL Sun over the years, but none of the results are public. That said, there are some factors I can discuss with you that you haven't mentioned and are very important parameters. 1) Are you doing full SSL handshakes with RSA every time ? Or SSL session reuse ? 2) If full handshake, with what key size ? 1024 bits or 2048 bits ? RSA is still a very expensive computation, even for modern CPUs. It represents over 95% of the CPU cycles that NSS spends in SSL full handshakes. If you are doing full RSA, even at 1024 bits, then 160 ops/s seems a good number to get for the kind of server hardware you have. To get quite a bit more than that, you would have to buy something with more processors, with SSL hardware accelerator cards, or more likely with both. Note that NSS has been optimized for multithreading and multiple CPUs . Most of the server-side performance work on NSS has focused on Sun Ultrasparc CPU, not on the x86 architecture. Also, note that the Linux 2.4 and prior kernel is not very as good at multithreading and SMP as, say, Solaris is. I expect 2.6 to be better but I haven't had a chance to verify that. PS. I do work for Sun, so I have a visible bias, but I must tell you that I make those statements about x86 and Linux vs Sparc Solaris because those are the facts I observed in my tests. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Nelson, Now, if it's true that TBird users CANNOT password protect their key DBs, then I think we (NSS developers) should insist that this be fixed. This is a GROSS security hole. Perhaps we should declare a moratorium on additional NSS work until this capability is restored ot the TBird UI. Because of FIPS 140-2 validation on softoken, we may be forced to put hard requirements on the password in the future, and no password wouldn't do . So, I think Tbird would be broken in the future if users can't set a password on the NSS DB, at least if FIPS mode is enabled. I guess they wouldn't be able to turn on FIPS mode anyway either ... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Frank, Frank Hecker wrote: Duane wrote re importing certificates into Thunderbird: tools - account settings - security (on any accounts listed) - manage certificates - authorities - import - cacert.crt D'oh! I don't know how I missed this. I guess I was prepped by previous messages not to expect this to be present. So what's all the fuss about then? AFAICT Thunderbird appears to have essentially the same capabilities for cert management as Mozilla. Frank Some of us prefer to use the full mozilla suite. I never tried thunderbird. I was just commenting on the (apparently incorrect) information about thunderbird not having a cert manager. I'm glad to read that was wrong. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Mariusz Woloszyn wrote: p.s. Mozilla should be able to properly report that there is no certificate... There is nobody working the mozilla security UI and so many errors are displayed with numbers, such as the one you got, instead of strings . p.s. why is mozilla not capable of importing pem client certs? I believe (but am not sure) that PEM format may contain the object in plaintext, and thus is not a suitable secure transport format for a private key, unlike PKCS#12, which allows the key within the file to be encrypted, when you set a passphrase, and thus PEM is considered too insecure a format to support for NSS and Mozilla, at least as far as private keys are concerned. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Franck, Frank Hecker wrote: Thunderbird works OK with this setup, but as you note there is no way for me to import the root CA certificate for my CA. Thus I have to rely on TB to present the initial cert warning dialog, and then tell it to accept the server certificate. After that everything seems to work OK. So, how informed is the decision when you make it ? Can you view the cert details before accepting the cert and trusting it ? Or do you have to do it just blindly ? Not being able to manage certs is certainly an inconvenience, but let me play devil's advocate for a moment: In a real enterprise deployment of Thunderbird it might be better to ship a customized version with pre-loaded certs, as opposed to relying on users to import a corporate root cert. Thus one could make an argument that instead of trying to design and implement Thunderbird UIs for cert management it would be more useful to enterprise customers just to make it as simple as possible to do cert preloading. (When I have some spare time I should seach out the instructions on how to rebuild the relevant NSS library and see if I can do this myself.) It's often not a practical solution in multi-platform environment to rebuild all the clients with pre-loaded certs. I think the deployment cost is too high, and the corporations will just look elsewhere for apps that have a cert manager. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Moving keys from one computer to another
Timur, Nice to see you in this neck of the woods ! Timur Tabi wrote: I know little about cryptography and how the S/MIME stuff works, so bear with me as I use simplified descriptions. I have a few public keys that I picked up from friends who sent me signed emails. With these keys, I can send them encrypted email. I also have a public and private key that I got from Thawte, that allows me to send signed emails and read encrypted emails sent to me. I'm running Mozilla 1.8 on OS X. One clarification first : Mozilla does not store public keys by themselves. It stores your correspondents' x.509 certificates, which among other things contain both their public key and their identity bound together (e-mail address). I'm moving my stuff to another computer running OS X. I want to transfer all of these public and private keys to that computer, so that everything works as it does here. What's the easiest way to do that? For your personal certificates and private keys, you can back them up to a PKCS#12 file . The easiest way to do this in Mozilla is to use edit / preferences / privacy security / manage certificates / backup all . Then, in the same menu on the other machine, you can import this file to restore your cert and keys. Currently, there isn't a good way within mozilla to backup export your recipients' certificates . A standard format exists, called PKCS#7, which can be imported, but there is no backup function for the public certs (ie. other people's certs) in Mozilla . One way to restore your friends certificates if you use an IMAP server is to simply re-read their signed e-mails in your Mozilla client on the new machine. Whenever you do so, Mozilla imports their certificates into the certificate database. If you aren't using IMAP, your next best bet is to simply copy over the entire cert and key db files from your old machine to their location in the profile on the new system. This will also restore your private key, thus eliminating the requirement for the PKCS#12 import/export step. If you are running Mozilla 1.8, the files you are looking for should be cert8.db and key3.db . However, the Mac browser developers have been known to change the default database filenames so perhaps they are something else. The actual database file format is platform-independent, so once you get them into the right filename and location, you can move your keys and certs to any machine on any OS running the same version of Mozilla. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Nelson Bolyard wrote: Mariusz Woloszyn wrote: Is it possible to use client certificates for authentication to smtps srver? Mozilla Thunderbird is supporting smtps, but I see no way to install client certificates and use them to authenticate... Regards, The word I've received is that the Thunderbird developers decided that all the UI for managing certs, keys, and the master password was just too confusing for former IE users, so they decided to leave it out. I guess that means if you want to use client certs, you have to use the mozilla suite (e.g. moz 1.7) instead of TBird. Sounds disingenuous. Outlook users, which is Microsoft's mail app - not IE - has quite a few crypto features. So, if anything, Outlook users will miss those features if they switch to Thunderbird Granted, client auth for SMTP doesn't seem to be one of Outlook's features, but it does S/MIME signing and encrypting. Also, if there is no UI for managing certs in Thunderbird, even basic SSL connections may fail if there is no way to install corporate root certs and trust them. That's going to be a much more common problem than not supporting client auth. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Using client certificates for smtps
Mariusz Woloszyn wrote: I don't see any way to use client certs in Mozilla _mailer_. They do work. You can configure your default client cert for SSL under edit/preferences/privacy security/certificates . Set either select automatically or ask every time. Admittedly, there is no specific setting of the client cert to use to login to each web site. In most cases there is no ambiguity and Mozilla NSS can determine the right cert to use automatically. If not, set ask every time and mozilla will present you with a dialog to let you select the client cert you want. Of course that can only work if you installed your client certs in mozilla previously (eg. from a PKCS#12 import). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Unique Inbox Icon For Digitally Signed Messages
Doug, Doug Bunger wrote: I reviewed the above link. We seem to be thinking on similar lines. Using your idea of a filter, I was able to use Thunderbird 0.7.3 to klunge something together: Within Tools / Message Filters, I had previously used the Customize feature to create a new type for Content-Type. This allows you to build a filter that looks in the message header for multipart/signed, and signature. It can then be moved to a folder or marked. The problem is that this does not check that the signature is valid. Yes, I know it's possible to filter on headers, but that's not sufficient for what we want. Do you know why your original suggestion was not implemented? Is it just a case of someone volunteering to work the problem? At the time, Netscape/AOL still had paid developers working on Mozilla/mail, but this feature was never considered a priority by management. And nobody else wanted to contribute this. I don't know who works on Mozilla mail filters today. You might want to try to find out and bring it to their attention - at least cc them. It's been 8 years since I last wrote GUI code, so it's unlikely I would be able to contribute the patch even if I had time. I could assist in helping with whatever NSS calls you need to make, but I think most of the calls are already in there in the S/MIME message signature check / decrypt . It's a matter of taking that code over to filters. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Unique Inbox Icon For Digitally Signed Messages
Nelson B wrote: Doug Bunger wrote: Several e-mail clients display a unique inbox icon for messages that are digitally signed. In my work with PKI, I feel that users appreciate this feature, as it allows them to quickly, visually, identify legitimate messages. I have not found this feature in either Mozilla Mail or Thunderbird. 1. Does this feature exist, and I have missed it? 2. Is there an existing development effort toward this? 3. What input for (or against) such an effort from the community? Doug Bunger, dougbunger-AT-comcast-DOT-net Doug, I think this is a great idea, an enhancement request to the mail client software (not to NSS). I don't think such a feature now exists in mozilla, and perhaps it has never been requested. It has, over two years ago, by yours truly :-) http://bugzilla.mozilla.org/show_bug.cgi?id=108767 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Expired Root Authorities Certificate update?
Bil, Bill Burns wrote: Not true, unless you're confusing the two Microsoft update mechanisms. Windows XP, starting with SP1, has a new component called Root certificate Update (or something similar). This component automatically queries the WindowsUpdate server when a CSP encounters a root CA certificate that it doesn't have. If the Windows Mother Ship has the root CA certificate available, the new root cert is downloaded silently and the cert-path-validation is recalculated. I've tested this myself and the process takes less than 300 ms; most users would never notice it happening. Older operating systems (like Win2K,98, etc) can download the new root CA certificates from the Windows Update server with their web browser, but it's a manual process. I was referring to the automatic Windows update which automatically downloads patches for Windows - not the manual browser updates. I have seen updates for root certificates in the list for Windows update, under Win2K. I have never used Win XP, so I couldn't have confused the two ... ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: JSS 3.4 build failure
Nicolas, Nicolas Mailhot wrote: The tree format you posted is not the standard NSS build tree, so you can't get the JSS build to use it. Follow the instructions on Mozilla and build your own NSS. This is the standard mozilla tree on Linux and both epiphany and galeon (and probably others) build fine using it. standard mozilla build tree != standard NSS build tree I don't really see the point of a standalone JSS release if it can't be made to work without a dedicated mozilla CVS tree. It can't be made to work as is, you will have to make changes to the JSS build system for it to work with a Mozilla build tree as opposed to an NSS build tree as it is setup today. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: JSS 3.4 build failure
Nicolas Mailhot wrote: Le Mon, 28 Jun 2004 15:23:49 -0700, Julien Pierre a crit : Well unfortunately it fails in the next step : You need to have an NSS build in order to build JSS. Ok. I have a local built nss. How can I tell the jss built to use it ? The tree format you posted is not the standard NSS build tree, so you can't get the JSS build to use it. Follow the instructions on Mozilla and build your own NSS. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Pkcs#11 problem using 2(or more) certificates with same subject
Ionut, Ionut Marasescu wrote: Hello everyone, We've developed a pkcs#11 module for our smartcard terminal and smartcard application. The smartcard contains 5 certificates (and corresponding private keys), so we implemented 5 slots. This isn't necessary. You could still have 5 certs and keys with the same subject in a single slot. We wanted to select one certificate for signing. Are you talking about S/MIME message signing ? Or SSL client auth ? Mozilla is not able to sign with the selected certificate (instead it uses the first one with the same subject displayed in the selection combo). If we set the slot names to be identical, it displays only one certificate (from the ones with the identical subject). We've imported two certificates with same subject in the Mozilla Software security device. They both appear in the Certificate Manager, but when trying to select one of them for the digital signature, we've observed that only one appears. At this point it seems to be a Mozilla issue. Does anyone know how to override this ? Or if it's a Mozilla issue, when (or if) it will be fixed ? We've tested with Mozilla 1.6 , 1.7 (releases) and Netscape 7.1, and the functionality is identical. We even declared the slots as software slots (we normally set the flag CKF_HW_SLOT), in order to observe all the calls that Mozilla normally makes. At some point Mozilla searches (C_findObjects) a certificate by using only the subject (which we know it's not unique), so it seems that our problem is related to this kind of search (it will be more convenient if the find will search by an unique atribute (like caserial number) instead of subject). Could you try to reproduce the problem with the software token instead of your token ? To do this, export your 5 certs and keys to a PKCS#12 file (you may have to generate new ones if the keys aren't exportable from your smartcard). Then import the PKCS#12 file into the database in mozilla. Then, repeat what you are trying to do and see if you are able to sign with a particular cert. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: JSS 3.4 build failure
Nicolas, Nicolas Mailhot wrote: Le Fri, 25 Jun 2004 15:23:22 -0700, Nelson Bolyard a crit : Nicolas Mailhot wrote: Anyone got an idea what's wrong ? Looks to me like you don't have the nsinstall tool in your path. Run gmake in mozilla/security/coreconf Well unfortunately it fails in the next step : You need to have an NSS build in order to build JSS. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: how to remove the extention from the p12 file exported from SunOne using pk12util
Jennifer J-N Liu wrote: I opened the p12 file, besides the certificate, there is an extention portion with fields like Authority Key Identifier, Basic Constraint, Netscape Comment, etc. What is the purpose for it? How to get rid of it? (or not to have it exported?) Those are certificate extensions. My guess is that they are part of the certificate which is included inside the certbag of your PKCS#12 file. You cannot remove them, short of not including that certificate in the file. I don't see why you wouldn't want them though, as they are standard cert extensions. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Permanent private key generation using JSS
Ian Hall wrote: Hi, I generate a public/private key-pair to create a certificate which I then write to a file and use the certutil.exe A' call to add it to the database. You need to archive the key at the time of the keygen. The certificate that you added with certutil only contains the public key, not the private key. If you want the private key, you'll need to create a pkcs#12 file that contains both the key and cert, and you can then import it with pk12util . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Retrieval of key from LDAP for mail recipient
Nelson, Nelson B wrote: Actually, the LDAP lookup feature got added in Mozilla 1.0 and I had it working back at Netscape. That is, until people started being forced to use aol.* addresses that didn't have certs published in the directory. That's potentially great news! Can you enlighten us about how to get certs from an LDAP directory server with moz 1.6 or 1.7? As I recall, you just needed to configure the directory in Mozilla, and it automatically got used when you sent an e-mail. I had my browser set to encrypt by default, and it would always look up everybody's certs in the LDAP based on e-mail address. More than 50% of the time, the messages would come back with please send unencrypted because the recipients weren't good about keeping their latest private key, or used multiple e-mail clients and didn't replicate their key ... From what I see in the UI, the only directory setting is under Edit / Preferences / Mail Newgroup / Addressing / Directory Server . This is said to be for autocompletion, but I think it works for the recipient cert lookup as well. If that doesn't work, you could probably search bugzilla on closed bugs to find when it got added, but grepping the PSM code is probably a better way. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Retrieval of key from LDAP for mail recipient
Nelson, Nelson Bolyard wrote: I would be EXTREMELY surprised if that worked. AFAIK, that level of automatic integration (looking up certs with LDAP *on demand while sending email* ) has never been in any Netscape or mozilla product. Nevertheless, that is the way I recall it working. You can read details at : http://bugzilla.mozilla.org/show_bug.cgi?id=119394 http://bugzilla.mozilla.org/show_bug.cgi?id=149212 I didn't read every detail, but I think the above support my recollection that the support is implemented, and it is the autocompletion UI setting that also controls the LDAP recipient cert lookup . Also if you care to read more, there are many bugs filed about LDAP cert fetching : http://bugzilla.mozilla.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=ldap+certslong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailassigned_to1=1emailtype1=exactemail1=emailassigned_to2=1emailreporter2=1emailqa_contact2=1emailtype2=exactemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= http://bugzilla.mozilla.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=ldap+certificatelong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailassigned_to1=1emailtype1=exactemail1=emailassigned_to2=1emailreporter2=1emailqa_contact2=1emailtype2=exactemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= http://bugzilla.mozilla.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=ldap+certificateslong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailassigned_to1=1emailtype1=exactemail1=emailassigned_to2=1emailreporter2=1emailqa_contact2=1emailtype2=exactemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Retrieval of key from LDAP for mail recipient
Nelson, Nelson B wrote: Communicator 4.x had the ability to pull certs from a directory server and import them into the local cert DB. It was a feature in the cert DB UI. But AFAIK, that feature has never been added to mozilla. Actually, the LDAP lookup feature got added in Mozilla 1.0 and I had it working back at Netscape. That is, until people started being forced to use aol.* addresses that didn't have certs published in the directory. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Jean-Marc, Jean-Marc Desperrier wrote: Nelson Bolyard wrote: Once you authenticate to a server that properly implements SSL session caching, each subsequent time you visit that server (until 24 hours pass, or you restart your browser), the client will say to the server I've previously authenticated an SSL sesiion with you, and here's its ID number, and the server will accept that, and will not ask the client to authenticate again. That's standard SSL/TLS session caching. It's been in every Netscape/mozilla browser since SSL has been in those browsers. For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. In order to login again to the same server with a new identity, you would need to invalidate the SSL session. Normally, the session is valid for 24 hours. If you don't want to wait that long, you can either restart the browser or the server, which will also invalidate it ;-) NSS does provide you with the ability to connect to a server without re-using an existing SSL session. Nothing in PSM tries to do this, to my knowledge. And it's pretty hard to envision what that would look like, from a user interface point of view. The best way would be if the server provided a logout page, which would invalidate the SSL session in the server, and thus force your browser to do another full handshake the next time around, and allow you to select another identity. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Mozilla's behavior dealing with client certificate selection
Nelson, Nelson B wrote: Julien Pierre wrote: Jean-Marc, Jean-Marc Desperrier wrote: For more advanced usage of client authentification, it can happen that you own several certs representing several identities that you may wish to wish concurently to connect to the server, or to change without having to close the browser. Yeah, the latest version of IE 6.0 has a new button in the Certificates portion of the Contents tab in the Internet Options control panel. The new button says Clear SSL State. Their context-dependent help says it wipes out the SSL cache. Presumably this is so that you can choose a different identity. Perhaps we should have something like this too. Do we have something in NSS to clear the cache for all SSL client sessions ? I don't seem to recall that we do. But probably support for that only requires change at the PSM level. I wonder if PSM would in it's current state support concurent access to the same site with a different user certificate. NSS permits an application to have multiple concurrent SSL sessions with the same peer, each session having different authentication. It's accomplished with the SSL_SetSockPeerID function. Yes, I'm aware of that. However, I don't really see a good way UI-wise to take advantage of this in PSM. But once you had multiple sessions, it's not clear to me how PSM would figure out which of them to use for a new SSL connection. It's also not clear to me that an ordinary user could keep it straight. In order to login again to the same server with a new identity, you would need to invalidate the SSL session. That's not required by NSS, nor by the SSL/TLS specs. Maybe you're saying that PSM currently requires this. I suggested it as it seemed the most logical thing to do if you just wanted to switch identity, as you wouldn't need to keep the existing session around for the old identity, and it would force NSS to make a full handshake for the next connetion. Normally, the session is valid for 24 hours. If you don't want to wait that long, you can either restart the browser or the server, which will also invalidate it ;-) NSS does provide you with the ability to connect to a server without re-using an existing SSL session. Nothing in PSM tries to do this, to my knowledge. And it's pretty hard to envision what that would look like, from a user interface point of view. The best way would be if the server provided a logout page, which would invalidate the SSL session in the server, and thus force your browser to do another full handshake the next time around, and allow you to select another identity. Maybe each browser window could display in its status bar the nickname of the user cert used to authenticate in that window? That's an idea. Clearly more than a lock icon is needed for this situation to be handled. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Could we use PKI encryption to identify non-spam ?
Ian, Ian Grigg wrote: Julien Pierre wrote: On the other hand, for someone to send you a signed e-mail, they have to obtain their own certificate from a CA, and agree with their terms of service, and the CA has the ability to revoke the certificate if those terms are broken. Therefore, using digital signatures for spam filtering makes sense, but using encryption does not. I think the main advantage is that your whitelist can be assured that it is a known sender, due to the caching of the cert. If it is a CA-signed cert or not seems irrelevant, as a spammer can send out a squillion messages well before a CA signs up and decides to dust of the revocation software. Any CAs around who'd like to comment on how long it might take to revoke a cert? You would have to make a careful choice of which CAs you want to use if you were to implement such a PKI-based spam filtering policy . The policy could be set not only by the end user in his e-mail client, but also by an ISP at the SMTP agent level, who could verify signatures and only deliver valid signed emails to a non-spam whitelisted folder. BTW, about 2 years ago, when I worked for AOL, I wrote a paper on this very topic - spam filtering with x.509 certificates and S/MIME digital signatures. Nobody ever cared about the idea, even as spam messages started costing millions of dollars to businesses everywhere. It was probably ahead of its time, but I still hope to see it implemented in some form someday. I'm sick of changing e-mail address every few months. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: User managed Trusted CA list
Egon Andersen wrote: Hi, I've been reading in bugzilla about inclusion of CA's in the builtin Trusted CA list and a lot of thoughts I've had during time was reflected in that discussion. I have some proposals for future releases of Mozilla to ensure both flexibility and trust. I personally don't like that there are any root-certificate in the Trusted CA list without I personally have accepted that specific CA to be trusted. You already have the option of untrusting any CA certs bundled with Mozilla that you don't like. Most users have no clue or ability to make root CA trust decisions however, so the default is to ship with the list. I think this can be handled simply by: Whenever a first certificate signed by a specific CA is received, a dialogue is presented to the user. This dialogue should give objective information about the trust of that specific CA. This objective information could be a list of criterias that Mozilla checks for each included CA. And for each criteria an indication of the CA meeting this criteria or not. Furthermore a subjective trust indicator (e.g. like a progress bar) could be displayed, saying what the 'Mozilla community' think of this CA. If there were some centralized place with updated 'trust info', this could be the info displayed. And how do you suggest the data be collected about what the mozilla community thinks of each CA ? Collect data of people that click through and accept the root CA ? In that case, I think you may as well trust every CA. Personally, I think your suggestion it's a horrible model. Most users (and even people who know about PKI like ourselves) have no way of making appropriate decisions about trust CAs by the time they see one in a cert chain. It's too late. The trusted CA has to be obtained by a separate out-of-band mechanism, and that mechanism is currently the built-in root cert list. If the user accept to trust a specific CA, it could be limited to e.g. 3 months after which the CA should be specificly trusted again. PKI already provides for expiration of certs, that is in the cert itself. Why complicate this with expiration of trust ? If you want to do revocation of root CAs, you need a better model than that. Updating the built-in root cert list, that comes from the Mozilla community (in the CVS source tree) seems much more sensible. One more benefit from having this 'user' accepted trust is that noone can blame Mozilla for a untrustworthy certificate being accepted. And one disadvantage is that the decision will be meaningless. You still haven't explained how the trust decision would actually be made. And of course a user should be able to trust a specific user-certificate without trusting the rootcertificate. He already can if the certificate is in the cert database. I believe the Mozilla UI is confusing about which certs get trusted. But the underlyinng NSS library allows you to trust any cert in the chain, not just the root CA. (I know there were some discussions on this list i february, but the articles has expired, so I couldn't read them to check if they addressed the same thoughts.) You better read them, as there were hundreds. google is your friend. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CRL import question
Pasi Koistinen wrote: Thanks for your quick answer. Can you recommend any handy tool for the conversion task? atob, which is part of the NSS tools. ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_9_RTM/ ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Expired Root Authorities Certificate update?
Nelson, Nelson Bolyard wrote: AFAIK, that feature is only in WinXP, and then only ones with recent OS updates. It works in Win2K as well. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: certutil.exe cert7.db
Nelson Bolyard wrote: So, IFF Jim really wants to create (or edit) cert7, and not cert8, he must use an older version of NSS, such as NSS 3.6. (If I'm misremembering which version of NSS was the last to use cert7, somebody please correct me. Thanks.) That's correct, NSS 3.6 is the last official release to write cert7.db . Some Sun products are also using older NSS 3.3 versions of which write cert7.db . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Expired Root Authorities Certificate update?
marcel wrote: Hi all, As I've seen Microsoft has a automatic root cert update program to update the trusted root store. (I dont really like that, but I think it has some advantages for the normal user that doesnt know anything about PKI). I have some question about the trusted root certs in Mozilla (NSS). What happens if one of the built-in root certs expires? Is there a similar automatic update, some process to ensure each user can renew the cert securely? No. You have to update your browser manually, through the same insecure means that you use today. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: system-wide installation of PKCS#11 module
Thomas, Thomas Pornin wrote: I would like to provide some system-wide installation procedure, such that the machine root or administrator installs the module, which then becomes automatically available and activated for all users. Is it doable, and, if yes, how ? There are multiple ways. The simplest way, which I would recommend, would be to search for all secmod.db on the system, and run modutil to add your module. That would install your PKCS#11 module on all existing mozilla installs. It would do nothing for new Mozilla profiles or installations, though. If you want the module to be automatically installed in all future mozilla profiles and mozilla installations you would need to patch Mozilla to force it to load your PKCS#11 module after NSS is initiliazed. Such changes will not be accepted in the public tree, so that's probably not very practical. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding root CAs to Mozilla's default install w/o recompiling
Damiano, Damiano ALBANI wrote: Yes, I use Cygwin and compile with MS Virtual C++ Toolkit 2003 (the free one). That could be a problem right there. You should make sure all of the DLLs are built with the same compiler. As far as I know, the official bits for Mozilla are built with MS VC 6.0, not with the .net 2003 compiler. You may have to rebuild all of Mozilla with your compiler in order to get things to work right. In theory, this shouldn't be an issue if you are only updating nssckbi.dll, as it uses the PKCS#11 API interface. However, it could be a problem if the C calling convention used between the compilers changed. I would still recommend you don't mix files built with different compilers on Windows. In NSS 3.9 build howto, it's stated to pull mozilla/security/dbm with DBM_1_61_RTM tag. But I suppose that a Mozilla release depends on a specific version of NSS, which in turn depends on a specific version of DBM ? So how can I know this cascade of dependencies ? So that for any version of Mozilla I take, I get the right DBM version and thus, build the correct addbuiltin ? DBM has been stable for a while. To know the exact dependencies, you need to read the docs on mozilla.org for each NSS release, or if it's not there, ask here. Currently for NSS 3.9.1, DBM_1_61_RTM is the correct tag. FYI, here is the checkout script I use (on Solaris) to pull NSS 3.9 (and NSPR, which I like to build myself) : #!/bin/tcsh cvs co -r NSPR_4_4_1_RTM mozilla/nsprpub cvs co -r DBM_1_61_RTM mozilla/dbm mozilla/security/dbm cvs co -r NSS_3_9_BRANCH mozilla/security/coreconf mozilla/security/nss ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding root CAs to Mozilla's default install w/o recompiling
Damiano, Damiano ALBANI wrote: I've just tried with OS_TARGET=WIN95 and the problem is still there ! :( All the original certs are recognized but not mine. When I open my nssckbi.dll file with a text editor, the character flow is different when it comes to my new certificate. I've put the DLL on http://snotling.dyndns.org/nssckbi.dll if someone wants to have a look. Someone else will have to look at this. I don't have a windows machine setup to build NSS. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding CRLs to Mozilla's default install
Frank, Frank Hecker wrote: It is true that the CRLs themselves get updated frequently. However CAs typically make the CRLs available at public URLs, and these URLs appear to be reasonably stable. This leads to a different proposal: pre-load the URLs at which CRLs can be downloaded, and mark the CRLs for automated updating. (As far as I can tell this is basically taking the existing CRL manager functionality and having it turned on by default, so that Mozilla would download a CRL for a given CA at the first opportunity.) There is a cert extension called CRL distribution point to specify where the CRL is to be downloaded from. The root CAs that have a stable (permanent) URL can simply add it to their certs, and get them updated in mozilla's nssckbi . Doing so however will not in itself help the browser find the CRLs, because mozilla does not look at the content of that cert extension. There are other bugs filed to make use of that extension. However, that is the only way to store the CRL URL in nssckbi . There is no way to store URLs by themselves. You would have to use another database for that, in Mozilla itself, not an NSS database or module. Also note that the storage of CRL objects in PKCS#11 tokens, such as the softoken's cert8.db, is a non-standard NSS extension . I don't think any other PKCS#11 application works with CRLs this way. Even NSS might reconsider this in the (distant) future. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding root CAs to Mozilla's default install w/o recompiling
Damiano, Damiano ALBANI wrote: So, would it be a problem with my Windows compiling environment ? Following the HOWTO, I use MS Visual C++ 6, upgraded to SP5. May it come from the fact that I only recompiled the DLL and use the 'official' Mozilla binary package for Windows (i.e. I'm not rebuilding the whole source) ? I haven't done any windows builds of NSS or the mozilla browser in a long time. The things to watch for is that you must use the proper version of NSPR . There are two win32 versions - one for WIN95 and another for WINNT. You need to set OS_TARGET=WIN95 for building NSPR/NSS DLLs that are compatible with Mozilla. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding CRLs to Mozilla's default install
Damiano, Damiano ALBANI wrote: Provided that I can add a new root CA to the builtin list (in theory at least ;) ), what is possible to do with CRLs ? Accepting a CRL in a browsing session put it into cert8.db, so I thought it might be addable to the nssckbi module. I've tried to use the 'addbuiltin' utility to import my CRL, but to no avail (addbuiltin: failed to convert certificate). Is there another tool ? Unfortunately, crlutil seems to work on cert8.db files. There is no provision for putting CRLs in nssckbi. nssckbi is strictly for trusted root certs, that is, information that changes very rarely. Typically, the module only gets changed when some root certs get added, though there has been talk of removing some also. CRLs on the other hand get updates all the time, and do not belong in a pre-compiled library. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Adding root CAs to Mozilla's default install w/o recompiling
Damiano ALBANI wrote: Ok, so I managed (more or less easily :)) to compile a new nssckbi.dll file. I followed instructions available on http://lxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/README. Everything worked correctly : I populated certdata.txt with a new root certificate, previously transcoded in DER format and rebuilt a new DLL. *However*, my root CA doesn't appear in the list of built-in certificates (Preferences-Privacy Security-Certificates-Manage Certificates-Authorities). Yet, if I edit my new nssckbi.dll, I can see some references to my certificate. Any idea ? Cheers, Are you sure your new nssckbi.dll DLL is in use ? Check in secmod.db using modutil to see where it's loaded from . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CA policy comments
Ian, Ian Grigg wrote: Also, given the nature of self-signed certificates, it is pretty clear that the user gives up any benefit of revocation by CAs. What on earth is offensive about that? A self-signed cert user doesn't want anything to do with a CA, including revocation. There is simply no drama here. What that means is that applications such as Mozilla should treat self-signed certs differently from certs issued by trusted CAs. And they do currently, by bringing you a big warning. I think it should remain. Perhaps wording can be added, to explain that if the user accepts the cert, there is no way it will ever get revoked. But I believe that's too complicated for most people to understand. Under most circumstances, the cert simply shouldn't be trusted period, especially by people who have no understanding of certs. Having an advanced mode for the browser where it's possible to change trust, and a normal mode where it's not, for unsophisticated users, would be a good compromise. The logical conclusion of this is that self-signed certs, if they are ever to be used, should only be used by sophisticated users, who have means to validate the certs outside of PKI, in a manual way (!). Having an application automatically generate self-signed certs to widen PKI use for the masses, as you have suggested, would be a very bad disservice to the value of certs, because the masses could never understand the risks associated with using and trusting any of those self-signed certs. They just don't read the security warnings, they blindly click through. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
