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 Hendrik >Von: Carl Wallace via Datatracker <noreply@xxxxxxxx> >Gesendet: Freitag, 7. Februar 2025 11:55 > >Reviewer: Carl Wallace >Review result: Has Nits > >The draft defines four new object identifiers for use with the extended key usage >extension defined in RFC 5280. The mechanism in the draft is fine and the security >considerations section seem adequate but the draft could use some editing. A few >suggestions are below. > >Intro >- Expand ERJU >- The first sentence is correct but perhaps should note the extension is defined there >too. Maybe: RFC 5280 defines the ExtendedKeyUsage extension and several >extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 >certificates. [HB] OLD RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines KeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety- critical communication to be included in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by industrial automation and the ERJU System Pillar. NEW RFC 5280 defines the ExtendedKeyUsage extension and several extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates. This document defines KeyPurposeIds for general-purpose and trust anchor configuration files, for software and firmware update packages, and for safety- critical communication to be included in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by industrial automation and the Europe's Rail Joint Undertaking (ERJU) System Pillar. > >Section 1 >- The first sentence of the fourth paragraph is not quite right. Suggest "specifies >several extended key usages" instead of "specifies several key usage extensions." [HB] Thank you for the proposal. You are right, there is only one extension and several possible IDs >- In the second sentence replace "Key usage extensions" with "KeyPurposeIds." >- s/management of trust anchor/management of trust anchors [HB] Done >- s/if the file is signed/if the file is verified [HB] Right, thank you >- Suggest adding "or in ExtendedKeyUsage extensions that have >been marked critical" to the end of the second sentence in the next to last paragraph. >- Suggest dropping "or misusing" in the same sentence. [HB] Is this the change you proposed? OLD However, using or misusing KeyPurposeIds outside of their intended vendor-controlled environment can lead to interoperability issues. NEW However, using KeyPurposeIds outside of their intended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. >- 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. > >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. > >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? > >Section 6 >s/reduces existing/reduce existing [HB] Done > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
