Closed
Bug 653572
Opened 14 years ago
Closed 11 years ago
PSM should use CERT_SetUsePKIXForValidation() to switch all calls to libpkix (calls from with NSS, or from extensions)
Categories
(Core :: Security: PSM, enhancement)
Core
Security: PSM
Tracking
()
RESOLVED
INVALID
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: briansmith, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: APIchange, dev-doc-needed)
Attachments
(1 file)
(deleted),
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #479393 +++ There is a question as to whether we should call CERT_SetUsePKIXForValidation(PR_TRUE) so that extensions start using libpkix instead of the old certificate validation semantics. My opinion is we shouldn't do so, because (a) we cannot make these calls use the same verification options as we are using for other verifications (which is really what extensions would want, I would guess), and (b) some extensions may be somehow relying on the old validation behavior. I recommend WONTFIX.
Comment 1•14 years ago
|
||
(In reply to comment #0) > > There is a question as to whether we should call > CERT_SetUsePKIXForValidation(PR_TRUE) More precisely, my proposal is: - query the preference that either enables or disables the use of libpkix in PSM - use either TRUE or FALSE for this function call during PSM init, depending on the preference. When using PR_FALSE, it's a noop and keeps the old behaviour. When the preference is set to TRUE, we really want to use libpkix for all uses, including potential indirect calls triggered from NSS itself. > so that extensions start using libpkix > instead of the old certificate validation semantics. Not limited to extensions, this affects calls from inside NSS to verifications, too. (I don't know whether such code paths exist that affect PSM. I haven't read all of NSS. My argue is, let's just make sure we're switching completely.) Regarding extensions, I think you refer to Firefox add-ons that: - do not use the XPCOM interfaces that PSM provides - directly link to NSS and directly call C interfaces Difficult question and decision. In my opinion, the driving factor for answering this question should be, what's our strategy? Is it (a) continue to keep the old verifications APIs forever, with the old semantic or is it (b) encourage everyone to switch to libPKIX. I suspect it's (b). If it's really (b), then having libPKIX use globally enabled, this would be a good opportunity for the developers of such extensions to notice that things are changing. If they don't like the new behaviour, they are free to update their code to use their own defaults.
Reporter | ||
Comment 3•14 years ago
|
||
I think this won't work, for the same reason we aren't using CERT_SetUsePKIXForValidation for the core validaiton in PSM: there isn't a way to set the validation options (CRL options, OCSP options, missing cert fetching, etc.). That's why I said that this is a third set of semantics. Also, as we saw with the need for us to use SkipOcsp/SkipOcspOff() previously, the old API is really problematic when concurrently validating certificate chains. I would rather have extensions continue to work the same way they always have, and document that the old API is deprecated in Mozilla. I've already started auditing the code in NSS to find places where calls to the old API are done and I will file bugs about any calls to those functions. (I know one case is the handling of SSL step up in SSL, which should be disabled in PSM anyway.)
Updated•14 years ago
|
Summary: PSM should use CERT_SetUsePKIXForValidation() to switch extensions to libpkix → PSM should use CERT_SetUsePKIXForValidation() to switch all calls to libpkix (calls from with NSS, or from extensions)
Comment 4•14 years ago
|
||
Comment on attachment 529514 [details] [diff] [review] Patch v1 - Do not check in until bug 551429 is fixed (by way of a libPKIX improvement) r+ rrelyea
Attachment #529514 -
Flags: review?(rrelyea) → review+
Reporter | ||
Comment 5•14 years ago
|
||
This will cause stack overflows due to bug 635384, that do not occur without it.
Reporter | ||
Updated•14 years ago
|
Attachment #529514 -
Attachment description: Patch v1 → Patch v1 - Do not check in until bug 635384 is fixed
Reporter | ||
Updated•13 years ago
|
No longer blocks: pkix-default
Reporter | ||
Comment 6•13 years ago
|
||
From Sean Leonard on the dev-tech-crypto thread "libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)":
> As stated, we would like to move away from using
> CERT_VerifyCertificate, provided that CERT_PKIXVerifyCert is
> strictly better. CERT_PKIXVerifyCert has significant gaps in
> functionality that need to be addressed first.
So, calling CERT_SetUsePKIXForValidation(PR_TRUE) may actually have negative effects w.r.t. addon compatibility.
Reporter | ||
Updated•13 years ago
|
Reporter | ||
Comment 7•13 years ago
|
||
The patch in bug 551429 does the exact opposite of this. Because of the addon compatibility issues, I am proposing we WONTFIX this. Re-open if you disagree.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Comment 8•13 years ago
|
||
I disagree. Reopening. We must improve libPKIX to work correctly.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•13 years ago
|
Depends on: pkix-default
Updated•13 years ago
|
Attachment #529514 -
Attachment description: Patch v1 - Do not check in until bug 635384 is fixed → Patch v1 - Do not check in until bug 551429 is fixed (by way of a libPKIX improvement)
Reporter | ||
Comment 9•13 years ago
|
||
(In reply to Kai Engert (:kaie) from comment #8) > I disagree. Reopening. > > We must improve libPKIX to work correctly. There is no way libpkix will be enabled by default in mozilla13 if you insist that all the bugs in libpkix that would block this bug be fixed. There is a lot of work that needs to be done to make libpkix backward-compatible enough to make it the default for all addon use cases too. Again, see Sean's email on dev-tech-crypto.
No longer depends on: pkix-default, 728321
Comment 10•13 years ago
|
||
Please acknowledge that libpkix won't be the default in moz13 because the functionality which it provides is insufficient for effective transition. Until it's fixed, this bug needs to depend on bug 651246 and bug 728321. Otherwise, you're pushing an increased library initialization footprint with no benefit, also called "dead code".
Reporter | ||
Comment 11•11 years ago
|
||
There's no need for calling CERT_SetUsePKIXForValidation in Gecko given that we're ready to switch to insanity::pkix in Firefox. Additionally, I am planning to make it so that Gecko builds NSS without building libpkix to save footprint, so CERT_SetUsePKIXForValidation won't even be available to call.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•