Subject: [Acme] Re: AD comments on draft-ietf-acme-device-attest
From: Deb Cooley <[email-masked]>
To: Sven A Rajala <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, IETF ACME <[email-masked]>
Date: Fri, 23 Jan 2026 11:49:18 -0500
List-Id: Automated Certificate Management Environment <acme.ietf.org>

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-masked]>
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-masked]>
> *Date: *Wednesday, 2026 January 7 at 22:47
> *To: *Deb Cooley <[email-masked]>, Michael Richardson <
> [email-masked]>
> *Cc: [email-masked] <
> [email-masked]>,
> <[email-masked]>, IETF ACME <[email-masked]>
> *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-masked]>
> *Date: *Sunday, 2025 December 28 at 07:26
> *To: *Michael Richardson <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>,
> <[email-masked]>, IETF ACME <[email-masked]>
> *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-masked]>
> wrote:
>
>
> Deb Cooley <[email-masked]> 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-masked]  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-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>