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 -----Original Message----- From: Gervase Markham [mailto:[email protected]] Sent: Monday, November 7, 2016 10:46 AM To: Doug Beattie <[email protected]>; [email protected] Subject: Re: Implementing a SHA-1 ban via Mozilla policy On 07/11/16 15:34, Doug Beattie wrote: > I'd prefer a requirement for long serial numbers over a total ban on > SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend > using that for non BR certificates (assuming client applications don't > have issues with that). Can you list some of the uses you'd still like to use SHA-1 in publicly-trusted hierarchies for? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
