[cabfpub] CAB Forum Policy Change request

Thu Sep 3 18:02:52 UTC 2015

Slightly higher.
There’s sadly no demonstrated collision on SHA1 yet, and since all public CAs are good actors and add some entropy in the beginning of the certificate as indicated by the BR (isn’t it right?), a random prefix collision on SHA1 is further away.

I’m not saying I support this proposal.

Cordialement,
Erwann Abalea

> Le 3 sept. 2015 à 14:06, Bruce Morton <bruce.morton at entrust.com> a écrit :
> 
> Kirk,
>  
> I think the risk is higher. A hash collision attack happens at the time of certificate issuance. The proposal would add an additional year for a collision attack to take place.
>  
> Bruce.
>  
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
> Sent: Thursday, September 3, 2015 1:48 AM
> To: CABFPub (public at cabforum.org) <public at cabforum.org>
> Subject: [cabfpub] CAB Forum Policy Change request
>  
> Reposting to public list. 
>  
> We support the proposal, as it doesn’t appear to have a different result than current policy under the Baseline Requirements – SHA-1 certs can continue so long as they expire on or before Jan. 1, 2017.  What difference does it make whether the cert was issued before or after Jan. 1, 2016 – the security risk is the same.
>  
> From: Kirk Hall (RD-US) 
> Sent: Wednesday, September 02, 2015 1:54 PM
> To: 'Rick Andrews'; management at cabforum.org <mailto:management at cabforum.org>
> Cc: Mark Kelly; Shannon Ortiz
> Subject: RE: [cabfquest] CAB Forum Policy Change request
>  
> While we have not received such customer requests, Trend Micro would support this to handle legacy customer issues.  The certs could (would) be deprecated in the browsers as they choose, but if the customer is willing to deal with that and knows of potential risks, we don’t see a big difference between a SHA-1 cert issued on 12/31/2015 and expiring on 1/1/2017 versus a SHA-1 cert issued on Jan. 1, 2016 (or March 1, or July 1) and expiring on 1/1/2017.  Seems like the level of risk is about the same for all these cases.
>  
> From: management-bounces at cabforum.org <mailto:management-bounces at cabforum.org> [mailto:management-bounces at cabforum.org <mailto:management-bounces at cabforum.org>]On Behalf Of Rick Andrews
> Sent: Wednesday, September 02, 2015 1:47 PM
> To: management at cabforum.org <mailto:management at cabforum.org>
> Cc: Mark Kelly; Shannon Ortiz
> Subject: Re: [cabfman] [cabfquest] CAB Forum Policy Change request
>  
> Removing AT&T for the moment, and posting to the Management list instead of the Questions list.
>  
> I believe that to meet AT&T’s needs, we’d simply need to remove this sentence from the BRs: “Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm.” We would still be left with “CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA‐1 algorithm with an Expiry Date greater than 1 January 2017.” We could even change the SHOULD NOT in that sentence to MUST. 
>  
> It’s essentially the same as a proposal that I made to Tom Albertson of Microsoft a while ago when he first started discussing SHA-1 deprecation. I said that in the past, we’d had customers complain strongly about arbitrary deadlines that are difficult for them to meet, especially when those deadlines are at the end of December, a time when many companies freeze their infrastructures. Giving CAs and customers the ability to get progressively shorter certs until the final 2017 deadline helps customers a lot. Tom’s opposition was that it allows for more SHA-1 certs to be created, but I would argue that it’s a compromise that would go a long way to achieving the ultimate goal with much less business disruption.
>  
> Symantec would like to be able to help customers such as AT&T without violating the BRs and receiving a qualified audit next year.
>  
> -Rick
>  
>  
> On Aug 31, 2015, at 4:26 PM, WILEMON, ANDREA A <aw8139 at att.com <mailto:aw8139 at att.com>> wrote:
>  
> CAB Browser Forum,
>  
> This message is from the AT&T Services, Inc., Chief Security Office, Data Protection Team.  
>  
> ISSUE
> We are writing about the SHA-1 depreciation policy that all trusted Internet Certification Authorities must comply.  Our specific concern is the December 31, 2015 deadline for obtaining SHA-1 server certificates.  This timeframe does not allow flexibility for our applications running SHA-1 certificates now with migration plans for the SHA-256 upgrade in 2016. 
>  
>  
> BACKGROUND
> We understand all CA issued SHA-1 certificates must expire by 12/31/2016 to comply with the Microsoft Windows Root Certificate Program technical requirements disabling Windows SHA-1 support in 2017.  
>  
> Please note at: http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx <https://urldefense.proofpoint.com/v2/url?u=http-3A__social.technet.microsoft.com_wiki_contents_articles_31633.microsoft-2Dtrusted-2Droot-2Dprogram-2Drequirements.aspx&d=BQMFAg&c=eEvniauFctOgLOKGJOplqw&r=bPeNvovSv0L4jj3hFD6Tw5sI3rGGNujxDceaEaUPuUQ&m=ZAkCyRUyNPWbkd0s3fkfjeZO8EmFbGVXhmSu5qjGlhc&s=c3bbI7UNyV1nTqGsbjW4HHr-KlCS37HhfXpIPnpZHSo&e=> 
>  
> Symantec, our Certification Authority (CA) vendor, confirmed in 2014 that we would retain the option to issue SHA-1 certificates in 2016 with expiration no later than 12/31/2016, for:
>  
> 1)      Our applications that can’t upgrade in 2015 and need new or renewal SHA-1 certificates for part of 2016. 
>  
> 2)      Continued support of legacy applications scheduled to retire in 2016 which need SHA-1 certificate renewal. 
>  
> We successfully migrated to 2048-bit encryption keys using this method during the last PKI industry standard change and were assured the same option would be available for the SHA-256 migration in 2016.
>  
>  
> NEGATIVE BUSINESS IMPACTS
> Symantec recommended issuing all SHA-1 certificates that expire in 2016 by the end of 2015.  This interim solution is not feasible to implement for multiple reasons: 
>  
> 1) Symantec’s proposal involves changing thousands of SHA-1 certificates that will translate to a high volume of unplanned operations and workload churn.  Specifically, the operational complexities of tracking server key store changes followed by the secondary labor intensive task to manually revoke each decommissioned certificate.  PKI security isn’t strengthened by limiting SHA-1 certificate issuance in 2016.  We increase risk for private key compromise by leaving decommissioned but valid key pairs scattered across many servers pending revokes. 
>  
> 2) AT&T freezes non-emergency changes from mid-November through mid-January for zero customer service disruptions during the holidays.  Technically we have less than three months to migrate the remaining SHA-1 certificates which equates to thousands of certificates.  Three months does not provide sufficient time to deploy Symantec’s solution.
>  
> 3) Some applications can’t upgrade to SHA-256 until early to mid-2016 when vendor supported software is available. 
>  
> 4) Many applications committed to firm 2016 deployment plans and resource allocations for this change and can’t migrate before 12/31/2015 due to current ongoing commitments.
>  
>  
> RESOLUTION
>  
> We request a policy change allowing Symantec to continue issuing less-than-one-year SHA-1 certificates after 12/31/2015 under their public trusted PKI hierarchy to support our remaining applications scheduled for SHA-256 adoption or retirement in 2016.  
>  
> We must retain the option to issue SHA-1 certificates in 2016, with expiration no later than December 31, 2016, for enrollments, renewals and replacements to support uninterrupted production services.  
>  
> In closing, we agree with the CA Browser Forum’s intent but do not agree with the execution of this high business impact policy change that will involve many software providers, hardware vendors and businesses.
>  
> Andrea
>  
> Andrea A. Wilemon, CISSP
> Principle-Technology Security
>  
> Rethink Possible® 
>  
> Chief Security Office, Mobility, Cloud & Enterprise Security
> AT&T Services, Inc.
>  
> P: 248-424-4115
> aw8139 at att.com <mailto:aw8139 at att.com>
>  
> Send #X before you drive to pause the
> conversation until you arrive. 
> Take the pledge... It Can Wait.
>  
> This e-mail and any files transmitted with it are the property of AT&T, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 248-424-4115 and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited."
>  
>  
>  
> _______________________________________________
> Questions mailing list
> Questions at cabforum.org <mailto:Questions at cabforum.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_questions&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=bPeNvovSv0L4jj3hFD6Tw5sI3rGGNujxDceaEaUPuUQ&m=ZAkCyRUyNPWbkd0s3fkfjeZO8EmFbGVXhmSu5qjGlhc&s=rH3ItIyTa4kLx-3C_jU6P1OrzSZVef-pwDY4yrOZdM4&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__cabforum.org_mailman_listinfo_questions&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=bPeNvovSv0L4jj3hFD6Tw5sI3rGGNujxDceaEaUPuUQ&m=ZAkCyRUyNPWbkd0s3fkfjeZO8EmFbGVXhmSu5qjGlhc&s=rH3ItIyTa4kLx-3C_jU6P1OrzSZVef-pwDY4yrOZdM4&e=>
>  
>  
> TREND MICRO EMAIL NOTICE
> 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.
>  
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150903/d9e34aed/attachment-0003.html>