> 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. > > 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.
In my experience, most of the EV-certifying CAs have versions of their EV root that are cross-signed by their 'legacy' (non-EV) root. This is to allow non-EV legacy systems to properly recognize the EV-issued certificate as valid, while EV-aware systems utilize the newer trust anchor. The result of this is that there are at least two, often more, 'valid' chains that can be returned - but often one and only one will be valid for the EV policy. The heuristics described in RFC 4158 can be used to rank the EV-validated chain as higher (and thus return it first). libpkix, given its 4158 implementation, could be easily expanded to support this - and better, in my experience, than the non-libpkix path. non-libpkix tends to return the 'first' chain that is valid, which is non-deterministic based upon sites the user has previously visited, the security modules the user may have installed, and seemingly how NSS is feeling at that time of day. Though an EV-specific solution might be able to be coded, it would likely end up being just that - EV specific - and not really re-usable (eg: for things like Baseline Requirements or for some of the other OID asserations being proposed). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
