Hi Lanlan, Thanks for this: it'd be great to bring CT enforcement to more clients and in particular DNS.
I'm not sure this is the right layer though. The most natural approach would be to add support for SCT checking in the trust store and certificate verifier itself, whether that's owned by the application (like many browsers) or the system. This requires one to maintain a list of trusted logs not to dissimilar from maintaining a list of trusted roots (although the turnover of the former is higher). Each root in the trust store can be marked to require SCTs for their leaves, and ideally they're required for all. If there are resolvers without SCTs in their leaves (are there any today?), then an extra signal could be useful. I'm not read into RFC9606, but from a quick glance it seems that that channel is not typically authenticated, and an attacker could just strip it. Some comments: - RFC 9162 is not deployed, and there is no indication it will be. The CT ecosystem is on RFC 6962 with some changes on top coming in (StaticCT). - The signed_certificate_timestamp extension (6962's transparency_info) is only rarely used. We do, but in practice embedded SCTs are the standard way to deliver them. Best, Bas
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
