Hi Eran, Thanks (again) for your insight.
Do you think we’d need a 6962-ter to accommodate STAR? Or could we specify a different SCT format and processing rules for STAR-like certificates in the framework defined by 6962-bis? Cheers On 08/11/2017, 00:54, "Eran Messeri" <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
