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

[Brian Smith]

On Thu, Sep 18, 2014 at 3:09 PM, Erwann Abalea
<erwann.abalea at opentrust.com> wrote:
> Le 18/09/2014 23:04, Brian Smith a écrit :
>> On Thu, Sep 18, 2014 at 2:08 AM, Rob Stradling <rob.stradling at comodo.com> wrote:
>>> On 18/09/14 04:55, Brian Smith wrote:
>>> [...]
>>>
>>>> Note that the use or non-use of a precertificate signing certificate has
>>>> no bearing (IIUC) on whether the precertificate would be a duplicate of
>>>> the final certificate, because the difference between Option 1 and
>>>> Option 2 doesn't affect the issuer and serial number fields of the
>>>> precertificate.
>>>
>>> Not quite.  The Precertificate's serial number is indeed the same with both
>>> options.  However, the Precertificate's issuer name and AKI are different,
>>> depending on whether option 1 or 2 is used.
>> No. Read section 3.2 very carefully; in particular, note all the
>> mentions of "final certificate" and "Note that it is also possible to
>> reconstruct this TBSCertificate from the final certificate by
>> extracting the TBSCertificate from it and deleting the SCT extension."
>
> 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. 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.

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.

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.

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.

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

Cheers,
Brian