rfc9809v1.txt | rfc9809.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) H. Brockhaus | Internet Engineering Task Force (IETF) H. Brockhaus | |||
Request for Comments: 9809 Siemens | Request for Comments: 9809 Siemens | |||
Category: Standards Track D. Goltzsche | Category: Standards Track D. Goltzsche | |||
ISSN: 2070-1721 Siemens Mobility | ISSN: 2070-1721 Siemens Mobility | |||
June 2025 | June 2025 | |||
X.509 Extended Key Usage (EKU) for Configuration, Updates, and Safety | X.509 Certificate Extended Key Usage (EKU) for Configuration, Updates, | |||
Communication | and Safety-Critical Communication | |||
Abstract | Abstract | |||
RFC 5280 defines the Extended Key Usage (EKU) extension and specifies | RFC 5280 defines the Extended Key Usage (EKU) extension and specifies | |||
several extended key purpose identifiers (KeyPurposeIds) for use with | several extended key purpose identifiers (KeyPurposeIds) for use with | |||
that extension in X.509 certificates. This document defines | that extension in X.509 certificates. This document defines | |||
KeyPurposeIds for general-purpose and trust anchor configuration | KeyPurposeIds for general-purpose and trust anchor configuration | |||
files, for software and firmware update packages, and for safety- | files, for software and firmware update packages, and for safety- | |||
critical communication to be included in the EKU extension of X.509 | critical communication to be included in the EKU extension of X.509 | |||
v3 public key certificates. | v3 public key certificates. | |||
skipping to change at line 55 ¶ | skipping to change at line 55 ¶ | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Revised BSD License text as described in Section 4.e of the | include Revised BSD License text as described in Section 4.e of the | |||
Trust Legal Provisions and are provided without warranty as described | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction | 1. Introduction | |||
2. Conventions and Definitions | 2. Conventions and Definitions | |||
3. Extended Key Purpose for Configuration Files, Update Packages, | 3. Extended Key Purpose for Configuration Files, Update Packages, | |||
and Safety Communication | and Safety-Critical Communication | |||
4. Including the Extended Key Purpose in Certificates | 4. Including the Extended Key Purpose in Certificates | |||
5. Implications for a Certification Authority | 5. Implications for a Certification Authority | |||
6. Security Considerations | 6. Security Considerations | |||
7. Privacy Considerations | 7. Privacy Considerations | |||
8. IANA Considerations | 8. IANA Considerations | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
9.2. Informative References | 9.2. Informative References | |||
Appendix A. ASN.1 Module | Appendix A. ASN.1 Module | |||
Appendix B. Use Cases | Appendix B. Use Cases | |||
skipping to change at line 93 ¶ | skipping to change at line 93 ¶ | |||
* Validating signatures of general-purpose software configuration | * Validating signatures of general-purpose software configuration | |||
files. | files. | |||
* Validating signatures of trust anchor configuration files. | * Validating signatures of trust anchor configuration files. | |||
* Validating signatures of software and firmware update packages. | * Validating signatures of software and firmware update packages. | |||
* Authenticating communication endpoints authorized for safety- | * Authenticating communication endpoints authorized for safety- | |||
critical communication. | critical communication. | |||
If the purpose of an issued certificate is not restricted, i.e., the | If the purpose of an issued certificate is not restricted (i.e., the | |||
type of operations for which a public key contained in the | operations of the public key contained in the certificate can be used | |||
certificate can be used in unintended ways, the risk of cross- | in unintended ways), the risk of cross-application attacks is | |||
application attacks is increased. Failure to ensure adequate | increased. Failure to ensure adequate segregation of duties means | |||
segregation of duties means that an application or system that | that an application or system that generates the public/private keys | |||
generates the public/private keys and applies for a certificate to | and applies for a certificate to the operator Certification Authority | |||
the operator Certification Authority (CA) could obtain a certificate | (CA) could obtain a certificate that can be misused for tasks that | |||
that can be misused for tasks that this application or system is not | this application or system is not entitled to perform. For example, | |||
entitled to perform. For example, management of trust anchors is a | management of trust anchors is a particularly critical task. A | |||
particularly critical task. A device could potentially accept a | device could potentially accept a trust anchor configuration file | |||
trust anchor configuration file signed by a service that uses a | signed by a service that uses a certificate with no EKU or with the | |||
certificate with no EKU or with the KeyPurposeIds id-kp-codeSigning | KeyPurposeIds id-kp-codeSigning (Section 4.2.1.12 of [RFC5280]) or | |||
(Section 4.2.1.12 of [RFC5280]) or id-kp-documentSigning [RFC9336]. | id-kp-documentSigning [RFC9336]. A device should only accept trust | |||
A device should only accept trust anchor configuration files if the | anchor configuration files if the file is verified with a certificate | |||
file is verified with a certificate that has been explicitly issued | that has been explicitly issued for this purpose. | |||
for this purpose. | ||||
The KeyPurposeId id-kp-serverAuth (Section 4.2.1.12 of [RFC5280]) can | The KeyPurposeId id-kp-serverAuth (Section 4.2.1.12 of [RFC5280]) can | |||
be used to identify that the certificate is for a TLS WWW server, and | be used to identify that the certificate is for a TLS WWW server, and | |||
the KeyPurposeId id-kp-clientAuth (Section 4.2.1.12 of [RFC5280]) can | the KeyPurposeId id-kp-clientAuth (Section 4.2.1.12 of [RFC5280]) can | |||
be used to identify that the certificate is for a TLS WWW client. | be used to identify that the certificate is for a TLS WWW client. | |||
However, there are currently no KeyPurposeIds for usage with X.509 | However, there are currently no KeyPurposeIds for usage with X.509 | |||
certificates for safety-critical communication. | certificates for safety-critical communication. | |||
This document addresses the above problems by defining KeyPurposeIds | This document addresses the above problems by defining KeyPurposeIds | |||
for the EKU extension of X.509 public key certificates. These | for the EKU extension of X.509 public key certificates. These | |||
skipping to change at line 153 ¶ | skipping to change at line 152 ¶ | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
This document uses terms defined in [RFC5280]. X.509 certificate | This document uses terms defined in [RFC5280]. X.509 certificate | |||
extensions are defined using ASN.1 [X.680] [X.690]. | extensions are defined using ASN.1 [X.680] [X.690]. | |||
The term "safety-critical communication" refers to communication that | The term "safety-critical communication" refers to communication that | |||
could, under certain conditions, lead to a state in which human life, | could, under certain conditions, lead to a state in which human life, | |||
health, property, or the environment is endangered. For the | health, property, or the environment is endangered. For the | |||
definition of "safety", see [NIST_Glossary] and [ISO.IEC.IEEE_12207]. | definition of "safety", see [NIST.SP.800-160] and | |||
[ISO.IEC.IEEE_12207]. | ||||
3. Extended Key Purpose for Configuration Files, Update Packages, and | 3. Extended Key Purpose for Configuration Files, Update Packages, and | |||
Safety Communication | Safety-Critical Communication | |||
This specification defines the KeyPurposeIds id-kp-configSigning, id- | This specification defines the following KeyPurposeIds: | |||
kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp- | ||||
safetyCommunication. These KeyPurposeIds are used, respectively, for | * id-kp-configSigning: Used for signing general-purpose | |||
signing general-purpose configuration files, signing trust anchor | configuration files. | |||
configuration files, signing software or firmware update packages, | ||||
and authenticating communication peers for safety-critical | * id-kp-trustAnchorConfigSigning: Used for signing trust anchor | |||
communication. As described in Section 4.2.1.12 of [RFC5280], "[i]f | configuration files. | |||
the [extended key usage] extension is present, then the certificate | ||||
MUST only be used for one of the purposes indicated", and "[i]f | * id-kp-updatePackageSigning: Used for signing software or firmware | |||
multiple [key] purposes are indicated the application need not | update packages. | |||
recognize all purposes indicated, as long as the intended purpose is | ||||
present". | * id-kp-safetyCommunication: Used for authenticating communication | |||
peers for safety-critical communication. | ||||
As described in Section 4.2.1.12 of [RFC5280], "[i]f the [extended | ||||
key usage] extension is present, then the certificate MUST only be | ||||
used for one of the purposes 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". | ||||
None of the KeyPurposeIds specified in this document are | None of the KeyPurposeIds specified in this document are | |||
intrinsically mutually exclusive. Instead, the acceptable | intrinsically mutually exclusive. Instead, the acceptable | |||
combinations of those KeyPurposeIds with others specified in this | combinations of those KeyPurposeIds with others specified in this | |||
document and with other KeyPurposeIds specified elsewhere are left to | document and with other KeyPurposeIds specified elsewhere are left to | |||
the technical standards of the respective application and the | the technical standards of the respective application and the | |||
certificate policy of the respective PKI. For example, a technical | certificate policy of the respective PKI. For example, a technical | |||
standard may specify the following: "Different keys and certificates | standard may specify the following: "Different keys and certificates | |||
must be used for safety communication and for trust anchor updates, | must be used for safety-critical communication and for trust anchor | |||
and a relying party must ignore the KeyPurposeId id-kp- | updates, and a relying party must ignore the KeyPurposeId id-kp- | |||
trustAnchorConfigSigning if id-kp-safetyCommunication is one of the | trustAnchorConfigSigning if id-kp-safetyCommunication is one of the | |||
specified key purposes in a certificate." For example, the | specified key purposes in a certificate." For example, the | |||
certificate policy may specify the following: "The id-kp- | certificate policy may specify the following: "The id-kp- | |||
safetyCommunication KeyPuposeId should not be included in an issued | safetyCommunication KeyPuposeId should not be included in an issued | |||
certificate together with the KeyPurposeId id-kp- | certificate together with the KeyPurposeId id-kp- | |||
trustAnchorConfigSigning." Technical standards and certificate | trustAnchorConfigSigning." Technical standards and certificate | |||
policies of different applications may specify other rules. Further | policies of different applications may specify other rules. Further | |||
considerations on prohibiting combinations of KeyPurposeIds is | considerations on prohibiting combinations of KeyPurposeIds is | |||
described in Section 6. | described in Section 6. | |||
skipping to change at line 414 ¶ | skipping to change at line 421 ¶ | |||
[ERJU] Europe's Rail Joint Undertaking, "Shared Cybersecurity | [ERJU] Europe's Rail Joint Undertaking, "Shared Cybersecurity | |||
Services Specification - SP-SEC-ServSpec - V1.0", February | Services Specification - SP-SEC-ServSpec - V1.0", February | |||
2025, <https://rail-research.europa.eu/wp- | 2025, <https://rail-research.europa.eu/wp- | |||
content/uploads/2025/03/ERJU-SP-Cybersecurity- | content/uploads/2025/03/ERJU-SP-Cybersecurity- | |||
Specifications-V1.0.zip>. | Specifications-V1.0.zip>. | |||
[ERJU-web] Europe's Rail Joint Undertaking, "Europe's Rail Joint | [ERJU-web] Europe's Rail Joint Undertaking, "Europe's Rail Joint | |||
Undertaking - System Pillar", | Undertaking - System Pillar", | |||
<https://rail-research.europa.eu/system_pillar/>. | <https://rail-research.europa.eu/system_pillar/>. | |||
[EU-CRA] European Commission, "Proposal for a REGULATION OF THE | [EU-CRA] European Commission, "Regulation (EU) 2024/2847 of the | |||
EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal | European Parliament and of the Council of 23 October 2024 | |||
cybersecurity requirements for products with digital | on horizontal cybersecurity requirements for products with | |||
elements and amending Regulation (EU) 2019/1020", | digital elements and amending Regulations (EU) No 168/2013 | |||
September 2022, <https://digital- | and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber | |||
strategy.ec.europa.eu/en/library/cyber-resilience-act>. | Resilience Act)", November 2024, | |||
<https://eur-lex.europa.eu/eli/reg/2024/2847/oj>. | ||||
[EU-STRATEGY] | [EU-STRATEGY] | |||
European Commission, "The EU's Cybersecurity Strategy for | European Commission, "The EU's Cybersecurity Strategy for | |||
the Digital Decade", December 2020, <https://digital- | the Digital Decade", December 2020, <https://digital- | |||
strategy.ec.europa.eu/en/library/eus-cybersecurity- | strategy.ec.europa.eu/en/library/eus-cybersecurity- | |||
strategy-digital-decade-0>. | strategy-digital-decade-0>. | |||
[NIST_Glossary] | [NIST.SP.800-160] | |||
NIST CSRC, "safety", | Ross, R., Winstead, M., and M. McEvilley, "Engineering | |||
<https://csrc.nist.gov/glossary/term/safety>. | Trustworthy Secure Systems", NIST SP 800-160v1r1, | |||
DOI 10.6028/NIST.SP.800-160v1r1, November 2022, | ||||
<https://doi.org/10.6028/NIST.SP.800-160v1r1>. | ||||
[ISO.IEC.IEEE_12207] | [ISO.IEC.IEEE_12207] | |||
ISO/IEC/IEEE, "Systems and software engineering - Software | ISO/IEC/IEEE, "Systems and software engineering - Software | |||
life cycle processes", ISO/IEC/IEEE 12207:2017, November | life cycle processes", ISO/IEC/IEEE 12207:2017, November | |||
2017, <https://www.iso.org/standard/63712.html>. | 2017, <https://www.iso.org/standard/63712.html>. | |||
[NIS2] European Commission, "Directive (EU) 2022/2555 of the | [NIS2] European Commission, "Directive (EU) 2022/2555 of the | |||
European Parliament and of the Council", December 2024, | European Parliament and of the Council", December 2024, | |||
<https://digital-strategy.ec.europa.eu/en/policies/ | <https://digital-strategy.ec.europa.eu/en/policies/ | |||
nis2-directive>. | nis2-directive>. | |||
skipping to change at line 507 ¶ | skipping to change at line 517 ¶ | |||
Appendix B. Use Cases | Appendix B. Use Cases | |||
These use cases are only for informational purposes. | These use cases are only for informational purposes. | |||
Automation hardware and software products strive to become more safe | Automation hardware and software products strive to become more safe | |||
and secure by fulfilling mandatory, generic system requirements | and secure by fulfilling mandatory, generic system requirements | |||
related to cybersecurity, e.g., driven by federal offices like the | related to cybersecurity, e.g., driven by federal offices like the | |||
European Union Cyber Resilience Act [EU-CRA] governed by the European | European Union Cyber Resilience Act [EU-CRA] governed by the European | |||
Commission and the High Representative of the Union for Foreign | Commission and the High Representative of the Union for Foreign | |||
Affairs and Security Policy. Automation products connected to the | Affairs and Security Policy. Automation products connected to the | |||
Internet would bear the so-called "CE marking" [CE-marking] to | Internet and sold in the EU after 2027 must bear the so-called "CE | |||
indicate they comply. Such regulation was announced in the 2020 EU | marking" [CE-marking] to indicate that they comply with the EU-CRA. | |||
Cybersecurity Strategy [EU-STRATEGY] and complements other | Such regulation was announced in the 2020 EU Cybersecurity Strategy | |||
legislation in this area, like the NIS2 Framework, Directive on | [EU-STRATEGY] and complements other legislation in this area, like | |||
measures for a high common level of cybersecurity across the Union | the directive on measures for a high common level of cybersecurity | |||
for network and information systems (NIS) across the European Union | ||||
[NIS2]. | [NIS2]. | |||
The 2020 EU Cybersecurity Strategy [EU-STRATEGY] suggests | The 2020 EU Cybersecurity Strategy [EU-STRATEGY] suggests | |||
implementing and extending international standards such as "Security | implementing and extending international standards such as | |||
for industrial automation and control systems - Part 4-2: Technical | [IEC.62443-4-2] and [IEC.62443-3-3]. Automation hardware and | |||
security requirements for IACS components" [IEC.62443-4-2] (IACS | software products of diverse vendors that are connected on automation | |||
refers to Industrial Automation and Control System) and "Industrial | networks and the Internet can be used to build common automation | |||
communication networks - Network and system security - Part 3-3: | solutions. Standardized attributes would allow transparency of | |||
System security requirements and security levels" [IEC.62443-3-3]. | security properties and interoperability for vendors in the context | |||
Automation hardware and software products of diverse vendors that are | of software and firmware updates, general-purpose configuration, | |||
connected on automation networks and the Internet can be used to | trust anchor configuration, and safety-critical communication. | |||
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. | ||||
A concrete example for automation is a rail automation system. The | A concrete example for automation is a rail automation system. The | |||
Europe's Rail web page [ERJU-web] states: | Europe's Rail web page [ERJU-web] states: | |||
| The System Pillar brings rail sector representatives under a | | The System Pillar brings rail sector representatives under a | |||
| single coordination body. To achieve this, the System Pillar will | | single coordination body. To achieve this, the System Pillar will | |||
| deliver a unified operational concept and a functional, safe and | | deliver a unified operational concept and a functional, safe and | |||
| secure system architecture, with due consideration of cyber- | | secure system architecture, with due consideration of cyber- | |||
| security aspects, focused on the European railway network to which | | security aspects, focused on the European railway network to which | |||
| Directive 2016/797 applies (i.e. the heavy rail network) as well | | Directive 2016/797 applies (i.e. the heavy rail network) as well | |||
End of changes. 11 change blocks. | ||||
62 lines changed or deleted | 68 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |