]> Google LLC

davidben@google.com

Security Automated Certificate Management Environment This document defines how an ACME Server may indicate collections of related certificate profiles to ACME Clients.

Introduction As PKIs evolve, an application that authenticates with certificates may need to support a wide range of relying parties, both before and after some change. For example:

• When transitioning to post-quantum cryptography, newer relying parties may expect post-quantum trust anchors, while older, unupdated relying parties still only support classical ones.
• When a certification authority (CA) is found untrustworthy, or its keys rotated or compromised, newer relying parties may expect a newer CA instance, while older, unupdated relying parties may only support the older CA.

As the furthest relying parties diverge, using a single certificate may not be feasible. Applications may then need to obtain multiple certificates, presenting different certificates to different relying parties. defines ACME profiles, a mechanism for ACME Clients to choose between different certificate profiles from a single ACME Server. However, in applications that require certificates from multiple profiles, an ACME Client must know which profiles are needed, and be updated over time. This document extends ACME profiles with profile sets. A profile set is a set of related profiles, defined by the ACME Server. As PKIs evolve, the ACME Server can update its profile sets to reflect relying party needs. In particular, if satisfying all relying parties with a single profile would be infeasible or inefficient, the ACME Server can add a profile to the profile set. An ACME Client configured with a profile set requests a certificate for each profile, automatically incorporating updates to the profile set as part of certificate renewal. This allows the ACME Server to aid ACME Clients in handling PKI evolution.

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.

Extensions to the Directory Resource An ACME Server that wishes for clients to combine multiple certificate profiles MUST include a new field, profileSets, in the meta field of its Directory object. The field is defined as follows:

profileSets (optional, object):

A map of profile set names to objects describing profile sets. Profile and profile set names MUST NOT overlap.

Each profile set is described by a JSON object with the following fields:

description (required, string):

A human-readable description of the profile set.

profiles (required, array of string):

An array of strings, containing the names of the profiles in the profile set.

The human-readable descriptions are analogous to those of the profiles map defined in . Their contents are up to the CA; for example, they might be prose descriptions of the properties of the profile, or they might be URLs pointing at a documentation site. ACME Clients SHOULD present these profile set names and descriptions to their operator during initial setup and at appropriate times thereafter. Profile sets MAY contain overlapping profiles. Together, the profiles and profileSets maps indicate the choices available to the ACME Client operator. An individual profile in a profile set MAY appear in the profiles map if the ACME Server intends it to be a standalone choice for the ACME Client operator. It MAY also be omitted from the profiles map if the ACME Server intends it to be used only in a profile set. For example, the following Directory object defines two profile sets, profile1Ext and profile2, alongside standalone profile1. An ACME Client might interpret this by offering three choices to the operator, profile1, profile1Ext, and profile2, with their corresponding human-readable descriptions. The profile1Ext profile set consists of profile1, which is also a standalone profile, and profileExt, which is a profile-set-only profile. The profile2 profile set consists of three profile-set-only profiles, profile2a, profile2b, and profileExt.

Client Behavior An ACME Client that supports profile sets MAY be configured to obtain certificates according to a profile set, rather than an individual profile. If configured with a profile set, the ACME Client SHOULD request certificates from each profile in the profile set, creating independent, parallel orders for each. Each profile MAY spend different amounts of time in the "processing" state, so the ACME Client SHOULD support multiple orders in the "processing" state in parallel. Each profile MAY produce certificates with different lifetimes, so the ACME Client SHOULD evaluate each certificate for renewal independently. The ACME Client SHOULD periodically re-fetch the Directory object to discover updated profile set definitions. For example, the client MAY re-fetch the Directory when it periodically evaluates its certificates for renewal. If the profile set definition has since changed, the ACME Client SHOULD request certificates for any newly-added profiles. Certificates for newly-removed profiles SHOULD NOT be removed until the ACME Client has provisioned some certificate for each profile in the new profile set definition. ACME Clients MAY implement the above with the following example procedure, run periodically:

1. Fetch the Directory object from the ACME Server.
2. For each profile in the selected profile set: a. Check if the client has an unfinished order for the profile. If so, check if it has entered the "valid" state and download the certificate. b. Otherwise, check if the client already has a certificate for the profile, and if it should be renewed, e.g. because it is soon to expire. c. If the certificate does not exist, or is soon to expire, start a new order with the profile, as described in , and complete its authorizations.
3. Cancel any unfinished orders for profiles that are no longer in the profile set.
4. If the client has a certificate for each profile in the profile set, remove certificates for profiles that are no longer in the profile set.

Determining which certificate to use with which relying party is out of scope for this document. TLS implementations MAY use the procedures defined in Sections and of , as well as other TLS extensions, to select certificates.

Security Considerations The extensions to the ACME protocol described in this document build upon the Security Considerations and threat model defined in , along with the mechanism defined in . It does not change the account management or identifier validation flows, so the security considerations are largely unchanged. It also does not change the lifecycle of any individual order, or issuance from the perspective of the server. Profile sets allow an ACME Server to help ACME Clients configure themselves appropriately during PKI security transitions, such as a change in algorithm, a change in trusted CAs, or CA key rotation. Most PKIs have far fewer ACME Servers than ACME Clients, with ACME Server operators well-connected to relying party requirements. This can help transitions complete more quickly, and thus allow the PKI to realize the security benefits sooner.

IANA Considerations

ACME Directory Metadata Fields IANA will add the following entry to the "ACME Directory Metadata Fields" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at https://www.iana.org/assignments/acme:

Field Name	Field Type	Reference
profileSets	object	This document

References Normative References Internet Security Research Group This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. 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. 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. Informative References 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.

Acknowledgements Thanks to Aaron Gable for feedback on this document, as well as many valuable design discussions.