Original text:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as CDNs or remote data centers.  This allows server 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 on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), 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, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del>  To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the peer.  The secret key used to sign a credential corresponds to the <del> public key of the peer's X.509 end-entity certificate. </del>  A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways: these two mechanisms with TLS 1.3 RFC8446. These two mechanisms can be complementary.  A server could use <del> 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 <del> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del>  3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del>  structure: Relative time in seconds from the beginning of the delegation 3.1. <del> This document defines the following extension code point. </del>  3.1.1.

Reviewer comments:
Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).

Revised text:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low-  <ins> trust zones such as Content Delivery Network (CDNs) or remote data centers.  This allows server 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 on an external CA for such short- lived credentials.  In Online Certiicate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), 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, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the peer.  The secret key used to sign a credential corresponds to the  <ins> public key of the peer's X.509 end-entity certificate RFC5280. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways: these two mechanisms with TLS 1.3 RFC8446. These two mechanisms can be complementary.  A server could use  <ins> credentials for clients that support them, while using KEYLESS to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above  <ins> by automating certificate issuance, e.g., with Automated Certificate Managmeent Encvironment (ACME) RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the  <ins> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation 3.1.  <ins> This document defines the following TLS extension code point. </ins> 3.1.1.