Answers submitted on behalf of First Data below. We've kept them in the thread 
with the prior questions:

On 08/10/16 13:44, Dean Coclin wrote:
> “First Data has successfully updated all other internal systems, 
> websites, networks and POS devices to SHA-256.  Where FD has control 
> we are compliant.” However, the majority of POS devices are created, 
> sold, deployed and maintained by third parties. Merchants are free to 
> obtain POS devices from these providers and use them with FD's 
> infrastructure.

But those POS devices won't work with FD's infrastructure unless they contain 
the roots which anchor the certificates that FD uses. Given that, does FD have 
a policy for which roots, algorithms etc. need to be supported by terminals in 
order to guarantee continued operation?

I assume you don't agree to take the burden of supporting any old device, 
however old or buggy or badly designed.

[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.  

Where First Data manages/maintains POS devices and merchant relationships we do 
have a formal product life-cycle, where non-compliant legacy products are 
deprecated. 

The reason for this exception is that we do not control all of the devices that 
use the First Data processing network.  

> Regarding the Root removal policy:  Many of the POS devices created by 
> other parties are simply applications running on standard Windows or 
> Linux distributions.  Those devices contain the same root stores that 
> browsers trust.  Many of them are Java applications, which by default 
> use the Java trust store that contains many of the same roots trusted 
> by browsers.

Well, those don't sound too hard to update. I was assuming we were talking 
about embedded devices with limited crypto processors. Dean often uses the 
example of the embedded device taken out of the drawer once a year for the bake 
sale.

So can we assume that devices in the "Windows/Linux/Java app" category have not 
been updated either because the vendor has withheld the knowledge of the 
necessity of this from the merchant, or the merchant has ignored the warnings?

(I'm sure it can't be because the vendor has stopped supporting the software, 
because unsupported POS software which handles payments would be a massive 
security risk.)

[First Data] Those are probable explanations, however given the size of the 
population, complexity of eco-system and variety of engagement levels between 
POS vendors and merchants it would be incorrect to assume those are the only 
reasons.  

As stated in our previous response there are valid circumstances where a 
merchant may not know who currently supports their POS system. E.g.  changing 
banking relationships, inheriting POS systems when buying/selling a business, 
etc..  

We feel that our plan to upgrade our network repeatedly for short bursts 
combined with a final communications attempt will garner the necessary (if 
painful) attention to this matter and if granted an extension, provide time for 
remediation without the catastrophic cessation of business just before the 
holiday peak season. 


> [First Data] As stated previously, the ecosystem is very large and 
> complex. There are over 1,200 different POS applications/devices 
> running various versions of operating systems, patch levels, POS 
> software revisions etc.,  which use the First Data infrastructure.

And is it right that First Data takes no responsibility for the level of 
security of those clients (e.g. whether they are running updated and secure OS 
versions)? That's the responsibility of the merchant and the POS vendor?

Or do you have some requirements, e.g. PCI compliance?

[First Data] Yes there are PCI requirements that must be met. As pointed out by 
Peter Bowen, those requirements have not yet prohibited SHA-1 certificates. 

> Most of these are managed by third party providers, outside of First 
> Data control.
> 
> Given the complexity of device ownership it would be impossible to 
> survey all devices and the list of roots that they trust.

So what was your plan if the one root you know they all trusted (because it's 
the one you were using) got compromised and ceased issuing certificates?

[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.  

> If you are one end of a secure connection and you can't communicate 
> security-related information to the person controlling the other end, 
> even when given 12 months to do it, you are doing it wrong.
> 
> [First Data]  As explained, FD doesn't have a direct business 
> relationship with many of the merchants. The communication and 
> administration of POS devices are handled by the POS vendors who sold 
> the merchants their POS system.

So presumably when this system stops working, the merchant will go back to the 
POS vendor and say "Hey, you knew this was coming because First Data told you - 
why didn't you warn me?" And either they will reply "We did, and you ignored it 
- look here", or they will reply "Oops", at which point the merchant gets a new 
POS vendor.

[First Data] Agreed. If we are granted the extension we can accomplish the goal 
of raising awareness for all merchants through our short burst upgrade 
exercise.  

Undoubtedly merchants will be calling their POS vendors as a result.  First 
Data can at least keep them remain in service through holiday peak season while 
driving compliance. 

> The POS provider is required maintain PCI compliance of their device.

And PCI compliance doesn't yet require use of SHA-256? What is the exact status 
there, with deadlines?

[First Data] As pointed out by Peter Bowen, PCI has not yet prohibited SHA-1 
certificates. 

Our goal is to comply with the SHA-256 mandate as driven by the CAB/f. 


> [First Data]  Based upon demands from our Distribution Systems, we 
> will be starting this exercise on Tuesday October 18th.

9 days before your certificates expire?

To be honest, the trouble with your request is moral hazard. Various companies 
have put in massive amounts of effort to deal with this deadline - or, at 
least, had the foresight to stockpile certificates so they had until December 
31st. If we continue to grant extensions, we penalise those companies which 
have put in the effort and favour those who have not. Does First Data really 
have a more eclectic and complicated mix of clients, and a longer 
communications distance between you and the merchants, than other payment 
processors?

 

[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   


[First Data]  We have an obligation to our clients and partners to pursue every 
available avenue that will allow merchants to continue to process during the 
holiday peak season.  

We feel that our plan to upgrade our network repeatedly for short bursts 
combined with a final communications attempt will garner the necessary (if 
painful) attention to this matter and if granted an extension, provide ample 
time for remediation.  

Do any of the other root store operators have thoughts on this matter?



-----Original Message-----
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Monday, October 10, 2016 12:02 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 08/10/16 13:44, Dean Coclin wrote:
> “First Data has successfully updated all other internal systems, 
> websites, networks and POS devices to SHA-256.  Where FD has control 
> we are compliant.” However, the majority of POS devices are created, 
> sold, deployed and maintained by third parties. Merchants are free to 
> obtain POS devices from these providers and use them with FD's 
> infrastructure.

But those POS devices won't work with FD's infrastructure unless they contain 
the roots which anchor the certificates that FD uses. Given that, does FD have 
a policy for which roots, algorithms etc. need to be supported by terminals in 
order to guarantee continued operation?

I assume you don't agree to take the burden of supporting any old device, 
however old or buggy or badly designed.

> Regarding the Root removal policy:  Many of the POS devices created by 
> other parties are simply applications running on standard Windows or 
> Linux distributions.  Those devices contain the same root stores that 
> browsers trust.  Many of them are Java applications, which by default 
> use the Java trust store that contains many of the same roots trusted 
> by browsers.

Well, those don't sound too hard to update. I was assuming we were talking 
about embedded devices with limited crypto processors. Dean often uses the 
example of the embedded device taken out of the drawer once a year for the bake 
sale.

So can we assume that devices in the "Windows/Linux/Java app" category have not 
been updated either because the vendor has withheld the knowledge of the 
necessity of this from the merchant, or the merchant has ignored the warnings?

(I'm sure it can't be because the vendor has stopped supporting the software, 
because unsupported POS software which handles payments would be a massive 
security risk.)

> [First Data] As stated previously, the ecosystem is very large and 
> complex. There are over 1,200 different POS applications/devices 
> running various versions of operating systems, patch levels, POS 
> software revisions etc.,  which use the First Data infrastructure.

And is it right that First Data takes no responsibility for the level of 
security of those clients (e.g. whether they are running updated and secure OS 
versions)? That's the responsibility of the merchant and the POS vendor?

Or do you have some requirements, e.g. PCI compliance?

> Most of these are managed by third party providers, outside of First 
> Data control.
> 
> Given the complexity of device ownership it would be impossible to 
> survey all devices and the list of roots that they trust.

So what was your plan if the one root you know they all trusted (because it's 
the one you were using) got compromised and ceased issuing certificates?

> If you are one end of a secure connection and you can't communicate 
> security-related information to the person controlling the other end, 
> even when given 12 months to do it, you are doing it wrong.
> 
> [First Data]  As explained, FD doesn't have a direct business 
> relationship with many of the merchants. The communication and 
> administration of POS devices are handled by the POS vendors who sold 
> the merchants their POS system.

So presumably when this system stops working, the merchant will go back to the 
POS vendor and say "Hey, you knew this was coming because First Data told you - 
why didn't you warn me?" And either they will reply "We did, and you ignored it 
- look here", or they will reply "Oops", at which point the merchant gets a new 
POS vendor.

> The POS provider is required maintain PCI compliance of their device.

And PCI compliance doesn't yet require use of SHA-256? What is the exact status 
there, with deadlines?

> [First Data]  Based upon demands from our Distribution Systems, we 
> will be starting this exercise on Tuesday October 18th.

9 days before your certificates expire?

To be honest, the trouble with your request is moral hazard. Various companies 
have put in massive amounts of effort to deal with this deadline - or, at 
least, had the foresight to stockpile certificates so they had until December 
31st. If we continue to grant extensions, we penalise those companies which 
have put in the effort and favour those who have not. Does First Data really 
have a more eclectic and complicated mix of clients, and a longer 
communications distance between you and the merchants, than other payment 
processors?

Do any of the other root store operators have thoughts on this matter?

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