MIME-Version: 1.0
References: 
 <177456502637.650544.14855547787185245061@dt-datatracker-5775bcb475-pnkww>
In-Reply-To: 
 <177456502637.650544.14855547787185245061@dt-datatracker-5775bcb475-pnkww>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Wed, 1 Apr 2026 13:29:59 -0700
Message-ID: 
 <CAEmnEreNrXnMqc+KKXKY_q8KePeRaGee4rcb66YFDwXY0O4Lkg@mail.gmail.com>
To: Mike Ounsworth <mike@ounsworth.ca>
Content-Type: multipart/alternative; boundary="0000000000004e31f5064e6bf33c"
Message-ID-Hash: IZX5BSFYACK3PZ4S2LLP75JNDCBW3AXQ
CC: acme-chairs@ietf.org, acme@ietf.org,
 draft-ietf-acme-device-attest@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BAcme=5D_Re=3A_WG_Last_Call=3A_draft-ietf-acme-device-attest-02_?=
	=?utf-8?q?=28Ends_2026-04-09=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/acme/CQJaU9JqYet03JffIdjtLoDbJo0>

--0000000000004e31f5064e6bf33c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

Here are notes from my review of the most recent version of this document:

1. The new ABNF production rules in 3.1 and 4.1 appear to have mangled
formatting: the triple backticks delimiting a code block are present
verbatim in both the HTML and TXT views of the document.

2. Sections 3.2 and 4.2 both note that the Server may wish to omit the
identifier from the resulting certificate due to "privacy concerns". These
should probably be discussed in more detail in the Security Considerations
section, so implementers can make informed decisions about whether and when
to include these identifiers.

3. Section 1 states that the new device-attest-01 challenge type can prove
control of either permanent-identifier or hardware-module identifiers.
However, Section 8.2 only adds one new entry to the ACME Validation Methods
IANA registry. It should add two entries, one for each identifier type (see
the current table
<https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods>
which
has multiple rows for http-01, one for dns and one for ip identifiers).

4. It's unclear how the device-attest-01 challenge demonstrates control
over a specific permanent-identifier or hardware-module. The value of the
identifier never comes up in the validation flow. Contrast this with
http-01, where the identifier is part of the URL the server makes a request
to, or tkauth-01, where the TNAuthList appears within the "atc" claim. I
*think* what's happening here is that the permanent identifier or hardware
module would appear within the WebAuthn attestation, and would be validated
as part of "1. Perform the verification procedures described in Section 6
of WebAuthn". But suppose someone produced a WebAuthn attestation which
attested *nothing* except for the key authorization itself. Then it seems
like this would be a valid challenge response, and the Server should mark
the Authorization as valid, even though nothing related to the
permanent-identifier has actually been demonstrated.

Thanks for all the revisions so far, I think this is a big improvement.

Aaron

On Thu, Mar 26, 2026 at 3:44=E2=80=AFPM Mike Ounsworth via Datatracker <
noreply@ietf.org> wrote:

> This message starts a WG Last Call for:
> draft-ietf-acme-device-attest-02
>
> This Working Group Last Call ends on 2026-04-09
>
> Abstract:
>    This document specifies new identifiers and a challenge for the
>    Automated Certificate Management Environment (ACME) protocol which
>    allows validating the identity of a device using attestation.
>
> File can be retrieved from:
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> acme@ietf.org
> in copy. Objections should be explained and suggestions to resolve them a=
re
> highly appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the
> provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can b=
e
> found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-acme-device-attest-02.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-acme-device-attest=
-02
>
> _______________________________________________
> Acme mailing list -- acme@ietf.org
> To unsubscribe send an email to acme-leave@ietf.org
>

--0000000000004e31f5064e6bf33c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>Here are notes from my review o=
f the most recent version of this document:</div><div><br></div><div>1. The=
 new ABNF production rules in 3.1 and 4.1 appear to have mangled formatting=
: the triple backticks delimiting a code block are present verbatim=C2=A0in=
 both the HTML and TXT views of the document.</div><div><br></div><div>2. S=
ections 3.2 and 4.2 both note that the Server may wish to omit the identifi=
er from the resulting certificate due to &quot;privacy concerns&quot;. Thes=
e should probably be discussed in more detail in the Security Consideration=
s section, so implementers can make informed decisions about whether and wh=
en to include these identifiers.</div><div><br></div><div>3. Section 1 stat=
es that the new device-attest-01 challenge type can prove control of either=
 permanent-identifier or hardware-module identifiers. However, Section 8.2 =
only adds one new entry to the ACME Validation Methods IANA registry. It sh=
ould add two entries, one for each identifier type (see the <a href=3D"http=
s://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods">curre=
nt table</a>=C2=A0which has multiple rows for http-01, one for dns and one =
for ip identifiers).</div><div><br></div><div>4. It&#39;s unclear how the d=
evice-attest-01 challenge demonstrates control over a specific permanent-id=
entifier or hardware-module. The value of the identifier never comes up in =
the validation flow. Contrast this with http-01, where the identifier is pa=
rt of the URL the server makes a request to, or tkauth-01, where the TNAuth=
List appears within the &quot;atc&quot; claim. I <i>think</i>=C2=A0what&#39=
;s happening here is that the permanent identifier or hardware module would=
 appear within the WebAuthn attestation, and would be validated as part of =
&quot;1. Perform the verification procedures described in Section 6 of WebA=
uthn&quot;. But suppose someone produced a WebAuthn attestation which attes=
ted <i>nothing</i>=C2=A0except for the key authorization itself. Then it se=
ems like this would be a valid challenge response, and the Server should ma=
rk the Authorization as valid, even though nothing related to the permanent=
-identifier has actually been demonstrated.</div><div><br></div><div>Thanks=
 for all the revisions so far, I think this is a big improvement.</div><div=
><br></div><div>Aaron</div></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 26, 2026 at 3:=
44=E2=80=AFPM Mike Ounsworth via Datatracker &lt;<a href=3D"mailto:noreply@=
ietf.org">noreply@ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">This message starts a WG Last Call for:<br>
draft-ietf-acme-device-attest-02<br>
<br>
This Working Group Last Call ends on 2026-04-09<br>
<br>
Abstract:<br>
=C2=A0 =C2=A0This document specifies new identifiers and a challenge for th=
e<br>
=C2=A0 =C2=A0Automated Certificate Management Environment (ACME) protocol w=
hich<br>
=C2=A0 =C2=A0allows validating the identity of a device using attestation.<=
br>
<br>
File can be retrieved from:<br>
<br>
Please review and indicate your support or objection to proceed with the<br=
>
publication of this document by replying to this email keeping <a href=3D"m=
ailto:acme@ietf.org" target=3D"_blank">acme@ietf.org</a><br>
in copy. Objections should be explained and suggestions to resolve them are=
<br>
highly appreciated.<br>
<br>
Authors, and WG participants in general, are reminded of the Intellectual<b=
r>
Property Rights (IPR) disclosure obligations described in BCP 79 [1].<br>
Appropriate IPR disclosures required for full conformance with the provisio=
ns<br>
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.<br>
Sanctions available for application to violators of IETF IPR Policy can be<=
br>
found at [3].<br>
<br>
Thank you.<br>
<br>
[1] <a href=3D"https://datatracker.ietf.org/doc/bcp78/" rel=3D"noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/doc/bcp78/</a><br>
[2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" rel=3D"noreferrer" =
target=3D"_blank">https://datatracker.ietf.org/doc/bcp79/</a><br>
[3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" rel=3D"noreferrer=
" target=3D"_blank">https://datatracker.ietf.org/doc/rfc6701/</a><br>
<br>
The IETF datatracker status page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/"=
 rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draf=
t-ietf-acme-device-attest/</a><br>
<br>
There is also an HTML version available at:<br>
<a href=3D"https://www.ietf.org/archive/id/draft-ietf-acme-device-attest-02=
.html" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/archive/id=
/draft-ietf-acme-device-attest-02.html</a><br>
<br>
A diff from the previous version is available at:<br>
<a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-acme-devi=
ce-attest-02" rel=3D"noreferrer" target=3D"_blank">https://author-tools.iet=
f.org/iddiff?url2=3Ddraft-ietf-acme-device-attest-02</a><br>
<br>
_______________________________________________<br>
Acme mailing list -- <a href=3D"mailto:acme@ietf.org" target=3D"_blank">acm=
e@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:acme-leave@ietf.org" targ=
et=3D"_blank">acme-leave@ietf.org</a><br>
</blockquote></div>

--0000000000004e31f5064e6bf33c--