Automated Certificate Management Environment P. van Brouwershaven Internet-Draft M. Ounsworth Intended status: Standards Track Entrust Expires: 18 August 2024 C. Bonnell DigiCert I. Barreira Sectigo Q. Misell AS207960 15 February 2024 Auto-discovery mechanism for ACME authorized clients draft-vanbrouwershaven-acme-client-discovery-00 Abstract 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. About This Document 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/. van Brouwershaven, et al.Expires 18 August 2024 [Page 1] Internet-Draft ACME Client Discovery February 2024 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. Status of This Memo 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 18 August 2024. Copyright Notice 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. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. Well-Known URI for the ACME Directory . . . . . . . . . . 5 van Brouwershaven, et al.Expires 18 August 2024 [Page 2] Internet-Draft ACME Client Discovery February 2024 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.1. Attacker Control Over Well-Known Directory . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Introduction 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. van Brouwershaven, et al.Expires 18 August 2024 [Page 3] Internet-Draft ACME Client Discovery February 2024 3. 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 [RFC8555]. van Brouwershaven, et al.Expires 18 August 2024 [Page 4] Internet-Draft ACME Client Discovery February 2024 +----------------+ +----------------+ +----------------+ | | | | | | | | | ACME Server | | ACME Client / | | User | | / CA | | Service Prov. | | | | | | | +----------------+ +----------------+ +----------------+ | | | | 1. Create account | | +--------------------->| | | | | | 2. Authorize client | | +--------------------->| | | | 3. Register key | | |<---------------------| | | | | | 4. Verify key with | | | info from well-known | | +--------------------->| | | | | | 5. Request cert | | |<---------------------+ | | | | | 6. Normal operation | | |<-------------------->| | | | 4. Implementation Considerations 5. IANA Considerations 5.1. Well-Known URI for the ACME Directory 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 6. Security Considerations van Brouwershaven, et al.Expires 18 August 2024 [Page 5] Internet-Draft ACME Client Discovery February 2024 6.1. 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 [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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 7.2. Informative References [I-D.vanbrouwershaven-acme-auto-discovery] van Brouwershaven, P., Ounsworth, M., Bonnell, C., Barreira, I., and Q. Misell, "Auto-discovery mechanism for ACME servers", Work in Progress, Internet-Draft, draft- vanbrouwershaven-acme-auto-discovery-03, 15 February 2024, . van Brouwershaven, et al.Expires 18 August 2024 [Page 6] Internet-Draft ACME Client Discovery February 2024 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . Acknowledgments TODO acknowledge. Authors' Addresses Paul van Brouwershaven Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: paul.vanbrouwershaven@entrust.com Mike Ounsworth Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: mike.ounsworth@entrust.com Corey Bonnell DigiCert, Inc Pittsburgh, PA United States of America Email: corey.bonnell@digicert.com Iñigo Barreira Sectigo (Europe) SL Rambla Catalunya 86, 3 1. 08008 Barcelona. 08008 Barcelona Spain Email: inigo.barreira@sectigo.com Q Misell AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd Email: q@as207960.net van Brouwershaven, et al.Expires 18 August 2024 [Page 7]