[Uta] Re: Genart review of draft-ietf-uta-tls13-iot-profile-21

[Ira McDonald <[e-mail]>]

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: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Tue, Jun 16, 2026, 8:03 AM Tschofenig, Hannes <hannes.tschofenig=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>