[cabfpub] Ballot for limited exemption to RFC 5280 for CT implementation

[Jeremy.Rowley]

CT is required for EV in January, and most CAs are trying to get ready 
before the deadline.  Waiting for the Trans group isn't really an option 
anymore, especially if there is delay between any document adopted by 
Trans and the implementation date by Google. I also don't think we need 
to time-box on the language since (a) we don't have a timeline from 
Trans on when a standard will be adopted and (b) we don't have a 
timeline from Google on when any ideas from Trans will be adopted.

That said, we might want to clarify that the language about what 
constitutes a "pre-certificate".  Your definition seems reasonable.

Jeremy


On 9/17/2014 9:55 PM, Brian Smith wrote:
> On Wed, Sep 17, 2014 at 7:01 PM, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com>> wrote:
>
>
>     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)._/*
>
>
> This seems like a bad and unnecessary idea to me. The trans working 
> group is already debating discussing the format of precertificates so 
> that they are not syntactically-valid certificates for the 
> standards-track CT mechanism. The version of CT Google and the CAs 
> have implemented is an experiment, not a standard or proposed 
> standard. The CAs can work around this issue by using the OCSP-based 
> CT mechanism instead of the precertificate mechanism. Finally, IIUC, 
> the only negative consequence of this that EV certificates
>
> IMO, it makes more sense to change the experiment than it does to 
> (effectively) change the fundamental standards that all CABForum work 
> is based on.
>
> Note that the use or non-use of a precertificate signing certificate 
> has no bearing (IIUC) on whether the precertificate would be a 
> duplicate of the final certificate, because the difference between 
> Option 1 and Option 2 doesn't affect the issuer and serial number 
> fields of the precertificate.
>
>      2. Amend Appendix B as follows:
>
>     Appendix B – Certificate Extensions (Normative/)_;*Limited
>     Exemption from Compliance with RFC 5280*_/
>
>     **
>
>     This appendix specifies the requirements for Certificate
>     extensions for Certificates generated after the Effective Date. ***
>
>     *_(/5) Limited Exemption from Compliance with RFC 5280/_*
>
>     */__/*
>
>     */_In order to comply with the requirements of Certificate
>     Transparency, CAs may use pre-certificates and certificates that
>     contain the same serial number and are issued from the same
>     Subordinate CA Certificate._/*
>
>
> I think the language here should be cleaned up, because 
> "pre-certificate" is not defined in the document. In particular, I 
> suggest that you state the exemption in terms of the presence of the 
> critical poison extension and that the two certificates must be 
> bit-for-bit identical except for the poison extension, the SCT 
> extension, and the signature, and the length fields of the 
> tbsCertificate and tbsCertificate.extensions fields. This way, you 
> avoid creating a giant and unintended loophole in the BRs.
>
> Also, I suggest that you time-box the exemption so that it doesn't 
> continue in perpetuity, past when CT is fixed.
>
> Cheers,
> Brian
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140917/3865b804/attachment-0003.html>