All of the proposed changes look fine. One comment is inline below. On 2/10/25, 4:22 AM, "Brockhaus, Hendrik" <hendrik.brockhaus@xxxxxxxxxxx <mailto:hendrik.brockhaus@xxxxxxxxxxx>> wrote: Carl Thank you for your review. Please find my comments below. You can find the Diff on Github https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-automation-keyusages&url_2=https://lamps-wg.github.io/automation-keyusages/draft-ietf-lamps-automation-keyusages.txt <https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-lamps-automation-keyusages&url_2=https://lamps-wg.github.io/automation-keyusages/draft-ietf-lamps-automation-keyusages.txt> Hendrik >Von: Carl Wallace via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> >Gesendet: Freitag, 7. Februar 2025 11:55 > >Reviewer: Carl Wallace >Review result: Has Nits <snip> >- The last two sentences of the last paragraph are overly broad. >As written, I could elect to use any of these KeyPurposeIds for any purpose I want to. >That can't be the intention and it's in direct conflict with the first paragraph of Section >3. Suggest deleting those sentences. I suspect the point was to address combination >of KeyPurposeIds. If this is correct, >maybe: "This specification does not prohibit combining the KeyPurposeIds defined in >this specification with any other KeyPurposeId. Such restrictions may be imposed by >other technical standards or certificate policies." This point is already made in section >3, though, so deletion is fine too. [HB] This paragraph is not about combinations of keyPurposeIds. In my company it was discussed whether the keyPurposeIds defined here, which are first used in the EU-Rail specification, may also be used in other industry-specific standards. The aim of this paragraph is to express that the use of the keyPurposeIds defined in this document can be used by any other application specific standard. If it does no harm, I would like to keep this statement. [CW] OK, but I still think its too broadly worded. How about instead of "How any of the KeyPurpose OIDs defined in this document are implemented is out of scope of this document" something like "The context in which the KeyPurposeIds defined in this document are used is out of scope for this document." > >Section 3 >- s/keyPurposeId's/KeyPurposeIds >- s/KeyPurposeId's/KeyPurposeIds [HB] Done >- In the last paragraph, the should in the first sentence should probably be SHOULD. [HB] I think normative language does not hurt. >- Why are keyEncipherment and keyAgreement mentioned in this draft? All of the >KeyPurposeIds are focused on signature usage. Suggest: All certificates containing >one of the KeyPurposeIds defined in this specification MUST also feature a >KeyUsage extension that asserts the digitalSignature value. [HB] Actually the safetyCommunication KeyPurposeId may also be used for TLS server certificates. [CW] Well, for TLS 1.2 but OK. > >Section 5 >This section does not add much. Admonishing a CA to include "correct" values for >EKU and KU extensions is not necessary. The point about combinations is already >made in Section 3. [HB] You are right. I borrowed the Section form RFC 9336 and RFC 9509 expecting it is required. Do you think I should remove it? [CW] I don't suppose it matters much if it stays, it just doesn't do much either. <snip> -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
