Re: [Trans] IETF 90 scheduling

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 <melinda.shore@gmail.com>:

> 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
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>