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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
