Hi, Some questions, based on draft-05:
(1) Is there going to be a DNS-based protocol for retrieving audit proofs? (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and SupplementalData mechanisms used to convey the SCT, instead of defining a new TLS Extension? (RFC 5878 is an Experimental-track TLS Extension; CT adds a new extension value to it to signal that an SCT is included in an RFC 4680 SupplementalData handshake message; this seems more complex than just putting the SCT directly in a TLS Extension). (3) Some things about "precertificates" are unclear to me, in draft-05: - If the precert is signed by the "CA certificate that will sign the final certificate", as described in the second bullet in 3.1, does this CA cert also need to contain the "Certificate Transparency" EKU extension from the first bullet? - In the SCT for a precertificate, what exactly does the log sign? Is it the TBSCertificate including the poison extension, or is the log expected to remove the poison extension prior to signing? - How exactly does a TLS client verify an SCT for a precert? Does the client need to remove the SCTs and recalculate the original TBSCertificate's ASN.1 to verify? - Related to previous: why is it necessary for SCTs and MerkleTreeLeafs to have different cases for precerts and certs? Could the signature be calculated on a "normalized" form of the TBSCertificate which is the same for certs and precerts (i.e. the TBSCertificate with poison and SCT extensions removed?) (4) Why is the SCT's timestamp and CtExtensions included in the MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert) leaves instead of hash(SCT fields), then the audit path mechanism could be deployed earlier / independently from SCTs, i.e. browsers could retrieve and check audit paths for certs regardless of whether the TLS server had presented an SCT. Perhaps CT doesn't envision that use case, but it seems potentially useful. So I'm wondering if it might be worth decoupling the SCTs from the merkle trees to provide more deployment flexibility. Trevor _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
