Hi, I have actually two technical comments with the current specifications of CT:
#1 Log server identification Currently, if I am correct, the identity of the log server providing the SCT is based on its public key (in fact, the hash of it), which is also stored in the TLS client. As with the public key pinning mechanism (cf. draft-ietf-websec-key-pinning), I am afraid about a potential complexity (from a technical/business point of view) to add a new public key in the TLS client (e.g., web browser), to be able to set up/manage a new log server. So, I am wondering, instead (or in parallel) of using log server's public key as log server's ID, if that would be easier to use URI for new log servers deployment. #2 Interaction between TLSA RR and CT At first, from my point of view, using TLSA RR means "prevention" and using CT means "repression". Now, if I want only do "prevention", the current CT specifications will not allow me to do it. Indeed, as specified in Section 3, TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate, enforcing the use of CT by the TLS server. Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would relax this enforcement. I would appreciate any feedback from the WG regarding these comments. Thanks in advance for your replies. Best regards, JMC. 2014-04-22 0:35 GMT+02:00 Melinda Shore <[email protected]>: > We just received notification that working group session > scheduling for the July meeting is now open. This is a good > time to be thinking about what needs to be done between > now and then and how session time will be spent. Right now > my sense is that a single two-hour session will be more than > enough, but I'll hold off until we get a better sense of > what will need to be done during the session. > > Melinda > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
