| Internet-Draft | ACME PK Challenge | July 2025 |
| Geng, et al. | Expires 8 January 2026 | [Page] |
This document specifies an extension to the ACME protocol [RFC8555] that enables Acme server to use the public key authentication protocol to verify that the real certificate applicant behind the Acme client has control over the identity and to ensure strong consistency between the identity in the challenge phase and the identity of the final certificate issued. This document also proposes a process extension for removing CSR at the certificate application phase.¶
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 8 January 2026.¶
Copyright (c) 2025 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.¶
When ACME was first introduced, its main focus was on the challenge of verifying control of identifiers such as domain names. ACME later expanded to support verification of user/device ownership and issuance of the certificate for user/device. Based on the sso-01 [I-D.biggs-acme-sso] for verifying email identifiers, this document proposes a more general ACME challenge type oriented towards verifying user/device ownership. The challenge enables the Acme server to verify the control of the identity of the certificate applicant behind the Acme client via a public key authentication protocol, truly realizing what the Acme WG Charter describes as "The processing must also confirm that the requesting party has access to the private key that corresponds to the public key that will appear in the certificate". On the other hand the challenge avoids public key replacement attacks.¶
Typically, the Acme client acts as a unified entry point for automated certificate requests and communicates with the Acme server. In the process of requesting a certificate for the user/device, the Acme server does not verify whether the public key in the Certificate Signing Request (CSR) is owned by the applicant, although it can verify the applicant's control over an identifier through the challenge phase. This mechanism has the risk of public key replacement, i.e., an untrustworthy or compromised Acme client may replace the public key in the CSR after completing the challenge, so that the applicant who completes the challenge is not the same as the user corresponding to the public key of the issued certificate. This ultimately allows certificates to be issued to unrelated or malicious entities.¶
This document proposes a new ACME challenge type pk-01 that verifies the identity of the applicant by means of public key authentication and is directly bound to the authorization process. The Acme server requires that the public key in the challenge phase be consistent with the public key in the final CSR submission, eliminating the risk of public key replacement attacks. Considering the complicated task of CSR parsing, this document supplements a simplified process of removing CSR (see Section 7), which directly issues a certificate after successful challenge phase, realizing the consistency of the public key in the challenge phase and in the issued certificate.¶
More critically, the challenge is designed for the Acme server to work in coordination with a trusted identity provider (IdP), which endorses the relationship between the applicant and its public key. Enables Acme server to recognize the real applicant behind through Acme client, and establishes a complete chain of trust from Acme server to applicant. This trust binding mechanism is particularly important in the scenario of issuing certificates for user/device, ensuring that the certificate clearly identifies the legitimacy of the holder of the identifier.¶
Note that this document requires an IdP that records public keys. The IdP is the trust center for the automated certificate request process, which stores the trusted user's public key and possibly the identity information corresponding to the public key. Specific identity information can be selected based on the actual operations. Before the certificate request process, the user's public key should have been entered into the IdP in some way, such as self-registration by the user or LDAP-based import.¶
It is worth noting that the existing external account binding in ACME [RFC8555] is primarily used to authenticate Acme client account identitie and is not the same as the validation of certificate applicant identities proposed in this document. The main purpose of this document is to issue certificates to applicant who actually pass the challenge, ensuring that the public key of the applicant who completes the challenge and the public key of the certificate issued are consistent. This document strictly corresponds to the concept of “Prohibit the reuse of Acme client public key to request certificate” in the standard ACME process. If the Acme client's public key is used to apply for a certificate, it is equivalent to an identity impersonation/injection attack by the Acme client on the certificate applicant. The pk-01 challenge presented in this document avoids this very problem by allowing the Acme server to see the actual applicant behind the Acme client, enhancing security.¶
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.¶
## Problem Statement¶
The standard ACME automated certificate application process can be summarized in three phases: ACME account management, challenge phase and certificate application phase. The current decoupled design of the three-part framework brings many benefits, but there are also security issues. The public key of the applicant who completes the challenge in phase 2 and the public key in the issued certificate in phase 3 is not consistently bound. Problems can occur where the users in the challenge phase are not the same as the users who actually receive certificates.¶
The content of ACME application certificates can be categorized into resources and user/device. The resource category is mainly server-side resources (e.g., domain names), such as dns-01[RFC8555], http-01[RFC8555][RFC8738], tls-alpn-01[RFC8737][RFC8738] and so on. The user/device category is mainly such as sso-01 [I-D.biggs-acme-sso], device-attest-01 [I-D.acme-device-attest], and e-mail-reply-00 [RFC8823] and so on. Public key replacement attacks are more likely to occur in scenarios where certificates are issued for the user/device.¶
In that case, the applicant is required to demonstrate resource control (e.g., dns-01, http-01, etc.). This is a typical use case for the initial focused application scenario of Web PKI domain name certificates presented in the Acme WG Charter. In this use case, the applicant controls the resource and needs to grant Acme client privileges to directly prove its ownership of the resource to complete the interrogation, in exchange for Acme server's trust, so as to obtain the certificate. Thus both Acme server and applicant need to trust Acme client.¶
┌────────────┐ ┌───────────────┐
│ DNS │ Resource Validation │ ACME Server │
│ │ ◄───────────────────► │ (IdP_A) │
└────────────┘ └───────────────┘
▲ ▲
\ /
\ /
\ /
\ ┌────────────────┐ /
\ │ ACME Client │ /
\ │ (SK_1,PK_1) │ ▼
┼────────────────┼
│ Application │
└────────────────┘
In this case a third party IdP_B exists to provide identity assertion for the applicant. This is commonly seen in situations where certificates are issued for user/device within an organization, where the user/device already hold their own public-private key pairs.¶
Applicant has registered the identity public key PK_2 under IdP_B to get the provided identity assertion of IdP_B. Acme server trusts Acme client, but applicant can't fully trust Acme client and holds private key privileges by itself without granting them to other. As a result, when the applicant completes the challenge, it cannot trust whether the Acme client will apply for certificates for other malicious users with the help of its own challenge success record, i.e., the Acme client may be attacked so as to replace the public key information in the CSR to apply for certificates to the Acme server. This causes an adversary to impersonate a legitimate user/device. And Acme server can't “see” the applicant behind the Acme client.¶
┌───────────┐ ┌───────────┐
│User's IdP │ │ACME Server│
│ (IdP_B) │ │ (IdP_A) │
└───────────┘ └───────────┘
▲ ▲
\ /
\ /
\ /
\ ▼
\─────────────┐ ┌────────────┐
│ Application │ │ACME Client │
│ (SK_2,PK_2) │??????│(SK_1,PK_1) │
└─────────────┘ └────────────┘
This document proposes the pk-01 challenge to construct a complete chain of trust from the Acme server to the applicant, so that certificates can be issued to the applicants (users/devices) that actually pass the challenge. Acme server indirectly verifies the authenticity of PK_2 behind the Acme client proxy and who holds control of SK_2 by trusting IdP_B. A complete chain of trust from the Acme server to the applicant is constructed so that the Acme server verifies the control of the identity by the applicant behind the Acme client through a public key authentication protocol.¶
┌───────────┐ PK-01 ┌───────────┐
│User's IdP │# # # # # # # # # # # # # │ACME Server│
│ (IdP_B) │ │ (IdP_A) │
└───────────┘ └───────────┘
# ▲
# /
# /
PK-01 /
# ▼
#─────────────┐ ┌────────────┐
│ Application │ │ACME Client │
│ (SK_2,PK_2) │ │(SK_1,PK_1) │
└─────────────┘ └────────────┘
Under the security model of Section 3.1.2, because of the presence of User's IdP, instead of granting the Acme client privileges and trust equivalent to resource control as it did in Section 3.1.1, the applicant only needs to give the Acme client the minimum required trust to require the Acme client to fulfill its proxy responsibility for requesting certificates. PK-01 provides end-to-end security when crossing trust domains from Acme server to applicant (user/device), preventing attacks from both external and internal sources, constructing a stronger generalized security model. It is also applicable and relevant for authentication scenario use cases between cross-trust domains.¶
The pk-01 challenge presented in this document prevents public key replacement attacks on the other hand (especially in 8.2 scenarios). With the proposed new identifiers, the consistency of the PK in the challenge phase and the pk in the final issued certificate is guaranteed against public key replacement attacks.¶
New identifier types are proposed in this document to ensure strong consistency between the identity corresponding to the final certificate issued and the identity of the certificate applicant. And the public key authentication protocol is utilized to provide strong security for the authentication process.¶
The identifier pk can be used in lightweight binding cases, such as user-bound devices, where the Acme server needs to verify the consistency of the pk identifier in the final certificate issuance phase and in the challenge phase. The identifiers csr and selfsign-cert can be used in cases where specific identity information is bound (including pk, subject, etc.). The Acme server needs to verify the consistency of this identifier value during the final certificate issuance phase to prevent the identity information from being tampered with midway. Especially when csr is specified as the identifier, the applicant can send the csr when submitting the certificate order without submitting the csr file again in the final certificate application phase, which corresponds to the simplified process of revocation of csr in Section 7. Implementations MUST NOT use the challenge of type pk-01 as options to validate a type identifier other than the following.¶
"identifier": { "type": "pk", "value":"MIGfMA0GC***GbQIDAQAB"}
"identifier": { "type": "selfsign-cert", "value":"MIIHSDCC***AU1GH3xQ="}
"identifier": { "type": "csr", "value":"MIICljCCA***RL64+taHbP"}
¶
The pk-01 challenge type requires the client to access the specified pk-url to start the challenge and complete the verification of the corresponding private key control of the declared public key. A challenge of this type MUST include all required fields described in section 8 of [RFC8555]. In addition, the following fields are defined for this specific type of challenge:¶
pk_url (required, string): The URL to start the pk-01 challenge type process. The server must include enough information in the URL to allow the request to be associated with a specific challenge and to be able to point to a specific PK provider or public key server.¶
pk_provider (optional, string): The domain of the PK provider relied upon for this challenge. Acme server MAY rely upon any number of PK providers and public key servers, however each MUST be represented as a different entry in the challenge array. The applicant can use this field to differentiate the list of providers and select the most appropriate one. If this field does not exist, the Acme server's default identity provider is used. The server MUST NOT present more than one pk-01 challenge with the same pk_provider value in a single authorization, including values for unprovided fields.¶
process options (optional, string): Indicate options for the ACME process. The Acme server provides a choice between the standard ACME protocol flow (standard) or a removed CSR file (simplified). If this field is not exist, the ACME standard process is executed by default.¶
The server MUST sets the status of the challenge to processing after receiving a response from the client within the validity period. If the client completes the proof of ownership of the private key corresponding to public key and the generated identity assertion validates the declared identifier, then the status of the challenge is set to "valid". If the server fails to validate the public key against the private key control or fails to validate the declared identifier, the status of the challenge will be set to "invalid".¶
{
"type": "pk-01",
"url": "https://example.org/acme/chall/abc123_defg456",
"status": "pending",
"pk_url": "https://example.org/acme/start-pk",
"pk_provider": "https://pk-identity-provider.org/",
"standardization": "standard" | "simplified",
}
¶
The general process of the PK challenge is illustrated by the standard ACME certificate issuance sequence. For convenience, it is divided into three phases: certificate application, public key authentication and certificate issuance phase.¶
In the first phase, the client submits the certificate request, which carries the public key information at the start. The server responds to the client that it must satisfy authentication. The client can select one of the various authentication methods it supports and inform the server. The server returns what needs to be accomplished for this authentication method. This content will contain the "start URL".¶
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~ Certificate Application ~~~~~~~~~~~~~~~~~~~~~~~~~
request new order(pk) -------->
<-------- required authorizations
request authorization -------->
<-------- PK challenge with start URL
~~~~~~~~~~~~~~~~~~~~ public key authentication ~~~~~~~~~~~~~~~~~~~~~~~~~~
request on PK start URL --------->
ACME redirect to provider
authentication request
provider authenticates client (not shown here)
provider redirect to ACME --------->
identity assertion
validate provider assertion
record challenge as valid
<--------- redirect to client
~~~~~~~~~~~~~~~~~~~~ certificate issuance ~~~~~~~~~~~~~~~~~~~~~~
request challenge ----------->
<---------- valid
request finalize (CSR) -----------> (Verify pk consistency)
<----------- finalize URL
finalize ----------->
<----------- certificate
In the second phase, the client performs a request for one of the authentication methods and the server responds to it. Among these may be one or more challenge of type pk-01, which can be used to start the process of authentication based on the web through different "start URL". The request redirects the client to the applicant and the IdP, which conducts the public key authentication protocol with the applicant. After successfully providing validation to the IdP, the Acme server records the associated challenge as validated (or not). Among them, the whitelisting mechanism can be supplemented here. Legitimate public key identities will be registered in advance at the Acme server to form a trusted list, and after the public key authentication protocol is passed, the public key identity will be signed by the IdP and then passed to the Acme server to verify the application authority of the public key (whether it is in the trusted list), thus restricting unauthorized public key identities.¶
In the process of authentication, the process of this document is quite different from the way of sso. The authentication process is primarily authenticated through public key authentication protocols (e.g. aPAKE/Opaque [I-D.irtf-cfrg-opaque]). The IdP here also needs to support the appropriate public key authentication protocols.¶
The redirection to the client then indicates that the authentication process has been completed, at which point it can be demonstrated whether the applicant has the private key corresponding to the public key in the application order. The user's private key information is always private in this process and does not need to be provided to the agent. After completing the authentication, it redirects the client to the certificate request process.¶
In the last phase, after completing authentication the client eventually submits the CSR. This document requires that the public key contained in the CSR must match the public key in the starting order. In this way, tampering with public key information can be avoided. Other processes are consistent with the standard process.¶
Public key authentication is essentially authenticating the control of the corresponding private key of a public key and pk_url allows the client to initiate the public key authentication process. The server must accept GET requests for pk_url. Upon receiving such a request:¶
The Acme server receives the request and redirects it to the IdP. IdP instance holds the public key, e.g. IdP instances supporting the aPAKE/Opaque protocols.¶
The IdP requires the requesting party to perform authentication to verify that it holds the private key corresponding to the public key. The IdP will include supported public key verification protocols in the verification request, protocols that include, but are not limited to (1) challenge public key signature and verify signature, (2) Opaque/AKE and (3) non-interactive zero-knowledge (NIZK) discrete logarithm equality (DLEQ) proof, etc. The client selects one of the protocols to perform the authentication process.¶
After successfully authenticating the identity, the IdP returns the user's information and the logged-in device public key information to the Acme server. When the Acme server receives the request, it checks whether the device public key is consistent with the public key in the order. When the ACME server receives the request, it MUST check whether the device public key is consistent with the public key in the order. For identifiers of type csr and selfsign-cert, identity consistency checks are also required. The challenge is successful if the check passes.¶
ACME Server Applicant IdP
~~~~~~~~~~~~~~~~~~~~~~~~~~~provider authenticates client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACME redirect to provider ------------------------------------------------->
<--------- list of supported
public key authentication protocols
select authentication protocol --------->
verification <----------------------------------------------- redirect to ACME Server
When the Acme server receives a response from IdP, it must validate it and update the appropriate challenge status. The server updates the challenge status to "valid" if the provider validation is successful, or to "invalid" if it is unsuccessful.¶
In the case of public key verification, the IdP acts as the asserting party and conducts a public key authentication agreement with the applicant to obtain public key information and identity information about the subject (applicant). The Acme server acts as a relying party that receives identity information from the IdP. The Acme server verifies the consistency of the public key and the order public key after receiving the public key and identity information. For the identifiers of type csr and selfsign-cert, the identity consistency needs to be further checked on the basis again.¶
The standard process, as defined in section 7.4 of [RFC8555]. Once the client has been authorized in all respects, it can proceed with the completion of the order. The client SHOULD use the public key declared in the order as the public key in the CSR. If the order identifier type is csr or selfsign-cert, the commonName, subjectAltName, etc. fields should be filled in the CSR. Then the CSR, encapsulated as specified, is submitted to the ACME server.¶
The server needs to validate the order against the identifier after receiving a request from the client to complete the order. The client's request for order fulfillment can only be continued under the condition that all checks have been passed.¶
Since the Acme server has already obtained the user/device's authenticated public key during the challenge phase, there is no need to send the CSR in the final phase, since the CSR no longer carries parts that are not present in other parts of the ACME protocol.¶
The process after removing the CSR, starting from the client issuing a new order request to the ACME server validating the challenge, is consistent with the process in Section 6. It is only in the final certificate issuance phase that the ACME server updates the challenge record to verified (or unverified) and automatically requests a certificate for the applicant (verified public key) when the result is verified. There is no need to send the CSR file again.¶
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~~ certificate issuance ~~~~~~~~~~~~~~~~~~~~~~~~~~~
request challenge ---------->
<--------- valid
issue certificates
finalize ---------->
<---------- certificate
## Temporary Certificate with One-time Key¶
The public key authentication protocol in pk-01 can be chosen OPAQUE protocol to realize the temporary certificate with one-time key. For example, in an enterprise cooperation scenario, each company has its own private CA, and a member of company A needs to have a temporary meeting with a member of company B, Bob, and needs to authenticate and authorize Bob. The most suitable method is that the CA of company A signs a temporary certificate for him for this meeting.¶
Alice, a legitimate user in company A, generates a temporary ID and password pw for Bob (pw performs OPAQUE protocol for registration), passes the ID and pw to Bob via out-of-band, and Bob generates a temporary public-private key pair (pk,sk) for this purpose. Bob registers the temporary public key pk at the ACME server after authentication through the OPAQUE protocol with the help of the password pw, and then applies for a temporary certificate issued by the CA of Company A that is bound to pk and ID.¶
The certificate applicant can pick a suitable public key authentication protocol according to the specific usage scenario. It can be WebAuthn authentication, OPAQUE, private key signature checking, non-interactive zero-knowledge (NIZK) discrete logarithm equality (DLEQ) proof, and so on.¶
When a certificate is revoked, it is also necessary to prove whether the user is authorized to revoke it. Thus, the PK-01 challenge proposed in this document can also be used to prove that the user applying for revocation does have the ownership of the corresponding private key of the certificate, so as to realize a more reliable revocation.¶
The "ACME Identifier Types" registry is to be updated to include the following entries:¶
+----------------+------------------+ | Label | Reference | +----------------+------------------+ | pk | RFC XXXX | +----------------+------------------+ | csr | RFC XXXX | +----------------+------------------+ | selfsign-cert | RFC XXXX | +----------------+------------------+¶
The "ACME Validation Methods" registry is to be updated to include the following entries:¶
+------------+-------------------------+---------+------------+ | Label | Identifier Type | ACME | Reference | +------------+-------------------------+---------+------------+ | pk-01 | pk/csr/selfsign-cert | Y | RFC XXXX | +------------+-------------------------+---------+------------+¶