[Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT

["Doug Beattie" <[e-mail]>]

Those CAs that want to use a Precertificate Signing Certificate need to
follow a more complicated process for signing and I don't think it's well
documented or thought out.

1) What chain does the Precertificate Signing Certificate need to be issued
under? 

RFC 6962 states: "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 (note that the log *may* relax standard validation rules to
allow this, so long as the issued certificate will be valid)"

Point 1.1: Normally CAs have path length set to 0, so CAs are not able to
issue CA certificates under them, and this looks like a CA certificate
because CA:TRUE.  

Point 1.2: The also RFC States: "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. "

This makes the Precertificate Signing Certificate look even less like a CA
certificate.  How do we convince a compliant/certified CA application to use
an Issuer DN other than the one that was used to sign the certificate?
Compliant CAs won't.

Point 1.3: The "may" above needs to be MUST, or validation will fail due to
the Issuer DN not matching what was posted.

Recommendation 1: At a minimum, remove CA:true from the Certificate Signing
Certificate profile.  Ideally the profile should be updated to be more like
a Document/Code signing certificate than a CA certificate. 

The signed TBScertificates posted to the log specifies the final
certificate's issuer DN, but the cert chain for the Precertificate Signing
Certificate is supplied so the CT log can validate that chain using relaxed
validation rules.  What's the relationship between the hierarchy of the
Precertificate Signing Certificate and the final certificate? I struggle to
find any relationship except they both chain to publicly trusted roots.  Is
that the intent of the RFC?

Recommendation 2: The Precertificate Signing Certificate used by a CA may be
issued under any one of its roots and be used to sign all entries to be
posted to the log.  Unless there is a requirement to validate that the
chains use the same root/hierarchy, there is no reason to require that.

2) Does the certificate serial number need to be the same in the
TBScertificate and the final certificate?

CAs that randomly generate serial numbers during issuance can't pre-generate
serial numbers to be used in the TBScertificate, then subsequently in the
final certificate. Is the serial number *that* important that it MUST be
included in the SCT?  The issuer for the TBScertificate does not match the
value of the certificate that signed it, so what's the point of the serial
number?  The CN, SAN, signing algorithms and keys are the most critical
components.  Can we limit the SCT to these values?

Recommendation 3: Don't require that the TBScertificate and the final
certificate contain the same serial number.


Summary: The CT Log validation rules need to be clearly defined so that the
CAs can post valid entries to the CT logs.  

* Currently I don't believe that the RFC is implementable by compliant CAs
that want to use Precertificate Signing Certificate.  
* Compliant CAs won't issue certificates with duplicate issuer DNs and
serial numbers, so that model is also broken - the Precertificate Signing
Certificate needs to be a non-CA certificate.  
* CAs that randomly generate serial numbers during issuance can't
pre-generate serial numbers to be used in the TBScertificate, then
subsequently in the final certificate, so serial numbers need to be removed
from the content hashed by the SCT.

Doug