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

[Erwann Abalea]

Bonsoir,

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.
The whole paragraph is:
-----
    "tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280])
    component of the Precertificate -- that is, without the signature and
    the poison extension.  If the Precertificate is not signed with the
    CA certificate that will issue the final certificate, then the
    TBSCertificate also has its issuer changed to that of the CA that
    will issue the final certificate.  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.
    Also note that since the TBSCertificate contains an
    AlgorithmIdentifier that must match both the Precertificate signature
    algorithm and final certificate signature algorithm, they must be
    signed with the same algorithm and parameters.  If the Precertificate
    is issued using a Precertificate Signing Certificate and an Authority
    Key Identifier extension is present in the TBSCertificate, the
    corresponding extension must also be present in the Precertificate
    Signing Certificate -- in this case, the TBSCertificate also has its
    Authority Key Identifier changed to match the final issuer.
-----

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.