[Acme] Re: WG Last Call: draft-ietf-acme-device-attest-02 (Ends 2026-04-09)

[Aaron Gable <[e-mail]>]

Hi all,

Here are notes from my review of the most recent version of this document:

1. The new ABNF production rules in 3.1 and 4.1 appear to have mangled
formatting: the triple backticks delimiting a code block are present
verbatim in both the HTML and TXT views of the document.

2. Sections 3.2 and 4.2 both note that the Server may wish to omit the
identifier from the resulting certificate due to "privacy concerns". These
should probably be discussed in more detail in the Security Considerations
section, so implementers can make informed decisions about whether and when
to include these identifiers.

3. Section 1 states that the new device-attest-01 challenge type can prove
control of either permanent-identifier or hardware-module identifiers.
However, Section 8.2 only adds one new entry to the ACME Validation Methods
IANA registry. It should add two entries, one for each identifier type (see
the current table
<https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods>
which
has multiple rows for http-01, one for dns and one for ip identifiers).

4. It's unclear how the device-attest-01 challenge demonstrates control
over a specific permanent-identifier or hardware-module. The value of the
identifier never comes up in the validation flow. Contrast this with
http-01, where the identifier is part of the URL the server makes a request
to, or tkauth-01, where the TNAuthList appears within the "atc" claim. I
*think* what's happening here is that the permanent identifier or hardware
module would appear within the WebAuthn attestation, and would be validated
as part of "1. Perform the verification procedures described in Section 6
of WebAuthn". But suppose someone produced a WebAuthn attestation which
attested *nothing* except for the key authorization itself. Then it seems
like this would be a valid challenge response, and the Server should mark
the Authorization as valid, even though nothing related to the
permanent-identifier has actually been demonstrated.

Thanks for all the revisions so far, I think this is a big improvement.

Aaron

On Thu, Mar 26, 2026 at 3:44 PM Mike Ounsworth via Datatracker <
[e-mail]> wrote:

> This message starts a WG Last Call for:
> draft-ietf-acme-device-attest-02
>
> This Working Group Last Call ends on 2026-04-09
>
> Abstract:
>    This document specifies new identifiers and a challenge for the
>    Automated Certificate Management Environment (ACME) protocol which
>    allows validating the identity of a device using attestation.
>
> File can be retrieved from:
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> [e-mail]
> in copy. Objections should be explained and suggestions to resolve them are
> highly appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the
> provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-acme-device-attest-02.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-device-attest-02
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>