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]
