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]
