Cisco

rlb@ipv.sx

Facebook

subodh@fb.com

Cloudflare

nick@cloudflare.com

Windy Hill Systems, LLC

ekr@rtfm.com

Security tls certificate authentication TLS 1.3 signature scheme The organizational separation between operators of TLS and DTLS endpoints 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 Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Conventions and Terminology
• .  Solution Overview
  • .  Rationale
  • .  Related Work
• .  Delegated Credentials
  • .  Client and Server Behavior
    • .  Server Authentication
    • .  Client Authentication
    • .  Validating a Delegated Credential
  • .  Certificate Requirements
• .  Operational Considerations
  • .  Client Clock Skew
• .  IANA Considerations
• .  Security Considerations
  • .  Security of Delegated Credential's Private Key
  • .  Re-use of Delegated Credentials in Multiple Contexts
  • .  Revocation of Delegated Credentials
  • .  Interactions with Session Resumption
  • .  Privacy Considerations
  • .  The Impact of Signature Forgery Attacks
• .  References
  • .  Normative References
  • .  Informative References
• .  ASN.1 Module
• .  Example Certificate
• Acknowledgements
• Authors' Addresses

Introduction Server operators often deploy (D)TLS termination to act as the server for inbound TLS connections. These termination services can be in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect compromises of private key material corresponding to TLS certificates. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external Certification Authority (CA) is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificate and therefore a higher risk that an outage at a CA will negatively affect the uptime of the TLS-fronted service. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a CA) . This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations. For example:

• Whenever the server operator wants to deploy a new certificate, it has to interact with the CA.
• The CA might only issue credentials containing certain types of public keys, which can limit the set of (D)TLS signature schemes usable by the server operator.

To reduce the dependency on external CAs, this document specifies a limited delegation mechanism that allows a (D)TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to terminate connections for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 even if their CA does not support them. This document refers to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC".

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 interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 indicates a delegation from the certificate that is issued to the peer. The private key used to sign a credential corresponds to the public key of the peer's X.509 end-entity certificate . shows the intended deployment architecture.

Delegated Credentials 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

A (D)TLS handshake that uses delegated credentials differs from a standard handshake in a few important ways:

• The initiating peer provides an extension in its ClientHello or CertificateRequest that indicates support for this mechanism.
• The peer sending the Certificate message provides both the certificate chain terminating in its certificate and the delegated credential.
• The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the peer.
• Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.

As detailed in , the delegated credential is cryptographically bound to the end-entity certificate with which the credential may be used. This document specifies the use of delegated credentials in (D)TLS 1.3 or later; their use in prior versions of the protocol is not allowed. Delegated credentials allow a peer to terminate (D)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 of the compromise of a delegated credential's private key, delegated credentials have a maximum validity period. In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or that extends beyond the validity period of the delegation certificate. This mechanism is described in detail in . It was noted in 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 (). 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 .)

Rationale Delegated credentials present a better alternative than other delegation mechanisms like proxy certificates for several reasons:

• There is no change needed to certificate validation at the PKI layer.
• X.509 semantics are very rich. This can cause unintended consequences if a service owner creates a proxy certificate where 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 is not necessary. For this reason, delegated credentials have very restricted semantics that 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 end-entity certificate. Since the certificate path building process is not cryptographically protected, it is possible that a proxy 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.
• Each delegated credential is bound to a specific signature algorithm for use in the (D)TLS handshake (). This prevents them from being used with other, perhaps unintended, signature algorithms. The signature algorithm bound to the delegated credential can be chosen independently of the set of signature algorithms supported by the end-entity certificate.

Related Work Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to client behavior (e.g., a PKCS#11 interface or a remote signing mechanism, being one example). These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key. The mechanism proposed in this document allows the delegation to be done offline, with no per-transaction latency. The figure below compares the message flows for these two mechanisms with (D)TLS 1.3 . Remote key signing: Client Front-End Back-End |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | | Delegated Credential: 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 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 private key. The use of short-lived certificates with automated certificate issuance, e.g., with the Automated Certificate Management Environment (ACME) , reduces the risk of key compromise but has several 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.

Delegated Credentials While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is valid to use them to issue other signed objects as long as the certificate contains the digitalSignature KeyUsage (). (All certificates compatible with TLS 1.3 are required to contain the digitalSignature KeyUsage.) This document defines a new signed object format that encodes only the semantics that are needed for this application. 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 ), endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in ).

dc_cert_verify_algorithm:

The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in . This is expected to be the same as the sender's CertificateVerify.algorithm (as described in ).
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 SubjectPublicKeyInfo as defined in .

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:

1. An octet stream that consists of octet 32 (0x20) repeated 64 times.
2. The non-null terminated context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication.
3. A single octet 0x00, which serves as the separator.
4. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.
5. DelegatedCredential.cred.
6. 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.

Client and Server Behavior This document defines the following (D)TLS extension code point. enum { ... delegated_credential(34), (65535) } ExtensionType;

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 ): 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.

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.

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 that it is 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:

1. 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.)
2. 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.
3. 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.
4. Verify that the end-entity certificate satisfies the conditions described in .
5. 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. 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.

Certificate Requirements This document defines a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials. What follows is the ASN.1 for the DelegationUsage certificate extension. 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 .) An endpoint MUST NOT accept a delegated credential unless the peer's end-entity certificate satisfies the following criteria:

• It has the DelegationUsage extension.
• It has the digitalSignature KeyUsage (see the KeyUsage extension defined in ).

A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed (D)TLS and PKI software stacks without requiring CAs to issue new intermediate certificates.

Operational Considerations The operational considerations documented in this section should be taken into consideration when using delegated credentials.

Client Clock Skew 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 of or behind the server's clock, then clients will reject delegated 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.

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 this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in (D)TLS 1.3 . Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage certificate extension in . IANA has 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. An OID for the DelegationUsage certificate extension is not needed, as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc.

Security Considerations The security considerations documented in this section should be taken into consideration when using delegated credentials.

Security of Delegated Credential's Private Key Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period. An attacker who compromises the private key of a delegated credential cannot create new delegated credentials, but they can impersonate the compromised party in new TLS connections until the delegated credential expires. Thus, delegated credentials should not be used to send a delegation to an untrusted party. Rather, they 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.

Re-use of Delegated Credentials in Multiple Contexts 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).

Revocation of Delegated Credentials Delegated credentials do not provide any additional form of early revocation. Since it is short-lived, the expiry of the delegated credential revokes the credential. Revocation of the long-term private key that signs the delegated credential (from the end-entity certificate) also implicitly revokes the delegated credential.

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. Failing to do so may result in resuming connections for which the delegated credential has expired.

Privacy Considerations Delegated credentials can be valid for 7 days (by default), and it is much easier for a service to create delegated credentials than a certificate signed by a CA. A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing which credentials the client accepts. Since client time can be unique to a particular client, privacy-sensitive clients who do not trust the service, such as browsers in incognito mode, might not want to advertise support for delegated credentials, or might limit the number of probes that a server can perform.

The Impact of Signature Forgery Attacks Delegated credentials are only used in (D)TLS 1.3 connections. However, the certificate that signs a delegated credential may be used in other contexts such as (D)TLS 1.2. Using a certificate in multiple contexts opens up 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 allow forging an RSA signature over an arbitrary message . The TLS 1.2 specification describes a strategy for preventing these attacks that requires careful implementation of timing-resistant countermeasures. (See .) Experience shows that, in practice, server implementations may fail to fully stop these attacks due to the complexity of this mitigation . For (D)TLS 1.2 servers that support RSA key exchange using a DC-enabled end-entity certificate, a hypothetical signature forgery attack would allow forging 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). Server operators should therefore minimize the risk of using DC-enabled end-entity certificates where 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. Furthermore, server operators may 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 choose any value for the valid_time field. Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. ITU-T ITU-T Informative References Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1-12 IEEE Trustcom/BigDataSE/ISPA 2015 This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. 27th USENIX Security Symposium Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security

ASN.1 Module The following ASN.1 module provides the complete definition of the DelegationUsage certificate extension. The ASN.1 module makes imports from . 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

Example Certificate The following is an example of a delegation certificate that satisfies the requirements described in (i.e., uses the DelegationUsage extension and has the digitalSignature KeyUsage). -----BEGIN CERTIFICATE----- MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6 bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw 0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X /AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt y5S4RfWHIIPjbw== -----END CERTIFICATE-----

Acknowledgements 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 for their discussions, ideas, and bugs they have found.

Authors' Addresses Cisco

rlb@ipv.sx

Facebook

subodh@fb.com

Cloudflare

nick@cloudflare.com

Windy Hill Systems, LLC

ekr@rtfm.com