One way for a single SCT to be valid for multiple certificates is to omit the fields that change from the data covered by the SCT's signature. For short-lived certificates this would (likely) be the serial number, notBefore and notAfter dates.
This means there's no need to re-request an SCT each time a new short-lived certificate is minted, and the SCT covers all key fields in the certificate's TBSCertificate structure (Subject Alternative Names, key, etc). The drawback is that without a serial number (1) it is not possible to verify CAs don't violate the unique serial number requirement (effectively reducing auditing capabilities) (2) mis-issued certificates can't be revoked using the usual means. Note that such a mechanism cannot be implemented either using 6962 or 6962-bis: Both documents mandate that the SCT covers all fields in the TBSCertificate (at least). But, if the design was changed to exclude some fields, it seems to me that this solution would otherwise be compatible with the rest of the CT protocol. On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore <[email protected]> wrote: > The question of how to log short-lived certificates is something > that's been coming up more frequently recently, and it's > independent (mostly) of the issuance mechanism. I think we've > got time to discuss it during the session at IETF 100, and > it would be helpful if there's a specific proposal to use as > a starting point. Will the folks working on this be > at the meeting? > > Melinda > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
