<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Bonsoir,<br>
<br>
Le 18/09/2014 20:53, Ryan Sleevi a écrit :<br>
</div>
<blockquote
cite="mid:CACvaWvZCL9vGtj_BmvbLBz67Bf78x5oQkP6Wyk3exYVKqSgDDA@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Sep 18, 2014 11:43 AM, "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 04:01, <a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
a écrit :<br>
<br>
[...]<br>
>> However, this creates a dilemma – both the precert and
the production cert will be issued from the same sub-CA (the
entire issuing chain will be the same), and both will have the
same Serial Number – something necessary for CT, but not
permitted under RFC 5280. To remedy this, the precert will have
a so-called “poison extension” to tell applications it is not to
be used as a real SSL cert. The use of the poison extension may
or may the precerts do not violate RFC 5280, but this is not
clear.<br>
><br>
> It is clear that the poison extension has no impact of
X.509/RFC5280 violation. The uniqueness of
issuerName+serialNumber does NOT depend on any other factor or
element.<br>
</p>
<p dir="ltr">Respectfully, I'd disagree. A PreCert is NOT a cert
intended to comply with RFC5280. It's potentially an X.509 cert,
yes, but you know very well that not every X.509 encoded cert is
an RFC5280 cert.</p>
</blockquote>
<br>
You're right, compliance to X.509 does not imply compliance to
RFC5280. But this uniqueness isn't brought by RFC5280. Taken from
X.509:<br>
<br>
3.4.14 certificate serial number: An integer value, unique within
the issuing authority, which is unambiguously associated with a
certificate issued by that authority.<br>
<br>
Later, section 7:<br>
serialNumber is an integer assigned by the CA to each certificate.
The value of serialNumber shall be unique for each certificate
issued by a given CA (i.e., the issuer name and serial number
identify a unique certificate).<br>
<br>
<br>
"A PreCert is NOT a cert intended to comply with RFC5280." is a
dangerous argument. What if a CA caught while producing non
{BR,RFC5280} compliant certificates replies "these certificates were
not intended to comply with {BR,RFC5280}"? Would that be an
acceptable answer? We've already had this same question about
Qualified certificates containing anyExtendedKeyUsage in EKU, or no
EKU at all, and the "intention" that drove the production of such
certificates isn't an acceptable argument for their BR
non-compliance.<br>
<br>
<blockquote
cite="mid:CACvaWvZCL9vGtj_BmvbLBz67Bf78x5oQkP6Wyk3exYVKqSgDDA@mail.gmail.com"
type="cite">
<p dir="ltr">
>> 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>
><br>
> That's wrong. The requirements to comply with RFC5280 will
be violated by CAs that choose Option 1. That's why {you, they,
we}'re asking for an exemption.<br>
></p>
<p dir="ltr">As we discussed, there is quite a bit of 'open
discussion' on what RFC5280 compliance means.</p>
<p dir="ltr">I don't think anyone would say a CA violates RFC5280
when they sign an OCSPResponse (RFC2560), which is equivalent in
spirit and intent to signing a PreCertificate (RFC6962).</p>
</blockquote>
<br>
How could producing an OCSPResponse violate RFC5280? Where is it
stated in RFC5280 that a CA can't sign an OCSPResponse? (or any
other other object)<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>
<blockquote
cite="mid:CACvaWvZCL9vGtj_BmvbLBz67Bf78x5oQkP6Wyk3exYVKqSgDDA@mail.gmail.com"
type="cite">
<p dir="ltr">However, rather than debate this (as we have), it
seems quite good to do what is being done here - which is being
explicit about that.</p>
<p dir="ltr">><br>
>> <br>
>><br>
>> Proposed Solution<br>
>><br>
>> <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>
> I fail to see where the limit is stated.<br>
><br>
> For the previous exemption (non critical NC extension), the
exception to RFC5280 runs "until the Name Constraints extension
is supported by Application Software Suppliers whose software is
used by a substantial portion of Relying Parties worldwide."<br>
><br>
> I'd like to see the same kind of limit expressed.<br>
> Maybe something like "until a successor of RFC6962 defines
a structure that doesn't violate RFC5280 constraints"? We'll
have to deal with then-legacy software, again.<br>
><br>
</p>
<p dir="ltr">I fail to see the value/concern here, even if we
accept your position that it's a violation, so I'm hoping you
can explain more.<br>
</p>
</blockquote>
<br>
I'm not a big fan of giving permanent exceptions to adopted
standards because a software supplier doesn't support some part of
this standard (we all recognize Apple and NameConstraints), so the
exception isn't permanent but limited in time to the evolution of
this software supplier.<br>
<br>
I'm a lesser fan of giving a permanent exception to adopted
standards because an experimental idea arises from another software
supplier that conflicts with this standard because this violation
wasn't forseen. (please don't take this as a wrong indication of
what I think of this experimental idea)<br>
<br>
Ongoing discussions on the trans mailing list about format and
content of PreCerts clearly indicate that the current format isn't
satisfying and needs to change.<br>
<br>
If there's no violation, what's the purpose of this ballot?<br>
<br>
</body>
</html>