Re: [Trans] Precertificate format

[Matt Palmer <[e-mail]>]

On Mon, Sep 08, 2014 at 04:24:26PM -0700, Rick Andrews wrote:
> > The CA may use a Precertificate Signing Certificate to sign the
> > Precertificate, and then sign the final certificate with the production
> > CA certificate.  Then, there would be no duplicate serial number issues.
> 
> Brian, even if the CA uses a Precert signing cert, the precert's issuer
> name has to be that of the ultimate issuer, and the serial number has to
> be that of the ultimate certificate, so I don't think that solves the
> problem.

As the Wikipedians say, "Citation Needed".  My understanding is that there
is no restriction on the contents of the issuer certificate of a precert,
other than:

    a special-purpose (CA:true, Extended Key Usage: Certificate
    Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
    Certificate.  The Precertificate Signing Certificate MUST be directly
    certified by the (root or intermediate) CA certificate that will
    ultimately sign the end-entity TBSCertificate yielding the end-entity
    certificate

That's from RFC6962 s3.1, and the wording is identical in rfc6962-bis.xml in
the github repo at the time of writing.

Of all the mentions of "issuer" in 6962, the closest relevant mention I can
find is in s3.2, "Structure of the Signed Certificate Timestamp", in the
paragraph discussing what `tbs_certificate` is, which talks (rather densely)
about how precerts differ from regular certs, and how the TBSCertificate
structure's issuer and AKI extension need to be those of the final
certificate issuer, not the precert issuer.

This variation between the issuer listed in the precert and the *actual*
issuer of the precert would potentially be a problem, if the usual chain
verification methods were employed, but it does mention elsewhere in 6962
(s3.1, para 4) that normal X.509 verification rules "may be relaxed" to
accommodate this sort of situation.  This is reasonable because the chain
verification is for spam prevention, rather than for information security.

For my log implementation, I've just made sure that the signature of the
cert was made by the public key in the next cert up the chain.  I'm not
looking at revocation, notBefore/notAfter, issuer/subject matching, or
anything else of that nature

Nobody other than logs need to verify the chain of the precert, either,
because browsers can verify the signature for the precert and then compare
the contents of the precert (from the log) and the presented cert and make
sure those details match.

- Matt