This is Dean from Symantec (same Dean as the CA/B Forum Chair but I'm leaving that hat off right now). I'd like to answer some questions about this situation on which I agree is less than ideal.
First off, as Gerv mentioned, many device manufacturers erroneously embedded public roots in their devices way before CA/B Forum Baseline Requirements were ever conceived. One can argue they didn't know any better. CAs didn't (and still don't) always know who has downloaded their public roots or copied them from browsers to use in their own devices. These devices go as far back as the 90s and are still in use in merchants as POS and ATMs. Many devices cannot have their root stores or their crypto code remotely upgraded. The payment processors don't always provide the devices to the merchants. Much like the way you can buy your own telephone and plug it into the public network, merchants can source devices from many places. Hence, the payment processors don't control the endpoints. The number of device manufacturers coupled with the myriad of various firmware revisions makes it difficult to give precise numbers.
This is apparently a widespread problem in this ecosystem and unfortunately Worldpay is first up, given the imminent expiration of their certificates. However, the problem is much larger than Worldpay. The FS-ISAC, which is an association of these processors, is scoping the entire problem space by surveying their members and I'm hoping to get the results to the browsers shortly. But let's focus on WP for now since time is short.
Some of the suggestions on this thread are very good. But given the tight time constraint and the fact that they would have to be tested, some can't be considered for this instance. For example:
1. Creating a new intermediate. This will have to be tested to see if the terminals will accept this.
2. What roots are trusted in the devices? Hard to say given the myriad of devices, firmware and changes over the years
3. Including >80 bit of entropy. Great idea and I believe that is already the case for these existing certificates, and will be the case for any new ones we sign.
4. Technically constraining the sub CA. Another great idea but would require testing first
5. Use an older hashing algorithm. Prohibited by PCI.
6. Use a smaller (1024) key size root. Interesting idea that might work but again would have to be tested
7. Use an older root that has been removed from the browsers. This has worked for at least 85% of the terminals. It's the last 10-15% that are affected.
In the end, everyone is right. This should have been brought to light some time ago. Symantec did notify these customers but unfortunately not all certificates were renewed in time. Perhaps they didn't understand the impact. While the processor in question didn't renew their SHA-1 certs before the deadline, that's neither here nor there. But as others have said, this is a serious issue with a short timeline to address.
Thank you
Dean Coclin
Symantec
Symantec
On 24/02/16 19:27, Jeremy Rowley wrote:
> I believe the concern is that Worldpay is asking for an exception by saying,
> "We've tried 'things' and they didn't work - can we please have a SHA1
> cert?" We don't know what these 'things' they've tried are or whether there
> is an alternative. Lots of customers have asked for SHA1 certs on the
> premises that they need them because of old devices. Is this one special?
> Perhaps, but the alternatives should first be considered.
I believe that large chunks of Worldpay got this right; one part of the
business "didn't get the memo" and missed the deadline for cert renewal
at the end of the year. Once they found out, a short time ago, they
tried the "non-BR root" method but that only covered 90% of devices due
to divergent root stores. (200,000 devices use these servers, so 20,000
would still be affected if they went that way - that's where the numbers
we have been using come from.)
> When creating OneCRL, Mozilla expressed concerns about the potential size of
> the CRL if end entity certs were included. Now, they are being asked to
> include 10,000 end-entity certs in OneCRL (which are not even revoked).
Sorry if this wasn't clear originally; they don't need one cert per
terminal, they need one cert per receiving server. The number of certs
concerned is nine (9).
Gerv
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
> I believe the concern is that Worldpay is asking for an exception by saying,
> "We've tried 'things' and they didn't work - can we please have a SHA1
> cert?" We don't know what these 'things' they've tried are or whether there
> is an alternative. Lots of customers have asked for SHA1 certs on the
> premises that they need them because of old devices. Is this one special?
> Perhaps, but the alternatives should first be considered.
I believe that large chunks of Worldpay got this right; one part of the
business "didn't get the memo" and missed the deadline for cert renewal
at the end of the year. Once they found out, a short time ago, they
tried the "non-BR root" method but that only covered 90% of devices due
to divergent root stores. (200,000 devices use these servers, so 20,000
would still be affected if they went that way - that's where the numbers
we have been using come from.)
> When creating OneCRL, Mozilla expressed concerns about the potential size of
> the CRL if end entity certs were included. Now, they are being asked to
> include 10,000 end-entity certs in OneCRL (which are not even revoked).
Sorry if this wasn't clear originally; they don't need one cert per
terminal, they need one cert per receiving server. The number of certs
concerned is nine (9).
Gerv
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
