Automated Certificate Management Environment (ACME) Extension for Public Key Challenges

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 12 April 2025.¶

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. Introduction

More and more applications use end-to-end encryption to protect the communication process, in which X.509 certificates play an important role. ACME helps to promote and popularize the certificate. In the automatic application process for certificates, the public key of the submitted certificate signing request (CSR) is not checked in the finalized order request to see if it belongs to the applying user. The public key replacement attack may exist for this.¶

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.¶

In environments where proxies are used, which are usually relatively safe, there are also risks with very low probability. Based on the standard ACME automated certificate request process, the ACME server can communicate with the user and prove the validity of the user's identity through the use of proxies. However, in this scenario, on the one hand, users may inevitably need to grant their own identity proofing privileges to intermediate proxies, e.g., they need proxies to complete DNS records; on the other hand, at the final submission of the CSR, the proxy may substitute the final CSR and apply for a mismatched certificate.¶

Similarly, in other non-proxy scenarios it is possible for an applicant to obtain the CSR of another users, thus obtaining the corresponding certificate of the others, resulting in a security risk.¶

This specification introduces a new ACME challenge type to allow the identity of a user to be verified by means of public key (PK) authentication. In this process it can be ensured that the public key of the application request is consistent with the public key in the final submitted CSR, eliminating the security risk of public key replacement in the certificate application.¶

The protocol interaction process is based on the ACME standardized 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 awarding process. The entire process of applying for a certificate conforms to the ACME standardized process.¶

Note that this specification 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.¶

2. Protocol Overview

The general process of the PK challenge is illustrated by the standard ACME certificate issuance sequence. First the client needs to submit 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 single sign-on (SSO) [draft-biggs-acme-sso-01], except that the IDP here must contain the user's public key and no longer requires a passphrase or key information.¶

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 logs the associated challenge as validated (or not).¶

In the process of authentication, the process of this specification 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.¶

Then the redirection to the client indicates that the authentication process has been completed, at which point it can be demonstrated that the client 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.¶

Figure 1 depicts the overview of the public key challenge flow:¶

Client                                                    ACME Server

~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~

request new order              -------->
                              <--------           required authorizations
request authorization           -------->
                              <--------        PK challenge with start URL

~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~

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

~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~

request challenge             -------->
                           <---------                          valid
request finalize (CSR)         --------->
                           <---------                    finalize URL
finalize                      -------->
                           <---------                     certificate

After completing authentication the client eventually submits the CSR. This specification 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.¶

3. 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"}

4. 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.¶

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/”
}

5. 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.¶

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

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.¶

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 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.¶

6. Security Considerations

This document is an extension to ACME to provide an additional validation method for verifing that the client has control of the public key corresponding to the private key. 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.¶

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.¶

7. IANA Considerations

+----------------+------------------+
| Label          | Reference        |
+----------------+------------------+
| pk             | RFC XXXX         |
+----------------+------------------+
| csr            | RFC XXXX         |
+----------------+------------------+
| selfsign-cert  | RFC XXXX         |
+----------------+------------------+

+------------+-------------------------+---------+------------+
| Label      | Identifier Type         | ACME    | Reference  |
+------------+-------------------------+---------+------------+
| pk-01      | pk/csr/selfsign-cert    | Y       | RFC XXXX   |
+------------+-------------------------+---------+------------+

8. References

Authors' Addresses