Original text:
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In contrast to OCSP stapling, in which an operator could choose to talk to the CA frequently to obtain stapled responses, failure to fetch an OCSP stapled response results only in degraded performance, however </del>  failure to fetch a potentially large number of short lived certificates would result in the service not being available which creates greater operational risk. A public key (with its associated algorithm) The signature on the credential indicates a delegation from the <del> certificate which is issued to the TLS server operator.  The key pair used to sign a credential is presumed to be one whose public key is contained in an X.509 certificate that associates one or more names to the credential. </del>  A TLS handshake that uses credentials differs from a normal handshake in a few important ways: signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 <del> which permits use of delegated credentials.  Clients MUST NOT accept </del>  delegated credentials associated with certificates without this extension. credentials, which rely on a cryptographic binding between the entire certificate and the Delegated credential, cannot. <del> Delegated credentials allow signed messages to be bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </del>  2.2. figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. <del> These two classes of mechanism can be complementary.  A server could use credentials for clients that support them, while using LURK to </del>  support legacy clients. It is possible to address the short-lived certificate concerns above procedures.  It then takes the following additional steps: Verify that the current time is within the validity interval of <del> the credential. </del>  Use the public key in the server's end-entity certificate to verify the signature on the credential. provided in the handshake.  That is the CertificateVerify message in TLS 1.3 or ServerKeyExchange in 1.2. <del> Verify that the certificate has the correct extensions that allow the use of Delegated credentials. </del>  <del> Clients that receive Delegated credentials that are valid for more than 7 days MUST terminate the connection with an "illegal_parameter" alert. </del>  4. DelegationUsage ::= BIT STRING { allowed (0) } <del> Conforming CAs MUST mark this extension as non-critical.  This would allow the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </del>  5.

Reviewer comments:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes

Revised text:
operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely  <ins> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, </ins> failure to fetch a potentially large number of short lived certificates would result in the service not being available which creates greater operational risk. A public key (with its associated algorithm) The signature on the credential indicates a delegation from the  <ins> certificate that is issued to the TLS server operator.  The secret key used to sign a credential is presumed to be one whose corresponding public key is contained in an X.509 certificate that associates one or more names to the credential. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways: signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509  <ins> that permits use of delegated credentials.  Clients MUST NOT accept </ins> delegated credentials associated with certificates without this extension. credentials, which rely on a cryptographic binding between the entire certificate and the Delegated credential, cannot.  <ins> Delegated credentials are bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </ins> 2.2. figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13.  <ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above procedures.  It then takes the following additional steps: Verify that the current time is within the validity interval of  <ins> the credential and that the credential's time to live is no more than 7 days. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential. provided in the handshake.  That is the CertificateVerify message in TLS 1.3 or ServerKeyExchange in 1.2.  <ins> Verify that the certificate has the DelegationUsage extension, which permits the use of Delegated credentials. </ins>  <ins> If one or more of these criteria are not met, then the Delegated credential is invalid.  Clients that receive Delegated credentials that are invalid MUST terminate the connection with an "illegal_parameter" alert. </ins> 4. DelegationUsage ::= BIT STRING { allowed (0) }  <ins> Conforming CAs MUST mark this extension as non-critical.  This allows the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </ins> 5.