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: [email protected] <[email protected]>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434* On Tue, Jun 16, 2026, 8:03 AM Tschofenig, Hannes <hannes.tschofenig= [email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
