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
[email protected]<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
[email protected]<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]<mailto:mcr%[email protected]>> wrote:
Deb Cooley <[email protected]<mailto:[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]<mailto:[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]<mailto:mcr%[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]
