]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada paul.vanbrouwershaven@entrust.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

DigiCert, Inc

Pittsburgh PA United States of America corey.bonnell@digicert.com

Sectigo (Europe) SL

Rambla Catalunya 86, 3 1. 08008 Barcelona. Barcelona 08008 Spain inigo.barreira@sectigo.com

AS207960 Cyfyngedig

13 Pen-y-lan Terrace Caerdydd CF23 9EU Cymru q@as207960.net

Security Automated Certificate Management Environment ACME Auto-discovery A significant challenge in the widespread adoption of the Automated Certificate Management Environment (ACME) is the trust establishment between ACME servers and clients. While ACME clients can automatically discover the URL of the ACME server through ACME Auto Discovery , they face difficulty in identifying authorized clients. This draft proposes a solution to this problem by allowing Certification Authority (CA) customers to specify which ACME keys are authorized to request certificates on their behalf by simply providing the domain name of the service provider. Specifically, this document registers the URI "/.well-known/acme-keys" at which all compliant service providers can publish their ACME client public keys. This mechanism allows the ACME server to identify the specific service provider, enhancing the trust relationship. Furthermore, it provides flexibility to service providers as they can use multiple keys and rotate them as often as they like, thereby improving security and control over their ACME client configurations while giving CA customers the ability to specifically authorize which service providers can request certificates on their behalf. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Automated Certificate Management Environment Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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.

Introduction The Automated Certificate Management Environment (ACME) has been instrumental in streamlining the process of certificate issuance and validation. However, a significant challenge that hinders its widespread adoption is the establishment of trust between ACME servers and clients. While ACME clients can automatically discover the URL of the ACME server through ACME Auto Discovery , identifying authorized clients remains a complex task. This document proposes a solution to this problem by introducing a mechanism that allows Certification Authority (CA) customers to specify which ACME keys are authorized to request certificates on their behalf. This is achieved by simply providing the domain name of the service provider. Specifically, this document registers the URI "/.well-known/acme-keys" where all compliant service providers can publish their ACME client public keys. This mechanism not only enhances the trust relationship by allowing the ACME server to identify the specific service provider but also provides flexibility to service providers. They can use multiple keys and rotate them as often as they like, thereby improving security and control over their ACME client configurations. Moreover, this mechanism empowers CA customers by giving them the ability to specifically authorize which service providers can request certificates on their behalf.

Protocol Overview

1. A user creates an account at server.example.
2. The user specifies at server.example that client.example is authorized to request certificats on their behalf for the domain customer.example.
   1. The ACME server server.example downloads the known public keys from https://client.example/.well-known/acme-keys and will regularly check for changes.
3. The ACME client client.example registers its key at server.example, which will only succeed if any of the customers have authorized client.example.
4. The ACME client client.example makes an ACME request to the ACME server from server.example for domain customer.example.
5. Based on the domain customer.example the ACME server server.example authenticates the ACME client against the known public keys of the service providers that the customer has authorized.
6. The ACME client continues normal operation according to .

| | | | | | 2. Authorize client | | +--------------------->| | | | 3. Register key | | |<---------------------| | | | | | 4. Verify key with | | | info from well-known | | +--------------------->| | | | | | 5. Request cert | | |<---------------------+ | | | | | 6. Normal operation | | |<-------------------->| | | | ]]>

Implementation Considerations

IANA Considerations

Well-Known URI for the ACME Directory The following value has been registered in the "Well-Known URIs" registry (using the template from ):

• RFC Editor's Note: Please replace XXXX above with the RFC number assigned to this document

Security Considerations

Attacker Control Over Well-Known Directory This document introduces a mechanism where ACME client keys are published in a well-known directory of a service provider. This introduces a potential risk if an attacker gains control over this well-known directory. In such a scenario, the attacker could add their own ACME client keys, posing as the service provider. This could potentially allow the attacker to request certificates on behalf of the service provider. However, it's important to note that even if an attacker manages to publish their own keys in the well-known directory, they would still need to prove control over the domain name to obtain a certificate, as per the ACME protocol . This provides an additional layer of security and significantly reduces the risk of unauthorized certificate issuance. Service providers should ensure the security of their well-known directories to prevent unauthorized access.

References Normative References 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. 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. Informative References This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] Entrust Limited Entrust Limited DigiCert, Inc Sectigo (Europe) SL AS207960 Cyfyngedig A significant impediment to the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] is that ACME clients need to be pre-configured with the URL of the ACME server to be used. This often leaves domain owners at the mercy of their hosting provider as to which Certification Authorities (CAs) can be used. This specification provides a mechanism to bootstrap ACME client configuration from a domain's DNS CAA Resource Record [RFC8659], thus giving control of which CA(s) to use back to the domain owner. Specifically, this document specifies two new extensions to the DNS CAA Resource Record: the "discovery" and "priority" parameters. Additionally, it registers the URI "/.well-known/acme" at which all compliant ACME servers will host their ACME directory object. By retrieving instructions for the ACME client from the authorized CA(s), this mechanism allows for the domain owner to configure multiple CAs in either load-balanced or fallback prioritizations which improves user preferences and increases diversity in certificate issuers.

Acknowledgments TODO acknowledge.