Skip to main content

Auto-discovery mechanism for ACME authorized clients
draft-vanbrouwershaven-acme-client-discovery-00

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Paul van Brouwershaven , Mike Ounsworth , Corey Bonnell , Iñigo Barreira , Q Misell
Last updated 2024-08-18 (Latest revision 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 Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

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.

Authors

Paul van Brouwershaven
Mike Ounsworth
Corey Bonnell
Iñigo Barreira
Q Misell

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)