Certificate Chains, PKCS12 and Mozilla
Hello everybody, I have a problem with certificate chains (I have been exploring through the mailing list archives and i haven't seen it) sorry if it is a repeated topic. 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. I want that a pair of users using netscape / mozilla can interchange signed messages, so every user imports the root self-signed certificate into the navigator. The problem is: I want that an user certified by a concrete sub-authority (SubCA_1) must be able to authenticate an user cerified by another sub-authority (SubCA_2). 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). I do this hoping that when the mail program will generate the SMIME, it will include the chain and the receiver will verify the chain using the root certificate. The problem is that importing the user's PKCS12 to netscape / mozilla does not recognize the first certificate of the chain as the sub-authority so the program says that the user certificate issuer is unknown and nothing works. Anyone has played with an scheme like this ? someone can suggest me where can be the problem or even tell me if it is possibe or not ? Thank you very much. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
smart card with private key an C_UnwrapKey / C_Decrypt
Hi! To decrypt some ciphertext with the private key from a smart card I need to unwrap the private key first with the following code: rv = C_UnwrapKey(session, wrapMech, unwrappingKey, wrappedKey, wrappedKeyLen, template, 4, unwrappedKey); My problem: I have no unwrapping key. The private key was generated by openssl and therefore encrypted using DES3. If I try to generate a unwrappingKey like rv = C_GenerateKey(session, des_mech, NULL_PTR, 0, unwrappingKey); I get an error CKR_FUNCTION_NOT_SUPPORTED. Can anybody help me? Thanks. Jan ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
UhZ52l britney_spears_still_the_sexiest UhZ52l+P
We all know how sexy she can be!! s4W,ob)PKnlw\7ujwwvD\^$kH;[EMAIL PROTECTED] ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
NSS ignoring next update on CRL check
I've discovered bug 108021 http://bugzilla.mozilla.org/show_bug.cgi?id=108021 and the steps that have been taken so that NSS ignores next update when checking a CRL. I'm surprised the security implication of that were not taken more into account before implementing it. I'm a bit shocked by such a choice, and at least all implementation using NSS should be warned as explicitly as possible that they must check by hand next update when NSS tells them a crl is OK to be sure the CRL is still valid (that means all sample code showing how to call this function should make the check). According to the update in bug 98193, PSM is one such client that does not implement it's own check, and so will continue to trust an outdated CRL forever. All in one, I don't think it's a good pratice at all not to include this verification inside the crl check function. There is no client that should have a need to continue to trust an outdated crl. It's standard practice that if the only available crl is outdated, then all certificate check will fail. This how Apache works, IIS works, etc. Apparently this change has been made out of concern that the client may not have enough time to download the new crl before making the check. But the standard way to handle this case in PKI deployment is for the CA to emit a new CRL before the next update date, allowing ample time for the client to download the new crl before the actual next update. So that the next update is not actually the time at which a new crl will exist, but the time at which it becomes inappropriate to continue to trust the CRL. In fact, Mozilla crl manager conforms exactly to this logic by enabling to download a new crl n days before next update, or at a regular interval different from next update. Even if a user uses only manual update, and not automatic download, it should be warned that the crl is outdated by the failure of cert check, so that he know he must update the CRL. I'd be in favor of removing the change in bug 108021, and I would not be surprised to be backed on this view by many users. If not, I hope at least some change will be brought rapidly to PSM to reimplement the checking of crl_update. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Certificate Chains, PKCS12 and Mozilla
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
PSM and crl distribution point
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) ___ 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: All in one, I don't think it's a good pratice at all not to include this verification inside the crl check function. There is no client that should have a need to continue to trust an outdated crl. It's standard practice that if the only available crl is outdated, then all certificate check will fail. This how Apache works, IIS works, etc. First, I think you need to distinguish between client and server applications. They clearly don't have the same security requirements. Netscape Enterprise Server (NES), which is a server, and also uses NSS, has much more stringent requirements for CRL freshness, and probably more configuration options in that area than both Apache and IIS - I must admit I have not looked at them, but CRL support for NES was something I spent about 4 months on and I can tell you it is quite extensive. The same requirements did not apply to the client, and in particular to PSM, so the support for CRLs in PSM is much lighter. Apparently this change has been made out of concern that the client may not have enough time to download the new crl before making the check. But the standard way to handle this case in PKI deployment is for the CA to emit a new CRL before the next update date, allowing ample time for the client to download the new crl before the actual next update. So that the next update is not actually the time at which a new crl will exist, but the time at which it becomes inappropriate to continue to trust the CRL. I have never seen an explicit stated requirement to interpret nextUpdate as a CRL trust mechanism in the way you state, neither for the client or the server. Trust is generally something that is left to the implementors, both for certificates and for CRLs. nextUpdate is in fact an optional field in a CRL, though current profiles tend to require it. While the logic you describe in Apache does not seem unreasonable, it isn't the only one. 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. In NES, the chosen approach is different from Apache as far as CRL trust. 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. As you can see this is pretty stringent, and you wouldn't want your client to shut down similarly in this case. It is true that there is no way for NSS to just make the certificate verification for that CRL issuer fail if nextUpdate is considered too old. Even in NES, the age check is only performed at the time the CRL is downloaded, not at the time of each certificate verification. It wouldn't be too hard to implement such logic now that there is a CRL cache however. There are plenty of cases where all verifications for the issuer will fail. In fact, Mozilla crl manager conforms exactly to this logic by enabling to download a new crl n days before next update, or at a regular interval different from next update. 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. Even if a user uses only manual update, and not automatic download, it should be warned that the crl is outdated by the failure of cert check, so that he know he must update the CRL. Currently there is no NSS error that indicates that the CRL is outdated and needs to be updated. It is very hard to get something meaningful back to the user, even knowledgeable users like us, let alone average users. At this time, there is only a Revoked certificate error code. It is the same code that will be returned whether that failure is caused by an OCSP check or a CRL check. 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. 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
Re: PSM and crl distribution point
Jean-Marc, 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. delta CRLs support should be fairly easy to add given the current design of the CRL cache, but it has not been a priority. See bugzilla 148214 . 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 . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
