1. libpkix can handle cross-signed certificates correctly, without getting stuck in loops. Non-libpkix validation cannot.
2. libpkix can accept parameters that control each individual validation, whereas non-libpkix validation relies on global settings. 2.a. libpkix can control OCSP/CRL/cert fetching on a per-validation basis. 2.b. libpkix can restrict the set of roots that are validated. non-libpkix validation cannot. 3. libpkix can enforce certificate policies (e.g. requiring EV policy OIDs). Can the non-libpkix validation? 4. libpkix can can return the full certificate chain to the caller. The non-libpkix validation cannot. 5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch revocation information for every cert in a chain. The non-libpkix validation cannot (right?). 5.b. libpkix can (in theory) fetch using LDAP in addition to HTTP. non-libpkix validation cannot. 5.c. libpkix checks for revocation information while walking from a trusted root to the EE. The non-libpkix validation does the fetching while walking from the EE to the root. Are there any other benefits? As for #5, I don't think Firefox is going to be able to use libpkix's current OCSP/CRL fetching anyway, because libpkix's fetching is serialized and we will need to be able to fetch revocation for every cert in the chain in parallel in order to avoid regressing performance (too much) when we start fetching intermediate certificates' revocation information. I have an idea for how to do this without changing anything in NSS, doing all the OCSP/CRL fetching in Gecko instead. It seems to me that it would be relatively easy to add #2, #3, and #4 to the non-libpkix validation engine, especially since we can reference the libpkix code I don't know how much effort it would take to implement #1, but to my naive mind it seems like we could get something very serviceable pretty easily by trying every matching cert at each point in the chain, instead of checking only the "best" match. Is there some complexity there that I am missing? I know that just about everybody has expressed concerns about how difficult libpkix is to maintain. And, also, it is huge. I am not aware of all the problems that the older validation code has, so it seems like it might be somewhat reasonable to extend the old validation code to add the features it is missing, and avoid using libpkix at all. Thoughts? Thanks, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
