These all look good to me. I'll submit the draft to IETF Last Call. Thanks for the quick and thorough work.
Deb Cooley On Mon, May 25, 2026 at 10:57 AM Thomas Fossati <[email protected]> wrote: > 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]
