Sorry for the delay. On 4 June 2014 20:52, Doug Beattie <[email protected]> wrote: > > 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.
As you point out, the log can relax validation rules, which deals with this problem (and we do, indeed, do that in our implementation). > 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. I agree that this could be troublesome, though no-one has reported it as a blocker for them. If it turns out that no-one uses this option, perhaps we should drop it? > Point 1.3: The "may" above needs to be MUST, or validation will fail due to > the Issuer DN not matching what was posted. I guess so. File a bug? > 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. I am not sure I understand how this helps? The path length constraint is a constraint on the length of the path, surely - regardless of what bits are set in certs in the path? > 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? Yes. The intent is for a CA to state its intention to issue a particular certificate. > 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. The requirement is that we can track down the issuer and that we can reconstruct the precert from the cert. Its not clear to me that this meets that requirement. > 2) Does the certificate serial number need to be the same in the > TBScertificate and the final certificate? Yes. > 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? Serial numbers are used for revocation, so we need to know what they are. > Recommendation 3: Don't require that the TBScertificate and the final > certificate contain the same serial number. See above. > 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. This may be so, but I don't think you've found a way to fix this, if it is so. > * 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. Surely a different CA cert is equivalent to a different CA, and therefore the issuer DN/serial is _not_ a duplicate? > * 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. See above. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
