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

[Ryan Sleevi]

On Sep 18, 2014 11:43 AM, "Erwann Abalea" <erwann.abalea at opentrust.com>
wrote:
>
> 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.
>
>

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.

>>
>>
>> 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.
>

As we discussed, there is quite a bit of 'open discussion' on what RFC5280
compliance means.

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).

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.

>
>>
>>
>> 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.
>
>

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.
_______________________________________________
> 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/20140918/125e4135/attachment-0003.html>