1315018 - SHA-1 issuance by GlobalSign root

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Gervase Markham [:gerv]]

https://crt.sh/?cablint=211&iCAID=36&minNotBefore=2016-01-01&opt=cablint lists three intermediate certificates, which use the SHA-1 hash algorithm and were issued in 2016. These certs was issued directly by "GlobalSign Root CA", a root certificate trusted by Mozilla to issue server certificates.

This issuance is in violation of the Baseline Requirements, which Mozilla policies require adherence to. Please can you explain what has happened, with particular reference to the following questions:

A) Does the CP/CPS of the relevant issuing CA forbid the use of SHA-1? If not, why not?

B) What is the audit status of the relevant issuing CAs?

C) Given that the issuance of intermediates is a rare event taking much care, how did you manage to issue some SHA-1 ones?

D) What technical controls are in place within your CA to prevent SHA-1 issuance and how were they bypassed?

Gerv

Comment 1

[Kathleen Wilson]

Steve, Please look into this and update this bug with the information listed above as soon as possible.

Comment 2

[douglas.beattie]

Gerv,

GlobalSign generated some SHA-1 CAs earlier this year as part of normal CA lifecycle management.  These CAs were generated to support S/MIME and client authentication products and we don’t intent to use them for SSL certificate issuance.  These CAs are not technically constrained and they were disclosed to Mozilla in March 2016, shortly after they were created.

Since these CAs will not be used to issue SSL certificates we didn’t believe that they fall under the BRs, and we didn’t see anything in the Mozilla policy that prohibited the creation of new SHA-1 CAs as long as they were not intended to be used to issue SSL certificates.  If we misinterpreted your intent, we apologize, but based on your notes there is some "acknowledged" ambiguity which you appear to be addressing.

Why did we use SHA-1?
- We have several customers using our retail PersonalSign 1, 2, and 3 offering that continue to need SHA-1 S/MIME and/or client certificates including US FDA S/MIME, Belgian government and the Peru government.  Not directly related is the need for SHA-1 Code Signing to support those applications that need to be used on older operating systems.

Why did we not technically constrain these CAs?
- Adding EKU to CAs can have unintended consequences, especially in older applications.  Since we don't know all the applications that are using the email/client auth certificates it's risk we didn't want to take.  Also, there is a minor Thunderbird email issue with using EKUs in CAs: https://bugzilla.mozilla.org/show_bug.cgi?id=1225818

I hope this helps.

Doug

Comment 3

[Gervase Markham [:gerv]]

The BRs say:

"These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet."

Mozilla policy says:

"CA operations and issuance of certificates to be used for SSL-enabled servers must also conform to version 1.1.5 of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates."

Because both of these use language of intent, it is at best unclear whether the SHA-1 ban applies to certificate not intended for server use. There is a discussion going on in m.d.s.policy to remedy this loophole.

Gerv