Peter,
The same one they've been using and know works: VeriSign Class 3 International Server CA - G3.
Dean
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
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
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
