<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-automation-keyusages-08" number="9809" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" xml:lang="en" tocDepth="3" tocInclude="true" sortRefs="false" symRefs="true" version="3"> <front> <!--xml2rfc v2v3 conversion 3.28.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 --><front><title abbrev="EKU forconfig, update,Configuration, Updates, andsafety">X.509Safety">X.509 Extended Key Usage (EKU) forconfiguration, updatesConfiguration, Updates, andsafety-communication</title>Safety Communication</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-automation-keyusages-08"/>name="RFC" value="9809"/> <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus"> <organization abbrev="Siemens">Siemens</organization> <address> <postal> <street>Werner-von-Siemens-Strasse 1</street> <city>Munich</city> <code>80333</code> <country>Germany</country> </postal> <email>hendrik.brockhaus@siemens.com</email> <uri>https://www.siemens.com</uri> </address> </author> <author initials="D." surname="Goltzsche" fullname="David Goltzsche"> <organization>Siemens Mobility</organization> <address> <postal> <street>Ackerstrasse 22</street> <city>Braunschweig</city> <code>38126</code> <country>Germany</country> </postal> <email>david.goltzsche@siemens.com</email> <uri>https://www.mobility.siemens.com</uri> </address> </author> <dateyear="2025"/> <area>sec</area> <workgroup>LAMPS Working Group</workgroup>year="2025" month="June"/> <area>SEC</area> <workgroup>lamps</workgroup> <keyword>Industrial Automation</keyword> <keyword>ERJU</keyword> <keyword>extended key usage</keyword> <keyword>extension</keyword> <keyword>PKI</keyword> <abstract><?line 179?><t>RFC 5280 defines the Extended Key Usage (EKU) extension and specifies several extended keypurposespurpose 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 EKU extension of X.509 v3 public key certificates.</t> </abstract> </front> <middle><?line 184?><section anchor="Intro"> <name>Introduction</name> <t>Keypurposespurpose identifiers (KeyPurposeIds) added to the certificate'sextended key usageEKU extensionas defined in<xref target="RFC5280"/> are meant to express intent as to the purpose of the named usage, for humans andforcomplying libraries. A full list of KeyPurposeIds is maintained in the IANA registry "SMI Security for PKIX Extended Key Purpose" <xref target="SMI-PKIX-PURPOSE"/>. The use of the anyExtendedKeyUsage KeyPurposeId, as defined in <xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>, is generally considered a poor practice.</t> <t>This document defines KeyPurposeIds for certificates that are used for the following purposes, among others:</t> <ul spacing="normal"> <li> <t>Validating signatures of general-purpose software configuration files.</t> </li> <li> <t>Validating signatures of trust anchor configuration files.</t> </li> <li> <t>Validating signatures of software and firmware update packages.</t> </li> <li> <t>Authenticating communication endpoints authorized for safety-critical communication.</t> </li> </ul> <!-- [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. --> <t>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. Failure to ensure adequate segregation of duties means that an application or system that generates the public/private keys and applies for a certificate to the operator Certification Authority (CA) could obtain a certificate that can be misused for tasks that this application or system is not entitled to perform. For example, management of trust anchors is a particularly critical task. A device could potentially accept a trust anchor configuration file signed by a service that uses a certificate with noExtended Key Usage (EKU)EKU or with theKeyPurposeIdKeyPurposeIds id-kp-codeSigning (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) or id-kp-documentSigning <xref target="RFC9336"/>. A device should only accept trust anchor configuration files if the file is verified with a certificate that has been explicitly issued for this purpose.</t> <t>The KeyPurposeId id-kp-serverAuth (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) can be used to identify that the certificate is for a TLS WWW server, and the KeyPurposeId id-kp-clientAuth (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) can be used to identify that the certificate is for a TLS WWW client. However, there are currently no KeyPurposeIds for usage with X.509 certificates for safety-critical communication.</t> <t>This document addresses the above problems by definingkeyPurposeIdsKeyPurposeIds for the EKU extension of X.509 public key certificates. These certificates areeitherused either for signing files (general-purpose configurationandfiles, trust anchor configuration files, and software and firmware update packages) orare usedfor safety-critical communication.</t> <t>Vendor-defined KeyPurposeIds used within a PKI governed by vendors typically do not pose interoperability concerns, as non-critical extensions can be safely ignored if unrecognized. However, using KeyPurposeIds outside of their intended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds. Instead, this specification defines standard KeyPurposeIds to ensure interoperability across various vendors and industries.</t> <t>The definitions ofthesesthese KeyPurposeIds are intentionally broad to allow their use in different deployments even though they were initially motivated by industrial automation and railautomation, seeautomation (see <xreftarget="UseCases"/>.target="UseCases"/>). The details for each deploymentneedsneed to be described in the relevant technical standards and certificate policies.</t> </section> <section anchor="conventions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document uses terms defined in <xref target="RFC5280"/>. X.509 certificate extensions are defined using ASN.1 <xref target="X.680"/>and<xref target="X.690"/>.</t> <t>The term'safety-critical communication'"safety-critical communication" refers to communication that could, under certain conditions, lead to a state in which human life, health, property, or the environment is endangered. For the definition of'safety'"safety", see <xref target="NIST_Glossary"/> and <xref target="ISO.IEC.IEEE_12207"/>.</t> </section> <section anchor="EKU"> <name>Extended Key Purpose for Configuration Files, Update Packages, and Safety Communication</name> <!-- [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 updatepackages and safety-communication</name>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. --> <t>This specification defines the KeyPurposeIds id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication. These KeyPurposeIds are used, respectively,for:for signing general-purpose configurationfiles orfiles, signing trust anchor configuration files, signing software or firmware update packages,orand authenticating communication peers for safety-critical communication. As described in <xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>, "[i]f the [extended key usage] extension is present, then the certificate <bcp14>MUST</bcp14> only be used for one of the purposesindicated"indicated", and "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present".</t> <t>None of the KeyPurposeIds specified in this document are intrinsically mutually exclusive. Instead, the acceptable combinations of those KeyPurposeIds with others specified in this document and with other KeyPurposeIds specified elsewhere are left to the technical standards of the respective application and the certificate policy of the respective PKI. For example, a technical standard mayspecify: 'Differentspecify the following: "Different keys and certificates must be used for safety communication and for trust anchor updates, and a relying party must ignore the KeyPurposeId id-kp-trustAnchorConfigSigning if id-kp-safetyCommunication is one of the specified key purposes in acertificate.' Thecertificate." For example, the certificate policyfor examplemayspecify: 'Thespecify the following: "The id-kp-safetyCommunication KeyPuposeId should not be included in an issued certificate together with the KeyPurposeIdid-kp-trustAnchorConfigSigning.'id-kp-trustAnchorConfigSigning." Technical standards and certificate policies of different applications may specify other rules. Further considerations on prohibiting combinations of KeyPurposeIds is described in <xref target="security"/>.</t> <t>Systems or applications that verify the signature of a general-purpose configuration file or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication <bcp14>SHOULD</bcp14> require that corresponding KeyPurposeIds be specified by the EKU extension. If the certificate requester knows the certificate users are mandated to use these KeyPurposeIds, it <bcp14>MUST</bcp14> enforce their inclusion. Additionally, such a certificate requester <bcp14>MUST</bcp14> ensure that the KeyUsage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and keyAgreement for key agreement.</t> </section> <section anchor="include-EKU"> <name>Including the Extended Key Purpose in Certificates</name> <t><xref target="RFC5280"/> specifies the EKU X.509 certificate extension for use onend entityend-entity certificates. The extension indicates one or more purposes for which the certified public key is valid. The EKU extension can be used in conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used. The EKU extension syntax is repeated here for convenience:</t><artwork><![CDATA[<sourcecode><![CDATA[ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER]]></artwork>]]></sourcecode> <t>As described in <xref target="RFC5280"/>, the EKU extension may, at the option of the certificate issuer, be either critical or non-critical. The inclusion of KeyPurposeIds id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication in a certificate indicates that the public key encoded in the certificate has been certified for the following usages:</t> <ul spacing="normal"> <li> <t>id-kp-configSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-configSigning may be used for verifying signatures of general-purpose configuration files of various formats (e.g., XML, YAML, or JSON). Configuration files are used to configure hardware or software.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-trustAnchorConfigSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-trustAnchorConfigSigning may be used for verifying signatures of trust anchor configuration files of various formats (e.g., XML, YAML, or JSON). Trust anchor configuration files are used to add or remove trust anchors to the trust store of a device.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-updatePackageSigning</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-updatePackageSigning may be used for verifying signatures of software or firmware update packages. Update packages are used to install software (including bootloader, firmware, safety-related applications, and others) on systems.</t> </li></ul> <ul spacing="normal"><li> <t>id-kp-safetyCommunication</t></li> </ul> <ul empty="true"> <li><t>A public key contained in a certificate containing the KeyPurposeId id-kp-safetyCommunication may be used to authenticate a communication peer for safety-critical communication based on TLS or other protocols.</t> </li> </ul><artwork><![CDATA[<sourcecode><![CDATA[ id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 } id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 } id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }]]></artwork>]]></sourcecode> </section> <section anchor="ca-implication"> <name>Implications for a Certification Authority</name> <t>The procedures and practices employed by a certification authority must ensure that the correct values for the EKU extensionas well asand the KU extension are inserted in each certificate that is issued. The inclusion of the id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication KeyPurposeIds does not preclude the inclusion of other KeyPurposeIds.</t> </section> <section anchor="security"> <name>Security Considerations</name> <t>TheSecurity Considerationssecurity considerations of <xref target="RFC5280"/> are applicable to this document. Theseextended key usageEKU key purposes do not introduce new security risks but instead reduce existing security risks by providing the means to identify if a certificate is generated to verify the signature of a general-purpose or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication.</t> <t>To reduce the risk of specific cross-protocol attacks, the relying party may additionally prohibit use of specific combinations of KeyPurposeIds. The procedure for allowing or disallowing combinations of KeyPurposeIds using excluded KeyPurposeId and permitted KeyPurposeId, as carried out by a relying party, is defined in <xref section="4" sectionFormat="of" target="RFC9336"/>. The technical standards and certificate policies of the application should explicitly enumerate requirements for excluded or permitted KeyPurposeIds or their combinations. It is out of scope of this document to enumerate those, but an example of excluded KeyPurposeIds can be the presence of the anyExtendedKeyUsage KeyPurposeId. Examples of allowed KeyPurposeIds combinations can be the presence of id-kp-safetyCommunication together with id-kp-clientAuth or id-kp-serverAuth.</t> </section> <section anchor="privacy"> <name>Privacy Considerations</name> <t>In someprotocols, e.g.,protocols (e.g., TLS 1.2 <xreftarget="RFC5246">TLS 1.2</xref>,target="RFC5246"></xref>), certificates are exchanged in the clear. In otherprotocols, e.g.,protocols (e.g., TLS 1.3 <xreftarget="RFC8446">TLS 1.3</xref>, thetarget="RFC8446"></xref>), certificates are encrypted. The inclusion of the EKU extension can help an observer determine the purpose of the certificate. In addition, if the certificate is issued by a public certification authority, the inclusion of an EKU extension can help an attacker to monitor the Certificate Transparency logs <xref target="RFC9162"/> to identify the purpose of thecertificatecertificate, which may reveal private information of the certificate subject.</t> </section> <section anchor="iana"> <name>IANA Considerations</name> <t>IANAis requested to registerhas registered the following ASN.1 <xref target="X.680"/> module OID in the "SMI Security for PKIX Module Identifier" registry <xref target="SMI-PKIX-MOD"/>. This OID is defined in <xref target="asn1"/>.</t> <table> <thead> <tr> <th align="left">Decimal</th> <th align="left">Description</th> <thalign="left">References</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD1</td>align="left">117</td> <td align="left">id-mod-config-update-sc-eku</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> </tbody> </table> <t>IANAishas alsorequested to registerregistered the following OIDs in the "SMI Security for PKIX Extended Key Purpose" registry <xref target="SMI-PKIX-PURPOSE"/>. These OIDs are defined in <xref target="include-EKU"/>.</t> <table> <thead> <tr> <th align="left">Decimal</th> <th align="left">Description</th> <thalign="left">References</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">41</td> <td align="left">id-kp-configSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">42</td> <td align="left">id-kp-trustAnchorConfigSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">43</td> <td align="left">id-kp-updatePackageSigning</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> <tr> <td align="left">44</td> <td align="left">id-kp-safetyCommunication</td> <tdalign="left">This-RFC</td>align="left">RFC 9809</td> </tr> </tbody> </table> </section><section anchor="acknow"> <name>Acknowledgments</name> <t>We would</middle> <back> <!-- [rfced] Would you liketo thanktheauthors of <xref target="RFC9336"/> and <xref target="RFC9509"/> for their excellent template.</t> <t>We also thank all reviewers of this document forreferences to be alphabetized or left in theirvaluable feedback.</t> </section> </middle> <back>current order? --> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC2119"> <front> <title>Key words for use<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <!-- [rfced] FYI - The URLs inRFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signifytherequirements inreference entries below do not work (go to blank page). We updated thespecification. These words are often capitalized. This document defines these wordsURLs asthey should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overviewfollows. Please review. Original: [X.680] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification ofthis approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semanticsbasic 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 ofInternet name forms. Standard certificate extensions are describedBasic Encoding Rules (BER), Canonical Encoding Rules (CER) andtwo Internet-specific extensions are defined. A setDistinguished 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 ofrequired certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. Anbasic 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.1module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usageencoding rules: Specification ofthe key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference>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>. --> <reference anchor="X.680"target="https://www.itu.int/rec/T-REC.X.680">target="https://www.itu.int/rec/T-REC-X.680-202102-I/en"> <front> <title>Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-TRecommendation X.680" value=""/>Recommendation" value="X.680"/> </reference> <reference anchor="X.690"target="https://www.itu.int/rec/T-REC.X.690">target="https://www.itu.int/rec/T-REC-X.690-202102-I/en"> <front> <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-TRecommendation X.690" value=""/>Recommendation" value="X.690"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9162.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9336.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9509.xml"/> <referenceanchor="RFC5246"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <author fullname="T. Dierks" initials="T." surname="Dierks"/> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2008"/> <abstract> <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5246"/> <seriesInfo name="DOI" value="10.17487/RFC5246"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9162">anchor="Directive-2016_797" target="https://eur-lex.europa.eu/eli/dir/2016/797/2020-05-28"> <front><title>Certificate Transparency Version 2.0</title> <author fullname="B. Laurie" initials="B." surname="Laurie"/> <author fullname="E. Messeri" initials="E." surname="Messeri"/> <author fullname="R. Stradling" initials="R." surname="Stradling"/> <date month="December" year="2021"/> <abstract> <t>This document describes version 2.0<title>Directive (EU) 2016/797 of theCertificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activityEuropean Parliament andnotice the issuanceofsuspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t> <t>This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.</t> <t>Logs are network services that implementtheprotocol operations for submissions and queries that are defined in this document.</t> </abstract> </front> <seriesInfo name="RFC" value="9162"/> <seriesInfo name="DOI" value="10.17487/RFC9162"/> </reference> <reference anchor="RFC9336"> <front> <title>X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing</title> <author fullname="T. Ito" initials="T." surname="Ito"/> <author fullname="T. Okubo" initials="T." surname="Okubo"/> <author fullname="S. Turner" initials="S." surname="Turner"/> <date month="December" year="2022"/> <abstract> <t>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application.</t> </abstract> </front> <seriesInfo name="RFC" value="9336"/> <seriesInfo name="DOI" value="10.17487/RFC9336"/> </reference> <reference anchor="RFC9509"> <front> <title>X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions</title> <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/> <author fullname="J. Ekman" initials="J." surname="Ekman"/> <author fullname="D. Migault" initials="D." surname="Migault"/> <date month="March" year="2024"/> <abstract> <t>RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens (JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extensionCouncil ofX.509 v3 public key certificates used by Network Functions (NFs) for11 May 2016 on the5G System.</t> </abstract> </front> <seriesInfo name="RFC" value="9509"/> <seriesInfo name="DOI" value="10.17487/RFC9509"/> </reference> <reference anchor="Directive-2016_797" target="https://eur-lex.europa.eu/eli/dir/2016/797/2020-05-28"> <front> <title>Directive 2016/797 - Interoperabilityinteroperability of the rail system within theEU</title>European Union</title> <author> <organization>European Parliament, Council of the European Union</organization> </author> <date year="2020" month="May"/> </front> </reference> <reference anchor="ERJU" target="https://rail-research.europa.eu/wp-content/uploads/2025/03/ERJU-SP-Cybersecurity-Specifications-V1.0.zip"> <front> <title>Shared Cybersecurity Services Specification - SP-SEC-ServSpec - V1.0</title> <author> <organization>Europe's Rail Joint Undertaking</organization> </author> <date year="2025" month="February"/> </front> </reference> <reference anchor="ERJU-web" target="https://rail-research.europa.eu/system_pillar/"> <front><title>Europe’s<title>Europe's Rail Joint Undertaking - System Pillar</title> <author> <organization>Europe's Rail Joint Undertaking</organization> </author> <date/> </front> </reference> <!-- [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>. --> <reference anchor="EU-CRA" target="https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act"> <front> <title>Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THECOUCILCOUNCIL on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020</title> <author> <organization>European Commission</organization> </author> <date year="2022" month="September"/> </front> </reference> <reference anchor="EU-STRATEGY" target="https://digital-strategy.ec.europa.eu/en/library/eus-cybersecurity-strategy-digital-decade-0"> <front> <title>The EU's Cybersecurity Strategy for the Digital Decade</title> <author> <organization>European Commission</organization> </author> <date year="2020" month="December"/> </front> </reference><reference anchor="NIST_Glossary" target="https://csrc.nist.gov/glossary/term/safety"> <front> <title>Directive<!-- [rfced] The original title for the reference below is "Directive (EU) 2022/2555 of the European Parliament and of theCouncil</title>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 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 the glossary entry? Or is citing the glossary okay here? https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf --> <reference anchor="NIST_Glossary" target="https://csrc.nist.gov/glossary/term/safety"> <front> <title>safety</title> <author> <organization>NIST CSRC</organization> </author><date>n.d.</date></front> </reference> <!-- [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>. --> <reference anchor="ISO.IEC.IEEE_12207" target="https://www.iso.org/standard/63712.html"> <front> <title>Systems and software engineering–- Software life cycle processes</title> <author> <organization>ISO/IEC/IEEE</organization> </author> <dateyear="2024" month="December"/>year="2017" month="November"/> </front> <seriesInfo name="ISO/IEC/IEEE" value="12207:2017"/> </reference> <reference anchor="NIS2" target="https://digital-strategy.ec.europa.eu/en/policies/nis2-directive"> <front> <title>Directive (EU) 2022/2555 of the European Parliament and of the Council</title> <author> <organization>European Commission</organization> </author> <date year="2024" month="December"/> </front> </reference> <reference anchor="IEC.62443-4-2" target="https://webstore.iec.ch/publication/34421"> <front> <title>Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components</title> <author> <organization>IEC</organization> </author> <date year="2019" month="February"/> </front> <seriesInfoname="IEC 62443-4-2:2019" value=""/>name="IEC" value="62443-4-2:2019"/> </reference> <reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/publication/7033"> <front> <title>Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels</title> <author> <organization>IEC</organization> </author> <date year="2013" month="August"/> </front> <seriesInfoname="IEC 62443-3-3:2013" value=""/>name="IEC" value="62443-3-3:2013"/> </reference> <reference anchor="CE-marking" target="https://single-market-economy.ec.europa.eu/single-market/ce-marking_en"> <front> <title>CE marking</title> <author> <organization>European Commission</organization> </author><date>n.d.</date></front> </reference> <reference anchor="SMI-PKIX-PURPOSE"target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3">target="https://www.iana.org/assignments/smi-numbers"> <front> <title>SMI Security for PKIX Extended Key Purpose</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="SMI-PKIX-MOD"target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0">target="https://www.iana.org/assignments/smi-numbers"> <front> <title>SMI Security for PKIX Module Identifier</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> </references> </references><?line 331?><section anchor="asn1"> <name>ASN.1 Module</name> <t>The following module adheres to ASN.1 specifications <xref target="X.680"/> and <xref target="X.690"/>.</t> <sourcecodetype="asn1"><![CDATA[type="asn.1"><![CDATA[ <CODE BEGINS> Automation-EKU { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-config-update-sc-eku(TBD1)(117) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- Extended Key Usage Values id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 } id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 } id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 } END <CODE ENDS> ]]></sourcecode> </section> <section anchor="UseCases"> <name>Use Cases</name> <t>These use cases are only for informational purposes.</t> <t>Automation hardware and software products strive to become more safe and secure by fulfilling mandatory, generic system requirements related tocyber security,cybersecurity, e.g., driven by federal offices like the<xref target="EU-CRA">EuropeanEuropean Union Cyber ResilienceAct</xref>Act <xref target="EU-CRA"></xref> governed by the European Commission and the High Representative of the Union for Foreign Affairs and Security Policy. <!-- [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<xref target="CE-marking">CE marking</xref>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. --> <!-- [rfced] How may we clarify "NIS2 Framework, Directive" here? Original: Such regulation was announced in the<xref target="EU-STRATEGY">20202020 EU CybersecurityStrategy</xref>,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]. --> Automation products connected to the Internet would bear the so-called "CE marking" <xreftarget="NIS2">Directivetarget="CE-marking"></xref> to indicate they comply. Such regulation was announced in the 2020 EU Cybersecurity Strategy <xref target="EU-STRATEGY"></xref> and complements other legislation in this area, like the NIS2 Framework, Directive on measures for a high common level of cybersecurity across theUnion</xref>.</t> <t><xref target="EU-STRATEGY">2020Union <xref target="NIS2"></xref>.</t> <!-- [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 CybersecurityStrategy</xref>Strategy [EU-STRATEGY] suggests to implement and extend international standards such as the<xref target="IEC.62443-4-2">SecuritySecurity for industrial automation and control systems - Part 4-2: Technical security requirements for IACScomponents</xref>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]. --> <t>The 2020 EU Cybersecurity Strategy <xreftarget="IEC.62443-3-3">Industrialtarget="EU-STRATEGY"></xref> suggests implementing and extending international standards such as "Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components" <xref target="IEC.62443-4-2"></xref> (IACS refers to Industrial Automation and Control System) and "Industrial communication networks - Network and system security - Part 3-3: System security requirements and securitylevels</xref>.levels" <xref target="IEC.62443-3-3"></xref>. Automation hardware and software products of diverse vendors that are connected on automation networks and the Internet can be used to build common automation solutions. Standardized attributes would allow transparency of security properties and interoperability for vendors in the context of software and firmware updates, general-purpose configuration, trust anchor configuration, and safety communication.</t><t>A<!-- [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<xref target="ERJU-web">Europe'sEurope's Rail webpage</xref>page [ERJU-web] states: "The<xref target="ERJU">System Pillar</xref>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<xref target="Directive-2016_797">Directive 2016/797</xref>Directive 2016/797 [Directive-2016_797] applies (i.e. the heavy rail network) as well as associated specifications and/orstandards."</t> </section> <section anchor="history"> <name>History of Changes</name> <t>[RFC Editor: Please remove this appendix in the release version of the document.]</t> <t>Changes from 07 -> 08:</t> <ul spacing="normal"> <li> <t>Updated Appendix B</t> </li> </ul> <t>Changes from 06 -> 07:</t> <ul spacing="normal"> <li> <t>Moved Section 1.1 tostandards." 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, theAppendix</t> </li> <li> <t>Addressed DISCUSS items from Mohamed BoucadairSystem Pillar | will deliver a unified operational concept andPaul Wouters</t> </li> <li> <t>Addressed AD review comments from Paul Woutersa functional, safe | andOrie Steele</t> </li> <li> <t>Fixed some minor issues</t> </li> <li> <t>Updated referencesecure system architecture, with due consideration ofEU Rail specification to V1.0</t> </li> </ul> <t>Changes from 05 -> 06:</t> <ul spacing="normal"> <li> <t>Addressed AD review comments from Mike Bishop, Gorry Fairhurst, Andy Newton, Mohamed Boucadair, Erik Kline, and Eric Vyncke</t> </li> </ul> <t>Changes from 04 -> 05:</t> <ul spacing="normal"> <li> <t>Addressed SECDIR review comments from Carl Wallace</t> </li> </ul> <t>Changes from 03 -> 04:</t> <ul spacing="normal"> <li> <t>Addressed Deb's AD review comments (see "AD Commentscyber- | security aspects, focused ondraft-ietf-lamps-automation-keyusages")</t> </li> <li> <t>Added early allocated OIDs</t> </li> </ul> <t>Changes from 02 -> 03:</t> <ul spacing="normal"> <li> <t>Rename id-kp-trustanchorSigning to id-kp-trustAnchorConfigSigning</t> </li> <li> <t>Rename id-kp-updateSigningthe European railway network toid-kp-updatePackageSigning</t> </li> <li> <t>Fixed some nits</t> </li> </ul> <t>Changes from 01 -> 02:</t> <ul spacing="normal"> <li> <t>Updates Sections 3 and 6 addressing last call comments (see "WG Last Callwhich | 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]. --> <t>A concrete example fordraft-ietf-lamps-automation-keyusages-01")</t> </li> </ul> <t>Changes from 01 -> 02:</t> <ul spacing="normal"> <li> <t>Implementedautomation is a rail automation system. The Europe's Rail web page <xref target="ERJU-web"></xref> states: </t> <blockquote>The System Pillar brings rail sector representatives under a single coordination body. To achieve this, thechanges requested during WGLC</t> </li> </ul> <t>Changes from 00 -> 01:</t> <ul spacing="normal"> <li> <t>Fixed some minor nids and wording issues</t> </li> </ul> <t>draft-ietf-lamps-automation-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Updated document and filename after WG adoption</t> </li> </ul> <t>Changes from 00 -> 01:</t> <ul spacing="normal"> <li> <t>Updated last paragraph of Section 1 addressing WG adoption comments by RichSystem Pillar will deliver a unified operational concept andRuss</t> </li> <li> <t>Updated namea functional, safe andOIDsecure system architecture, with due consideration ofASN.1 module</t> </li> </ul> <t>draft-brockhaus-lamps-automation-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Broadenedcyber-security aspects, focused on thescopeEuropean railway network togeneral automation use case and use ERJUwhich Directive 2016/797 applies (i.e. the heavy rail network) asan example.</t> </li> <li> <t>Fixed some nits reported.</t> </li> </ul> <t>draft-brockhaus-lamps-eu-rail-keyusages version 00:</t> <ul spacing="normal"> <li> <t>Initial version ofwell as associated specifications and/or standards.</blockquote> <t>See <xref target="Directive-2016_797"/>. For details about thedocument following best practices from RFC 9336System Pillar, see <xref target="ERJU"/>.</t> </section> <section anchor="acknow" numbered="false"> <name>Acknowledgments</name> <t>We would like to thank the authors of <xref target="RFC9336"/> andRFC 9509</t> </li> </ul><xref target="RFC9509"/> for their excellent template.</t> <t>We also thank all reviewers of this document for their valuable feedback.</t> </section> <section anchor="contributors"numbered="false" toc="include" removeInRFC="false">numbered="false"> <name>Contributors</name> <contact initials="S." surname="Fazekas-Zisch" fullname="Szofia Fazekas-Zisch"> <organization abbrev="Siemens">Siemens AG</organization> <address> <postal> <street>Breslauer Str. 5</street> <city>Fuerth</city> <code>90766</code> <country>Germany</country> </postal> <email>szofia.fazekas-zisch@siemens.com</email> <uri>https://www.siemens.com</uri> </address> </contact> <contact initials="B." surname="Fouques" fullname="Baptiste Fouques"> <organization>Alstom</organization> <address> <email>baptiste.fouques@alstomgroup.com</email> </address> </contact> <contact initials="D. G." surname="Orta" fullname="Daniel Gutierrez Orta"> <organization>CAF Signalling</organization> <address> <email>daniel.gutierrez@cafsignalling.com</email> </address> </contact> <contact initials="M." surname="Weller" fullname="Martin Weller"> <organization>Hitachi Rail</organization> <address> <email>martin.weller@urbanandmainlines.com</email> </address> </contact> <contact initials="N." surname="Poyet" fullname="Nicolas Poyet"> <organization>SNCF</organization> <address> <email>nicolas.poyet@sncf.fr</email> </address> </contact> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA9U823LbRpbvqtI/9MgPlqYIUKQutlWzmVAUZTOxLitKcTKK K9UEmmSPQICDBkTTjqfmH/Zp3/Zb9lPmS/ac0924ERTpJJOpdaoiEOjLOafP vU+34zjbW48n7GB7y4+8kE/FCfNjPkocKZKRE/DpTDk8TaIpT2QUOg9ikSo+ FsrZf7m95fHkhKnEh6coVCJUqTphz5M4Fc+3t1Q6nEqloFeymMGw/d7t+fZW wMPxCRPh9tZMnmxvMZZEXt6Hfvpilkzg3QG9UItpLEaq2EZFcWLejXig8GUi kwDm+N492n/Feh8SEfrCZ9+KBbtDcNlu79u7PTaKYgaQjuQ4jQmfBktnPk+E Yjz0meIjkSwcL5pO01B61GJ7iw+HsQASwQiFAWzPRqEntI0FB4oIb3trDmi+ 7VxcD9i7KH6Q4Zi9jqN0tr0FJJxHsQ/IO6wf+qlKYskD1smIjB96N9/c4V9h UYFejCifvVWm6fW3fVg8AOWEtffbRwBEmkyimMbXC/oGhojlAzuNI+9hwlOF RIxiAHAgxRRGwt8WzcIrgEwIWOF3Ig5F7DzC+puvziCJuVKCtbCdF/kwy/OX +wcHes08mSxO2AUScaIbpGESw6vXIp7ycIHvxJTL4IRNNGzu0ML2tdJTuLAM 2C6NJbRKkpk6aTbn87lb+m5RPOOP0mevoyD5qLyJqCLILqKhDGSyKKLV8R5E rAwi7XYBk4OXrfZxAZPTmKchjDsXcrwGHx8BcccWkLXYTA1gZbSAx4ArhsAS xXUcfIxGkrNz/lE8cOX8RSpN3hKmnddrVvM0FirgqYgZLKLLjgp4v9p/cVzE +xxaJetWUBFU7shA9RGh+mWLeMpniVSJYOdR+rdU5GzaCVSiBzJzDk1Ld6Rb fs2pxRglrMoYoRQBe50mUsSx+Miu4oRnA3c750CicciDACS0tIzYzR3bbl97 fKSyhuUpLnicyBCkJAhEnA39Ribcm0h2A+MVBp5SY3dOjb9O4yEPQYHAtxAG FhWCXEovCrhi19FCJPlKX3bPCyOGupE7w0Zfq9AbuSMAY3srjGJUKI+C9OzN ebfdar2yz0ftl/v2+WXrxSE9f+8em7egiHk8RnYprppMUleGSTMWXvPWuel1 XephOmgV/JX+xUC3jTQAUchuhTcJoyAaL5jDOkMUOi9hg0WY8A/sMkp0q6sQ FHVncOm29k7sKIOZ8OTIKGMWjWDplfRYaProZpnG032ISv3bO+dWv9HK8Tlo x5az336uXyoRS6EkAJn1oy7sRqABALWkp8wwhIdXX0ycV19MHEQf7CNIJNqM OA2EWk2MUyJGz7a+wdZs97R3s9ewfbo8jNCYBUvNutDMtkIjdgYSBZ9TqSZg cKqtz7LW/2JqI8m2t6QlUM6+R+3D44xlD/PnV63jdvZ8cJC/B1+Ans8krAmO 5LT3W8fNF69erFhGkcZOID648DeacfjTFIFs+jJu2o7w0N539o+c9svSwj7P 5mC2KUPznggYScRcK3lcsmQiWAyCC44NKLApm8tkAtoDX/funq+mcA9hEjxk 1zwOJKiHMGmwLqhlD8Yy42Zt7sJMNvLlMHDTHOhfrCACAueAjRA89iYFUsxn DpolmLeZzoKI+wqJcdTcP2jiaM7g2ukuhmBRhQfqHvyoErcq57uWu+9+lLMy 3QYT8Jl8VurJBiJ+lB5wXZnhHQZzDHpdB7/jJ3iDo66l2nNFaph9E4GAAnF8 MGv8wWj8IomOLMcSRnMx/EIa6TX9aSaDgMfNMqYalH/+479XAYP4aZ64pv6/ DVrkIRNKd073psNWYOTLMRiswEHVnIjxwhVeUQzCZiCHMY8XTQ9XCnEHjgY1 JRzQ5GVEr6FXpEDhoLfM2U3v9d3bzm3/6pJdnbPbNz2A5Obqute5ZNedm7f9 zkXv8pZ1Ls/s5+7VXbf/lsGCA97yI/AcjOWVGCQWf0tB4FAIFE0ziyM/9eAH ihMzyDARmCao3lBktEIT4zTQHLXbg6gABPZVswXysYn0dUFb6aimyjttZ/+V 0zp6bmg9uL3p3PZe//Br6S1S5ZSQz7o4dgxfeNwXTtnU7NxqjaKqsmV6E9lQ aZwZYp3RKDu/igb7TqvttLQLedkf3P70OoiUAjRWUMFTseeGYHfAY35sjk3j JmjNadPGVPVa1qxcu91sHx0dLSnAXEnS2pvPRl0+sc4INOsObrr4tj+4cvtg x/u9Xu+nVru9v8pukPlXkQtDNFUCE/LYbx4fvGi13UkyDSoaj2TcRJzRKJmD AgSDPwb3D4wk8Oc///FfbGA/BHIkgPm9QCCPg05UQj0BP4DcBJCbCHJ1cQ5p cQ7t4rR/KWfOokB6YM2bsHBtYEKzJL/zSm3AjUWEcR2P24eHB86hswpz0PcQ RcTClYCyN2nO0mFgbE/z4PCw3aospBUplCSZR/J5uoQwolgusvZegZYHlBOG YGjXj5yz1aqt3+kOYJDpLArx3VOL3+tWSNB6BQbNab94wgvrdVlOF+xRphb8 9wuo9WL/4KBMrEKmo5RfYaFI5lH8gHS51I9aMrQlzMhiqIbgWCtZTzLqbL8E 4lEEX0iyA2f/pbO/EckQGuyBX7o9B2I7tL4r6AWDjANBjUTigNsbRtOKcJWa ND1hR/xJhGVqdnvMfPpyCRlc9J3rb/vfO9d3N9dXg95TOg2CU1JqXGHwSwRu qql0wnSKNqX47H5AVfes8MZpuQfusdtyj+C/F26FIQAMVpIghKmcurtOY3Ak xFPL17ns1Do7GZIXV2e/F4L7myB4AX4K6PK+D1OBZyue8vJWYLe95TgO4yaK xt/bWxDuMAzpmS9GmEfQOnZVHjTLHxppeYQIJSjnGmea9hD4QWezEH1f6Rxq qoR2tJIJTwqjydBkYD3wRLXfLpTL2O1EKuZHXkpq3oJYGpjGHYsQIXHM5ARd EoPegCdvUk3espGEyLRBPTNDil1GMp7SD52iZTPuPWDOWudqqbnJ9MLakPYt q6QkYkMByHhBiuSw0dm3dwVUwU5pVB8PmNZ8RLYS4napptL3A1q4ZxgSalcV B/n0jH5+xk/fPkV07iMgABcCUpgDvLvlDHFxeZWhNmHx6ZNJ/Hz+zJA8U1AO CY4qPszAoVfQJiE7rOxUdiGMVcaslK8n0WSfpFMeqoysaKWCBfow2nuVuPod NkqDAN7AMsI45VUHvsDcV8ItjDgN8j0o9TH0iBdsZ3NNsQMoVtXb588uQ1c4 zdHg4cL2hs5aMIpgNZboNhB6wQ7dNoh7q40jZbRsIBaGdYMF8qiSEIpBX85m EQUnIKcQzxJDbCoLRU7SckYcrYSfee6jKAiiOZLbMg5APo3gdwSfY8wbbW/9 kX3HA4npFXhPKcwkhcVGDKrilglRjZi5a8ZaJ6br+m8kwGaQDuhKVJ+eHqgs vLCsM4yHlVGp8qPYQOZdrUb7oyrbg/kE05nCGIUFwQUPowR4FF0aLxHAMtIV boN643YXdqXED+U+aP75RHoTZImCtogqnF+cw4Oph2bF4TOAGhqOn/OF0lPF Uj3gVF4MkZPDZzPrgTGeJEA0EjBQZLHgMIzLzrkMgOIk86HCJwj5/pbidEqM QeSyzKKPmW9FKsKyHwxamAApqv0w+qp5KTGWR+PYnMXyEccGXE0MjgMIZTID RWyNwtE0g6/d7BtO1tFLCfK/2+3s4W5EAKHCEIlXHQeBMaQDpyeXF64eDCIJ SmA9KmZdkbnAiJPGBYAwEwm0g2biAwcNB8oP1B4wJIlwhfmJ5LDKmOf30gCi G1hny3MIBWpEX2B+y+Axi1DrSlIe3PPEDIZaJ08kPQDgELqgj0rDEXYp2o8y TchUh9FqfwC5U5vzsiJk0nceMO3nC9wlQWHbXaMMaTDdzSo525XMDyZoUSVn NFATvZhhjv06XcKkFlMiBFAb3Bd0pXyNRA0/TECfD4UI0dBh7JrAXEaqtS6F QYzMGx1dSweks4iRFzcgQ1F8gY2kdvgWlgVFVZ9okbh9O2Dv3r1jeirtsKxa Fcy/Jb8LNHoql72J5oLAQvMiyCCBWY7hGxAUGGzZimmHhNZl2TPcUC2XLSa4 QjFlQbQpH0aPlBkZBhhbgziQRUV2e1gC5gkvbpULh66DEmWoKV8jkQS5OVaG xzV/7lYta5mJN3NrN7KIJG4lx2A9Pb8DJRDFjnVwyotG45g9CY6eFhsDhWOj ax6pq0ITh4PDqvsRaUzCUla3OwAvoFyoyKEKozCHKlsCZVkT4UaxHIcRuk4g 4mkYQ5QMdP2IpivjvRSj5ArUUZqgz2UcPBmzzFZqiB2ThEGdLsJHGUeh1t3Y ki05gwXojP4AJiMFQqG5nyt0BD4QXAtVFX1SMZqHYgFrA3ZDJmQe/EepOLAs 0Q66xog6LP3jE0vjQuwARor7Da2wVGlvxDqSNv1YIVBu8Jeg5OQ8sEdw16NU ZUuMXGeTWsbzQrWoxUt7NZraasl95WaaEJsRlwzjSNOIo8dq1igllmG+HI1E rJ3hWRAtdBoH1hpdoigdk1lasLmgUaUxlNMoId+C2HJ18o122vJ3IFVCgCG6 U6ILHpGywYEvwJUItJYQHNy0HBQWCqEJOMR2CpZ+mDtssHDikaKoPJNnVkCT sKhXbeLUOJvPWDcKHzWVdOOzAnE/PfPyr58t+VFBYfWQYjsXd4PbnYb+yy6v 6Pmm9593/ZveGT4P3nTevs0etkyLwZuru7dn+VPes3t1cdG7PNOd4S0rvdra uej8sKMN0s7VNW7ndN7uaDKU1LP2LoeG0SCuxDXiaqtEutPu9f/+T+sQVuIP pi4BQlL9A4sR4MccPHw9G3kG+icywhZ4boKT3AIjgADOMFutVQz4EvOQobS5 W1t/vEfKvD9hfxp6s9bhV+YFIlx6aWlWekk0W36z1FkTseZVzTQZNUvvK5Qu w9v5ofTb0r3w8k9/xroR5rRe/vmrrWVrSd4gbqeUAtp74xm8d5etclH54WLa blrt6vKEeyqKeE/Lc09b9u8zBYGTsedPWqHnIDYg8iRUlcwLee/oEIKex/1M ggy9fBAGX0tGI1O4HGUtISWigytKR9CWSQO4gAfJpIG+ASi7ZNFgxgMo6n8g FZYehGMM17WLn5SUHOo4g8xz0h33pW0tQ4LljaL3mYzX5SmWCxGt0a+Y95Vl iaAewJP5nC14vTGoeo4qc+hxauOXN8xL8kg65JB0675r0K41ZNk3MhPaOyYw uyV3w7hPy+YB3YwGxs8zvUsULCihdJI5Uk97UNrNwtVa70aZATN3ChquThCi N/VUdmEmkG/X+1mso8rGYm0OaefHe/njex3Y/Hi/nNX78X0x0QrxCpYfYA0I QrvkwpOmI805LPiGUZjlwLJUI9hO6uLvaN1uwJimQSIh1AVYAASYPOugrbvp pJ3wQiyN1tLkRozvRmp6eTpS2AEmq7hm1Mxls0ueI7lD0nRZAL/MUYb7rVmu 2iOJxZRAOO2xTtMkpQfxwQtAqz0KlxVdK2HCUPLPYFWHMuQFfyda4meKbnTG 7UlIQr/QdCUGIlBinoVXgRglNjdS52LYgqJMkEqLYaPHJSdkUdMRfH0gRCnL wWvmBBd4YcBd0D6v9d6yJE8pWJqifA6X4pOKWNkEckmcTWm21jGcfGTKdXLQ 5npcHSysCpBXKTSMLVaqLOS6Ap/l61LaFKmmndzn5EbW0HmU07NCOeywGgzC x6BjUiQoVZV9ifrsZBKNBfHYU0mdVdRBVL7Al6VcYcYDBeZTRXQNz1M1IzJZ GtNvmyq38hWitZ7IobSatyR7SzsHFQVrd33BqUd1YessUKUXwSIfg1JGC73E Ng9N6d4NDM8GdqdRN/IGFihzUopGSHshvMYSbbCXZbxRs0VuHawY5T7S5VBl sg6LPD9cLOdMIAwdLSkVHF4AuWP2EEZztfQdpD/WlmOKDJXoLBQGgMmyg0BR MhkwgUWglNjUMT3pa7KuvnYGUY+DiU+9atovB8gMRLFvlu1ajvQJcUG61hTA DLLVswke/UtnGz0TT0J70Ay90JMz4GhS9FSPlueTROjFi5lujVIE7zrjWIis LTbi9k3mN/ZJzHGBlrZyrRcJXN8t6tpPz4xucKxvWNzxs8uqsjV9wvfPtnn1 jorOiNfkxkqbv76Bg/RnDCF6XPAz8i2QAnOQtc8ohalc3B/SI5czdZXdEBC5 v6ahdqiKWs6mtUu73A0zcQ4hSadI8npyWqJoHPMZtKzfuSmDjfCigjMw1YGs dHk7YBULCFmR6cmuG+cfYnsqoKRdur///e+00w/rbHnTVMezk5P/YGwAQWrv sttjg/5femy35boXne/3sGKyKDo4EgxS0va6/9XpN73uLeuf9S5v++f93o2Z cntr2VEtOKXLGVPAGdg4MZs1VjktZ5DBKMUNpI7JlGbqCZAvZgI14TLRrtHz v2vEsmTZS0xj8C4Ld1SoESh2zDYdcqZZ3rjVh+nMRm0NqvjhK9ZZuWlYhtV8 skqjdiun6AgVGJhg01Zx/UZxbTA2ylKIunJfsV3hjt0G+/7ibYP90MH/wxzf DK4u91zWrRkiy2NTXkB/RzrGvjWb1oS6RYKtYoPfmnYr/clNybh2X+vLaIjY 3a4bskhT7vvYOxZT3DQpb1raGINeUl2fdjr0Ll2J3nVi9VvTum6Ojem8Sajv srtqqqVAKYgWEwxbs5F2ZWaOh1GU4PEH1G929Ib1wiBIIUVf9DhNGpMCxD1G hoE80xJRa3TRb03TOnVXJClySO52il/qcQ6x1ADRxN1DTDqQ/gfHPom8KNBY W3NHgNVYJ7JathaOfQJ7Eu229uy2JahSJ4rHPJQfacrdgz0Is/3d4z2ddA5F Aq2z7iyrB9092mNTCG6gp5oq/DV7kB92X+yxA/bZGM86PVn8twwrGthPBpXD Fg6UDbNSZawbpl0aplYaNoHmoDRMHQNsNMwhDmP8BfJNp4V4Sm8Vr6rX+PTM 447M22c7GVTN7pPIonjYGinFxBS3Xmxtg1cal2fjUvxfdespsPES9CJTsWrP F8wynr60aafyN8oWQbCSaBGjvaClcgKsqaGou8Z5SbKo/ndzWcr+kh8JXcQy A1JgMGCSawUYaxJQWdiRFdp1y7H5p2dZeG1XcFVTmKFaaWjUIWbUyNAU8mI2 R1xTx1hKuZiNZmnqJwULxbxQAi6xvGeYJqS6cX8gFtRKfNCnGpeaLpADH2UW YZlKp0JthBxVXUGVlTmRttw8ifD/KGOgN3IiS79ilZndZDDlZlal21qzht0R LabpwL7wQrCeJXhsPWY+5lPZHqohLugMrXSsEw3PvlTZz6fzRnofi3K/fmWL XSsiiOJlklQ+Ubba43GMbnwEbEbKqYRrQ6ek6qpGTarf1j6x2xXZ3KeSbNVE u0kKFiqaRAgCFdvsR+kMSYYupiZqEVSGj2Rcop/L+qTvEGVcLS+amdxoMbVN 1QV2ckqRN0gWeZjlPqFPLc2z+g8KrCjd721cqOtCvEzDE4WIAZaHL3LDirlW 69ZyKnWp8CqrdctLw1ytR6+x9NGrUaMz/YG0aB+WMZqK3DlqMO3u36Pv1HLb 73efmYPPe42aIqQP6MqMC+FnIHiMdSJVp6sy7oEeFw9R7zWqgasZW2etVtq4 5ezMRAQzXPFoqImBRRXIaqGoKyUvJs8RYKskGra4r6J4TZqbxM44xCtcg8ay wQOoVsOrtRfAC1w8jUKZGIVaSK1BmAXGAaQcqLJgQTRWppixddwGC1cuqHsK VZNKQq0Yi0cBwm9LZGXhQoCafiod/hW0SZ4dxBL5Jd7C4yyasfAzJZ50GtTX RUZYUS+qKQi9pf/pE+3pAzZTfULlqn9m2WpFBf7SUZadvGi/UId/cXWmy2wA Hhq0oiW5ClsmZf8zHkKVUyALPmFSalZwUgv/fmY3grYc0GH8GTqeOOZf/lT7 r/QZO7Lb07OWHhIkGXA3fpvxxBzlOeIhxc+IgIPnbBjOWKQyD1S0EakBfbWG qPXHGuroWjjfYFwoGr5Ys0H0LeaEv5DMv4LQdaQ+bNlB1wRZVWL/jAFRqevK wKqm60G568pgqqbrYbnrygCqjjue4QVDYTQPhD/WlvjTM05vSETfgTIgCx7I B+MV8/Ahc+UwJ2Mdae03kHegfx/tY70U8owx2WAJ8EIZqkMDe4hK1cxBvKmH xoQGaB0p5iJWy0Z8lDkAGD6Rrz4Swh8CzEbt4Fkm/GmwI71hlACghmJsQ4Oc 5Y024T6mvsm/1v1KBSuqoH4AS9y3oKoiw68QeTIcfnvrT92rsx477b3uXw6+ oux1fjUZ8DfGur8mWbA+T6B1xO6+6fCUythFzbKn8wpnvfP+ZR+Ltwasf3H9 tt/t37LbzuuBznMQQprCpCI7sUd3oFD0XRub/+sxfZhh/88GqpqjA99RkJ3B uVqaN8mYrJHqTbIla6R7k0zJGinfJEuyvdW7PNPiopkVfiKrmuzJMyAeuBZY ewoyk5WhGrlR+piax22dDVXw6OPlmXvA82oatywCeaq8dLdAdjcGlsg+mvJM D/1O2qFDdPNT0wJdrFEaQEwa6Jwr7tdGMbhVFNSC32XOypSCDJv3xMw9XjeR MZj1PH2cOqTBhU/HTaPRiPI9Wv+B0rgvX1+j760A+2NvGgF9moDjqu8x2SvV pSfFGwXy485ZAcwbOZ7ASKaciG4Vsl6WngtpfA7UAIZhndGIS1MBnRnoayrn cEvkzggLrB8KL8mPaPaNvBkVP8SCVYrvIweLkKDhfX6EG3DKD4/v6fSzb9NN lPTFU5Uw9QD3ueP89pI5RyBDvCohjwHu8RoO1rtbce2HJqC9nGSvYa4owCBK r6SOHAJ0OIJsS0wfmYoFb+TLhVdIsPOYTwUe2ofYIr/yARPLgitK7un04AQX APMMUagP5dOptRKEpg49WxOAFKfYIyb/MqzAXR6PwRnT+RyLG6Gq00xGIVp5 yiNwXUqgobj/91zwALiULqvYY7vUIq+Z3RSUvYz/7/+d1y+UEIL/9ly2uc6i 8qJHXPL88Ik9DJuLnY7/7JAZThb9TBwrx6CGqQx8y5aFAVQUpCb9MTCsQcdI IVSkWxmBrbVgm+MMxegQsyQWf1N7LIU9TlE5eqE3sTRWuqghAf5cdxxWNZ7e kG08kWssXldak/fr0JEdrNnPEjcjXRJrSUOHG+nWqcIaam7RmYL78t1UczFk MzDFKKHmTq09XbatzB1F96VLr0y7PTbEu3CUuSoNVpk2LosKXJkKcc70tRkA egTrFJpdqMhfYGAUMbyFUaDZAx2mcwOlCdkc/kDEFCCXwWBAENqrz2pASGRC fSyTChFHpvCEB40l42nkBq8FkwlAneLeoL6TKhXlerdMAzq5CqRiTLrSwEvN LlrJtCE15nxhORx5WGcU7pfvnwNKLl98t5cdwd3FA8s0+kTwx4UmtBl3r7hJ wpWKPEnWveK0A95NTCdb7enuaBfnjcQNZBKFLiWo0NeZ6Jfk6uD5A9bzMdVy wq4DPJyc7Uqbw7l4V9eH4ikbThogLuagsi2E9zionWoUR1O2/4I5X7H9l6ay Qu/1+qxjBz5d7nFMPV6YHhcADJl/WqoWRCzGtNshzFF0cxrRZ2f9QfduMGCS bAANeRFN6MKE0yj1uA8+BXHKNU8D9i4CLRKr6iCdMxOhMX0rYmJGKvahQa5i CXycCKHvlfgjO5cfcIHIq5Mh2is6fFZGP7axPFIQjClJaPnoAGCJV+otk+eI yHN8sinIF+gnnEo1iWYN9jqKgR/OgQSTNFZJg3VCfwEGZ56gSlqiU4P18L7i b/Foi9ZYPXQ8v1uE3oNYBu2QQDtaAm3Q6571b+rB6/IYKAr6m3s1Ix7QiIdL I56JISi2GpR38WzIDnzo2jd4DGOTi7R39rJJsPqbzoujWdHl9ZjSWQavTeAd GPBuBN7LUUyMaM1vox9KT64rlKkMoy3N0girSj9K/BfKpAbmFsHcLgmksgKm 2AEt87E93kt3iHCFFjsIqmR+95q9xW9d/Ib2acMby1ua1k/B1bfOojna4Jm2 eXbPT+mStnev33Z1mFcebp+Ga52skMpQmm2eOdmqcUFMt7c2QiNTgvv7FeVW OmmAe4q0njAk2DUgGfd1vd56qO2AtADg13Cqi0SdkenD4joVxs5XCoKyG7rv AmC5SVVFEWnIQuJvHFfnhHSuqEiL7FbwLyLIKZ42FaFZQr1nBSxsnKaiN2Oj bYIFf6DvQUYv27lya/kbfZEIqwTcp8AVqUM3hT4Ba1+faF1l2gqZtKHA1cjK JGjh0I5idlCTGX8c7b/a3vo/TBAdX9ZfAAA=[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. --> <!-- [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 --> <!-- [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]. --> <!-- [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. --> </rfc>