I've no real opinion on whether this draft is worth doing, because that depends on making an assessment about CWT and I keep bouncing off the C part. I guess that the point of the draft is to start that part of the discussion, which is a fine thing.
There are a few more mundane, mechanical issues I noted when reading the draft. This appears to be aimed at both TLS 1.2 and TLS 1.3. That should be made clearer. Supporting TLS 1.2 complicates the design. The mapping from CWT to TLS signature scheme (or signature algorithms in 1.2) needs to be clearer. Also, the interactions with the TLS 1.3 signature_algorithms_cert extension need some treatment. For some of what I think is being proposed, that requires the definition of new methods of producing CertificateVerify messages. The symmetric key stuff needs considerably more meat on it. How does the sender know what encryption schemes are used? Why use an encrypted key and not just a key identifier (or PSK for that matter)? Section 4 is interesting. It's good to see a treatment of this issue here. However, this is missing the piece where the server checks to see if it is willing to offer the identity it has been given via server_name. The use of a URI as an identity is new. It narrows the conception of server identity in a way that could be useful. However, it needs far more thorough a treatment than this text gives. Take a look at RFC 6125 if you want to get an appreciation for what thorough means in this context. Cheers, Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
