Dean as Symantec, What CA(s) would Symantec use as the issuer for the certificates?
Thanks, Peter On Feb 24, 2016 12:52 PM, "Dean Coclin" <[email protected]> wrote: > 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 > > > On 02/24/16, Gervase Markham<[email protected]> wrote: > > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
