Automated Certificate Management Environment Working Group F. Geng
Internet-Draft P. Wu
Intended status: Standards Track L. Xia
Expires: 4 September 2025 Huawei Technologies
3 March 2025
Automated Certificate Management Environment (ACME) Extension for Public
Key Challenges
draft-geng-acme-public-key-01
Abstract
This document specifies an extension to the ACME protocol [RFC8555]
that enables ACME servers to use the public key authentication
protocol to verify the certificate applicant's control of the
identity and to ensure strong consistency between the final
certificate issued and the identity of the application order. A
process extension for removing CSR at the certificate application
phase is also proposed in this document.
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 4 September 2025.
Copyright Notice
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
Geng, et al. Expires 4 September 2025 [Page 1]
Internet-Draft ACME PK Challenge March 2025
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Standard Process . . . . . . . . . . . . . . . . . . . . 4
2.2. Remove CSR . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Model . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Attacks and Threat Models . . . . . . . . . . . . . . . . 8
3.1.1. Users/devices generate their own public-private
keys . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. ACME client agent generates public-private keys . . . 10
3.1.3. Terminals apply for their own certificates . . . . . 10
3.2. Defend against Threats . . . . . . . . . . . . . . . . . 10
4. ACME pk Identifier Type . . . . . . . . . . . . . . . . . . . 11
5. ACME pk-01 Challenge Type . . . . . . . . . . . . . . . . . . 11
6. Public Key Authentication & Order Fulfillment . . . . . . . . 12
7. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Various Public Key Authentication Protocols . . . . . . . 14
7.2. Revocation of Certificates . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 15
9.2. ACME Validation Method . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
When ACME was first introduced, its main focus was on the challenge
of verifying control of identifiers such as domain names. ACME has
expanded to support verification of user/device ownership and
issuance of certificates for users/devices. Based on the sso-01
[I-D.biggs-acme-sso] for verifying email identifiers, this document
introduces a more general ACME challenge type for user/device while
avoiding public key substitution attacks.
During the ACME automatic certificate request process, the ACME
server does not check whether the public key of the submitted CSR
belongs to the requesting user in the finalized order request. The
public key substitution attacks may exist for this phase.
Geng, et al. Expires 4 September 2025 [Page 2]
Internet-Draft ACME PK Challenge March 2025
Normally a user has a client for automated applications. And in some
specific application scenarios, some users who expect to obtain
certificates and allow continuous updates cannot integrate such a
client. Such a user might use a proxy as a unified entry point for
automated certificate requests. This proxy might be a system or an
administrator. Based on the standard ACME application process, the
ACME server can communicate with the user and prove the validity of
the user's identity through its proxy. However, standard ACME
application process does not verify that the public key in the
challenge phase and the public key in the CSR are the same when the
CSR is submitted. The proxy may be a malicious adversary that
substitutes the final CSR and applies for a mismatched certificate.
Similarly, in non-proxy scenarios the certificate applicant is the
ACME client, which may generate other arbitrary public-private key
pairs to apply for obtaining mismatched certificates after completing
the challenge phase, i.e., the public key of the finally issued
certificate does not match with the public key in the challenge
phase, which results in a security risk.
This document introduces a new ACME challenge type that verifies the
identity of the applicant by public key authentication. It also
ensures that the public key in the challenge phase is consistent with
the public key in the final CSR submission , eliminating the risk of
public key substitution attacks. Considering the complicated task of
CSR parsing, this document supplements a simplified process of
removing CSR (see Section 2.2), 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.
The protocol interaction process is based on the standard ACME
process. The client only needs to know how to initiate the public
key authentication protocol by opening a given URL, and then
recognize when that interaction has ended. Once finished, the ACME
client can query the status of the challenge to the ACME server to
determine if the challenge was successful and, if so, to complete the
standard ACME process.
Note that this document requires an Identity Provider (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.
Geng, et al. Expires 4 September 2025 [Page 3]
Internet-Draft ACME PK Challenge March 2025
It is worth noting that the existing external account binding in ACME
[RFC8555] is primarily used to authenticate ACME accounts. This
document focuses on the scenario where the ACME client acts as a
proxy to request certificates for multiple users/devices (see
Section 3.1.1), where the ACME client itself can be a malicious
adversary that performs the public key substitution attack, and thus
authentication of the account is not secured. The document proposes
public key verification to verify the identity control of the
certificate applicant and to guarantee the authenticity and
consistency of the public key in the challenge phase and the final
issued certificate against the public key substitution attack.
2. Protocol Overview
This section describes the PK challenge process in terms of the
standard ACME [RFC8555] process for issuing certificates and the
process for removing CSR, respectively.
2.1. Standard Process
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 a 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 its supported authentication methods from a variety of
authentication methods and inform the server. The server returns
what needs to be accomplished for this authentication method. This
content will contain the “start URL”. This authentication method is
similar to that of sso-01 [I-D.biggs-acme-sso] , except that the IDP
here must contain the user's public key and no longer requires a
passphrase or key information.
Geng, et al. Expires 4 September 2025 [Page 4]
Internet-Draft ACME PK Challenge March 2025
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~ Certificate Application ~~~~~~~~~~~~~~~~~~~~~~~~~
request new order(public key) -------->
<-------- 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 public key consistency)
<----------- finalize URL
finalize ----------->
<----------- certificate
Figure 1: Overview of the PK Challenge Flow
Geng, et al. Expires 4 September 2025 [Page 5]
Internet-Draft ACME PK Challenge March 2025
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 object and the IDP, which conducts a 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 user 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, only part of the computation is done. 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.
2.2. Remove CSR
Geng, et al. Expires 4 September 2025 [Page 6]
Internet-Draft ACME PK Challenge March 2025
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~ Certificate Application ~~~~~~~~~~~~~~~~~~~~~~~~~
request new order(public key) -------->
<-------- 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
issue certificates
finalize ---------->
<---------- certificate
Figure 2: Overview of the PK Challenge Flow(remove CSR)
Since the ACME server has already obtained the user/device's
authenticated public key in 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 remains consistent from the time
the server sends a new order request until the ACME server verifies
that the challenge is valid, that is, consistent with the first and
second phases in section 3.1.1. The ACME server updates the
challenge record as verified (or unverified) and automatically
applies a certificate for the applicant (verified public key) when
the result is verified. There is no need to send the CSR file again.
3. Security Model
Geng, et al. Expires 4 September 2025 [Page 7]
Internet-Draft ACME PK Challenge March 2025
3.1. Attacks and Threat Models
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~ ACME account management ~~~~~~~~~~~~~~~~~~~~~~~
ACME account registration --------->
~~~~~~~~~~~~~~~~~~~~~~~~ Challenge phase ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
creating a certificate order --------->
<--------- a series of challenges
choose a challenge type and
complete it --------->
validate challenge results
~~~~~~~~~~~~~~~~~~~~ Application for Certificate ~~~~~~~~~~~~~~~~~~~~~~
request finalize (CSR) ---------->
<---------- finalize URL
finalize ----------->
<---------- certificate
Figure 3: Overview of the ACME Flow
The standard ACME 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-phase framework has brought many benefits, such as
compatibility with the current network, ease of expansion, and ease
of deployment. However, the decoupled design also brings security
problems. After the verification is completed in the second phase of
challenge, the ACME server will cache the Authz record, but the
public key of the second phase and the third phase is not consistent
binding, the adversary can use the cache record to obtain mismatched
certificates. That is, to obtain an actual unvalidated certificate
issued by the CA, and the adversary holds the public-private key pair
corresponding to that certificate.
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-03 [acme-device-attest-03], and e-mail-reply-00
[RFC8823] and so on. The orthogonal decoupling of the second and
Geng, et al. Expires 4 September 2025 [Page 8]
Internet-Draft ACME PK Challenge March 2025
third phase of the ACME architecture brings security issues for this
purpose. The subjects applying for certificates in the third phase
may not be the same subjects that passed the challenge in the second
phase. Attacks against the resource category are mainly when an
adversary obtains ACME account credentials and then impersonates the
victim's server to get a fake SSL certificate, which can be defended
against by containing the IP and client ID fields when sending
requests in the third phase of ACME. The CA can verify the identity
of the ACME client by verifying the consistency of the IP and ID
fields.
The main focus in our proposed specification is on attacks targeting
the user user/device category. In the threat model, unlike resource-
based subjects, the adversary can be the ACME client, so verifying
the authenticity of the ACME account cannot defend against the
attack. Especially in corporate enterprise scenarios, agent (network
administrator) is required to apply certificates for multiple users/
devices. The proxy, the ACME client, is the malicious adversary.
The adversary applies for certificates for multiple users/devices and
performs public key substitution to obtain false certificates after
the challenge phase to impersonate legitimate user/device.
3.1.1. Users/devices generate their own public-private keys
______________
| ACME client | ______________
| (proxy) | -------------------| ACME server |
|______________| |_____________|
/\ \
/ \ \
/ \ \
/ \ \
_________ _________ _________
| user 1 | | user 2 | | user 3 |
|________| |________| |________|
Figure 4: Scenarios for ACME Clients as Proxy
The ACME client acts as a delegated agent role to request
certificates for multiple users/devices. In this scenario, the user/
device generates and holds the public/private key pair itself, and
the ACME client does not hold any user/device private key. In the
standard ACME certificate application process, the challenge phase
and the certificate application phase do not perform consistency
checking, so if the public key identity of user 1 completes the proof
of ownership during the challenge phase, but the ACME client as a
malicious adversary replaces the public key identity of another
person, i.e., applies for the certificate with the CSR file
Geng, et al. Expires 4 September 2025 [Page 9]
Internet-Draft ACME PK Challenge March 2025
corresponding to the other public key, so as to obtain the final
certificate. At this time the adversary who owns the certificate
(also owns the private key of the certificate) can impersonate user
1.
3.1.2. ACME client agent generates public-private keys
The ACME client acts as a delegated agent role to request
certificates for multiple users/devices. In this scenario, it is
possible that the user/device lacks the ability to generate public-
private key pairs, and the ACME client generates corresponding
public-private key pairs for them. At this time the ACME client as
an adversary has great freedom to apply for certificates for any
user/device. Then the adversary can impersonate any user/device.
3.1.3. Terminals apply for their own certificates
The ACME client is the user/device itself, and in this scenario, the
adversary is the user/device itself. After completing the challenge
phase, the adversary can generate any public-private key pair and
apply for a certificate in the third phase, eventually obtaining an
illegitimate certificate issued by the CA. This scenario is similar
to the scenario in section 3.1.2 where the ACME client agent
generates the public and private keys of the user/device.
3.2. Defend against Threats
This document is mainly oriented to the security problem in scenario
1 (Section 3.1.1), when the adversary is the ACME client, acting as a
proxy role (not holding a user/device private key), and is able to
perform a public key substitution attack to request a certificate.
The challenge type proposed in this document ensures identity
consistency by verifying that the public key is the same at the time
of the certificate application phase and the challenge phase, thus
preventing an adversary from replacing the public key to apply for a
certificate after the challenge phase is completed.
For the attack problems in Scenario 2 and Scenario 3, a similar
whitelisting mechanism can be supplemented on the basis of
consistency checking, i.e., the IDP signing the identity of the
public key and then passing it to the ACME server for verifying the
application privilege of the public key, so as to realize the
legitimacy verification.
Geng, et al. Expires 4 September 2025 [Page 10]
Internet-Draft ACME PK Challenge March 2025
4. ACME pk Identifier Type
This document defines the pk-01 challenge type that ensures strong
consistency between the final certificate and the identity of the
application order even in scenarios where proxies are present. And
public key authentication protocol is utilized to provide strong
security for the authentication process.
The pk-01 challenge type can be applied to a variety of identity
types that contain public key information. The public key can be
used directly with no specific identity information. The identifier
pk can be used in case of user-bound devices; csr and selfsign-cert
can be used in cases where specific identity information needs to be
bound. 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"}
5. ACME pk-01 Challenge Type
The pk-01 challenge type requires the client to access the specified
pk-url to start the PK 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 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. An 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.
Geng, et al. Expires 4 September 2025 [Page 11]
Internet-Draft ACME PK Challenge March 2025
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”
}
6. Public Key Authentication & Order Fulfillment
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:
1. The ACME server receives the request and redirects it to the IDP
server. IDP instance holds the public key, e.g. IDP instances
supporting the aPAKE/Opaque protocols.
2. The IDP server 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.
Geng, et al. Expires 4 September 2025 [Page 12]
Internet-Draft ACME PK Challenge March 2025
3. 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
Figure 5: Overview of the Public Key Authentication Flow
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
user to obtain public key information and identity information about
the subject (user). 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.
Geng, et al. Expires 4 September 2025 [Page 13]
Internet-Draft ACME PK Challenge March 2025
The server needs to validate the order against the identifier after
receiving a request from the customer to complete the order. For
identifiers of pk type, it is necessary to check whether the public
key recorded in the identifier matches the public key in the CSR.
For csr or selfsign-cert type identifiers, in addition to this, the
identity in the order has to be verified against the identity in the
CSR. The client's request for order fulfillment can only be
continued under the condition that all checks have been passed.
In the simplified process of removing CSR, the ACME server issues a
certificate for the public key directly after successful
authentication of the identity, without the need for the user to
generate a CSR file and send it to the ACME server. In this
simplified process, the consistency of the public key of the
certificate and the public key of the challenge phase can be ensured
against public key substitution attacks.
7. Further Use Cases
## 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.
7.1. Various Public Key Authentication Protocols
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.
Geng, et al. Expires 4 September 2025 [Page 14]
Internet-Draft ACME PK Challenge March 2025
7.2. Revocation of Certificates
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.
8. Security Considerations
This challenge is designed to verify that the client has control of
the corresponding identity and to defend against public key
substitution attacks. For general security considerations related to
the ACME certificate issuance process, see [RFC8555].
As with ACME validation methods, the security of PK validation
depends on the risk of the validation process being compromised and
the strength of the binding between the validation process and the
ACME transaction.
The binding of the validation process to the ACME transaction is
managed through a built-in public key validation protocol, where the
IDP and the requesting party negotiate an validation protocol to
return identity information to the ACME server. The whitelisting
mechanism introduced here prevents unauthorized public keys from
requesting certificates.
As for the security based on PK-based authentication itself, it is
carried out based on the public key authentication protocol, and
corresponding risk mitigation measures can be applied. In PK-based
certificate issuance, the PK provided is trustworthy enough to assert
whether a given user has a given identity and public key information.
A malicious PK provider may falsify these assertions, resulting in
the issuance of the wrong certificate. CA's selection of a trusted
PK provider is one of the initiatives to mitigate this risk.
9. IANA Considerations
9.1. ACME Identifier Types
The "ACME Identifier Types" registry is to be updated to include the
following entries:
Geng, et al. Expires 4 September 2025 [Page 15]
Internet-Draft ACME PK Challenge March 2025
+----------------+------------------+
| Label | Reference |
+----------------+------------------+
| pk | RFC XXXX |
+----------------+------------------+
| csr | RFC XXXX |
+----------------+------------------+
| selfsign-cert | RFC XXXX |
+----------------+------------------+
9.2. ACME Validation Method
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 |
+------------+-------------------------+---------+------------+
10. References
10.1. Normative References
[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/info/rfc8555>.
[RFC8738] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension",
RFC 8738, DOI 10.17487/RFC8738, February 2020,
<https://www.rfc-editor.org/info/rfc8738>.
[RFC8737] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) TLS Application-Layer Protocol
Negotiation (ALPN) Challenge Extension", RFC 8737,
DOI 10.17487/RFC8737, February 2020,
<https://www.rfc-editor.org/info/rfc8737>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>.
10.2. Informative References
Geng, et al. Expires 4 September 2025 [Page 16]
Internet-Draft ACME PK Challenge March 2025
[I-D.biggs-acme-sso]
Biggs, A., Barnes, R., and R. Moynihan, "Automated
Certificate Management Environment (ACME) Extension for
Single Sign On Challenges", Work in Progress, Internet-
Draft, draft-biggs-acme-sso-01, 8 April 2021,
<https://datatracker.ietf.org/doc/html/draft-biggs-acme-
sso-01>.
[I-D.irtf-cfrg-opaque]
Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
OPAQUE Augmented PAKE Protocol", Work in Progress,
Internet-Draft, draft-irtf-cfrg-opaque-18, 21 November
2024, <https://datatracker.ietf.org/doc/html/draft-irtf-
cfrg-opaque-18>.
Authors' Addresses
Feng Geng
Huawei Technologies
Email: gengfeng@huawei.com
Panyu Wu
Huawei Technologies
Email: wupanyu3@huawei.com
Liang Xia
Huawei Technologies
Email: frank.xialiang@huawei.com
Geng, et al. Expires 4 September 2025 [Page 17]