[Acme] Re: I-D Action: draft-geng-acme-public-key-07.txt

[Ilari Liusvaara <[e-mail]>]

On Sun, Jun 14, 2026 at 06:13:21AM -0700, [e-mail] wrote:
> Internet-Draft draft-geng-acme-public-key-07.txt is now available. It is a
> work item of the Automated Certificate Management Environment (ACME) WG of the
> IETF.
> 
>    Title:   Automated Certificate Management Environment (ACME) Extension for Public Key Challenges
>    Authors: Feng Geng
>             Panyu Wu
>             Liang Xia
>             Xin Chen
>    Name:    draft-geng-acme-public-key-07.txt
>    Pages:   56
>    Dates:   2026-06-14
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-geng-acme-public-key/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-geng-acme-public-key-07.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-geng-acme-public-key-07

Some comments from partial read (did not go through the more technical
stuff yet):


I do not think this approach works. The problem is that each
authorization only needs one valid challenge. With identifier types like
"dns" and "ip", this must establish control, which "pk-01" does not do.

Why is this a new field, instead of new identifier type? If it was a
new identifier type, one could have authorization for it, and hang the
"pk-01" off that.

Acme-profiles is not suitable for specifying subject. For SAN, I would
think the identifiers are enough (this might need new identifier types
to be added in the future).

And with regards to attestation: Be careful. TLS has formal analyis turn
up multiple subtle issues with attestation. There might be subtle issues
here in ACME too.

Documents should not have explicit lists of supported algorithms. At
least not without consideration how that list can be extended later.




-Ilari