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

Introduction The ACME protocol balances the verification of control over identifiers such as domain names and the verification of subject ownership (user/device), ensuring the authenticity of entity identities and issuance accuracy during automated certificate application processes. 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 this 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. Because we recognize that the act of submitting a CSR does not truly prove control over the private key contained within that CSR. This mechanism has the risk of public key replacement, i.e., an untrustworthy or compromised Acme client (such as Resellers or other agents) 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 8), 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 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.

Terminology 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 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, http-01, tls-alpn-01 and so on. The user/device category is mainly such as sso-01 , device-attest-01 , and e-mail-reply-00 and so on.

Web-PKI - PKI/CA Reseller When issuing certificates for resources, the applicant is required to demonstrate resource control (e.g., dns-01, http-01, etc.). 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. In PKI/CA reseller scenarios (As shown in the figure on the right，such as SSL.com generating ACME certificates for reseller customers), the PKI/CA reseller acts as an intermediary selling digital certificates, serving as the Registration Authority (RA) between users and the CA. Resellers receive users' CSRs, then forward the CSRs to the CA to complete the certificate issuance process. During this process, instances of dishonest resellers may occur, including issues such as fraudulent applications.

PKI/CA Reseller Use Case

IoT-PKI - Remote Control for Automobiles In remote control of vehicles scenarios, it is necessary to apply for a remote control certificate for the device in order to control the automobile. This process involves the vehicle owner's terminal app, the vehicle cloud TSP (Telematics Service Provider), the automobile, and the ACME server (PKI/CA). The ACME client can be deployed on the terminal app or the vehicle cloud TSP. Vehicle cloud TSP provides identity assertions for the terminal app, and the Acme server trusts the Acme client. TSP serves as the unified identity authentication center within the automotive enterprise. The terminal app and TSP belong to Trust Domain A, while the ACME server (PKI/CA) that ultimately issues certificates belongs to Trust Domain B. This involves requesting device certificates across trust domains. The terminal app in Trust Domain A ultimately needs to connect to the automobile in Trust Domain B to enable remote control. However, the terminal app cannot fully trust the Acme client, as it holds the private key itself and does not grant external access to it. Due to vehicle safety requirements, it is essential to verify that the owner's terminal app holds the corresponding key control rights for the certificate. Currently, the Acme server cannot “see” the actual terminal app behind the ACME client. Additionally, there exists the possibility that the Acme client could be compromised, allowing an attacker to replace the public key information in the CSR with that of another malicious user to request a certificate from the ACME server.

Remote Control for Automobiles

Security Considerations 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.

Trust chain from Acme server to applicant Regarding the issue in Section 3.1, the applicant need not grant the Acme client privileges or trust equivalent to resource control. Instead, it only needs to provide the Reseller with the minimum necessary trust required to fulfill its responsibility of applying for certificates on behalf of the applicant. The pk-01 challenge verifies the identity of the applicant through public key authentication, directly binding it to the authorization process. This ensures that the applicant who completes the challenge matches the applicant associated with the public key issuing the certificate, thereby eliminating public key substitution attacks. The entire process establishes an end-to-end connection from the ACME server to the applicant themselves, preventing resellers from tampering with the process. Regarding the issue in Section 3.2, the ACME server via pk-01 challenge can verify whether the terminal application itself holds control over the private key corresponding to the certificate. This process implements cross-domain end-to-end security between the terminal app and the PKI/CA (ACME server), preventing attacks from both external and internal sources. It is 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. 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.

Extensions -- Identifier Types 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 8. 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"}

Extensions -- pk-01 Challenge Types 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 . 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", }

Identifier Validation Challenges

Protocol Overview 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".

Overview of the pk-01 Challenge Flow <-------- 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). 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 & 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:

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.

Overview of the Public Key Authentication Flow <--------- 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 . 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.

Changes to the Finalize Request 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.

Overview of the PK Challenge Flow(remove CSR) <--------- valid issue certificates finalize ----------> <---------- certificate ]]>

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.

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.

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.

IANA Considerations

ACME Identifier Types The "ACME Identifier Types" registry is to be updated to include the following entries:

ACME Validation Method The "ACME Validation Methods" registry is to be updated to include the following entries: