[cabfpub] CT Precertificates and the BRs

Robert Relyea rrelyea at redhat.com
Wed Jan 15 16:46:22 MST 2014


On 01/10/2014 06:20 AM, Rob Stradling wrote:
> On 08/01/14 11:11, Ben Laurie wrote:
>> On 8 January 2014 06:38, Mads Egil Henriksveen wrote:
> <snip>
>>> 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.
>> This would be cleaner, of course.
> I expect that this will be the end result, yes.
>
> IMHO, the BRs - as currently written - neither explicitly nor implicitly 
> forbid a CA from using the same serial number in multiple certificates.

So it may not be explicitly forbidden by the BR's but it's certainly not
going to work with the Mozilla security library. It treats issuer/SN as
a unique identifier for a certificate. If you have 2 with the same
issuer/DN, NSS will only ever see one of them (even if you try to import
the second). If the precert is ever anything a browser would see, it's
probably not a good idea to have it share a serial number with it's
peer, otherwise it may render the peer inoperable inside NSS...


bob

>
> If (and, I hope, when) we close this loophole, then yes, the BRs will 
> need to explicitly permit a CA to sign a Precertificate and a 
> Certificate sharing the same serial number.
>
> Until then, I conclude that, right now, the BRs implicitly permit a CA 
> to sign a Precertificate and a Certificate sharing the same serial number.
>
>>> Regards
>>> Mads
>>>
>>>
>>> -----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 4.1.2.2 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
>>> https://cabforum.org/mailman/listinfo/public
>>> _______________________________________________
>>> 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: 4521 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20140115/237e4d87/attachment-0001.bin 


More information about the Public mailing list