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]>, [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]
