Issuing and using SHA-1 OCSP signing certificates

[Doug Beattie]

Hello Gerv,

The BRs are clear on the use of SHA-1, but I have a question about the Mozilla policy and how it relates to the use of SHA-1 OCSP signing certificates.

In December 2016 the Mozilla policy 2.3 was published and it didn't address the use of SHA-1 on OCSP signing certificates (see anyone that needs it, this page for links to the Mozilla CA policies: https://wiki.mozilla.org/CA:CertPolicy )

In February 2017, Mozilla Policy 2.4 was published which added stipulations for use of SHA-1 and that has been subsequently updated a few times this year to evolve to this:

5.1.1 SHA-1
CAs MAY sign SHA-1 hashes over end-entity certificates which chain up to roots in Mozilla's program only if all the following are true:
1. The end-entity certificate:
o is not within the scope of the Baseline Requirements;
o contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes;
o has at least 64 bits of entropy from a CSPRNG in the serial number.
2. The issuing certificate:
o contains an EKU extension which does not contain either of the id-kp-serverAuth or anyExtendedKeyUsage key purposes;
o has a pathlen:0 constraint.
Point 2 does not apply if the certificate is an OCSP signing certificate manually issued directly from a root.
In late 2016 we pre-generated a number of OCSP signing certificates for use in signing OCSP messages under our SSL CAs, but since we didn't know this same rule would be applied to non-BR certificates, we didn't pre-generate any OCSP signing certificates for those CAs.

The specific issue is that these client certificate CAs don't have the EKU extension even though we have no intent of issuing SSL certificates (they are WT audited and verified to not issue any SSL certificates per the BRs).

Is it permissible to continue issuing SHA-1 OCSP signing certificates for these existing legacy non-SSL CAs so we may continue providing revocation services using algorithms they support until all certificates under the CAs expire? This would be no later than the end of 2020.

[Gervase Markham]

On 03/10/17 18:35, Doug Beattie wrote:
> The specific issue is that these client certificate CAs don't have
> the EKU extension even though we have no intent of issuing SSL
> certificates (they are WT audited and verified to not issue any SSL
> certificates per the BRs).

Would it be an acceptable solution to add these intermediates to OneCRL?

> Is it permissible to continue issuing SHA-1 OCSP signing certificates
> for these existing legacy non-SSL CAs so we may continue providing
> revocation services using algorithms they support until all
> certificates under the CAs expire? This would be no later than the
> end of 2020.

Can anyone see any problems with an answer to Doug which says that he
may do this once the intermediates are in OneCRL?

Gerv

[Nick Lamb]

On Wednesday, 4 October 2017 20:19:22 UTC+1, Gervase Markham wrote:
> Would it be an acceptable solution to add these intermediates to OneCRL?

I can't think of any reason this isn't a good idea, the intermediate claims never to issue anything Firefox (the consumer of OneCRL) would want to trust.

However if I understand the situation correctly, this situation is already very low risk anyway with no reasonable expectation that it could be exploited against a competent SSL/TLS client which for some reason still accepts SHA1 and of course no risk for e.g. modern Firefox which doesn't accepts SHA1 anyway. If I haven't understood (please anyone jump in) then my assessment may be utterly wrong.

In this part of Doug's hierarchy actual OCSP responses are from a dedicated OCSP signer using SHA1. It might prove possible for attackers to force a collision here by manipulating the details they present, but since it's dedicated to this purpose they can't use the signature in the response to make something else like an X.509 certificate, it won't be trusted in that context. So this is useless practically speaking.

The certificates Doug wants permission to issue - for that dedicated signer itself - are also signed with SHA1 and that signature is trusted on an X.509 certificate, so that could be a target. BUT they're signing something that's directly under Doug's control, not an attacker, so there's no avenue here for collision.

[Doug Beattie]

Hi Gerv and Jacob,

Thanks for the assistance and recommendations.

Since I sent this initial email I found out we have a couple of CAs without EKUs that are issuing SHA-1 Client certificates, so I'm afraid the scope of the question has just expanded beyond just OCSP signing certificates. We've had SHA-2 replacement CAs in production for a while, but some customers need to renew their SHA-1 with SHA-1, so there continues to be some issuance. This will end in January 2018 when they will all be shut down.

The Mozilla requirement to have EKUs in all issuing CAs took us a bit by surprise and I apologize for not getting the internal coordination done as quickly as we should have.

Read more below.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Jakob
> Bohm via dev-security-policy
> Sent: Thursday, October 5, 2017 12:49 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Issuing and using SHA-1 OCSP signing certificates

>
> On 05/10/2017 00:38, Nick Lamb wrote:
> > On Wednesday, 4 October 2017 20:19:22 UTC+1, Gervase Markham wrote:
> >> Would it be an acceptable solution to add these intermediates to OneCRL?
> >
> > I can't think of any reason this isn't a good idea, the intermediate claims
> never to issue anything Firefox (the consumer of OneCRL) would want to
> trust.
> >
>

> Another question though, in the particular case of GlobalSign, isn't it the case
> that all SHA-1 certificates chain to the old GlobalSign root
> (04:00:00:00:00:01:15:4b:5a:c3:94), while all SHA-256 or higher chain to new
> GlobalSign R3 root (04:00:00:00:00:01:21:58:53:08:a2) or one of the other
> GlobalSign Rx roots (including the R2 root now owned by Google).

- All SHA-1 certificates chain to Root R1 (04:00:00:00:00:01:15:4b:5a:c3:94),
- Root R3 only has SHA-256 certificates under it.
- R1 has SHA-256 CAs under it (most of our current SSL CAs are under R1)

> If so, would the proposed SHA-1 OCSP certs chain only to the old root?

Yes, this is true, SHA-1 OCSP certs will chain only to Root R1

> Would that old root be completely unused by current NSS clients (Firefox,
> Thunderbird, Redhat, ...)?

As mentioned above, we have several active SSL SHA-256 CAs under R1, so that's not a good idea.

> Has GlobalSign successfully revoked the R3 to old cross certificate (that failed
> to be revoked due to that OCSP bug a while back).

The OCSP issue a while back was between R1 and R2 and the revocation was related to the sale of that root to google. Yes, those R1/R2 cross certs have all been revoked, but that was not really your question. We have some R1 to R3 cross certificates, but no R3 to R1 cross certificates

> If all 3 answers are Yes, couldn't that old root just be removed from the root
> store with a comment (for the benefit of "clone" root stores) that this root
> CA cert has exited the BR scope to become a dedicated
> SHA-1 only CA used for people needing backwards compatible certificates.

Unfortunately, we continue to use Root R1 for SSL so this would not work.

I keep coming back to the base requirement that a SHA-1 Subordinate CAs must have EKU in order to continue issuing certificates. I understand Mozilla wants to be sure that no SSL certificates are issued using SHA-1, but even if that happened they would not be trusted by any of the major browsers.

We could provide you with the non-SSL SHA-1 CAs and have them added to OneCRL as long as we're sure that would not impact their use for client authentication and secure email. Would that suffice?


> Of cause GlobalSign could continue telling SHA-256 customers to include the
> old-to-R3 cross certificates in chains supplied to clients that may have old
> root stores without R3 (such as Microsoft systems not subscribing to
> automatic CA updates), as those systems would only trust the old root and
> not distrust it over this. Again, this relies on the old root not being explicitly
> blocked in a way that would barf at its inclusion in an alternative certificate
> chain.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public
> discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 04/10/17 23:38, Nick Lamb wrote:
> However if I understand the situation correctly, this situation is
> already very low risk anyway with no reasonable expectation that it
> could be exploited against a competent SSL/TLS client which for some
> reason still accepts SHA1 and of course no risk for e.g. modern
> Firefox which doesn't accepts SHA1 anyway. If I haven't understood
> (please anyone jump in) then my assessment may be utterly wrong.

Of course, this is an argument for ceasing to regulate SHA-1 issuance at
all, because no modern browser accepts it, so why bother? But I don't
think we are quite ready to go there; it does have the useful secondary
effect of going some way to force obsolete software (like old XP) off
the Internet.

Gerv

[Gervase Markham]

On 06/10/17 19:41, Doug Beattie wrote:
> We could provide you with the non-SSL SHA-1 CAs and have them added to OneCRL as long as we're sure that would not impact their use for client authentication and secure email. Would that suffice?

Yes. File a Bugzilla bug.

While we don't have a mandated timescale for this, please migrate new
issuance to appropriately-constrained intermediates if you have not done
so already.

Gerv

[Alex Gaynor]

It also protects consumers of the Mozilla Root Program who are not using it
with a browser -- I know it has been expressed before that that's not a
totally supported use case, but nonetheless it is _extremely_ common to use
a derivative of the Mozilla trust store with verifies like OpenSSL, which
do not limit signature hash algorithms.

Alex

On Sat, Oct 7, 2017 at 3:02 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 04/10/17 23:38, Nick Lamb wrote:

> > However if I understand the situation correctly, this situation is
> > already very low risk anyway with no reasonable expectation that it
> > could be exploited against a competent SSL/TLS client which for some
> > reason still accepts SHA1 and of course no risk for e.g. modern
> > Firefox which doesn't accepts SHA1 anyway. If I haven't understood
> > (please anyone jump in) then my assessment may be utterly wrong.
>

> Of course, this is an argument for ceasing to regulate SHA-1 issuance at
> all, because no modern browser accepts it, so why bother? But I don't
> think we are quite ready to go there; it does have the useful secondary
> effect of going some way to force obsolete software (like old XP) off
> the Internet.
>
> Gerv