[cabfpub] SHA-1 exception request

[Dean Coclin]

Additional commentary from First Data about the December cutoff date:

•	Dec. 31st falls on the first weekend after Christmas this year which is the peak time for gift returns and exchanges.  
•	Gift card redemptions are also at their peak this weekend
•	New Year’s Day is a national holiday and is an extended 3-day weekend
•	New Year’s Day is also a critical day for sports entertainment in the U.S. driving increased retail, grocery and restaurant traffic.
•	Though we appreciate the extension, the end of the calendar year is one of the busiest retail seasons of the year 
•	First Data is not the only Payments processor to request an extension and would want to ensure our clients are afforded similar time to remediate as the clients of other processors who have been granted extensions.
•	Given the size and scale of our client base we feel additional time is warranted


-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin via Public
Sent: Thursday, October 13, 2016 4:58 PM
To: Gervase Markham <gerv at mozilla.org>; CABFPub <public at cabforum.org>
Cc: Halliday, Morgan <Morgan.Halliday at firstdata.com>; Sidoriak, Evan S <Evan.Sidoriak at firstdata.com>
Subject: Re: [cabfpub] SHA-1 exception request

Gerv,

Thank you for the prompt response to First Data's application. While we appreciate the approval and await responses from other browsers, I'd like to point out that this deadline doesn't really help First Data and the merchants much.

As discussed during the TSYS exception in July, the timing for merchant holiday payment processing and returns extends into January. This is why the TSYS application was granted a February 10, 2017 expiration date. Andrew Ayer had commented on TSYS' application at the time:

[TSYS via Dean] "One thing you will notice is the validity date extends to Feb 10, 2017. In the payment industry, 31 December is an absolutely horrible time to make a change as it represents one of the peak times for traffic."

[Andrew] Although the "Post Jan 2016 SHA-1 Issuance Request Procedure" version
1.1 mandates an expiration of December 31, 2016 or earlier, I think a later expiration is fine.  The risk to the public from SHA-1 manifests during issuance and a later expiration date does not affect this risk.
In fact, it would be better for TSYS to have some extra time than it would be to invoke this procedure again.

First Data requested an expiration in March and while I understand Mozilla's reluctance to approve a date that late, I was hoping they would at least receive equal treatment as TSYS with a February 9th expiration. I've asked First Data to provide a list of the reasons why a December cutoff for the payment industry is "absolutely horrible" and should have that shortly.

Also, First Data is much larger than TSYS and the affected community is 5 times the size.

Thanks again for your consideration,

Dean


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Thursday, October 13, 2016 3:38 PM
To: Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org>
Cc: Halliday, Morgan <Morgan.Halliday at firstdata.com>; Sidoriak, Evan S <Evan.Sidoriak at firstdata.com>
Subject: Re: [cabfpub] SHA-1 exception request

On 29/09/16 19:52, Dean Coclin wrote:
> In accordance with the SHA-1 Exception Request procedure, we hereby 
> submit the attached request on behalf of our client.

After consideration, Mozilla grants an exception for the issuance of
SHA-1 certificates, with the condition that they expire not after December 31st 2016, in line with the policy Google drafted.

We accept there is a case to be made that duration does not directly affect risk of issuance, but it affects risk of ongoing use, and it affects the issue of moral hazard and fairness to other companies.

Mozilla's public purpose is to make the Internet a better place for everyone, and that includes citizens whose credit card data passes across it. We are saddened that various payment card industry standards do not seem to put as high a value on the security of users' data as the Internet community does.

Thanks to First Data for their honest answers to the questions put.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161013/4a4a9ccc/attachment-0001.p7s>