[cabfpub] SHA-1 exception request

Dean Coclin Dean_Coclin at symantec.com
Thu Oct 13 06:16:16 MST 2016


More responses below:

On 12/10/16 16:50, Dean Coclin wrote:
> [First Data]  Yes. First Data requires POS vendors to certify to our 
> API’s which detail the signature algorithms that are supported and 
> also detail which ROOT CA’s must be used.

Is this documentation available? Which root CA(s) are on the list?

[First Data]  Yes.  We send them directly to integrators. They are not published on a website.  At the point a device vendor certifies to our network we currently specify one Root which is the VeriSign G5. With the emergence of 2048bit certs, we established a policy of specifying a single Root. 

This is a material point as ~70% of our client base uses physical POS devices.  


> [First Data] We have multiple roots available to fall back to, however 
> each of them would require us to use this SHA-1 procedure because all 
> of the 300,000 devices require a SHA-1 end entity certificate.

And as it happens, none of them are in the set of roots that CAs have pulled from browser root stores so they can continue SHA-1 issuance?

[First Data]  Some devices may have a pulled Root, but again the exercise impacts every merchant, so we need a solution that works for everyone and allows time for clients to upgrade/replace devices.

Over the lifespan of our network there have been multiple single Root’s in service.   At this point we can’t get statistically significant coverage with any Root other than the G5. 

> As was pointed out in a previous application the risk is at issuance 
> and is not affected by validity period.

Nevertheless, the SHA-1 deprecation process, as outlined in the BRs, does not allow unlimited validity.

[First Data]  Understood and agreed.  We are requesting this extension to March 15th 2017 to prevent merchant impact during the holiday peak season and provide time for remediation.  

If granted, we will use the additional time to raise awareness by every possible means including directly affecting merchant processing to drive compliance.

Mozilla is considering our response internally; we hope to have an answer for you soon.

[First Data]  Thank you for your consideration. We appreciate the opportunity to advocate on behalf of our merchant community and hope we have provided adequate justification to decide in our favor.

> If the vulnerability does not carry severe risk, we would attempt to
> contact the merchant(s) and/or vendors and drive them to replace the POS 
> system.

And that's what you are doing in this case. Presumably either you rate the 
risk of using SHA-1 as low and therefore didn't pull out all the stops, or 
this process would take up to eighteen months even for a major security 
problem in a terminal type or technology. The latter is a very scary prospect; 
the former suggests First Data could have done more to avoid being in the 
situation you're in now, even without the benefit of hindsight.


> Where we own control we can proactively force updates to capable
> devices and/or communicate with our clients to obtain the necessary
> updates by the deadline.
>
>  Where we do not have control, we can notify the POS vendor and client
> of the compliance deadline and deactivate those who do not comply.

In order to do that, your systems must be able to tell the identity of the 
software running on the connecting device - the equivalent of a browser's User 
Agent string. If you couldn't, and were unable to map that information to a 
list of vulnerable devices, then you wouldn't know which devices to deactivate 
in this scenario.

This seems at odds with what you seem to be claiming, which is that you don't 
know much/anything about many of the devices connecting to your network. 
Either you can refuse transactions from known-insecure ones, or you can't.

[First Data]  We get a16 digit application ID with each transaction so we are able to identify the devices that connect to our network.  If a vulnerability is identified with a particular POS device we could deactivate them. 
We cannot correlate an Application ID to the list of available Roots in a specific POS device.  While we do get a user agent string it is not specific enough to act upon.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Wednesday, October 12, 2016 12:00 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 12/10/16 16:50, Dean Coclin wrote:
> [First Data]  Yes. First Data requires POS vendors to certify to our 
> API’s which detail the signature algorithms that are supported and 
> also detail which ROOT CA’s must be used.

Is this documentation available? Which root CA(s) are on the list?

> [First Data] We have multiple roots available to fall back to, however 
> each of them would require us to use this SHA-1 procedure because all 
> of the 300,000 devices require a SHA-1 end entity certificate.

And as it happens, none of them are in the set of roots that CAs have pulled from browser root stores so they can continue SHA-1 issuance?

> 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

Nevertheless, the SHA-1 deprecation process, as outlined in the BRs, does not allow unlimited validity.

Mozilla is considering our response internally; we hope to have an answer for you soon.

Gerv
-------------- 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/20161013/96eb586c/attachment.bin>


More information about the Public mailing list