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

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 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. 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. It is worth noting that the existing external account binding in ACME 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.

Protocol Overview This section describes the PK challenge process in terms of the standard ACME process for issuing certificates and the process for removing CSR, respectively.

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 , except that the IDP here must contain the user's public key and no longer requires a passphrase or key information.

Overview of the PK 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 public key 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 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 ). 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.

Remove CSR

Overview of the PK Challenge Flow(remove CSR) <-------- 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 ]]> 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.

Security Model

Attacks and Threat Models

Overview of the ACME Flow ~~~~~~~~~~~~~~~~~~~~~~~~ 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 ]]> 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, http-01, tls-alpn-01 and so on. The user/device category is mainly such as sso-01 , device-attest-03 [acme-device-attest-03], and e-mail-reply-00 and so on. The orthogonal decoupling of the second and 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.

Users/devices generate their own public-private keys

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

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.

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.

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.

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.

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

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 server. IDP instance holds the public key, e.g. IDP instances supporting the aPAKE/Opaque protocols.
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.
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 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 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. 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.

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.

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

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: