+++ This bug was initially created as a clone of Bug #479393 +++

Make libpkix-based certificate path building/validation the default in PSM

Brian suggested to set APIchange, dev-doc-needed in bug 479393 comment 58, and I think it should be rather in this bug.

Bug 439505 and bug 653572 are not blockers for this. Bug 651585 blocks enabling AIA cert fetching, but not this. (The dependency is already set in that bug.) Bug 650307, bug 650296, bug 653565, and must all be fixed before libpkix is enabled by default on Aurora/Beta/Final release. I also want to investigate bug 480706 further.

Kai, I propose that we remove the dependencies on bug 592978 and bug 640892 and instead change our bad cert handler to avoid using CERTVerifyLog at all, as I explained in the email I sent you today. As I commented in bug 489714, I think the current (old) cert verification code would have the same problem, so that shouldn't be a blocker. I also don't think we need to have bug 647364 block this. If we have explicitly distrusted a root or intermediate CA, it is OK if the user can't explicitly trust an EE or intermediate chained to the distrusted cert. It is probably better that way, actually. I also think we do not need to fix 653572 to enable libpkix by default. We can open up a new bug to change the default certificate validation for extensions using the old API, and fix it later. Do you agree with the above? If so, that would leave only bug 672811 to fix and bug 647722 to investigate and possibly fix. I will investigate bug 647722 tomorrow and I will submit patches for the remaining issues (the cert override issue which would require a new bug, and bug 672811 which I already know how to fix without a change to NSS). Then we would be able to try to enable libpkix for FF11. This would resolve bug 634074, which is a very high priority.

We need to make sure that all the blacklisted certificates have the correct "distrusted" version of the cert, for the reason Wan-Teh mentions in bug 642503 comment 50.

If we don't fix bug 653572, then we will need to explicitly call CERT_SetusePKIXForValidation(PR_FALSE) in libpkix mode to avoid bug 551429.

Excited to see this change make it in, will it also include executing the NIST PKITS tests (http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html) publishing the results?

blocks: 478418 US Federal Bridge PKI doesn't certify end-entities, it cross-certifies other roots. libpkix is necessary, dveditz tells me, for cross-certification.

I am removing bug 551429 from the blocking list because we have a workaround for that in bug 728321, which is already blocking this bug.

Today we discussed the initial step in switching Mozilla to libPKIX should be low impact, and behaviour like amount of OCSP and CRL downloads should be similar to what we have today. That probably means, we'll want to keep automatic CRL downloading disabled for the initial step. The idea is to enable CRL downloading in a subsequent step, so we can better distinguish whether bug reports are related to libPKIX or rather related to enabling of additional downloading etc.

(In reply to Kai Engert (:kaie) from comment #10) > Today we discussed the initial step in switching Mozilla to libPKIX should > be low impact, and behaviour like amount of OCSP and CRL downloads should be > similar to what we have today. I filed bug 775827 about this, and I will clarify its summary so it is clear that it is about making the default revocation checking behavior for libpkix-based verification to be the same as the default revocation checking behavior for classic verification, with respect to both CRLs and OCSP.

As discussed on nss-dev, libpkix won't become the default in Gecko. This will be discussed further on the dev-tech-crypto mailing list soon.