Original text:
Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms.  This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking </del>  compatibility with clients that do not support this specification. 1. "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential".  2. A delegated credential is a digitally signed data structure with two <del> semantic fields: a validity interval, and a public key (with its associated algorithm).  The signature on the credential indicates a delegation from the 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. </del>  A TLS handshake that uses credentials differs from a normal handshake in a few important ways: support for this mechanism. The server provides both the certificate chain terminating in its <del> certificate as well as the credential. </del>  The client uses information in the server's certificate to verify <del> the signature on the credential and verify that the server is asserting an expected identity. </del>  The client uses the public key in the credential as the server's working key for the TLS handshake. <del> This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </del>  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 (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> that permits use of delegated credentials.  Clients MUST NOT accept delegated credentials associated with certificates without this extension. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit the exposure of a delegation credential compromise, servers MUST NOT issue credentials with a validity period longer than 7 days.  Clients MUST NOT accept credentials with longer validity periods. </del>  2.1. layer. X.509 semantics are very rich.  This can cause unintended <del> consequences if a service owner creates a proxy cert where the properties differ from the leaf certificate.  For this reason, </del>  delegated credentials have very restricted semantics which should not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the <del> server certificate.  Since the cert path building process is not cryptographically protected, it is possible that a proxy </del>  certificate could be bound to another certificate with the same public key, with different X.509 parameters.  Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> 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. </del>  2.2. 3. <del> This document defines the following extension code point. A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.3 or later is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least one of the supported signature algorithms.  A delegated credential MUST NOT be negotiated by the server if its signature is not compatible with any of the supported signature algorithms or the credential's public key is not usable with the supported signature algorithms of the client, even if the client advertises support for delegated credentials. The SignatureScheme the server selects in the "signature_algorithms" extension MUST be that of the credential public key.  On receiving a credential and a certificate chain, the client validates the certificate chain and matches the end-entity certificate to the server's expected identity following its normal procedures.  It then takes the following steps: Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than 7 days. Verify that the end-entity certificate satisfies the conditions specified in Section certificate-requirements. Use the public key in the server's end-entity certificate to verify the signature of the credential. If one or more of these checks fail, then the delegated credential is deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to verify the signature in the serer's CertificateVerify message. 4. </del> 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 key usage (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 </del>  structure: Relative time in seconds from the beginning of the delegation is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard. </del>  The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3. </del>  <del> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. </del>  The delegated credential has the following structure: <del> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. </del>  The signature over the credential with the end-entity certificate's public key, using the scheme. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> DelegatedCredential.cred. </del>  DelegatedCredential.scheme. the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their <del> semantics in this way is intended to mitigate thee risk of cross </del>  protocol attacks involving delegated credentials. The code changes to create and verify delegated credentials would be changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). <del> 4.1. </del>  We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials. <del> The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria: </del>  It has the DelegationUsage extension. <del> It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an "illegal_parameter" alert. </del>  <del> 5. </del>  TBD <del> 6. 6.1. Marking the delegation certificate's DelegationUsage extension non- critical allows the certificate to be used for clients that do not support delegated credentials.  However, it may be desirable to ensure that the delegation certificate is only used in handshakes in which a delegated credential negotiated.  It suffices to mark the extension crticial and set the strict boolean to true: if the client does not support delegated credentials, then it will abort the handshake if the certificate has the DelegationUsage extension (as per Section 4.2 of RFC5280); if the client indicates support, but the server does not offer a delegated credential, then the client will abort the handshake (as per certificate-requirements). </del>  <del> 6.2. </del>  Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.3. </del>  Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated credential would revoke the credential.  Revocation of the long term <del> private key that signs the delegated credential also implictly </del>  revokes the delegated credential. <del> 6.4. </del>  Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

Reviewer comments:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me

Revised text:
Abstract The organizational separation between the operator of a TLS server  <ins> and the certificate 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 certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking </ins> compatibility with clients that do not support this specification. 1. "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". <ins> 1.1. (*) indicates changes to the wire protocol. draft-02 Change DelegationUsage extension to be NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. (*) Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate. </ins> 2. A delegated credential is a digitally signed data structure with two  <ins> semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential corresponds to the public key of the X.509 end-entity certificate. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways: support for this mechanism. The server provides both the certificate chain terminating in its  <ins> certificate as well as the delegated credential. </ins> The client uses information in the server's certificate to verify  <ins> the delegated credential and that the server is asserting an expected identity. </ins> The client uses the public key in the credential as the server's working key for the TLS handshake.  <ins> As detailed in delegated-credentials, the delegated credential is cryptographically bound to the end-entity certificate and the protocol in 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 protocol is explicitly disallowed. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit exposure in case a delegated credential is compromised, servers may not issue credentials with a validity period longer than 7 days.  This mechanism is described in detail in client- and-server-behavior. </ins> 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 (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.  (See certificate- requirements.) </ins> 2.1. layer. X.509 semantics are very rich.  This can cause unintended  <ins> consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, </ins> delegated credentials have very restricted semantics which should not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the  <ins> server certificate.  Since the certificate path building process is not cryptographically protected, it is possible that a proxy </ins> certificate could be bound to another certificate with the same public key, with different X.509 parameters.  Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot.  <ins> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </ins> 2.2. 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 is no longer valid. The signature algorithm of the credential key pair, where the type  <ins> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the  <ins> type ProtocolVersion is as defined in TLS 1.3.  This is expected to match the protocol version that is negotiated by the client and server. </ins>  <ins> The credential's public key, a DER-encoded SubjectPublicKeyInfo as defined in RFC5280. </ins> The delegated credential has the following structure:  <ins> The signature algorithm used to verify DelegatedCredential.signature. </ins> The signature over the credential with the end-entity certificate's public key, using the scheme. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.  <ins> DelegatedCredential.algorithm. </ins> DelegatedCredential.scheme. the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their  <ins> semantics in this way is intended to mitigate the risk of cross </ins> protocol attacks involving delegated credentials. The code changes to create and verify delegated credentials would be changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack).  <ins> 3.1. This document defines the following extension code point. A client which supports this specification SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.3 or a later version is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a type advertised by the client in the "signature_algorithms" extension.  A delegated credential MUST NOT be negotiated otherwise, even if the client advertises support for delegated credentials. On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity certificate to the server's expected identity following its normal procedures.  It also takes the following steps: Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than 7 days. Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. Verify that expected_version matches the protocol version indicated in the server's "supported_versions" extension. Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements. Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm. If one or more of these checks fail, then the delegated credential is deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to verify the signature in the server's CertificateVerify message. 3.2. </ins> We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials.  <ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria: </ins> It has the DelegationUsage extension.  <ins> It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). </ins>  <ins> 4. </ins> TBD  <ins> 5. </ins>  <ins> 5.1. </ins> Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules.  <ins> 5.2. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated credential would revoke the credential.  Revocation of the long term  <ins> private key that signs the delegated credential also implicitly </ins> revokes the delegated credential.  <ins> 5.3. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate