Re: Certificate Chains, PKCS12 and Mozilla
Thank you Julien, The problem was that the certificates of intermediate authorities didn't have the Object Signing CA and S/MIME CA bits from the NetscapeCertType extension activated. Julien Pierre wrote: Hi, [EMAIL PROTECTED] wrote: I have a PKI with 3 levels: 1. A root self-signed certificate at the first level 2. Sub certification authorities certified by the first one at second level 3. User certificates certified by second level authorities at third level. That is a fairly typical PKI. All you need to do for the CA to be recognized is to get a copy of the root CA certificate in DER format and trust it. Send it around with the extension .DER . When a mozilla user clicks on it, he will be prompted to trust the certificate. The exact window will say : Downloading certificate. You have been asked to trust a new Certificate Authority (CA). Do you want to trust your CA name here for the following purposes ? X Trust this CA to identify web sites. X Trust this CA to identify email users. X Trust this CA to identify software developers. You just need to trust it to identify email users. To implement this scheme I create the PKCS12 files for users adding two certificate bags (the first one is the certificate corresponding to the sub-authority certificate and the last one the user certificate). The PKCS#12 format is designed to transport certs and keys. However, it does not transport trust. Trust is up to the user. It sounds like your users already have the root certificate, but it's not trusted. In that case, go to the Manage certificates window (under Edit/Preferences/Privacy security/Certificates/Manage certificates). Go to the Authorities tab. Click on your cert once. Then click the Edit button at the button. Check the check box for This certificate can identify mail users. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: PSM and crl distribution point
Julien Pierre wrote: Jean-Marc Desperrier wrote: Is there a way to get PSM to make any use of the crl distribution point (crldp) extension ? How is it handled within NSS ? (I could check the source/doc. I will if nobody feels inclined to respond) Or you could type distribution point in bugzilla query before posting :-). This is not currently supported in NSS. See bugzilla 133191 . At this time, the only CRL format supported by NSS is full CRLs. Sorry Julien, there's a confusion here. The one I was talking about is the certificate extension, which is named CRL Distribution Points usually abbreviated crldp, while the crl extension you're talking about is named Issuing Distribution Point, usually abbreviated idp. This is the nomenclature used in RFC3280. I had seen the bug 133191, but I had seen also it was not what I was looking for. I've been looking in the code through lxr this time (BTW http://lxr.mozilla.org/security/ doesn't work, had to use http://lxr.mozilla.org/mozilla/), and it seems the functions NSS provides to handle the cert crldp are CERT_FindCRLDistributionPoints and CERT_DecodeCRLDistributionPoints/CERT_EncodeCRLDistributionPoints at a lower level. And the source of Mozilla/PSM does not have a single call to CERT_FindCRLDistributionPoints, so it seems clear there's is no support for it. As CERT_DecodeCRLDistributionPoints is only called by certutil and from CERT_FindCRLDistributionPoints, there's no chance even the view details of PSM will display it, and experience confirms it. I have done some work on distribution point as well, and this is reflected in the CRL cache, but it is not complete either and is even lower priority than delta CRLs. Look for the word XCRL and #if 0 in mozilla/security/nss/lib/certdb/certi.h . Some reflexions about IDP. There's two cases : A - All revocation information for 1 certificate can be obtained from 1 crl B -revocation information for 1 certificate must be aggregated from several crl If the IDP does *not* use onlySomeReasons or indirectCRL, we're in case A, and the code can support the extension just by making sure that the cert matches the information inside the IDP (has a CRLDP that matches IDP's distributionPoint, is of the right type: CA, user, Attribute). The question stays of how the cache will be populated with all the needed CRL, and how the right CRL will be selected when checking a certificate. I see some of the #if 0 modification in certi.h suggest a way of handling at least the second part of this. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: LDAP CRLs
Julien Pierre wrote: Scott Rea wrote: I am doing this on a Windows 2000 box and an LDAP URL opens the Windows Address Book [not very helpful] whether I enter the URL in IE or Mozilla. How can I get Mozilla to do the same as it does for *.crl files that are entered into the address bar? Woops. Looks like unfortunately this is another RFE that you need to file ... Seems strongly related to bug 91534 : http://bugzilla.mozilla.org/show_bug.cgi?id=91534 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS ignoring next update on CRL check
Julien Pierre wrote: In many situations, eg. if your client (or even server) is in a submarine, with no available connection to the outside world to download a newer CRL, it may be acceptable to use the latest CRL available, even if the nextUpdate has passed, than to fail altogether. If you're in a submarine with no connection, you don't receive new information, so you don't have a need to verify the validity of new content. Except if you recheck the validity of content you already own everytime you access it. But then you are getting away from a situation where the real-time paradigm applies (in this case I don't need to worry about time when validating content, because everything is done in a short enough interval that all revocation information is still available and valid). So your check would need to include the date to check the validity at, and if this date is before next update or before the revocation date of the certificate, the content is valid. [...] In NES, CRLs are considered trusted if their thisUpdate field is within a certain time interval of the current date. This is called a maximum age. nextUpdate is not considered. The web server can be configured to shut down if the latest CRL exceeds that age, so that nobody can login to the server as proper authentication mechanisms have become unavailable. So a properly configured NES is secure, even if next update is not considered. But other users of NSS should beware of the way they use the function. As you can see this is pretty stringent, and you wouldn't want your client to shut down similarly in this case. I'd probably want a warning. If I don't want a warning, then I don't really need the CRL. [...] Even in NES, the age check is only performed at the time the CRL is downloaded, not at the time of each certificate verification. This seems to contradict what you say earlier about NES shutting down if the latest CRL exceed the maximum age. If this check really done only when downloading the crl ? If Mozilla downloads a CRL before nextupdate, it cannot be guaranteed to get a new CRL than it already has, since the CA does not guarantee it will generate a new one before nextUpdate. And even then, there is a bit of leeway. Many CAs (CMS included) will start the new CRL generation at nextUpdate, but in some cases it may take a long time to generate, so that the new CRL won't really become available until nextupdate+some delta ... We don't want the clients to fail in that case either. Maybe a larger sample of usual practice would be useful but notice that a crl issuer like Verisign emits everyday crl that have a next update set to 7 days later. So you have to miss 6 daily updates, before being in a blocking situation. [...] Moreover, certificates are verified on a chain basis, so the application would have to identify which CRL in the chain is outdated, since you can have CRL not only for the immediate certificate issuer but at any level. This is a lot of work, which I have to admit NSS does not make very easy for applications, and which the Mozilla browser definitely does not perform. Microsoft CAPI implements this by starting a download for all CRL that are found outdated in the chain verification. Independant CRL download by a CRL manager as done in PSM is probably a better solution, but I think that failure to get updated CRL should be a failure case, not transparent. If not, I hope at least some change will be brought rapidly to PSM to reimplement the checking of crl_update. I think you should file an RFE against PSM to add a check of the next update. This will only have an effect at the time of the CRL download, but it will be better than the current situation. If we consider emitting a new CRL only at next update to be a standard and correct practice, then there's a need to continue to trust them after next update (I've just checked and openssl has no provision to trust a crl after next update. Neither does Apache's mod_ssl that I just see doesn't check lastUpdate at all, not clean). I see RFC3280 says : This field indicates the date by which the next CRL will be issued. Notice the by and will be issued. I think this implies that if the CRL issuing process takes time, the CA should ensure to start it in time so that it is finished by the nextUpdate time. In fact, I now remember there has been some pkix discussion about that, but it's difficult to find it back. If we keep the view of CA not necessarily having a valid crl available at nextUpdate, maybe the modification should be in the CRL manager to mark a crl untrusted if it fails to download after a given retry threshold. Or implement the RFE in bug 98193 and set a reasonnable default value for the time to continue to trust after next update. I believe this should be in the client when checking the crl, not at the CRL download. This might be done with a rather minor patch to NSS. ___
Re: PSM and crl distribution point
Jean-Marc Desperrier wrote: [In case the CRL doesn't include onlySomeReasons in the IDP] [...] the code can support the extension just by making sure that the cert matches the information inside the IDP (has a CRLDP that matches IDP's distributionPoint, is of the right type: CA, user, Attribute). In fact, implementing point (b)(2) subpoints (i),(ii),(iii) and (iv) of 6.3.3 CRL Processing inside RFC3280. The coverage of the onlySomeReasons is point (d) (1)(2)(3)(4). Also it shows certs that have a CRLDP extension including reasons should be refused, because the CRL revocation code in NSS dosn't support them. Also the presence of a cRLIssuer in the CRLDP DP might be a reason to refuse them, but I'm not too sure because a CRL without IDP might be considered valid. Or at least, it will be valid to have several CRLDP and another one pointing to a full CRL without IDP that NSS can handle. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS ignoring next update on CRL check
Jean-Marc, Jean-Marc Desperrier wrote: In many situations, eg. if your client (or even server) is in a submarine, with no available connection to the outside world to download a newer CRL, it may be acceptable to use the latest CRL available, even if the nextUpdate has passed, than to fail altogether. If you're in a submarine with no connection, you don't receive new information, so you don't have a need to verify the validity of new content. Not new content, but you may be still be validating some older content, such as e-mails you received prior to disconnection. When using the logic you suggested from Apache, this verification would fail because the CRL would be considered outdated. Except if you recheck the validity of content you already own everytime you access it. Mozilla definitely does that with e-mails. And in a way, that's a good thing, because CRLs can contain information that is retroactively added. Eg. somebody got their key/cert compromised on 11/1, but did not become aware of it until 11/4 . The cert can be retroactively added to the CRL on 11/5. If users received forged e-mails signed with the forged cert between 11/1 and 11/4, and fetch the new CRLs, those e-mails will no longer verify. Since certs cannot be unrevoked (the only exception is for a cert going from on hold status), it might be a good thing for Mozilla to mark content as invalid once the verification fails due to revocation. This way the verification would not have to be performed again. This would be good so that 2 years from now, when the cert has expired and is no longer on the CRL, the e-mail does not suddenly verify. Unfortunately the NSS cert db only supports one CRL per issuer at the moment. I opened a bug on that but can't recall the number right now. But then you are getting away from a situation where the real-time paradigm applies (in this case I don't need to worry about time when validating content, because everything is done in a short enough interval that all revocation information is still available and valid). So your check would need to include the date to check the validity at, and if this date is before next update or before the revocation date of the certificate, the content is valid. OCSP is more appropriate to the real-time scenario than CRLs are. CRLs can get large, and for that reason they are generally used in servers rather than in clients. I believe that's one of the reason why they weren't given high priority in PSM, back when someone was still working on that component. So a properly configured NES is secure, even if next update is not considered. But other users of NSS should beware of the way they use the function. Yes. [...] Even in NES, the age check is only performed at the time the CRL is downloaded, not at the time of each certificate verification. This seems to contradict what you say earlier about NES shutting down if the latest CRL exceed the maximum age. If this check really done only when downloading the crl ? Yes, it is done when downloading only, but the server can be set to periodically download CRLs on a very frequent basis, in a background thread, so that it would really shut down in this case if it didn't get an up to date CRL. Maybe a larger sample of usual practice would be useful but notice that a crl issuer like Verisign emits everyday crl that have a next update set to 7 days later. So you have to miss 6 daily updates, before being in a blocking situation. Yet if you did not enable the automatic update, it's almost a given that you will run into the blocking situation, unless you remember to manually update it every day. Microsoft CAPI implements this by starting a download for all CRL that are found outdated in the chain verification. Independant CRL download by a CRL manager as done in PSM is probably a better solution, but I think that failure to get updated CRL should be a failure case, not transparent. NSS itself never initiates a download of a CRL. We try never to initiate any ouside connection because we want our function calls to return ASAP, since in many cases applicatinos use NSS functions in blocking mode. NSS searches for CRLs for each issuer in all available PKCS#11 modules. This itself is a Netscape extension, since the official PKCS#11 spec does not specify CRL object storage. Typically, the only PKCS#11 module available that has CRL is the NSS softoken. CRLs are stored in cert8.db, or in the cert8.dir subdirectory if they exceed the size of a dbm record (4kB). So you can write code that will download CRLs and import them to the cert DB - which is what Mozilla / PSM do. Or you can write your own PKCS#11 module to make CRLs available to NSS. This is what I did for NES. That PKCS#11 module does the download in memory only. Theoritically it could be integrated into any NSS product, but it is not open-source and only part of NES at this time. If we consider emitting a new CRL only at next update to
Re: PSM and crl distribution point
Jean-Marc, Jean-Marc Desperrier wrote: This is not currently supported in NSS. See bugzilla 133191 . At this time, the only CRL format supported by NSS is full CRLs. Sorry Julien, there's a confusion here. The one I was talking about is the certificate extension, which is named CRL Distribution Points usually abbreviated crldp, while the crl extension you're talking about is named Issuing Distribution Point, usually abbreviated idp. This is the nomenclature used in RFC3280. You are right. Regardless, the other half of my response stands, at this time only full CRLs are supported, without critical extensions. Some reflexions about IDP. There's two cases : A - All revocation information for 1 certificate can be obtained from 1 crl B -revocation information for 1 certificate must be aggregated from several crl If the IDP does *not* use onlySomeReasons or indirectCRL, we're in case A, and the code can support the extension just by making sure that the cert matches the information inside the IDP (has a CRLDP that matches IDP's distributionPoint, is of the right type: CA, user, Attribute). Indeed, implementing case A should be fairly simple. Case B is the more complex part. I did not think it would be wise to try to support such a small subset of the extensions (crldp, case A). I think if and when the CRL extension work gets prioritized, most likely I would add support for all of them at the same time. The question stays of how the cache will be populated with all the needed CRL, and how the right CRL will be selected when checking a certificate. I see some of the #if 0 modification in certi.h suggest a way of handling at least the second part of this. Yes, in the header file - I started the design, but there needs to be code for this as well and there is not that much corresponding ifdef'ed code for XCRL in crl.c . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
enablePrivilege
Forgive me if this has already been covered, but I couldn't find it anywhere in the list (perhaps I am posting to the wrong list???) I have an XUL that I want to grant privileges to but seems I need to grant privileges for each individual JS function - is there no way to grant privs globally for a given XUL? I can get it to work if I include all my JS functions in the XUL page and grant privs on each function (very annoying for user), but as soon as I import a JS I run into priv problems. Regards, -- Scott Rea ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
