[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation

[Rob Stradling]

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.

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) is in thinking that the AKI and Issuer modifications are done 
by the CA and are reflected in the Precertificate.  They're not. 
They're done by the log when it transforms the Precertificate's 
TBSCertificate into the "modified TBSCertificate".
(When a Precertificate Signing Certificate signs a Precertificate, that 
Precertificate's Issuer and AKI match the Precertificate Signing 
Certificate's Subject and SKI).

When verifying a precert_entry SCT, a TLS Client needs to reconstruct 
the "modified TBSCertificate", *NOT* the Precertificate's TBSCertificate.

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!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online