The default bug view has changed. See this FAQ.
Bug 651246 (pkix-default)

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

RESOLVED INVALID

Status

()

Core
Security: PSM
--
enhancement
RESOLVED INVALID
6 years ago
4 years ago

People

(Reporter: briansmith, Unassigned)

Tracking

(Depends on: 3 bugs, {APIchange, dev-doc-needed})

Trunk
APIchange, dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

+++ This bug was initially created as a clone of Bug #479393 +++
Blocks: 651248
No longer blocks: 611781

Comment 1

6 years ago
Make libpkix-based certificate path building/validation the default in PSM
Alias: pkix-default
Depends on: 651585
Depends on: 651994
No longer depends on: 651994
Depends on: 551429
Depends on: 647722
Depends on: 647364
Depends on: 439505
Depends on: 652376
Depends on: 489714
Depends on: 592978
Depends on: 653565
Depends on: 653572

Comment 2

6 years ago
Brian suggested to set APIchange, dev-doc-needed
in bug 479393 comment 58,
and I think it should be rather in this bug.
Keywords: APIchange, dev-doc-needed
Depends on: 655340
No longer depends on: 551429
Blocks: 634074
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.
No longer depends on: 439505, 650296, 650307, 651585
Depends on: 672811

Updated

6 years ago
Depends on: 672871

Updated

6 years ago
Depends on: 640892
No longer depends on: 672871
Blocks: 650307

Updated

6 years ago
No longer depends on: 481656

Updated

6 years ago
No longer depends on: 652376

Updated

6 years ago
No longer depends on: 653565
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.
Depends on: 699874
No longer depends on: 592978, 640892, 653572
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.
Depends on: 551429

Updated

5 years ago
Depends on: 718759
Blocks: 694926

Comment 7

5 years ago
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?

Comment 8

5 years ago
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.

Updated

5 years ago
Blocks: 478418

Updated

5 years ago
Blocks: 155481

Updated

5 years ago
Blocks: 725994

Updated

5 years ago
Blocks: 653572
Depends on: 728321
No longer blocks: 653572

Updated

5 years ago
Depends on: 737802

Updated

5 years ago
Depends on: 489188
Blocks: 765133
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.
No longer depends on: 551429
Depends on: 775827
No longer blocks: 634074

Comment 10

5 years ago
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.
Depends on: 787155
Depends on: 787353
Depends on: 785259
Blocks: 744204

Updated

4 years ago
Depends on: 856060
Depends on: 863534
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.
No longer blocks: 155481, 478418, 650307, 651248, 694926, 725994, 744204, 765133
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.