]> Google Inc

me@brandonweeks.com

AppViewX Inc.

ganesh.mallaya@appviewx.com

Keyfactor

sven.rajala@keyfactor.com

TurboLight Solutions

corey.bonnell@turbolightsolutions.com

Peculiar Ventures

ryan.hurst+ietf@peculiarventures.com

Security ACME Working Group Internet-Draft This document specifies new identifiers and a challenge for the Automatic Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. This document updates RFC 8555 to enable a privacy-preserving mode for the identifiers defined in this document.

Introduction The Automatic Certificate Management Environment (ACME) standard specifies methods for validating control over identifiers, such as domain names. It is also useful to be able to validate properties of the device requesting the certificate, such as the identity of the device and whether the certificate key is protected by a secure cryptoprocessor. Many operating systems and device vendors offer functionality enabling a device to generate a cryptographic attestation of their identity, such as:

• Android Key Attestation
• Chrome OS Verified Access
• Trusted Platform Module
• Managed Device Attestation for Apple Devices

The following changes to the ACME specification are described in this document:

• Addition of permanent-identifier and hardware-module identifier types.
• Addition of the device-attest-01 challenge type to prove control of the permanent-identifier and hardware-module identifier types.
• The challenge response payload contains a serialized WebAuthn attestation statement format instead of an empty JSON object ({}).
• Accounts and external account binding being used as a mechanism to pre-authenticate requests to an enterprise CA.

This document does not specify the attestation verification procedures. Section 13 of gives some guidance, however verification procedures are complex and may require changes to address future security issues. Efforts are underway within the Remote ATtestation ProcedureS (RATS) working group to define a set of standard formats and protocols for attestation. An explicit aim of this document is to support vendor specific formats and protocols that are widely deployed at publication time of this specification.

Conventions and Definitions 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.

Permanent Identifier A new identifier type, permanent-identifier is introduced to represent the identity of a device assigned by the manufacturer, typically a serial number. Additionally, the assigner of the identifier MAY be specified. The name of this identifier type was chosen to align with . This specification does not prescribe the lifetime of the identifier, which is at the discretion of the Assigner Authority (). Although permits any valid UTF-8 string to be used as the identifier, this specification mandates that identifiers MUST NOT contain the forward-slash "/" (UTF-8: U+002F) character. This restriction is required to make the ABNF production rule for the permanent-identifier-value unambiguous.

Representation in Order resources The identifier's value field contains a UTF-8 string representation of the identity of the device. In addition to the value being a valid UTF-8 string, the value MUST match the permanent-identifier-value production rule as defined in this ABNF syntax: A valid permanent-identifier-value value is a UTF-8 string that contains an identity consisting of one or more characters without any forward-slash "/" (UTF-8: U+002F) characters. Optionally, a forward-slash "/" character and "dotted-decimal" object identifier identifying the assigner may follow the identity. The assigner-value is a dotted-decimal representation of an ASN.1 OBJECT IDENTIFIER. The Server MUST verify that identifier values in newOrder requests conform to the permanent-identifier-value production rule and MUST reject requests containing non-conforming values with a "malformed" error. Example of an identifier without an assigner: Example of an identifier with an assigner:

Representation in Certificate Signing Requests (CSRs) and X.509 Certificates This section describes the X.509 representation of the permanent-identifier. Other credential types may use the same identifier values with representations appropriate to those credential types. The identity is included in the Subject Alternative Name extension ("SAN") using the identifierValue field of the PermanentIdentifier form described in . Although permits the requester to include the identifierValue in a serialNumber subject attribute, this specification mandates that the identifierValue field of the PermanentIdentifier MUST be present and MUST contain the identifier. The value of the identifierValue field of the PermanentIdentifier MUST be an octet-for-octet match of the device-identifier-value value as encoded in the Order resource. If the assigner-value value is included in the identifier as encoded in the Order resource, then the assigner field of the PermanentIdentifier MUST be the encoding of the "dotted-decimal" object identifier encoded as the assigner-value value. This strict matching requirement ensures that the SAN in the issued certificate appears exactly as it appeared during proof-of-ownership validation, preventing identifier malleability. Serial number allocation schemes may be case-sensitive or otherwise sensitive to exact byte representation, so no normalization or transformation is permitted. To ensure that the identifier as presented in the Order resource and CSR match, the Server MUST perform the logical equivalent of extracting the device-identifier-value and assigner-value values from the CSR and reconstructing the UTF-8 representation of the identifier. The Server MUST then ensure that the UTF-8 representation and the identifier presented in the Order resource are an octet-for-octet match and reject the Order otherwise. Servers that derive identifier values directly from verified attestation evidence and construct the certificate SAN from that evidence, provided the derived values are verified against the attested device identity in the attestation statement, satisfy the intent of this requirement. section 7.4 mandates that "The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request". However, there are some environments where the Server requires validation of the identifier but does not include the identifier in certificates due to privacy concerns. This document updates to specify that the CSR SHOULD indicate the exact same set of requested identifiers of types permanent-identifier and hardware-module () as the initial newOrder request (identifiers of other types MUST be indicated in the CSR per section 7.4). To support privacy-preserving certificates, Clients MAY omit identifiers of types permanent-identifier and hardware-module in the certificate signing request (CSR). Similarly, if the Server wishes to issue privacy-preserving certificates, it MAY reject CSRs containing a PermanentIdentifier or HardwareModuleName in the subjectAltName extension. See the for more information.

Hardware Module A new identifier type, hardware-module is introduced to represent the identity of the secure cryptoprocessor that generated the certificate key. The identity is modeled after the HardwareModuleName form described in . It consists of two components: an OBJECT IDENTIFIER to represent the type of hardware module, and a serial number that identifies the specific hardware module. Although specifies that serial numbers can be represented as any sequence of bytes, this specification requires that serial numbers MUST be representable as valid UTF-8 strings consisting of at least one code point and MUST NOT contain a forward-slash "/" (UTF-8: U+002F) character. This restriction ensures that serial numbers can be included in hardware-module identifier string values and that the ABNF production rule for the value is unambiguous.

Representation in Order resources The identifier's value field contains a UTF-8 string representation of the identity of the hardware module. In addition to the value being a valid UTF-8 string, the value MUST match the hardware-module-value production rule as defined in this ABNF syntax: A valid hardware-module-value value is a UTF-8 string that contains a serial number consisting of one or more characters without any forward-slash "/" (UTF-8: U+002F) characters. A forward-slash "/" character and "dotted-decimal" object identifier identifying the hardware type follows the serial number. The Server MUST verify that identifier values in newOrder requests conform to the hardware-module-value production rule and MUST reject requests containing non-conforming values with a "malformed" error. Example of an identifier with the type of the hardware module represented using the OBJECT IDENTIFIER "1.2.3.4" and a serial number of "ABCD":

Representation in Certificate Signing Requests and X.509 Certificates This section describes the X.509 representation of the hardware-module identifier. Other credential types may use the same identifier values with representations appropriate to those credential types. The hardware module identity is included in the Subject Alternative Name extension using the HardwareModuleName form described in . The HardwareModuleName is encoded as an otherName with the OID id-on-hardwareModuleName (1.3.6.1.5.5.7.8.4) and consists of:

• hwType: An OBJECT IDENTIFIER that identifies the type of hardware module
• hwSerialNum: An OCTET STRING containing the hardware module serial number

The value of the hwSerialNum field of the HardwareModuleName MUST be an octet-for-octet match of the hw-serial-num-value value as encoded in the Order resource. If the hw-type-value value is included in the identifier as encoded in the Order resource, then the hwType field of the HardwareModuleName MUST be the encoding of the "dotted-decimal" object identifier encoded as the hw-type-value value. This strict matching requirement ensures that the SAN in the issued certificate appears exactly as it appeared during proof-of-ownership validation, preventing identifier malleability. Serial number allocation schemes may be case-sensitive or otherwise sensitive to exact byte representation, so no normalization or transformation is permitted. To ensure that the identifier as presented in the Order resource and CSR match, the Server MUST perform the logical equivalent of extracting the hw-serial-num-value and hw-type-value values from the CSR and reconstructing the UTF-8 representation of the identifier. The Server MUST then ensure that the UTF-8 representation and the identifier presented in the Order resource are an octet-for-octet match and reject the Order otherwise. Servers that derive identifier values directly from verified attestation evidence and construct the certificate SAN from that evidence, provided the derived values are verified against the attested device identity in the attestation statement, satisfy the intent of this requirement. section 7.4 mandates that "The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request". This document updates to specify that the CSR SHOULD indicate the exact same set of requested identifiers of types permanent-identifier () and hardware-module as the initial newOrder request (identifiers of other types MUST be indicated in the CSR per section 7.4). To support privacy-preserving certificates, Clients MAY omit identifiers of types permanent-identifier and hardware-module in the certificate signing request (CSR). Similarly, if the Server wishes to issue privacy-preserving certificates, it MAY reject CSRs containing a PermanentIdentifier or HardwareModuleName in the subjectAltName extension. See the for more information.

Device Attestation Challenge A Client can prove control over a permanent identifier of a device by providing an attestation statement containing the identifier of the device. The device-attest-01 ACME challenge object has the following format:

type (required, string):

The string device-attest-01.

token (required, string):

A random value that uniquely identifies the challenge.

An example message with a device-attest-01 challenge is provided below: A Client fulfills this challenge by constructing a key authorization () from the token value provided in the challenge and the Client's account key. The Client then generates a WebAuthn attestation object using the key authorization as the challenge. This specification borrows the WebAuthn attestation object representation as described in Section 6.5.4 of for encapsulating attestation formats, but with these modifications:

• The key authorization is used to form attToBeSigned. This replaces the concatenation of authenticatorData and clientDataHash. attToBeSigned is hashed using an algorithm specified by the attestation format.
• Some attestation formats use an external attestation authority that issues a certificate binding the challenge to the device before the Client's account key is available. In these formats, attToBeSigned is formed from the token alone rather than the full key authorization, because the external authority signs at attestation time before the account key thumbprint can be incorporated. The token construction provides freshness. The key authorization construction additionally binds the attestation to a specific account key. The Server MUST process and verify attestations in accordance with the format-specific documentation. Attestation formats whose signing procedure does not incorporate attToBeSigned cannot be used to satisfy this challenge type.
• The authData field carries browser-context data (including the RP ID hash) that has no meaning in the ACME context and SHOULD be omitted.

A Client responds with the response object containing the WebAuthn attestation object in the attObj field to acknowledge that the challenge can be validated by the Server. Clients MAY include additional fields beyond attObj in the response object. Servers MUST ignore unrecognized fields in the challenge response. On receiving a response, the Server constructs and stores the key authorization from the challenge's token value and the current Client account key. To validate a device attestation challenge, the Server performs the following steps:

1. Perform the verification procedures described in Section 6 of .
2. Verify that attToBeSigned contains the key authorization or the token, according to the construction required by the attestation format, and that the value matches what the Server stored.
3. Verify that the attestation statement contains a device identifier and that it matches the identifier in the Order. The means by which the identifier is encoded in the attestation statement are specific to the attestation format.

If any of the steps fail, then the Server MUST respond to the Client with a badAttestationStatement error and set the status of the challenge object to invalid. The Server MUST provide the reason for rejecting the challenge in the detail field of the problem document, unless disclosing the reason to the Client presents a privacy concern; see for more information. An example challenge response containing the WebAuthn attestation object in the payload: The WebAuthn payload MAY contain any identifiers registered in "WebAuthn Attestation Statement Format Identifiers" and any extensions registered in "WebAuthn Extension Identifiers" .

Operational Considerations

Enterprise PKI ACME was originally envisioned for issuing certificates in the Web PKI, however this extension is primarily useful in enterprise PKI. The sections below provide operational considerations for enterprise PKIs.

External Account Binding An enterprise CA likely only wants to receive requests from authorized devices. It is RECOMMENDED that the Server require a value for the externalAccountBinding field to be present in newAccount requests, as defined by Section 7.3.4 of . If an enterprise CA desires to limit the number of certificates that can be requested with a given account, including limiting an account to a single certificate, after the desired number of certificates have been issued to an account the Server MAY revoke the account as described in Section 7.1.2 of .

Attestation Posture Enterprise deployments often consist of heterogeneous device fleets where not all devices are capable of hardware attestation. A Server MAY offer device-attest-01 alongside other challenge types within a single authorization, allowing capable devices to complete device-attest-01 while other devices complete an alternative challenge. This posture allows operators to observe fleet attestation coverage before enforcing policy and is compatible with phased deployments. Servers MAY rely on other authorization mechanisms, such as external account binding or pre-authorized accounts, to establish device identity instead of completing the device-attest-01 challenge.

Multiple Challenge Types permits a Server to offer multiple challenge types within a single authorization, with any one being sufficient to complete it. Servers MAY offer device-attest-01 alongside other challenge types for the same authorization, allowing capable devices to attest while other devices use an alternative challenge type.

Attestation Trust Attestation formats differ in the authority that enforces the boundary around the attested key and in the claims that authority can make. At one end, dedicated security hardware (such as a TPM or HSM) provides manufacturer-backed guarantees that the key is generated and stored within the hardware and cannot be exported. At the other end, OS-enforced isolation boundaries (such as platform keystores protected by the operating system kernel) provide meaningful key protection guarantees without discrete security hardware. Intermediate cases include TEE-based attestation where a hypervisor or trusted execution environment acts as the authority. Server operators must consider the trust properties of each attestation format when establishing issuance policy, including the nature of the authority making the attestation and the key protection guarantees it can assert. The key authorization construction described in also contributes to this trust model: formats that use the full key authorization as attToBeSigned bind the attestation to a specific account key, while formats that use the token alone provide freshness without account key binding.

Privacy Considerations This section analyzes the privacy implications of the permanent-identifier and hardware-module identifier types introduced in this document. The guidance here is informed by the threat taxonomy defined in and is intended to help implementers make informed decisions about whether and when to include these identifiers in certificate requests and issued certificates. Both identifier types represent unchanging hardware-bound properties of a device. Unlike domain names or other identifiers whose lifetime is bounded by operational changes, these identifiers typically persist across the entire operational life of a device and cannot be rotated or revoked by the device owner. This permanence has material privacy consequences that implementers must weigh carefully. The privacy analysis below addresses the two phases in which these identifiers appear: the attestation exchange between the Client and server during challenge validation, and the optional embedding of identifiers in the issued certificate.

Identification and Correlation The permanent-identifier type encodes a manufacturer-assigned device identity, typically a serial number. The hardware-module type encodes the identity of the secure cryptoprocessor that generated the certificate key. In both cases, the identifier is globally unique within its assigner scope and unchanging for the lifetime of the device or hardware module. From the perspective of Section 5.2.2, such identifiers enable direct identification of a device across protocol interactions, deployments, and time. Any entity that receives or observes these identifiers, including the server, intermediary infrastructure, and any relying party that processes the issued certificate acquires an observable reference that can be used to track the device's certificate issuance history, renewal patterns, and operational context. When the same permanent-identifier or hardware-module value appears across multiple certificate requests (as it will in any recurring renewal workflow), it enables correlation: an observer with access to server logs can reconstruct the full lifecycle of a device's certificate activity. Similarly, when such identifiers are included in issued certificates, logging issued certificates in a central location (in certificate transparency logs, etc.) produces a persistent device audit trail regardless of whether the log operator intends to maintain one. Implementers should assess whether the operational benefit of unchanging device identification outweighs this correlation exposure. In deployments where device anonymity or pseudonymity is a requirement, such as systems handling sensitive workloads on behalf of individuals, implementers should consider whether alternative validation mechanisms that do not bind the certificate to a permanent hardware identifier are more appropriate.

Fingerprinting via Attestation Payloads The device-attest-01 challenge response carries a WebAuthn attestation object that may contain significantly more information than the identifier value alone. Depending on the attestation format, this payload may include device model, firmware version, bootloader state, hardware security level, and operating system version. Even when the resulting certificate is issued in a privacy-preserving form that omits the identifier from the subjectAltName extension (see Section 3.2 and Section 4.2), the attestation payload itself is transmitted to and evaluated by the server during challenge validation. This constitutes a fingerprinting surface as defined in Section 3.2. The combination of a hardware serial number, hardware type OID, and firmware attestation attributes may uniquely identify not just the device model but the specific device unit, even in the absence of an explicit permanent-identifier value. Implementers operating servers should apply data-minimization principles by evaluating only the attributes necessary to make the authorization decision. The full attestation payload should not be retained beyond the challenge-validation exchange unless there is a specific, documented operational requirement to do so. Implementers operating ACME Clients should be aware that the attestation format selected may expose more device state than is necessary to satisfy the server's authorization policy. Where multiple attestation formats are available, Clients should prefer formats that minimize the set of disclosed attributes.

Secondary Use of Attestation Data The server receives attestation data in the context of authorizing a certificate issuance request. Section 5.2.3 identifies secondary use as the processing of data for purposes beyond the original collection context and as a distinct privacy threat. Attestation payloads received during challenge validation may contain information about device health, software configuration, and hardware capability that is operationally useful beyond certificate issuance. For example, for asset inventory, compliance monitoring, or security posture assessment. Implementers operating servers must clearly define and document the purposes for which attestation data is processed and must not process attestation data for purposes materially different from authorization of the certificate request without explicit policy disclosure to the device owner or operator. Implementers integrating ACME device attestation into enterprise PKI platforms should publish a clear attestation data handling policy that specifies what attributes are evaluated, how long they are retained, and whether they are shared with other systems.

Privacy-Preserving Certificate Issuance This document provides an explicit mechanism to decouple attestation-based validation from identifier disclosure in the issued certificate. Clients MAY omit the permanent-identifier or hardware-module from the CSR, and servers MAY issue certificates that do not contain these identifiers in the subjectAltName extension, even when those identifiers were used to authorize the request. Implementers should treat this privacy-preserving mode as the default posture unless there is a specific operational requirement for the identifier to appear in the certificate. The following considerations apply to this decision:

• If the issued certificate will be presented to relying parties outside the issuing organization's trust boundary, embedding a permanent-identifier or hardware-module value in the certificate enables those relying parties to correlate certificate presentations with specific physical hardware. This may be acceptable in closed enterprise environments but is likely inappropriate in any context where the certificate is presented to external services, counterparties, or public infrastructure.
• If the certificate is used for mutual TLS in a workload identity context, embedding an unchanging hardware identifier couples the cryptographic identity of the workload to the physical device rather than to the logical identity of the workload. This can impede key rotation, device replacement, and workload migration, in addition to creating the correlation risks described above. In such cases, implementers should prefer logical workload identifiers (such as SPIFFE URIs) in the issued certificate and treat the hardware attestation as a bootstrap authorization mechanism only.
• If the certificate is intended for use in certificate transparency logs, implementers must consider that embedding a permanent-identifier or hardware-module value will make that identifier permanently and publicly discoverable, indexed by issuance time, issuer, and subject. This constitutes an irreversible disclosure under Section 5.2.4 and should be avoided unless public discoverability of the device identifier is an explicit operational requirement.

Stored Data and Account Binding This document recommends the use of externalAccountBinding to pre-authenticate device requests to an enterprise server. When an ACME account is persistently bound to a device identity, the server's account store contains a durable mapping between the cryptographic account credential and the physical device. Per Section 5.1.2, this stored association constitutes a target for compromise: an attacker who obtains the account store gains not only account credentials but a historical record of device-to-identity mappings across all certificate issuances. Implementers operating servers should store account-to-device bindings using the minimum fidelity necessary for authorization decisions. Where the operational requirement is only to confirm that a given device is authorized to request certificates, it may be sufficient to store a hash or other one-way transformation of the device identifier rather than the identifier itself. Implementers should also define and enforce retention limits on historical account-to-certificate linkage records.

Implementer Decision Guidance Implementers considering whether to include permanent-identifier or hardware-module in CSRs and issued certificates should work through the following questions before enabling these identifiers:

• Is unchanging hardware identity in the certificate necessary for the relying party to make authorization decisions, or is it sufficient for the server to have validated it at issuance time? If the latter, prefer privacy-preserving certificate mode.
• Will the certificate be logged to a certificate transparency log or otherwise made publicly accessible? If so, embedding a permanent hardware identifier creates an irrevocable, publicly indexed disclosure and should be avoided unless explicitly required.
• Will the certificate be presented to parties outside the issuing organization's administrative control? If so, consider whether those parties should have visibility into the device's hardware identity.
• Does the deployment have requirements for device replacement or key rotation without service interruption? Binding the certificate's identity to a specific hardware module OID and serial number complicates these operational scenarios and may require reissuance policies that expose additional identifier churn in logs.
• What is the attestation data handling policy of the server operator? If this is not documented or auditable, device operators should treat the attestation exchange as a full disclosure of all attributes present in the attestation payload.

Security Considerations Please reference for other security considerations. See Section 13 of for additional security considerations related to attestation statement formats, including certificate revocation. Key attestation statements may include a variety of information in addition to the public key being attested. While not described in this document, the Server MAY use any policy when evaluating this information. This evaluation can result in rejection of a certificate request that features a verifiable key attestation for the public key contained in the request. For example, an attestation statement may indicate use of an unacceptable firmware version. The token value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters (=). The token value MUST be generated using a cryptographically secure pseudorandom number generator (CSPRNG). See , Appendix C.1 for guidance on random number generation. The binding between the certified public key and the device identifier is established through the attestation statement rather than through the CSR alone. The attestation authority cryptographically binds the public key to the device identity, either by signing the attestation statement directly, by issuing an attestation certificate, or by other cryptographic means specific to the attestation format. The Server verifies this chain: the attestation is produced by a trusted attestation authority, the public key in the attestation matches the public key in the CSR, and the device identifier in the attestation matches the identifier in the Order. This three-way binding is the basis on which the Server can associate a certified public key with a particular device.

IANA Considerations

ACME Identifier Types The "ACME Identifier Types" registry is to be updated to include the following entries:

Label	Reference
permanent-identifier	RFC XXXX
hardware-module	RFC XXXX

ACME Validation Method The "ACME Validation Methods" registry is to be updated to include the following entries:

Label	Identifier Type	ACME	Reference
device-attest-01	permanent-identifier	Y	RFC XXXX
device-attest-01	hardware-module	Y	RFC XXXX

New Error Types The "ACME Error Types" registry is to be updated to include the following entry:

Type	Description	Reference
badAttestationStatement	The attestation statement is unacceptable (e.g. not signed by an attestation authority trusted by the CA)	RFC XXXX

Normative References This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK] This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] 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. 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. n.d. Google Mozilla Microsoft Microsoft Yubico 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. 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 offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

Acknowledgments We thank the participants on the ACME Working Group mailing list for their insightful feedback and comments. In particular, the authors extend sincere appreciation to Aaron Gable, Christopher Inacio, Deb Cooley, Eric Vyncke, Mahesh Jethanandani, Mike Bishop, Mike Ounsworth, Mohamed Boucadair, Richard Barnes, Roman Danyliw, and Tommy Jensen for their reviews and suggestions, which greatly improved the quality of this document.

Contributors These contributors provided significant implementation experience using Smallstep CA, which shaped the evolution and design of this document. Mariano Cano Smallstep mariano.cano@gmail.com Herman Slatman Smallstep mail@hermanslatman.nl