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

1.1. Background and Motivation

In the current ACME process, applicants must separately generate and submit a PKCS#10 CSR during the "finalize" phase, which presents the following issues:¶

• Implementation Burden: CSR requires clients to implement ASN.1 encoding, DER format construction, and PKCS#10 encapsulation. For standard Domain Validation (DV) certificates and resource-constrained devices, this introduces unnecessary complexity.¶

• Semantic Redundancy: In the ACME certificate scenario, the certificate’s subject information can be provided through existing methods; the CSR serves solely as a carrier for transmitting the public key, and other fields (such as the Subject DN) are typically ignored by the CA.¶

• Post-Quantum Migration: The signature sizes of post-quantum signature algorithms (such as ML-DSA and SLH-DSA) are significantly larger than those of traditional algorithms, and ASN.1 toolchains do not yet fully support the identifiers for these algorithms; as a result, CSR-based processes face higher compatibility risks in post-quantum scenarios. This extension provides a more streamlined migration path for the introduction of post-quantum cryptography by moving the public key declaration to newOrder, transmitting it in the original SPKI format, and using the declared key directly to complete the PoP signature.¶

The solution proposed in this document is to move the public key declaration to the "newOrder" phase and perform ownership verification during the challenge phase using methods such as private key signatures. As a result, the "finalize" phase does not require a CSR; instead, the ACME server issues the certificate directly using the verified public key and the identifiers in the order.¶

This extension minimizes changes to the existing ACME infrastructure, adding only three top-level fields — public_key, pop_mode, and csr_less — to the "newOrder" request and introducing a new challenge type, "pk-01". No modifications are required to the behavior during the finalization phase.¶

3.1. Description of New Fields

The rules for the pop_mode field are as follows:¶

• "async" (Asynchronous mode): The applicant pre-deploys the PoP signature proof to a specified resource location, and the AS independently queries and verifies it at any time; the applicant does not need to be online during verification. Supported delivery methods are declared by the supported_delivery field of the challenge target and can be "dns", "http", or "email".¶

• "sync" (Synchronous mode): AS performs authentication by interacting directly with the applicant's server via a real-time protocol; the applicant MUST remain online during authentication. Supported delivery methods are specified by the supported_delivery declaration; a typical implementation is a simplified "tls-alpn" handshake.¶

• If pop_mode is omitted, CA SHOULD use the "async" by default.¶

• If the CA does not support the scheme declared by the client, it SHOULD return an error in the response.¶

3.2. newOrder Request Example

{
  "identifiers": [
    { "type": "dns", "value": "example.com" }
  ],
  "public_key": "<Claimed Public Key, Base64URL-encoded SPKI>",
  "pop_mode": "async",
  "csr_less": true
}

{
  "identifiers": [
    { "type": "dns", "value": "example.com" }
  ],
  "public_key": "<Claimed Public Key, Base64URL-encoded SPKI>",
  "pop_mode": "sync",
  "csr_less": true
}

{
  "identifiers": [
    { "type": "rfc822name", "value": "user@example.com" }
  ],
  "public_key": "<Claimed Public Key, Base64URL-encoded SPKI>",
  "pop_mode": "async",
  "csr_less": true
}

4.1. Base KeyAuthorization Value

The base keyAuthorization value is consistent with [RFC8555]:¶

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))

4.2. Signature Construction in Asynchronous Mode

In asynchronous mode, signed messages (to_sign) append a usage context prefix and an identifier string to keyAuthorization. The usage context prefix (ACME-pk-01\x00) provides cryptographic domain separation from other protocols (see §7.5), while the identifier serves as a defense against UKS attacks (see §7.2):¶

to_sign_async = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

Proof of Possession Value:¶

proof = base64url(Sign(claimedPrivateKey, to_sign_async))

Here, identifier is the string value of the identifier associated with the current authorization (such as "example.com" or "user@example.com"). For the semantics of Sign(key, message), see §4.4.¶

Deployment locations for proofs of each identifier type:¶

4.3. Signature Construction in Synchronous Mode

In synchronous mode, the token in a signed message is replaced with a new random number (nonce) issued by the CA to ensure the timeliness of the signature, and the message is similarly appended with a usage context prefix and identifier.¶

keyAuthorization_sync = nonce || "." || base64url(JWK_Thumbprint(accountKey))
to_sign_sync = "ACME-pk-01\x00" || keyAuthorization_sync || "." || identifier

Proof of Possession Value:¶

proof = base64url(Sign(claimedPrivateKey, to_sign_sync))

The nonce is issued by the CA in the challenge object (see §5.4.1) and has at least 128 bits of entropy. The semantics of Sign(key, message) are described in §4.4.¶

A typical implementation of the synchronous mode is the TLS-ALPN handshake: the CA initiates a TLS connection to the applicant’s domain (using the ALPN protocol identifier "acme-pk/1"), and the applicant’s server returns a proof during the handshake. The CA simultaneously verifies both domain reachability (control) and the signature (proof of private key possession). The time-sensitive nature of the nonce ensures that the signature cannot be precomputed.¶

4.4. Signature Algorithm Convention

In this document, Sign(key, message) denotes performing a complete signing operation on the raw bytes of message (the algorithm handles the hashing internally; the caller must not perform any additional hashing on message beforehand). The specific algorithm is determined by the key type of the declared public key:¶

The server SHOULD reject signature algorithms that are not included in the table above or do not comply with the current security baseline requirements, and explicitly declare the set of supported algorithms in the metadata of the Directory resource. Clients MUST use algorithms that correspond to the declared public key types; algorithm mismatches will result in signature verification failure.¶

5.1. Asynchronous mode of DNS

{
  "type": "pk-01",
  "url": "https://acme.example.com/acme/chall/abc123",
  "status": "pending",
  "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA",
  "supported_delivery": ["dns", "http"]
}

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))

to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

proof = base64url(Sign(claimedPrivateKey, to_sign))

_acme-challenge.example.com.  120  IN  TXT  "<proof>"

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

5.2. Asynchronous mode of HTTP

The asynchronous mode supports deploying PoP proofs to an HTTP path on a domain, which the AS retrieves independently via a GET request. Unlike DNS delivery, this method does not require DNS write permissions, but the applicant’s HTTP server MUST be accessible from the outside. The applicant does not need to remain online while the AS performs verification.¶

{
  "type": "pk-01",
  "url": "https://acme.example.com/acme/chall/def456",
  "status": "pending",
  "token": "DGyRejmCefe7v4NfDGDKfA",
  "supported_delivery": ["dns", "http"]
}

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

proof = base64url(Sign(claimedPrivateKey, to_sign))

http://<domain>/.well-known/acme-challenge/<token>

keyAuthorization = token || "." || base64url(JWK_Thumbprint(accountKey))
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

5.3. Email Scenario

The "pk-01" email scenario is based on the "email-reply-00" challenge mechanism defined in [RFC8823] and is suitable for email certificate application scenarios such as S/MIME (using the rfc822name type identifier); it always uses the asynchronous mode.¶

5.4. Synchronous mode of TLS-ALPN

In synchronous mode, the AS performs real-time verification through a direct TLS handshake with the applicant’s server; the applicant MUST remain online during the verification process. This document defines a new ALPN protocol identifier, "acme-pk/1" (see §2 and §8.3), for this handshake negotiation, using a simplified implementation: The client uses a signature message containing a nonce signed with the claimed private key pair to complete the PoP signature, and transmits the proof to the AS via the TLS handshake using the ALPN protocol identifier "acme-pk/1", without embedding the proof in the X.509 certificate extension fields.¶

"acme-pk/1" is a different application-layer protocol from "acme-tls/1" as defined in [RFC8737]: "acme-tls/1" requires the construction of a self-signed X.509 certificate containing OID extensions; in the "acme-pk/1" handshake, the server directly returns the raw proof bytes in the TLS application data, resulting in a simpler implementation with no additional restrictions on post-quantum large-size signatures.¶

{
  "type": "pk-01",
  "url": "https://acme.example.com/acme/chall/sync789",
  "status": "pending",
  "nonce": "Kz3mVpQeRd9fLwYbN5hXuT6oJsIc0vAg2nEp1yMrFqZ",
  "supported_delivery": ["tls-alpn"]
}

to_sign = "ACME-pk-01\x00" || keyAuthorization_sync || "." || identifier

proof = base64url(Sign(claimedPrivateKey, to_sign))

keyAuthorization_sync = nonce || "." || base64url(JWK_Thumbprint(accountKey))
to_sign = "ACME-pk-01\x00" || keyAuthorization_sync || "." || identifier

5.5. Protocol Interaction Process

EE (Applicant)              AS (ACME Server)         DNS Server
     |                            |                       |
     |-------1. newOrder--------->|                       |
     |       identifiers,         |                       |
     |       public_key: PK,      |                       |
     |       pop_mode: "async"    |                       |
     |                            |                       |
     |<------2. pk-01 (token)-----|                       |
     |                            |                       |
     |   [keyAuth, to_sign]       |                       |
     |   [proof=Sign(SK,to_sign)] |                       |
     |                            |                       |
     |-------------------3. DNS TXT record--------------->|
     |       _acme-challenge.example.com = proof          |
     |                            |                       |
     |-------4. POST {"delivery": |                       |
     |        ----   "dns"}------>|                       |
     |                            |                       |
     |              5. Look up DNS TXT records----------->|
     |                            |<------TXT: proof------|
     |                            |                       |
     |    [6. Reconstruct to_sign,|                       |
     |      verify the signature using the PK]            |
     |                            |                       |
     |<---7. Challenge valid------|                       |
     |                            |                       |
     |----8. finalizeOrder------->|                       |
     |   (without CSR)            |                       |
     |                            |                       |
     |<--9. Certificate(PK, SAN)--|                       |
     |                            |                       |

EE (Applicant)                                   AS (ACME Server)
     |                                                    |
     |-------------------1. newOrder--------------------->|
     |                 identifiers,                       |
     |                 public_key: PK,                    |
     |                 pop_mode: "sync"                   |
     |                                                    |
     |<------------------2. pk-01 (nonce: N)--------------|
     |                                                    |
     |  [keyAuth_sync,to_sign, proof]                     |
     |  [Configure TLS Listener,                          |
     |             ALPN: "acme-pk/1"]                     |
     |                                                    |
     |-----------3. POST {"delivery": "tls-alpn"}-------->|
     |                                                    |
     |<---------------4. TLS handshake--------------------|
     |           (domain:443, ALPN: "acme-pk/1")          |
     |                                                    |
     |----------------5. return proof-------------------->|
     |                                                    |
     |   [6. Reconstruct `to_sign` using the local `N`    |
     |               verify the signature using the PK]   |
     |                                                    |
     |<---------------7. Challenge valid------------------|
     |                                                    |
     |----------------8. finalizeOrder------------------->|
     |                  (without CSR)                     |
     |                                                    |
     |<-------------9. Certificate(PK, SAN)---------------|
     |                                                    |

6.1. csr_less: true（No CSR）

"finalize" requests do not require a CSR, and the body may be an empty object. The server constructs and issues the certificate directly based on the following sources:¶

• Public Key: Taken from the public_key field in "newOrder" (the declared public key, verified via a challenge).¶

• Subject Alternative Name (SAN): Taken from the identifiers field in "newOrder".¶

POST /acme/order/xyz/finalize HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{}

The server issues a certificate using the public_key (claimed public key) as the public key and the domain name in identifiers as the SAN, and returns the certificate download URL.¶

6.2. csr_less: false（Compatibility mode, default value）

"finalize" requests MUST still include a standard PKCS#10 CSR; the process is consistent with the standard ACME [RFC8555] procedure. At this point, the "pk-01" challenge is performed as an additional public key pre-validation step: after verifying the proof of ownership of the claimed public key during the challenge phase, the server performs an additional byte-by-byte comparison during the "finalize" phase to ensure that the public key in the CSR matches the public_key field exactly before issuing the certificate. If the two do not match, the server MUST reject the request and return an error.¶

POST /acme/order/xyz/finalize HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{
  "csr": "<DER-encoded PKCS#10 CSR, Base64URL-encoded>"
}

6.3. Public Key Consistency Validation and Byte Normalization

Regardless of the value of csr_less, the server MUST:¶

1. Confirm that the order status is "ready" (all challenges have been passed).¶

2. Perform a strict byte-by-byte comparison between the public key to be written to the certificate and the public_key declared in "newOrder" to ensure they are exactly the same.¶

To ensure the reliability of byte-level comparison, the server MUST treat the raw bytes of the public_key received in the "newOrder" request as the sole authoritative source and MUST NOT perform any form of DER normalization, re-encoding, or attribute pruning on it. A single cryptographic key may have multiple valid DER encodings (for example, the ECParameters field of an EC public key can be in OID format or implicit format). If the server normalizes the data during storage or comparison, this can result in false negatives (valid requests being rejected) or false positives (keys with different encodings being mistakenly identified as identical).¶

7.1. Proof of Key Possession

"pk-01" requires applicants to possess the private key corresponding to the public key they declare. The server MUST verify the signature using the public_key in "newOrder" and MUST NOT rely on indirect methods to infer ownership of the public key. When issuing a certificate, the server MUST compare the public key bytes again to ensure consistency.¶

7.2. Unknown Key Share Attack Mitigation

An Unknown Key Sharing (UKS) attack is described as follows: An attacker claims another person’s public key and requests PoP verification for a domain under their control, attempting to bind the other person’s public key to their own domain.¶

This document defends against this attack by including an identifier field in the signed message:¶

to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier

identifier explicitly binds the current authorization to a specific domain or email address, ensuring that signatures generated for different identifiers cannot be used interchangeably.¶

7.3. Replay Attack Prevention

In asynchronous mode, the token MUST meet the unpredictability requirement (entropy of at least 128 bits) [RFC4086]. In synchronous mode, the nonce MUST also have an entropy of at least 128 bits. The server accepts each nonce only once; after use, it MUST immediately mark it as consumed. Any subsequent authentication requests carrying the same nonce MUST be rejected to prevent replay attacks.¶

7.4. DNS Control Dependency

In asynchronous mode (DNS identifier), security relies on the applicant having actual control over the corresponding DNS zone. If DNS control is compromised (e.g., through DNS hijacking), an attacker could write a forged signature into the TXT record. Implementers SHOULD use this in conjunction with DNSSEC.¶

7.5. Cross-Protocol Attack Mitigation

When a single private key is used across multiple protocols (such as TLS, CMS, and IKEv2), an attacker may trick the key into signing a maliciously crafted ACME challenge within the context of one of these protocols, thereby passing PoP verification without actually possessing the private key. This type of attack is known as a cross-protocol attack.¶

This document appends a fixed usage context prefix, "ACME-pk-01\x00" (a fixed ASCII string followed by a NUL byte), to the beginning of all "pk-01" signed messages. Its function is identical to the 64-byte padding and context string mechanism used in the CertificateVerify message in TLS 1.3:¶

to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || identifier
proof   = base64url(Sign(claimedPrivateKey, to_sign))

This prefix ensures that the signature message for "pk-01" is structurally distinct from the signature fields of other protocols. Even if the same private key is used for signing by another protocol, the resulting signature cannot be reused in the context of "pk-01".¶

Implementers MUST include this prefix when constructing and verifying signed messages; omitting the prefix is considered a protocol violation.¶

7.6. Algorithm Agility

The type of the claimed public key determines the range of signature algorithms that can be selected. The server SHOULD reject signature algorithms that do not meet the current security baseline requirements and explicitly state the supported algorithms in the metadata of the Directory resource.¶

7.7. Authorization Reuse Binding

RFC 8555 supports the reuse of valid, unexpired authorizations. However, "pk-01" authorizations are bound to specific public_key: if the public key associated with the reused authorization differs from the public key claimed in the new order, an attacker could exploit this to request a certificate for an unverified public key.¶

The server MUST persistently store the original bytes of the public_key from the successful "pk-01" challenge in the authorization record, and perform a byte-by-byte comparison when reusing the authorization: if there is a mismatch, MUST reject the reuse and trigger a new challenge.¶

7.8. Security Notes for csr_less Mode

After enabling csr_less: true, the finalization phase no longer passes the public key via the CSR; the CA relies entirely on the public_key declared in "newOrder" and validated by the "pk-01" challenge. In this scenario, the proof of private key ownership from the "pk-01" challenge is the sole cryptographic basis for the public key’s legitimacy. The server MUST perform byte-level locking on the order’s public key after the challenge verification passes to prevent subsequent requests from replacing the public key.¶

8.1. ACME Validation Methods

This document requests that IANA add the following entry to the ACME Validation Methods registry.¶

8.2. IANA ACME Message Fields

This document requests that IANA add the following entry to the ACME Validation Fields registry.¶

newOrder request fields:¶

Challenge Target Field:¶

8.3. TLS ALPN Protocol Identifier Registration

This document requests that IANA add the following entry to the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry [RFC7301] with the IETF as the Change Controller:¶

The "acme-pk/1" identifier is reserved for TLS-ALPN delivery in the "pk-01" challenge synchronization mode; its operational semantics differ from those of [RFC8737]: In TLS sessions using "acme-pk/1", the server returns the raw proof bytes directly in the TLS application data after the handshake is complete, without constructing an X.509 certificate or embedding any challenge data in the certificate extension fields.¶

9.1. ACME Server

• When processing a "newOrder" request, the server must perform strict format validation on the public_key field to verify that it is a valid DER-encoded SPKI; for unsupported key types, it SHOULD return an error. The server MUST store public_key in the raw bytes received and must not perform any DER normalization or re-encoding (see §6.3).¶

• The server must verify the uniqueness of the token in asynchronous mode and the nonce in synchronous mode to prevent token reuse.¶

• Before issuing the certificate, the server must verify the public key bytes once again to ensure they match exactly, byte-for-byte, with the public key declared in "newOrder".¶

• The server MUST mark the nonce as used immediately after it is consumed for the first time and reject any subsequent attempts to reuse it. The server should limit the validity window of the nonce (RECOMMENDED to be no longer than the challenge token's validity period).¶

• When executing an asynchronous HTTP GET request, the server MUST NOT follow HTTP redirects that change the target domain to a different domain (cross-domain redirects), as following such redirects would invalidate the domain control verification. The server SHOULD allow same-domain redirects (such as HTTP → HTTPS redirects within the same host) and adhere to the standard ACME http-01 HTTP request specifications (timeouts, maximum number of redirects, etc.) to prevent server-side request forgery (SSRF).¶

• The server SHOULD include a supported_delivery field in the challenge object to declare all supported delivery methods for the client to choose from.¶

• After the server receives the Challenge-Response POST request, it must read the delivery field to determine which verification method to use; if the delivery field is missing or contains an unsupported value, the server SHOULD return an error.¶

9.2. ACME Client

• The client MUST ensure that the private key used for signing strictly matches the public_key declared in "newOrder"; a mismatch in key types will cause the server to fail the signature verification.¶

• In synchronous mode, the client MUST send a response to the challenge URL only after the TLS listening configuration is complete, to ensure it is reachable when the server initiates the TLS handshake.¶

• In asynchronous mode, the client SHOULD verify that the resource (DNS TXT record or HTTP path) has taken effect before notifying the server, taking into account DNS propagation delays or HTTP service availability.¶

• When csr_less: true, the body of the "finalize" request may be an empty object {}, the client does not need to construct a CSR; when csr_less: false (default), the client MUST still submit a standard PKCS#10 CSR during the "finalize" phase, and the public key in the CSR MUST match the public_key declared in "newOrder".¶

• When sending a challenge-response POST request, the client MUST include a delivery field in the request body, and its value must be one of the items in the supported_delivery list of the challenge object.¶

10.1. Asynchronous Mode: pk-01 (DNS) – Complete Interaction, Without Extensions

Prerequisites: The applicant MUST have DNS control over the domain example.com and a P-256 key pair (private key d, public key Q, SPKI-encoded as pk_spki).¶

Step 1: newOrder Request¶

POST /acme/new-order HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{
  "identifiers": [
    { "type": "dns", "value": "example.com" }
  ],
  "public_key": "pk_spki",
  "pop_mode": "async",
  "csr_less": true
}

Step 2: The server returns the pk-01 challenge¶

{
  "type": "pk-01",
  "url": "https://acme.example.com/acme/chall/abc123",
  "status": "pending",
  "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
}

Step 3: The client generates a signature and writes it to the DNS TXT record¶

keyAuthorization = "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA.pswg5_v_JaVFRXrHxGfJkg"
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || "example.com"
proof = base64url(Sign(d, to_sign))  →  "<proof_value>"
# The Sign() function uses ECDSA-with-SHA256 (P-256 key) and internally signs the `to_sign` value after applying SHA-256 to it.

_acme-challenge.example.com.  120  IN  TXT  "<proof_value>"

Step 4: The client notifies the server, and the server queries and verifies¶

POST /acme/chall/abc123 HTTP/1.1
Content-Type: application/jose+json

{"delivery": "dns"}

The server queries the TXT record for _acme-challenge.example.com, reconstructs to_sign locally, verifies the signature using pk_spki, and sets the challenge status to valid upon successful verification.¶

Step 5: finalizeOrder (without CSR)¶

POST /acme/order/xyz/finalize HTTP/1.1
Content-Type: application/jose+json

{}

The server issues a certificate using pk_spki as the public key and example.com as the subject alternative name (SAN).¶

10.2. Asynchronous Mode: pk-01 (HTTP) – Complete Interaction, Without Extensions

Prerequisites: The applicant MUST have HTTP control over the domain example.com and a P-256 key pair.¶

Step 1: newOrder Request¶

POST /acme/new-order HTTP/1.1
Content-Type: application/jose+json

{
  "identifiers": [
    { "type": "dns", "value": "example.com" }
  ],
  "public_key": "pk_spki",
  "pop_mode": "async",
  "csr_less": true
}

Step 2: The server returns the pk-01 challenge¶

{
  "type": "pk-01",
  "url": "https://acme.example.com/acme/chall/def456",
  "status": "pending",
  "token": "DGyRejmCefe7v4NfDGDKfA",
  "supported_delivery": ["dns", "http"]
}

Step 3: The client generates a signature and deploys it to the HTTP path¶

keyAuthorization = "DGyRejmCefe7v4NfDGDKfA.pswg5_v_JaVFRXrHxGfJkg"
to_sign = "ACME-pk-01\x00" || keyAuthorization || "." || "example.com"
proof = base64url(Sign(d, to_sign))
# The Sign() function uses ECDSA-with-SHA256 (P-256 key) and internally signs the `to_sign` value after applying SHA-256 to it.

Deploy to: http://example.com/.well-known/acme-challenge/DGyRejmCefe7v4NfDGDKfA¶

Content: <proof>¶

Step 4: The client notifies the server, and the server initiates an HTTP GET authentication request¶

POST /acme/chall/def456 HTTP/1.1
Content-Type: application/jose+json

{"delivery": "http"}

The server sends an HTTP GET request to http://example.com/.well-known/acme-challenge/DGyRejmCefe7v4NfDGDKfA to verify domain ownership. After validating the signature, it sets the challenge status to "valid".¶

Step 5: finalizeOrder (without CSR)¶

The server issues a certificate using pk_spki as the public key and example.com as the subject alternative name (SAN).¶