[cabfpub] SHA-1 exception request

Dean Coclin Dean_Coclin at symantec.com
Mon Oct 3 07:26:47 MST 2016


Gerv,
I am posting responses on behalf of First Data below. Symantec has also answered the 2 questions indicated:


* The answer to question 3 is not complete, in that it does not explain whether alternative measures such as issuing from a pulled root have been tried and if so, what the outcome was, and if not, why not.

FD Response: We tested a private root and determined that this would not work for all affected clients.
Modern POS systems would not have the pulled root and would need to manually add the private root. 
The level of effort involved would be similar to if not greater than just upgrading or replacing Non SHA-2 compliant devices. 

FD verified that POS devices do perform expiration checking and will fail if expired SHA-1 certificates are in use. 

Changing the clock on the POS devices will not work.  PCI compliance mandates that POS clocks are synchronized. 

Given the size and diversity of the POS device population there are no pulled roots that would remediate a significant portion of the 300,000 clients at risk. 

* It seems pretty amazing that, given that this company was not unaware of the relevant deadlines that they only bothered in August 2016 to check and see how effective their attempts at getting the ecosystem to upgrade were.

FD Response: FD initially communicated a June 30th deadline which would have provide a four month buffer before final expiry of existing certificates. 

Several large merchants and banks working on remediation plans through efforts such as contacting clients, upgrading POS software and/or deploying new compliant POS hardware requested that we extend the deadline to August 1st, which we did.   

We had to wait until our August deadline had passed to evaluate client readiness in order to avoid impacting clients who were in the process of becoming compliant. 

As stated in the response to question #8 “Additional steps in the future would be to conduct readiness tests much farther in advance.” We would definitely consider this a lesson learned and will be moving our internal deadlines up much further in the future. 

* This seems not to be a case of "we didn't know" or "we weren't told"
by First Data, but a case of "we were told but we didn't listen" by First Data's community of software vendors, VARs and gateway providers.
This makes me less sympathetic - either these companies have failed to communicate to their customers the importance of the impending deadline, or the customers have simply ignored the communications. And they have no-one to blame but themselves.

FD Response:  There are valid circumstances that would prevent communications from reaching the end user.  

Most of these clients are small merchants with limited IT industry knowledge.  Many of them have bought/sold their businesses, inheriting the POS device.  Some have changed banking relationships. Others don’t have an active relationship with their POS vendor, or for many other reasons, may not even know who administers their POS system.  

FD believes that these businesses, which by their nature are not technically sophisticated, should not be put to experience an extended business disruption that would result from the inability to extend SHA-1 certificates for the period requested.

Please also see the response to the last question below on efforts proposed to accelerate user compliance.


* Do the proposed certificates "correspond to an Existing Certificate..." as outlined in the section "Existing Certificate Information" in the procedure doc? If they do, can crt.sh links be provided for the existing certificates? If not, is that because matching certs existed but were not logged, or because other changes have been made? If the latter, can it be explained why the additional changes to the certificate contents are needed? In general, it seems that while the answers to the initial questions have been provided, the data requested by this section has not.

Symantec: Links to the crt.sh entries were provided at the top of each certificate's disclosure in the second email. Each of the candidate toBeSigned certificates match the logged certificates they replace with the exception of the serial number and validity period. Matching was preserved to the extent of using T61String encoding, SGC EKU, and BR compliance policy OIDs from our arc rather than the CABF's.

* The procedure doc says that validity of exceptional certificates may not extend beyond 31st December 2016. First Data is asking for 15th March 2017, which is impermissible as the doc stands. (The CAB Forum has regularly had discussions about how the end of a calendar year is a bad time for deadlines; however, in this case, the actual deadline was a year ago, so I don't think this complaint can be made in this case.)

Symantec:  Precedent exists to provide expiration dates after Jan 1, 2017.    

As was pointed out in a previous application the risk is at issuance and is not affected by validity period. See link:  https://cabforum.org/pipermail/public/2016-July/008007.html   

* Given that above, I wonder whether, if the only way to make the affected retailers pay attention is if their devices actually stop working, it's best for that to happen in October/November rather than on December 31st, in the middle of the Christmas period.


FD Response:  FD proposes an alternative that can highlight the need to address this issue without causing a sustained impact that would be more disruptive to merchant businesses.   

Beginning in the first week of October, FD is planning to conduct what we are calling “Short Burst” upgrades. We will regularly and continually upgrade to SHA-2 for short intervals on varying dates and times of day.  Non-compliant clients will be unable to process during these burst upgrade periods which should induce corrective measures.   




Thanks,
Dean

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, September 30, 2016 4:56 AM
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

Hi Dean,

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.

I've been considering this application, with reference to https://github.com/awhalley/docs-for-comment/blob/master/SHA1RequestProcedure.MD
, which I believe is the latest version.

* The answer to question 3 is not complete, in that it does not explain whether alternative measures such as issuing from a pulled root have been tried and if so, what the outcome was, and if not, why not.

* It seems pretty amazing that, given that this company was not unaware of the relevant deadlines, that they only bothered in August 2016 to check and see how effective their attempts at getting the ecosystem to upgrade were.

* This seems not to be a case of "we didn't know" or "we weren't told"
by First Data, but a case of "we were told but we didn't listen" by First Data's community of software vendors, VARs and gateway providers.
This makes me less sympathetic - either these companies have failed to communicate to their customers the importance of the impending deadline, or the customers have simply ignored the communications. And they have no-one to blame but themselves.

* Do the proposed certificates "correspond to an Existing Certificate..." as outlined in the section "Existing Certificate Information" in the procedure doc? If they do, can crt.sh links be provided for the existing certificates? If not, is that because matching certs existed but were not logged, or because other changes have been made? If the latter, can it be explained why the additional changes to the certificate contents are needed? In general, it seems that while the answers to the initial questions have been provided, the data requested by this section has not.

* The procedure doc says that validity of exceptional certificates may not extend beyond 31st December 2016. First Data is asking for 15th March 2017, which is impermissible as the doc stands. (The CAB Forum has regularly had discussions about how the end of a calendar year is a bad time for deadlines; however, in this case, the actual deadline was a year ago, so I don't think this complaint can be made in this case.)

* Given that above, I wonder whether, if the only way to make the affected retailers pay attention is if their devices actually stop working, it's best for that to happen in October/November rather than on December 31st, in the middle of the Christmas period.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20161003/d2f769b5/attachment-0001.bin 


More information about the Public mailing list