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

[Ryan Sleevi]

On Sep 18, 2014 4:13 PM, "Erwann Abalea" <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>
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.

That is, the similarity of the outer syntax alone is enough for these to be
conflated.

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

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?

In each of these cases, we are saying there is 'intent' - with language
backed by appropriate specs that defines precisely how to divine/express
that intent - that makes these 'different'.

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

Right :)

And though we disagree, this ballot helps drive us to the same effective
result, even though we have reached different conclusions.

>> [...]
>>
>> > 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".
>

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)

> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140918/d8931f86/attachment-0001.html