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

[Ryan Sleevi]

On Sep 18, 2014 1:25 PM, "Erwann Abalea" <erwann.abalea at opentrust.com>
wrote:
>
> 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>
wrote:
>> >
>> > Le 18/09/2014 04:01, 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.
>

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.

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

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.

Their distinguishing feature comes from how that inner SEQUENCE is
structured.

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.

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.

The poison extension - a structural facet of a PreCert - is as
distinguishing to RFC5280 as a different ASN.1 structure. It makes them
different.

>
>> >> 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)
>

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 )

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

Hopefully the above makes it clearer.

>
>> 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?
>

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140918/48e26cd4/attachment-0001.html