Hi, This draft is very well written, I mainly have high level comments:
- I think there is an overlap between draft-ietf-tls-subcerts and draft-tschofenig-tls-cwt, which also propose a form of delegated credentials. CWT is an existing format, that draft supports delegation on both the client and server side, and does not require the certificate to be sent. On the other hand the CWT draft lacks a lot of the security considerations of the DC draft. Could these ideas be combined? Having two delegated credential formats in TLS does not seem optimal unless the belief is that they serve very different use cases. - Only supporting delegated credentials for the server seems very limiting. What if I have a virtualized TLS client talking to a virtualized TLS server? I see that this was recently added as issue #24, I support solving issue #24. - Abstract: "without breaking compatibility with clients that do not support this specification." I do not see how... The deployment scenario is that the CDN or remote data center has the DC private key, but not the certificate private key (as it is not trusted enough). LURK/Keyless SSL clearly benefits from DC, but while LURK/Keyless SSL can be used without DC, use of DC with any clients not supporting DC more or less requires LURK/Keyless SSL. Not giving guidance on how to do the interface between Front-end and Back-end seems like a bad idea. I think the text about compatibility need to be changed. I think it needs to be clear that until 100 % of clients support DC, LURK/Keyless SSL is a requirement. - Section 1 - Could add "The server operator can only use validity periods supported by the CA" to the examples as that is one of the benefits of DC highlighted below. - Section 3.1 "if the extension is not present, the server MUST NOT send a delegated credential." As often requested by Jim Schaad, could you formulate this as a positive sentence instead. What should the server do in this case, terminate the connection? Use LURK? Security considerations: - "TLS private key" is not defined and in fact TLS uses many different private keys. - Add "The extension creates an unencrypted signal that might be used to identify which clients support delegated credentials." (text borrowed from the sic extension) Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
