rfc9809.original.xml   rfc9809.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2. -ietf-lamps-automation-keyusages-08" number="9809" updates="" obsoletes="" categ
3) --> ory="std" consensus="true" submissionType="IETF" xml:lang="en" tocDepth="3" tocI
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft nclude="true" sortRefs="false" symRefs="true" version="3">
-ietf-lamps-automation-keyusages-08" category="std" consensus="true" submissionT
ype="IETF" xml:lang="en" tocDepth="3" tocInclude="true" sortRefs="false" symRefs
="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title abbrev="EKU for config, update, and safety">X.509 Extended Key Usage <!-- [rfced] Should the document title be updated to use "X.509 Certificate"
(EKU) for configuration, updates and safety-communication</title> rather than "X.509" to align with the titles of RFCs 9509 and 9336? Or is
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-automation-keyusag the current okay?
es-08"/>
Original:
X.509 Extended Key Usage (EKU) for configuration, updates and safety-communica
tion
Current:
X.509 Extended Key Usage (EKU) for Configuration, Updates, and Safety Communic
ation
Perhaps:
X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, and Saf
ety Communication
-->
<title abbrev="EKU for Configuration, Updates, and Safety">X.509 Extended Ke
y Usage (EKU) for Configuration, Updates, and Safety Communication</title>
<seriesInfo name="RFC" value="9809"/>
<author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus"> <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
<organization abbrev="Siemens">Siemens</organization> <organization abbrev="Siemens">Siemens</organization>
<address> <address>
<postal> <postal>
<street>Werner-von-Siemens-Strasse 1</street> <street>Werner-von-Siemens-Strasse 1</street>
<city>Munich</city> <city>Munich</city>
<code>80333</code> <code>80333</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>hendrik.brockhaus@siemens.com</email> <email>hendrik.brockhaus@siemens.com</email>
skipping to change at line 41 skipping to change at line 54
<postal> <postal>
<street>Ackerstrasse 22</street> <street>Ackerstrasse 22</street>
<city>Braunschweig</city> <city>Braunschweig</city>
<code>38126</code> <code>38126</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>david.goltzsche@siemens.com</email> <email>david.goltzsche@siemens.com</email>
<uri>https://www.mobility.siemens.com</uri> <uri>https://www.mobility.siemens.com</uri>
</address> </address>
</author> </author>
<date year="2025"/> <date year="2025" month="June"/>
<area>sec</area>
<workgroup>LAMPS Working Group</workgroup> <area>SEC</area>
<workgroup>lamps</workgroup>
<keyword>Industrial Automation</keyword> <keyword>Industrial Automation</keyword>
<keyword>ERJU</keyword> <keyword>ERJU</keyword>
<keyword>extended key usage</keyword> <keyword>extended key usage</keyword>
<keyword>extension</keyword> <keyword>extension</keyword>
<keyword>PKI</keyword> <keyword>PKI</keyword>
<abstract> <abstract>
<?line 179?>
<t>RFC 5280 defines the Extended Key Usage (EKU) extension and several extended key purposes (KeyPurposeIds) for use with that extension in X.509 certificates. This document defines KeyPurposeIds for general-purpose and trust anchor config uration files, for software and firmware update packages, and for safety-critica l communication to be included in the EKU extension of X.509 v3 public key certi ficates.</t> <t>RFC 5280 defines the Extended Key Usage (EKU) extension and specifies several extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates. This document defines KeyPurposeIds for general-purpose an d trust anchor configuration files, for software and firmware update packages, a nd for safety-critical communication to be included in the EKU extension of X.50 9 v3 public key certificates.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 184?>
<section anchor="Intro"> <section anchor="Intro">
<name>Introduction</name> <name>Introduction</name>
<t>Key purposes (KeyPurposeIds) added to the certificate's extended key us age extension as defined in <xref target="RFC5280"/> are meant to express intent as to the purpose of the named usage, for humans and for complying 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 an yExtendedKeyUsage KeyPurposeId, as defined in <xref section="4.2.1.12" sectionFo rmat="of" target="RFC5280"/>, is generally considered a poor practice.</t> <t>Key purpose identifiers (KeyPurposeIds) added to the certificate's EKU extension <xref target="RFC5280"/> are meant to express intent as to the purpose of the named usage, for humans and complying libraries. A full list of KeyPurpo seIds is maintained in the IANA registry "SMI Security for PKIX Extended Key Pur pose" <xref target="SMI-PKIX-PURPOSE"/>. The use of the anyExtendedKeyUsage KeyP urposeId, as defined in <xref section="4.2.1.12" sectionFormat="of" target="RFC5 280"/>, is generally considered a poor practice.</t>
<t>This document defines KeyPurposeIds for certificates that are used for the following purposes, among others:</t> <t>This document defines KeyPurposeIds for certificates that are used for the following purposes, among others:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Validating signatures of general-purpose software configuration fil es.</t> <t>Validating signatures of general-purpose software configuration fil es.</t>
</li> </li>
<li> <li>
<t>Validating signatures of trust anchor configuration files.</t> <t>Validating signatures of trust anchor configuration files.</t>
</li> </li>
<li> <li>
<t>Validating signatures of software and firmware update packages.</t> <t>Validating signatures of software and firmware update packages.</t>
</li> </li>
<li> <li>
<t>Authenticating communication endpoints authorized for safety-critic al communication.</t> <t>Authenticating communication endpoints authorized for safety-critic al communication.</t>
</li> </li>
</ul> </ul>
<t>If the purpose of an issued certificate is not restricted, i.e., the ty <!-- [rfced] Please clarify the text following "i.e.,".
pe 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 Original:
to ensure adequate segregation of duties means that an application or system th If the purpose of an issued certificate is not restricted, i.e., the
at generates the public/private keys and applies for a certificate to the operat type of operations for which a public key contained in the
or Certification Authority (CA) could obtain a certificate that can be misused f certificate can be used in unintended ways, the risk of cross-
or tasks that this application or system is not entitled to perform. For example application attacks is increased.
, management of trust anchors is a particularly critical task. A device could po
tentially accept a trust anchor configuration file signed by a service that uses Perhaps:
a certificate with no Extended Key Usage (EKU) or with the KeyPurposeId id-kp-c If the purpose of an issued certificate is not restricted (i.e.,
odeSigning (<xref section="4.2.1.12" sectionFormat="of" target="RFC5280"/>) or i the operations of the public key contained in the
d-kp-documentSigning <xref target="RFC9336"/>. A device should only accept trust certificate can be used in unintended ways), the risk of cross-
anchor configuration files if the file is verified with a certificate that has application attacks is increased.
been explicitly issued for this purpose.</t> -->
<t>If the purpose of an issued certificate is not restricted, i.e., the ty
pe 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 th
at generates the public/private keys and applies for a certificate to the operat
or Certification Authority (CA) could obtain a certificate that can be misused f
or 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 po
tentially accept a trust anchor configuration file signed by a service that uses
a certificate with no EKU or with the KeyPurposeIds id-kp-codeSigning (<xref se
ction="4.2.1.12" sectionFormat="of" target="RFC5280"/>) or id-kp-documentSigning
<xref target="RFC9336"/>. A device should only accept trust anchor configuratio
n files if the file is verified with a certificate that has been explicitly issu
ed for this purpose.</t>
<t>The KeyPurposeId id-kp-serverAuth (<xref section="4.2.1.12" sectionForm at="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 certif icate is for a TLS WWW client. However, there are currently no KeyPurposeIds for usage with X.509 certificates for safety-critical communication.</t> <t>The KeyPurposeId id-kp-serverAuth (<xref section="4.2.1.12" sectionForm at="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 certif icate 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 defining keyPurposeIds fo r the EKU extension of X.509 public key certificates. These certificates are eit her used for signing files (general-purpose configuration and trust anchor confi guration files, software and firmware update packages) or are used for safety-cr itical communication.</t> <t>This document addresses the above problems by defining KeyPurposeIds fo r the EKU extension of X.509 public key certificates. These certificates are use d either for signing files (general-purpose configuration files, trust anchor co nfiguration files, and software and firmware update packages) or for safety-crit ical communication.</t>
<t>Vendor-defined KeyPurposeIds used within a PKI governed by vendors typi cally do not pose interoperability concerns, as non-critical extensions can be s afely ignored if unrecognized. However, using KeyPurposeIds outside of their int ended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. Therefore, it is advis able not to rely on vendor-defined KeyPurposeIds. Instead, this specification de fines standard KeyPurposeIds to ensure interoperability across various vendors a nd industries.</t> <t>Vendor-defined KeyPurposeIds used within a PKI governed by vendors typi cally do not pose interoperability concerns, as non-critical extensions can be s afely ignored if unrecognized. However, using KeyPurposeIds outside of their int ended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. Therefore, it is advis able not to rely on vendor-defined KeyPurposeIds. Instead, this specification de fines standard KeyPurposeIds to ensure interoperability across various vendors a nd industries.</t>
<t>The definitions of theses KeyPurposeIds are intentionally broad to allo w their use in different deployments even though they were initially motivated b y industrial automation and rail automation, see <xref target="UseCases"/>. The details for each deployment needs to be described in the relevant technical stan dards and certificate policies.</t> <t>The definitions of these KeyPurposeIds are intentionally broad to allow their use in different deployments even though they were initially motivated by industrial automation and rail automation (see <xref target="UseCases"/>). The details for each deployment need to be described in the relevant technical stand ards and certificate policies.</t>
</section> </section>
<section anchor="conventions"> <section anchor="conventions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>This document uses terms defined in <xref target="RFC5280"/>. X.509 certifica <t>This document uses terms defined in <xref target="RFC5280"/>. X.509 certifica
te extensions are defined using ASN.1 <xref target="X.680"/> and <xref target="X te extensions are defined using ASN.1 <xref target="X.680"/> <xref target="X.690
.690"/>.</t> "/>.</t>
<t>The term 'safety-critical communication' refers to communication that c <t>The term "safety-critical communication" refers to communication that c
ould, under certain conditions, lead to a state in which human life, health, pro ould, under certain conditions, lead to a state in which human life, health, pro
perty, or the environment is endangered. For the definition of 'safety' see <xre perty, or the environment is endangered. For the definition of "safety", see <xr
f target="NIST_Glossary"/> and <xref target="ISO.IEC.IEEE_12207"/>.</t> ef target="NIST_Glossary"/> and <xref target="ISO.IEC.IEEE_12207"/>.</t>
</section> </section>
<section anchor="EKU"> <section anchor="EKU">
<name>Extended Key Purpose for configuration files, update packages and sa <name>Extended Key Purpose for Configuration Files, Update Packages, and S
fety-communication</name> afety Communication</name>
<t>This specification defines the KeyPurposeIds id-kp-configSigning, id-kp <!-- [rfced] May we update this text to be list to improve readability?
-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunica
tion. These KeyPurposeIds are used, respectively, for: signing general-purpose c Original:
onfiguration files or trust anchor configuration files, signing software or firm This specification defines the KeyPurposeIds id-kp-configSigning, id-
ware update packages, or authenticating communication peers for safety-critical kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-
communication. As described in <xref section="4.2.1.12" sectionFormat="of" targe safetyCommunication. These KeyPurposeIds are used, respectively,
t="RFC5280"/>, "[i]f the [extended key usage] extension is present, then the cer for: signing general-purpose configuration files or trust anchor
tificate <bcp14>MUST</bcp14> only be used for one of the purposes indicated" and configuration files, signing software or firmware update packages, or
"[i]f multiple [key] purposes are indicated the application need not recognize authenticating communication peers for safety-critical communication.
all purposes indicated, as long as the intended purpose is present".</t>
<t>None of the KeyPurposeIds specified in this document are intrinsically Perhaps:
mutually exclusive. Instead, the acceptable combinations of those KeyPurposeIds This specification defines the following KeyPurposeIds:
with others specified in this document and with other KeyPurposeIds specified e
lsewhere are left to the technical standards of the respective application and t * id-kp-configSigning: Used for signing general-purpose configuration
he certificate policy of the respective PKI. For example, a technical standard files.
may specify: 'Different keys and certificates must be used for safety communicat
ion and for trust anchor updates, and a relying party must ignore the KeyPurpose * id-kp-trustAnchorConfigSigning: Used for signing trust anchor
Id id-kp-trustAnchorConfigSigning if id-kp-safetyCommunication is one of the spe configuration files.
cified key purposes in a certificate.' The certificate policy for example may sp
ecify: 'The id-kp-safetyCommunication KeyPuposeId should not be included in an i * id-kp-updatePackageSigning: Used for signing software or firmware
ssued certificate together with the KeyPurposeId id-kp-trustAnchorConfigSigning. update packages.
' Technical standards and certificate policies of different applications may spe
cify other rules. Further considerations on prohibiting combinations of KeyPurp * id-kp-safetyCommunication: Used for authenticating communication peers
oseIds is described in <xref target="security"/>.</t> for safety-critical communication.
-->
<t>This specification defines the KeyPurposeIds id-kp-configSigning, id-kp-trust
AnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication.
These KeyPurposeIds are used, respectively, for signing general-purpose configur
ation files, signing trust anchor configuration files, signing software or firmw
are update packages, and 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 purposes indicated", and "[i]f multipl
e [key] purposes are indicated the application need not recognize all purposes i
ndicated, 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 e
lsewhere are left to the technical standards of the respective application and t
he certificate policy of the respective PKI. For example, a technical standard
may specify the following: "Different keys and certificates must be used for saf
ety 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 a certificate." For example, the certificat
e policy may specify the following: "The id-kp-safetyCommunication KeyPuposeId s
hould not be included in an issued certificate together with the KeyPurposeId id
-kp-trustAnchorConfigSigning." Technical standards and certificate policies of d
ifferent applications may specify other rules. Further considerations on prohib
iting 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 softwa re 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 kn ows the certificate users are mandated to use these KeyPurposeIds, it <bcp14>MUS T</bcp14> enforce their inclusion. Additionally, such a certificate requester <b cp14>MUST</bcp14> ensure that the KeyUsage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and ke yAgreement for key agreement.</t> <t>Systems or applications that verify the signature of a general-purpose configuration file or trust anchor configuration file, the signature of a softwa re 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 kn ows the certificate users are mandated to use these KeyPurposeIds, it <bcp14>MUS T</bcp14> enforce their inclusion. Additionally, such a certificate requester <b cp14>MUST</bcp14> ensure that the KeyUsage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and ke yAgreement for key agreement.</t>
</section> </section>
<section anchor="include-EKU"> <section anchor="include-EKU">
<name>Including the Extended Key Purpose in Certificates</name> <name>Including the Extended Key Purpose in Certificates</name>
<t><xref target="RFC5280"/> specifies the EKU X.509 certificate extension <t><xref target="RFC5280"/> specifies the EKU X.509 certificate extension
for use on end entity certificates. The extension indicates one or more purposes for use on end-entity certificates. The extension indicates one or more purposes
for which the certified public key is valid. The EKU extension can be used in c for which the certified public key is valid. The EKU extension can be used in c
onjunction with the Key Usage (KU) extension, which indicates the set of basic c onjunction with the Key Usage (KU) extension, which indicates the set of basic c
ryptographic operations for which the certified key may be used. The EKU extensi ryptographic operations for which the certified key may be used. The EKU extensi
on syntax is repeated here for convenience:</t> on syntax is repeated here for convenience:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER 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 inclu sion 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 follow ing usages:</t> <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 inclu sion 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 follow ing usages:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>id-kp-configSigning</t> <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 con figuration files of various formats (e.g., XML, YAML, or JSON). Configuration fi les are used to configure hardware or software.</t> <t>A public key contained in a certificate containing the KeyPurposeId id-kp-configSigning may be used for verifying signatures of general-purpose con figuration files of various formats (e.g., XML, YAML, or JSON). Configuration fi les are used to configure hardware or software.</t>
</li> </li>
</ul>
<ul spacing="normal">
<li> <li>
<t>id-kp-trustAnchorConfigSigning</t> <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 an chor configuration files of various formats (e.g., XML, YAML, or JSON). <t>A public key contained in a certificate containing the KeyPurposeId id-kp-trustAnchorConfigSigning may be used for verifying signatures of trust an chor 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> Trust anchor configuration files are used to add or remove trust anchors to the trust store of a device.</t>
</li> </li>
</ul>
<ul spacing="normal">
<li> <li>
<t>id-kp-updatePackageSigning</t> <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 (includin g bootloader, firmware, safety-related applications, and others) on systems.</t> <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 (includin g bootloader, firmware, safety-related applications, and others) on systems.</t>
</li> </li>
</ul>
<ul spacing="normal">
<li> <li>
<t>id-kp-safetyCommunication</t> <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> <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> </li>
</ul> </ul>
<artwork><![CDATA[ <sourcecode><![CDATA[
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 } security(5) mechanisms(5) pkix(7) 3 }
id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 } id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 }
id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 } id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 }
id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 } id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 }
id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="ca-implication"> <section anchor="ca-implication">
<name>Implications for a Certification Authority</name> <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 extension as well as the KU extensio n are inserted in each certificate that is issued. The inclusion of the id-kp-co nfigSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id- kp-safetyCommunication KeyPurposeIds does not preclude the inclusion of other Ke yPurposeIds.</t> <t>The procedures and practices employed by a certification authority must ensure that the correct values for the EKU extension and the KU extension are i nserted in each certificate that is issued. The inclusion of the id-kp-configSig ning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safe tyCommunication KeyPurposeIds does not preclude the inclusion of other KeyPurpos eIds.</t>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations of <xref target="RFC5280"/> are applicable to this document. These extended key usage key purposes do not introduce new sec urity 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-pur pose or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critic al communication.</t> <t>The security considerations of <xref target="RFC5280"/> are applicable to this document. These EKU 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 a nchor configuration file, the signature of a software or firmware update package , or the authentication of a communication peer for safety-critical communicatio n.</t>
<t>To reduce the risk of specific cross-protocol attacks, the relying part y may additionally prohibit use of specific combinations of KeyPurposeIds. The procedure for allowing or disallowing combinations of KeyPurposeIds using exclud ed KeyPurposeId and permitted KeyPurposeId, as carried out by a relying party, i s defined in <xref section="4" sectionFormat="of" target="RFC9336"/>. The techn ical standards and certificate policies of the application should explicitly enu merate requirements for excluded or permitted KeyPurposeIds or their combination s. It is out of scope of this document to enumerate those, but an example of exc luded KeyPurposeIds can be the presence of the anyExtendedKeyUsage KeyPurposeId. Examples of allowed KeyPurposeIds combinations can be the presence of id-kp-saf etyCommunication together with id-kp-clientAuth or id-kp-serverAuth.</t> <t>To reduce the risk of specific cross-protocol attacks, the relying part y may additionally prohibit use of specific combinations of KeyPurposeIds. The procedure for allowing or disallowing combinations of KeyPurposeIds using exclud ed KeyPurposeId and permitted KeyPurposeId, as carried out by a relying party, i s defined in <xref section="4" sectionFormat="of" target="RFC9336"/>. The techn ical standards and certificate policies of the application should explicitly enu merate requirements for excluded or permitted KeyPurposeIds or their combination s. It is out of scope of this document to enumerate those, but an example of exc luded KeyPurposeIds can be the presence of the anyExtendedKeyUsage KeyPurposeId. Examples of allowed KeyPurposeIds combinations can be the presence of id-kp-saf etyCommunication together with id-kp-clientAuth or id-kp-serverAuth.</t>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>In some protocols, e.g., <xref target="RFC5246">TLS 1.2</xref>, certifi cates are exchanged in the clear. In other protocols, e.g., <xref target="RFC844 6">TLS 1.3</xref>, the certificates are encrypted. The inclusion of the EKU exte nsion can help an observer determine the purpose of the certificate. In addition , if the certificate is issued by a public certification authority, the inclusio n of an EKU extension can help an attacker to monitor the Certificate Transparen cy logs <xref target="RFC9162"/> to identify the purpose of the certificate whic h may reveal private information of the certificate subject.</t> <t>In some protocols (e.g., TLS 1.2 <xref target="RFC5246"></xref>), certi ficates are exchanged in the clear. In other protocols (e.g., TLS 1.3 <xref targ et="RFC8446"></xref>), certificates are encrypted. The inclusion of the EKU exte nsion can help an observer determine the purpose of the certificate. In addition , if the certificate is issued by a public certification authority, the inclusio n of an EKU extension can help an attacker to monitor the Certificate Transparen cy logs <xref target="RFC9162"/> to identify the purpose of the certificate, whi ch may reveal private information of the certificate subject.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register the following ASN.1 <xref target="X.680"/ > module OID in the "SMI Security for PKIX Module Identifier" registry <xref tar get="SMI-PKIX-MOD"/>. This OID is defined in <xref target="asn1"/>.</t> <t>IANA has registered the following ASN.1 <xref target="X.680"/> module O ID in the "SMI Security for PKIX Module Identifier" registry <xref target="SMI-P KIX-MOD"/>. This OID is defined in <xref target="asn1"/>.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD1</td> <td align="left">117</td>
<td align="left">id-mod-config-update-sc-eku</td> <td align="left">id-mod-config-update-sc-eku</td>
<td align="left">This-RFC</td> <td align="left">RFC 9809</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IANA is also requested to register the following OIDs in the "SMI Secur ity for PKIX Extended Key Purpose" registry <xref target="SMI-PKIX-PURPOSE"/>. These OIDs are defined in <xref target="include-EKU"/>.</t> <t>IANA has also registered the following OIDs in the "SMI Security for PK IX Extended Key Purpose" registry <xref target="SMI-PKIX-PURPOSE"/>. These OIDs are defined in <xref target="include-EKU"/>.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">41</td> <td align="left">41</td>
<td align="left">id-kp-configSigning</td> <td align="left">id-kp-configSigning</td>
<td align="left">This-RFC</td> <td align="left">RFC 9809</td>
</tr> </tr>
<tr> <tr>
<td align="left">42</td> <td align="left">42</td>
<td align="left">id-kp-trustAnchorConfigSigning</td> <td align="left">id-kp-trustAnchorConfigSigning</td>
<td align="left">This-RFC</td> <td align="left">RFC 9809</td>
</tr> </tr>
<tr> <tr>
<td align="left">43</td> <td align="left">43</td>
<td align="left">id-kp-updatePackageSigning</td> <td align="left">id-kp-updatePackageSigning</td>
<td align="left">This-RFC</td> <td align="left">RFC 9809</td>
</tr> </tr>
<tr> <tr>
<td align="left">44</td> <td align="left">44</td>
<td align="left">id-kp-safetyCommunication</td> <td align="left">id-kp-safetyCommunication</td>
<td align="left">This-RFC</td> <td align="left">RFC 9809</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="acknow">
<name>Acknowledgments</name>
<t>We would like to thank the authors of <xref target="RFC9336"/> and <xre
f target="RFC9509"/> for their excellent template.</t>
<t>We also thank all reviewers of this document for their valuable feedbac
k.</t>
</section>
</middle> </middle>
<back> <back>
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
le> 280.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="March" year="1997"/> 174.xml"/>
<abstract>
<t>In many standards track documents several words are used to sig <!-- [rfced] FYI - The URLs in the reference entries below do not work (go to
nify the requirements in the specification. These words are often capitalized. T blank page). We updated the URLs as follows. Please review.
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co Original:
mmunity, and requests discussion and suggestions for improvements.</t> [X.680] ITU-T, "Information Technology - Abstract Syntax Notation
</abstract> One (ASN.1): Specification of basic notation", ITU-T
</front> Recommendation X.680 , February 2021,
<seriesInfo name="BCP" value="14"/> <https://www.itu.int/rec/T-REC.X.680>.
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
</reference> Specification of Basic Encoding Rules (BER), Canonical
<reference anchor="RFC5280"> Encoding Rules (CER) and Distinguished Encoding Rules
<front> (DER)", ITU-T Recommendation X.690 , February 2021,
<title>Internet X.509 Public Key Infrastructure Certificate and Cert <https://www.itu.int/rec/T-REC.X.690>.
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/> Updated:
<author fullname="S. Santesson" initials="S." surname="Santesson"/> [X.680] ITU-T, "Information Technology - Abstract Syntax Notation
<author fullname="S. Farrell" initials="S." surname="Farrell"/> One (ASN.1): Specification of basic notation", ITU-T
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/> Recommendation X.680, February 2021,
<author fullname="R. Housley" initials="R." surname="Housley"/> <https://www.itu.int/rec/T-REC-X.680-202102-I/en>.
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/> [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
<abstract> Specification of Basic Encoding Rules (BER), Canonical
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif Encoding Rules (CER) and Distinguished Encoding Rules
icate revocation list (CRL) for use in the Internet. An overview of this approac (DER)", ITU-T Recommendation X.690, February 2021,
h and model is provided as an introduction. The X.509 v3 certificate format is d <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
escribed in detail, with additional information regarding the format and semanti -->
cs of Internet name forms. Standard certificate extensions are described and two <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-20
Internet-specific extensions are defined. A set of required certificate extensi 2102-I/en">
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [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</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the 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>
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC.X.680">
<front> <front>
<title>Information Technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title> <title>Information Technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.680" value=""/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
</reference> </reference>
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC.X.690">
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-20
2102-I/en">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation X.690" value=""/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference> </reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5246"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 246.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
e> 446.xml"/>
<author fullname="T. Dierks" initials="T." surname="Dierks"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> 162.xml"/>
<date month="August" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 336.xml"/>
<t>This document specifies Version 1.2 of the Transport Layer Secu <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
rity (TLS) protocol. The TLS protocol provides communications security over the 509.xml"/>
Internet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery. [STAN
DARDS-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</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9162">
<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 of the Certificate Transpar
ency (CT) protocol for publicly logging the existence of Transport Layer Securit
y (TLS) server certificates as they are issued or observed, in a manner that all
ows anyone to audit certification authority (CA) activity and notice the issuanc
e of suspect certificates as well as to audit the certificate logs themselves. T
he 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 t
he logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS e
xtension that is used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operation
s 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) fo
r 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 (Ke
yPurposeIds) for X.509 certificates. This document defines a general-purpose Doc
ument-Signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extensi
on of X.509 public key certificates. Document-Signing applications may require t
hat the EKU extension be present and that a Document-Signing KeyPurposeId be ind
icated in order for the certificate to be acceptable to that Document-Signing ap
plication.</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 Fun
ctions</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 (Ke
yPurposeIds) for X.509 certificates. This document defines encrypting JSON objec
ts in HTTP messages, using JSON Web Tokens (JWTs), and signing the OAuth 2.0 acc
ess tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension
of X.509 v3 public key certificates used by Network Functions (NFs) for the 5G
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"> <reference anchor="Directive-2016_797" target="https://eur-lex.europa.eu /eli/dir/2016/797/2020-05-28">
<front> <front>
<title>Directive 2016/797 - Interoperability of the rail system with in the EU</title> <title>Directive (EU) 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the Eu ropean Union</title>
<author> <author>
<organization>European Parliament, Council of the European Union</ organization> <organization>European Parliament, Council of the European Union</ organization>
</author> </author>
<date year="2020" month="May"/> <date year="2020" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="ERJU" target="https://rail-research.europa.eu/wp-cont ent/uploads/2025/03/ERJU-SP-Cybersecurity-Specifications-V1.0.zip"> <reference anchor="ERJU" target="https://rail-research.europa.eu/wp-cont ent/uploads/2025/03/ERJU-SP-Cybersecurity-Specifications-V1.0.zip">
<front> <front>
<title>Shared Cybersecurity Services Specification - SP-SEC-ServSpec - V1.0</title> <title>Shared Cybersecurity Services Specification - SP-SEC-ServSpec - V1.0</title>
<author> <author>
<organization>Europe's Rail Joint Undertaking</organization> <organization>Europe's Rail Joint Undertaking</organization>
</author> </author>
<date year="2025" month="February"/> <date year="2025" month="February"/>
</front> </front>
</reference> </reference>
<reference anchor="ERJU-web" target="https://rail-research.europa.eu/sys tem_pillar/"> <reference anchor="ERJU-web" target="https://rail-research.europa.eu/sys tem_pillar/">
<front> <front>
<title>Europe’s Rail Joint Undertaking - System Pillar</title> <title>Europe's Rail Joint Undertaking - System Pillar</title>
<author> <author>
<organization>Europe's Rail Joint Undertaking</organization> <organization>Europe's Rail Joint Undertaking</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </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/?u
ri=CELEX:52022PC0454>.
-->
<reference anchor="EU-CRA" target="https://digital-strategy.ec.europa.eu /en/library/cyber-resilience-act"> <reference anchor="EU-CRA" target="https://digital-strategy.ec.europa.eu /en/library/cyber-resilience-act">
<front> <front>
<title>Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF T HE COUCIL on horizontal cybersecurity requirements for products with digital ele ments and amending Regulation (EU) 2019/1020</title> <title>Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF T HE COUNCIL on horizontal cybersecurity requirements for products with digital el ements and amending Regulation (EU) 2019/1020</title>
<author> <author>
<organization>European Commission</organization> <organization>European Commission</organization>
</author> </author>
<date year="2022" month="September"/> <date year="2022" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="EU-STRATEGY" target="https://digital-strategy.ec.euro pa.eu/en/library/eus-cybersecurity-strategy-digital-decade-0"> <reference anchor="EU-STRATEGY" target="https://digital-strategy.ec.euro pa.eu/en/library/eus-cybersecurity-strategy-digital-decade-0">
<front> <front>
<title>The EU's Cybersecurity Strategy for the Digital Decade</title > <title>The EU's Cybersecurity Strategy for the Digital Decade</title >
<author> <author>
<organization>European Commission</organization> <organization>European Commission</organization>
</author> </author>
<date year="2020" month="December"/> <date year="2020" month="December"/>
</front> </front>
</reference> </reference>
<!-- [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 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"> <reference anchor="NIST_Glossary" target="https://csrc.nist.gov/glossary /term/safety">
<front> <front>
<title>Directive (EU) 2022/2555 of the European Parliament and of th e Council</title> <title>safety</title>
<author> <author>
<organization>NIST CSRC</organization> <organization>NIST CSRC</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </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/stand ard/63712.html"> <reference anchor="ISO.IEC.IEEE_12207" target="https://www.iso.org/stand ard/63712.html">
<front> <front>
<title>Systems and software engineering – Software life cycle proces ses</title> <title>Systems and software engineering - Software life cycle proces ses</title>
<author> <author>
<organization>ISO/IEC/IEEE</organization> <organization>ISO/IEC/IEEE</organization>
</author> </author>
<date year="2024" month="December"/> <date year="2017" month="November"/>
</front> </front>
<seriesInfo name="ISO/IEC/IEEE" value="12207:2017"/>
</reference> </reference>
<reference anchor="NIS2" target="https://digital-strategy.ec.europa.eu/e n/policies/nis2-directive"> <reference anchor="NIS2" target="https://digital-strategy.ec.europa.eu/e n/policies/nis2-directive">
<front> <front>
<title>Directive (EU) 2022/2555 of the European Parliament and of th e Council</title> <title>Directive (EU) 2022/2555 of the European Parliament and of th e Council</title>
<author> <author>
<organization>European Commission</organization> <organization>European Commission</organization>
</author> </author>
<date year="2024" month="December"/> <date year="2024" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="IEC.62443-4-2" target="https://webstore.iec.ch/public ation/34421"> <reference anchor="IEC.62443-4-2" target="https://webstore.iec.ch/public ation/34421">
<front> <front>
<title>Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components</title> <title>Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components</title>
<author> <author>
<organization>IEC</organization> <organization>IEC</organization>
</author> </author>
<date year="2019" month="February"/> <date year="2019" month="February"/>
</front> </front>
<seriesInfo name="IEC 62443-4-2:2019" value=""/> <seriesInfo name="IEC" value="62443-4-2:2019"/>
</reference> </reference>
<reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033"> <reference anchor="IEC.62443-3-3" target="https://webstore.iec.ch/public ation/7033">
<front> <front>
<title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title> <title>Industrial communication networks - Network and system securi ty - Part 3-3: System security requirements and security levels</title>
<author> <author>
<organization>IEC</organization> <organization>IEC</organization>
</author> </author>
<date year="2013" month="August"/> <date year="2013" month="August"/>
</front> </front>
<seriesInfo name="IEC 62443-3-3:2013" value=""/> <seriesInfo name="IEC" value="62443-3-3:2013"/>
</reference> </reference>
<reference anchor="CE-marking" target="https://single-market-economy.ec. europa.eu/single-market/ce-marking_en"> <reference anchor="CE-marking" target="https://single-market-economy.ec. europa.eu/single-market/ce-marking_en">
<front> <front>
<title>CE marking</title> <title>CE marking</title>
<author> <author>
<organization>European Commission</organization> <organization>European Commission</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="SMI-PKIX-PURPOSE" target="https://www.iana.org/assign ments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3"> <reference anchor="SMI-PKIX-PURPOSE" target="https://www.iana.org/assign ments/smi-numbers">
<front> <front>
<title>SMI Security for PKIX Extended Key Purpose</title> <title>SMI Security for PKIX Extended Key Purpose</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="SMI-PKIX-MOD" target="https://www.iana.org/assignment s/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0"> <reference anchor="SMI-PKIX-MOD" target="https://www.iana.org/assignment s/smi-numbers">
<front> <front>
<title>SMI Security for PKIX Module Identifier</title> <title>SMI Security for PKIX Module Identifier</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<?line 331?>
<section anchor="asn1"> <section anchor="asn1">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>The following module adheres to ASN.1 specifications <xref target="X.68 0"/> and <t>The following module adheres to ASN.1 specifications <xref target="X.68 0"/> and
<xref target="X.690"/>.</t> <xref target="X.690"/>.</t>
<sourcecode type="asn1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
<CODE BEGINS> <CODE BEGINS>
Automation-EKU Automation-EKU
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-config-update-sc-eku (TBD1) } id-mod-config-update-sc-eku (117) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- OID Arc -- OID Arc
id-kp OBJECT IDENTIFIER ::= id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) } security(5) mechanisms(5) pkix(7) kp(3) }
skipping to change at line 532 skipping to change at line 570
id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 } id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }
END END
<CODE ENDS> <CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="UseCases"> <section anchor="UseCases">
<name>Use Cases</name> <name>Use Cases</name>
<t>These use cases are only for informational purposes.</t> <t>These use cases are only for informational purposes.</t>
<t>Automation hardware and software products strive to become more safe an <t>Automation hardware and software products strive to become more safe an
d secure by fulfilling mandatory, generic system requirements related to cyber s d secure by fulfilling mandatory, generic system requirements related to cyberse
ecurity, e.g., driven by federal offices like the <xref target="EU-CRA">European curity, e.g., driven by federal offices like the European Union Cyber Resilience
Union Cyber Resilience Act</xref> governed by the European Commission and the H Act <xref target="EU-CRA"></xref> governed by the European Commission and the H
igh Representative of the Union for Foreign Affairs and Security Policy. igh Representative of the Union for Foreign Affairs and Security Policy.
Automation products connected to the Internet would bear the so-called <xref tar
get="CE-marking">CE marking</xref> to indicate they comply. <!-- [rfced] Please review "would bear" here. Should this be updated to "bear"
Such regulation was announced in the <xref target="EU-STRATEGY">2020 EU Cybersec or "should bear"?
urity Strategy</xref>, and complements other legislation in this area, like the
NIS2 Framework, <xref target="NIS2">Directive on measures for a high common leve Original:
l of cybersecurity across the Union</xref>.</t> Automation products connected to the
<t><xref target="EU-STRATEGY">2020 EU Cybersecurity Strategy</xref> sugges Internet would bear the so-called CE marking [CE-marking] to indicate
ts to implement and extend international standards such as the <xref target="IEC they comply.
.62443-4-2">Security for industrial automation and control systems - Part 4-2: T
echnical security requirements for IACS components</xref> (IACS refers to indust Perhaps:
rial automation and control system) and the <xref target="IEC.62443-3-3">Industr Automation products connected to the
ial communication networks - Network and system security - Part 3-3: System secu Internet bear the so-called "CE marking" [CE-marking] to indicate
rity requirements and security levels</xref>. Automation hardware and software p they comply.
roducts of diverse vendors that are connected on automation networks and the Int
ernet can be used to build common automation solutions. Standardized attributes Or:
would allow transparency of security properties and interoperability for vendors Automation products connected to the
in context of software and firmware updates, general-purpose configuration, tru Internet should bear the so-called "CE marking" [CE-marking] to indicate
st anchor configuration, and safety communication.</t> they comply.
<t>A concrete example for automation is a Rail Automation system. The <xre -->
f target="ERJU-web">Europe's Rail web page</xref> states: "The <xref target="ERJ <!-- [rfced] How may we clarify "NIS2 Framework, Directive" here?
U">System Pillar</xref> brings rail sector representatives under a single coordi
nation body. To achieve this, the System Pillar will deliver a unified operatio Original:
nal concept and a functional, safe and secure system architecture, with due cons Such regulation was announced in the 2020 EU
ideration of cyber-security aspects, focused on the European railway network to Cybersecurity Strategy [EU-STRATEGY], and complements other
which <xref target="Directive-2016_797">Directive 2016/797</xref> applies (i.e. legislation in this area, like the NIS2 Framework, Directive on
the heavy rail network) as well as associated specifications and/or standards."< measures for a high common level of cybersecurity across the Union
/t> [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" <xref target="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 a
cross the Union <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 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].
-->
<t>The 2020 EU Cybersecurity Strategy <xref target="EU-STRATEGY"></xref> suggest
s implementing and extending international standards such as "Security for indus
trial automation and control systems - Part 4-2: Technical security requirements
for IACS components" <xref target="IEC.62443-4-2"></xref> (IACS refers to Indus
trial Automation and Control System) and "Industrial communication networks - Ne
twork and system security - Part 3-3: System security requirements and security
levels" <xref target="IEC.62443-3-3"></xref>. Automation hardware and software p
roducts of diverse vendors that are connected on automation networks and the Int
ernet 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>
<!-- [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].
-->
<t>A concrete example for automation is a rail automation system. The Europe's R
ail 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, the System Pillar will deliver a unified op
erational concept and a functional, safe and secure system architecture, with du
e consideration of cyber-security aspects, focused on the European railway netwo
rk to which Directive 2016/797 applies (i.e. the heavy rail network) as well as
associated specifications and/or standards.</blockquote>
<t>See <xref target="Directive-2016_797"/>. For details about the System Pillar,
see <xref target="ERJU"/>.</t>
</section> </section>
<section anchor="history"> <section anchor="acknow" numbered="false">
<name>History of Changes</name> <name>Acknowledgments</name>
<t>[RFC Editor: Please remove this appendix in the release version of the <t>We would like to thank the authors of <xref target="RFC9336"/> and <xre
document.]</t> f target="RFC9509"/> for their excellent template.</t>
<t>Changes from 07 -&gt; 08:</t> <t>We also thank all reviewers of this document for their valuable feedbac
<ul spacing="normal"> k.</t>
<li>
<t>Updated Appendix B</t>
</li>
</ul>
<t>Changes from 06 -&gt; 07:</t>
<ul spacing="normal">
<li>
<t>Moved Section 1.1 to the Appendix</t>
</li>
<li>
<t>Addressed DISCUSS items from Mohamed Boucadair and Paul Wouters</t>
</li>
<li>
<t>Addressed AD review comments from Paul Wouters and Orie Steele</t>
</li>
<li>
<t>Fixed some minor issues</t>
</li>
<li>
<t>Updated reference of EU Rail specification to V1.0</t>
</li>
</ul>
<t>Changes from 05 -&gt; 06:</t>
<ul spacing="normal">
<li>
<t>Addressed AD review comments from Mike Bishop, Gorry Fairhurst, And
y Newton, Mohamed Boucadair, Erik Kline, and Eric Vyncke</t>
</li>
</ul>
<t>Changes from 04 -&gt; 05:</t>
<ul spacing="normal">
<li>
<t>Addressed SECDIR review comments from Carl Wallace</t>
</li>
</ul>
<t>Changes from 03 -&gt; 04:</t>
<ul spacing="normal">
<li>
<t>Addressed Deb's AD review comments (see "AD Comments on draft-ietf-
lamps-automation-keyusages")</t>
</li>
<li>
<t>Added early allocated OIDs</t>
</li>
</ul>
<t>Changes from 02 -&gt; 03:</t>
<ul spacing="normal">
<li>
<t>Rename id-kp-trustanchorSigning to id-kp-trustAnchorConfigSigning</
t>
</li>
<li>
<t>Rename id-kp-updateSigning to id-kp-updatePackageSigning</t>
</li>
<li>
<t>Fixed some nits</t>
</li>
</ul>
<t>Changes from 01 -&gt; 02:</t>
<ul spacing="normal">
<li>
<t>Updates Sections 3 and 6 addressing last call comments (see "WG Las
t Call for draft-ietf-lamps-automation-keyusages-01")</t>
</li>
</ul>
<t>Changes from 01 -&gt; 02:</t>
<ul spacing="normal">
<li>
<t>Implemented the changes requested during WGLC</t>
</li>
</ul>
<t>Changes from 00 -&gt; 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 -&gt; 01:</t>
<ul spacing="normal">
<li>
<t>Updated last paragraph of Section 1 addressing WG adoption comments
by Rich and Russ</t>
</li>
<li>
<t>Updated name and OID of ASN.1 module</t>
</li>
</ul>
<t>draft-brockhaus-lamps-automation-keyusages version 00:</t>
<ul spacing="normal">
<li>
<t>Broadened the scope to general automation use case and use ERJU as
an 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 of the document following best practices from RFC 9
336 and RFC 9509</t>
</li>
</ul>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false">
<name>Contributors</name> <name>Contributors</name>
<contact initials="S." surname="Fazekas-Zisch" fullname="Szofia Fazekas-Zi sch"> <contact initials="S." surname="Fazekas-Zisch" fullname="Szofia Fazekas-Zi sch">
<organization abbrev="Siemens">Siemens AG</organization> <organization abbrev="Siemens">Siemens AG</organization>
<address> <address>
<postal> <postal>
<street>Breslauer Str. 5</street> <street>Breslauer Str. 5</street>
<city>Fuerth</city> <city>Fuerth</city>
<code>90766</code> <code>90766</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
skipping to change at line 688 skipping to change at line 712
</address> </address>
</contact> </contact>
<contact initials="N." surname="Poyet" fullname="Nicolas Poyet"> <contact initials="N." surname="Poyet" fullname="Nicolas Poyet">
<organization>SNCF</organization> <organization>SNCF</organization>
<address> <address>
<email>nicolas.poyet@sncf.fr</email> <email>nicolas.poyet@sncf.fr</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </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> </rfc>
 End of changes. 69 change blocks. 
636 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.48.