<p dir="ltr"><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>
> Bonsoir,<br>
><br>
> Le 18/09/2014 20:53, Ryan Sleevi a écrit :<br>
>><br>
>><br>
>> On Sep 18, 2014 11:43 AM, "Erwann Abalea" <<a href="mailto:erwann.abalea@opentrust.com">erwann.abalea@opentrust.com</a>> wrote:<br>
>> ><br>
>> > Le 18/09/2014 04:01, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> a écrit :<br>
>><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>
>><br>
>> 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.<br>
><br>
><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>
></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>
<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>
<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>
<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>
<p dir="ltr">><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>
>> ><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>
>> ><br>
>><br>
>> As we discussed, there is quite a bit of 'open discussion' on what RFC5280 compliance means.<br>
>><br>
>> 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).<br>
><br>
><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>
></p>
<p dir="ltr">That's exactly the point. It DOESN'T say a CA can't use the key to sign any other object or arbitrary data. Neither do the BRs, but we all assume the intent (want to ballot to make it explicit? :D )</p>
<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>
<p dir="ltr">><br>
>> 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.<br>
>><br>
>> ><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>
>><br>
>> 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>
><br>
><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>
></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>