Hello TLS WG, RFC6962 only talks about support of CT to verify the server certificates, however while working on zero trust services that require MTLS for each connection, I realized that enabling CT for client certificates can make the TLS handshakes with Mutual TLS more secure. (I don't want to go into details of how CT can make it more secure as those benefits are already mentioned in RFC6962).
Here is how I think it can be supported and I am looking for your feedback on this. Approach 1: If a client has sent the signed_certificate_timestamp [RFC6962] in the client hello with empty data and if the server is configured to only accept the client certificates with a CT log, server will send the signed_certificate_timestamp extension with empty extension_data in the Certificate Request [RFC 8446 section 4.3.2] message to indicate that it requires certificate's Signature Timestamp as a proof that the certificate is logged with a CT server. On the client side, If it's certificate does not have an SCT extension, then the client can either be configured with a static SCT data or it can be configured to fetch it from an external server. The client can use the SCT data to add a signed_certificate_timestamp extension in the CertificateEntry in the Certificate message [RFC8446 Section 4.4.2 along with its certificate. Approach 2: Another way could be the CA of the client's certificate can send the signed_certificate_timestamp extension in the OCSP response to the server indicating that client has a CT log along with the log. Server can enforce both CT and Revocation checks at the same time. Please let me know your opinion on this and do you think there is some merit to standardize this. Thanks for paying attention to my email. Regards, Mohit Sahni _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
