Auto-discovery mechanism for ACME authorized clients
draft-vanbrouwershaven-acme-client-discovery-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Paul van Brouwershaven , Mike Ounsworth , Corey Bonnell , Iñigo Barreira , Q Misell | ||
| Last updated | 2024-02-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Related Implementations |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vanbrouwershaven-acme-client-discovery-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
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,
<https://datatracker.ietf.org/doc/html/draft-
vanbrouwershaven-acme-auto-discovery-03>.
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,
<https://www.rfc-editor.org/rfc/rfc5785>.
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]