On 24/02/16 22:53, Dean Coclin wrote:
Peter,
The same one they've been using and know works: VeriSign Class 3
International Server CA - G3.
Dean, are you sure about that?
I just ran "openssl s_client" on each of the 7 names that Richard Barnes
mentioned.
I couldn't reach 3 of them (tptrans-l.lynksystems.com,
tframe1.rbslynk.com and tframe2.rbslynk.com).
qac.tf.rbslynk.com is currently using a cert issued by "VeriSign Class 3
International Server CA - G3".
However, the other 3 (tptrans.lynksystems.com, tpdev.lynksystems.com and
tf.lynk-systems.com) are currently using certs issued by "Symantec
Private SSL SHA1 CA". "VeriSign Class 3 International Server CA - G3"
doesn't feature anywhere in the chain.
Dean
On 02/24/16, Peter Bowen<pzbo...@gmail.com> wrote:
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" <dean.j.coc...@verizon.net
<mailto:dean.j.coc...@verizon.net>> 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<g...@mozilla.org
<mailto:g...@mozilla.org>> 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
> dev-security-policy@lists.mozilla.org
<mailto: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
<mailto: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
<mailto: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
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
