X.509 Extended Key Usage (EKU) for configuration, updates and safety-communication
draft-ietf-lamps-automation-keyusages-08

# Andy Newton, ART AD, comments for draft-ietf-lamps-automation-keyusages-05
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-automation-keyusages-05.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thank you for the work on this document.

I have the following comments.

### General Applicability

11      Abstract

13         RFC 5280 defines the ExtendedKeyUsage extension and several extended
14         key purpose identifiers (KeyPurposeIds) for use with that extension
15         in X.509 certificates.  This document defines KeyPurposeIds for
16         general-purpose and trust anchor configuration files, for software
17         and firmware update packages, and for safety-critical communication
18         to be included in the Extended Key Usage (EKU) extension of X.509 v3
19         public key certificates used by industrial automation and the
20         Europe's Rail Joint Undertaking (ERJU) System Pillar.

Is this a generally usable specification or intended mostly for the ERJU?
My impression is that this document has a broader use than just the ERJU,
and if so perhaps that langauge of the last sentence could be adjusted so it
is not suggestive of the narrower application.

My suggestion:

"... to be included in the Extended Key Usage (EKU) extension of X.509 v3
public key certificates, such as those used by industrial automation and the
Europe's Rail Joint Undertaking (ERJU) System Pillar.""

### A Long Intro

72      1.  Introduction

74         Automation hardware and software products will strategically be more
75         safe and secure by fulfilling mandatory, generic system requirements
76         related to cyber security driven by federal offices like the European
77         Union Cyber Resilience Act [EU-CRA] governed by the European
78         Commission and the High Representative of the Union for Foreign
79         Affairs and Security Policy.  Automation products connected to the
80         internet would bear the so called CE marking [CE-marking] to indicate
81         they comply.  Such regulation was announced in the 2020 EU
82         Cybersecurity Strategy [EU-STRATEGY], and complements other
83         legislation in this area, specifically the NIS2 Framework, Directive
84         on measures for a high common level of cybersecurity across the Union
85         [NIS2]. 2020 EU Cybersecurity Strategy suggests to implement and
86         extend international standards such as the Security for industrial
87         automation and control systems - Part 4-2: Technical security
88         requirements for IACS components [IEC.62443-4-2] (IACS refers to
89         industrial automation and control system) and the Industrial
90         communication networks - Network and system security - Part 3-3:
91         System security requirements and security levels [IEC.62443-3-3].
92         Automation hardware and software products of diverse vendors that are
93         connected on automation networks and the internet build common
94         automation solutions.  Harmonized attributes would allow transparency
95         of security properties and interoperability for vendors in context of
96         secure software and firmware updates, general-purpose configuration,
97         trust anchor configuration, and secure safety communication.

...

I agree with the other reviewers with regard to this being a long introduction.
IMHO, this would be more readable if the introduction summarized the technical
aspects of the specification and referenced the applicability in an appendix.

### TLS WWW Client and Server

149        The KeyPurposeId id-kp-serverAuth (Section 4.2.1.12 of [RFC5280]) can
150        be used to identify that the certificate is for a TLS WWW server, and
151        the KeyPurposeId id-kp-clientAuth (Section 4.2.1.12 of [RFC5280]) can
152        be used to identify that the certificate is for a TLS WWW client.
153        However, there are currently no KeyPurposeIds for usage with X.509
154        certificates for safety-critical communication.

Can the terms TLS WWW server and TLS WWW client be changed to HTTPS server
and HTTPS client? Or is there something specific to these clients being
based on web browsers?

### Relying Party or Relying Party Software

317        To reduce the risk of specific cross-protocol attacks, the relying
318        party or the relying party software may additionally prohibit use of

Does the software need to be explicitly mentioned? Can this just say "relying party"?

### Concrete Requirements

322        party, is defined in Section 4 of [RFC9336].  The technical standards
323        and certificate policies of the application should specify concrete
324        requirements for excluded or permitted KeyPurposeIds or their
325        combinations.  An example of excluded KeyPurposeIds can be the

In my opinion, "concrete requirements" is not concrete enough. :)
Would the following wording be helpful?

"... the application should explicitly enumerate requirements..."

# Internet AD comments for draft-ietf-lamps-automation-keyusages-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* "will strategically be more safe and secure by fulfilling mandatory,
   generic system requirements related to cyber security driven by federal"

  I don't think this is really a defensible statement.  They certainly
  "aim to be more safe ...", but whether they are or not is a function of
  a great many factors, including the quality and "up-to-date-ness" of
  various federal regulations.

Thank you for preparing this document, I have the following comments:

1. The introduction includes:  “will strategically be more safe and secure”. I think that an RFC cannot make such a claim, please consider an alternate phrase, perhaps using “are designed to make”. 

2. The first para of the introduction is long. please divide this into paragraphs (or preferably a set of subsections)
.
3. The sentence below (and following) seems like it belongs in a different paragraph:
“Automation hardware and software products of diverse vendors that are connected on automation networks and the internet build common automation solutions.” Here, I think the word “build” here is problematic and I suggest this could be “can be used to build” is much easier to read.

4. I found the last paragraph of the introduction a little hard to parse and understand, but I suspect this may be important. Is something like this a possible clearer statement?

   This specification focuses on use in industrial automation.
   The definitions are intentionally broad to also allow use of the
   KeyPurposeIds in other deployments. The details for
   each implementation needs to be described in technical standards and certificate policies.

5. Several words are used to describe similar things, and it was not clear what the difference was between “applications” “deployments” and “implementations”. Please see if fewer terms could be used to simplify reading, and makes sure it clearly sets out the various uses.

6. I expect the following sentence is about the privacy considerations: “The inclusion of the EKU extension can help an observer determine the purpose of the certificate.” - But I don’t exactly see what this implies, please explain, possibly adding “which may reveal private information”?

Section 1 makes several strong claims about things that don't have to do with the technical properties of our protocols. Fine to reference the regulations and describe their goals, but it doesn't seem appropriate to make definitive statements about the outcomes those regulations will achieve/deliver. We simply can't know that, and making those assertions isn't the IETF's role. Related, the first half of this section reads as if this document were a product of the ERJU System Pillar rather than an IETF specification. I encourage reworking the tone here.

Section 3's example specification language seem quite specific. Are these quotes from somewhere that should be referenced?

I'm unclear what makes "safety-critical communication" a key usage and what separates it from client/server authentication more broadly. I would have thought that "safety-critical" is a property of the message, with rules around which authenticated clients/servers are trusted when they assert that their messages are safety-critical. Is this effectively just moving that rule set into the CA? (It's fine to just educate me on this question, but it might be worth including the answer in the document as well.)

Minor nit:
- In Section 1, s/internet/Internet/

Hi Hendrik,

Thank you for addressing my DISCUSS and COMMENT points [1] and also merging the PR. Much appreciated. 

I'm still not comfortable including some claims about external organizations/specifications (especially on the safety/security) even if those are in an appendix. 

(1) The causality effect is not trivial IMO

   Automation hardware and software products strive to become more safe
   and secure by fulfilling mandatory, generic system requirements
   related to cyber security driven by federal offices

(2) not clear who made the call that "deliverables include due consideration of cyber security..":

The
   deliverables include due consideration of cyber security aspects
   based on the IEC 62443 series of standards, focused on the European
   railway network to which Directive 2016/797 - Interoperability of the
   rail system within the EU [Directive-2016_797] applies.

That's said, I trust the authors and Deb to do the right thing here.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/spasm/1sC5bIs7r6y2VVask6yu70xPkoE/

Thank you to Stewart Bryant for the GENART review.

Comment for the WG and responsible AD: Please consider if the LAMPS WG charter needs to be clarified.  It currently contains this language "In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering."  Are these EKUs considered a clarifying update to a PKIX document?

Just two minor non-blocking comments:

1) the mention of the railway use case in the abstract is distracting, suggest removing it

2) the 1st paragraph is section 1 is also distracting and useless. In the same vein, have a subsection about "use case" where the railway use case can then fit nicer without disturbing the natural flow

Note: based on authors/contributors' affiliations, I appreciate that this document comes from the railway use case.