[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation

Brian Smith brian at briansmith.org
Fri Sep 19 18:53:24 UTC 2014

On Fri, Sep 19, 2014 at 1:23 AM, Rob Stradling <rob.stradling at comodo.com> wrote:
> On 19/09/14 07:04, Erwann Abalea wrote:
> <snip>
>> 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
> Thanks Erwann.  This logic is exactly correct.  The test cases in the
> certificate-transparency.org code demonstrate that this is correct.

I am OK with going with your interpretation, if that is what Google
and the CAs implemented, since there's practically no alternative.
But, then, I do not think it makes sense to site RFC6962 with respect
to these technical details, because at best RFC6962 is unclear. In
particular, the test cases in the certificate-transparency.org code
are not part of RFC6962.

> Brian's error (which I shared until Emilia corrected me privately last week,
> and which you also shared until I corrected you on TRANS earlier this week)


> Since we've each independently reached the same wrong conclusion on this
> issue and have needed to be corrected, I think we can safely say that
> relevant text in RFC6962 is insufficiently clear!

I don't think the way that you, Erwann, Ryan (apparently), and I read
RFC6962 is unreasonable, even if it wasn't what the authors intended.
The certificate-transparency.org code could be wrong. It is worth
looking at other, independent implementations of CT to see what they
implemented. Even if they all agreed, I think it is dangerous to have
implementations outvote the text of what the RFC says. (I remember
when Mozilla implemented HKDF in multiple products, and my
implementation failed to interoperate with three others. But,
ultimately, the other three were wrong, according to the RFC. It would
have been a mistake for us to say the RFC is wrong based on the
results of the three bad implementations.)

Again, my point is that if the BRs are to be changed to accomodate
that, then I think it is important to restrict it as much as possible.
And, that requires knowing the exact syntax and contents of


More information about the Public mailing list