Internet Engineering Task Force (IETF) H. Brockhaus
Request for Comments: 9809 Siemens
Category: Standards Track D. Goltzsche
ISSN: 2070-1721 Siemens Mobility
July 2025
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 and trust anchor configuration files, for software and firmware update packages, and for safety-critical communication to be included in the EKU extension of X.509 v3 public key certificates.
RFC 5280は、拡張キー使用量（EKU）拡張機能を定義し、X.509証明書でその拡張機能で使用するためのいくつかの拡張された主要な目的識別子（keypurposeIds）を指定します。このドキュメントでは、汎用および信頼のアンカー構成ファイル、ソフトウェアおよびファームウェアの更新パッケージ、およびX.509 V3公開キー証明書のEKU拡張に含まれる安全性批判的な通信のためのKeypurposeIdsを定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9809.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9809で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Extended Key Purpose for Configuration Files, Update Packages,
and Safety-Critical Communication
4. Including the Extended Key Purpose in Certificates
5. Implications for a Certification Authority
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. ASN.1 Module
Appendix B. Use Cases
Acknowledgments
Contributors
Authors' Addresses
Key purpose identifiers (KeyPurposeIds) added to the certificate's EKU extension [RFC5280] are meant to express intent as to the purpose of the named usage, for humans and complying libraries. A full list of KeyPurposeIds is maintained in the IANA registry "SMI Security for PKIX Extended Key Purpose" [SMI-PKIX-PURPOSE]. The use of the anyExtendedKeyUsage KeyPurposeId, as defined in Section 4.2.1.12 of [RFC5280], is generally considered a poor practice.
証明書のEKU拡張機能[RFC5280]に追加された主要な目的識別子（keypurposeIds）は、人間と図書館を遵守するための、指名された使用法の目的に関して意図を表明することを目的としています。KeypurposeIdsの完全なリストは、IANAレジストリ「PKIXの拡張主要な目的のSMIセキュリティ」[SMI-PKIX-PURPOSE]に維持されています。[RFC5280]のセクション4.2.1.12で定義されているように、ayextededededeyusage keypurposeidの使用は、一般に貧弱な慣行と見なされます。
This document defines KeyPurposeIds for certificates that are used for the following purposes, among others:
このドキュメントでは、次の目的で使用される証明書のkeypurposeIdsを定義します。
* Validating signatures of general-purpose software configuration files.
* 汎用ソフトウェア構成ファイルの署名の検証。
* Validating signatures of trust anchor configuration files.
* トラストアンカー構成ファイルの署名の検証。
* Validating signatures of software and firmware update packages.
* ソフトウェアとファームウェアの更新パッケージの署名の検証。
* Authenticating communication endpoints authorized for safety-critical communication.
* 安全性が批判的なコミュニケーションを認められた通信エンドポイントを認証します。
If the purpose of an issued certificate is not restricted (i.e., the operations of the public key contained in the certificate can be used in unintended ways), the risk of cross-application attacks is increased. Failure to ensure adequate segregation of duties means that an application or system that generates the public/private keys and applies for a certificate to the operator Certification Authority (CA) could obtain a certificate that can be misused for tasks that this application or system is not entitled to perform. For example, management of trust anchors is a particularly critical task. A device could potentially accept a trust anchor configuration file signed by a service that uses a certificate with no EKU or with the KeyPurposeIds id-kp-codeSigning (Section 4.2.1.12 of [RFC5280]) or id-kp-documentSigning [RFC9336]. A device should only accept trust anchor configuration files if the file is verified with a certificate that has been explicitly issued for this purpose.
発行された証明書の目的が制限されていない場合（つまり、証明書に含まれる公開鍵の操作を意図しない方法で使用できます）、クロスアプリケーション攻撃のリスクが増加します。適切な職務の分離を確保できないこととは、パブリック/プライベートキーを生成し、オペレーター認証局（CA）に証明書を申請するアプリケーションまたはシステム（CA）が、このアプリケーションまたはシステムが実行する権利がないタスクに対して誤用できる証明書を取得できることを意味します。たとえば、トラストアンカーの管理は特に重要なタスクです。デバイスは、EKUのない証明書またはkeypurposeIds ID-kp-codeSiging（[RFC5280]のセクション4.2.1.12）またはID-kp-documentived [RFC9336]を使用して証明書を使用するサービスによって署名されたトラストアンカー構成ファイルを潜在的に受け入れることができます。この目的のために明示的に発行された証明書でファイルが検証されている場合のみ、デバイスはトラストアンカー構成ファイルを受け入れる必要があります。
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 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. However, there are currently no KeyPurposeIds for usage with X.509 certificates for safety-critical communication.
keypurposeId id-kp-serverauth（[RFC5280]のセクション4.2.1.12）を使用して、証明書がTLS WWWサーバー用であることを特定できます。ただし、現在、安全性が批判的な通信のためのX.509証明書を使用して使用するためのKeypurposeIdsはありません。
This document addresses the above problems by defining KeyPurposeIds for the EKU extension of X.509 public key certificates. These certificates are used either for signing files (general-purpose configuration files, trust anchor configuration files, and software and firmware update packages) or for safety-critical communication.
このドキュメントは、X.509公開キー証明書のEKU拡張のためのkeypurposeIdsを定義することにより、上記の問題に対処します。これらの証明書は、ファイル（汎用構成ファイル、アンカー構成ファイルの信頼、ソフトウェアおよびファームウェアの更新パッケージ）の署名、または安全性の高い通信のいずれかに使用されます。
Vendor-defined KeyPurposeIds used within a PKI governed by vendors typically do not pose interoperability concerns, as non-critical extensions can be safely ignored if unrecognized. However, using KeyPurposeIds outside of their intended vendor-controlled environment or in ExtendedKeyUsage extensions that have been marked critical can lead to interoperability issues. Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds. Instead, this specification defines standard KeyPurposeIds to ensure interoperability across various vendors and industries.
ベンダーが支配するPKI内で使用されるベンダー定義のキーパイズリドは、通常、非批判的な拡張機能を認識していない場合は安全に無視できるため、相互運用性の懸念をもたらしません。ただし、意図したベンダー制御環境の外側または重要とマークされている拡張キーエージェージ拡張機能の外でキープラーズイドを使用すると、相互運用性の問題につながる可能性があります。したがって、ベンダー定義のkeypurposeidsに依存しないことをお勧めします。代わりに、この仕様では、さまざまなベンダーや産業にわたる相互運用性を確保するために、標準のキーパイズインドを定義します。
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 Appendix B). The details for each deployment need to be described in the relevant technical standards and certificate policies.
これらのキープラーズイドの定義は、産業の自動化と鉄道自動化によって最初に動機付けられていたにもかかわらず、異なる展開での使用を可能にするために意図的に広いです（付録Bを参照）。各展開の詳細は、関連する技術基準と証明書ポリシーで説明する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses terms defined in [RFC5280]. X.509 certificate extensions are defined using ASN.1 [X.680] [X.690].
このドキュメントでは、[RFC5280]で定義された用語を使用します。X.509証明書拡張機能は、asn.1 [x.680] [x.690]を使用して定義されます。
The term "safety-critical communication" refers to communication that could, under certain conditions, lead to a state in which human life, health, property, or the environment is endangered. For the definition of "safety", see [NIST.SP.800-160] and [ISO.IEC.IEEE_12207].
「安全性クリティカルコミュニケーション」という用語は、特定の条件下で、人間の生活、健康、財産、または環境が危険にさらされる状態につながる可能性があるコミュニケーションを指します。「安全」の定義については、[nist.sp.800-160]および[iso.iec.ieee_12207]を参照してください。
This specification defines the following KeyPurposeIds:
この仕様は、次のkeypurposeIdsを定義します。
* id-kp-configSigning: Used for signing general-purpose configuration files.
* ID-KP-ConfigSINGING：汎用構成ファイルの署名に使用されます。
* id-kp-trustAnchorConfigSigning: Used for signing trust anchor configuration files.
* ID-KP-TRUSTANCHORCONFIGSINGING：Trust Anchor構成ファイルの署名に使用されます。
* id-kp-updatePackageSigning: Used for signing software or firmware update packages.
* id-kp-updatePackagesInging：ソフトウェアまたはファームウェアアップデートパッケージの署名に使用されます。
* id-kp-safetyCommunication: Used for authenticating communication peers for safety-critical communication.
* ID-KP-SafetyCommunication：安全性の高いコミュニケーションのための通信ピアの認証に使用されます。
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".
[RFC5280]のセクション4.2.1.12で説明されているように、「[i] f [拡張キー使用]拡張機能が存在する[i] fが存在する場合、証明書は示されている目的のいずれかにのみ使用する必要があります」、および「[i] f複数の[キー]目的は、アプリケーションが示されているすべての目的を認識しない必要はありません」。
None of the KeyPurposeIds specified in this document are intrinsically mutually exclusive. Instead, the acceptable combinations of those KeyPurposeIds with others specified in this document and with other KeyPurposeIds specified elsewhere are left to the technical standards of the respective application and the certificate policy of the respective PKI. For example, a technical standard may specify the following: "Different keys and certificates must be used for safety-critical 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 certificate policy may specify the following: "The id-kp-safetyCommunication KeyPuposeId should not be included in an issued certificate together with the KeyPurposeId id-kp-trustAnchorConfigSigning." Technical standards and certificate policies of different applications may specify other rules. Further considerations on prohibiting combinations of KeyPurposeIds is described in Section 6.
このドキュメントで指定されているキープラーズイドは、本質的に相互に排他的ではありません。代わりに、これらのキープラスイドの許容可能な組み合わせは、このドキュメントで指定された他の人と他の場所で指定された他のキーパスプローズイドと、それぞれのアプリケーションの技術基準とそれぞれのPKIの証明書ポリシーに任されています。たとえば、技術標準では、次のように指定できます。「安全性が批判的なコミュニケーションと信頼のアンカーの更新には、異なるキーと証明書を使用する必要があります。また、ID-KP-SafetyCommunicationが指定された主要な目的の1つである場合、依存者はkeypurposeId ID-KP-TrustanchorConfigsingを無視する必要があります。たとえば、証明書ポリシーは次のことを指定できます。「ID-KP-SafetyCommunication keypuposeIdは、KeypurposeId ID-KP-TrustanchorConfigSIGINGとともに発行された証明書に含めるべきではありません。」さまざまなアプリケーションの技術基準と証明書ポリシーは、他のルールを指定する場合があります。KeypurposeIdsの組み合わせの禁止に関するさらなる考慮事項については、セクション6で説明します。
Systems or applications that verify the signature of a general-purpose configuration file or trust anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication SHOULD require that corresponding KeyPurposeIds be specified by the EKU extension. If the certificate requester knows the certificate users are mandated to use these KeyPurposeIds, it MUST enforce their inclusion. Additionally, such a certificate requester MUST ensure that the Key Usage extension be set to digitalSignature for signature verification, to keyEncipherment for public key encryption, and keyAgreement for key agreement.
汎用構成ファイルまたはトラストアンカー構成ファイルの署名、ソフトウェアまたはファームウェアアップデートパッケージの署名、または安全性批判的な通信のための通信ピアの認証を検証するシステムまたはアプリケーションでは、対応するキープラーズイドがEKU拡張によって指定される必要があります。証明書要求者が証明書ユーザーがこれらのkeypurposeIdsを使用することを義務付けられていることを知っている場合、それらの包含を実施する必要があります。さらに、このような証明書要求者は、キー使用法拡張機能が署名検証のためにデジタル署名に設定され、公開キー暗号化のためのkeyencipherment、およびキー契約のためのキーアグメントに設定されることを確認する必要があります。
[RFC5280] specifies the EKU X.509 certificate extension 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 conjunction with the Key Usage (KU) extension, which indicates the set of basic cryptographic operations for which the certified key may be used. The EKU extension syntax is repeated here for convenience:
[RFC5280]エンドエンティティ証明書で使用するためのEKU X.509証明書延長を指定します。拡張機能は、認定された公開キーが有効である1つ以上の目的を示します。EKU拡張機能は、認定キーを使用する可能性のある基本的な暗号操作のセットを示すキー使用（KU）拡張機能と組み合わせて使用できます。EKU拡張構文は、便利なためにここで繰り返されます。
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
As described in [RFC5280], the EKU extension may, at the option of the certificate issuer, be either critical or non-critical. The inclusion of KeyPurposeIds id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication in a certificate indicates that the public key encoded in the certificate has been certified for the following usages:
[RFC5280]で説明されているように、EKU拡張は、証明書発行者のオプションで、批判的または非批判的である場合があります。keypurposeIds id-kp-configsing、id-kp-trustanchorconfigsing、id-kp-updatepackagesing、およびID-kp-safetycommunicationの包含は、証明書にエンコードされた公開鍵が次の使用について認定されていることを示しています。
* id-kp-configSigning
* id-kp-configsing
A public key contained in a certificate containing the KeyPurposeId id-kp-configSigning may be used for verifying signatures of general-purpose configuration files of various formats (e.g., XML, YAML, or JSON). Configuration files are used to configure hardware or software.
keypurposeId id-kp-configsingを含む証明書に含まれる公開キーは、さまざまな形式の汎用構成ファイル（XML、YAML、またはJSONなど）の署名を検証するために使用できます。構成ファイルは、ハードウェアまたはソフトウェアの構成に使用されます。
* id-kp-trustAnchorConfigSigning
* ID-KP-TrustanchorConfigSINGING
A public key contained in a certificate containing the KeyPurposeId id-kp-trustAnchorConfigSigning may be used for verifying signatures of trust anchor configuration files of various formats (e.g., XML, YAML, or JSON). Trust anchor configuration files are used to add or remove trust anchors to the trust store of a device.
keypurposeId id-kp-trustanchorconfigsingを含む証明書に含まれる公開キーは、さまざまな形式の信頼できるアンカー構成ファイル（XML、YAML、またはJSONなど）の署名を検証するために使用できます。Trust Anchor構成ファイルは、デバイスの信頼ストアにトラストアンカーを追加または削除するために使用されます。
* id-kp-updatePackageSigning
* id-kp-updatePackagesing
A public key contained in a certificate containing the KeyPurposeId id-kp-updatePackageSigning may be used for verifying signatures of software or firmware update packages. Update packages are used to install software (including bootloader, firmware, safety-related applications, and others) on systems.
keypurposeId id-kp-updatepackagesingを含む証明書に含まれる公開キーは、ソフトウェアまたはファームウェアアップデートパッケージの署名を確認するために使用できます。更新パッケージは、システムにソフトウェア（ブートローダー、ファームウェア、安全関連のアプリケーションなど）をインストールするために使用されます。
* id-kp-safetyCommunication
* ID-KP-SafetyCommunication
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.
KeypurposeID ID-KP-SafetyCommunicationを含む証明書に含まれる公開キーを使用して、TLSまたはその他のプロトコルに基づいた安全性が批判的な通信のために通信ピアを認証することができます。
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 }
id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 }
id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 }
id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }
The procedures and practices employed by a certification authority must ensure that the correct values for the EKU extension and the KU extension are inserted in each certificate that is issued. The inclusion of the id-kp-configSigning, id-kp-trustAnchorConfigSigning, id-kp-updatePackageSigning, and id-kp-safetyCommunication KeyPurposeIds does not preclude the inclusion of other KeyPurposeIds.
認証機関が採用している手順と慣行は、EKU拡張機能とKU拡張の正しい値が発行される各証明書に挿入されることを確認する必要があります。ID-KP-ConfigSINGING、ID-KP-TRUSTANCHORCONFIGSINGING、ID-KP-UpDatePackagesInging、およびID-KP-SafetyCommunication KeypurposeIdsを含めることは、他のKeypurposeIdsの包含を排除しません。
The security considerations of [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 anchor configuration file, the signature of a software or firmware update package, or the authentication of a communication peer for safety-critical communication.
[RFC5280]のセキュリティ上の考慮事項は、このドキュメントに適用できます。これらのEKUの主要な目的は、新しいセキュリティリスクを導入するのではなく、代わりに、一般的な目的または信頼できるアンカー構成ファイルの署名、ソフトウェアまたはファームウェアアップデートパッケージの署名、または安全性の高いコミュニケーションのための通信ピアの認証を検証するために証明書を生成するかどうかを特定する手段を提供することにより、既存のセキュリティリスクを減らします。
To reduce the risk of specific cross-protocol attacks, the relying party may additionally prohibit use of specific combinations of KeyPurposeIds. The procedure for allowing or disallowing combinations of KeyPurposeIds using excluded KeyPurposeId and permitted KeyPurposeId, as carried out by a relying party, is defined in Section 4 of [RFC9336]. The technical standards and certificate policies of the application should explicitly enumerate requirements for excluded or permitted KeyPurposeIds or their combinations. It is out of scope of this document to enumerate those, but an example of excluded KeyPurposeIds can be the presence of the anyExtendedKeyUsage KeyPurposeId. Examples of allowed KeyPurposeIds combinations can be the presence of id-kp-safetyCommunication together with id-kp-clientAuth or id-kp-serverAuth.
特定のクロスプロトコル攻撃のリスクを減らすために、依存している当事者は、キープラーズイドの特定の組み合わせの使用をさらに禁止する可能性があります。依存している当事者によって実行されるように、除外されたkeypurposeIdおよび許可されたkeypurposeidを使用して、キープラスイドの組み合わせを許可または禁止する手順は、[RFC9336]のセクション4で定義されています。アプリケーションの技術標準と証明書ポリシーは、除外または許可されたキーパスリスイドまたはその組み合わせの要件を明示的に列挙する必要があります。これらを列挙することはこのドキュメントの範囲外ですが、除外されたkeypurposeidsの例は、ayextededededeyusage keypurposeidの存在です。許可されたKeypurposeIdsの組み合わせの例は、ID-KP-ClientauthまたはID-KP-ServerauthとともにID-KP-Safetycommunicationの存在です。
In some protocols (e.g., TLS 1.2 [RFC5246]), certificates are exchanged in the clear. In other protocols (e.g., TLS 1.3 [RFC8446]), certificates are encrypted. The inclusion of the EKU extension can help an observer determine the purpose of the certificate. In addition, if the certificate is issued by a public certification authority, the inclusion of an EKU extension can help an attacker to monitor the Certificate Transparency logs [RFC9162] to identify the purpose of the certificate, which may reveal private information of the certificate subject.
一部のプロトコル（例：TLS 1.2 [RFC5246]）では、証明書は明確に交換されます。他のプロトコル（TLS 1.3 [RFC8446]など）では、証明書が暗号化されます。EKU拡張機能を含めると、オブザーバーが証明書の目的を決定するのに役立ちます。さらに、証明書が公的認証機関によって発行された場合、EKU拡張機能を含めることで、攻撃者が証明書の透明性ログ[RFC9162]を監視するのに役立ち、証明書の目的を特定します。
IANA has registered the following ASN.1 [X.680] module OID in the "SMI Security for PKIX Module Identifier" registry [SMI-PKIX-MOD]. This OID is defined in Appendix A.
IANAは、「PKIXモジュール識別子のSMIセキュリティ」レジストリ[SMI-PKIX-MOD]に次のASN.1 [X.680]モジュールOIDを登録しました。このOIDは、付録Aで定義されています。
+=========+=============================+===========+
| Decimal | Description | Reference |
+=========+=============================+===========+
| 117 | id-mod-config-update-sc-eku | RFC 9809 |
+---------+-----------------------------+-----------+
Table 1
IANA has also registered the following OIDs in the "SMI Security for PKIX Extended Key Purpose" registry [SMI-PKIX-PURPOSE]. These OIDs are defined in Section 4.
IANAはまた、「PKIXの拡張主要な目的のSMIセキュリティ」レジストリ[SMI-PKIX-Purpose]に次のOIDを登録しました。これらのOIDは、セクション4で定義されています。
+=========+================================+===========+
| Decimal | Description | Reference |
+=========+================================+===========+
| 41 | id-kp-configSigning | RFC 9809 |
+---------+--------------------------------+-----------+
| 42 | id-kp-trustAnchorConfigSigning | RFC 9809 |
+---------+--------------------------------+-----------+
| 43 | id-kp-updatePackageSigning | RFC 9809 |
+---------+--------------------------------+-----------+
| 44 | id-kp-safetyCommunication | RFC 9809 |
+---------+--------------------------------+-----------+
Table 2
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, February 2021,
<https://www.itu.int/rec/T-REC-X.680-202102-I/en>.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9336] Ito, T., Okubo, T., and S. Turner, "X.509 Certificate
General-Purpose Extended Key Usage (EKU) for Document
Signing", RFC 9336, DOI 10.17487/RFC9336, December 2022,
<https://www.rfc-editor.org/info/rfc9336>.
[RFC9509] Reddy.K, T., Ekman, J., and D. Migault, "X.509 Certificate
Extended Key Usage (EKU) for 5G Network Functions",
RFC 9509, DOI 10.17487/RFC9509, March 2024,
<https://www.rfc-editor.org/info/rfc9509>.
[Directive-2016_797]
European Parliament, Council of the European Union,
"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 European Union", May 2020,
<https://eur-lex.europa.eu/eli/dir/2016/797/2020-05-28>.
[ERJU] Europe's Rail Joint Undertaking, "Shared Cybersecurity
Services Specification - SP-SEC-ServSpec - V1.0", February
2025, <https://rail-research.europa.eu/wp-
content/uploads/2025/03/ERJU-SP-Cybersecurity-
Specifications-V1.0.zip>.
[ERJU-web] Europe's Rail Joint Undertaking, "Europe's Rail Joint
Undertaking - System Pillar",
<https://rail-research.europa.eu/system_pillar/>.
[EU-CRA] European Commission, "Regulation (EU) 2024/2847 of the
European Parliament and of the Council of 23 October 2024
on horizontal cybersecurity requirements for products with
digital elements and amending Regulations (EU) No 168/2013
and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber
Resilience Act)", November 2024,
<https://eur-lex.europa.eu/eli/reg/2024/2847/oj>.
[EU-STRATEGY]
European Commission, "The EU's Cybersecurity Strategy for
the Digital Decade", December 2020, <https://digital-
strategy.ec.europa.eu/en/library/eus-cybersecurity-
strategy-digital-decade-0>.
[NIST.SP.800-160]
Ross, R., Winstead, M., and M. McEvilley, "Engineering
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, "Systems and software engineering - Software
life cycle processes", ISO/IEC/IEEE 12207:2017, November
2017, <https://www.iso.org/standard/63712.html>.
[NIS2] European Commission, "Directive (EU) 2022/2555 of the
European Parliament and of the Council", December 2024,
<https://digital-strategy.ec.europa.eu/en/policies/
nis2-directive>.
[IEC.62443-4-2]
IEC, "Security for industrial automation and control
systems - Part 4-2: Technical security requirements for
IACS components", IEC 62443-4-2:2019, February 2019,
<https://webstore.iec.ch/publication/34421>.
[IEC.62443-3-3]
IEC, "Industrial communication networks - Network and
system security - Part 3-3: System security requirements
and security levels", IEC 62443-3-3:2013, August 2013,
<https://webstore.iec.ch/publication/7033>.
[CE-marking]
European Commission, "CE marking", <https://single-market-
economy.ec.europa.eu/single-market/ce-marking_en>.
[SMI-PKIX-PURPOSE]
IANA, "SMI Security for PKIX Extended Key Purpose",
<https://www.iana.org/assignments/smi-numbers>.
[SMI-PKIX-MOD]
IANA, "SMI Security for PKIX Module Identifier",
<https://www.iana.org/assignments/smi-numbers>.
The following module adheres to ASN.1 specifications [X.680] and [X.690].
次のモジュールは、ASN.1仕様[X.680]および[X.690]に準拠しています。
<CODE BEGINS>
Automation-EKU
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-config-update-sc-eku (117) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arc
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
-- Extended Key Usage Values
id-kp-configSigning OBJECT IDENTIFIER ::= { id-kp 41 }
id-kp-trustAnchorConfigSigning OBJECT IDENTIFIER ::= { id-kp 42 }
id-kp-updatePackageSigning OBJECT IDENTIFIER ::= { id-kp 43 }
id-kp-safetyCommunication OBJECT IDENTIFIER ::= { id-kp 44 }
END
<CODE ENDS>
These use cases are only for informational purposes.
これらのユースケースは、情報目的のみを目的としています。
Automation hardware and software products strive to become more safe and secure by fulfilling mandatory, generic system requirements related to cybersecurity, e.g., driven by federal offices like the European Union Cyber Resilience Act [EU-CRA] governed by the European Commission and the High Representative of the Union for Foreign Affairs and Security Policy. Automation products connected to the Internet and sold in the EU after 2027 must bear the so-called "CE marking" [CE-marking] to indicate that they comply with the EU-CRA. Such regulation was announced in the 2020 EU Cybersecurity Strategy [EU-STRATEGY] and complements other legislation in this area, like the directive on measures for a high common level of cybersecurity for network and information systems (NIS) across the European Union [NIS2].
オートメーションハードウェアおよびソフトウェア製品は、たとえば、欧州連合サイバーレジリエンス法[EU-CRA]などの連邦オフィスによって推進された、サイバーセキュリティに関連する必須の一般的なシステム要件を満たすことにより、より安全で安全になるよう努めています。インターネットに接続され、2027年以降にEUで販売された自動化製品は、いわゆる「CEマーキング」[CE-Marking]を担い、EU-CRAに準拠していることを示す必要があります。このような規制は、2020年のEUサイバーセキュリティ戦略[EU戦略]で発表され、この分野の他の法律を補完します。
The 2020 EU Cybersecurity Strategy [EU-STRATEGY] suggests implementing and extending international standards such as [IEC.62443-4-2] and [IEC.62443-3-3]. Automation hardware and software products of diverse vendors that are connected on automation networks and the Internet can be used to build common automation solutions. Standardized attributes would allow transparency of security properties and interoperability for vendors in the context of software and firmware updates, general-purpose configuration, trust anchor configuration, and safety-critical communication.
2020年のEUサイバーセキュリティ戦略[EU戦略]は、[IEC.62443-4-2]や[IEC.62443-3-3]などの国際基準の実装と拡張を提案しています。自動化ネットワークとインターネットで接続されている多様なベンダーの自動化ハードウェアとソフトウェア製品を使用して、一般的な自動化ソリューションを構築できます。標準化された属性により、ソフトウェアおよびファームウェアの更新、汎用構成、信頼アンカー構成、安全性の高いコミュニケーションのコンテキストで、ベンダーのセキュリティプロパティと相互運用性の透明性が可能になります。
A concrete example for automation is a rail automation system. The Europe's Rail web page [ERJU-web] states:
自動化の具体的な例は、レール自動化システムです。ヨーロッパの鉄道のウェブページ[Erju-Web]は次のように述べています。
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.
システムの柱は、鉄道部門の代表者を単一の調整機関の下にもたらします。これを達成するために、システムの柱は、統一された安全で安全なシステムアーキテクチャを提供し、サイバーセキュリティの側面を十分に考慮して、指令2016/797が適用する欧州鉄道ネットワーク（つまり、重い鉄道網）と関連する仕様および/または標準に焦点を当てています。
See [Directive-2016_797]. For details about the System Pillar, see [ERJU].
[Directive-2016_797]を参照してください。システムの柱の詳細については、[erju]を参照してください。
We would like to thank the authors of [RFC9336] and [RFC9509] for their excellent template.
[RFC9336]と[RFC9509]の著者に、優れたテンプレートについて感謝します。
We also thank all reviewers of this document for their valuable feedback.
また、この文書のすべてのレビュアーが貴重なフィードバックをしてくれたことにも感謝します。
Szofia Fazekas-Zisch
Siemens AG
Breslauer Str. 5
90766 Fuerth
Germany
Email: szofia.fazekas-zisch@siemens.com
URI: https://www.siemens.com
Baptiste Fouques
Alstom
Email: baptiste.fouques@alstomgroup.com
Daniel Gutierrez Orta
CAF Signalling
Email: daniel.gutierrez@cafsignalling.com
Martin Weller
Hitachi Rail
Email: martin.weller@urbanandmainlines.com
Nicolas Poyet
SNCF
Email: nicolas.poyet@sncf.fr
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
David Goltzsche
Siemens Mobility
Ackerstrasse 22
38126 Braunschweig
Germany
Email: david.goltzsche@siemens.com
URI: https://www.mobility.siemens.com