Jean-Marc Desperrier wrote: > Brian Smith a écrit : > > 3. libpkix can enforce certificate policies (e.g. requiring EV > > policy OIDs). Can the non-libpkix validation? > > EV policy have been defined in a way that means they could be > supported by a code that handles an extremely tiny part of all what's > possible with RFC5280 certificate policies.
Right. How much of PKIX a client actually needs to implement is still an open question in my mind. > They could even not be supported at all by NSS, and instead handled > by a short bit of code inside PSM that inspects the certificate chain > and extract the value of the OIDs. Given that the code above NSS needs > anyway to have a list of EV OIDs/CA name hard coded (*if* I'm > correct, I might be wrong on that one), it wouldn't change things that > much actually. AFAICT, it is important that you know the EV policy OID you are looking for during path building, because otherwise you might build a path that has a cert without the EV policy even when there is another possible path that uses certs that all have the policy OID. On the other hand, do we really need to do path building at all? It seems reasonable to me to require that sites that want EV treatment to return (in their TLS Certificates message) a pre-constructed path with the correct certs (all with the EV policy OID) to verify (sans root), which is what the TLS specification requires anyway. So, I would say that, AFAICT, practical EV support doesn't really require PKIX processing, though other things might. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
