[cabfpub] CT Precertificates and the BRs

Mads Egil Henriksveen Mads.Henriksveen at buypass.no
Wed Jan 8 06:38:34 UTC 2014

Hi Rob

I agree with your conclusion. i.e. that the CT precertificate should be allowed within BR. But I am not comfortable with how you suggest to accomplish this.

If I understand the CT concept correct, a CT precertificate is a complete SSL certificate (as those we issue today) to be registered in a CT log. The CT log returns a SCT which could be included as a certificate extension and the final SSL certificate including the SCT (or more than one SCT) has to be (re)signed before delivery to the customer. Both the CT precertificate and the final SSL certificate could be used as a SSL certificate. The idea of saying that the CT precertificate as not intended to be used as a SSL certificate is problematic and difficult to ensure.  

The CT precertificate and the final SSL certificate are both SSL certificates, with the SCT(s) as the only difference. Of course, the hash and signature for those certificates will differ as well. So we need to decide on whether these are two different certificates or could be interpreted as one certificate (as Jeremy suggest). 

I think we should stick with your original proposal, i.e. change the BR to permit a CA to sign a Precertificate and a Certificate sharing the same serial number.  


-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling
Sent: 7. januar 2014 13:14
To: public at cabforum.org
Subject: Re: [cabfpub] CT Precertificates and the BRs

I've changed my mind.  I no longer think that a CT Precertificate (with the same Issuer Name/Key and Serial Number as the corresponding SSL
Certificate) is currently illegal under the BRs.

The current scope of the BRs is "Certificates intended to be used for authenticating servers accessible through the Internet".  A CT Precertificate is only intended to be used to verify that the CA and the CT Log(s) are doing CT stuff correctly.  It's the corresponding SSL Certificate that is intended to be used for authenticating server(s).

As we continue to work on drafting new text to fix the loopholes in the Scope of the BRs, let's make sure that CT Precertificates remain legal!

On 17/12/13 13:18, Rob Stradling wrote:
> RFC6962 (Certificate Transparency) permits a Precertificate to be 
> signed by the same CA Name/Key that signs the corresponding 
> Certificate, and for the Precertificate and Certificate to share the same Serial Number.
> However, BRs Appendix B (4) says:
>      "All other fields and extensions MUST be set in accordance with RFC
>       5280."
> Although the title of Appendix B is "Certificate Extensions", I think 
> "fields and extensions" must surely imply that "fields" are the 
> non-extension parts of a certificate (such as the serial number).
> And since certificate serial numbers are not explicitly mentioned in 
> Appendix B, I have to conclude that certificate serial numbers "MUST 
> be set in accordance with RFC 5280".
> RFC 5280 Section says:
>      "The serial number...MUST be unique for each certificate issued by a
>       given CA (i.e., the issuer name and serial number identify a unique
>       certificate)".
> It seems that the practice of using the same CA Name/Key to sign both 
> a Precertificate and Certificate is currently _illegal_ under the BRs.
> RFC6962 also permits a Precertificate to be signed by a subordinate 
> Precertificate Signing Certificate.  This approach doesn't violate
> RFC5280 or the BRs, but some CAs will want to avoid the burden of 
> managing a Precertificate Signing Certificate for every subordinate CA 
> they operate.  So, Ben Laurie and I have been working on some other 
> possible solutions, but our preferred outcome would be for both of the 
> Precertificate signing options in RFC6962 to be made legal.
> Therefore, I would like to propose updating Appendix B of the BRs so 
> that CAs are permitted to sign a Precertificate and a Certificate 
> (sharing the same serial number) using the same CA Name/Key.
> Would anybody have a problem with that?

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Public mailing list
Public at cabforum.org

More information about the Public mailing list