Return-Path: X-Original-To: acme@mail2.ietf.org Delivered-To: acme@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E2030AC0FDEA for ; Fri, 23 Jan 2026 08:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSGB2xPJmhmK for ; Fri, 23 Jan 2026 08:49:30 -0800 (PST) Received: from mail-dy1-x132f.google.com (mail-dy1-x132f.google.com [IPv6:2607:f8b0:4864:20::132f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0D67EAC0FD9D for ; Fri, 23 Jan 2026 08:49:30 -0800 (PST) Received: by mail-dy1-x132f.google.com with SMTP id 5a478bee46e88-2b71515d8adso2405704eec.1 for ; Fri, 23 Jan 2026 08:49:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769186969; cv=none; d=google.com; s=arc-20240605; b=B/nMzA2cS/hOqwomx+Zl12SyfT/82xwVtOIWq5MyQ00jgrXcn3yKa13rvcavDHOLuK +Bk3oDVxTUr4byh3AgJve0kbt/ZuiptQpT6vP4nIFeDg0IYrZE3/rKETQy46txRcrmrV TiiwebkkgZy5VkeCUFiZaSnVOKUH7XoE4Gdl/0sDcnaEVMkXPzEI1GQWCeOBbeBGv1V8 dGJdB6rYgV3HROrWAJCc5Hxz52FMd4mi+yVRKyDwOCg3BbU821QzyOYYoq0U4DOsCboy LuhxbsB+8mpdfCNy8khgKxQLskZrLC2zekqvU+L5WqCMXpF0zIO+MfDZL1PU8BbN9USx t8Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=+R11iqDIjwl6BY/JuCOKdorrv1KmqTgMNf0DAwcxcgw=; fh=s9ZmbJ7J3U+EtC74p/CzWDmpXYIUS3bWOgxk7sZCLe0=; b=RZHQbcx72MEEtXo7NRa2Jfdb8VQvlI2YTEZO1YLuA039/cK692SnPnFBDWWCvh1R3V v006xSPjGcv+jW1rYs7jxfw+kObXfRYyCO7iP68P7XcvgCZOMBatiOFnCIS9vQnMxNvs L70xw3e7r4pL72KBt5SaRSoXijBKXMsn4MSpO+23SEeGthJW6Oq5sQ8DyrNLSn7tqPAe FJW+xDjyCtMtlLFX7gx9ZDaVev+NDwgQrbcrSTgHYtqVCMEpUNe9144ClnW6NJzSDsnQ ETGtRGSRkXEcrIKiV210XRY5y0UM2Qp7niWquoGH6sk6CcupbEnHqIqlHn95CC+Uv1W1 obUg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769186969; x=1769791769; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+R11iqDIjwl6BY/JuCOKdorrv1KmqTgMNf0DAwcxcgw=; b=A+zqXGHCn0s4LMDq2/3dWMaUmTgoQIqqqhfhf21Cxne9bQnRNtqXZxrNt8mOVUPBat PYRGUhklKqolkJCOLxq37pq/NmETFw6okXApe6nTPaKWXJn002lBeP1U9zAv5cN/bEwQ VyZ4v2XSElrEsiz7W0Rg9sSfBOUO6TetUMRKpC99k7ne9DLydN0+dH6rUQoeL/cKTCkg F4M8LEMcjPmiKGB6AyDtvb9orNzs4W4WHjJLz+LX+mgdpvVxoMXDisVnE5DlaWDz8MBi Zzm850snYKfrXAnc43WBIvzi2F14THv0GU2pHnlI9VHJoKHFbCtP+C1xfGjbBLamv+A1 1+jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769186969; x=1769791769; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+R11iqDIjwl6BY/JuCOKdorrv1KmqTgMNf0DAwcxcgw=; b=dQpqk8onTPNUFeJKco1zyN4UKgvSNrxuxyHKMbsHyL0CPXbAY+hYVm/8hPckeCb/g3 piRanwspJSYrDFYn3HO9ywC0kgrSKmfBFYxaEvfeSGCA9Oh81M8txGPcREHG5szS1H42 yYsERzDp4U+RCFjQakutoDosan0vs4m7uOAymYYhjHFAzYkHGhL5i22G74lS/2vrNNcI q2SqCbQV+CuWz8mABMbb03w9q67sGN++SIrNqsALe3v1mQUIj7c2WLGcTPRLWPEH3G+x jK1iaxYUKGM0jgVVldavxT3y0qmQvCaQ0W7YIkusQejbRFPMoaYlWBfsL6WOtpNroZoB 17dw== X-Forwarded-Encrypted: i=1; AJvYcCXQMvdQ5Uf+iuAdg6oqFHBmC8H0xy8IkhVrPaFIOew1Xg+ZkJvwLXubnSwZBY8iFI9Dljb8@ietf.org X-Gm-Message-State: AOJu0YwYP6Sh/SA0JIiiKRPD+BrLMO6XzPlCL6RQg4LRFhxIXZTNSma7 kzYOQPXEzmuvw45hEvMbY/eNTpq2SU40Fz1lsEDNxy6VGBIvWYv2DIrgu1RdaK0BhzW8FWKw8q5 hBOlM88BtGPTlaTIE53IRDXy8wdXcjA== X-Gm-Gg: AZuq6aK1LznyUy+7QbnbLd6jkQsuLSlTMh3A5S3ZaSxk3fR8sbsTIFVYVsS5LHQOqSn +3afzxJl+gDa1H+OT1ku7gPa+BnKgq5UEAc0ifVLCBCieDrxJDqVVPmZuJvuVsjw/G5aIgi0WjA /WTv9egqwB8nxyYNG2BX5HRJIiUlYp79dqWOCKEY8oGnvfOhyJOS+mrYxnC3Ny4x6JxgCeRyPFg fgIoItBMNQlYrmu3q7zNxk0V6baXeaIRtengvyavfdfiHs4cv7V+2zwILN0iA0WThOwqvTWGqVI mxoHGN8qUVPFYlj8GNVBO0wuZPagL+MX7ERTYn0ipMGp8Dtv2JirtF9rSRFsuiPp2hoPEyNqgIJ UUOtzU10Z2vDqzA== X-Received: by 2002:a05:7300:5726:b0:2ac:1506:c781 with SMTP id 5a478bee46e88-2b73999511bmr1357459eec.10.1769186968625; Fri, 23 Jan 2026 08:49:28 -0800 (PST) MIME-Version: 1.0 References: <10927.1766855792@obiwan.sandelman.ca> In-Reply-To: From: Deb Cooley Date: Fri, 23 Jan 2026 11:49:18 -0500 X-Gm-Features: AZwV_QhkgCAh8AGIP_FsaUg5wn06aDnw90FXUxQWQ-Hf4mfek8YFwf-w_HUmrG0 Message-ID: To: Sven A Rajala , "draft-ietf-acme-device-attest.authors@ietf.org" Content-Type: multipart/related; boundary="000000000000cee291064910f0ba" Message-ID-Hash: SLMQNAZZAVDVWTCFR7WH56ELHDNUSLUB X-Message-ID-Hash: SLMQNAZZAVDVWTCFR7WH56ELHDNUSLUB X-MailFrom: debcooley1@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-acme.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "" , IETF ACME X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BAcme=5D_Re=3A_AD_comments_on_draft-ietf-acme-device-attest?= List-Id: Automated Certificate Management Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000cee291064910f0ba Content-Type: multipart/alternative; boundary="000000000000cee290064910f0b9" --000000000000cee290064910f0b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Sven A Rajala 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 publis= h > 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, a= nd > 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 * > > > *From: *Sven A Rajala > *Date: *Wednesday, 2026 January 7 at 22:47 > *To: *Deb Cooley , Michael Richardson < > mcr+ietf@sandelman.ca> > *Cc: *draft-ietf-acme-device-attest.authors@ietf.org < > draft-ietf-acme-device-attest.authors@ietf.org>, > , IETF ACME > *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 > > > 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 * > > > *From: *Deb Cooley > *Date: *Sunday, 2025 December 28 at 07:26 > *To: *Michael Richardson > *Cc: *draft-ietf-acme-device-attest.authors@ietf.org < > draft-ietf-acme-device-attest.authors@ietf.org>, > , IETF ACME > *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 > > > inline w/ [DC] > > On Sat, Dec 27, 2025 at 12:16=E2=80=AFPM Michael Richardson > wrote: > > > Deb Cooley 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 poli= ce > 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 publis= h > 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/ > > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ > > | ruby on rails [ > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > --000000000000cee290064910f0b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've left a couple of little comments on the PR.<= /div>

Once you up issue=C2=A0the 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 h= im, but he will need to be responsive at some point).

<= div>Deb

p.s. I do love the sig file.=C2=A0 I'l= l leave it at that.=C2=A0

On Wed, Jan 21, 2026 a= t 10:40=E2=80=AFAM Sven A Rajala <Sven.Rajala@keyfactor.com> 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=


=C2=A0 =C2=A0 > *Section 1, last para:=C2=A0 I am assuming that the auth= ors believe the rats
=C2=A0 =C2=A0 > work is substantially far into the future?=C2=A0 (Or why= would we publish the
=C2=A0 =C2=A0 > challenge device-attest-01 if the rats work would replac= e it?).=C2=A0 With any
=C2=A0 =C2=A0 > 'SHOULD' one needs to outline when one might ign= ore 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 a= lready 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=C2=A0Rajala

International PKI Man of My= stery=C2=A0

=C2=A0

M:=C2=A0+1 540 687 0761

sven.rajala@keyfactor.com=C2=A0

=C2=A0

From: Sven A Rajala <sven.rajala@keyfactor.com>
Date: Wednesday, 2026 January 7 at 22:47
To: Deb Cooley <debcooley1@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca&g= t;
Cc: draft-ietf-acme-device-attest.authors@ietf.org <= draft-ietf-acme-device-attest.authors@ietf.org>,
<acme-chairs@i= etf.org>, IETF ACME <acme@ietf.org>
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.
=C2= =A0
Thanks for the review Deb and Michael. Ganesh and I will work on incorporat= ing the feedback.

Thank you,

Sven=C2=A0Rajala

International PKI Man of My= stery=C2=A0

=C2=A0

M:=C2=A0+1 540 687 0761

sven.rajala@keyfactor.com=C2=A0

=C2=A0

From: Deb Cooley <debcooley1@gmail.com>
Date: Sunday, 2025 December 28 at 07:26
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: draft-ietf-acme-device-attest.authors@ietf.org <= draft-ietf-acme-device-attest.authors@ietf.org>,
<acme-chairs@i= etf.org>, IETF ACME <acme@ietf.org>
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.
=C2= =A0
inline w/ [DC]

On Sat, Dec 27, 2025 at 1= 2:16=E2=80=AFPM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Deb Cooley <de= bcooley1@gmail.com> wrote:
=C2=A0 =C2=A0 > Here are my comments on this draft.=C2=A0 There is one t= hat has broader
=C2=A0 =C2=A0 > implications (*).=C2=A0 I'd like to see this address= ed by the working group
=C2=A0 =C2=A0 > (specifically, why is there a need for multiple attestat= ion 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:
=C2=A0 "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) a= s
part of a bill of sale or while applying for insurance.=C2=A0 =C2=A0The VIN= won't tell
you who *owns* the car [or if it passed a safety/emission test], but it wil= l
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]=C2=A0 well, it can = still be done.=C2=A0 Certainly drafts have changed their titles while in=C2= =A0
IESG evaluation.=C2=A0 = =C2=A0

=C2=A0 =C2=A0 > Also, I recognize that I'm posting these during the = holidays.=C2=A0 I certainly
=C2=A0 =C2=A0 > don't expect authors to respond until after the new = year.

:-)

=C2=A0 =C2=A0 > *Section 1, last para:=C2=A0 I am assuming that the auth= ors believe the rats
=C2=A0 =C2=A0 > work is substantially far into the future?=C2=A0 (Or why= would we publish the
=C2=A0 =C2=A0 > challenge device-attest-01 if the rats work would replac= e it?).=C2=A0 With any
=C2=A0 =C2=A0 > 'SHOULD' one needs to outline when one might ign= ore the SHOULD.

It won't replace it, it might complement it.
=C2=A0
[DC]=C2=A0 Then the draf= t needs to state that.=C2=A0 And SHOULD at that point seems... odd.=C2=A0

=C2=A0 =C2=A0 > Section 7.3:=C2=A0 What is the bullet 'Change Contro= ller' meant to accomplish?

It tells IANA who can update this entry.
=C2=A0
[DC]=C2=A0 We can certai= nly ask IANA, but all the registries listed are pre-existing acme entries w= ith various RFCs as the references.=C2=A0 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).=C2=A0


You might benefit from reading my email at:
https://mailarchive.ietf.org/arc= h/msg/rats/zu3Mqm-FOm2pAi1GymfDVHey-7s/

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby = on rails=C2=A0 =C2=A0 [


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--000000000000cee290064910f0b9-- --000000000000cee291064910f0ba Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_19bebbebb084cff311 iVBORw0KGgoAAAANSUhEUgAAABIAAAASCAYAAABWzo5XAAAAAXNSR0IArs4c6QAAAHhlWElmTU0A KgAAAAgABQESAAMAAAABAAEAAAEaAAUAAAABAAAASgEbAAUAAAABAAAAUgEoAAMAAAABAAIAAIdp AAQAAAABAAAAWgAAAAAAAACQAAAAAQAAAJAAAAABAAKgAgAEAAAAAQAAABKgAwAEAAAAAQAAABIA AAAAP0JqHQAAAAlwSFlzAAAWJQAAFiUBSVIk8AAAABhJREFUOBFjYBgFoyEwGgKjITAaAthDAAAF IgAByPUp7wAAAABJRU5ErkJggg== --000000000000cee291064910f0ba--