[cabfpub] Application for SHA-1 Issuance

Steve Medin Steve_Medin at symantec.com
Thu Aug 4 20:52:57 UTC 2016

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
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:

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>

More information about the Public mailing list