<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Bonjour,<br>
<br>
Le 19/09/2014 01:38, Ryan Sleevi a écrit :<br>
</div>
<blockquote
cite="mid:CACvaWvb2Ps5-ai2E+ULfHUDkuXApojzUgxNxSrjWzwL8ENoE0Q@mail.gmail.com"
type="cite">
<p dir="ltr">
On Sep 18, 2014 4:13 PM, "Erwann Abalea" <<a
moz-do-not-send="true"
href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>>
wrote:<br>
><br>
> Le 18/09/2014 22:59, Ryan Sleevi a écrit :<br>
>><br>
>> 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>
>> 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>
> Their syntax, yes.<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>
> 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>
</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>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CACvaWvb2Ps5-ai2E+ULfHUDkuXApojzUgxNxSrjWzwL8ENoE0Q@mail.gmail.com"
type="cite">> 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>
<p dir="ltr">
> 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>
</blockquote>
<br>
There's a hierarchy.<br>
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.<br>
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.<br>
<br>
Rephrasing.<br>
Among all possible stream of octets, some of them form X.509
certificates.<br>
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.<br>
<br>
[...]<br>
<blockquote
cite="mid:CACvaWvb2Ps5-ai2E+ULfHUDkuXApojzUgxNxSrjWzwL8ENoE0Q@mail.gmail.com"
type="cite">
<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 :)<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>
</blockquote>
<br>
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).<br>
<br>
<blockquote
cite="mid:CACvaWvb2Ps5-ai2E+ULfHUDkuXApojzUgxNxSrjWzwL8ENoE0Q@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
Rephrasing.<br>
<br>
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).<br>
<br>
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):<br>
-----<br>
[...]<br>
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.<br>
<br>
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. <br>
<br>
Proposed Solution<br>
<br>
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. <br>
-----<br>
<br>
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?<br>
Either admit that we're violating some RFC5280 requirements and ask
for an exemption, or don't ask for anything.<br>
<br>
<br>
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.<br>
</body>
</html>