MIME-Version: 1.0
References: <aaa921f7e971495e9a360e789e5d7b00@unibw.de>
In-Reply-To: <aaa921f7e971495e9a360e789e5d7b00@unibw.de>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Tue, 16 Jun 2026 08:56:13 -0400
Message-ID: 
 <CAN40gSuGSL-QSJVgMwJgGLEkiP0AGPqh5=B2yiUUOexvhPkZZQ@mail.gmail.com>
To: "Tschofenig, Hannes" <hannes.tschofenig=40unibw.de@dmarc.ietf.org>,
	Ira McDonald <blueroofmusic@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000067df3606545e78cd"
Message-ID-Hash: 4BTJQ3QZHQP7T5RYQKTFXLWHZRLCYWKC
CC: uta@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BUta=5D_Re=3A_Genart_review_of_draft-ietf-uta-tls13-iot-profile-?=
	=?utf-8?q?21?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/uta/coRviakbFU7WxfDUX7JJm3WHmP8>

--00000000000067df3606545e78cd
Content-Type: text/plain; charset="UTF-8"

Hi Hannes,

BTW - That MAC address draft is already approved and in the RFC Editor
queue, so not a blocking reference for you.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*
*Co-Chair - TCG Mobile Platform WG*


*Chair - Linux Foundation Open Printing WGSecretary - ISTO Printer Working
GroupCo-Chair - ISTO PWG Internet Printing Protocol WGIETF Designated
Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Tue, Jun 16, 2026, 8:03 AM Tschofenig, Hannes <hannes.tschofenig=
40unibw.de@dmarc.ietf.org> wrote:

> Hi Russ,
>
> Thank you for the careful review and the helpful suggestions.
>
> We have updated the draft to address your comments. In particular:
>
> * We clarified the certificate serial number generation. The draft now says
> that CAs SHOULD generate serial numbers containing at least eight octets of
> unpredictable output, and that this random value MAY be combined with a
> counter or other information that ensures uniqueness.
>
> * We clarified the discussion of the PKI hierarchy and device credentials,
> including the relationship between IDevIDs, LDevIDs, manufacturer CAs,
> operator-issued certificates, and application instance certificates.
>
> * We clarified that this document borrows selected terminology and
> certificate
> fields from IEEE 802.1AR, but does not claim conformance to IEEE 802.1AR.
>
> * We clarified that CA certificates and end-entity certificates are not
> required
> to use the same signature algorithm, while noting that CAs should select
> algorithms that constrained relying devices can actually validate.
>
> * We added text explaining that TLS 1.3 certificate-based authentication
> uses
> signature-capable end-entity certificates, and that static DH/ECDH
> certificate-based key exchange modes from TLS 1.2 are prohibited by this
> profile.
>
> * We expanded the certificate lifetime discussion to point out that an
> IDevID
> with an effectively unlimited lifetime is only useful if the relevant
> certification path remains usable for the intended device lifetime.
>
> * We have made many editorial fixes.
>
> Here is the PR:
>
> <https://github.com/thomas-fossati/draft-tls13-iot/pull/202>
> https://github.com/thomas-fossati/draft-tls13-iot/pull/201
>
> There is an open issue from your review, namely:
> "
> Section 17.4.1: Why prohibit the use of MACAddress otherName as specified
> in draft-ietf-lamps-macaddress-on, which is in the RFC Editor's queue.
> "
>
> I had not realized that this draft already existed; we need to brainstorm
> how to address this issue.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> Uta mailing list -- uta@ietf.org
> To unsubscribe send an email to uta-leave@ietf.org
>

--00000000000067df3606545e78cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hi Hannes,</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">BTW - That MAC address draft is already approved and in the RFC E=
ditor queue, so not a blocking reference for you.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto">- Ira</div><div><b=
r></div><div data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div =
dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><=
div dir=3D"ltr"><i><font size=3D"1">Ira McDonald (Musician / Software Archi=
tect)</font></i></div><div><i><font size=3D"1"></font></i></div><div dir=3D=
"ltr"><i><font size=3D"1">Co-Chair - TCG Mobile Platform WG</font></i></div=
><div><i><font size=3D"1"></font></i></div><div dir=3D"ltr"><i><font size=
=3D"1">Chair - Linux Foundation Open Printing WG<br>Secretary - ISTO Printe=
r Working Group<br>Co-Chair - ISTO PWG Internet Printing Protocol WG<br>IET=
F Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music / High North=
 Inc<br><a style=3D"color:rgb(51,51,255)" href=3D"http://sites.google.com/s=
ite/blueroofmusic" target=3D"_blank">http://sites.google.com/site/blueroofm=
usic</a><br><a style=3D"color:rgb(102,0,204)" href=3D"http://sites.google.c=
om/site/highnorthinc" target=3D"_blank">http://sites.google.com/site/highno=
rthinc</a><br>mailto: <a href=3D"mailto:blueroofmusic@gmail.com" target=3D"=
_blank">blueroofmusic@gmail.com</a><br>(permanent) PO Box 221=C2=A0 Grand M=
arais, MI 49839=C2=A0 906-494-2434</font></i></div></div></div></div></div>=
</div></div></div></div></div></div></div></div></div></div></div></div></d=
iv></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"l=
tr" class=3D"gmail_attr">On Tue, Jun 16, 2026, 8:03 AM Tschofenig, Hannes &=
lt;hannes.tschofenig=3D<a href=3D"mailto:40unibw.de@dmarc.ietf.org">40unibw=
.de@dmarc.ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir=3D"ltr">
<div id=3D"m_-28581994037812676divtagdefaultwrapper" dir=3D"ltr" style=3D"f=
ont-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,&qu=
ot;EmojiFont&quot;,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;=
,NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,Emoji=
Symbols">
<p></p>
<div>Hi Russ,<br>
<br>
Thank you for the careful review and the helpful suggestions.<br>
<br>
We have updated the draft to address your comments. In particular:<br>
<br>
* We clarified the certificate serial number generation. The draft now says=
<br>
that CAs SHOULD generate serial numbers containing at least eight octets of=
<br>
unpredictable output, and that this random value MAY be combined with a<br>
counter or other information that ensures uniqueness.<br>
<br>
* We clarified the discussion of the PKI hierarchy and device credentials,<=
br>
including the relationship between IDevIDs, LDevIDs, manufacturer CAs,<br>
operator-issued certificates, and application instance certificates.<br>
<br>
* We clarified that this document borrows selected terminology and certific=
ate<br>
fields from IEEE 802.1AR, but does not claim conformance to IEEE 802.1AR.<b=
r>
<br>
* We clarified that CA certificates and end-entity certificates are not req=
uired<br>
to use the same signature algorithm, while noting that CAs should select<br=
>
algorithms that constrained relying devices can actually validate.<br>
<br>
* We added text explaining that TLS 1.3 certificate-based authentication us=
es<br>
signature-capable end-entity certificates, and that static DH/ECDH<br>
certificate-based key exchange modes from TLS 1.2 are prohibited by this<br=
>
profile.<br>
<br>
* We expanded the certificate lifetime discussion to point out that an IDev=
ID<br>
with an effectively unlimited lifetime is only useful if the relevant</div>
<div>certification path remains usable for the intended device lifetime.<br=
>
<br>
* We have made many editorial fixes.</div>
<br>
Here is the PR:=C2=A0
<p></p>
<p><a href=3D"https://github.com/thomas-fossati/draft-tls13-iot/pull/202" t=
arget=3D"_blank" rel=3D"noreferrer"></a><a href=3D"https://github.com/thoma=
s-fossati/draft-tls13-iot/pull/201" target=3D"_blank" rel=3D"noreferrer">ht=
tps://github.com/thomas-fossati/draft-tls13-iot/pull/201</a><br>
</p>
<br>
<p>There is an open issue from your review, namely:<br>
&quot;</p>
<div>Section 17.4.1: Why prohibit the use of MACAddress otherName as specif=
ied<br>
in draft-ietf-lamps-macaddress-on, which is in the RFC Editor&#39;s queue.<=
/div>
&quot;<br>
<p><span style=3D"white-space:pre-wrap">I had not realized that this draft =
already existed; we need to brainstorm how to address this issue.</span></p=
>
<br>
<p></p>
<p>Ciao<br>
Hannes</p>
<p><br>
</p>
</div>
</div>

_______________________________________________<br>
Uta mailing list -- <a href=3D"mailto:uta@ietf.org" target=3D"_blank" rel=
=3D"noreferrer">uta@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:uta-leave@ietf.org" targe=
t=3D"_blank" rel=3D"noreferrer">uta-leave@ietf.org</a><br>
</blockquote></div>

--00000000000067df3606545e78cd--