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

[Erwann Abalea]

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.

> This is the same arguments for Certificate != PreCertificate. The 
> ASN.1 diverges and distinguishes the two, the same conceptual way the 
> contents of a tbsCertList differs from a tbsCertificate.
>

No, the ASN.1 between a Certificate and a PreCertificate doesn't 
diverge. They both are syntaxically the same thing, an X.509 
certificate. If you wanted to make them syntaxically different, you 
could have added an element in the signed SEQUENCE such as a BOOLEAN 
element before the version (strong result), or changed the version to be 
a negative number (weak result). But the position was to ease adoption 
and deployment, and the easiest way for CAs was to reuse an object they 
already can produce: an X.509 certificate.

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.

It's like me saying in fluent french that I don't speak french.
Or having a PreCert that contains a CertificatePolicies referencing a 
policyId not in scope with its issuing CA certificate itself having a 
PolicyConstraints extension with a requiredExplicitPolicy set to 0, to 
tell that this certificate isn't concerned by all these constraints.

> The poison extension - a structural facet of a PreCert - is as 
> distinguishing to RFC5280 as a different ASN.1 structure. It makes 
> them different.
>

It makes it invalid for any purpose, by its semantic. Not by its syntax 
(ASN.1).

[...]
>
> > I don't follow you. Where is the equivalence (in spirit and intent) 
> between an OCSPResponse and a PreCertificate? A PreCertificate is kind 
> of a "I produced and intend to render public for auditing purpose this 
> certificate (with this content, etc)", while an OCSPResponse is a "the 
> current revocation status of the certificate with this serial number 
> is ...".
> >
>
> Hopefully the above makes it clearer.
>

Nope.
Well, not really. It's clear that we disagree ;)

> [...]
> > If there's no violation, what's the purpose of this ballot?
> >
>
> 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".

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140919/7acbc0ec/attachment.html