[cabfpub] SHA-1 exception request
Dean Coclin
Dean_Coclin at symantec.com
Wed Oct 12 08:50:15 MST 2016
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:gerv at mozilla.org]
Sent: Monday, October 10, 2016 12:02 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 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
-------------- 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/20161012/e5fa753b/attachment-0001.bin>
More information about the Public
mailing list