RFC 9345

Delegated Credentials for TLS and DTLS

📅 published July 2023, from ietf

Delegated Credentials for TLS and DTLS 💖

okay bestie, this is RFC 9345 🎀 and the title says it all: Delegated Credentials for TLS and DTLS. It's a Standards Track document ✨, so it's an official Internet Standards Track spec 💅. It was written by R. Barnes (Cisco), S. Iyengar (Facebook), N. Sullivan (Cloudflare), and E. Rescorla (Windy Hill Systems, LLC), and it came out in July 2023 🌈. It's published by the Internet Engineering Task Force (IETF) under ISSN 2070-1721 🦋. The header doesn't list any obsoletes or updates, so there's nothing it replaces or changes 🙈.

Abstract ✨

the TLS and DTLS endpoints run by operators are separate from the certification authority (CA), and that split can cause real limitations 😩. for example, the CA ultimately decides how long certificates last, how they can be used, and which algorithms they support. this document describes a mechanism to get around some of those limits by letting operators delegate their own credentials for use in TLS and DTLS, without breaking compatibility with peers that don't support this specification 🫶.

Status of This Memo 📜

this is an Internet Standards Track document 🔥.

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨. if you want more about Internet Standards, check Section 2 of RFC 7841.

info about the current status, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9345 💜.

Copyright Notice ⚖️

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. please read these carefully, because they spell out your rights and restrictions with respect to this document 🧾. code components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🍓.

Table of Contents 🗂️

   1.  Introduction
   2.  Conventions and Terminology
   3.  Solution Overview
     3.1.  Rationale
     3.2.  Related Work
   4.  Delegated Credentials
     4.1.  Client and Server Behavior
       4.1.1.  Server Authentication
       4.1.2.  Client Authentication
       4.1.3.  Validating a Delegated Credential
     4.2.  Certificate Requirements
   5.  Operational Considerations
     5.1.  Client Clock Skew
   6.  IANA Considerations
   7.  Security Considerations
     7.1.  Security of Delegated Credential's Private Key
     7.2.  Re-use of Delegated Credentials in Multiple Contexts
     7.3.  Revocation of Delegated Credentials
     7.4.  Interactions with Session Resumption
     7.5.  Privacy Considerations
     7.6.  The Impact of Signature Forgery Attacks
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  ASN.1 Module
   Appendix B.  Example Certificate
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

server operators often run (D)TLS termination, which means the box acts as the server for inbound TLS connections 🖥️. these termination services can live in places like remote data centers or Content Delivery Networks (CDNs), where it can be hard to notice if the private key behind a TLS certificate has been compromised 😬. short-lived certificates can be used to limit how exposed those keys are in these situations 🫣.

BUT (okay, not in caps, it's just dramatic 💀) short-lived certificates need renewing more often than long-lived ones. if an external Certification Authority (CA) can't issue a certificate in time to replace one that's already deployed, the server can't show a valid certificate to clients anymore 😭. with short-lived certificates there's a smaller window to renew, so there's a higher risk that a CA outage will hurt the uptime of the TLS-fronted service 📉.

normally, a (D)TLS server uses a certificate from some entity other than the server operator, which is the CA [RFC8446] [RFC5280]. that split makes the server operator depend on the CA for parts of its operations 🙃. for example:

whenever the server operator wants to deploy a new certificate, it has to go through the CA 📮.
the CA might only issue credentials with certain types of public keys, and that can limit which (D)TLS signature schemes the server operator can use 🔐.

to cut down on that dependency on external CAs, this document specifies a limited delegation mechanism. it lets a (D)TLS peer issue its own credentials within the scope of a certificate that an external CA issued 🦋. these credentials only let the recipient of the delegation terminate connections for names the CA has authorized 🎯. on top of that, this mechanism lets the server use modern signature algorithms such as Ed25519 [RFC8032], even if their CA doesn't support them 🌟.

this document calls the certificate issued by the CA a "certificate", or "delegation certificate". the one issued by the operator is called a "delegated credential" or "DC" 🏷️.

2. Conventions and Terminology 🌸

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, just like they do here 📖.

3. Solution Overview 🧚

a delegated credential (DC) is a digitally signed data structure with two semantic fields: a validity interval and a public key (along with its associated signature algorithm) 💎. the signature on the delegated credential shows a delegation from the certificate that was issued to the peer. the private key used to sign a credential matches the public key of the peer's X.509 end-entity certificate [RFC5280]. Figure 1 shows the intended deployment architecture 🏗️.

Client            Front-End            Back-End
  |                   |<--DC distribution->|
  |----ClientHello--->|                    |
  |<---ServerHello----|                    |
  |<---Certificate----|                    |
  |<---CertVerify-----|                    |
  |        ...        |                    |

Legend:
Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to a private key

       Figure 1: Delegated Credentials Deployment Architecture

a (D)TLS handshake that uses delegated credentials is different from a standard handshake in a few important ways 👀:

the initiating peer sends an extension in its ClientHello or CertificateRequest that says it supports this mechanism 🙋.
the peer sending the Certificate message provides both the certificate chain that ends in its certificate and the delegated credential 🔗.
the initiator uses info from the peer's certificate to verify the delegated credential, and to check that the peer is asserting an expected identity. that's how it decides the authentication result for the peer 🕵️.
peers that accept the delegated credential use it as the certificate key for the (D)TLS handshake 🔑.

as Section 4 details, the delegated credential is cryptographically bound to the end-entity certificate it may be used with 🔒. this document specifies using delegated credentials in (D)TLS 1.3 or later. their use in earlier versions of the protocol is not allowed 🚫.

delegated credentials let a peer terminate (D)TLS connections on behalf of the certificate owner 🎭. if a credential gets stolen, there's no way to revoke it without revoking the certificate itself 😱. to limit exposure if a delegated credential's private key is compromised, delegated credentials have a maximum validity period. unless an application profile standard says otherwise, that maximum is 7 days ⏳. peers MUST NOT issue credentials with a validity period longer than the maximum validity period, or one that runs past the validity period of the delegation certificate. Section 4.1 walks through this mechanism in detail 📚.

[XPROT] noted that certificates used by servers that support outdated protocols like SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage ([RFC5280], Section 4.2.1.3) 💀. so to reduce the risk of cross-protocol attacks on certificates that aren't meant for DC-capable TLS stacks, this document defines a new DelegationUsage extension to X.509 that permits use of delegated credentials 🛡️. (see Section 4.2.)

3.1. Rationale 💭

delegated credentials are a better option than other delegation mechanisms, like proxy certificates [RFC3820], for a few reasons 🌷:

there's no change needed to certificate validation at the PKI layer ✅.
X.509 semantics are super rich. that can cause unintended consequences if a service owner makes a proxy certificate whose properties differ from the leaf certificate 🤯. proxy certificates can be useful in controlled environments, but they're still a risk in situations where the extra flexibility they offer isn't needed. for this reason, delegated credentials have very restricted semantics that shouldn't conflict with X.509 semantics 🧠.
proxy certificates depend on the certificate path building process to bind the proxy certificate to the end-entity certificate. since that process isn't cryptographically protected, a proxy certificate could end up bound to another certificate that has the same public key but different X.509 parameters 😵. delegated credentials rely on a cryptographic binding between the entire certificate and the delegated credential, so that can't happen 🙅‍♀️.
each delegated credential is bound to one specific signature algorithm for use in the (D)TLS handshake ([RFC8446], Section 4.2.3) 🎯. that stops them from being used with other, maybe unintended, signature algorithms. the signature algorithm bound to the delegated credential can be picked independently of the signature algorithms the end-entity certificate supports 🪄.

a lot of the use cases for delegated credentials can also be handled with purely server-side mechanisms that don't need any changes to client behavior. examples include a PKCS#11 interface or a remote signing mechanism, with [KEYLESS] being one example 🖇️. those mechanisms do add per-transaction latency, though, since the front-end server has to talk to a back-end server that holds a private key 🐌. the mechanism in this document lets the delegation happen offline, with no per-transaction latency ⚡. the figure below compares the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] [RFC9147] 📊.

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, because the delegated credential can be used in place of a certificate private key 🫶

The use of short-lived certificates with automated certificate issuance, e.g., with the Automated Certificate Management Environment (ACME) [RFC8555], reduces the risk of key compromise, but it comes with some limitations 😭 Specifically, it introduces an operationally critical dependency on an external party (the CA). It also limits the types of algorithms supported for (D)TLS authentication to those the CA is willing to issue a certificate for. Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning delegated credentials 🧚

4. Delegated Credentials ✨

Okay so X.509 says end-entity certificates can't be used as issuers for other certificates 🙅‍♀️ BUT it's totally valid to use them to issue other signed objects, as long as the certificate contains the digitalSignature KeyUsage ([RFC5280], Section 4.2.1.3). (All certificates compatible with TLS 1.3 are required to contain the digitalSignature KeyUsage.) This document defines a new signed object format that only encodes the semantics needed for this application, and it's giving minimalism 💅 The Credential has the following structure:

      struct {
        uint32 valid_time;
        SignatureScheme dc_cert_verify_algorithm;
        opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
      } Credential;

valid_time: Time, in seconds relative to the delegation certificate's notBefore value, after which the delegated credential is no longer valid ⏰ By default, unless set to an alternative value by an application profile (see Section 3), endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in Section 4.1.3).
dc_cert_verify_algorithm: The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in [RFC8446]. This is expected to be the same as the sender's CertificateVerify.algorithm (as described in Section 4.1.3). When using RSA, the public key MUST NOT use the rsaEncryption OID. As a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, and rsa_pss_rsae_sha512 🚫
ASN1_subjectPublicKeyInfo: The Credential's public key, a DER-encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280] 🔑

The DelegatedCredential has the following structure:

      struct {
        Credential cred;
        SignatureScheme algorithm;
        opaque signature<1..2^16-1>;
      } DelegatedCredential;

cred: The Credential structure as previously defined.
algorithm: The signature algorithm used to create DelegatedCredential.signature.
signature: 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.

The signature of the DelegatedCredential is computed over the concatenation of:

An octet stream that consists of octet 32 (0x20) repeated 64 times.
The non-null terminated context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication.
A single octet 0x00, which serves as the separator.
The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.
DelegatedCredential.cred.
DelegatedCredential.algorithm.

The signature is computed by using the private key of the peer's end-entity certificate, with the algorithm indicated by DelegatedCredential.algorithm.

The signature effectively binds the credential to the parameters of the handshake in which it is used. In particular, it ensures that credentials are only used with the certificate and signature algorithm chosen by the delegator 🔐

The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the (D)TLS stack. This has the advantage of avoiding changes to the often-delicate, security-critical PKI code 🥰

4.1. Client and Server Behavior 🎀

This document defines the following (D)TLS extension code point.

      enum {
        ...
        delegated_credential(34),
        (65535)
      } ExtensionType;

4.1.1. Server Authentication 🦋

A client that is willing to use delegated credentials in a connection SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList (defined in [RFC8446]):

      struct {
        SignatureScheme supported_signature_algorithms<2..2^16-2>;
      } SignatureSchemeList;

If the client receives a delegated credential without having indicated support in its ClientHello, then the client MUST abort the handshake 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. When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension. An example of when a server could choose not to send a delegated credential is when the SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection 🙈

The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate. The client MUST NOT use delegated credentials sent as extensions to any other certificate, and SHOULD ignore them, but MAY abort the handshake with an "illegal_parameter" alert. If the server sends multiple delegated credentials extensions in a single CertificateEntry, the client MUST abort the handshake with an "illegal_parameter" alert 💀

The algorithm field MUST be of a type advertised by the client in the "signature_algorithms" extension of the ClientHello message, and the dc_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList. Otherwise, the credential is considered not valid. Clients that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert 🙅‍♀️

4.1.2. Client Authentication 🌸

A server that supports this specification SHALL send a "delegated_credential" extension in the CertificateRequest message when requesting client authentication. The body of the extension consists of a SignatureSchemeList. If the server receives a delegated credential without having indicated support in its CertificateRequest, then the server MUST abort with an "unexpected_message" alert 🚨

If the extension is present, the client MAY send a delegated credential. If the extension is not present, the client MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the client MUST ignore this extension.

The client MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate. The server MUST NOT use delegated credentials sent as extensions to any other certificate, and SHOULD ignore them, but MAY abort the handshake with an "illegal_parameter" alert. If the client sends multiple delegated credentials extensions in a single CertificateEntry, the server MUST abort the handshake with an "illegal_parameter" alert 💀

The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message, and the dc_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList. Otherwise, the credential is considered not valid. Servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert 🙅‍♀️

4.1.3. Validating a Delegated Credential 🔍

On receiving a delegated credential and certificate chain, the peer validates the certificate chain and matches the end-entity certificate to the peer's expected identity, in the same way it's done when delegated credentials are not in use. It then performs the following checks, with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time:

Verify that the current time is within the validity interval of the credential. This is done by asserting that the current time does not exceed the expiry time. (The start time of the credential is implicitly validated as part of certificate validation.)
Verify that the delegated credential's remaining validity period is no more than the maximum validity period. This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days by default) and that the expiry time is less than the certificate's expiry_time.
Verify that dc_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials.
Verify that the end-entity certificate satisfies the conditions described in Section 4.2.
Use the public key in the peer'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 not valid. Clients and servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert 🚫

Heads up, bestie: every failed check above means the credential is not valid, and that's a hard stop for the connection. No exceptions, periodt 💅

If successful, the participant receiving the Certificate message uses the public key in DelegatedCredential.cred to verify the signature in the peer's CertificateVerify message ✨

4.2. Certificate Requirements ✨

okay bestie, this section is all about the certificate that's doing the vouching 💅. This document defines a brand-new X.509 extension called DelegationUsage, and it only belongs in a certificate that says "yes, delegated credentials are allowed here" 🎀. Here's the ASN.1 [X.680] for it:

    ext-delegationUsage EXTENSION  ::= {
        SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage
    }

    DelegationUsage ::= NULL

    id-pe-delegationUsage OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          private(4) enterprise(1) id-cloudflare(44363) 44 }

The extension MUST be marked non-critical 🙈. (See Section 4.2 of [RFC5280].) An endpoint MUST NOT accept a delegated credential unless the peer's end-entity certificate meets these criteria:

It has the DelegationUsage extension.
It has the digitalSignature KeyUsage (see the KeyUsage extension defined in [RFC5280]).

Why a new extension and not a new Extended Key Usage (EKU)? Because it keeps things compatible with the (D)TLS and PKI software that's already out there, and CAs don't have to go issue brand-new intermediate certificates 🦋. Lowkey genius.

5. Operational Considerations 🌸

okay, the operational considerations in this section should be taken into consideration when you're using delegated credentials. Read them, they matter!

5.1. Client Clock Skew ⏰

one of the risks of a short-lived credential system based on absolute time is client clock skew 😭. If a client's clock is far enough ahead of or behind the server's clock, the client will reject delegated credentials that are totally valid from the server's point of view. Clock skew also messes with the validity of the original certificates too. The lifetime of the delegated credential should be set with clock skew in mind. And clock skew can hit a delegated credential at the very beginning and very end of its validity periods, so that should be factored in as well 🥲.

6. IANA Considerations 📋

this document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry 🍓. The delegated_credential extension has been assigned the ExtensionType value 34. The IANA registry lists it as "Recommended" (i.e., "Y") and says it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in (D)TLS 1.3 [RFC8446] [RFC9147]. The "DTLS-Only" column is set to "N" ✨.

This document also defines an ASN.1 module for the DelegationUsage certificate extension in Appendix A. IANA registered value 95 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry 🎀. No separate OID is needed for the DelegationUsage certificate extension, because it already has one from Cloudflare's IANA Private Enterprise Number (PEN) arc. Iconic, right? 👑

7. Security Considerations 🔐

okay this is the serious part, bestie, so listen up 🫶. The security considerations in this section should be taken into consideration when you're using delegated credentials.

7.1. Security of Delegated Credential's Private Key 🗝️

delegated credentials limit how exposed the private key in a (D)TLS connection is, by limiting its validity period. An attacker who compromises the private key of a delegated credential can't make new delegated credentials, BUT they can still impersonate the compromised party in new TLS connections until the delegated credential expires 😱.

So, delegated credentials should not be used to send a delegation to an untrusted party. They're meant for parties that already have some kind of trust relationship with each other 🤝. That means keeping the delegated credential's private key secret is super important, and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules 🔒.

7.2. Re-use of Delegated Credentials in Multiple Contexts 🙅‍♀️

you can't use the same delegated credential for both client and server authentication. Why? Because the issuing parties compute the signature using a context string that's unique to the intended role (client or server) 💅.

7.3. Revocation of Delegated Credentials ⌛

delegated credentials don't offer any extra form of early revocation. They're short-lived, so the credential's expiry is what revokes it ✨. Revoking the long-term private key that signs the delegated credential (from the end-entity certificate) also implicitly revokes the delegated credential 💀.

7.4. Interactions with Session Resumption 🔁

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 too 🧚. If they don't, they might end up resuming connections where the delegated credential has already expired.

7.5. Privacy Considerations 👀

delegated credentials can be valid for 7 days (by default), and it's way easier for a service to create one than to get a certificate signed by a CA 😬. A service could figure out the client's time and clock skew by making several delegated credentials with different expiry timestamps and seeing which ones the client accepts. Since client time can be unique to a particular client, privacy-sensitive clients who don't trust the service (think browsers in incognito mode) might not want to advertise support for delegated credentials, or might limit how many probes a server can run 🙈🌈.

7.6. The Impact of Signature Forgery Attacks 🚨

delegated credentials only get used in (D)TLS 1.3 connections. BUT the certificate that signs a delegated credential may also get used in other contexts, like (D)TLS 1.2. Using one certificate in multiple contexts opens the door to a potential cross-protocol attack against delegated credentials in (D)TLS 1.3 😭.

When (D)TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that let someone forge an RSA signature over an arbitrary message [BLEI]. The TLS 1.2 specification describes a strategy for stopping these attacks, but it needs careful implementation of timing-resistant countermeasures. (See Section 7.4.7.1 of [RFC5246].)

In practice, though, server implementations can fail to fully stop these attacks because the mitigation is so complicated [ROBOT] 🥴. For (D)TLS 1.2 servers that support RSA key exchange using a DC-enabled end-entity certificate, a hypothetical signature forgery attack would let someone forge a signature over a delegated credential. The forged delegated credential could then be used by the attacker as the equivalent of an on-path attacker, valid for a maximum of 7 days (if the default valid_time is used) 😱.

So server operators should minimize the risk of using DC-enabled end-entity certificates anywhere a signature forgery oracle may be present 🛑. If possible, server operators may choose to use DC-enabled certificates only for signing credentials and not for serving non-DC (D)TLS traffic. Server operators may also use elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic. This completely prevents such attacks 🦋✨.

Note that if a signature can be forged over an arbitrary credential, the attacker can pick any value for the valid_time field. Repeated signature forgeries can therefore let the attacker create multiple delegated credentials that cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may let the attacker impersonate a server for the lifetime of the certificate 💀.

8. References 📚

8.1. Normative References 💜

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, https://www.rfc-editor.org/info/rfc8446.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, https://www.rfc-editor.org/info/rfc9147.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ISO/IEC 8824-1:2021, February 2021, https://www.itu.int/rec/T-REC-X.680.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2021, February 2021, https://www.itu.int/rec/T-REC-X.690.

8.2. Informative References ✨

[BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1", Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1-12, 1998, https://link.springer.com/chapter/10.1007/BFb0055716.
[KEYLESS] Stebila, D. and N. Sullivan, "An Analysis of TLS Handshake Proxying", IEEE Trustcom/BigDataSE/ISPA 2015, 2015, https://ieeexplore.ieee.org/document/7345293.
[RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. Thompson, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", RFC 3820, DOI 10.17487/RFC3820, June 2004, https://www.rfc-editor.org/info/rfc3820.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, https://www.rfc-editor.org/info/rfc5246.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, https://www.rfc-editor.org/info/rfc5912.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, https://www.rfc-editor.org/info/rfc8032.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, https://www.rfc-editor.org/info/rfc8555.
[ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX Security Symposium, 2018, https://www.usenix.org/conference/usenixsecurity18/presentation/bock.
[XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, 2015, https://dl.acm.org/doi/10.1145/2810103.2813657.

Appendix A. ASN.1 Module ✨

Here's the full ASN.1 module, the whole definition of the DelegationUsage certificate extension, all in one place 💖 It pulls some imports from [RFC5912] 🎀

DelegatedCredentialExtn
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-delegated-credential-extn(95) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORT ALL

IMPORTS

EXTENSION
  FROM PKIX-CommonTypes-2009 -- From RFC 5912
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-pkixCommon-02(57) } ;

-- OID

id-cloudflare OBJECT IDENTIFIER ::=
  { iso(1) identified-organization(3) dod(6) internet(1) private(4)
    enterprise(1) 44363 }

-- EXTENSION

ext-delegationUsage EXTENSION ::=
  { SYNTAX DelegationUsage
    IDENTIFIED BY id-pe-delegationUsage }

id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }

DelegationUsage ::= NULL

END

Appendix B. Example Certificate 🦋

Okay, this one is the vibe 😭 It's an example delegation certificate that checks every box in Section 4.2. Which means it uses the DelegationUsage extension AND has the digitalSignature KeyUsage. Iconic behaviour, honestly 👑

Acknowledgements 🫶

Huge thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, 奥一穂 (Kazuho Oku), Daniel Kahn Gillmor, Watson Ladd, Robert Merget, Juraj Somorovsky, and Nimrod Aviram 💜 Y'all's discussions, ideas, and the bugs you found made this so much better, no cap ✨

Authors' Addresses 🌸

Richard Barnes, Cisco, Email: rlb@ipv.sx
Subodh Iyengar, Facebook, Email: subodh@fb.com
Nick Sullivan, Cloudflare, Email: nick@cloudflare.com
Eric Rescorla, Windy Hill Systems, LLC, Email: ekr@rtfm.com

📦 where this page comes from

ietf: rfc9345 2023-07
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms