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

[Michael Richardson <[e-mail]>]

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