[cabfpub] CT Precertificates and the BRs

Jeremy Rowley jeremy.rowley at digicert.com
Fri Dec 20 21:28:37 UTC 2013

Agreed.  Plus, a CT-type solution was not anticipated by the RFCs so this
scenario can't be considered covered by the RFCs recommendations.  As
mentioned on the call, I view them as the same certificate, so I don't see
an issue with the same serial number.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rob Stradling
Sent: Friday, December 20, 2013 2:24 PM
To: Phillip Hallam-Baker; Jeremy Rowley
Cc: public at cabforum.org
Subject: Re: [cabfpub] CT Precertificates and the BRs

On 20/12/13 16:34, Phillip Hallam-Baker wrote:
> If we are having to change policy to accommodate CT then I don't think 
> the choice of using the serial number can be said to be working so well.

X.509 and the PKIX RFCs are not sacred texts.  The BRs have deviated from
them on a few points already: allow non-critical Name Constraints, disallow
OCSP "good" for non-issued certs.

To repeat my question:
If there are 2 certs (a Certificate and its associated CT
Precertificate) with the same Issuer Name and Serial Number, what exactly
would break in the WebPKI?

An RFC6962 Precertificate/Certificate pair MUST be revoked together, so from
this point of view sharing the same Issuer Name and Serial Number is
actually desirable.

Yes, RFC6962-bis could specify a non-X509v3 format for Precertificates, but
that would be reinventing the wheel.  Not impossible, but (for those who
have already implemented RFC6962 Precertificates, including me) not
desirable either.

What would be the tangible benefit(s) of disallowing the same Issuer Name
and Serial Number for a Precertificate/Certificate pair?


Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Public mailing list
Public at cabforum.org

More information about the Public mailing list