Last Comment Bug 908125 - Reject BR EE certs with lifetimes greater than the BRs allow
: Reject BR EE certs with lifetimes greater than the BRs allow
Status: NEW
[psm-backlog]
:
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: unspecified
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 1145679
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 02:35 PDT by Gervase Markham [:gerv]
Modified: 2016-05-25 16:15 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
MozReview Request: Bug 908125 - Reject BR EE certs with lifetimes greater than the BRs allow. (40 bytes, text/x-review-board-request)
2015-07-12 09:41 PDT, :Cykesiopka
dkeeler: feedback+
Details | Review
MozReview Request: Bug 908125 - Allow overrides for MOZILLA_PKIX_ERROR_VALIDITY_TOO_LONG. (40 bytes, text/x-review-board-request)
2015-07-12 09:41 PDT, :Cykesiopka
no flags Details | Review

Description Gervase Markham [:gerv] 2013-08-22 02:35:50 PDT
Google plans, as of the start of 2014, to stop recognizing certificates with lifetimes > 60 months (in their equivalent of Nightly, and the change will ride the trains):
https://cabforum.org/pipermail/public/2013-August/002135.html

Everyone agrees such certs, when newly issued, are incompatible with the Baseline Requirements. Some CAs have argued that when _re_issued, this is not so, but Google does not agree with them.

We should consider making the same change.

Gerv
Comment 1 Gervase Markham [:gerv] 2013-08-22 08:09:37 PDT
In case it's not clear, this refers to end-entity certificates only.

Gerv
Comment 2 Daniel Veditz [:dveditz] 2013-08-22 16:44:21 PDT
From a business/legal standpoint I can see the CA's case: if they sold a product with one set of terms (both lifetime and "service policy" about how certs are reissued) and then come back later and say "sorry, we're chopping two years off that cert" they could be in hot water. Although it does seem as if re-issuing as a 60-month cert with the promise to re-issue with the balance later ought to be satisfactory.

If we get to make up our own requirements that differ from the Baseline Requirement consensus can we say 60 months is still ridiculous and impose a 36 months limit? How fast do company takeovers and mergers happen? 3 years is still probably too long in practice.
Comment 3 Rob Stradling 2013-08-23 01:08:00 PDT
(In reply to Daniel Veditz [:dveditz] from comment #2)
> If we get to make up our own requirements that differ from the Baseline
> Requirement consensus can we say 60 months is still ridiculous and impose a
> 36 months limit? How fast do company takeovers and mergers happen? 3 years
> is still probably too long in practice.

Dan,
The Baseline Requirements also say:
"...Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months."

It would not be unreasonable for Mozilla's code to enforce that rule.

If Mozilla thinks 39 months is still too long, then there's nothing to stop you from making a proposal to the CABForum to reduce it even further.
Comment 4 Gervase Markham [:gerv] 2013-08-23 01:50:42 PDT
(In reply to Daniel Veditz [:dveditz] from comment #2)
> From a business/legal standpoint I can see the CA's case: if they sold a
> product with one set of terms (both lifetime and "service policy" about how
> certs are reissued) and then come back later and say "sorry, we're chopping
> two years off that cert" they could be in hot water. Although it does seem
> as if re-issuing as a 60-month cert with the promise to re-issue with the
> balance later ought to be satisfactory.

No-one is asking CAs to not give customers what they've paid for in terms of duration; it will just need to be 2 (or more) separate certs. I agree that changing certs once every 5 years rather than every 10 might be a minor inconvenience for customers who use the same web server hardware and software for > 5 years, but I'm not sure how large a group that is.

Google's metrics suggests that this restriction will affect only 2038 certificates that they found. Those certs will need to be replaced with ones of 5 year duration before Chrome stops accepting them in 2014.

> If we get to make up our own requirements that differ from the Baseline
> Requirement consensus 

Let's be clear: we are not making up our own requirements that differ from the BRs. We and Google both think the BRs are clear that all certs issued under the BRs should have a validity of 60 months or less (at the moment - that limit is changing to 39 months on 1st April 2015). Some CAs have tried to argue that a reissue/rekey doesn't count, but we don't think that the English language is capable of supporting such an interpretation of the word "issue".

> can we say 60 months is still ridiculous and impose a
> 36 months limit? How fast do company takeovers and mergers happen? 3 years
> is still probably too long in practice.

See above; on 1st April 2015 the limit comes down to 39 months (rationale: 3 years, plus a little extra overlap time to get the cert changed). These figures are hard-won compromises; we could of course just act unilaterally, but I am reluctant to do so.

Gerv
Comment 5 Rick Andrews 2013-08-23 17:27:41 PDT
Gerv, would Mozilla also think about blocking use of certs 
* that are not of type X.509 v3
* that have an RSA key with size less than 1024 bits
* that are signed using the MD2, MD4 or MD5 hash algorithm?
Comment 6 Ryan Sleevi 2013-08-23 21:11:03 PDT
Mozilla already blocks MD2/MD4/MD5 certs.

http://mxr.mozilla.org/nss/source/lib/certhigh/certvfy.c?mark=41,65-69#37
http://mxr.mozilla.org/nss/source/lib/util/secoid.c?mark=1930-1940#1930

Can you please explain what security benefit to users would be served by only supporting X.509v3?

I would encourage Mozilla to also drop support for keys < 1024-bits. Chrome (all platforms) and Microsoft (IE) have already done so. However, that may be worth a separate bug.
Comment 7 Kaspar Brand 2013-08-23 23:11:29 PDT
(In reply to Ryan Sleevi from comment #6)
> I would encourage Mozilla to also drop support for keys < 1024-bits.

See bug 360126 (which is sort of blocked by bug 790809, apparently).

(In reply to Gervase Markham [:gerv] from comment #0)
> Google plans, as of the start of 2014, to stop recognizing certificates with
> lifetimes > 60 months

An important additional condition not mentioned here so far: Ryan's message on the CABF public list states that Google "will reject as invalid any and all certificates that have been issued after the Baseline Requirements Effective Date of 2012-07-1 and which have a validity period exceeding the specified maximum of 60 months". I.e., certificates issued before 1 July 2012 are still allowed to have a validity of more than 60 months.
Comment 8 Ryan Sleevi 2013-08-23 23:37:21 PDT
(In reply to Kaspar Brand from comment #7)
> (In reply to Ryan Sleevi from comment #6)
> > I would encourage Mozilla to also drop support for keys < 1024-bits.
> 
> See bug 360126 (which is sort of blocked by bug 790809, apparently).

Hrm. I don't really understand why it should be blocked on 790809, even given Mozilla's (legacy) cert validation. It "should" be as simple as adding it to the filter that sorts certs by issuance date. I know bsmith is working on fixing that up with insanity::pkix, but it'd be a reasonable step forward.

> 
> (In reply to Gervase Markham [:gerv] from comment #0)
> > Google plans, as of the start of 2014, to stop recognizing certificates with
> > lifetimes > 60 months
> 
> An important additional condition not mentioned here so far: Ryan's message
> on the CABF public list states that Google "will reject as invalid any and
> all certificates that have been issued after the Baseline Requirements
> Effective Date of 2012-07-1 and which have a validity period exceeding the
> specified maximum of 60 months". I.e., certificates issued before 1 July
> 2012 are still allowed to have a validity of more than 60 months.

Right.

The negotiation in the CA/B Forum regarding the expiration was a long one, balanced by the risks to users, the costs to CAs, and the benefits to security. In the end, it was agreed to allow the certificates to expire naturally, while working to improve the issuance pipeline going further.

The change list in discussion is https://codereview.chromium.org/20628006/ , with the bug at https://code.google.com/p/chromium/issues/detail?id=119211
Comment 9 Kaspar Brand 2013-08-24 08:32:36 PDT
(In reply to Ryan Sleevi from comment #8)
> (In reply to Kaspar Brand from comment #7)
> > (In reply to Ryan Sleevi from comment #6)
> > > I would encourage Mozilla to also drop support for keys < 1024-bits.
> > 
> > See bug 360126 (which is sort of blocked by bug 790809, apparently).
> 
> Hrm. I don't really understand why it should be blocked on 790809, even
> given Mozilla's (legacy) cert validation. It "should" be as simple as adding
> it to the filter that sorts certs by issuance date.

I argued for adding such weak key checks directly to libSSL (i.e. NSS) in bug 587234, but the "Reject more weak server keys" patch was dismissed in the end. Maybe it's time to resurrect that patch (attachment 468110 [details] [diff] [review], but with SSL_MIN_PUB_KEY_BITS increased to 1024), instead of adding such checks to PSM?
Comment 10 Rick Andrews 2013-08-26 11:17:26 PDT
(In reply to Ryan Sleevi from comment #6)
> Mozilla already blocks MD2/MD4/MD5 certs.
> 
> http://mxr.mozilla.org/nss/source/lib/certhigh/certvfy.c?mark=41,65-69#37
> http://mxr.mozilla.org/nss/source/lib/util/secoid.c?mark=1930-1940#1930

That's encouraging; thanks. I just wish the info was more readily available than just in the source code.

> Can you please explain what security benefit to users would be served by
> only supporting X.509v3?

Yes, if the cert isn't v3, it won't have extensions. The CABF BRs list two extensions that MUST be present (three if stapling isn't being used). Without extensions, there's a risk that code will allow the cert to be used for unintended uses. Since v3 is the norm, I think there's a possibility that code isn't frequently tested with v1 certs.
Comment 11 Gervase Markham [:gerv] 2013-08-26 11:30:31 PDT
(In reply to Rick Andrews from comment #10)
> That's encouraging; thanks. I just wish the info was more readily available
> than just in the source code.

https://wiki.mozilla.org/CA:MD5and1024 :-)

> Yes, if the cert isn't v3, it won't have extensions. The CABF BRs list two
> extensions that MUST be present (three if stapling isn't being used).
> Without extensions, there's a risk that code will allow the cert to be used
> for unintended uses. Since v3 is the norm, I think there's a possibility
> that code isn't frequently tested with v1 certs.

A fair point, and one which relates to the post I recently made in the Forum about how NSS decides what certs can be used for what purposes. It has special processing for < v3 certs.

Gerv
Comment 12 Rick Andrews 2013-08-26 13:25:54 PDT
(In reply to Gervase Markham [:gerv] from comment #11)
> (In reply to Rick Andrews from comment #10)
> > That's encouraging; thanks. I just wish the info was more readily available
> > than just in the source code.
> 
> https://wiki.mozilla.org/CA:MD5and1024 :-)

Gerv, I'm extremely grateful for this documentation, but I note that it only mentions MD5, not MD2 or MD4. Would you be willing to update it?
Comment 13 Kathleen Wilson 2013-08-26 18:06:13 PDT
(In reply to Rick Andrews from comment #12)
>> 
>> https://wiki.mozilla.org/CA:MD5and1024 :-)
> 
> Gerv, I'm extremely grateful for this documentation, but I note that it only
> mentions MD5, not MD2 or MD4. Would you be willing to update it?

Done -- added the following to the wiki page:
"Note: NSS does not accept MD2 and MD4 as hash algorithms in certificate signatures."
If you want to work on the wording more, please send me email and we'll handle outside of this bug.
Comment 14 :Cykesiopka 2015-06-21 06:31:27 PDT
I've been working on patches for this bug in tandem with the patches for Bug 1145679, so I'm just going to go ahead and assign myself to this now.

With regards to the change to the summary:
 - I intend to enforce the newer 39 month limit as well.
 - I don't intend to be stricter than Chrome on this, so I'm making it clear that the limit only applies to BR certs.
Comment 15 :Cykesiopka 2015-07-12 09:41:36 PDT
Created attachment 8632563 [details]
MozReview Request: Bug 908125 - Reject BR EE certs with lifetimes greater than the BRs allow.

Bug 908125 - Reject BR EE certs with lifetimes greater than the BRs allow.
Comment 16 :Cykesiopka 2015-07-12 09:41:38 PDT
Created attachment 8632564 [details]
MozReview Request: Bug 908125 - Allow overrides for MOZILLA_PKIX_ERROR_VALIDITY_TOO_LONG.

Bug 908125 - Allow overrides for MOZILLA_PKIX_ERROR_VALIDITY_TOO_LONG.
Comment 17 :Cykesiopka 2015-07-12 09:44:49 PDT
Comment on attachment 8632563 [details]
MozReview Request: Bug 908125 - Reject BR EE certs with lifetimes greater than the BRs allow.

MapResultPerBrRequirements() is rather icky, but I'm not sure how else I can achieve the same results in a less icky way - just asking for feedback for now.
Comment 18 David Keeler [:keeler] (use needinfo?) 2015-07-13 15:45:28 PDT
https://reviewboard.mozilla.org/r/13099/#review11741

This looks good. I do have some feedback - see below.

::: security/certverifier/CertVerifier.cpp:121
(Diff revision 1)
> +MapResultPerBrRequirements(Result originalResult, ScopedCERTCertList& builtChain)

I get the motivation here, but I don't think we should do this. If we're concerned about breakage, we should gather telemetry with fallback like we've been doing for small RSA keys and SHA-1 signatures.

::: security/certverifier/NSSCertDBTrustDomain.cpp:910
(Diff revision 1)
> +        maxValidityDuration = DURATION_10_YEARS;

Was there a limit on validity duration before 2012? We should probably just allow unlimited duration for these certificates for now.

::: security/manager/ssl/tests/unit/pycert.py:18
(Diff revision 1)
> +[validity:[notBefore string in YYYYMMDD format],<validity period in days>]

In the implementation of this, it's implicitly the case that notBefore = now - 7 days if it's unspecified. How about we make that explicit by saying that validity can be specified either as "validity:<YYYYMMDD>,<validity period in days>" OR "validity:now-<timedelta>,now+<timedelta>" (e.g. "validity:now-10days,now+10days" or something).

::: security/manager/ssl/tests/unit/test_validity.js:151
(Diff revision 1)
> +  // TODO: Checking the DV chains ahead of the EV chains causes the

This is strange. The order shouldn't matter. Maybe we need to clear the OCSP cache in between the two sets of tests?
Comment 19 David Keeler [:keeler] (use needinfo?) 2015-07-13 15:47:21 PDT
https://reviewboard.mozilla.org/r/13101/#review11769

In general, looks good. If we go the telemetry/fallback route, we won't need this for a bit, though.

::: security/manager/ssl/tests/unit/test_cert_overrides.js:234
(Diff revision 1)
> +  if (validityCheckingWillCauseErrors) {

Depending on how the other patch goes, this will probably change.
Comment 20 Ryan Sleevi 2015-07-13 15:50:45 PDT
dkeeler: see https://code.google.com/p/chromium/issues/detail?id=119211 for Chrome's checks. The pre-2012 certs would be fairly mad to accept, considering their week cryptographic properties (RSA-1024)
Comment 21 David Keeler [:keeler] (use needinfo?) 2015-07-13 15:59:28 PDT
Oh, I see. Makes sense, then.
Comment 22 :Cykesiopka 2016-03-14 06:45:48 PDT
(Unassigning myself for now since I'm currently focusing on other work.)

Note You need to log in before you can comment on or make changes to this bug.