Hi Aaron, Thanks a lot for the detailed and thoughtful review this is really helpful.
A PR has already been raised to address the issues you’ve highlighted, and we’re actively working through the fixes. Specifically: - The ABNF formatting issue (backticks rendering in HTML/TXT) has been identified and is being corrected. - We’re expanding the discussion around identifier privacy into the Security Considerations section to provide clearer guidance for implementers. We’ll share an updated revision shortly once these changes are incorporated. Really appreciate the thorough review, this is helping improve the clarity and robustness of the draft. Regards, Ganesh Mallaya On Wed, Apr 1, 2026 at 1:30 PM Aaron Gable <aaron= [email protected]> wrote: > 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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
