Change:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in

Discussion:
Address case nits <ins> Fix section bullets in 4.1.3. Add operational considerations section for clock skew </ins> Add text around using an oracle to forge DCs in the future and past

Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus <del> DelegatedCredential.cred.valid_time.  2 Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del> <ins> DelegatedCredential.cred.valid_time. Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the

5. <ins> 5.1. One of the risks of deploying a short-lived credential system based on absolute time is client clock skew.  If a client's clock is sufficiently ahead or behind of the server's clock, then clients will reject credentials that are valid from the server's perspective. Clock skew also affects the validity of the original certificates. The lifetime of the delegated credential should be set taking clock skew into account.  Clock skew may affect a delegated credential at the beginning and end of its validity periods, which should also be taken into account. 6. </ins> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" extension has been assigned a code point of 34.  The IANA registry

extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Delegated credentials limit the exposure of the private key used in a TLS connection by limiting its validity period.  An attacker who

mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. <del> 6.2. </del> <ins> 7.2. </ins> It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server). <del> 6.3. </del> <ins> 7.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated

private key that signs the delegated credential also implicitly revokes the delegated credential. <del> 6.4. </del> <ins> 7.4. </ins> 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> 6.5. </del> <ins> 7.5. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

want to advertise support for delegated credentials or limit the number of probes that a server can perform. <del> 6.6. </del> <ins> 7.6. </ins> When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary