[cabfpub] Application for SHA-1 Issuance

Wed Jul 20 19:20:20 UTC 2016

Responses below posted on behalf of TSYS.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Andrew Ayer
Sent: Sunday, July 17, 2016 5:16 PM

Thanks, Dean, for adding the CC.  Here are my questions for TSYS.  I also
have some concerns regarding the answer to question 9 that both TSYS and
Symantec should consider carefully.

Question 3

Has using a pulled root been tried yet, or are you speculating what would
happen if a pulled root were used?

>> TSYS started validation using a pulled root in May 2016, when it was
determined that the G1 Verisign root was a candidate and promptly created
test ports / services for integration partners to utilize.

While a pulled root would likely satisfy ~90% of the short term need, many
operating systems including iOS/Mac OS 10.10 do not trust the chain
associated with the deprecated root and many OS platforms will remove the G1
root in 2017 from CA Trust Stores.

The use of a pulled root, while technically possible and having slightly
lower risk than moving to SHA-2, has not been validated End-to-End by every
possible OS and Payment Software or Device combination by Integration
Partners, ISVs, Acquirers or Merchants that utilize TSYS.  While progress is
being made and confidence in a deprecated root SHA-1 solution has improved,
TSYS does not have confidence that deployment of a deprecated root solution
would be 99.99% successful and limit cardholder impact at the Point-of
Interaction with the Merchant.

TSYS is continuing to work with all of the payment vendors to validate
interoperability with a deprecated root and the associated chain, however it
is secondary to ensuring they complete the necessary changes/updates to be
ready for SHA-2 by January 2017.

If required to deploy a deprecated root solution, TSYS expects ~10% failure
rate for untrusted CA or Chain, which requires manual intervention on most
platforms and in some cases is not something that can be done in the field.

The existing chain and signing root for our current SHA-1 certificates is
presently trusted, which is why TSYS has asked for a short extension.

One option, if some clients are receiving updates and others aren't, is to
serve different certificate chains depending on the TLS handshake.
If the handshake indicates support for SHA-2, you serve a SHA-2 certificate
from a trusted root.  Otherwise, you serve a SHA-1 certificate from a pulled
root.  Facebook and CloudFlare use this technique successfully.

Facebook and CloudFlare use custom code, but Apache has out-of-the-box
support for selecting certificates based on key algorithm, so you could
serve a SHA-2 ECDSA certificate to clients that support ECDSA, and a SHA-1
RSA certificate (from a pulled
root) to clients that don't.  This would work as long as the clients that
don't support ECDSA recognize the pulled root.  See:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile

Has this technique been tried yet?  If not, could it be?

>> The technique noted related to 2 certificates is not supported by the
platform versions that we presently use.  It was considered as a potential
solution and would have required a substantial re-design, regression, risk
and impact assessment of the platforms.  All consideration was given to
alternate options vs extending the life of our SHA-1 certificates.

Question 7

"11/30/2015 - Symantec report of remaining SHA1 certs sent internally by
TSYS"

Did this report include the certificates for the four FQDNs in this
application?  If not, why not?

If it did, why did TSYS not obtain SHA-1 certificates for these FQDNs
between November 30 and December 31?  Other organizations stockpiled
long-lived SHA-1 certificates before the sunset to allow themselves extra
time to migrate away from SHA-1.  Was TSYS aware of this possibility?

>> The team responsible for certificate management within the TSYS
subsidiary received the notifications but did not understand the full impact
and did not realize they could have stockpiled SHA1 certificates.

Question 9

"One thing you will notice is the validity date extends to Feb 10, 2017. In
the payment industry, 31 December is an absolutely horrible time to make a
change as it represents one of the peak times for traffic."

Although the "Post Jan 2016 SHA-1 Issuance Request Procedure" version
1.1 mandates an expiration of December 31, 2016 or earlier, I think a later
expiration is fine.  The risk to the public from SHA-1 manifests during
issuance and a later expiration date does not affect this risk.
In fact, it would be better for TSYS to have some extra time than it would
be to invoke this procedure again.

>> TSYS has communicated that it will terminate all support for SHA-1
Certificates starting January 16, 2017 and concluding on February 9, 2017.  

A more serious problem with this request is that every TBSCertificate uses a
brand new key pair that first appeared in certificate transparency logs only
a few days ago.  An explanation for why new key pairs are needed has not
been provided as required by the Request Procedure.  Also troubling is that
every TBSCertificate contains inexplicable gibberish in the Subject OU (e.g.
"TDS-2-Dallas-SCA-v2PmB4cxayEu") that does not appear in any certificate
known to exist before 2016.  Furthermore, the order of extensions is
different from pre-2016 certificates for these FQDNs.

As Peter Bowen explained in
<https://cabforum.org/pipermail/public/2016-April/007188.html>, making the
TBSCertificate as similar as possible to one that existed prior to the SHA-1
sunset greatly minimizes the risk of a collision attack.
(This implies reusing a key pair, since the Subject Public Key Info
comprises the bulk of a TBSCertificate.)  However, the TBSCertificates in
this request look nothing like certificates known to exist prior to the
sunset, and the introduction of gibberish in the subject OU is exactly what
one might see if this request were exploiting a collision.  (I'm sure
there's an innocuous explanation for the gibberish, but considering the risk
to the public, any request for SHA-1 issuance must be above suspicion.)

>> As a practice, for the SSL/TLS Payment Gateway Services, TSYS Acquiring
generates new Private Keys, passphrases and CSRs for every issuance of
SSL/TLS Certificates.  This is to avoid unnecessary revocation due to
deprecated process, content management/controls and any risks related to key
retention and broad re-use.

This appears fixable.  I found the following unexpired certificates for
these FQDNs in CT:

 * ssl1.tsysacquiring.net, logged in 2015:
https://crt.sh/?sha256=C741F74C12594139191F80734A57B0A4847F3CF2BD048E433EA76
F858927F1C1
 * ssl1.vitalps.net, logged in 2014:
https://crt.sh/?sha256=a432185e24201d7ab954870193d3f4b2d077b8fd521da76773fed
0623236b27f
 * ssl2.vitalps.net, logged in July 2016, notBefore in 2014:
https://crt.sh/?sha256=1b5546e8d29ec8734dca953e29da8df757122cd169ceadb364a10
c3670f7d15c
 * ssl3.vitalps.net, logged in July 2016, notBefore in 2015:
https://crt.sh/?sha256=49d022ab09592a9c4139e9e958438fe905e745e1a48bac72355b0
108b9e4a088

Two of these certificates were logged before the sunset, and the other two
have a notBefore date prior to the sunset.  TSYS should reuse the keys and
subjects from these certificates, or from one of the other pre-2016
certificates that can be found by searching crt.sh for these FQDNs.
Symantec should make the TBSCertificates as similar as possible to these
pre-2016 certificates, including in the order of extensions.
Ideally, the only differences would be in validity and serial number.
It would also help to provide evidence that the keys for ssl2.vitalps.net
and ssl3.vitalps.net were generated prior to 2016.

Following these recommendations would make this request a lot less risky,
more in line with the letter and spirit of the "Existing Certificate
Information" section of the Request Procedure, and presumably more likely to
be approved by the Application Software Suppliers. However, as the request
currently stands, I think the Application Software Suppliers should reject
it.

Regards,
Andrew
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160720/05935933/attachment-0001.p7s>