I've left a couple of little comments on the PR. Once you up issue the draft, I'll put it into IETF Last Call (the next step in the process).
At some point soon, I suggest that you all reach out to Brandon Weeks to find out if he's interested in continuing as an author (happy to have him, but he will need to be responsive at some point). Deb p.s. I do love the sig file. I'll leave it at that. On Wed, Jan 21, 2026 at 10:40 AM Sven A Rajala <[email protected]> wrote: > Hej Debs & Michael, > > I created a PR from the comments you shared here: > https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/10 > > > > *Section 1, last para: I am assuming that the authors believe the > rats > > work is substantially far into the future? (Or why would we publish > the > > challenge device-attest-01 if the rats work would replace it?). > With any > > 'SHOULD' one needs to outline when one might ignore the SHOULD. > > This is already deployed at scale by large vendors and has been for years. > At this point, this doc is simply documenting and making official what is > already in the field. Think of this as a v1 solving a specific problem, and > the rats work as a v2 that generalizes it. > > Kindly, > > Sven Rajala > > International PKI Man of Mystery > > > > *M:* +1 540 687 0761 > > sven.rajala@*keyfactor.com <https://www.keyfactor.com/>* > > > *From: *Sven A Rajala <[email protected]> > *Date: *Wednesday, 2026 January 7 at 22:47 > *To: *Deb Cooley <[email protected]>, Michael Richardson < > [email protected]> > *Cc: *[email protected] < > [email protected]>, > <[email protected]>, IETF ACME <[email protected]> > *Subject: *Re: [Acme] AD comments on draft-ietf-acme-device-attest > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BjbSd3t9V7AnTp3tuV-82YaK!_GQhDcCG3PTnc8MyUNczNVgjv33l3DSXIBOmNETmaw9nECS6zvcZhz3bBMtpTbHJxqAAfXFj7VcW1SGzS81gFeNq2G21bQk7fhrsOEaLcuOHggyRkAyrIXJlc7t7cXRjQNnAeWjzlbRIQFMC$> > > Thanks for the review Deb and Michael. Ganesh and I will work on > incorporating the feedback. > > Thank you, > > Sven Rajala > > International PKI Man of Mystery > > > > *M:* +1 540 687 0761 > > sven.rajala@*keyfactor.com <https://www.keyfactor.com/>* > > > *From: *Deb Cooley <[email protected]> > *Date: *Sunday, 2025 December 28 at 07:26 > *To: *Michael Richardson <[email protected]> > *Cc: *[email protected] < > [email protected]>, > <[email protected]>, IETF ACME <[email protected]> > *Subject: *Re: [Acme] AD comments on draft-ietf-acme-device-attest > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/BjbSd3t9V7AnTp3tuV-82YaK!_uQhDA6gOjSI1sZc2x5_9NTONUjPYPGghTRV5pPAfas8IqUXoLeDNdilSvTgNUoRAss26dk0Tq46kFWvIB0sqW6wG7vmFFkaU6nrcc8e4MuqPraD8oT_QgaxWwvIlesN$> > > inline w/ [DC] > > On Sat, Dec 27, 2025 at 12:16 PM Michael Richardson <[email protected]> > wrote: > > > Deb Cooley <[email protected]> wrote: > > Here are my comments on this draft. There is one that has broader > > implications (*). I'd like to see this addressed by the working > group > > (specifically, why is there a need for multiple attestation > challenges). > > My long-standing comment is that this document is slightly mis-named. > I'm not sure if you asking why this document permits multiple (ACME) > challenges, or why there is more than one document with the name > "Attestation" in the title. > > I would have called this document something like: > "Device Hardware Identifiers" > > The process described has nothing to do with RFC9334 or DICE or TCG! > > To me, this is akin to recording the Vehicle Indentification Number (VIN) > as > part of a bill of sale or while applying for insurance. The VIN won't > tell > you who *owns* the car [or if it passed a safety/emission test], but it > will > tell you if the insurance slip [or emission test results] I show the police > is really for that vehicle, or for my *other* F-150^WVolkswagon Diesel. > > > [DC] well, it can still be done. Certainly drafts have changed their > titles while in > IESG evaluation. > > > > Also, I recognize that I'm posting these during the holidays. I > certainly > > don't expect authors to respond until after the new year. > > :-) > > > *Section 1, last para: I am assuming that the authors believe the > rats > > work is substantially far into the future? (Or why would we publish > the > > challenge device-attest-01 if the rats work would replace it?). > With any > > 'SHOULD' one needs to outline when one might ignore the SHOULD. > > It won't replace it, it might complement it. > > > [DC] Then the draft needs to state that. And SHOULD at that point > seems... odd. > > > > Section 7.3: What is the bullet 'Change Controller' meant to > accomplish? > > It tells IANA who can update this entry. > > > [DC] We can certainly ask IANA, but all the registries listed are > pre-existing acme entries with various RFCs as the references. There is no > place (that I can see) for what you have described (certainly registries > like media types have structures like you allude to, but the acme > registries do not). > > > You might benefit from reading my email at: > https://mailarchive.ietf.org/arch/msg/rats/zu3Mqm-FOm2pAi1GymfDVHey-7s/ > <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/rats/zu3Mqm-FOm2pAi1GymfDVHey-7s/__;!!BjbSd3t9V7AnTp3tuV-82YaK!xwG_ekoMg4roN8pgn-4cu0nVn4I1Ywul3VCI7TMAjkPKOVzkAnk7_u87EmCHkJH8-i9imwiNvaclGPYXW_SrJjtb$> > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] http://www.sandelman.ca/ > <https://urldefense.com/v3/__http://www.sandelman.ca/__;!!BjbSd3t9V7AnTp3tuV-82YaK!xwG_ekoMg4roN8pgn-4cu0nVn4I1Ywul3VCI7TMAjkPKOVzkAnk7_u87EmCHkJH8-i9imwiNvaclGPYXW7kxhX4A$> > | ruby on rails [ > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
