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

[Erwann Abalea]

Le 18/09/2014 04:01, kirk_hall at trendmicro.com a écrit :
>
> Ben -- at our F2F meeting yesterday, I presented the following draft 
> ballot to provide a limited exemption from RFC 5280 for the purpose of 
> CT implementation. The background for this proposed ballot is included 
> below.
>
> The Members were favorable to the idea, and there were four endorsers 
> for the draft ballot: Digicert, Entrust, GoDaddy, and Symantec.
>
> At the right time, can you present this to the Members as a Ballot for 
> discussion and voting?  Thanks.
>
> */Kirk R. Hall/*
>
> Operations Director, Trust Services
>
> Trend Micro
>
> +1.503.753.3088
>
> *****
>
> 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)._/*
>
> 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._/*__
>
> Effective Date: Upon approval by the Members.
>
> *****
>
> Reasons for ballot:
>
> *_The Problem_*
>
> CT envisions three methods for presenting the necessary SCTs to 
> browsers to show that a certificate has been logged in CT logs, but 
> only one method (using precerts to gather the SCTS, then include them 
> with the production cert sent to the customer) is currently workable.
>
> RFC 6962 seems to say that CAs have two choices for how to issue 
> precerts and production certs after CT logging and gathering of SCTs.
>
> _Option 1_ -- The CA can use the /_real_/ issuing sub-CA /_both_/ to 
> issue the precert (for logging the precert and collecting SCTs) and to 
> issue the final production cert containing the SCTs, or
>
> _Option 2_ - The CA can use a /_special_/ precert signing sub-CA for 
> the precert (for logging the precert and collecting SCTs), and then 
> use the /_real_/ issuing sub-CA to issue the final production cert 
> containing the SCTs.  The CA must change the name of the issuing 
> sub-CA in the final production cert (from the name of the special 
> precert signing sub-CA).
>
> I polled the members of the CA Security Council on which option they 
> prefer, and at this point we all strongly prefer Option 1.  For some, 
> Option 2 is especially difficult, as it will involve a handoff of 
> information between the precert sub-CA and the production cert sub-CA.
>
> CAs have been told that they must implement CT by January 1, 2015, and 
> there is little time left to complete engineering if this deadline is 
> to be met.  Also, the IETF group working on RFC 6962 (which is still 
> "experimental" with "errata") has not yet completed specifications 
> around precerts.
>

Current work at IETF on precerts specifications will be for RFC6962-bis. 
RFC6962 already exists and has its own (not perfect) definition of what 
a precert is.

> However, this creates a dilemma -- both the precert and the production 
> cert will be issued from the same sub-CA (the entire issuing chain 
> will be the same), and both will have the same Serial Number -- 
> something necessary for CT, but not permitted under RFC 5280.  To 
> remedy this, the precert will have a so-called "poison extension" to 
> tell applications it is not to be used as a real SSL cert. The use of 
> the poison extension may or may the precerts do not violate RFC 5280, 
> but this is not clear.
>

It is clear that the poison extension has no impact of X.509/RFC5280 
violation. The uniqueness of issuerName+serialNumber does NOT depend on 
any other factor or element.

> The current Baseline Requirements seem to require all certificates to 
> comply with RFC 5280.  See the Definition of Valid Certificate, and 
> see the references to RFC 5280 in Appendix B.
>
> Given that CAs will likely be implementing CT Option 1 before 2015 to 
> meet the CT deadlines, we would like clarity in the BRs that we are 
> not violating the requirements to comply with RFC 5280.
>

That's wrong. The requirements to comply with RFC5280 will be violated 
by CAs that choose Option 1. That's why {you, they, we}'re asking for an 
exemption.

> *Proposed Solution*
>
> The proposed solution is to amend the BRs to provide a limited 
> exemption to RFC 5280 compliance for CT implementation.  See the 
> ballot language above.
>

I fail to see where the limit is stated.

For the previous exemption (non critical NC extension), the exception to 
RFC5280 runs "until the Name Constraints extension is supported by 
Application Software Suppliers whose software is used by a substantial 
portion of Relying Parties worldwide."

I'd like to see the same kind of limit expressed.
Maybe something like "until a successor of RFC6962 defines a structure 
that doesn't violate RFC5280 constraints"? We'll have to deal with 
then-legacy software, again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140918/99263999/attachment-0003.html>