On 2010-07-21 10:50 PDT, Ryan Sleevi wrote, quoting Gervase Markham: >> On 21/07/10 07:26, Amax Guan wrote: >>> But if you generate a user Certificate that's issued by a untrusted CA, >>> there will be an alert popup. >> Can some NSS or PSM hacker explain why this is? >> >> Gerv > > While neither an NSS nor PSM hacker,
Considering the excellent job you did with the research below, I do hereby pronounce you to be an official PSM hacker! > the implementation details (in moz-central) are at [1] > > If any certs beyond the user cert are supplied, then ImportValidCACerts() is > called. The certificates are all imported as temporary certificates, then > each certificate is tested to see if a chain can be built [2]. > > The "simple" way to work around this would be to only supply the user's > certificate in the application/x-x509-user-cert (since the user's cert is > not placed through this verification logic) OR, first supply (and have the > user install) the CA certificate of the issuing authority using the > previously recommended application/x-x509-ca-cert. Exactly the advice I was going to give. This is as intended. The user's own cert may be imported without any restriction. It is not required to chain to any known authority. But authority certs, in general, and certs for other than the user's own, are required to chain to known authorities, lest they be used for attacks. The Chinese Bank should be able to merely download just the user's cert to the browser, and then when requesting client auth, request it using the name of the issuer of the client's cert. The browser will then send just the client's cert, which the bank will be able to validate by supplying the rest of the chain itself. This is all S.O.P. > As for a good answer why, I can only speculate, but I suspect some code > paths would be affected by blindly importing certificates without first > vetting their chain. eg, a malicious party could supply a certificate that > appeared to be the same as a valid intermediate CA certificate (except that > the signature was wrong, naturally). If that certificate ended up being > selected during chain building/locating by subject/etc (pre-libpkix/STAN), > then it would cause connections using that intermediate to fail (a DoS). > > Actually, a little CVS blame digging, and it turns out this is the case. See > [3] > > [1] > http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSS > CertificateDB.cpp#885 > [2] > http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSS > CertificateDB.cpp#772 > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=249004 > > > -- /Nelson Bolyard <b> </b> 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
