[cabfpub] Ballot for limited exemption to RFC 5280 for CT implementation

Erwann Abalea erwann.abalea at opentrust.com
Thu Sep 18 13:25:39 MST 2014


Bonsoir,

Le 18/09/2014 20:53, Ryan Sleevi a écrit :
>
>
> On Sep 18, 2014 11:43 AM, "Erwann Abalea" <erwann.abalea at opentrust.com 
> <mailto:erwann.abalea at opentrust.com>> wrote:
> >
> > Le 18/09/2014 04:01, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> a écrit :
>
> [...]
> >> 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.
> >
> > 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.
>
> 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.
>

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:

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.

Later, section 7:
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).


"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.

> >> 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.
> >>
> >> 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.
> >
> >
> > 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.
> >
>
> As we discussed, there is quite a bit of 'open discussion' on what 
> RFC5280 compliance means.
>
> 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).
>

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)

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 
...".

> 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.
>
> >
> >>
> >>
> >> Proposed Solution
> >>
> >>
> >>
> >> 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.
> >
> >
> > I fail to see where the limit is stated.
> >
> > 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."
> >
> > I'd like to see the same kind of limit expressed.
> > 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.
> >
>
> 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.
>

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.

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)

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.

If there's no violation, what's the purpose of this ballot?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140918/e839bfc8/attachment.html 


More information about the Public mailing list