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:g...@mozilla.org] 
Sent: Wednesday, October 12, 2016 12:00 PM
To: Dean Coclin <dean_coc...@symantec.com>; CABFPub <public@cabforum.org>
Cc: Halliday, Morgan <morgan.halli...@firstdata.com>; Sidoriak, Evan S 
<evan.sidor...@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to