Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 18:01: > Nelson Bolyard wrote: >> Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 14:47: >> >>> [...] any limitation put into place by the >>> CA will be essentially _useless_!!!! The system is already compromised, >>> why would you believe that it's still bound to a certain domain? There >>> is no way to limit a CA certificate to a certain domain name only. >>> >> Eddy, I think perhaps you misunderstand what Frank was saying. >> >> The rest of your argument in the message to which I am reply seems to >> hinge on this assumption that "there is no way to limit a [subordinate] >> CA to a certain domain". But in fact there *IS* a way for a superior >> CA to constrain the name space in which a subordinate CA may issue certs. >> Certs issued by the subordinate CA that attempt to certify names outside >> of the constrained space fail to pass validation checks. >> > Thanks Nelson! As you indicated in your previous mail, neither you nor > did I ever see such a restricted CA in real life. If this is the case > with the intermediate CA issued by WISeKey, one quarter or my argument > wouldn't be valid. Maybe.... > > ...and only maybe, because the user using an application with NSS (being > it FF, TB or anything else) is the relying party, not the XYZ customer > of some sub CA. It could be me, you or anybody else receiving a mail or > visiting a site which was issued from such a compromised system. Hence > it just limits the scope of the compromise, not the severity itself.
Yes, and (assuming that our name constraints extension handling code is working properly), we would not be fooled at all. We would find the cert to be invalid. Name constraints don't stop the issuer from issuing bogus certs. They stop the relying party from mistakenly relying on bogus certs. > Therefore even if the CA indeed limits the domain with the name > constraints, the relying party can still fall victim. It's a very common > mistake to think that digital certification is about the subscriber or > issuer, but it's really about the relying parties, Mozilla itself being > one... If a subordinate CA's cert is constrained to issue certs only for names in the domain foo.com, and the CA issues a cert for a name in bar.com, and a relying party has correctly working name constraints handling, then the relying party will not compromised by that bar.com cert, because the relying party will find it to be invalid. Now the question has arisen as to whether other software (than NSS) implements name constraints correctly, or at all. There is an open question as to whether or not Windows (and IE) implement it correctly or at all. If not, IE users would be vulnerable to certs that violate their name constraints. But I submit that that question is irrelevant. Mozilla's policy governs certificates that will be used by NSS-based software, which includes most (not all) of Mozilla's products. Mozilla's policy attempts to ensure that the security of Mozilla's products' users will be adequately protected when certs issued by CAs in its trusted root list are relied upon by Mozilla's NSS-based software. Mozilla's policy does not state that the CA certs approved for Mozilla's trusted CA list are "safe" for use in any other products than Mozilla's NSS-based products. (Right Frank? :) This suggests to me that Mozilla should NOT approve for inclusion any certs for root CAs that rely on any constraining cert extensions (name constraints aren't the only ones) that are not implemented in NSS. It also speaks to a question you asked in another thread, about some other product, not NSS based, that is relying on the CA certs in Mozilla's trusted CA list. If that product does not implement all the certificate controls implemented in NSS, then it could be that users of that product will NOT be adequately protected by relying on the root CA certs chosen by mozilla for its own products. I might even suggest that Mozilla's root CA policy be amended to explicitly disclaim any responsibility for security of users who rely on the certs in Mozilla's root CA list, but use them with other non-Mozilla software. /Nelson _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
