| Internet-Draft | ACME Client Discovery | February 2024 |
| van Brouwershaven, et al. | Expires 16 August 2024 | [Page] |
A significant challenge in the widespread adoption of the Automated Certificate Management Environment (ACME) [RFC8555] 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 [I-D.vanbrouwershaven-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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://vanbroup.github.io/acme-client-discovery/draft-vanbrouwershaven-acme-client-discovery.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-client-discovery/.¶
Discussion of this document takes place on the Automated Certificate Management Environment Working Group mailing list (mailto:acme@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/acme/. Subscribe at https://www.ietf.org/mailman/listinfo/acme/.¶
Source for this draft and an issue tracker can be found at https://github.com/vanbroup/acme-client-discovery.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 August 2024.¶
Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Automated Certificate Management Environment (ACME) [RFC8555] 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 [I-D.vanbrouwershaven-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.¶
A user creates an account at server.example.¶
The user specifies at server.example that client.example is authorized to request certificats on their behalf for the domain customer.example.¶
The ACME server server.example downloads the known public keys from https://client.example/.well-known/acme-keys and will regularly check for changes.¶
The ACME client client.example registers its key at server.example, which will only succeed if any of the customers have authorized client.example.¶
The ACME client client.example makes an ACME request to the ACME server from server.example for domain customer.example.¶
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.¶
The ACME client continues normal operation according to [RFC8555].¶
The following value has been registered in the "Well-Known URIs" registry (using the template from [RFC5785]):¶
URI suffix: acme-keys Change controller: IETF Specification document(s): RFC XXXX, Section Y.Z Related information: N/A¶
RFC Editor's Note: Please replace XXXX above with the RFC number assigned to this document¶
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 [RFC8555]. 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.¶
TODO acknowledge.¶