Nelson Bolyard wrote: > Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-08 18:01: > > ...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. > OK!
But back to our issue, if a compromised server issues a certificate from within the name constraint and uses it to attack another user (by claiming to send mail from [EMAIL PROTECTED] or setting up a fake site for https://really.allowed-domain.com), this would be the classical MITM vector SSL is meant to prevent. Hence it doesn't matter really if there is or isn't a name constraint, just the range of possible attacks is limited. CAs which issue sub CAs without taking responsible actions to control, verify and guide them, are suspected to being compromised right from the beginning. Without insisting on this, we can just stop reviewing CAs altogether and save us the hassle... > > 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. > Which is completely off-topic ;-) > > 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. > This argument however might be very important when evaluating CAs for inclusion...I'm not aware of any such circumstances right now. Even WISeKey hasn't yet confirmed if they use constraints at all. Haven't seen anything in their CP/CPS, but might have missed it? No, the limitations are in the software to all of my knowledge... > 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. A valid argument which deserves its own thread perhaps. I'm not sure if Mozilla takes any responsibility to start with (strictly legalese speaking).. -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
