<p dir="ltr"><br>
On Sep 18, 2014 11:43 AM, "Erwann Abalea" <<a href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>> wrote:<br>
><br>
> Le 18/09/2014 04:01, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> a écrit :<br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> The Members were favorable to the idea, and there were four endorsers for the draft ballot: Digicert, Entrust, GoDaddy, and Symantec.<br>
>><br>
>>  <br>
>><br>
>> At the right time, can you present this to the Members as a Ballot for discussion and voting?  Thanks.<br>
>><br>
>>  <br>
>><br>
>> Kirk R. Hall<br>
>><br>
>> Operations Director, Trust Services<br>
>><br>
>> Trend Micro<br>
>><br>
>> +1.503.753.3088<br>
>><br>
>>  <br>
>><br>
>> *****<br>
>><br>
>>  <br>
>><br>
>> Proposed amendments to Baseline Requirements.  <br>
>><br>
>>  <br>
>><br>
>> New language is shown in bold , italics, and underlined.<br>
>><br>
>>  <br>
>><br>
>> 1. Amend the Definitions as follows:<br>
>><br>
>>  <br>
>><br>
>> Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280 (except for the limited exemption provided in Appendix B).<br>
>><br>
>>  <br>
>><br>
>>  <br>
>><br>
>> 2. Amend Appendix B as follows:<br>
>><br>
>>  <br>
>><br>
>> Appendix B – Certificate Extensions (Normative); Limited Exemption from Compliance with RFC 5280<br>
>><br>
>>  <br>
>><br>
>> This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date. ***<br>
>><br>
>>  <br>
>><br>
>> (5) Limited Exemption from Compliance with RFC 5280<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> Effective Date: Upon approval by the Members.<br>
>><br>
>>  <br>
>><br>
>> *****<br>
>><br>
>>  <br>
>><br>
>> Reasons for ballot:<br>
>><br>
>>  <br>
>><br>
>> The Problem<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> 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<br>
>><br>
>>  <br>
>><br>
>> 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).<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
><br>
><br>
> 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.<br>
><br>
><br>
>> 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.<br>
><br>
><br>
> 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.<br>
><br>
></p>
<p dir="ltr">Respectfully, I'd disagree. A PreCert is NOT a cert intended to comply with RFC5280. It's potentially an X.509 cert, yes, but you know very well that not every X.509 encoded cert is an RFC5280 cert.</p>
<p dir="ltr">>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> 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.<br>
><br>
><br>
> 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.<br>
></p>
<p dir="ltr">As we discussed, there is quite a bit of 'open discussion' on what RFC5280 compliance means.</p>
<p dir="ltr">I don't think anyone would say a CA violates RFC5280 when they sign an OCSPResponse (RFC2560), which is equivalent in spirit and intent to signing a PreCertificate (RFC6962).</p>
<p dir="ltr">However, rather than debate this (as we have), it seems quite good to do what is being done here - which is being explicit about that.</p>
<p dir="ltr">><br>
>>  <br>
>><br>
>> Proposed Solution<br>
>><br>
>>  <br>
>><br>
>> 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. <br>
><br>
><br>
> I fail to see where the limit is stated.<br>
><br>
> 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."<br>
><br>
> I'd like to see the same kind of limit expressed.<br>
> 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.<br>
><br>
></p>
<p dir="ltr">I fail to see the value/concern here, even if we accept your position that it's a violation, so I'm hoping you can explain more.<br>
 _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
><br>
</p>