



Automated Certificate Management Environment Working Group       F. Geng
Internet-Draft                                                     P. Wu
Intended status: Standards Track                                  L. Xia
Expires: 3 September 2026                            Huawei Technologies
                                                            2 March 2026


Automated Certificate Management Environment (ACME) Extension for Public
                             Key Challenges
                     draft-geng-acme-public-key-04

Abstract

   This document implements automated certificate provisioning through
   "public key identity challenge + private key ownership verification"
   by introducing the pk-01 challenge to the ACME protocol [RFC8555].
   It serves as a valuable complement to existing external resource
   verification challenge types such as DNS/HTTP, extending the ACME
   protocol's applicability beyond Web-PKI to other scenarios.  This
   enables automated certificate issuance for devices and accounts.  The
   core design objective of this document's extension to ACME's pk-01
   challenge is to introduce a trusted identity provider (IdP) during
   the digital certificate application process.  This provider verifies
   the certificate applicant's identity and obtains the corresponding
   identity public key.  It enables the ACME server to use public key
   identity authentication protocols (e.g., WebAuthn and Opaque
   [RFC9807]) to verify whether the genuine application behind the ACME
   client controls the public key.  It ensures strong consistency
   between the public key used during the challenge phase and the public
   key ultimately used to sign the certificate, preventing tampering
   with the public key during the CSR submission phase.  This enhances
   the security of the digital certificate issuance process.  Similar
   related work can be found in [RFC9883].

   This document also defines an optional process extension that allows
   removal of the CSR under the pk-01 challenge, enabling the ACME
   server to issue a certificate directly after successful public key
   verification.

   This document provides an example of practical application at the
   end, illustrating the integration of the OPAQUE [RFC9807], strong
   asymmetric password authenticated key exchange (saPAKE) protocol with
   the pk-01 challenge.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.



Geng, et al.            Expires 3 September 2026                [Page 1]

Internet-Draft              ACME PK Challenge                 March 2026


   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 3 September 2026.

Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Document Contributions  . . . . . . . . . . . . . . . . .   4
     1.2.  Some notes  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Motivation and Threat Model . . . . . . . . . . . . . . . . .   6
     3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Practical Risk Scenarios  . . . . . . . . . . . . . . . .   7
       3.2.1.  Reseller-Based Certificate Issuance . . . . . . . . .   8
       3.2.2.  IoT and Device Enrollment . . . . . . . . . . . . . .   8
       3.2.3.  Cross-Domain Vehicle Control with External IdP  . . .   9
     3.3.  Core Security Issues  . . . . . . . . . . . . . . . . . .   9
     3.4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  10
       3.4.1.  System Model  . . . . . . . . . . . . . . . . . . . .  10
       3.4.2.  Trust Assumptions . . . . . . . . . . . . . . . . . .  10
       3.4.3.  Attack Capabilities and Core Threats  . . . . . . . .  11
   4.  Extensions - Identifier Types . . . . . . . . . . . . . . . .  11
     4.1.  Binding Model . . . . . . . . . . . . . . . . . . . . . .  12
       4.1.1.  Self-Signed Certificate Binding Mode  . . . . . . . .  12
       4.1.2.  CSR Binding Mode  . . . . . . . . . . . . . . . . . .  12
   5.  Extensions -- pk-01 Challenge Types . . . . . . . . . . . . .  13



Geng, et al.            Expires 3 September 2026                [Page 2]

Internet-Draft              ACME PK Challenge                 March 2026


     5.1.  Challenge Definition  . . . . . . . . . . . . . . . . . .  13
     5.2.  Challenge Object  . . . . . . . . . . . . . . . . . . . .  13
   6.  Identifier Validation Challenges  . . . . . . . . . . . . . .  14
     6.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Protocol Details  . . . . . . . . . . . . . . . . . . . .  15
     6.3.  Public key authentication & Order fulfillment . . . . . .  16
   7.  Certificate Issuance without CSR  . . . . . . . . . . . . . .  18
   8.  Integration with OPAQUE Protocol  . . . . . . . . . . . . . .  18
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  OPAQUE-based Public Key Authentication Flow . . . . . . .  19
     8.3.  Step-by-Step Integration Details  . . . . . . . . . . . .  19
     8.4.  Implementation Scenarios: Cross-Domain Trust  . . . . . .  20
   9.  Further Use Cases . . . . . . . . . . . . . . . . . . . . . .  21
     9.1.  Various Public Key Authentication Protocols . . . . . . .  21
     9.2.  Revocation of Certificates  . . . . . . . . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
     10.1.  Trust in the Identity Provider (IdP) . . . . . . . . . .  21
     10.2.  Integrity of the Assertion . . . . . . . . . . . . . . .  21
     10.3.  Credential Security and OPAQUE . . . . . . . . . . . . .  22
     10.4.  Privacy Considerations . . . . . . . . . . . . . . . . .  22
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Identifier Types . . . . . . . . . . . . . . . . . . . .  22
     11.2.  ACME Validation Method . . . . . . . . . . . . . . . . .  23
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The ACME protocol ensures the accuracy and security of automated
   certificate issuance through various challenge types.  Early external
   resource verification challenges such as DNS/HTTP [RFC8555] have
   brought much-needed flexibility to Web-PKI, enabling comprehensive
   automation of web certificates.  This document proposes a more
   general public key identity challenge type for verifying an
   applicant's (especially an end-entity's or account's) control over
   certificate ownership.  It supports automated certificate issuance
   for devices and accounts based on public-key identity verification
   challenges.

   The challenge enables the ACME server to verify the control of the
   identity of the certificate applicant behind the ACME client via the
   public key authentication protocol (e.g., WebAuthn and Opaque
   [RFC9807]), truly realizing what the ACME WG Charter describes as
   "The processing must also confirm that the requesting party has
   access to the private key that corresponds to the public key that
   will appear in the certificate".  On the other hand, the proposed
   challenge mitigates public key substitution attacks.  In typical
   deployments, the ACME client serves as the automated interface



Geng, et al.            Expires 3 September 2026                [Page 3]

Internet-Draft              ACME PK Challenge                 March 2026


   between the real applicant and the ACME server.  During certificate
   issuance, while the ACME server verifies the applicant’s control over
   an identifier through the challenge process, it does not verify that
   the public key contained in the CSR is actually controlled by the
   applicant.  It is observed that untrusted or compromised ACME clients
   might replace the public key in the CSR after completing the
   challenge.  Particularly in PKI/CA reseller scenarios, the resellers
   may submit CSR requests with replaced public key to the ACME server.
   This results in a mismatch between the applicant's identity and the
   identity associated with the public key used to issue the
   certificate.  This ultimately allows certificates to be issued to
   unrelated or malicious entities.

1.1.  Document Contributions

   This document proposes a new ACME challenge type pk-01 that verifies
   the applicant's control over their identity by means of public key
   authentication.  The public key used in the challenge phase must
   consistently match the public key in the 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 7), which directly
   issues a certificate after successful challenge phase, realizing the
   consistency of the public key in the challenge phase and in the
   issued certificate.

   More critically, the challenge is designed for the ACME server to
   work in coordination with a trusted identity provider (IdP), which
   endorses the relationship between the applicant and its public key.
   This 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
   end-entity, ensuring that the certificate clearly identifies the
   legitimacy of the holder of the identifier.  It is precisely this
   mechanism enabling the ACME server to collaborate with trusted
   identity providers that supports automated certificate issuance for
   devices and accounts based on public-key authentication verification
   challenges.  This extends ACME's applicability beyond Web-PKI
   scenarios.











Geng, et al.            Expires 3 September 2026                [Page 4]

Internet-Draft              ACME PK Challenge                 March 2026


1.2.  Some notes

   Note that this document requires an IdP that records public keys,
   achieved by supporting the corresponding public key authentication
   protocols (e.g., WebAuthn and Opaque).  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 (EAB)
   in ACME [RFC8555] is primarily used to authenticate ACME client
   account identitie and is not the same as the validation of
   certificate applicant identities proposed in this document; the two
   do not conflict.  EAB enables the ACME client to authenticate to ACME
   server using an identifier and key value, which the server can verify
   against its maintained repository.  Through EAB, ACME servers can
   filter which users can access their services, making it highly useful
   for commercial certificate authorities.  This differs from Let's
   Encrypt's model, which allows anyone to request certificates.

   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.

2.  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 [RFC2119] [RFC8174] when, and only
   when, they appear in all capitals, as shown here.







Geng, et al.            Expires 3 September 2026                [Page 5]

Internet-Draft              ACME PK Challenge                 March 2026


3.  Motivation and Threat Model

3.1.  Motivation

   The real world presents typical practical use cases that ACME
   currently struggles to adequately address.  For instance: http-01
   requires ports 80/443, yet many devices cannot open them; dns-01
   requires permission to modify DNS settings, which is unfeasible for
   internal networks or IoT devices; tls-alpn-01 [RFC8737] has limited
   support, and no ACME challenge currently supports “pure public-key
   identity”. However, extending the pk-01 public key challenge can
   perfectly address the certificate automation needs in these real-
   world scenarios, such as:

   1.  Automated Certification for IoT Devices/Industrial Internet of
       Things (IoT)

       These devices lack domain names and public IP addresses, cannot
       open ports 80/443, and cannot modify DNS settings.  However, each
       device possesses a unique identity public key.  Through the pk-01
       extension, it proves “I am a legitimate device” and “I possess
       the private key”, device certificate are issued fully
       automatically with zero configuration.

   2.  Automated Certification for 5G/6G Edge Nodes, Base Stations, and
       Small Cells

       These massive edge nodes cannot be manually deployed or
       configured with DNS, but they come equipped with factory
       certificates from the device supplier.  With the pk-01 extension,
       they can prove “I am a legitimate device” and “I possess a
       factory certificate”, enabling certificate automation.

   3.  Automated Certification for V2X/TSP Platforms

       Automatic certificate renewal for vehicle components (ECU, T-Box,
       IVI, etc.) cannot rely on DNS/HTTP.  Remote vehicle control via
       the owner's app requires the verified account to request remote
       control certificates from the TSP.  The pk-01 challenge proves “I
       am a legitimate component” and “I am a legitimate account”,
       enabling certificate automation.

   4.  Automation Workload Certificate in Zero Trust Architecture (ZTA)








Geng, et al.            Expires 3 September 2026                [Page 6]

Internet-Draft              ACME PK Challenge                 March 2026


       The zero-trust architecture explicitly requires public keys as
       the basis for identity, rather than IP/domain names.  The pk-01
       challenge can directly issue identity certificates to containers,
       Pods, microservices, and virtual machines using the workload's
       public key.

   5.  Automated Certificate provisioning for Internal Network Devices
       (Government and Enterprises)

       Achieve automated certificate management for internal network
       devices through pk-01 challenge based on an internal network IdP
       combined with a private CA.

   6.  Anonymous/Pseudonymous Identity Certificates (corresponding to
       privacy-enhanced PKI)

       With pk-01, only public key identity and private key ownership
       need to be verified, protecting users' real identities.  It can
       be widely used in scenarios such as private communications,
       anonymous conferences, pseudonymous identities, and data
       sovereignty.

3.2.  Practical Risk Scenarios

   The ACME protocol generally assumes by default that the ACME Client
   represents the real applicant and is capable of correctly submitting
   a CSR containing the applicant's public key.  However, in many
   deployment models, the ACME client is not operated directly by the
   end entity.  Instead, it may be provided by a reseller, managed
   security service, IoT platform operator, or other intermediary.  In
   such scenarios, the ACME server verifies control over the identifier
   during the challenge phase, but does not verify that the public key
   contained in the CSR is actually controlled by the entity that
   completed the challenge.

   The core issue is the lack of strong cryptographic binding between:

   *  The entity that completes the challenge, and

   *  The holder of the private key corresponding to the issued
      certificate.

   The ACME server relies on an assumption of trust in ACME client
   without enforcing a strong cryptographic binding between the
   challenging entity and the public key of the final certificate.






Geng, et al.            Expires 3 September 2026                [Page 7]

Internet-Draft              ACME PK Challenge                 March 2026


3.2.1.  Reseller-Based Certificate Issuance

   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 challenge, in exchange for ACME server's trust, so as to
   obtain the certificate.

   In reseller-based PKI deployment models, an intermediary may operate
   the ACME client and interact directly with the CA on behalf of
   multiple end entities.  Such intermediaries often assume
   responsibilities comparable to those of a Registration Authority
   (RA), including key management or CSR submission.  In these
   architectures, the CA validates control over an identifier during the
   ACME challenge phase but does not independently verify that the
   public key included in the CSR is controlled by the same entity that
   completed the challenge.

   If the intermediary replaces or generates a different public key
   after successful validation—whether due to compromise, operational
   error, or malicious intent—the resulting certificate may bind the
   validated identifier to a key unrelated to the original applicant.
   This architectural trust assumption introduces a potential public key
   substitution risk.

3.2.2.  IoT and Device Enrollment

   In IoT deployment models, certificate issuance is often performed at
   large scale through automated enrollment systems.  An IoT platform or
   device management service may operate as the ACME client on behalf of
   thousands or millions of devices.  In such architectures, devices
   typically:

   *  Possess hardware-bound key pairs (e.g., generated in a Secure
      Element or TPM), or

   *  Rely on a provisioning service to request certificates during
      manufacturing or onboarding.

   While ACME identifier validation ensures control over an identifier
   (e.g., device domain name or device identifier), it does not
   guarantee that the public key included in the CSR corresponds to the
   actual hardware device that completed the validation process.  If
   private key ownership is not verified during the challenge phase, the
   device's identity integrity cannot be enforced.

   Device Identity ↔ Hardware Private Key ↔ Issued Certificate



Geng, et al.            Expires 3 September 2026                [Page 8]

Internet-Draft              ACME PK Challenge                 March 2026


3.2.3.  Cross-Domain Vehicle Control with External IdP

   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.  In certain vehicle ecosystems, user authentication is
   delegated to an external Identity Provider (IdP), such as a charging
   service provider or mobility platform.  In this model: The IdP
   authenticates the vehicle owner; The Original Equipment Manufacturer
   (OEM) vehicle cloud relies on the IdP’s identity assertion; An ACME
   client (operated by the OEM cloud or the service provider) requests a
   certificate from a CA; The vehicle ultimately trusts certificates
   issued by the CA.

   This architecture spans multiple trust domains:

   *  Trust Domain A: External IdP and user-facing application

   *  Trust Domain B: OEM vehicle cloud

   *  Trust Domain C: CA/ACME server

   In such cross-domain scenarios, the CA validates the certificate
   request through the ACME client but does not directly verify that the
   authenticated end user possesses the private key corresponding to the
   public key included in the CSR.  If the ACME client or an
   intermediary component substitutes the public key after identity
   validation, the issued certificate may bind the authenticated
   identity to an attacker-controlled key.  The vehicle, trusting the
   CA, may accept remote control commands from the attacker.  This risk
   is amplified in cross-domain deployments because identity assertion,
   certificate request, and certificate validation occur in different
   trust domains.

   The “pk-01” challenge is therefore necessary to ensure that the
   authenticated end entity demonstrates proof-of-possession of the
   certificate key, thereby enforcing strong identity–key binding across
   trust boundaries.

3.3.  Core Security Issues

   The core issue is the lack of strong cryptographic binding between:

   *  The entity that completes the challenge, and

   *  The holder of the private key corresponding to the issued
      certificate.





Geng, et al.            Expires 3 September 2026                [Page 9]

Internet-Draft              ACME PK Challenge                 March 2026


   While ACME ensures identifier control, it does not inherently
   guarantee that the validated entity and the certificate subject key
   are cryptographically linked beyond the trust assumption placed on
   the ACME client.  This gap may lead to identity–key inconsistency and
   certificate misbinding.

   Binding the public key to the challenge is valuable regardless of
   whether you trust the ACME client.

3.4.  Threat Model

3.4.1.  System Model

   The following entities are involved in cross-domain ACME deployment
   scenarios:

   *  *End-Entity (EE)*: The ultimate certificate subject that generates
      a key pair and intends to obtain a certificate (e.g., IoT device,
      vehicle control application, customer system).

   *  *Intermediary / ACME Client*: An entity that interacts directly
      with the ACME server on behalf of the End-Entity.

   *  *ACME Server / CA (AS)*: The certificate authority that validates
      challenges and issues certificates.

   *  *Identity Provider (IdP)* (optional): Provides identity assertions
      to the intermediary.

   The ACME Server trusts the ACME Client to complete the challenge
   procedure, while the End-Entity relies on the intermediary to request
   a certificate corresponding to its key material.  These entities may
   reside in different trust domains.  The ACME Server/CA (AS) needs to
   establish trust with the identity provider.

3.4.2.  Trust Assumptions

   *  The ACME Server fully trusts the ACME Client to correctly
      represent the End-Entity.

   *  The End-Entity does not necessarily trust the ACME Client with its
      private key.

   *  The ACME Server cannot directly observe the End-Entity behind the
      ACME Client.

   *  Identity assertions (if any) are not cryptographically bound to
      the certificate public key by default.



Geng, et al.            Expires 3 September 2026               [Page 10]

Internet-Draft              ACME PK Challenge                 March 2026


3.4.3.  Attack Capabilities and Core Threats

   The adversary is capable of:

   *  Modifying or replacing the CSR public key.

   *  Submitting a substituted key for certificate issuance.

   *  Rebinding identity assertions to attacker-controlled key material.

   The core threat lies in the fact that the Challenge executor ≠ CSR
   private key holder, and the CA cannot prove their identity matches.

               Trust Domain A                     Trust Domain B
       ---------------------------------------------------------------

       +-----------------+            +------------------+
       |   End-Entity    |            |   ACME Server    |
       |  (Device/App)   |            |      (CA)        |
       |                 |            |                  |
       |  Generates Key  |            |  Validates       |
       |  Holds Private  |            |  Challenge       |
       +--------+--------+            +---------+--------+
                |                               ^
                | CSR                           |
                v                               |
       +-----------------+  ACME Protocol       |
       | Intermediary /  |----------------------+
       |  ACME Client    |
       | (Reseller/TSP)  |
       +-----------------+

                           Figure 1: Threat Model

4.  Extensions - Identifier Types

   This document introduces an extension that enables validation of end-
   entity ownership of the public key included in the certificate
   request.  It ensures 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.

   This extension does not replace existing identifier types.  Instead,
   it augments the ACME validation model by enabling cryptographic
   binding between:

   *  The identifier being validated, and



Geng, et al.            Expires 3 September 2026               [Page 11]

Internet-Draft              ACME PK Challenge                 March 2026


   *  The public key to be certified.

   This document defines a new identifier type:

   "identifier": {
        "type": "pk",
        "value":"MIGfMA0GC***GbQIDAQAB"
   }

   The “pk” identifier represents a public key to be certified.  The
   ACME server MUST ensure that the public key included in the final
   certificate matches the value of the “pk” identifier.  This
   identifier type is intended for lightweight key-binding scenarios,
   such as device enrollment or user-device association, where the
   public key itself represents the certified subject.

4.1.  Binding Model

   In certain deployments, stronger binding between identity information
   and key material may be required.  This document defines optional
   binding modes for the pk identifier:

4.1.1.  Self-Signed Certificate Binding Mode

   The client MAY provide a self-signed certificate containing the
   public key and subject information.  If used, the ACME server MUST
   verify that:

   *  The public key matches the “pk” identifier.

   *  The subject information in the final certificate matches the self-
      signed certificate.

   The self-signed certificate serves solely as a binding container and
   does not imply trust in its issuer.

4.1.2.  CSR Binding Mode

   The client MAY include a base64url-encoded CSR in the order object.
   If present, the ACME server MUST ensure that:

   *  The public key in the final certificate matches the CSR.

   *  The subject and extensions in the final certificate are consistent
      with the CSR.






Geng, et al.            Expires 3 September 2026               [Page 12]

Internet-Draft              ACME PK Challenge                 March 2026


   When CSR binding mode is used, the client is not required to resubmit
   the CSR during the finalize step.  This mechanism prevents
   modification of identity information between order creation and
   certificate issuance.

   {
     "identifiers": [
        { "type": "pk",
          "value": "MIGfMA0GC..."
          "bindingMode": { \n
               "mode": "none" | "csr" | "selfsigned",
               "value": "<base64 data if applicable>"
          }
        }
      ],
   }

5.  Extensions -- pk-01 Challenge Types

5.1.  Challenge Definition

   This specification defines a new ACME challenge type pk-01. pk-01
   challenge is used to prove an applicant's control over the private
   key corresponding to a given public key.  Unlike traditional
   identifiers (e.g., DNS, IP), the PK identifier itself represents a
   public key value.  Therefore, the goal of the pk-01 challenge is:

   To prove that the entity initiating the challenge actually holds the
   private key matching the public key specified in the identifier.

5.2.  Challenge Object

   The pk-01 challenge type requires the client to access the specified
   “pk-url” to start the challenge and complete the verification of the
   corresponding private key control of the declared public key.  A
   challenge of this type MUST include all required fields described in
   section 8 of [RFC8555].  In addition, the following fields are
   defined for this specific type of challenge:

   *  pk_url (required, string): The url to start the pk-01 challenge
      type process.  The server must include enough information in the
      URL to allow the request to be associated with a specific
      challenge and to be able to point to a specific PK provider or
      public key server.

   *  pk_provider (optional, string): The domain of the PK provider
      relied upon for this challenge.  ACME server MAY rely upon any
      number of PK providers and public key servers, however each MUST



Geng, et al.            Expires 3 September 2026               [Page 13]

Internet-Draft              ACME PK Challenge                 March 2026


      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.

   *  standardization (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",
         "token": "LoqXcYV8...uZg",
         "pk_url": "https://example.org/acme/start-pk",
         "pk_provider": "https://pk-identity-provider.org/",
         "standardization": "standard" | "simplified"
   }

6.  Identifier Validation Challenges

6.1.  Protocol Overview

   When the identifier type is "pk", the ACME server MUST validate
   proof-of-possession of the corresponding private key using the pk-01
   challenge.  The bindingMode parameter associated with the identifier
   defines additional validation requirements that apply during order
   finalization, but it does not alter the semantics of the pk-01
   challenge.

   The validation process consists of two logically distinct phases:

   1.  Challenge Validation Phase: Proves possession of the private key
       corresponding to the identifier public key.



Geng, et al.            Expires 3 September 2026               [Page 14]

Internet-Draft              ACME PK Challenge                 March 2026


   2.  Order Finalization Phase: Enforces consistency constraints
       defined by the selected bindingMode.

   The ACME server MUST ensure that the public key used to complete the
   challenge is identical to the public key bound to the issued
   certificate.

6.2.  Protocol Details

   The general process of the pk-01 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 newOrder request containing
   one or more identifiers, including public key information for the pk
   identifier.  The ACME server responds with a list of authorizations,
   each containing one or more available challenges for proving control
   of the identifier.  The client selects a challenge it can complete
   and performs the required proof-of-possession operation.

   In the second phase, the client selects a challenge from the list of
   available challenges provided by the ACME server, which may be of the
   pk-01 type.  Selecting such a challenge triggers a public key
   authentication protocol between the applicant and their corresponding
   IdP.  The ACME client and IdP perform the authentication protocol
   (e.g., aPAKE or Opaque [RFC9807]) to prove possession of the private
   key corresponding to the identifier public key.  The IdP may
   optionally provide a signed assertion of the public key identity if
   the ACME server maintains a whitelist of trusted public keys.  Upon
   successful validation, the ACME server marks the associated challenge
   as valid.  The applicant’s private key is never disclosed to any
   intermediate agent during this process.

   After completing the challenge, the client proceeds to finalize the
   order by submitting the CSR (if not submitted earlier).  The ACME
   server MUST verify that the public key in the CSR matches the public
   key in the identifier that was validated during the challenge phase.
   Furthermore, ACME server MUST verify whether the bindingMode value
   matches that specified in the CSR.

   This ensures that any tampering with the public key is detected.
   Other aspects of order finalization and certificate issuance follow
   the standard ACME process.







Geng, et al.            Expires 3 September 2026               [Page 15]

Internet-Draft              ACME PK Challenge                 March 2026


 Client                                                      ACME Server
    |                                                              |
    |==================== Certificate Application =================|
    |                                                              |
    |                                                              |
    | request newOrder(pk) --------------------------------------> |
    | <-------------------------------- required authorizations    |
    | request authorization -------------------------------------> |
    | <----------------------------- pk-01 challenge (token + URL) |
    |                                                              |
    |                                                              |
    |================== Public Key Authentication =================|
    |                                                              |
    | request pk-01 challenge response --------------------------> |
    |                                                              |
    |            ACME Server invokes IdP / Provider API            |
    |            to perform public key authentication              |
    |                                                              |
    | <------------------ signed identity assertion from IdP ----- |
    |                                                              |
    | ACME Server validates assertion and PoP                      |
    | Records challenge as valid                                   |
    |                                                              |
    |                                                              |
    |==================== Certificate Issuance ====================|
    |                                                              |
    | request finalize (submit CSR) -----------------------------> |
    |                                                              |
    |          Verify CSR.publicKey == identifier.publicKey        |
    |          Enforce bindingMode consistency                     |
    |                                                              |
    | <--------------------------- finalize URL / certificate ---- |

             Figure 2: Overview of the pk-01 Challenge Flow

6.3.  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 requests for pk_url.

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






Geng, et al.            Expires 3 September 2026               [Page 16]

Internet-Draft              ACME PK Challenge                 March 2026


   2.  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 (WebAuthn), (2) saPAKE (Opaque
       [RFC9807]) and (3) zero-knowledge proof authentication (DLEQ or
       zk-SNARKs), 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
       csr and selfsign-cert bindingMode types, identity consistency
       checks are also required.  The challenge is successful if the
       check passes.

ACME Server                     Applicant                         IdP
   |                               |                               |
   |-------------- Provider Authenticates Client ------------------|
   |                               |                               |
   | 1. Send pk-01 challenge       |                               |
   |   (token + URL) ------------> |                               |
   |                               |                               |
   |                               | 2. Request list of supported public key auth protocols
   |                               | <---------------------------- |
   |                               |                               |
   |                               | 3. Select authentication protocol
   |                               | ----------------------------> |
   |                               |                               |
   |                               | 4. Execute public key auth protocol (PoP verification)
   |                               | <---------------------------->|
   |                               |                               |
   | 5. Receive signed assertion   |                               |
   |    from IdP                   |                               |
   | <---------------------------- |                               |
   |                               |                               |
   | 6. ACME Server validates PoP  |                               |
   |    and marks challenge valid  |                               |
   | <-----------------------------------------------------------> |

           Figure 3: Overview of the PK Authentication Flow





Geng, et al.            Expires 3 September 2026               [Page 17]

Internet-Draft              ACME PK Challenge                 March 2026


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

7.  Certificate Issuance without CSR

   Since the ACME server has already obtained and validated the
   applicant’s public key during the pk-01 challenge phase, submitting a
   CSR in the finalization phase is optional.  In cases where the CSR
   does not contain any additional information beyond what is already
   established in the ACME protocol (e.g., identifier and public key),
   the final phase can proceed without transmitting a separate CSR file.

   The process from the client submitting a new order to the ACME server
   validating the challenge remains consistent with Section 6.  During
   the final certificate issuance phase, the ACME server updates the
   challenge status to valid (or invalid if verification fails) and
   automatically issues a certificate bound to the verified public key.
   There is no need to submit the CSR again.

   Client                                                 ACME Server
      |                                                         |
      |================== Certificate Issuance =================|
      |                                                         |
      | request challenge ------------------------------------> |
      | <-------------------------------------- challenge valid |
      |                                                         |
      | finalize (no CSR needed) -----------------------------> |
      | <----------------------------------- issued certificate |

        Figure 4: Overview of the pk-01 Challenge Flow (remove CSR)

8.  Integration with OPAQUE Protocol

8.1.  Overview

   This section specifies the integration of the OPAQUE asymmetric
   Password-Authenticated Key Exchange (aPAKE) protocol with the pk-01
   ACME challenge.

   The synergy between these two protocols addresses the "Identity-to-
   Key" binding problem in Zero Trust environments.  While OPAQUE
   provides a cryptographically strong, password-based mutual



Geng, et al.            Expires 3 September 2026               [Page 18]

Internet-Draft              ACME PK Challenge                 March 2026


   authentication where the server never sees the plaintext password,
   the pk-01 challenge provides a mechanism for an ACME server to verify
   that a Public Key (PK) is indeed owned by the authenticated entity.
   By combining them, an IdP can issue an endorsement for a transient
   public key based on a successful OPAQUE exchange.

8.2.  OPAQUE-based Public Key Authentication Flow

   The following diagram illustrates the interaction between the ACME
   Client, the ACME Server, and the OPAQUE-enabled IdP.

  ACME Server                  Applicant (Client)                    IdP
     |                                |                               |
     | 1. Send pk-01 challenge        |                               |
     |------------------------------->|                               |
     |                                |                               |
     |                                | 2. Request supported protocols|
     |                                |<----------------------------->|
     |                                |    (Includes OPAQUE)          |
     |                                |                               |
     |                                | 3. Select OPAQUE              |
     |                                |------------------------------>|
     |                                |                               |
     |                                | 4. Execute OPAQUE Flow        |
     |                                |<=============================>|
     |                                |   (Auth + Session Key Export) |
     |                                |                               |
     |                                | 5. Execute pk-01 PoP          |
     |                                |    (Sign token with SK_temp)  |
     |                                |------------------------------>|
     |                                |                               |
     | 6. Receive Signed Assertion    |                               |
     |<---------------------------------------------------------------|
     |                                |                               |
     | 7. Validate Assertion & Token  |                               |
     |    (Challenge marked valid)    |                               |
     |                                |                               |
     | 8. Finalize Order              |                               |
     |<-------------------------------|                               |

          Figure 5: OPAQUE-based Public Key Authentication Flow

8.3.  Step-by-Step Integration Details

   1) Challenge Initiation: The ACME Server provides a token which MUST
   be unique and a url pointing to the OPAQUE-enabled IdP.  1) Protocol
   Selection and OPAQUE Execution: Upon contacting the IdP, the
   Applicant selects OPAQUE from the supported list.



Geng, et al.            Expires 3 September 2026               [Page 19]

Internet-Draft              ACME PK Challenge                 March 2026


   *  The OPAQUE exchange provides Mutual Authentication: The Applicant
      verifies the IdP, and the IdP verifies the Applicant via their
      password.

   *  Key Export: Both parties derive a shared secret Kexport.  This key
      is used to secure the subsequent PoP verification.

   3) PoP Verification (The Key Binding): The Applicant generates a
   transient key pair (PKtemp, SKtemp) and proves possession to the IdP.

   *  The Applicant signs the ACME token using SKtemp.

   *  The entire request to the IdP is authenticated using the OPAQUE
      session key (Kexport), binding the identity to the specific public
      key and ACME session.

   4) Assertion Submission: The IdP generates a Signed Assertion
   containing:

   *  The validated Public Key (PKtemp).

   *  The ACME token.

   *  The Applicant's identity metadata (e.g., alice@company-a.com).

   The IdP sends this directly to the ACME Server (or via the
   Applicant).  The ACME Server verifies the IdP's signature and the
   token freshness.

8.4.  Implementation Scenarios: Cross-Domain Trust

   In a managed guest access scenario (e.g., Alice from Company A
   joining Company B's session), cross-domain temporary certificate
   requests can be achieved by combining pk-01 and OPAQUE.

   *  Out-of-band Provisioning: An administrator at Company B pre-
      registers Alice in Company B's OPAQUE IdP and securely transmits a
      temporary password to her.

   *  Challenge Redirection: When Alice initiates the ACME process with
      Company B's Server, she is directed to Company B's IdP.

   *  Local Trust: The ACME Server is configured to trust its local
      OPAQUE IdP.  The IdP acts as the "Validator" of the pk-01
      challenge.






Geng, et al.            Expires 3 September 2026               [Page 20]

Internet-Draft              ACME PK Challenge                 March 2026


   *  Credential Lifecycle: Since the password was pre-registered for a
      specific meeting, the IdP can automatically expire the OPAQUE
      record and the associated pk-01 validation status once the session
      concludes.

9.  Further Use Cases

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

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

10.  Security Considerations

   The security of the pk-01 challenge depends on the integrity of the
   tripartite trust model between the ACME Server, the Applicant, and
   the Identity Provider (IdP).

10.1.  Trust in the Identity Provider (IdP)

   In this model, the ACME Server delegates the verification of public
   key possession to an external IdP.  Therefore, the ACME Server MUST
   establish a strong trust relationship with the IdP.  If an IdP is
   compromised, an attacker could obtain fraudulent certificates by
   generating malicious assertions for arbitrary public keys.  ACME
   Servers SHOULD limit the scope of certificates (e.g., specific
   identifiers or short validity periods) issued based on assertions
   from any single IdP.

10.2.  Integrity of the Assertion

   The assertion issued by the IdP acts as the proof of validation.  It
   MUST be protected against tampering and replay attacks.

   *  Cryptographic Binding: The assertion MUST be digitally signed by
      the IdP using a key verifiable by the ACME Server.



Geng, et al.            Expires 3 September 2026               [Page 21]

Internet-Draft              ACME PK Challenge                 March 2026


   *  Freshness: The assertion MUST contain a timestamp and the ACME
      token to ensure it is bound to a specific, current challenge and
      cannot be re-used in a different context.

   *  Public Key Pinning: The IdP MUST include the exact subject public
      key (PK) in the assertion to prevent "Public Key Substitution"
      attacks, where an attacker intercepts a valid identity proof but
      replaces the public key with their own.

10.3.  Credential Security and OPAQUE

   When OPAQUE is used as the authentication protocol:

   *  Password Hardening: OPAQUE provides protection against offline
      dictionary attacks even if the IdP's database is breached.
      However, the initial provisioning of temporary passwords (e.g., in
      guest access scenarios) remains a point of vulnerability.  Such
      passwords SHOULD be transmitted via out-of-band, encrypted
      channels.

   *  Session Binding: The IdP SHOULD ensure that the public key PoP
      (Proof of Possession) is performed within the secure session
      established by the OPAQUE handshake to prevent session hijacking.

10.4.  Privacy Considerations

   The IdP SHOULD only share the minimum necessary identity metadata
   with the ACME Server.  While the ACME Server needs to verify that the
   applicant is authorized, it may not require the user’s full profile.
   Implementing parties SHOULD adhere to the principle of least
   privilege regarding data disclosure in assertions.

11.  IANA Considerations

11.1.  Identifier Types

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

   +----------------+------------------+
   | Label          | Reference        |
   +----------------+------------------+
   | pk             | RFC XXXX         |
   +----------------+------------------+







Geng, et al.            Expires 3 September 2026               [Page 22]

Internet-Draft              ACME PK Challenge                 March 2026


11.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                      | Y       | RFC XXXX   |
   +------------+-------------------------+---------+------------+

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

   [RFC9807]  Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
              OPAQUE Augmented Password-Authenticated Key Exchange
              (aPAKE) Protocol", RFC 9807, DOI 10.17487/RFC9807, July
              2025, <https://www.rfc-editor.org/info/rfc9807>.

   [RFC9883]  Housley, R., "An Attribute for Statement of Possession of
              a Private Key", RFC 9883, DOI 10.17487/RFC9883, October
              2025, <https://www.rfc-editor.org/info/rfc9883>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

Authors' Addresses

   Feng Geng
   Huawei Technologies
   Email: gengfeng@huawei.com




Geng, et al.            Expires 3 September 2026               [Page 23]

Internet-Draft              ACME PK Challenge                 March 2026


   Panyu Wu
   Huawei Technologies
   Email: wupanyu3@huawei.com


   Liang Xia
   Huawei Technologies
   Email: frank.xialiang@huawei.com











































Geng, et al.            Expires 3 September 2026               [Page 24]
