[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation

[Erwann Abalea]

Bonjour,

Le 19/09/2014 01:40, Brian Smith a écrit :
> On Thu, Sep 18, 2014 at 3:09 PM, Erwann Abalea
> <erwann.abalea at opentrust.com> wrote:
[...]
>> Section 3.2 deals with objects stored at log level, after they have been
>> signed by the log.
> <snip>
>
>> That's confusing, but since it is said that the "tbs_certificate" is
>> without the poison extension, and the CA MUST include this extension,
>> then this "tbs_certificate" does NOT reflect what the CA produced and
>> sent. Thus, this "tbs_certificate" is modified by the log (modifications
>> listed: issuer name and AKI), and the result is then signed by the log.
> Thanks for explaining that. It is helpful to know why people disagree.
> However, I still think I am right. I agree it is strange that section
> 3.2 doesn't say anything about the poison extension.

It does, in the sniped text.

>   But, I think it
> is a big leap to infer from that omission that the precertifcate's
> issuer and AKI must be the subject and SKI of the precertificate
> signing certificate.

It's ambiguous, for sure.

> Section 3.1 explains how to construct a precertificate's
> tbsCertificate from the tbsCertificate of the final certificate:
>
>     [...] The Precertificate is
>     constructed from the certificate to be issued by adding a special
>     critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose
>     extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the
>     end-entity TBSCertificate (this extension is to ensure that the
>     Precertificate cannot be validated by a standard X.509v3 client) and
>     signing the resulting TBSCertificate [RFC5280] with either
>
>     o  a special-purpose (CA:true, Extended Key Usage: Certificate
>        Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
>        Certificate. [...]
>
>      o  or, the CA certificate that will sign the final certificate.
>
> Notice that it mentions inserting the poison extension but it doesn't
> mention changing the AKI or issuer fields.

The poison extension is added so that the Precertificate, as issued by 
the CA, doesn't fall into the scope of the BR.
AKI and issuer fields are not mentioned because they have no special 
treatment by the CA. That is, the AKI points to the Precert Signing 
Certificate's SKI, and issuer is equal to Precert Signing Certificate's 
subject name.

> Further, nowhere does it indicate that the Precertificate Signing
> Certificate must have a different subject name or a different public
> key from the issuing CA certificate.

If the Precert Signing Certificate has the same subject name as the 
final CA certificate, then it's the same CA (with or without a different 
key).
Are you suggesting that this RFC should explicitely distinguish all the 
following cases (variations on subject name and key):
  - the Precertificate Signing Certificate is another certificate 
belonging to the final CA (same subject name), with the same key, and 
special purpose EKU
  - the PSC is another certificate belonging to the final CA, with a 
different key, and special purpose EKU
  - the PSC is a different CA (different name), special purpose EKU, 
directly issued by the final CA, with the same key as the final CA
  - the PSC is a different CA, special purpose EKU, directly issued by 
the final CA, with a different key
  - the PSC is the exact same final CA certificate

and reject the first 3?

> It would be very strange for the log to take a precertificate and
> modify its AKI and issuer name before logging it. Remember that the
> purpose of the log is to accurately record the output of the CAs. Any
> substitutions of the CAs output is counter to that purpose.

True. But it's what it does already (with the poison extension).
The AKI and issuer changes are necessary so the browser can build 
"something" signed by the log out of the certificate sent by the web 
server, and verify this signature (which is present in the SCT extension 
of the final certificate).

The logic:
  - CA produces a PreCert by including the poison extension
  - log extracts the TBSCertificate from the PreCert, removes the poison 
extension, and changes issuer and AKI if the PreCert was issued under a 
PreCert Signing Certificate => the PreCert and what is signed by the log 
are now different (signature and signatureAlgorithm have been removed, 
poison extension has been removed, issuer and AKI has been changed if 
PreCert issuer is different than the final CA)
  - log signs this result and sends the SCT back to the publisher
  - CA includes a set of SCT in the final certificate

Later:
  - the browser receives the final certificate
  - it extracts the TBSCertificate from it, takes the content of the SCT 
extension apart (keeps it for future use) and removes the extension
  - it verifies the resulting modified TBSCertificate against the 
signatures contained in the SCT extension it kept => if issuer and AKI 
weren't changed by the log, this verification would always fail if 
PreCert SC is different than final CA, and the browser can't know what 
these values were before modifications

> (Also, it is a terrible mistake that the precertificate signing
> certificate has basicoConstraints.cA == true. Implementations will now
> Precertificate Signing Certificates to issue certificates, not just
> precertificates, and also this interacts poorly with path length
> constraints on the issuing CA.)

This decision has impacts on what to do regarding the CABF or BR rules. 
Because these are not technically-constrained CAs as defined by BR, and 
are CAs under a public root. So they have other duties than just 
generate PreCerts.