Hi all, Per my reading of rfc 6962, it seems that SCT (in that RFC) are only produced for Leaf certificates. 6962-bis introduce a possibility that intermediates certs are also logged and SCT produced for them. (Section 3.2.3. Using a Name-Constrained Intermediate CA)
This raised a couple questions: - How are SCTs for intermediates provided to TLS clients ? Can they be provided through the TLS extension? Through the OCSP response? Embedded in the leaf cert ? Or only embedded in the intermediate cert ? - If intermediates SCTs can be provided by the same channel as SCTs for leaf certs, how is the TLS client supposed to know which cert correspond to a given SCT? Should the TLS client just try all the certs in the chain until the signature match ? - afaict, there is no data in the SCT that bind it to the cert, beside the signature. - If I, a TLS client, have SCTs for both leafs and certs, assuming I figure out which one is for which, what kind of policies are we expecting the TLS client to apply. I realize this is probably out of scope for the RFC, but I'm curious what the expectation are here. In both 6962, and 6962-bis, the TLS client behavior is very shortly described in section 5.2. TLS Clients. It basically boils down to one sentence "they (TLS clients) should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature," In 6962-bis, section 3.2.3, there is some language about what kind of intermediate CA are acceptable to log. It seems that at least some logs clients should also check that intermediates CA with SCTs do obey those rules. I'm not sure if it's the role of TLS clients, Auditors, Monitors or all of them to do so. Thanks -- Fabrice _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
