Change:
changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). <del> 4.1. </del> <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. <del> The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria: </del> <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. <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> <ins> It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). </ins> <del> 5. </del> <ins> 4. </ins> 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> <ins> 5. </ins> <del> 6.2. </del> <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

Discussion:
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