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]
