I have left this same comment on the PR: I don't believe this can be the correct fix, for two reasons: 1) ACME clients need to know how to encode these identifier types when they request them in a newOrder message. 2) The table in the section immediately below this references the `permanent-identifier` and `hardware-module` identifier types, so they must be defined.
Instead, the fix should be amending the text of the draft to explicitly describe how an ACME client would encode one of these identifier types in a newOrder request, and (equivalently) how the ACME server would render them when returning an Order or Authorization object. Aaron On Fri, Mar 6, 2026, 06:44 Sven A Rajala <[email protected]> wrote: > Hej Hej, > > Thank you for the expert review Richard! After some discussion we have > created a PR to address your feedback and have removed the IANA > consideration for the ACME ID Types. > > The PR is here if you would like to review: > https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/13 > > Happy Friday, > > Sven Rajala > > Deputy PKI Officer > > > > *M:* +1 540 687 0761 > > sven.rajala@*keyfactor.com <https://www.keyfactor.com/>* > > > *From: *Richard Barnes <[email protected]> > *Date: *Tuesday, 2026 March 3 at 18:01 > *To: *[email protected] < > [email protected]> > *Cc: *[email protected] <[email protected]>, [email protected] < > [email protected]> > *Subject: *[Acme] Re: [IANA #1442982] expert review for > draft-ietf-acme-device-attest (acme) > > This Message Is From an Untrusted Sender > You have not previously corresponded with this sender. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BjbSd3t9V7AnTp3tuV-82YaK!_uQhDA_K0P7N0OW-XJiS_xLhi5mHVvx8bzMwxx5otQMrftZQMC2pGji2ZvDc1ZrlqgCQGwvPNJD1iy3kwmdBnrz_-Dz5KVh9w9FFMsb7IywZBavTXK7Z7vkrMvCa6kfz$> > > Hi David, > > The requested validation method and error types are approved. The > identifier types are NOT approved. > > The document does not specify the content of the ACME identifier object > when these identifier types are used. There is discussion of what a client > may put in a CSR, but the JSON fields that appear in the identifier object > are not defined. > > --Richard > > On Mon, Mar 2, 2026 at 5:30 PM David Dong via RT < > [email protected]> wrote: > > Dear Richard Barnes, Aaron Gable (cc: acme WG), > > Following up on this expert review request from February 11th; thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Wed Feb 18 20:56:17 2026, david.dong wrote: > > Dear Richard Barnes, Aaron Gable (cc: acme WG), > > > > Following up on this expert review request; thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Wed Feb 11 00:36:58 2026, david.dong wrote: > > > Dear Richard Barnes, Aaron Gable (cc: acme WG), > > > > > > As the designated experts for the ACME Identifier Types, ACME > > > Validation Methods and ACME Error Type registries, can you review the > > > proposed registrations in draft-ietf-acme-device-attest-01 for us? > > > Please see: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/__;!!BjbSd3t9V7AnTp3tuV-82YaK!y8cW-VorNx2xtOEebJjyNTPm-uUD8c3br5tEOSrC5kT___jERN69XCBBx272gIDVPg8_ILmadu7zlWo$> > > > > > > The due date is February 24th. > > > > > > If this is OK, when the IESG approves the document for publication, > > > we'll make the registration at: > > > > > > https://www.iana.org/assignments/acme/ > <https://urldefense.com/v3/__https://www.iana.org/assignments/acme/__;!!BjbSd3t9V7AnTp3tuV-82YaK!y8cW-VorNx2xtOEebJjyNTPm-uUD8c3br5tEOSrC5kT___jERN69XCBBx272gIDVPg8_ILmaXqMomC0$> > > > > > > Unless you ask us to wait for the other reviewer, we’ll act on the > > > first response we receive. > > > > > > With thanks, > > > > > > David Dong > > > IANA Services Sr. Specialist > >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
