[cabfpub] Intent to Deprecate: SHA-1 certificates

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Thu Aug 28 18:44:40 MST 2014

Ryan, I think you have misinterpreted both Microsoft’s and Mozilla’s policies.

Microsoft says “issue no new SHA-1 certs on or after 1/1/2016” – but SHA-1 certs issued before that date that expire by 12/31/2016 are ok – they don’t need to be switched out, now or later.  Only SHA-1 certs expiring in 2017 are invalid.

Mozilla’s policy is more or less the same – SHA-1 certs will be treated as valid through 12/31/2016.  CAs should refrain from issuing any new ones now (even those expiring in 2016), but may do so if the customer says it’s necessary for compatibility reasons.  Only SHA-1 certs expiring in 2017 are invalid.

So 2016 SHA-1 certs are ok with both browsers – but 2017 certs are not.

I can assure you that any Trend Micro customer who has a SHA-1 cert expiring in Nov. or Dec. 2016 (there are no such customers today – we only issue one-year and two-year certs) will know from us well in advance what is coming.  Maybe we will pull back our maximum validity date for new SHA-1 certs to earlier than Nov. 2016 – it’s something to think about.

I can also assure you that a Trend Micro customer with SHA-1 certs expiring in the first half of 2016 would much rather receive reminders and pestering notices from us over the next 18 months to change to SHA-256 (as they will) than to have to change hundreds of 2016 certs today and again in 2015  – no question about it.

From: sleevi at google.com [mailto:sleevi at google.com] On Behalf Of Ryan Sleevi
Sent: Thursday, August 28, 2014 5:22 PM
To: Kirk Hall (RD-US)
Cc: Chris Palmer; rsleevi at chromium.org; security-dev; blink-dev; steve.medin at gmail.com; net-dev
Subject: Re: Intent to Deprecate: SHA-1 certificates

On Thu, Aug 28, 2014 at 4:55 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Also, Chris -- who doesn't Google just deprecate SHA-1 certificates that expire on or after January 1, 2017 (now, or in six months) -- I can guarantee once that happens those certs will disappear, which is your stated goal -- and no new certs expiring in 2017 or later will ever be issued.

Why do you have to attack SHA-1 certs now that expire in 2016?  If you just focus on certs expiring in 2017 or later, you will save thousands of website owners from needless switching of their current SHA-1 certs (when then will never be receiving SHA-1 replacement certs that expire in 2017).

This makes no sense -- can you explain why Google's SHA-1 early deprecation isn't limited to SHA-1 certs that expire in 2017 or later???  That would catch everything, and prevent issuance of new 2017 certs.

Because as you well know from Microsoft's policy, the date for cessation of issuance isn't 2017, it's 2016. Mozilla's policy is clearer and even more to the point "CAs should not be issuing new SHA-1 certificates", without a date attached, and also notes "If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before 2017", which is more than the Microsoft policy requires (and is in line with our proposed UI changes and what we proposed to the CA/Browser Forum 6 months ago, to much reaction and rejection)

Again, going back to the earlier point, the site operator who obtained their 5 year certificate from TrendMicro in 2011 (or your CA of choice, since in either case, it's permissible and widely practiced, whether or not TrendMicro practices it), which expires in July 2016, needs to be aware that they, too, are affected by SHA-1 deprecation, as they will be unable to get a SHA-1 certificate when it comes time to renew their certificate.

They need to actively be communicating with their CA and working on SHA-256 transition plans, much the same as those with certificates expiring after 2017 (who will outright fail).

It would be truly unfortunate for a TrendMicro customer, possessing a certificate expiring during that busy Christmas shopping period of November-to-December 2016, with a wide variety of internal legacy systems, to find that they cannot get a certificate that will work in their infrastructure, because they failed to begin transitioning their infrastructure. Even if UAs support SHA-256, we both know (as do many of the CAs, as evidenced by things like Symantec's acknowledge BR violation) that legacy systems represent a real issue for CA's customers, beyond just user agents, and so we hope through our combined efforts, we will see the Internet as a whole transition to a more secure environment.

I can't see how delaying the messaging, which, as noted, affects Chrome users far beyond just CAs, and which affects CAs' customers far beyond just Chrome, would serve either of our respective goals.


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140829/d73164fb/attachment-0001.html 

More information about the Public mailing list