[Acme] Re: Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)

["palos.chen" <[e-mail]>]

Hi Michael,

Thanks for the detailed review. We've prepared a revision (draft-geng-acme-public-key-07, attached) that addresses most of your points.

Walking through them:


> It seems that this almost suffers from the same mis-understanding of challenges as acme-rats originally did. At least though, the intention is that it is pk-01 OR dns-01 OR http-01 OR ... (not AND as rats needed)

In -07, pk-01 is no longer entangled with identifier validation. We introduced a new "pk" identifier type (Section 3); pk-01 is bound to "pk" identifiers and proves possession of the certificate private key only. Existing challenges (dns-01, http-01, ...) remain bound to their own identifier types per [RFC8555] without modification.

An order can carry both identifier types:



{
  "identifiers": [
    { "type": "dns", "value": "www.example.com" },
    { "type": "pk",  "value": "<base64url(SPKI)>" }
  ]
}


> This produces two independent authorizations, evaluated per [RFC8555] Section 7.1.6 (all authorizations across all identifiers must reach "valid"; within each authorization the client picks one challenge to complete). See -07 Sections 3.2 and 3.3.

In the "async" mode, the pk-01 replaces the dns-01, http-01 or email-01 challenges. This would seem to wind up limiting future extensions to challenge types, and it does not cover all the challenge types extensions we've already done. (like, onion, subdomain, dns-persist, ...)

The async/sync modes of -06 are entirely removed in -07. pk-01 no longer carries any identifier control role. Existing extensions (onion-csr-01, subdomain, dns-persist, etc.) continue to operate unchanged alongside pk-01.


> I'm not entirely sure how the client communicates to the server what mechanism is going to be used.

There is no mechanism negotiation in -07. The challenge mode (signature vs KEM) is determined uniquely by the AlgorithmIdentifier inside the SPKI carried by the "pk" identifier value — see -07 Section 3.1.


> I found 4.3, async, not well enough described. Sounds like https-01?

Section 4.3 of -06 is gone. -07 Section 4 specifies one challenge object format per key type and one validation flow per mode.


> Examples should include dns-01, http-01 as options that the client does not choose.

Done. -07 Section 11.1 Step 2:

The authorization for the dns identifier typically contains multiple challenges such as dns-01, http-01, and tls-alpn-01; the client picks one to complete per [RFC8555] Section 7.1.4. This example uses dns-01 (per [RFC8555] Section 8.4).

> Replacing the CSR with something better, something that can deal with keys that can't make signatures (either do to math or policy) is important. I had proposed work like this if/when we start RFC7030bis.

We share this motivation. KEM-key support is in fact one of the primary reasons for a dedicated PoP mechanism rather than relying on the CSR self-signature, which is impossible for KEM-only keys. -07 supports ML-KEM-512/768/1024 via a Decapsulate + HKDF + HMAC PoP — see Section 5.2 (KEM PoP construction) and Section 5.4 (KEM algorithm registry).


> The ACME server should simply announce the set of POP methods that it can support, with CSR being the default. I don't think a new challenge method is the correct way to negotiate this.

This is the one architectural point where we've taken a different direction, following the chair's earlier guidance and the model that ACME has consistently used: challenges bound to identifier types (dns-01 for dns, http-01 for dns-via-http, onion-csr-01 for onion, etc.). -07 introduces a "pk" identifier type and a pk-01 challenge bound to it, which keeps the architecture modular and aligned with how the working group has handled similar extensions.

That said, -07 Section 5.5 does include directory-level capability advertisement: the server SHOULD declare its supported signature and KEM algorithms in Directory metadata, giving clients a way to check support before initiating an order.

If you see specific failure modes of the challenge-type approach that would not occur under a directory-announcement approach, we'd welcome a concrete discussion — happy to follow up either on the list or in a side thread.


Best regards!

2026年5月1日 01:36，Michael Richardson <[e-mail]> 写道：


I would not adopt.
This is the wrong way to do this.

Mike Ounsworth via Datatracker <[e-mail]> wrote:
This message starts a acme WG Call for Adoption of:
draft-geng-acme-public-key-06

This Working Group Call for Adoption ends on 2026-05-12

Chair Note #1: The most recent version of the draft has significantly
scoped-down the content from what was presented at IETF 125. This draft
is now purely focused on the pk-01 challenge type towards the goal of
being able to remove the ASN.1 CSR from an ACME flow.

okay... but:

}   After the ACME server receives a "newOrder" request containing the
}   public_key field, it will issue a "pk-01" challenge for each
}   identifier.  When csr_less is set to "true", the server issues the

It seems that this almost suffers from the same mis-understanding of challenges as
acme-rats originally did.   At least though, the intention is that it is
pk-01 OR dns-01 OR http-01 OR ...  (not AND as rats needed)

In the "async" mode, the pk-01 replaces the dns-01, http-01 or email-01 challenges.
This would seem to wind up limiting future extensions to challenge types, and
it does not cover all the challenge types extensions we've already
done. (like, onion, subdomain, dns-persist, ...)

I'm not entirely sure how the client communicates to the server what
mechanism is going to be used.

I found 4.3, async, not well enough described.  Sounds like https-01?

Examples should include dns-01, http-01 as options that the client does not
choose.

Replacing the CSR with something better, something that can deal with keys
that can't make signatures (either do to math or policy) is important.
I had proposed work like this if/when we start RFC7030bis.

The ACME server should simply announce the set of POP methods that it can
support, with CSR being the default.
I don't think a new challenge method is the correct way to negotiate this.

Chair Note #2: IPR

yeah.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **




_______________________________________________
Acme mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]