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

Mon Sep 22 09:56:36 MST 2014

Bonjour,

Le 19/09/2014 01:38, Ryan Sleevi a écrit :
>
> On Sep 18, 2014 4:13 PM, "Erwann Abalea" <erwann.abalea at opentrust.com 
> <mailto:erwann.abalea at opentrust.com>> wrote:
> >
> > Le 18/09/2014 22:59, Ryan Sleevi a écrit :
> >>
> >> On Sep 18, 2014 1:25 PM, "Erwann Abalea" 
> <erwann.abalea at opentrust.com <mailto:erwann.abalea at opentrust.com>> wrote:
> >> [...]
> >> Put differently, since I think you missed it: A CA can (on a 
> technical level) use the associated key to sign any data they want. 
> The BRs are not restrictive in this front.
> >>
> >> Currently, CAs sign three things for sure - BR compliant certs 
> (which incorporates RFC5280, which incorporates X.509), CRLs (again, 
> BRs to RFC5280), and OCSP (BRs -> RFC 2560).
> >>
> >> As you know, on a technical level, 5280 certs, 5280 crls, and 2560 
> responses ALL have the same conceptual structure - an ASN.1 SEQUENCE 
> of (SEQUENCE), AlgorithmIdentifier, BitString.
> >>
> >> Their distinguishing feature comes from how that inner SEQUENCE is 
> structured.
> >
> > Their syntax, yes.
> >
> >> You wouldn't argue that a BasicOCSPResponse is the same as a 
> Certificate is the same as a CertificateList, even though they have 
> the same basic structure.
> >
> > They have the same *conceptual* structure (only the outter layer), 
> but are syntaxically different beasts and are not interchangeable. You 
> can't read an X.509 certificate with an OCSPResponse parser.
>
> You'd be surprised. The fact that this outer structure is identical 
> means, for a number of APIs, you can give an OCSP response, ask "is 
> this a valid signed _certificate_", and the answer will come back yes.
>

The signature method has been defined by X.509v3 in 1997. Maybe the 
signature verification of that particular API is misnamed and checks 
that it's a correct X.509 signature (and not a correctly signed X.509 
certificate)? See SIGNED, SIGNATURE, and ENCRYPTED-HASH ASN.1 
definitions in X.509 (section 6), a Certificate is defined as 
"Certificate ::= SIGNED { CertificateContent }" at section 7.

Anyway, syntactically, an OCSPResponse, an X.509 CRL, and an X.509 
certificate are completely different objects. They may all use the same 
method/expression for the signature, defined by X.509. That doesn't make 
them interchangeable, only verifiable by the same API.

> > The Precertificate includes a perfectly described X.509/RFC5280 
> mechanism to make sure that an X.509/RFC5280 compliant validation 
> software will reject this certificate. The rejection won't be the 
> result of not being able to parse the object, but will be the result 
> of applying X.509/RFC5280 validation logic, the fact that a compliant 
> application trying to validate a certificate containing an unknown but 
> critical extension MUST reject the certificate. Once the application 
> gets at this stage, it already has read the X.509 certificate and 
> applies standard X.509 rules; whence, it's an X.509 certificate.
>
> > You're using the X.509/RFC5280 standardized validation algorithm to 
> tell that this object isn't concerned by X.509/RFC5280 constraints. 
> This can't stand.
> >
>
> Perhaps I have trouble understanding your "this cannot stand", but how 
> is this different from an S/MIME cert or a code signing cert - both of 
> which are 'syntactically' RFC5280 certs, but for which the processing 
> rules (of the SSL BRs) prevent them from being used as SSL?
>

There's a hierarchy.
We define what is covered by the BR, and what is out of scope of the BR, 
based on "higher" standards (RFC5280). So we're free to say that the 
Precerts are out of scope of the BR. And we can do this by using what is 
defined by these higher standards.
X.509/RFC5280 has nothing similar. There's no higher standard than 
X.509/RFC5280 that says that one particular "object" (which should have 
been defined by this inexistant standard) is out of scope of 
X.509/RFC5280 rules, other than being syntaxically incorrect or 
incorrectly signed.

Rephrasing.
Among all possible stream of octets, some of them form X.509 certificates.
Among all possible X.509 certificates, some of them form SSL 
certificates and MUST be covered by BR. The discriminant between BR 
in-scope/out-of-scope certificates is something that is expressed at 
X.509 level. BR cannot dictate what is to be covered by X.509 
constraints and what isn't.

[...]
>
> >> To make it clear to everyone that there's no violation, so that 
> auditor's don't have to have the same debate you and I are having with 
> CAs :)
> >
> > I'm not sure about telling the auditor "I'm not concerned with this 
> requirement because I decided so. XOXO".
> >
>
> I'm not sure I follow your remark. This is a ballot that as the Forum 
> make it clear that this is out of scope of the BRs explicitly (which I 
> argue it already is implicitly, using the same arguments that CAs have 
> made that have us discussing what the scope of the BRs cover)
>

Out of scope of the BR doesn't mean that it's out of scope of RFC5280. 
The auditor has to check that the CA correctly does its job (that's 
questionable, I know).

> > We already sat on RFC5280 requirements about NameConstraints, 
> despite the security risks, and didn't try to elude it.
> > Why can't we do the same on this issuerName+serialNumber unicity 
> without admitting that we're violating it?
>
> I have trouble parsing what you are saying here. But I also suspect we 
> disagree whether this is a 'bug' or not, much in the same way we 
> debate NCs (and what the language of 5280 requires of 5280 compliant 
> impls - that is, it DOES NOT require clients to support what the Forum 
> wants to use)
>

Rephrasing.

RFC5280 states that the NameConstraints extension MUST be critical. 
Doing otherwise is a security risk. As we know from experience, having 
this extension set to critical cuts a significant portion of browsers 
(Apple). It was discussed at IETF PKIX WG if an erratum could be 
proposed to change this MUST into a SHOULD. As you know, this wasn't 
accepted, and we finally added the current Appendix B in the BR. Despite 
the security risk of doing so (controlled risk, measurable consequences, 
etc).

I have no problem with the proposed addition to Appendix B (the wording 
only, not the idea). But I do care about how it is presented (Reasons 
for ballot):
-----
[...]
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.

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

How can a solution be proposed to something that isn't a problem? How 
can we ask for an exemption to RFC5280 compliance if 2 lines earlier 
we're saying that we're not violating the RFC5280 requirements?
Either admit that we're violating some RFC5280 requirements and ask for 
an exemption, or don't ask for anything.

In fact, I'm not favorable to the exemption, because Option 2 doesn't 
need it. There's no existing software to support in the wild, the 
experimental RFC6962 proposes several solutions, only one of them 
requires this exemption. The fact that Option 1 is seen as easier or 
cheaper shouldn't be an argument to derive from well established standards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140922/d61872cc/attachment.html 