Hi Deb, We have just published -21 (see diff from -20 at [1]) in response to your follow-up comments.
[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-uta-tls13-iot-profile-21 Find a few more notes inline. On Tue, 19 May 2026 at 12:47, Deb Cooley <[email protected]> wrote: > > This draft is much improved. Thank you for that quick work! > > I have a few follow on comments: > > 1. Section 12: The move of the SNI-related paragraph from Section 17.4.1 to > Section 12 now highlights a contradiction about whether the extension should > be mandatory or not. I suggest a fresh read of Section 12 might be in order. Yes, you are right. We have adjusted the text to clarify that it's MTI for clients, not for constrained servers. > 2. Section 17.1.5: It is permissible to have an end entity certificate with > unlimited lifetime while the CA that issued it has an expiration time? > Please add some cautionary language either here or in Sec Consid about the > consequences of taking this path. This is a debate in the industry. Different fora have made different decisions. The letter of the law (RFC5280) is that the IDevID certificate becomes invalid when the signing (subordinate) CA becomes invalid. This contradicts the entire utility of the IDevID, and 802.1AR is silent about that. Good crypto hygiene suggests generating new subordinate CAs periodically to sign IDevID. (Maybe even daily.) There is, however, no requirement that the subordinate CA's certificate expire at the same time as its private key is destroyed. We say: "_Careful consideration_ is therefore required before issuing IDevID certificates with no maximum validity period, since an effectively unlimited certificate lifetime is only useful if _the relevant certification path remains usable_ for the intended lifetime of the device." And we don't say how the path remains usable :-) > 3. Section 17.1.7: This section is much better, but now a device relies on > shorter lifetime certificates? In general, the document recommends limiting the lifetime of “operational” certs (e.g., for LDevIDs, see §17.1.5, 5th para), and presents EE certs as “typically” short-lived (§17.1.7, 2nd para). We believe the message is pretty consistent. > Do we need guidance when unlimited lifetime certificates are allowed?[as in > Section 17.1.5?] The document observes that IDevIDs (which are "manufacturer-provisioned" rather than "operational" credentials) are, for practical reasons, often made by the manufacturer as "forever" objects. This is semantically incorrect and therefore problematic, but it is useful for preventing accidental bricking. (BTW, we added a concrete example of that.) We suggest the manufacturer think twice, but it is essentially framed as a soft recommendation -- probably the best we can do in the context of this document. > 4. Section 17.1.7, last paragraph: We need some discussion on the issues > created by not re-auth/re-establish of a long running TLS session. > Maintaining a session helps with operational considerations, but perhaps not > with security. Added. We also took the opportunity to reflow §17.1.7 to make it more cohesive. Thank you again for the great comments. cheers! _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
