[cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline

Fri Nov 6 18:52:27 UTC 2015

Jody,

I sent an email on this topic on October 28th with a similar recommendation.  We agree with Wayne’s assessment and request for information below.

Doug

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer
Sent: Friday, November 6, 2015 12:31 PM
To: Bruce Morton <bruce.morton at entrust.com>; Jody Cloutier <jodycl at microsoft.com>; public at cabforum.org
Cc: Magnus Nyström <mnystrom at microsoft.com>; Nazmus Sakib <mdsakib at microsoft.com>
Subject: Re: [cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline

Bruce’s comments on the risk of new issuance versus continued reliance on existing SHA-1 certs makes sense to me. Can someone from Microsoft (or Mozilla given that they are considering a similar policy change) respond to this question in the context of accelerating the deadline to stop trusting existing SHA-1 certificates?

Pulling the TLS deadline in by 7 months significantly increases the number of out-of-band replacements required because we have continued allowing the issuance of SHA-1 certs that expire prior to 2017 for the past 2 year since the original SHA-1 policy was announced. It also creates confusion since the 2017 deadline has been widely publicized. I’d like to gain a better understanding of the specific risk being mitigated by distrusting existing certificates sooner since it will cause significant pain for CAs and our customers if implemented.

Thanks,

Wayne

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Bruce Morton
Sent: Friday, October 30, 2015 8:12 AM
To: Jody Cloutier <jodycl at microsoft.com>; public at cabforum.org
Cc: Magnus Nyström <mnystrom at microsoft.com>; Nazmus Sakib <mdsakib at microsoft.com>
Subject: Re: [cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline

Jody,

The Baseline Requirements state “Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm.” This appears to be more restrictive than your proposal below and will mitigate collision attacks in about 2 months from now.

I do not understand what the issue with SHA-1 signed certificates which are already issued. They would no longer be subject to a collision attack and there appears to be no risk of a preimage/second-preimage attack during their validity period. I do not think the latest SHA-1 news has changed this understanding. I think your policy respects the issue with preimage for other certificates and see no reason why it shouldn’t be extended to SSL/TLS certificates. Nevertheless, we do understand that Windows will deprecate SHA-1 starting 1 January 2017 and this information has been provided to most Subscribers.

Thanks, Bruce.

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>  [mailto:public-bounces at cabforum.org] On Behalf Of Jody Cloutier
Sent: Wednesday, October 28, 2015 4:20 PM
To: public at cabforum.org <mailto:public at cabforum.org> 
Cc: Magnus Nyström <mnystrom at microsoft.com <mailto:mnystrom at microsoft.com> >; Nazmus Sakib <mdsakib at microsoft.com <mailto:mdsakib at microsoft.com> >
Subject: [cabfpub] Microsoft Proposed Updates to the SHA-1 Deprecation Timeline
Importance: High

In light of the recent news about potential SHA-1 vulnerabilities, Microsoft is considering changes to its SHA-1 deprecation policy, and we would like industry feedback on the ramification. 

Generally, Microsoft proposes that it will move in the previously-announced January 1, 2017 date at which Windows products would no longer trust SHA-1 certificates issued by roots in the Trusted Root Program and signed with the Mark of the Web. This proposal would change that date to June 1, 2016.

The summary of changes are as follows:

1.     CAs should move to issuing SHA-2 for signing OCSP responses for SHA-2 SSL certificates. Windows will no longer trust OCSP responses that use SHA-1 for their signature if the corresponding certificate had the Must Staple extension after January 1, 2016. Windows will no longer trust OCSP responses that use SHA-1 for any SSL certificates after June 1, 2016.

2.     Windows will no longer trust files with the Mark of the Web attribute that are timestamped with a SHA-1 signature hash after 6/1/2016 on Windows 10 systems.

3.     CAs may not issue SHA-1 certificates after December 31, 2016 (this is more restrictive than the current CAB Forum guidelines)

Certificate Type 

Windows Behavior 

Microsoft Policy 

TLS certificates 

Certificates signed with SHA-1 will be Blocked after 1/1/2017

[Update] Certificates signed with SHA-1 will be Blocked after 6/1/2016 

CAs must move all new certs to 

SHA-2 after 1/1/2016 

[Update] CAs must move all new certs to SHA-2 immediately

Code signing certificates 

On Win 7 and above, blocked on 1/1/2020 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files.  

[Update] On Win 7 and above, blocked on 1/1/2017 if time stamped before 1/1/2016, otherwise, blocked after 1/1/2016 for Mark of the Web files.

SmartScreen data may be used to allow certificates with good reputation  

CAs should issue new code signing certs with SHA-1 after 1/1/2016 only for developers 

targeting 

Vista/2008, otherwise, move all new certs to SHA2 

S/MIME certificates 

No OS specific policies. Application policies. 

CAs are recommended to move to SHA-2 

Time-stamping certificates 

No changes until SHA-1 preimage is possible 

CAs must issue new TS certs with SHA-1 after 1/1/2016 only for developers targeting 

Vista/2008, otherwise, move all new certs to SHA2 

OCSP signing and CRL signing certificates 

No changes until SHA-1 preimage is possible 

No changes until SHA-1 preimage is possible 

OCSP signatures 

On Windows 10 and above for certificates with the Must Staple extension, SHA-1 signatures will not be accepted after 1/1/2016

On Windows 10 and above, SHA-1 signatures will not be accepted for any SSL certificate after 1/1/2017 

[Update] Windows will no longer trust OCSP responses that use SHA-1 for their signature if the corresponding certificate had the Must Staple extension after January 1, 2016. Windows will no longer trust OCSP responses that use SHA-1 for any SSL certificates after June 1, 2016.

CAs should move to using SHA-2 starting 1/1/2016 for SHA-2 SSL certificates.

CAs should prepare to move to SHA-2 for all SSL certificates by 1/1/2017 

[Update] CAs should move to issuing SHA-2 for signing OCSP responses for SHA-2 SSL certificates.

CRL signatures 

No changes until SHA-1 preimage is possible 

No changes until SHA-1 preimage is possible 

Code signing signatures 

No changes until SHA-1 preimage is possible 

No changes until SHA-1 preimage is possible 

Time-stamp signatures 

On Win 10 and above, blocked on 1/1/2017 for Mark of the Web files. 

[Update] On Win 10 and above, blocked on 6/1/2016 for Mark of the Web files. 

CAs should move to using SHA-2 starting 1/1/2016 

Microsoft is asking for feedback from Forum members on the implications to the industry should we move forward with these changes. Please provide comments before Monday, November 2, 2015 by replying to this mail.

Thank you,

Jody Cloutier

Senior Security Program Manager

 <http://aka.ms/rootcert> Microsoft Trusted Root Certificate Program

 <sip:jodycl at microsoft.com>  <tel:+1%20(425)%20705-7566>  <mailto:jodycl at microsoft.com> 

 <http://microsoft.com/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3208 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3340 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3315 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1181 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4289 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151106/21af0509/attachment-0001.p7s>