908125 - Reject BR EE certificates with lifetimes / validity greater than the BRs allow

Status: NEW

(Core :: Security: PSM, defect, P3)

Description

[Gervase Markham [:gerv]]

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]]

In case it's not clear, this refers to end-entity certificates only.

Gerv

Comment 2

[Daniel Veditz [:dveditz]]

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]

(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]]

(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]

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]

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]

(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]

(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]

(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]

(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]]

(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]

(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]

(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]

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]

Attachment: 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]

Attachment: 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]

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

[Dana Keeler (she/her) (use needinfo) [:keeler]]

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

[Dana Keeler (she/her) (use needinfo) [:keeler]]

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]

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

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Oh, I see. Makes sense, then.

Comment 22

[:Cykesiopka]

(Unassigning myself for now since I'm currently focusing on other work.)

Comment 24

[Daniel C]

Copying my comment from the other bug (and editing summary as this didn't come up when I searched):

The Baseline Requirements first stated a maximum certificate lifetime of 60 months in version 1.0, effective 2012-07-01.

Subsequently, version 1.2.4 stated that the maximum lifetime was reduced to 39 months starting on 2015-04-01, although still up to 60 with detailed justification. Version 1.3.3 removed the exception and required a maximum of 39 months from 2016-02-04.

For reference, Google Chrome has implemented a block on the following types of certificates (all chaining up to publicly trusted roots - private CAs are excluded for now):

- Those issued after 2012-07-01 and that are valid for longer than 60 months
- Those issued after 2015-04-01 and that are valid for longer than 39 months (ignoring the exception period)
- Those issued before 2012-07-01 and that are valid for longer than 120 months (pre-BR common practice limit of 10 years)
- Those issued before 2012-07-01 and that expire after 2019-07-01 (7 years, I can't find a reference for this choice. Without this part, the previous point would allow certificates expiring up until 2022-06-30)

Reference code: https://chromium.googlesource.com/chromium/src/+/master/net/cert/cert_verify_proc.cc#793

(Look for HasTooLongValidity function).

"Month" is not well-defined, but Chrome seems to use calendar months, with a leeway of up to 23:59:59 over (e.g. 2017-01-01 00:00:00 through to 2020-04-01 23:59:59 doesn't return an error).

Comment 25

[Gervase Markham [:gerv]]

The SHA-1 ban means that almost no certs issued before 2012-07-01 are going to be still working anyway. So really only points 1 and 2 of your 4 are meaningful.

Gerv

Comment 26

[Daniel C]

We are now more than 5 years after version 1.0 of the Baseline Requirements became effective (2012-07-01).

I think it would be good to implement the following checks which Chrome has had for a while:

- Reject certificates chaining to publicly-trusted roots issued with a notBefore date of 2012-07-01 or later with a lifetime of longer than 60 months
- Reject certificates chaining to publicly-trusted roots issued with a notBefore date of 2015-04-01 or later with a lifetime of longer than 39 months

To go a step further than Chrome, you could change the first check to be:

- Reject certificates chaining to publicly-trusted roots issued with a lifetime of longer than 60 months

As Gerv says, the pre-2012-07-01 certificates are mostly going to have SHA-1 signatures anyway (I couldn't find a live example of a still-valid pre-BR certificate using SHA-256, after a quick search).

This avoids the extra 2 checks that Chrome is doing for pre-BR certificates: https://chromium.googlesource.com/chromium/src/+/master/net/cert/cert_verify_proc.cc#875

It looks like some of the code from bug 1145679 could be re-used for this but I'm not sure who is best to implement it.