[cabfpub] Posted on behalf of customer

Tue Dec 13 15:59:41 MST 2016

As I said below, much like you did with Rich’s post, I’m just posting this on behalf of FD. I’m sure they will have a response for you. But here’s what I think:

The items brought up in Gerv’s prior thread that you highlight below were all addressed at one time or another. For example:

https://cabforum.org/pipermail/public/2016-October/008492.html

https://cabforum.org/pipermail/public/2016-October/008510.html 

https://cabforum.org/pipermail/public/2016-October/008545.html

https://cabforum.org/pipermail/public/2016-October/008553.html

The “new” information appears to be a question of “fairness” in the way the forum has treated two independent companies in their exception requests. 

Dean

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, December 13, 2016 4:43 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Dean Coclin <Dean_Coclin at symantec.com>; Halliday, Morgan <Morgan.Halliday at firstdata.com>
Subject: Re: [cabfpub] Posted on behalf of customer

Dean,

I appreciate you sharing this request. While Rich expresses quite a bit of disagreement, it does seem to ignore the many efforts the Forum has taken, both as individual members and collectively, to provide steps for recourse.

It does not feel that this request shares any new information from the original request, but if I have misunderstood, it would be useful to understand what has changed. During the previous discussions, it was pointed out a number of fundamental issues here - highlighted by Gerv in this thread - https://cabforum.org/pipermail/public/2016-September/008484.html

Do you believe there's any new information that disagrees with that summary and conclusion?

On Tue, Dec 13, 2016 at 1:40 PM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Rich Salz (rsalz at akamai.com <mailto:rsalz at akamai.com> ) requested I post this. Please note these are Rich's opinions, and while we disagree with quite a bit, at least bears sharing.

-----post begins-----

I understand the desire to remove SHA-1 before it has actually shown true weakness.

I don’t see any concern with allowing special-case issuance, particularly for embedded devices, as long as the notAfter period doesn’t exceed the current policy.  I see no additional cryptographic risk from a 39 month cert that’s been in use for a year, and a 27 month cert that is just being issued.  I’ve been in discussions with various folks who know far more than I do, and nobody has posited any real issue with this, except perhaps that there will be a “rush” to issue SHA1 certs that all expire at the same time, and that this will be a problem for the ecosystem.  I call BS on that.  The webPKI has already shown that it can absorb 90-day certs on the order of millions over months.

If the consortium is not as sanguine as I am, then there are various controls it can exert. For example, it can issue a finite number of tokens (even as low as one) per SHA1 request.  It can mandate that a forum-provided extension (such as the SHA1 hash of an LE cert for the same domain) be included as random data to prevent attacks.

Y’all should do what you need to do, to allow the SYMC/FirstData request.  Not doing so looks like, to me an outsider, as petulance and bullying for no justifiable reason than “because we said so.”

On Mon, Dec 12, 2016 at 9:40 PM, Dean Coclin via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

I have been asked to post this request to the CA/B Forum, and specifically the browsers, to expedite visibility on behalf of a customer. Responses should be addressed to the author, cc’d on this note:

First Data is returning to the CA/B Forum to again request an extension of our SHA-1 certificates.  Over the last year and a half First Data has been working diligently with our Partners and Clients to convert more than a million and a half Clients to be able to use SHA-256 certificates.  Our business has coordinated with its many Bank Partners, Joint Ventures, Software Vendors, Independent Sales Organizations and Direct Merchants and we have made incredible progress. This has been accomplished by intense email and print mail efforts, outbound calling campaigns, software certifications, proactive delivery of new terminals at no cost to the Clients and a series of upgrades to servers that have in some cases have forced Clients to upgrade.  First Data has utilized some of the Forum’s suggestions such as the pulled root solution to alleviate impact and for Clients that this option works, we are limiting the length of time that this will apply.  With all of these efforts we have narrowed down the list of impacted Clients and are making continued best efforts to concentrate on those most impacted.

Despite these efforts, we are very concerned about the impact of the December 31 expiration. We believe that approximately 10% of the merchants utilizing these platforms would not be able to process once our certificates expire. The December 31 expiration offers little opportunity for us to make sure that they have upgraded. These next few weeks, Merchants in our industry are in the busiest and most intense period of the year with the Holiday season at its peak between now and December 31st.  Software vendors and Bank Partners not to mention First Data itself is in a period of a system’s freeze that extends into mid-January and for some software changes are locked down and cannot be made.  With the current expiration of December 31, 2016 there will be significant impact to both Merchants and consumers alike as they will be unable to purchase goods and services and make returns from prior purchases not to mention this will have an impact on New Year’s Eve and New Year’s Day activities.  

We believe that the disparate approach to First Data’s requested extension compared to the extension through February 9, 2017 that was granted to a competitor was inappropriate. There was no technical basis for the distinction. Nonetheless, by granting us a shorter extension the CA/B Forum is essentially prohibiting those merchants that for whatever reason cannot readily update to software that can accommodate a SHA-256 certificate from using the services of First Data or the many banks and other processors that are clients of First Data, while permitting those merchants to utilize the services of our competitors.  

By granting First Data less time than it has our competitors, the CA/B Forum is singling us out, granting to our competitors a critical advantage that it has denied to First Data. While we (and the Banks and others that utilize our platforms) have been reaching out to advise those Merchants that rely on our services as aggressively as we can for some time, the expiration of the certificates during the peak sales season puts us at a distinct disadvantage and harms our Merchants. The impact will primarily be on small, ”mom-and-pop” Merchants that are both technically not sophisticated and which can least afford a disruption to the sales that they rely upon. These Merchants are much less likely to be responsive to our continued letters and calls that we make to them during the peak season as they are focusing on making the sales that they need to carry them through the year. 

Our request is to obtain an extension through February 9, 2017 that will allow us to complete the conversion with as little disruption to these businesses, consumers and commerce in general as possible.  There are processors who are using SHA-1 certificates through May 2017. Singling out First Data for a December 31 expiration  seem unreasonable given the incredible progress we have made to date and the progress we feel can be made after this busiest time of year, we feel it not only fair but prudent.  We welcome the CA/B Forum’s response.

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161213/29136afb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20161213/29136afb/attachment-0001.bin>