[cabfpub] Possible BR amendment for limited exemption from RFC 5280 compliance

[kirk_hall at trendmicro.com]

I asked Ben to add the topic "Guideline review for CT implementation" to the F2F agenda.  Here is some background, as well as a potential amendment to the Baseline Requirements for us to discuss.

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.

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.

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.

A Possible Solution

A possible solution is to amend the BRs to provide a limited exemption to RFC 5280 compliance for CT implementation.  Here is possible amendment language to consider.  This is not a pre-ballot, just something for discussion on this list and at our F2F meeting next week.

*****

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.


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140912/2e9a64c0/attachment-0001.html