The draft looks good. I have a few minor nits and suggestions. Section 3, Fourth bullet: s/TLS hadshake/TLS handshake
Section 3, Fourth bullet: To eliminate possible confusion, what is meant by "certificate’s working key" could be defined more precisely. Section 3.2, Last paragraph: s/Automated Certificate Managmeent Encvironment/Automated Certificate Management Environment Section 3.2, Last paragraph: "It is possible to address the short-lived certificate concerns above ..." seems to refer to text in the Introduction. It is a bit far for use of "above" rather than indicating the particular section. Even better would be to add some text regarding the concerns to Section 3 or 3.1. Section 4: The definition of "valid_time" could mention that the value must not exceed 7 days. Section 4: The phrase "Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials." could be improved by adding at least one way that the minimized semantics mitigate such attacks. Section 6.1: The term "TLS private key" is used for the first time here. In the rest of the document we see the term "delegated private key"; are these the same? Section 6.1: The following phrase describes an important condition for using delegated credentials: "Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between parties that have some trust relationship with each other." I think it is important enough to include a similar statement when describing the solution in Section 3. Section 6.4: s/cache the certificate chain an re-validate it/cache the certificate chain and re-validate it Best regards, Jonathan _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
