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

[Mike Ounsworth <[e-mail]>]

Hello ACME,

I notice that in this whole thread only one person actually answered the
adoption questions (which was Michael Richardson who said "I would not
adopt."). I remind you that the adoptions questions were:

1) Does the WG want to work on a new ACME challenge for public key
proof-of-possession towards goals such as removing the CSR, enrolling KEM
certificates, and potentially other applications?

2) Does the WG feel that this draft is a reasonable starting point for
discussing and designing a solution to (1)?


There is not enough in this thread for me to make a consensus call, so I am
going to extend the Call For Adoption by another two weeks.


[chair hat off]

As a WG participant, I believe:

1) yes, extending ACME to allow alternate PoP mechanisms is a valuable
thing for the WG to spend effort on.

2) yes, I believe this draft provides a good starting point that we can
iterate. In particular, the authors seem happy to take design feedback from
the WG, so I believe that if we start from this draft, we will arrive at a
solution that everyone is happy with.


On Tue, 5 May 2026 at 18:47, 皮皮猪 <507069=[e-mail]> wrote:

> Hi Michael,
>
> To clarify the architectural reasoning behind the pk-01 proposal, I would
> like to outline how we see the verification dimensions in ACME.
>
> ACME [RFC8555] models certificate enrollment as an order containing a set
> of identifiers. Each identifier maps to an authorization that carries a set
> of challenges. Existing challenges such as dns-01 and http-01 address
> Domain Control Validation (DCV).
>
> Early versions of the pk-01 draft (prior to -05) also explored Identity
> Control Validation (ICV) for non-DCV scenarios. This line of exploration
> originated from the sso-01 draft and several subsequent related drafts.At
> that stage, public-key identity binding and Proof-of-Possession (PoP) were
> interleaved, aiming to shift the paradigm from "controlling communication
> resources" toward "controlling the claimed identity."
>
> Following extensive discussion, beginning around draft -05/-06, community
> feedback converged on the view that PoP should be fully decoupled as an
> independent component. The central question, therefore, is not whether to
> replace the CSR, but rather: what mechanism should prove possession of a
> public key, and how can that mechanism be combined orthogonally with both
> the existing DCV framework in ACME and any future ICV?
>
> In short, the ACME protocol suite comprises three independent verification
> dimensions, each supported by its own protocol framework. DCV and ICV stand
> as parallel capabilities; either can independently satisfy identifier
> validation and support certificate issuance. PoP is an independent
> verification dimension. It may be used together with DCV or ICV and may
> also serve alone as the basis for certificate requests when an order
> contains only the "pk" identifier.
>
> In my understanding, the three are fully orthogonal to each other.
>                         ACME identifier
>                                   |
>           +------------+------------+
>           |                       |                     |
>          dns-01            pk-01            idp-01
>           |                       |                     |
>           v                     v                    v
>          DCV              PoP                ICV
>           |       (fully decoupled)          |
>           +------------+------------+
>           |                                             |
>  DCV + (PoP)                          ICV + (PoP)
>
> DCV [RFC8555]: Do you control this domain name?
> ICV (idp-01): Do you control this identity?
> PoP (pk-01): Do you possess this private key?
>
> Best regards
> Geng Feng
> 原始邮件
> ------------------------------
> 发件人：Michael Richardson <[e-mail]>
> 发件时间：2026年5月5日 23:16
> 抄送：[e-mail] <[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> 主题：Re: [Acme] Call for adoption: draft-geng-acme-public-key-06 (Ends
> 2026-05-12)
>
>
> palos.chen <[e-mail]> wrote:
>     >> 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.
>
> But, it's the wrong approach.
> You have to change pk-01 each time someone comes along with a new challenge
> type.   What you are doing is orthogonal to the challenge.
>
>     > 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.
>
> okay, but I still think this is the wrong direction.
>
> I think that what you are proposing is useful, but it's a fundamental change
> to ACME, and should be treated that way.
>
>
>     >> 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).
>
> Then, let's fix/replace CSR.
>
>
>     >> 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.
>
> I think the chairs are wrong here :-)
>
> I don't think this is a good direction to go, because I don't think your
> needs are not the same as, for instance, .onion.
>
>
> --
> 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]
>