Hi Aaron, Richard, Following up on this review request for some clarifications on your comments.
Thank you. Best regards, David Dong IANA Services Sr. Specialist On Sat Mar 07 10:12:13 2026, [email protected] wrote: > Hi Aaron, and @Richard Barnes <[email protected]> , > > First, I want to point out that Sven has graciously stepped up to push > this > draft through to publication, even though it's not originally his > draft and > we're sorta guessing at what the use case motivations were. So I > really > appreciate everyone giving him good guidance. > > Thanks for your comment. Could you provide a little more context here > for > your comment? > > From my reading of the PR / draft, it links to [RFC4043 > <https://www.rfc-editor.org/rfc/rfc4043>] for the specification of a > CSR > attribute for PermanentIdentifier, and to [RFC4108 > <https://www.rfc-editor.org/rfc/rfc4108>] for the specification of a > CSR > attribute for HardwareModuleName. > > I don't know the right answer here, but I think I know the right > question, > which is: is it actually helpful to specify two different ways to > carry > these identifiers in an ACME request; one inside the CSR and one in > the > ACME JSON? > > I see three possible ways to resolve this situation: > > #1 Delete the ACME JSON mechanism -- this is what Sven's PR is > attempting > (but I agree that it doesn't currently delete it completely from the > document). > > #2 Delete the CSR mechanism -- this would mean fully removing all > references to [RFC4032] and [RFC4108] and instead defining new JSON > structures. > > #3 specify both -- add the JSON def's without removing the CSR > mechanism. > > On Fri, 6 Mar 2026 at 09:17, Sven A Rajala <[email protected]> > wrote: > > > Thank you for the review/feedback Aaron. We will work on amending the > > draft PR with your feedback. > > > > Happy Friday, > > > > Sven Rajala > > > > Deputy PKI Officer > > > > > > > > *M:* +1 540 687 0761 > > > > sven.rajala@*keyfactor.com <https://www.keyfactor.com/>* > > > > > > *From: *Aaron Gable <[email protected]> > > *Date: *Friday, 2026 March 6 at 09:57 > > *To: *Sven A Rajala <[email protected]> > > *Cc: *Richard Barnes <[email protected]>, drafts-expert-review- > > [email protected] < > > [email protected]>, IETF ACME <[email protected]> > > *Subject: *Re: [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!_uQhDA7he3oPdudYkfm4GoKGkNdqz7r66g_pw0icbYriykkfgNiAw38- > > xhpSfutT1yTR_GcRGaIPWJUq- > > 9b9ptLJgxVyZqekiHYUXHDn0CvX53qiB7oKWQRXHaaBb0qK$> > > > > 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] > > _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
