[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation
Erwann Abalea
erwann.abalea at opentrust.com
Thu Sep 18 22:09:54 UTC 2014
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.
More information about the Public
mailing list