On Sunday, December 4, 2016 at 5:58:56 PM UTC+8, Peter Gutmann wrote: > Wen-Cheng Wang writes: > > >However, that does not means our PKIX (RFC-5280) conforimg implementation > >will cause errors or bugs to current implementations of browsers. > > Given all the bizarre stuff that ended up in the PKIX spec, it would be quite > easy to create a fully PKIX-compliant cert that had all manner of strange and > unexpected interactions with browsers (see my previous message for examples). > The skill required for deploying certs is to know (or at least have a general > idea of) what will happen to them in the wild, not to assume that whatever > peculiar thing the PKIX spec says is actually implemented by anyone.
Actually, we have tested the capabilities of many browsers in the wild and found they can live peacefully with our PKIX-compliant root certs. They are not so weak as you might think. What I do not understand is why the first responses of people here seems in a hurry to reject a PKIX-compliant root cert? Currently, there is no rule in Mozilla CA policy that forbid a root CA to retain its DN after re-key. What we need to do here is simply to test whether Mozilla NSS can live peacefully with our PKIX-compliant root certs. If it does, why not accept it? > > >Actually, in RFC 5280 as well as the original X.509 standard, the recommended > >official way to distinguish the different generation of CA certificates is by > >using the chaining of the Issuer Key Identifier extension and Subject Key > >Identifier extension (as you mentioned) in certification path processing. > > OK, that's one of the less crazy things in the spec, but it still doesn't > guarantee that much, if anything, does it that way. In practice, you chain by > DN, not by key ID. Of course we chain up the certification path by DN. The Authority Key Identifier extension and the Subject Key Identifier extension are to be used to facilitate choosing different generation of CA certificates. I do not mean that the certification path is chained up by key ID. Wen-Cheng Wang _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
