If OneCRL always used the same hash algorithm as the certificate, then any colliding certificate would also be treated as revoked.
>Mozilla is very keen to see SHA-1 eliminated, but understands that for
>historical reasons poor decisions were made in private PKIs about which roots
>to trust, and such decisions are not easily remedied.
I'm curious about what's going on here, as you say this is a private PKI, so
why do they need certs from a public CA? Presumably Worldpay is doing this
for B2B comms, so why don't they issue their own certs, and they can keep
using SHA-1 for as long as required? It seems like Worldpay's mistake wasn't
failing to update SHA-1 only devices, it was using a public CA for a private
PKI.
Peter.
>But if it's an old version of NSS or OpenSSL, then the community could help
>find an exploitable bug.
If it's a remote-code-exec we could patch their firmware for them to support
SHA-256. Think of it as an undocumented remote admin capability.
(Something like this has been done in the past to fix a commercial vendor's
gear).
Peter.
>They state no business case where the 9 payment gateways are accessible by
>browsers or that any business case exists on the gateways that uses any
>client other than the payment terminal.
So these things will never see access by a browser enforcing the SHA-1
restrictions? Where is the restriction coming from then, is it that the
browser vendors have told the CAs (via the CAB Forum) they can't issue SHA-1
certs of any kind, even if they're only used in a private PKIs?
I'd really like to get some comment from WorldPay on precisely what's going on
here. It'd be a lot easier to sort out if we knew exactly what was happening,
Rob Stradling posted a good base set of questions that need to be answered.
If we knew more details it seems like there could be an easier solution than
having to break the no-SHA1-any-more rule.
Peter.
>The same one they've been using and know works: VeriSign Class 3
>International Server CA - G3.
So the devices will trust any cert from this CA?
This is a serious question, a contractor once got into USG infrastructure
with a $20 or so cert because they'd done the same thing, contracted their
private PKI out to a public CA, so their infrastructure trusted any cert
chaining up to the CA's roots.
Anyone know if one of these:
http://www.ebay.com/itm/WorldPay-Verifone-Credit-Card-Transaction-Terminal-With-Printer-New-In-Box-/301863681435
http://www.ebay.com/itm/WorldPay-Zinc-Chip-and-Pin-Mobile-Card-reader-/262304198832
would use these certs?
Peter.
>While we are disappointed that a critical part of the Internet
>infrastructure is holding back an increase in security, we believe that
>this allowance strikes an acceptable compromise between minimizing
>disruption and risk and encouraging migration away from SHA-1 as fast as
>possible.
I'd still really like to know the details of what happened here. As I've
pointed out to others off-list, it's not to assign blame but to learn from
it so that others won't make the same mistake in similar situations in the
future.
Peter.
>According to WP, as part of the EMV program, they are aggressively rolling
>out new devices to replace all old equipment in the field. They expect this
>to be completed by the end of the year. They have already moved a large
>number of devices to support SHA-2.
Wouldn't it be easier to issue their own certs (or roll out equipment which
relies on WorldPay certs), at which point they could follow their own
policies? Their problem is that their (inexplicable) use of a public CA for a
private PKI has meant they're now being held hostage to the CAB forum's cert
policy. I don't mean that in a negative sense, that policy is probably
perfectly sensible for browser PKI, but it's not a good policy for a payment
processor with huge amounts of fixed-function, non-upgradeable equipment
deployed all over the planet.
Peter.
Thesecertificate have been logged to our CT log server at ct.ws.symantec.com,with these index numbers:
236731
236746
236748
236751
236759
236763
236767