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 < [email protected]> 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 > [email protected] > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
