As promised, here is an update on where things stand with regard to DigiNotar and Entrust. (Since a lot of this is based on information I got from Nelson, he's invited to point out where I got things wrong.)
First, a recap for those who've forgotten: Recently I approved inclusion of the DigiNotar Root CA root certificate in Mozilla. Because DigiNotar does not at present meet Mozilla policy requirements for verification of email accounts, that approval was for SSL and object signing only; the email "trust bit" was set to off. However the DigiNotar Root CA public key has also been cross-signed by Entrust, so that DigiNotar Root CA can appear in cert chains as an intermediate CA certificate under the Entrust.net Secure Server Certification Authority root, one of the Entrust roots included in Mozilla and marked as suitable for all uses. (To see an example of this, go to https://www.diginotar.nl/ and view the cert chain.) Based on the way NSS currently works, if (for example) a Thunderbird user receives a signed email message with an accompanying cert chain that chains up to the Entrust root, NSS apparently ignores the presence of the included DigiNotar Root CA root cert, goes up the chain to the Entrust root, and then uses the Entrust root as the trust anchor. Since the email trust bit is enabled for that root, everything checks out fine, even though the DigiNotar Root CA itself is not enabled for email. (Incidentally, I can't remember exactly why NSS does path processing like this, e.g., whether it's something it just does, whether it's based on the relative expiry dates of the DigiNotar Root CA root cert vs. the Entrust-issued DigiNotar Root CA intermediate cert, or what. That's a question for Nelson or others who know the code better than I.) Given the above, we have various options: 1. Get DigiNotar to improve its practices with regard to certificates that contain email addresses and could be used for S/MIME email. This is my preferred solution, but DigiNotar hasn't yet committed to do this. 2. Modify NSS to turn off the email trust bit associated with the Entrust.net Secure Server Certification Authority root. This is my least-preferred option, as it would disable recognition of all Entrust-issued email certs and all email certs issued by other CAs whose roots have been cross-signed by Entrust. (This includes a number of other CAs that have their roots in Mozilla with the email trust bit enabled. Unfortunately as I understand it we'd have the same problem with them as with DigiNotar: NSS path processing would ignore the other CAs' included roots and their trust bits, go up the chain, and take email trust from the Entrust root.) In my judgement the potential security threat in this case is not high enough to justify such a drastic action. 3. Find some other way to get NSS not to recognize DigiNotar certs for email, perhaps in combination with some action by Entrust and/or DigiNotar. For example, one idea is to have end users of DigiNotar certs reconfigure their email clients to have cert chains that terminate in the DigiNotar Root CA root; unfortunately that's not really workable IMO (since every cert holder would have to do this). Another idea is to have Entrust revoke the DigiNotar Root CA intermediate cert; however as I understand it that would have no effect whatsoever, as NSS doesn't check for revocation of CA certs (except in the EV case). There's perhaps a possibility that adding the DigiNotar Root CA intermediate cert to the preloaded cert list would help, but that's unclear at this point given the current state of NSS. So the bottom line is that there are still unanswered questions, and I'm going to spend some more time trying to get them answered if I can. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
