[cabfpub] Application for SHA-1 Issuance

Dean Coclin Dean_Coclin at symantec.com
Mon Jul 18 17:47:45 UTC 2016


The response I received from TSYS regarding the OU value is as follows:

"The value at the end of the OU, is an independent cryptographically created
identity value used by TSYS Support for the sole purpose of identifying the
site where the services terminate."

Dean

-----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
To: public at cabforum.org; Bryan Smoak <BryanSmoak at tsys.com>
Subject: Re: [cabfpub] Application for SHA-1 Issuance

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?

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?


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?


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.

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.)

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/20160718/abbd303c/attachment-0001.p7s>


More information about the Public mailing list