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. 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. 3. Section 17.1.7: This section is much better, but now a device relies on shorter lifetime certificates? Do we need guidance when unlimited lifetime certificates are allowed?[as in Section 17.1.5?] 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. Deb On Mon, May 18, 2026 at 9:18 AM Thomas Fossati <[email protected]> wrote: > Hi Deb, > > Thanks a lot for your in-depth review, much appreciated! > > We believe that all of your comments should be addressed in -20. > > For the diff, see: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-uta-tls13-iot-profile-20 > > cheers! > > On Fri, 15 May 2026 at 16:01, Deb Cooley <[email protected]> wrote: > > > > Thank you for your work on this specification, apologies for taking so > long to send comments (I won't bore you with my excuses). > > > > I will happily take questions and/or comments on these. > > > > Deb Cooley > > Sec AD > > > > --------------------------------------- > > General: If there are implementations which feel comfortable being > listed, I think it would be a good idea. This could be in the shepherd's > writeup or you can add a section that would be removed by the RFC Editor > before publication (possibly in the 'discussion venue' section w/ a > modified name). > > > > CA/Browser Forum: There needs to be a stable reference for whatever you > are referring to when you say that the profile aligns or doesn't align with > something the CA/Browser Forum is specifying. > > > > Section 3: Why isn't the 'Record Size Limit extension' not listed here? > > > > Section 8: Add a sentence that states that this is out of scope at the > beginning of the section. This way it is clear that RFC 9150 is not a > normative reference. > > > > Section 10, para 2: How does the transmission of an ACK signal any sign > of disruption? Isn't it the lack of an ACK that does that? > > > > Section 11: RFC 7925 points to RFC 4086 which is pretty old at this > point. One could point to 8446bis, or if suitable RFC 8937. > > > > Section 17: There is so much quoting of RFC 5280 (sometimes with a > link, sometimes not). Is it really necessary? Could you make a statement > at the beginning of the section, and only mention it when the profile > deviates from it? > > > > Section 17, para 3 and beyond: Does this profile only handle entities > that have Device Identifiers? Or are there other options? If there are > other options, consider putting all the Device Identifier information in > its own section. > > > > Section 17, sentence after second set of bullets: This sentence is > repetitive, I suggest deleting it. > > > > Section 17, second to last paragraph: I struggle to see the point > beyond what the previous paragraph already makes. If the point is that > there are many bootstrapping protocols, then perhaps say that. I would > move the sentence about IDevIDs having a long lifetime up into the previous > paragraph. > > > > Section 17, last paragraph: I'm not entirely sure what the point is. > The second sentence is way too long. How about: 'However, this > specification does not claim conformance to IEEE 802.1AR which is broader, > mandates hardware, security, and process requirements outside IoT > constraints. This profile borrows terminology and fields but intentionally > omits those operational requirements.' Although I don't like 'operational' > in my second sentence since the first sentence doesn't use that term. > Maybe 'process requirements? Sentence 3 has the same issue... long enough > that one loses the plot before the end of the sentence. Sentence 4, IDK, I > lost the will to live before this sentence. I'd start over with a topic > sentence, and a couple of points. > > > > Section 17.1: Remove the first phrase, 'to avoid repetition'. I'm not > sure what the last sentence note is supposed to convey, it only serves to > make it confusing - the first sentence says 'requirements on X.509 > certificates', does the rest need to be explained? > > > > Section 17.1.2: Not quite. RFC 5280 does not require non-sequential > serial numbers, it only requires them to be unique for a given CA. I would > delete the last paragraph. > > > > Section 17.1.3, 17.1.6, last sentence: What is the advantage of using > the same signature algorithm for both CAs and devices? Under what > circumstances might one violate the 'SHOULD'? [note: in my opinion, this > SHOULD makes it harder to transition later, one has to update the CAs and > then the devices which increases the timeline.] > > > > Section 17.1.5: Please make it clear that if one uses the concept of > 'unlimited lifetime' that this applies to the whole trust chain - from the > trust anchor (Root CA) down to the subordinate CAs. > > > > Section 17.1.7: This comment can be summarized as 'don't bury the > lede': Para 1 and 2 - separate the background sentences from the > requirement/guidance sentences. Reworking some of these sentences to be > shorter and more concise would be a good idea. Para 3, where to start... > Remove 'has also seen considerable uptake...', 'some of which are > standardized'. Sentence 4 'device management protocols...' should be the > first sentence. Make 'Certificate upsdates do not affect existing...' to > the end a new paragraph (since it has nothing to do with short cert > lifetimes). Last para: should be up front in the section (without the > 'hence'). > > > > Section 17.2.4: So, if keyCertSign or cRLSign MUST be set, but there is > no Key Usage extension (since it is apparently optional - SHOULD), how does > that work? Possibly outlining when/why one might choose to not have a > keyusage extension might be a good step. Is DS required for the Root CA > certificate? > > > > Section 17.2.5: Let me understand this, a Root certificate is permitted > to have no expiry, and no limit for the depth of the CA chain. > > > > Section 17.4.1, last para: Does this actually pertain to the end-entity > certificate? I suspect this needs to be moved to a more appropriate > section, if it needs to be stated at all (how often is an IOT device a TLS > server?) > > > > Section 17.4.4, para 2: I don't believe that this is how it works. If > the private key associated with the cert is meant to be used for > authentication/signature, then DS is the appropriate KE. If the private > key is used to enable encryption (typically keyEncipherment or > keyAgreement), then those are set. Typically, one would discourage the use > of a single private key for both DS and keyEncipherment/keyAgreement uses. > Delivery of the private key to the device is a whole different matter. > This part should be removed from this section and covered elsewhere (if it > is necessary to cover it at all). > > > > Section 17.4.4, para 3: Given the current kerfluffle in the CA/B Forum > (or maybe within Google), is it still the plan to include id-kp-clientAuth? > > > > Section 20, last para: TLS 1.2? Is it a typo? > > > > Section 22: You will want to make sure that this is informational. > Maybe add a sentence to state that this section is guidance vice > requirements. > > > > Section 23: What if certificates are posted instead of transmitted > within the TLS exchange? Consider if there needs to be a mention of the > privacy situation when that option is considered (Section 19) > > > > Section 24: I do think there needs to be a discussion of the pros/cons > of a Root certificate that never expires. That discussion could be here, > or in Section 17.2.5 (I don't see it there currently). > > > > References: RFC 4210 has been obsoleted by RFC 9810 (note RFC 4210 is > ref multiple times within the draft). There are a couple of others which > have either been issued, or are in Auth48 (8446bis, for example). >
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
