[cabfpub] CAB Forum Policy Change request
sleevi at google.com
Wed Sep 2 22:33:09 UTC 2015
On Wed, Sep 2, 2015 at 3:06 PM, Rick Andrews <Rick_Andrews at symantec.com>
> Reposting to the Public list, with permission by the author.
Thanks Rick. I realize we've set time on our next agenda to discuss this,
so I'm sure we'll get to more substantial concerns on the next call.
> CAB Browser Forum,
> This message is from the AT&T Services, Inc., Chief Security Office, Data
> Protection Team.
> We are writing about the SHA-1 deprecation 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.
With regards to providing flexibility, this timeline was first
(formally/publicly) announced on November 12, 2013, with Microsoft's policy
update. Despite there being discussions of deprecation well before then, if
we take that time as the first signal for CAs to begin deprecating, that
left two years for organizations to begin planning and executing their
migration. We're now three months from that date, and, as was discussed
extensively during the CA/B Forum discussions of Ballot 118, we're now
hearing suggestions that the sunset period be extended.
There was extensive debate, from a variety of CAs and Browsers, as to the
appropriate dates. It's not surprising that several of the replies made (to
you or from the management list) effectively reflect the same positions
held and espoused during the extensive discussions around Ballot 118, which
took nearly a year after MSFT's announcement to be formally codified and
agreed. Considering that we are now three months from the deadline, it does
not appear that there is new information being presented here - these were
concerns very much taken into consideration during the previous discussions.
> 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.
I'm sorry to hear, but that advice was inconsistent with the Baseline
Requirements as of Ballot 118. While I'm certain it was inconsistent with
Microsoft's published policies, there exists the possibility that Symantec
reached some agreement with Microsoft for such an extension. However, it
did not do so with other vendors who indicated support for and expectations
of the same adherence, so it's unlikely that such a statement could have
been given at the time.
> 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.
No, but two years (Nov 12, 2013) seems like it would, and based on the
proposed extension, it seems like one year (Ballot 118 passed 16 October
2014) would also have been sufficient.
> 3) Some applications can’t upgrade to SHA-256 until early to mid-2016 when
> vendor supported software is available.
This was extensively discussed as a concern, especially following the awful
experience browsers had with deprecating MD-5 support. The dates chosen
factored these concerns in.
> 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.
This is why we began discussing it with a timeline aimed at nearly 5 years
later. Unfortunately, the Internet moves at a far faster pace, and
continues to accelerate. We saw that many software providers, hardware
vendors, and businesses were either incapable or unwilling to act regarding
MD5, which lasted half a decade after attacks were *known* and *practical*,
and we saw the same concerns - and from a number of CAs - regarding SHA-1
While understanding of your plight, I do find it somewhat difficult to be
sympathetic, given the efforts made to conduct this transition in an
orderly fashion, and the ongoing efforts to publicize and draw the
attention of software providers, hardware vendors, and businesses to this
issue. It is equally, if not moreso, unfortunate that, according to you,
you were provided with misleading information by your CA as to how the
As it stands, the Chrome team is opposed to any ballots to relax or extend
the sunset, as our experience with MD5 has taught us that CAs and vendors
alike will take advantage of such time to introduce greater issues and pain
upon users. If a CA decides to issue such certificates, we would expect a
qualified finding on the audit report, and expect those certificates to be
revoked. While Chrome itself will reject these certificates, we do not
believe that in and of itself provides sufficient mitigation for
ecosystem-wide issues, and thus remain opposed to any extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public