Change:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM

Discussion:
the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the <del> operator as a "delegated credential". </del> <ins> operator as a "delegated credential" or "DC". </ins> 1.1.

cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the <del> protocol is explicitly disallowed. </del> <ins> protocol is not allowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there

X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, <del> delegated credentials have very restricted semantics which should </del> <ins> delegated credentials have very restricted semantics that should </ins> not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process

entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm.  This prevents them from being used with other, unintended, signature algorithms. </del> <ins> algorithm that may be used to sign the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </ins> 2.2.

private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </del> <ins> 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

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 <del> APIs like ACME may be useful for provisioning credentials, within an </del> <ins> APIs like ACME may be useful for provisioning credentials within an </ins> operator network. 3.

The signature algorithm used to verify DelegatedCredential.signature. <del> The signature over the credential with the end-entity certificate's public key, using the scheme. </del> <ins> The delegation, a signature that binds the credential to the end- entity certificate's public key as specified below.  The signature scheme is specified by DelegatedCredential.algorithm. </ins> The signature of the DelegatedCredential is computed over the concatenation of:

this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. <del> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). </del> <ins> The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the TLS stack.  This has the advantage of avoiding changes to security-critical and often delicate PKI code. </ins> 3.1.

On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity <del> certificate to the server's expected identity following its normal procedures.  It also takes the following steps: </del> <ins> certificate to the server's expected identity in the usual way.  It also takes the following steps: </ins> Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more <del> than 7 days. </del> <ins> than 7 days.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements. </del> <ins> Verify that the end-entity certificate satisfies the conditions in certificate-requirements. </ins> Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm

limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the delegate credential expires, however they cannot create new delegated <del> credentials.  Thus delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </del> <ins> credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </ins> parties that have some trust relationship with each other.  The secrecy of the delegated private key is thus important and several <del> access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. </del> <ins> access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 5.2.