Original text:
endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the <del> certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in (D)TLS, without breaking compatibility with peers that do not support this specification. </del>  1. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC8446 ID.ietf-tls-dtls13 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </del>  Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. (*) indicates changes to the wire protocol.  draft-10 Address superficial comments It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (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 that permits use of delegated credentials.  (See certificate- requirements.) </del>  3.1. X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where <del> the properties differ from the leaf certificate.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </del>  Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end- interact with a back-end server that holds a 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 <del> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del>  These two mechanisms can be complementary.  A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients.  Both mechanisms require a trusted relationship between the Front-End and Back-End - the delegated credential can be used in place of a certificate <del> private key, and the remote key signing case is effectively a signing oracle for TLS connections using that certificate. </del>  Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME) 6. <del> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" </del>  extension has been assigned a code point of 34.  The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or <del> Certificate (CT) messages in (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del>  Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period.  An attacker who <del> compromises the private key of a delegated credential can act as a man-in-the-middle until the delegated credential expires.  However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </del>  7.2. 7.4. <del> If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. </del>  7.5.

Reviewer comments:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.

Revised text:
endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the  <ins> certification authority.  This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification. </ins> 1. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or  <ins> CA) RFC8446 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </ins> Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. (*) indicates changes to the wire protocol. <ins> draft-11 Editorial changes based on AD comments Add support for DTLS Address address ambiguity in cert expiry </ins> draft-10 Address superficial comments It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage  <ins> (RFC5280 section 4.2.1.3).  In order to reduce the risk of cross- protocol attacks on certificates that are not intended to be used with DC-capable TLS stacks, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate-requirements.) </ins> 3.1. X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where  <ins> the properties differ from the leaf certificate.  Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide are not necessary.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </ins> Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end- interact with a back-end server that holds a 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  <ins> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 I- D.ietf-tls-dtls13. </ins> These two mechanisms can be complementary.  A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients.  Both mechanisms require a trusted relationship between the Front-End and Back-End - the delegated credential can be used in place of a certificate  <ins> private key. </ins> Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME) 6.  <ins> This document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry.  The "delegated_credential" </ins> extension has been assigned a code point of 34.  The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or  <ins> Certificate (CT) messages in (D)TLS 1.3 RFC8446 I-D.ietf-tls-dtls13. </ins> Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period.  An attacker who  <ins> compromises the private key of a delegated credential can impersonate the compromised party in new TLS connections until the delegated credential expires. However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 7.2. 7.4.  <ins> If a peer decides to cache the certificate chain and re-validate it when resuming a connection, they SHOULD also cache the associated delegated credential and re-validate it.  Failing to do so may result in resuming connections for which the DC has expired. </ins> 7.5.