[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation
Jeremy.Rowley
jeremy.rowley at digicert.com
Thu Sep 18 14:15:01 UTC 2014
I like it. Thanks Rob.
Jeremy
On 9/18/2014 7:49 AM, Rob Stradling wrote:
> On 18/09/14 11:15, Ben Wilson wrote:
>> Rob,
>> What if the ballot proposed a change to the title of Appendix B as you suggest, and also made it clear that, irrespective of RFC 5280's section 4.1.2.2 prohibition of duplicate serial numbers, for purposes of implementing Certificate Transparency (CT) pre-certificates, such practice is deemed "allowed"?
> Hi Ben. I would endorse such a ballot. Here's what I sent to the CASC
> list a week ago (on which nobody commented, so I'm wondering if it
> failed to arrive)...
>
>
> I would say that the "validation procedure specified in RFC5280" is
> RFC5280 Section 6. Since the serial number uniqueness requirement is in
> Section 4.1.2.2, I don't think it's in scope for the BRs' definition of
> "Valid Certificate".
>
> Some suggested text...
>
> 1. I think we should change the beginning of BRs Appendix B to...
>
> 'Appendix B - Certificate *Fields and* Extensions (Normative)
> This appendix specifies the requirements for Certificate *fields and*
> extensions for Certificates generated after the Effective Date.'
>
> 2. And I think we should add this to the end of the "Subscriber
> Certificate" section of Appendix B...
>
> 'G. Serial Number (required)
> This field MUST be set in accordance with RFC5280, with the exception
> that a Certificate's serial number MAY be shared by a corresponding
> RFC6962 "Precertificate" signed by the same Issuing CA.'
>
>> Ben
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling
>> Sent: September 18, 2014 3:53 AM
>> To: kirk_hall at trendmicro.com; CABFPub (public at cabforum.org)
>> Subject: Re: [cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation
>>
>> On 18/09/14 03:01, kirk_hall at trendmicro.com wrote:
>> <snip>
>>> Proposed amendments to Baseline Requirements.
>>>
>>> New language is shown in */_bold , italics, and underlined._/*
>>>
>>> 1. Amend the Definitions as follows:
>>>
>>> Valid Certificate:**A Certificate that passes the validation procedure
>>> specified in RFC 5280 */_(except for the limited exemption provided in
>>> Appendix B)._/*
>> Kirk, this proposed change to the "Valid Certificate" definition makes no sense to me at all.
>>
>> I interpret "validation procedure specified in RFC 5280" to mean RFC5280 Section 6 (entitled "Certification Path Validation"), which has absolutely nothing to say about duplicate serial numbers.
>> (The prohibition on duplicate serial numbers is in RFC5280 Section 4.1.2.2).
>>
>> I think the "Valid Certificate" definition is intended to include all certs that browsers accept, regardless of whether or not they've been issued in full compliance with the BRs. (That's arguably an unfortunate use of the word "Valid", but nonetheless I think this is the intent).
>>
>>> 2. Amend Appendix B as follows:
>>>
>>> Appendix B - Certificate Extensions (Normative/)_;*Limited Exemption
>>> from Compliance with RFC 5280*_/**
>> Again, this makes no sense. The serial number field is not a certificate extension.
>>
>> IMHO, the BRs, as written, don't actually incorporate the RFC5280 Section 4.1.2.2 rule prohibiting duplicate serial numbers.
>>
>> We could fix this by changing the title of Appendix B to "Certificate Fields and Extensions", but until we do that, your proposed limited exemption is a no-op.
>>
>> <snip>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
More information about the Public
mailing list