[cabfpub] Application for SHA-1 Issuance

[Steve Medin]

On Sunday July 31, 2016, Symantec issued seven SHA-1 certificates as part of
the SHA-1 exception process discussed on this Forum over the past few
months. Symantec created an internal exception process where TBSCertificates
were submitted to the community for counter-cryptanalysis, then after
approval from browser vendors the final certificates were signed.
 
During the signing process for the final certificates, we discovered that
three certificates were signed with encoding discrepancies from the original
TBSCertificates. Specifically, the encoding of the RPA string in the
certPolicies extension of the final certificates was UTF8String, where the
encoding of that string in the TBSCertificates was PrintableString. The
discrepancy was discovered as part of a QA review during the signing
process, and once identified we corrected the encoding and re-signed the
certificates. 
 
As a result, for each of these three certificates, we signed two
certificates with the same serial number and identical data, except for the
encoding of the RPA string in certPolicies. RFC 5280 prohibits signing two
different certificates with the same serial number, but the exception
process required the serial number in the final certificate to match that of
the TBSCertificate, so we needed to re-sign these certificates so that their
content exactly matched what was previously published as TBSCertificates.
 
The application used to create the TBSCertificate was not designed to sign a
previously-generated TBSCertificate. During the course of re-manually
generating the approved TBSCertificate for signing, human error led to this
discrepancy. The QA review process occurred after the three certificates had
been issued. We have updated our manual exception process to ensure an
additional review is completed prior to signing. 
 
Given that the incorrectly-encoded and correctly-encoded certificates share
the same serial numbers, the incorrectly-encoded certificates cannot be
revoked without also revoking the correctly-encoded certificates.
 
These certificates are for use in non-browser applications, so browser
vendors may wish to blacklist (via OneCRL, CRLSet or equivalent method) both
sets of certificates. To that end, we offer the SHA-1 and SHA-2 fingerprints
of the three incorrectly-encoded certificates as follows:

ssl1.vitalps.net.Dallas_final_160731.cer
SHA1(ssl1.vitalps.net.Dallas_final_160731.cer)=
bd7bd71c65f7fa885c8ea8b71988bfec6bded381
SHA256(ssl1.vitalps.net.Dallas_final_160731.cer)=
a6a35c67acdd6b8d057253a19770110787982d7dbff0aa3a7698364dccb4ebdc
----------
ssl1.vitalps.net.Reston_final_160731.cer
SHA1(ssl1.vitalps.net.Reston_final_160731.cer)=
62e58770139a0f026078b50055cc80c02573f50c
SHA256(ssl1.vitalps.net.Reston_final_160731.cer)=
fa7a0cd1f4aab121cae8ca8e4b2b030d597e05f10f3ee36831e6b3076effe3d0
----------
ssl2.vitalps.net.Dallas_final_160731.cer
SHA1(ssl2.vitalps.net.Dallas_final_160731.cer)=
91432e8011bf13633e4e78fbc740b8cda63971a7
SHA256(ssl2.vitalps.net.Dallas_final_160731.cer)=
7b42b9c012da3753977de39ea39cb57165b035d99aaf9889e532678bc180a4c7
 
The three incorrectly-encoded certificates will not be provided to the
customer. Further, given the industry concerns regarding access to and abuse
of SHA-1 hashes, we do not intend to publish the three incorrectly-encoded
certificates to CT logs (the correctly encoded certificates have all been
logged already).

Kind regards,
Steven Medin
Symantec Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160804/1bde6f32/attachment-0001.p7s>