Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Should the document title be updated to use "X.509 Certificate"
rather than "X.509" to align with the titles of RFCs 9509 and 9336? Or is
the current okay?
Original:
X.509 Extended Key Usage (EKU) for configuration, updates and
safety-communication
Current:
X.509 Extended Key Usage (EKU) for Configuration, Updates, and Safety
Communication
Perhaps:
X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, and
Safety Communication
-->
2) <!-- [rfced] Please clarify the text following "i.e.,".
Original:
If the purpose of an issued certificate is not restricted, i.e., the
type of operations for which a public key contained in the
certificate can be used in unintended ways, the risk of cross-
application attacks is increased.
Perhaps:
If the purpose of an issued certificate is not restricted (i.e.,
the operations of the public key contained in the
certificate can be used in unintended ways), the risk of cross-
application attacks is increased.
-->
3) <!-- [rfced] May we update this text to be list to improve readability?
Original:
This specification defines the KeyPurposeIds id-kp-configSigning, id-
kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-
safetyCommunication. These KeyPurposeIds are used, respectively,
for: signing general-purpose configuration files or trust anchor
configuration files, signing software or firmware update packages, or
authenticating communication peers for safety-critical communication.
Perhaps:
This specification defines the following KeyPurposeIds:
* id-kp-configSigning: Used for signing general-purpose configuration
files.
* id-kp-trustAnchorConfigSigning: Used for signing trust anchor
configuration files.
* id-kp-updatePackageSigning: Used for signing software or firmware
update packages.
* id-kp-safetyCommunication: Used for authenticating communication peers
for safety-critical communication.
-->
4) <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
5) <!-- [rfced] FYI - The URLs in the reference entries below do not work (go to
blank page). We updated the URLs as follows. Please review.
Original:
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680 , February 2021,
<https://www.itu.int/rec/T-REC.X.680>.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690 , February 2021,
<https://www.itu.int/rec/T-REC.X.690>.
Updated:
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, February 2021,
<https://www.itu.int/rec/T-REC-X.680-202102-I/en>.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
-->
6) <!-- [rfced] The URL in this reference entry directs to a page titled "Cyber
Resilience Act". Should the title of this reference entry be updated
accordingly (see Perhaps 1 below)? Or should the URL be updated to match
a document with that title (see Perhaps 2 below)?
Original:
[EU-CRA] European Commission, "Proposal for a REGULATION OF THE
EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal
cybersecurity requirements for products with digital
elements and amending Regulation (EU) 2019/1020",
September 2022, <https://digital-
strategy.ec.europa.eu/en/library/cyber-resilience-act>.
Perhaps 1 (updated title):
[EU-CRA] European Union, "Cyber Resilience Act",
September 2022, <https://digital-
strategy.ec.europa.eu/en/library/cyber-resilience-act>.
Perhaps 2 (updated URL):
[EU-CRA] European Commission, "Proposal for a REGULATION OF THE
EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal
cybersecurity requirements for products with digital
elements and amending Regulation (EU) 2019/1020",
September 2022,
<https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022PC0454>.
-->
7) <!-- [rfced] The original title for the reference below is "Directive (EU)
2022/2555 of the European Parliament and of the Council", but the URL
directs to the NIST CSRC's glossary entry for the term "safety". Based
off the context from the document, we updated this reference entry title to
"safety" to match the content at the URL.
Original:
[NIST_Glossary]
NIST CSRC, "Directive (EU) 2022/2555 of the European
Parliament and of the Council", n.d.,
<https://csrc.nist.gov/glossary/term/safety>.
Current:
[NIST_Glossary]
NIST CSRC, "safety",
<https://csrc.nist.gov/glossary/term/safety>.
However, please note that NIST provides the following guidance for citing
terms in their glossary (https://csrc.nist.gov/glossary):
Cite the source publication, not this website. As our documents are
published and withdrawn, the terminology on these web pages will
change. When citing terms and definitions, we encourage you to cite
the source publication for the authoritative terminology and to
understand it in its proper context. Many terms on this website have
different definitions, from multiple publications.
Based on this, would you like to cite NIST SP 800-160, which is listed as the
source for the definition of "safety" in the NIST glossary, rather than citing
the
glossary entry? Or is citing the glossary okay in this context?
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf
-->
8) <!-- [rfced] FYI - We updated the date for this reference from "December
2024"
to "November 2017" to match the date at the URL provided.
Original:
[ISO.IEC.IEEE_12207]
ISO/IEC/IEEE, "Systems and software engineering - Software
life cycle processes", December 2024,
<https://www.iso.org/standard/63712.html>.
Current:
[ISO.IEC.IEEE_12207]
ISO/IEC/IEEE, "Systems and software engineering - Software
life cycle processes", ISO/IEC/IEEE 12207:2017, November
2017, <https://www.iso.org/standard/63712.html>.
-->
9) <!-- [rfced] Please review "would bear" here. Should this be updated to
"bear"
or "should bear"?
Original:
Automation products connected to the
Internet would bear the so-called CE marking [CE-marking] to indicate
they comply.
Perhaps:
Automation products connected to the
Internet bear the so-called "CE marking" [CE-marking] to indicate
they comply.
Or:
Automation products connected to the
Internet should bear the so-called "CE marking" [CE-marking] to indicate
they comply.
-->
10) <!-- [rfced] How may we clarify "NIS2 Framework, Directive" here?
Original:
Such regulation was announced in the 2020 EU
Cybersecurity Strategy [EU-STRATEGY], and complements other
legislation in this area, like the NIS2 Framework, Directive on
measures for a high common level of cybersecurity across the Union
[NIS2].
Perhaps:
Such regulation was announced in the 2020 EU
Cybersecurity Strategy [EU-STRATEGY] and complements other
legislation in this area, like the NIS2 Directive on
measures for a high common level of cybersecurity across the European Union
[NIS2].
-->
11) <!-- [rfced] Would you like to remove the titles of [IEC.62443-4-2] and
[IEC.62443-3-3] in this sentence to improve readability? Note that the
titles appear in the reference entries.
Original:
2020 EU Cybersecurity Strategy [EU-STRATEGY] suggests to implement
and extend international standards such as the Security for
industrial automation and control systems - Part 4-2: Technical
security requirements for IACS components [IEC.62443-4-2] (IACS
refers to industrial automation and control system) and the
Industrial communication networks - Network and system security -
Part 3-3: System security requirements and security levels
[IEC.62443-3-3].
Perhaps:
The 2020 EU Cybersecurity Strategy [EU-STRATEGY] suggests implementing
and extending international standards such as
[IEC.62443-4-2] and [IEC.62443-3-3].
-->
12) <!-- [rfced] The citations [ERJU] and [Directive-2016_797] do not appear in
the direct quote. We have moved these to appear after the direct
quote as shown below. Please review and let us know any concerns.
Original:
A concrete example for automation is a Rail Automation system. The
Europe's Rail web page [ERJU-web] states: "The System Pillar [ERJU]
brings rail sector representatives under a single coordination body.
To achieve this, the System Pillar will deliver a unified operational
concept and a functional, safe and secure system architecture, with
due consideration of cyber-security aspects, focused on the European
railway network to which Directive 2016/797 [Directive-2016_797]
applies (i.e. the heavy rail network) as well as associated
specifications and/or standards."
Perhaps:
A concrete example for automation is a rail automation system. The
Europe's Rail web page [ERJU-web] states:
| The System Pillar brings rail sector representatives under
| a single coordination body. To achieve this, the System Pillar
| will deliver a unified operational concept and a functional, safe
| and secure system architecture, with due consideration of cyber-
| security aspects, focused on the European railway network to which
| Directive 2016/797 applies (i.e. the heavy
| rail network) as well as associated specifications and/or
| standards.
See [Directive-2016_797]. For details about the System Pillar, see [ERJU].
-->
13) <!-- [rfced] We updated two instances of <artwork> to <sourcecode> in
Section 4. Should the "type" attribute be set to "asn.1" for these? Note that
it is also acceptable to leave the "type" attribute not set.
The current list of preferred values for "type" is available here:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. If the list
does not contain an applicable type, then feel free to suggest a new one.
-->
14) <!-- [rfced] We see the following forms in the document. Should these be
uniform? If so, please let us know which form is preferred.
safety communication
safety-critical communication
KeyUsage extension
Key Usage (KU) extension
-->
15) <!-- [rfced] Abbreviations
a) We updated the expansion for "KeyPurposeIds" as follows per RFCs 9336 and
9509. Let us know any concerns.
key purpose identifiers (KeyPurposeIds)
b) How should "NIS2" be expanded? We do not see an expansion in [NIS2].
Original:
Such regulation was announced in the 2020 EU
Cybersecurity Strategy [EU-STRATEGY] and complements other
legislation in this area, like the NIS2 Framework, Directive on
measures for a high common level of cybersecurity across the Union
[NIS2].
-->
16) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor/rv
On Jun 26, 2025, at 2:16 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/06/26
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9809.xml
https://www.rfc-editor.org/authors/rfc9809.html
https://www.rfc-editor.org/authors/rfc9809.pdf
https://www.rfc-editor.org/authors/rfc9809.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9809-diff.html
https://www.rfc-editor.org/authors/rfc9809-rfcdiff.html (side by side)
Alt-diff of the text (allows you to more easily view changes
where text has been deleted or moved):
https://www.rfc-editor.org/authors/rfc9809-alt-diff.html
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9809-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9809
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9809 (draft-ietf-lamps-automation-keyusages-08)
Title : X.509 Extended Key Usage (EKU) for configuration, updates
and safety-communication
Author(s) : H. Brockhaus, D. Goltzsche
WG Chair(s) : Russ Housley, Tim Hollebeek
Area Director(s) : Deb Cooley, Paul Wouters
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
