<p dir="ltr"><br>
On Sep 18, 2014 4:13 PM, "Erwann Abalea" <<a href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>> wrote:<br>
><br>
><br>
> Le 18/09/2014 22:59, Ryan Sleevi a écrit :<br>
>><br>
>> On Sep 18, 2014 1:25 PM, "Erwann Abalea" <<a href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>> wrote:<br>
>><br>
>> [...]<br>
>><br>
>> 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.<br>
>><br>
>> 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).<br>
>><br>
>> 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.<br>
>><br>
>> Their distinguishing feature comes from how that inner SEQUENCE is structured.<br>
><br>
><br>
> Their syntax, yes.<br>
><br>
><br>
>> 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.<br>
><br>
><br>
> 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.<br>
><br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">That is, the similarity of the outer syntax alone is enough for these to be conflated.</p>
<p dir="ltr">>> 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.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
> 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.<br>
></p>
<p dir="ltr">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?</p>
<p dir="ltr">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'.</p>
<p dir="ltr">> It's like me saying in fluent french that I don't speak french.<br>
> 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.<br>
><br>
><br>
>> The poison extension - a structural facet of a PreCert - is as distinguishing to RFC5280 as a different ASN.1 structure. It makes them different.<br>
><br>
><br>
> It makes it invalid for any purpose, by its semantic. Not by its syntax (ASN.1).<br>
><br>
> [...]<br>
><br>
>> > 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 ...".<br>
>> ><br>
>><br>
>> Hopefully the above makes it clearer.<br>
><br>
><br>
> Nope.<br>
> Well, not really. It's clear that we disagree ;)<br>
></p>
<p dir="ltr">Right :)</p>
<p dir="ltr">And though we disagree, this ballot helps drive us to the same effective result, even though we have reached different conclusions.</p>
<p dir="ltr">>> [...]<br>
>><br>
>> > If there's no violation, what's the purpose of this ballot?<br>
>> ><br>
>><br>
>> 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 :)<br>
><br>
><br>
> I'm not sure about telling the auditor "I'm not concerned with this requirement because I decided so. XOXO".<br>
></p>
<p dir="ltr">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)</p>
<p dir="ltr">> We already sat on RFC5280 requirements about NameConstraints, despite the security risks, and didn't try to elude it.<br>
> Why can't we do the same on this issuerName+serialNumber unicity without admitting that we're violating it?</p>
<p dir="ltr">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)</p>