All that is really needed is a well-defined and easily reversible transformation of the serial number that can be applied to verify the proof.
As issuing non-randomized serial numbers is no longer an acceptable practice for CAs, it could be as simple as: certSerialNum = preCertSerialNum++; -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Tuesday, July 01, 2014 10:35 AM To: [email protected] Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT Ben, > ... > As you point out, the log can relax validation rules, which deals with > this problem (and we do, indeed, do that in our implementation). My comments noted that relaxing rules in an unspecified fashion creates potential problems for those submitting pre-certs. The specific changes needed to enable acceptance oif pre-certs need to be spelled out. > ... >> 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. I understand the desire to have the serial number be submitted as part of the pre-cert, but the problem raised by Doug is a valid one that cannot be ignored. >> Recommendation 3: Don't require that the TBScertificate and the final >> certificate contain the same serial number. > See above. see my comment above as well :-). > >> 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. The burden on fixing it is not on Doug; it is on the authors of the doc! > >> * 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. Ben, it's not reasonable to tell CAs that their extant serial number management mechanism has to change to accommodate the CT design. It is the responsibility of the CT designers to figure out how to accommodate valid CA operation models. The RFC that forms the basis of the WG effort was experimental; there is no presumption that a final, standards track doc will be the same in every detail. The pre-cert serial number problem may be one aspect of the design that needs to change. Steve _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
