<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Le 18/09/2014 22:59, Ryan Sleevi a écrit :<br>
</div>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<p dir="ltr">
On Sep 18, 2014 1:25 PM, "Erwann Abalea" <<a
moz-do-not-send="true"
href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>>
wrote:<br>
<br>
[...]<br>
</p>
<p dir="ltr">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.</p>
<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">Their distinguishing feature comes from how that
inner SEQUENCE is structured.</p>
</blockquote>
<br>
Their syntax, yes.<br>
<br>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<p dir="ltr">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.</p>
</blockquote>
<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>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<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.</p>
</blockquote>
<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>
<br>
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>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<p dir="ltr">The poison extension - a structural facet of a
PreCert - is as distinguishing to RFC5280 as a different ASN.1
structure. It makes them different.</p>
</blockquote>
<br>
It makes it invalid for any purpose, by its semantic. Not by its
syntax (ASN.1).<br>
<br>
[...]<br>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<p dir="ltr">> 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>
></p>
<p dir="ltr">Hopefully the above makes it clearer.<br>
</p>
</blockquote>
<br>
Nope.<br>
Well, not really. It's clear that we disagree ;)<br>
<br>
<blockquote
cite="mid:CACvaWvaq1oKyqPDNQ6UeJr3JPbn7epHvVDDUaAp685wjBsXH8g@mail.gmail.com"
type="cite">
<p dir="ltr">[...]<br>
> If there's no violation, what's the purpose of this ballot?<br>
></p>
<p dir="ltr">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 :)</p>
</blockquote>
<br>
I'm not sure about telling the auditor "I'm not concerned with this
requirement because I decided so. XOXO".<br>
<br>
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?<br>
</body>
</html>