[要約] RFC 9483 - Lightweight Certificate Management Protocol (CMP) Profile aims to simplify and automate PKI management for industrial and IoT scenarios by profiling CMP and CRMF, emphasizing essential operations and options for lightweight and secure certificate management.
Internet Engineering Task Force (IETF) H. Brockhaus
Request for Comments: 9483 D. von Oheimb
Category: Standards Track S. Fries
ISSN: 2070-1721 Siemens
November 2023
This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.
このドキュメントは、産業およびモノのインターネット（IoT）シナリオの典型的なユースケースをカバーする、シンプルで相互運用可能な自動化されたPKI管理操作を目的としています。これは、証明書管理プロトコル（CMP）、関連する証明書要求メッセージ形式（CRMF）、および簡潔だが十分に詳細で自己完結型の方法でHTTPまたは制約されたアプリケーションプロトコル（COAP）に基づいて転送することによって達成されます。簡単なシナリオと制約されたデバイスの安全な証明書管理を可能な限り軽量にするために、最も重要なタイプの操作とオプションのみが必須として指定されています。より専門的または複雑なユースケースは、オプションの機能でサポートされています。
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/rfc9483.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9483で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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
1.1. How to Read This Document
1.2. Conventions and Terminology
1.3. Motivation for a Lightweight Profile of CMP
1.4. Special Requirements of Industrial and IoT Scenarios
1.5. Existing CMP Profiles
1.6. Compatibility with Existing CMP Profiles
1.7. Use of CMP in SZTP and BRSKI Environments
1.8. Scope of This Document
1.9. Structure of This Document
2. Solution Architecture
3. Generic Aspects of PKI Messages and PKI Management Operations
3.1. General Description of the CMP Message Header
3.2. General Description of the CMP Message Protection
3.3. General Description of CMP Message ExtraCerts
3.4. Generic PKI Management Operation Prerequisites
3.5. Generic Validation of a PKI Message
3.6. Error Handling
3.6.1. Reporting Error Conditions Upstream
3.6.2. Reporting Error Conditions Downstream
3.6.3. Handling Error Conditions on Nested Messages Used for
Batching
3.6.4. PKIStatusInfo and Error Messages
4. PKI Management Operations
4.1. Enrolling End Entities
4.1.1. Enrolling an End Entity to a New PKI
4.1.2. Enrolling an End Entity to a Known PKI
4.1.3. Updating a Valid Certificate
4.1.4. Enrolling an End Entity Using a PKCS #10 Request
4.1.5. Using MAC-Based Protection for Enrollment
4.1.6. Adding Central Key Pair Generation to Enrollment
4.1.6.1. Using the Key Transport Key Management Technique
4.1.6.2. Using the Key Agreement Key Management Technique
4.1.6.3. Using the Password-Based Key Management Technique
4.2. Revoking a Certificate
4.3. Support Messages
4.3.1. Get CA Certificates
4.3.2. Get Root CA Certificate Update
4.3.3. Get Certificate Request Template
4.3.4. CRL Update Retrieval
4.4. Handling Delayed Delivery
5. PKI Management Entity Operations
5.1. Responding to Requests
5.1.1. Responding to a Certificate Request
5.1.2. Responding to a Confirmation Message
5.1.3. Responding to a Revocation Request
5.1.4. Responding to a Support Message
5.1.5. Initiating Delayed Delivery
5.2. Forwarding Messages
5.2.1. Not Changing Protection
5.2.2. Adding Protection and Batching of Messages
5.2.2.1. Adding Protection to a Request Message
5.2.2.2. Batching Messages
5.2.3. Replacing Protection
5.2.3.1. Not Changing Proof-of-Possession
5.2.3.2. Using raVerified
5.3. Acting on Behalf of Other PKI Entities
5.3.1. Requesting a Certificate
5.3.2. Revoking a Certificate
6. CMP Message Transfer Mechanisms
6.1. HTTP Transfer
6.2. CoAP Transfer
6.3. Piggybacking on Other Reliable Transfer
6.4. Offline Transfer
6.4.1. File-Based Transfer
6.4.2. Other Asynchronous Transfer Protocols
7. Conformance Requirements
7.1. PKI Management Operations
7.2. Message Transfer
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Example CertReqTemplate
Acknowledgements
Authors' Addresses
This document specifies PKI management operations supporting machine-to-machine and IoT use cases. Its focus is to maximize automation and interoperability between all involved PKI entities, ranging from end entities (EEs) over any number of intermediate PKI management entities, such as registration authorities (RAs), to the Certificate Management Protocol (CMP) [RFC4210] endpoints of certification authority (CA) systems. This profile makes use of the concepts and syntax specified in CMP [RFC4210] [RFC9480] [RFC9481], Certificate Request Message Format (CRMF) [RFC4211] [RFC9045], Cryptographic Message Syntax (CMS) [RFC5652] [RFC8933], HTTP transfer for CMP [RFC6712], and CoAP transfer for CMP [RFC9482]. CMP, CRMF, and CMS are feature-rich specifications, but most application scenarios use only a limited subset of the same specified functionality. Additionally, the standards are not always precise enough on how to interpret and implement the described concepts. Therefore, this document aims to tailor the available options and specify how to use them in adequate detail to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible.
このドキュメントは、マシンからマシンとIoTのユースケースをサポートするPKI管理操作を指定します。その焦点は、登録機関（RAS）などの任意の数の中間PKI管理エンティティを超える最終エンティティ（EE）から証明書管理プロトコル（CMP）[RFC4210]エンドポイントに及ぶ、関係するすべてのPKIエンティティ間の自動化と相互運用性を最大化することです。認証機関（CA）システムの。このプロファイルは、CMP [RFC4210] [RFC9480] [RFC9481]で指定された概念と構文を使用しています。CMP [RFC6712]の転送、およびCMP [RFC9482]のCOAP転送。CMP、CRMF、およびCMSは機能が豊富な仕様ですが、ほとんどのアプリケーションシナリオは、同じ指定された機能の限られたサブセットのみを使用しています。さらに、標準は、説明されている概念を解釈および実装する方法について、必ずしも十分に正確ではありません。したがって、このドキュメントは、利用可能なオプションを調整し、それらを適切な詳細で使用する方法を指定して、相互運用可能な自動化された証明書管理の実装を可能な限り簡単かつ軽量にすることを目的としています。
While this document was being developed, documents intended to obsolete RFC 4210 [PKIX-CMP] and RFC 6712 [HTTP-CMP] were posted, and they include the full set of changes described in CMP Updates [RFC9480].
このドキュメントが開発されている間、RFC 4210 [PKIX-CMP]およびRFC 6712 [HTTP-CMP]を廃止することを目的としたドキュメントが投稿され、CMP更新[RFC9480]に記載されている変更の完全なセットが含まれています。
This document has become longer than the authors would have liked it to be. Yet apart from studying Section 3, which contains general requirements, the reader does not have to work through the whole document. The guidance in Sections 1.9 and 7 should be used to figure out which parts of Sections 4 to 6 are relevant for the target certificate management solution, depending on the PKI management operations, their variants, and types of message transfer needed.
この文書は、著者が望んでいたよりも長くなっています。しかし、一般的な要件を含むセクション3の研究とは別に、読者はドキュメント全体を操作する必要はありません。セクション1.9および7のガイダンスは、PKI管理操作、そのバリエーション、および必要なメッセージ転送の種類に応じて、ターゲット証明書管理ソリューションに関連するセクション4〜6のどの部分が関連するかを把握するために使用する必要があります。
Since conformity to this document can be achieved by implementing only the functionality declared mandatory in Section 7, the profile can still be called lightweight because, in particular for end entities, the mandatory-to-implement set of features is rather limited.
このドキュメントへの適合性は、セクション7で必須と宣言された機能のみを実装することで実現できるため、特に最終エンティティでは、義務的な特徴セットがかなり限られているため、プロファイルは軽量と呼ばれます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The term "PROHIBITED" is to be interpreted to mean that the respective ASN.1 field SHALL NOT be present or used.
「禁止」という用語は、それぞれのasn.1フィールドが存在したり使用されたりしないことを意味すると解釈されることです。
Technical terminology is used in conformance with [RFC4210], [RFC4211], [RFC5280], and IEEE 802.1AR [IEEE.802.1AR_2018]. The following terminology is used:
技術用語は、[RFC4210]、[RFC4211]、[RFC5280]、およびIEEE 802.1AR [IEEE.802.1AR_2018]に準拠して使用されます。次の用語が使用されます。
CA:
CA：
Certification authority, which issues certificates.
証明書を発行する認定機関。
RA:
RA：
Registration authority, an optional PKI component to which a CA delegates certificate management functions, such as end entity authentication and authorization checks for incoming requests. An RA can also provide conversion between various certificate management protocols and other protocols providing some operations related to certificate management.
登録機関、CAがエンティティ認証や承認チェックなどの証明書管理機能を代表するオプションのPKIコンポーネント。RAは、さまざまな証明書管理プロトコルと他のプロトコル間の変換を提供することもでき、証明書管理に関連するいくつかの操作を提供します。
LRA:
LRA：
Local registration authority, a specific form of RA with proximity to the end entities. Note: For ease of reading, this document also uses the term "RA" for LRAs in all cases where the difference is not relevant.
地方登録機関、最終エンティティに近いRAの特定の形式。注：読みやすさのために、このドキュメントでは、違いが関連しないすべての場合において、LRAの「RA」という用語も使用しています。
KGA:
KGA：
Key generation authority, an optional system component, typically colocated with an RA or CA, that offers key generation services to end entities.
通常、RAまたはCAでコロークされるオプションのシステムコンポーネントである主要生成機関は、エンティティを終了するための主要生成サービスを提供します。
EE:
EE：
End entity, typically a device or service that holds a public-private key pair for which it manages a public key certificate. An identifier for the EE is given as the subject of its certificate.
エンティティは、通常、公開鍵証明書を管理する官民キーペアを保持するデバイスまたはサービスです。EEの識別子は、その証明書の主題として与えられます。
The following terminology is reused from [RFC4210] as follows:
次の用語は、次のように[RFC4210]から再利用されます。
PKI management operation:
PKI管理操作：
All CMP messages belonging to a single transaction. The transaction is identified by the transactionID field of the message headers.
単一のトランザクションに属するすべてのCMPメッセージ。トランザクションは、メッセージヘッダーのトランザクションIDフィールドによって識別されます。
PKI management entity:
PKI管理エンティティ：
A non-EE PKI entity, i.e., an RA or a CA.
非EE PKIエンティティ、つまりRAまたはCA。
PKI entity:
PKIエンティティ：
An EE or PKI management entity.
EEまたはPKI管理エンティティ。
CMP messages are referred to by the names of PKIBody choices defined in Section 5.1.2 of [RFC4210] and are further described in Section 4 of this document.
CMPメッセージは、[RFC4210]のセクション5.1.2で定義されているPKIBODY選択の名前で言及され、このドキュメントのセクション4でさらに説明されています。
The following terms are introduced in this document:
このドキュメントでは、次の用語が紹介されています。
CMP protection key:
CMP保護キー：
The private key used to sign a CMP message.
秘密鍵は、CMPメッセージに署名するために使用されました。
CMP protection certificate:
CMP保護証明書：
The certificate related to the CMP protection key. If the keyUsage extension is present, it MUST include digitalSignature.
CMP保護キーに関連する証明書。KeyUSAGE拡張が存在する場合は、DigitalSignatureを含める必要があります。
CMP was standardized in 1999 and is implemented in several PKI products. In 2005, a completely reworked and enhanced version 2 of CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a document specifying a transfer mechanism for CMP messages using HTTP [RFC6712] in 2012.
CMPは1999年に標準化され、いくつかのPKI製品に実装されています。2005年には、CMP [RFC4210]およびCRMF [RFC4211]の完全に作り直され、強化されたバージョン2が公開され、2012年にはHTTP [RFC6712]を使用したCMPメッセージの転送メカニズムを指定するドキュメントが公開されました。
CMP is a capable protocol and could be used more widely. CMP [RFC4210] and CMP Updates [RFC9480] offer a very large set of features and options. On one hand, this makes CMP applicable to a very wide range of scenarios; on the other hand, a full implementation supporting all options is not realistic because this would take undue effort.
CMPは有能なプロトコルであり、より広く使用できます。CMP [RFC4210]およびCMP更新[RFC9480]は、非常に大きな機能とオプションセットを提供します。一方で、これにより、CMPは非常に幅広いシナリオに適用されます。一方、すべてのオプションをサポートする完全な実装は現実的ではありません。これには過度の努力が必要だからです。
In order to reduce complexity, the set of mandatory PKI management operations and variants required by this specification has been kept lean. This limits development efforts and minimizes resource needs, which is particularly important for memory-constrained devices. To this end, when there was design flexibility to either have necessary complexity on the EE or in the PKI management entity, this profile chose to include it in the PKI management entities where typically more computational resources are available. Additional recommended PKI management operations and variants support some more complex scenarios that are considered beneficial for environments with more specific demands or boundary conditions. The optional PKI management operations support less common scenarios and requirements.
複雑さを減らすために、この仕様に必要な必須のPKI管理操作とバリエーションのセットは、無駄のない状態に保たれています。これにより、開発の取り組みが制限され、リソースのニーズが最小限に抑えられます。これは、メモリが制約されたデバイスにとって特に重要です。この目的のために、EEまたはPKI管理エンティティに必要な複雑さを持つ設計の柔軟性があった場合、このプロファイルは、通常、より多くの計算リソースが利用可能なPKI管理エンティティにそれを含めることを選択しました。追加の推奨されるPKI管理操作とバリアントは、より具体的な要求または境界条件を備えた環境に有益であると考えられる、より複雑なシナリオをサポートしています。オプションのPKI管理操作は、あまり一般的ではないシナリオと要件をサポートしています。
Moreover, many details of the Certificate Management Protocol have been left open or have not been specified in full preciseness. The profiles specified in Appendices D and E of [RFC4210] define some more detailed PKI management operations. Yet the specific needs of highly automated scenarios for machine-to-machine communication are not covered sufficiently.
さらに、証明書管理プロトコルの多くの詳細は開いたままであるか、完全に正確に指定されていません。[RFC4210]の付録DおよびEで指定されたプロファイルは、いくつかのより詳細なPKI管理操作を定義します。しかし、マシン間通信のための高度に自動化されたシナリオの特定のニーズは、十分にカバーされていません。
Profiling is a way to reduce feature richness and complexity of standards to what is needed for specific use cases. 3GPP and UNISIG already use profiling of CMP as a way to cope with these challenges. To profile means to take advantage of the strengths of the given protocol while explicitly narrowing down the options it provides to those needed for the purpose(s) at hand and eliminating all identified ambiguities. In this way, the general aspects of the protocol are utilized and only the special requirements of the target scenarios need to be dealt with using distinct features the protocol offers.
プロファイリングは、特徴の豊かさと標準の複雑さを特定のユースケースに必要なものに減らす方法です。3GPPとUnisigは、これらの課題に対処する方法として、すでにCMPのプロファイリングを使用しています。プロファイルとは、指定されたプロトコルの強度を利用しながら、手元の目的に必要なものに提供するオプションを明示的に絞り込み、特定されたすべてのあいまいさを排除することを意味します。このようにして、プロトコルの一般的な側面が利用されており、ターゲットシナリオの特別な要件のみが、プロトコルが提供する明確な機能の使用に対処する必要があります。
Defining a profile for a new target environment takes high effort because the range of available options needs to be well understood and the selected options need to be consistent with each other and suitably cover the intended application scenario. Since most industrial PKI management use cases typically have much in common, it is worth sharing this effort, which is the aim of this document. Other standardization bodies can reference this document and further tailor the PKI management operations to their needs to avoid coming up with individual profiles from scratch.
新しいターゲット環境のプロファイルを定義するには、利用可能なオプションの範囲をよく理解する必要があり、選択したオプションが互いに一致し、意図したアプリケーションシナリオを適切にカバーする必要があるため、大きな労力が必要です。ほとんどの産業用PKI管理のユースケースには通常、多くの共通点があるため、この努力を共有する価値があります。これがこのドキュメントの目的です。他の標準化団体は、このドキュメントを参照し、個々のプロファイルをゼロから考えないように、PKI管理操作をさらに調整することができます。
The profiles specified in Appendices D and E of [RFC4210] have been developed particularly for managing certificates of human end entities. With the evolution of distributed systems and client-server architectures, certificates for machines and applications on them have become widely used. This trend has strengthened even more in emerging industrial and IoT scenarios. CMP is sufficiently flexible to support them well.
[RFC4210]の付録DおよびEで指定されたプロファイルは、特に人間の最終団体の証明書を管理するために開発されました。分散システムとクライアントサーバーアーキテクチャの進化により、マシンの証明書とそれらのアプリケーションが広く使用されています。この傾向は、新興産業およびIoTのシナリオでさらに強化されています。CMPは、それらをうまくサポートするのに十分な柔軟性があります。
Today's IT security architectures for industrial solutions typically use certificates for endpoint authentication within protocols like IPsec, TLS, or Secure Shell (SSH). Therefore, the security of these architectures highly relies upon the security and availability of the implemented certificate management operations.
今日のIT産業ソリューションのITセキュリティアーキテクチャは、通常、IPSEC、TLS、Secure Shell（SSH）などのプロトコル内でエンドポイント認証に証明書を使用しています。したがって、これらのアーキテクチャのセキュリティは、実装された証明書管理操作のセキュリティと可用性に大きく依存しています。
Due to increasing security and availability needs in operational technology, especially when used for critical infrastructures and systems with a high number of certificates, a state-of-the-art certificate management system must be constantly available and cost-efficient, which calls for high automation and reliability. Consequently, "Framework for Improving Critical Infrastructure Cybersecurity" [NIST.CSWP.04162018] refers to proper processes for issuance, management, verification, revocation, and audit of authorized devices, users, and processes involving identity and credential management. According to commonly accepted best practices, such PKI management operations are also required in [IEC.62443-3-3] for security level 2 and higher.
運用技術のセキュリティと可用性のニーズの増加により、特に多くの証明書を持つ重要なインフラストラクチャとシステムに使用される場合、最先端の証明書管理システムは常に利用可能で費用効率が高い必要があります。自動化と信頼性。その結果、「重要なインフラストラクチャサイバーセキュリティを改善するためのフレームワーク」[nist.cswp.04162018]とは、アイデンティティと資格管理を含む承認されたデバイス、ユーザー、およびプロセスの発行、管理、検証、取り消し、および監査のための適切なプロセスを指します。一般的に受け入れられているベストプラクティスによると、このようなPKI管理業務は、セキュリティレベル2以上の[IEC.62443-3-3]でも必要です。
Further challenges in many industrial systems are network segmentation and asynchronous communication. Also, PKI management entities like certification authorities (CAs) are not typically deployed on-site but in a highly protected data center environment, e.g., operated according to ETSI Policy and security requirements for Trust Service Providers issuing certificates [ETSI-EN.319411-1]. Certificate management must be able to cope with such network architectures. CMP offers the required flexibility and functionality, namely authenticated self-contained messages, efficient polling, and support for asynchronous message transfer while retaining end-to-end authentication.
多くの産業システムにおけるさらなる課題は、ネットワークセグメンテーションと非同期通信です。また、認定当局（CAS）などのPKI管理エンティティは、通常、現場で展開されるのではなく、高度に保護されたデータセンター環境で展開されます。1]。証明書管理は、このようなネットワークアーキテクチャに対処できる必要があります。CMPは、必要な柔軟性と機能、つまり、エンドツーエンド認証を保持しながら、非同期メッセージ転送の認証された自己完結型メッセージ、効率的なポーリング、サポートを提供します。
As already stated, [RFC4210] contains profiles with mandatory and optional PKI management operations in Appendices D and E of [RFC4210]. Those profiles focus on management of human user certificates and only partly address the specific needs of certificate management automation for unattended devices or machine-to-machine application scenarios.
すでに述べたように、[RFC4210]には、[RFC4210]の付録DおよびEに必須およびオプションのPKI管理操作を備えたプロファイルが含まれています。これらのプロファイルは、人間のユーザー証明書の管理に焦点を当てており、無人のデバイスまたはマシン間アプリケーションシナリオの証明書管理自動化の特定のニーズに部分的にのみ対処します。
Both Appendices D and E of [RFC4210] focus on PKI management operations between an EE and an RA or CA. They do not address further profiling of RA-to-CA communication, which is typically needed for full backend automation. All requirements regarding algorithm support for Appendices D and E of [RFC4210] have been updated by Section 7.1 of CMP Algorithms [RFC9481].
[RFC4210]の付録DとEの両方は、EEとRAまたはCAの間のPKI管理操作に焦点を当てています。彼らは、RAからCAへのコミュニケーションのさらなるプロファイリングには対処していません。これは通常、完全なバックエンド自動化に必要です。[RFC4210]の付録DおよびEのアルゴリズムサポートに関するすべての要件は、CMPアルゴリズム[RFC9481]のセクション7.1によって更新されています。
3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 [ETSI-3GPP.33.310] for automatic management of IPsec certificates in 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP profile for initial certificate enrollment and certificate update operations between EEs and RAs/CAs is specified in that document.
3GPPは、33.310 [ETSI-3GPP.33.310]でCMP [RFC4210]を使用して、3G、LTE、および5GバックボーンネットワークのIPSEC証明書を自動管理しています。2010年以降、EESとRAS/CAS間の初期証明書の登録と証明書の更新操作に関する専用のCMPプロファイルがそのドキュメントで指定されています。
In 2015, UNISIG included a CMP profile for enrollment of TLS certificates in the Subset-137 specifying the ETRAM/ETCS online key management for train control systems [UNISIG.Subset-137].
2015年、UNISIGには、サブセット137にTLS証明書を登録するためのCMPプロファイルが含まれており、列車制御システムのETRAM/etcsオンラインキー管理を指定しました[Unisig.Subset-137]。
Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI management operations for unattended devices and services.
両方の標準化ボディは、CMP [RFC4210]、CRMF [RFC4211]、およびCMP [RFC6712]のHTTP転送の両方で、無人のデバイスとサービスの高度に自動化された信頼性の高いPKI管理操作を行います。
The profile specified in this document is compatible with Appendices D and E of [RFC4210], with the following exceptions:
このドキュメントで指定されているプロファイルは、次の例外を除いて、[RFC4210]の付録DおよびEと互換性があります。
* signature-based protection is the default protection; an initial PKI management operation may also use protection based on the message authentication code (MAC),
* 署名ベースの保護はデフォルトの保護です。最初のPKI管理操作は、メッセージ認証コード（MAC）に基づいて保護を使用する場合があります。
* certification of a second key pair within the same PKI management operation is not supported,
* 同じPKI管理操作内の2番目のキーペアの認証はサポートされていません、
* proof-of-possession (POP) with the self-signature of the certReq containing the certTemplate (according to [RFC4211], Section 4.1, clause 3) is the recommended default POP method (deviations are possible for EEs when requesting central key generation, for RAs when using raVerified, and if the newly generated keypair is technically not capable to generate digital signatures),
* CertTemplateを含むCertreqの自己署名（[RFC4211]、セクション4.1、条項3による）を含む、POSPOSSESSION（POP）は、推奨されるデフォルトのPOPメソッドです（中央キー生成を要求する場合、EEの偏差が可能です。RASの場合、Raverifiedを使用する場合、および新しく生成されたKeypairが技術的にデジタル署名を生成できない場合、
* confirmation of newly enrolled certificates may be omitted, and
* 新しく登録された証明書の確認は省略され、
* all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages (requiring a push model, a CMP server on the EE) are excluded in favor of a lightweight implementation on the EE.
* すべてのPKI管理操作は、EEで発信されるリクエスト応答メッセージペアで構成されています。つまり、アナウンスメッセージ（プッシュモデル、EEのCMPサーバーが必要です）は、EEの軽量実装を支持して除外されます。
The profile specified in this document is compatible with the CMP profile for 3G, LTE, and 5G network domain security and authentication framework [ETSI-3GPP.33.310], except that:
このドキュメントで指定されたプロファイルは、3G、LTE、および5Gネットワークドメインのセキュリティおよび認証フレームワーク[ETSI-3GPP.33.310]のCMPプロファイルと互換性があります。
* protection of initial PKI management operations may be MAC-based,
* 最初のPKI管理操作の保護はMacベースである可能性があります、
* the subject field is mandatory in certificate templates, and
* 件名フィールドは証明書テンプレートで必須であり、
* confirmation of newly enrolled certificates may be omitted.
* 新しく登録された証明書の確認は省略される場合があります。
The profile specified in this document is compatible with the CMP profile for online key management in rail networks as specified in [UNISIG.Subset-137], except that:
このドキュメントで指定されたプロファイルは、[Unisig.Subset-137]で指定されている鉄道ネットワークのオンラインキー管理のCMPプロファイルと互換性があります。
* A certificate enrollment request message consists of only one certificate request (CertReqMsg).
* 証明書登録要求メッセージは、1つの証明書要求（certreqmsg）のみで構成されています。
* [RFC4210] requires that the messageTime is Greenwich Mean Time coded as generalizedTime.
* [RFC4210]では、MessageTimeがGreenized TimeがGeneralizedTimeとしてコード化されているグリニッジの平均時間であることを要求しています。
* Note: As Table 5 of [UNISIG.Subset-137] explicitly states that the messageTime is required to be "UTC time", it is not clear if this means a coding as UTCTime or generalizedTime and if time zones other than Greenwich Mean Time shall be allowed. Both time formats are described in Section 4.1.2.5 of [RFC5280].
* 注：[unisig.subset-137]の表5として、メッセージは「utc時間」である必要があることを明示的に述べています。これがUtctimeまたは一般化された時間としてのコーディングを意味するかどうかは明らかではありません。許可されている。両方の時間形式は、[RFC5280]のセクション4.1.2.5で説明されています。
* The same type of protection is required to be used for all messages of one PKI management operation. This means, in case the request message protection is MAC-based, the response, certConf, and pkiConf messages must also have MAC-based protection.
* 1つのPKI管理操作のすべてのメッセージに同じタイプの保護を使用する必要があります。これは、要求メッセージ保護がMacベースである場合、Response、CertConf、およびPKICONFメッセージにもMACベースの保護が必要な場合を意味します。
* Use of caPubs is not required but is typically allowed in combination with MAC-based protected PKI management operations. On the other hand, Table 12 of [UNISIG.Subset-137] requires using caPubs.
* カプブの使用は必須ではありませんが、通常、Macベースの保護されたPKI管理操作と組み合わせて許可されます。一方、[unisig.subset-137]の表12には、カプブを使用する必要があります。
* Note: It remains unclear from UNISIG Subset-137 which certificate(s) for the caPubs field should be used. For security reasons, it cannot be used for delivering the root CA certificate needed to validate the signature-based protection of the given response message (as stated indirectly also in Section 6.3.1.5.2 b of [UNISIG.Subset-137]).
* 注：UNISIG Subset-137から、どのCapubsフィールドの証明書を使用するかは不明のままです。セキュリティ上の理由から、指定された応答メッセージの署名ベースの保護を検証するために必要なルートCA証明書を配信するために使用することはできません（[Unisig.Subset-137]のセクション6.3.1.5.2 Bで間接的に述べたように）。
* This profile requires that the certConf message have one CertStatus element where the statusInfo field is recommended.
* このプロファイルでは、CERTCONFメッセージには、StatusINFOフィールドが推奨される1つのcertStatus要素が必要です。
* Note: In contrast, Table 18 of [UNISIG.Subset-137] requires that the certConf message has one CertStatus element where the statusInfo field must be absent. This precludes sending a negative certConf message in case the EE rejects the newly enrolled certificate. This results in violating the general rule that a certificate request transaction must include a certConf message (moreover, since using implicitConfirm is not allowed there either).
* 注：対照的に、[unisig.subset-137]の表18には、certConfメッセージには、statusinfoフィールドがない必要がある1つのcertstatus要素が必要です。これは、EEが新しく登録された証明書を拒否した場合に備えて、ネガティブなCertConfメッセージを送信することを妨げます。これにより、証明書リクエストトランザクションにはCertConfメッセージが含まれている必要があるという一般的なルールに違反します（さらに、ImplicitConfirmの使用も許可されていないため）。
In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other environments using Network Configuration Protocol (NETCONF) / YANG modules, [SZTP-CSR] offers a YANG module that includes several types of certificate requests to obtain a public key certificate for a locally generated key pair. Such messages are of the form ietf-ztp-types:cmp-csr from module ietf-ztp-csr and offer both proof-of-possession and proof-of-identity. To allow PKI management entities that use the module ietf-ztp-csr and also wish to comply with this profile, the ir, cr, kur, or p10cr message MUST be formatted by the EE as described in Section 4.1, and it MAY be forwarded, as specified in Section 5.2.
セキュアゼロタッチプロビジョニング（SZTP）[RFC8572]およびネットワーク構成プロトコル（NetConf） / Yangモジュールを使用した他の環境では、[SZTP-CSR]は、地元の地元の公開証明書を取得するためのいくつかのタイプの証明書リクエストを含むYangモジュールを提供します。生成されたキーペア。このようなメッセージは、IETF-ZTPタイプの形式であり、モジュールIETF-ZTP-CSRからのCMP-CSRであり、提案と証明の両方の同一性の両方を提供します。モジュールIETF-ZTP-CSRを使用し、このプロファイルに準拠することを希望するPKI管理エンティティを許可するには、IR、CR、KUR、またはP10CRメッセージをセクション4.1で説明したようにEEによってフォーマットする必要があり、転送される場合があります。、セクション5.2で指定されています。
In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI" [BRSKI-AE] describes a generalization regarding the employed enrollment protocols to allow alternatives to Enrollment over Secure Transport (EST) [RFC7030]. For the use of CMP, it requires adherence to this profile.
リモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]環境のブートストラップで、「BRSKI-AE：BRSKIの代替登録プロトコル」[BRSKI-AE]は、採用された登録プロトコルに関する一般化を説明しています。RFC7030]。CMPを使用するには、このプロファイルを順守する必要があります。
On one hand, this profile intends to reduce the flexibility of CMP to the generic needs of automated certificate management of machine end entities. On the other hand, it offers a variety of PKI management operations and options relevant for industrial use cases. Therefore, it is still a framework that supports further profiling by those addressing a specific use case or scenario, e.g., 3GPP/ETSI or UNISIG. There is room to further tailor this profile. This enables stricter profiling to meet the concrete needs in application areas.
一方では、このプロファイルは、CMPの自動化された証明書管理の一般的なニーズに対するCMPの柔軟性をマシンエンドエンティティの一般的なニーズに減らすことを目的としています。一方、さまざまなPKI管理業務と産業用ユースケースに関連するオプションを提供します。したがって、これは依然として、特定のユースケースまたはシナリオ、例えば3GPP/ETSIまたはUNISIGに対処する人によるさらなるプロファイリングをサポートするフレームワークです。このプロファイルをさらに調整する余地があります。これにより、より厳格なプロファイリングがアプリケーションエリアの具体的なニーズを満たすことができます。
To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements for generating PKI management messages on the sender side. However, it gives only minimal requirements on checks by the receiving side and how to handle error cases.
不必要な多様性を通じて曖昧さと複雑さを最小限に抑えるために、このドキュメントは、送信者側にPKI管理メッセージを生成するための徹底的な要件を指定します。ただし、受信側とエラーケースの処理方法によるチェックに関する最小要件のみを提供します。
Especially on the EE side, this profile aims at a lightweight implementation. This means that the number of PKI management operation implementations are reduced to a reasonable minimum to support typical certificate management use cases in industrial machine-to-machine environments. On the EE side, only limited resources are expected, while on the side of the PKI management entities, the profile accepts higher requirements.
特にEE側では、このプロファイルは軽量の実装を目指しています。これは、PKI管理操作の実装の数が、産業用機械からマシンへの環境での典型的な証明書管理のユースケースをサポートするために、合理的な最小値に削減されることを意味します。EE側では、限られたリソースのみが予想されますが、PKI管理エンティティの側では、プロファイルはより高い要件を受け入れます。
For the sake of interoperability and robustness, implementations should, so long as security is not affected, adhere to Postel's law: "Be conservative in what you do, be liberal in what you accept from others" (often reworded as: "Be conservative in what you send, be liberal in what you receive").
相互運用性と堅牢性のために、実装は、セキュリティが影響を受けない限り、ポステルの法律を遵守する必要があります。あなたが送るものは、あなたが受け取るものでリベラルになります」）。
Fields used in ASN.1 syntax in Sections 3, 4, or 5 are specified in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. When these sections do not explicitly discuss a field, then the field SHOULD NOT be used by the sending entity. The receiving entity MUST NOT require the absence of such a field and, if the field is present, MUST handle it gracefully.
セクション3、4、または5のASN.1構文で使用されるフィールドは、CMP [RFC4210] [RFC9480]、CRMF [RFC4211]、およびCMS [RFC5652] [RFC8933]で指定されています。これらのセクションがフィールドについて明示的に議論しない場合、フィールドは送信エンティティによって使用されるべきではありません。受信エンティティは、そのようなフィールドの不在を要求してはなりません。フィールドが存在する場合、それを優雅に処理する必要があります。
Section 2 introduces the general PKI architecture and approach to certificate management that is assumed in this document.
セクション2では、このドキュメントで想定されている一般的なPKIアーキテクチャと証明書管理へのアプローチを紹介します。
Section 3 profiles the generic aspects of the PKI management operations specified in detail in Sections 4 and 5 to minimize redundancy in the description and to ease implementation. This covers the general structure and protection of messages, as well as generic prerequisites, validation, and error handling.
セクション3は、説明の冗長性を最小限に抑え、実装を容易にするために、セクション4および5で詳細に指定されたPKI管理操作の一般的な側面をプロファイルします。これは、メッセージの一般的な構造と保護、および一般的な前提条件、検証、およびエラー処理をカバーします。
Section 4 profiles the exchange of CMP messages between an EE and the PKI management entity. There are various flavors of certificate enrollment requests, optionally with polling, central key generation, revocation, and general support PKI management operations.
セクション4は、EEとPKI管理エンティティの間のCMPメッセージの交換をプロファイルします。オプションでは、ポーリング、中央キーの生成、取り消し、および一般的なサポートPKI管理オペレーションなど、証明書登録リクエストにはさまざまなフレーバーがあります。
Section 5 profiles responding to requests, exchanges between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which involves polling for responses, and nesting of messages.
セクション5プロファイルは、リクエスト、PKI管理エンティティ間の交換、および他のPKIエンティティに代わっての運用に対応しています。これには、応答のポーリングやメッセージのネストを含むメッセージの配信の遅延が含まれる場合があります。
Section 6 outlines several mechanisms for CMP message transfer, including HTTP-based transfer [RFC6712] optionally using TLS, CoAP-based transfer [RFC9482] optionally using DTLS, and offline file-based transport.
セクション6では、HTTPベースの転送[RFC6712]、オプションでTLS、COAPベースの転送[RFC9482]をオプションで使用してDTLSを使用し、オフラインファイルベースのトランスポートを使用して、CMPメッセージ転送のいくつかのメカニズムの概要を説明します。
Section 7 defines which parts of the profile are mandatory, recommended, optional, or not relevant to implement for which type of entity.
セクション7では、プロファイルのどの部分が必須、推奨、オプション、またはどのタイプのエンティティの実装に関連していないかを定義します。
To facilitate secure automatic certificate enrollment, the device hosting an EE is typically equipped with a manufacturer-issued device certificate. Such a certificate is typically installed during production and is meant to identify the device throughout its lifetime. This certificate can be used to protect the initial enrollment of operational certificates after installation of the EE in its operational environment. In contrast to the manufacturer-issued device certificate, operational certificates are issued by the owner or operator of the device to identify the device or one of its components for operational use, e.g., in a security protocol like IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018], a manufacturer-issued device certificate is called an Initial Device Identifier (IDevID) certificate and an operational certificate is called a Locally Significant Device Identifier (LDevID) certificate.
安全な自動証明書の登録を容易にするために、EEをホストするデバイスには通常、メーカーが発行するデバイス証明書が装備されています。このような証明書は通常、生産中にインストールされ、その生涯を通じてデバイスを識別することを目的としています。この証明書は、運用環境にEEをインストールした後の運用証明書の初期登録を保護するために使用できます。製造業者が発行するデバイス証明書とは対照的に、デバイスの所有者またはオペレーターによって運用証明書が発行され、例えば、IPSEC、TLS、またはSSHなどのセキュリティプロトコルで、デバイスまたはそのコンポーネントの1つを識別します。IEEE 802.1AR [IEEE.802.1AR_2018]では、メーカーが発行するデバイス証明書は初期デバイス識別子（IDEVID）証明書と呼ばれ、運用証明書はローカルに重要なデバイス識別子（LDEVID）証明書と呼ばれます。
Note: The owner or operator using the manufacturer-issued device certificate for authenticating the device during initial enrollment of operational certificates MUST trust the respective trust anchor provided by the manufacturer.
注：運用証明書の最初の登録中にデバイスを認証するためにメーカーが発行したデバイス証明書を使用する所有者またはオペレーターは、メーカーが提供するそれぞれの信頼アンカーを信頼する必要があります。
Note: According to IEEE 802.1AR [IEEE.802.1AR_2018], a DevID comprises the triple of the certificate, the corresponding private key, and the certificate chain.
注：IEEE 802.1AR [IEEE.802.1AR_2018]によると、Devidは証明書のトリプル、対応する秘密鍵、および証明書チェーンを含む。
All certificate management operations specified in this document follow the pull model, i.e., they are initiated by an EE (or by an RA acting as an EE). The EE creates a CMP request message, protects it using some asymmetric credential or shared secret information, and sends it to a PKI management entity. This PKI management entity may be a CA or more typically an RA, which checks the request and responds to it itself or forwards the request upstream to the next PKI management entity. In case an RA changes the CMP request message header or body or wants to demonstrate successful verification or authorization, it can apply a protection of its own. The communication between an LRA and RA can be performed synchronously or asynchronously. Asynchronous communication typically leads to delayed message delivery as described in Section 4.4.
このドキュメントで指定されたすべての証明書管理操作は、プルモデルに従います。つまり、EE（またはEEとして機能するRA）によって開始されます。EEは、CMP要求メッセージを作成し、非対称の資格情報または共有秘密情報を使用して保護し、PKI管理エンティティに送信します。このPKI管理エンティティは、CA以上に通常はRAである場合があります。これは、リクエストをチェックしてそれ自体に応答するか、リクエストを次のPKI管理エンティティに上流に転送します。RAがCMPリクエストメッセージヘッダーまたはボディを変更する場合、または検証または承認の成功を実証したい場合、独自の保護を適用できます。LRAとRAの間の通信は、同期または非同期に実行できます。非同期通信は通常、セクション4.4で説明されているように、メッセージ伝達が遅れることにつながります。
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| EE |<---------->| LRA |<-------------->| RA |<---------->| CA |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
synchronous (a)synchronous (a)synchronous
+----connection----+------connection------+----connection----+
operators service partner
+---------on site---------+---back-end services--+---trust center--+
<--- downstream <--- | ---> upstream --->
Figure 1: Certificate Management Architecture Example
図1：証明書管理アーキテクチャの例
In operational environments, the certificate management architecture can have multiple LRAs bundling requests from multiple EEs at dedicated locations and one (or more than one) central RA aggregating the requests from the LRAs. Every LRA in this scenario has shared secret information (one per EE) for MAC-based protection or a CMP protection key and certificate, allowing it to protect CMP messages it processes using its own credentials. The figure above shows an architectural example with one LRA, RA, and CA. It is also possible not to have an RA or LRA or that there is no CA with a CMP interface. Depending on the network infrastructure, the message transfer between PKI management entities may be based on synchronous online connections, asynchronous connections, or even offline (e.g., file-based) transfer.
運用環境では、証明書管理アーキテクチャは、専用の場所で複数のEEからの複数のLRASバンドリングリクエストを持ち、LRASからの要求を集約する1つ（または複数）の中央RAを持つことができます。このシナリオのすべてのLRAは、Macベースの保護またはCMP保護キーと証明書の秘密情報（EEごと）を共有しているため、独自の資格情報を使用して処理するCMPメッセージを保護できます。上の図は、1つのLRA、RA、およびCAを含む建築例を示しています。また、RAまたはLRAを持っていないこと、またはCMPインターフェイスを持つCAがないことも可能です。ネットワークインフラストラクチャに応じて、PKI管理エンティティ間のメッセージ転送は、同期オンライン接続、非同期接続、またはオフライン（ファイルベース）転送に基づいている場合があります。
Note: In contrast to the pull model used in this document, other specifications could use the messages specified in this document to implement the push model. In this case, the EE is pushed (triggered) by the PKI management entity to provide the CMP request; therefore, the EE acts as the receiver, not initiating the interaction with the PKI. For example, when the device itself only acts (as a server as described in BRSKI with Pledge in Responder Mode [BRSKI-PRM]), support of certificate enrollment in a push model is needed. While BRSKI-PRM currently utilizes its own format for the exchanges, CMP in general and the messages specified in this profile offer all required capabilities. Nevertheless, the message flow and state machine as described in Section 4 must be adapted to implement a push model.
注：このドキュメントで使用されているプルモデルとは対照的に、他の仕様では、このドキュメントで指定されたメッセージを使用してプッシュモデルを実装できます。この場合、EEはPKI管理エンティティによってプッシュされ（トリガー）、CMPリクエストを提供します。したがって、EEは受信機として機能し、PKIとの相互作用を開始しません。たとえば、デバイス自体が（レスポンダーモード[BRSKI-PRM]の誓約を備えたBRSKIで説明されているサーバーとして）のみ動作する場合、プッシュモデルへの証明書登録のサポートが必要です。BRSKI-PRMは現在、取引所に独自の形式を利用していますが、一般的にCMPとこのプロファイルで指定されたメッセージはすべて必要な機能を提供します。それにもかかわらず、セクション4で説明されているメッセージフローと状態マシンは、プッシュモデルを実装するために適応する必要があります。
Note: Third-party CAs not conforming to this document may implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management. In such cases, an RA needs to adapt the exchanged CMP messages to the flavor of certificate management interaction required by such a nonconformant CA.
注：このドキュメントに準拠していないサードパーティCAは、CMP、異なる標準化されたプロトコル、または証明書管理のための独自のインターフェイスの他のバリエーションを実装する場合があります。そのような場合、RAは交換されたCMPメッセージを、そのような不適合caによって必要な証明書管理相互作用のフレーバーに適応する必要があります。
This section covers the generic aspects of the PKI management operations specified in Sections 4 and 5 as upfront general requirements to minimize redundancy in the description and to ease implementation.
このセクションでは、説明の冗長性を最小限に抑え、実装を容易にするための、セクション4および5で指定されているPKI管理操作の一般的な側面について説明します。
As described in Section 5.1 of [RFC4210], all CMP messages have the following general structure:
[RFC4210]のセクション5.1で説明されているように、すべてのCMPメッセージには次の一般的な構造があります。
+--------------------------------------------+
| PKIMessage |
| +----------------------------------------+ |
| | header | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | body | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | protection (OPTIONAL) | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | extraCerts (OPTIONAL) | |
| +----------------------------------------+ |
+--------------------------------------------+
Figure 2: CMP Message Structure
図2：CMPメッセージ構造
The general contents of the message header, protection, and extraCerts fields are specified in the following three subsections.
メッセージヘッダー、保護、およびエクストラメートフィールドの一般的な内容は、次の3つのサブセクションで指定されています。
In case a specific PKI management operation needs different contents in the header, protection, or extraCerts fields, the differences are described in the respective subsections of Sections 4 and 5.
特定のPKI管理操作がヘッダー、保護、またはエクストラセートフィールドに異なる内容が必要な場合、違いはセクション4および5のそれぞれのサブセクションで説明されています。
The CMP message body contains the PKI management operation-specific information. It is described in Sections 4 and 5.
CMPメッセージ本文には、PKI管理操作固有の情報が含まれています。セクション4および5で説明します。
Note: In the description of CMP messages, the presence of some fields is stated as OPTIONAL or RECOMMENDED. The following text that states requirements on such a field applies only if the field is present.
注：CMPメッセージの説明では、一部のフィールドの存在がオプションまたは推奨として述べられています。このようなフィールドの要件を記載する次のテキストは、フィールドが存在する場合にのみ適用されます。
The generic prerequisites needed by the PKI entities in order to perform PKI management operations are described in Section 3.4.
PKI管理操作を実行するためにPKIエンティティが必要とする一般的な前提条件については、セクション3.4で説明します。
The generic validation steps to be performed by PKI entities upon receiving a CMP message are described in Section 3.5.
CMPメッセージを受信したときにPKIエンティティによって実行される一般的な検証手順は、セクション3.5で説明されています。
The generic aspects of handling and reporting errors are described in Section 3.6.
取り扱いエラーと報告エラーの一般的な側面については、セクション3.6で説明します。
This section describes the generic header fields of all CMP messages.
このセクションでは、すべてのCMPメッセージの一般的なヘッダーフィールドについて説明します。
Any fields or variations specific to PKI management operation are described in Sections 4 and 5.
PKI管理操作に固有のフィールドまたはバリエーションは、セクション4および5で説明されています。
header
pvno REQUIRED
-- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData
-- is supported and expected to be used in the current
-- PKI management operation
-- MUST be 3 to indicate CMP v3 in certConf messages when using
-- the hashAlg field
-- MUST be 2 to indicate CMP v2 in all other cases
-- For details on version negotiation, see [RFC9480]
sender REQUIRED
-- Contains a name representing the originator, which also
-- protects the message
-- For signature-based protection, MUST be the subject field of
-- the CMP protection certificate
-- For MAC-based protection, MUST contain a name the PKI
-- management entity can use to identify the shared secret
-- information. This name MUST be placed in the commonName
-- field of the directoryName choice.
-- In a multihop scenario, the receiving entity cannot rely
-- on the correctness of the sender field.
recipient REQUIRED
-- SHOULD be the name of the intended recipient; otherwise, the
-- NULL-DN MUST be used
-- In the first message of a PKI management operation, SHOULD be
-- the subject DN of the CA the PKI management operation is
-- requested from
-- In all other messages, SHOULD contain the value of the sender
-- field of the previous message in the same PKI management
-- operation
-- The recipient field shall be handled gracefully by the
-- receiving entity, because in a multihop scenario, its
-- correctness cannot be guaranteed.
messageTime OPTIONAL
-- MUST be present if the confirmWaitTime field is present
-- MUST be the time at which the message was produced, if present
-- MAY be set by a PKI management entity to provide the current
-- time
-- MAY be used by the end entity for time synchronization if the
-- response was received within a short time frame
protectionAlg REQUIRED
-- MUST be an algorithm identifier indicating the algorithm
-- used for calculating the protection bits
-- If it is a signature algorithm, its type MUST be
-- MSG_SIG_ALG as specified in Section 3 of [RFC9481] and
-- MUST be consistent with the subjectPublicKeyInfo field of
-- the CMP protection certificate
-- If it is a MAC algorithm, its type MUST be MSG_MAC_ALG, as
-- specified in [RFC9481], Section 6.1
senderKID RECOMMENDED
-- For signature-based protection, MUST be used and contain the
-- value of the SubjectKeyIdentifier if present in the CMP
-- protection certificate
-- For MAC-based protection, MUST be used and contain the same
-- name as in the commonName field of the sender field
transactionID REQUIRED
-- In the first message of a PKI management operation, MUST be
-- 128 bits of random data to minimize the probability of
-- having the transactionID already in use at the server
-- In all other messages, MUST be the value from the previous
-- message in the same PKI management operation
senderNonce REQUIRED
-- MUST be cryptographically secure and fresh 128 random bits
recipNonce RECOMMENDED
-- If this is the first message of a transaction, MUST be absent
-- If this is a delayed response message, MUST be present and
-- contain the value of the senderNonce of the respective
-- request message in the same transaction
-- In all other messages, MUST be present and contain the value
-- of the senderNonce of the previous message in the same
-- transaction
generalInfo OPTIONAL
implicitConfirm OPTIONAL
-- RECOMMENDED in ir/cr/kur/p10cr messages,
-- OPTIONAL in ip/cp/kup response messages, and
-- PROHIBITED in other types of messages
-- Added to request messages to request omission of the certConf
-- message
-- Added to response messages to grant omission of the certConf
-- message
-- See [RFC4210], Section 5.1.1.1.
ImplicitConfirmValue REQUIRED
-- ImplicitConfirmValue MUST be NULL
confirmWaitTime OPTIONAL
-- RECOMMENDED in ip/cp/kup messages if implicitConfirm is
-- not included
-- PROHIBITED if implicitConfirm is included
-- See [RFC4210], Section 5.1.1.2.
ConfirmWaitTimeValue REQUIRED
-- ConfirmWaitTimeValue MUST be a GeneralizedTime value
-- specifying the point in time up to which the PKI management
-- entity will wait for the certConf message. The accepted
-- length of the waiting period will vary by use case.
certProfile OPTIONAL
-- MAY be present in ir/cr/kur/p10cr and in genm messages of type
-- id-it-certReqTemplate
-- MUST be omitted in all other messages
-- See [RFC9480].
CertProfileValue REQUIRED
-- MUST contain a sequence of one UTF8String element
-- MUST contain the name of a certificate profile
This section describes the generic protection field contents of all CMP messages. For signature-based protection, which is the default protection mechanism for all CMP messages described in this profile, the CMP protection key and CMP protection certificate are used. For MAC-based protection, shared secret information is used as described in Section 4.1.5.
このセクションでは、すべてのCMPメッセージの一般的な保護フィールドの内容について説明します。このプロファイルで説明されているすべてのCMPメッセージのデフォルト保護メカニズムである署名ベースの保護のために、CMP保護キーとCMP保護証明書が使用されます。Macベースの保護のために、セクション4.1.5で説明されているように、共有秘密情報が使用されます。
protection
-- If present, the same kind of protection MUST be used for all
-- messages of that PKI management operation.
-- MUST be present, except if protection is not possible for
-- error messages as described in Section 3.6.4
-- For signature-based protection, MUST contain the signature
-- calculated using the CMP protection key of the entity
-- protecting the message
-- For MAC-based protection, MUST contain a MAC calculated using
-- the shared secret information
-- The protection algorithm used MUST be given in the
-- protectionAlg field.
The CMP message protection provides, if available, message origin authentication and integrity protection for the header and body. The CMP message extraCerts field is not covered by this protection.
CMPメッセージ保護は、利用可能な場合、ヘッダーとボディのメッセージ起源認証と整合性保護を提供します。CMPメッセージExtracertsフィールドは、この保護によってカバーされていません。
Note: The extended key usages described in Section 2.2 of CMP Updates [RFC9480] can be used for authorization of a sending PKI management entity.
注：CMP更新のセクション2.2で説明されている拡張された主要な使用法[RFC9480]を使用して、送信PKI管理エンティティの承認に使用できます。
This section describes the generic extraCerts field of all CMP messages. Any specific requirements on the extraCerts are specified in the respective PKI management operation.
このセクションでは、すべてのCMPメッセージの一般的なエクストラセルトフィールドについて説明します。エクストラメートに関する特定の要件は、それぞれのPKI管理操作で指定されています。
extraCerts
-- MUST be present for signature-based protection and contain the
-- CMP protection certificate together with its chain for the
-- first request and response message of a PKI management
-- operation. MAY be omitted in certConf, PKIConf, pollReq,
-- and pollRep messages. The first certificate in this field
-- MUST be the CMP protection certificate followed by its
-- chain, where each element should directly certify the one
-- immediately preceding it.
-- MUST be present in ip, cp, and kup messages and contain the
-- chain of a newly issued certificate.
-- Self-signed certificates should be omitted from extraCerts and
-- MUST NOT be trusted based on their inclusion in any case
Note: One reason for adding a self-signed certificate to extraCerts is if it is the CMP protection certificate or a successor root CA self-signed certificate as indicated in the HashOfRootKey extension of the current root CA certificate; see [RFC8649]. Another reason for including self-signed certificates in the extraCerts is, for instance, due to storage limitations. A receiving PKI entity may not have the complete trust anchor information available but just a unique identification of it and thus needs the full trust anchor information carried in a self-signed certificate for further processing (see Section 9).
注：自己署名証明書をエクストラメートに追加する理由の1つは、CMP保護証明書または現在のルートCA証明書のHashofrootkey拡張に示されている後継者ルートCAの自己署名証明書であるかどうかです。[RFC8649]を参照してください。エクストラメートに自己署名証明書を含めるもう1つの理由は、たとえばストレージの制限によるものです。受信PKIエンティティには、完全な信頼アンカー情報が利用可能ではなく、それの独自の識別だけであるため、さらに処理するために自己署名証明書にある完全な信頼アンカー情報が必要です（セクション9を参照）。
For maximum interoperability, all implementations SHOULD be prepared to handle potentially additional certificates and arbitrary orderings of the certificates.
最大限の相互運用性のために、すべての実装を、潜在的に追加の証明書と証明書の任意の注文を処理するために準備する必要があります。
This subsection describes what is generally needed by the PKI entities to be able to perform PKI management operations.
このサブセクションでは、PKI管理オペレーションを実行できるためにPKIエンティティが一般的に必要とするものについて説明します。
Identification of PKI entities:
PKIエンティティの識別：
* For signature-based protection, each EE knows its own identity from the CMP protection certificate; for MAC-based protection, it MAY know its identity to fill the sender field.
* 署名ベースの保護のために、各EEはCMP保護証明書から独自のアイデンティティを知っています。Macベースの保護のために、送信者フィールドを埋めるためのアイデンティティを知っているかもしれません。
* Each EE MAY know the intended recipient of its requests to fill the recipient field, e.g., the name of the addressed CA.
* 各EEは、受信者フィールドを埋めるという要求の意図した受信者を知っている場合があります。
* Note: This name may be established using an enrollment voucher (as described in [RFC8366]), the issuer field from a CertReqTemplate response message content, or by other configuration means.
* 注：この名前は、登録バウチャー（[RFC8366]に記載されている）、certreqtemplate応答メッセージコンテンツからの発行者フィールド、またはその他の構成手段を使用して確立できます。
Routing of CMP messages:
CMPメッセージのルーティング：
* Each PKI entity sending messages upstream MUST know the address needed for transferring messages to the next PKI management entity in case online transfer is used.
* 上流のメッセージを送信する各PKIエンティティは、オンライン転送が使用された場合に、メッセージを次のPKI管理エンティティに転送するために必要なアドレスを知っている必要があります。
* Note: This address may depend on the recipient, the certificate profile, and the used transfer mechanism.
* 注：このアドレスは、受信者、証明書プロファイル、および使用済み転送メカニズムに依存する場合があります。
Authentication of PKI entities:
PKIエンティティの認証：
* Each PKI entity MUST have credentials to authenticate itself. For signature-based protection, it MUST have a private key and the corresponding certificate along with its chain.
* 各PKIエンティティには、認証するための資格情報が必要です。署名ベースの保護のためには、秘密キーとそのチェーンとともに対応する証明書が必要です。
* Each PKI entity MUST be able to establish trust in the PKI it receives responses from. When signature-based protection is used, it MUST have the trust anchor(s) and any certificate status information needed to perform path validation of CMP protection certificates used for signature-based protection.
* 各PKIエンティティは、回答を受け取るPKIに対する信頼を確立できる必要があります。署名ベースの保護が使用される場合、信頼できるアンカーと、署名ベースの保護に使用されるCMP保護証明書のパス検証を実行するために必要な証明書ステータス情報が必要です。
* Note: A trust anchor is usually a root certificate of the PKI addressed by the requesting EE. It may be established by configuration or in an out-of-band manner. For an EE, it may be established using an enrollment voucher [RFC8366] or in-band of CMP by the caPubs field in a certificate response message.
* 注：トラストアンカーは通常、要求するEEによって対処されたPKIのルート証明書です。構成によって、または帯域外で確立される場合があります。EEの場合、登録バウチャー[RFC8366]またはCAPUBSフィールドによってCMPの帯域帯域を使用して、証明書応答メッセージで確立できます。
Authorization of PKI management operations:
PKI管理操作の承認：
* Each EE or RA MUST have sufficient information to be able to authorize the PKI management entity to perform the upstream PKI management operation.
* 各EEまたはRAには、上流のPKI管理操作を実行するためにPKI管理エンティティを承認できるように十分な情報が必要です。
* Note: This may be achieved, for example, by using the cmcRA extended key usage in server certificates, by local configuration (such as specific name patterns for subject Distinguished Name (DN) or Subject Alternative Name (SAN) portions that may identify an RA) and/or by having a dedicated root CA usable only for authenticating PKI management entities.
* 注：これは、たとえば、サーバー証明書のCMCRA拡張キー使用量を使用して、ローカル構成によって達成される場合があります（被験者の著名な名前（DN）または件名代替名（SAN）部分の特定の名前パターンなど、RAを識別する可能性のある部分など）および/または、PKI管理エンティティを認証するためにのみ使用可能な専用ルートCAを使用することにより。
* Each PKI management entity MUST have sufficient information to be able to authorize the downstream PKI entity requesting the PKI management operation.
* 各PKI管理エンティティには、PKI管理操作を要求する下流のPKIエンティティを承認できるほど十分な情報が必要です。
* Note: For authorizing an RA, the same examples apply as above. The authorization of EEs can be very specific to the application domain based on local PKI policy.
* 注：RAを承認するには、上記と同じ例が適用されます。EEの承認は、ローカルPKIポリシーに基づいてアプリケーションドメインに非常に固有のものです。
This section describes generic validation steps of each PKI entity receiving a PKI request or response message before any further processing or forwarding. If a PKI management entity decides to terminate a PKI management operation because a check failed, it MUST send a negative response or an error message as described in Section 3.6. The PKIFailureInfo bits given below in parentheses MAY be used in the failInfo field of the PKIStatusInfo as described in Section 3.6.4; also see Appendix F of [RFC4210].
このセクションでは、さらに処理または転送する前にPKI要求または応答メッセージを受信する各PKIエンティティの一般的な検証手順について説明します。PKI管理エンティティがチェックに失敗したためにPKI管理操作を終了することを決定した場合、セクション3.6で説明されているように、否定的な応答またはエラーメッセージを送信する必要があります。括弧内に記載されているpkifailureinfoビットは、セクション3.6.4で説明されているように、pkistatusinfoの故障フィールドで使用できます。[RFC4210]の付録Fも参照してください。
All PKI message header fields not mentioned in this section, like the recipient and generalInfo fields, SHOULD be handled gracefully upon receipt.
このセクションで言及されていないすべてのPKIメッセージヘッダーフィールドは、受信者やgeneralInfoフィールドと同様に、受領時に優雅に処理する必要があります。
The following list describes the basic set of message input validation steps. Without these checks, the protocol becomes dysfunctional.
次のリストでは、メッセージ入力検証手順の基本セットについて説明します。これらのチェックがなければ、プロトコルは機能不全になります。
* The formal ASN.1 syntax of the whole message MUST be compliant with the definitions given in CMP [RFC4210] [RFC9480], CRMF [RFC4211], and CMS [RFC5652] [RFC8933]. (failInfo: badDataFormat)
* メッセージ全体の正式なASN.1構文は、CMP [RFC4210] [RFC9480]、CRMF [RFC4211]、およびCMS [RFC5652] [RFC8933]に与えられた定義に準拠している必要があります。（failinfo：baddataformat）
* The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: unsupportedVersion)
* PVNOはCMP2000（2）またはCMP2021（3）でなければなりません。（FailInfo BIT：サポートされていないバイオン）
* The transactionID MUST be present. (failInfo bit: badDataFormat)
* TransactionIDが存在する必要があります。（failinfo bit：baddataformat）
* The PKI message body type MUST be one of the message types supported by the receiving PKI entity and MUST be allowed in the current state of the PKI management operation identified by the given transactionID. (failInfo bit: badRequest)
* PKIメッセージのボディタイプは、受信PKIエンティティによってサポートされるメッセージタイプの1つでなければならず、指定されたTransactionIDによって特定されたPKI管理操作の現在の状態で許可されなければなりません。（failinfo bit：badrequest）
The following list describes the set of message input validation steps required to ensure secure protocol operation:
次のリストでは、安全なプロトコル操作を確保するために必要なメッセージ入力検証手順のセットについて説明します。
* The senderNonce MUST be present and MUST contain at least 128 bits of data. (failInfo bit: badSenderNonce)
* Sendernonceは存在する必要があり、少なくとも128ビットのデータを含める必要があります。（failinfo bit：badsendernonce）
* Unless the PKI message is the first message of a PKI management operation,
* PKIメッセージがPKI管理操作の最初のメッセージでない限り、
- the recipNonce MUST be present and MUST equal the senderNonce of the previous message or equal the senderNonce of the most recent request message for which the response was delayed, in case of delayed delivery as specified in Section 4.4. (failInfo bit: badRecipientNonce)
- Recistnonceは存在する必要があり、セクション4.4で指定されているように配信が遅れた場合、以前のメッセージのSendernonceまたは応答が遅延した最新の要求メッセージのSendernonceに等しくなければなりません。（failinfo bit：badrecipientnonce）
* Messages without protection MUST be rejected except for error messages as described in Section 3.6.4.
* セクション3.6.4で説明されているように、エラーメッセージを除き、保護のないメッセージを拒否する必要があります。
* The message protection MUST be validated when present, and messages with an invalid protection MUST be rejected.
* メッセージ保護は存在するときに検証する必要があり、無効な保護を持つメッセージを拒否する必要があります。
- The protection MUST be signature-based except if MAC-based protection is used as described in Sections 4.1.5 and 4.1.6.3. (failInfo bit: wrongIntegrity)
- セクション4.1.5および4.1.6.3で説明されているように、MACベースの保護が使用される場合を除き、保護は署名ベースでなければなりません。（failinfo bit：誤解）
- If present, the senderKID MUST identify the key material needed for verifying the message protection. (failInfo bit: badMessageCheck)
- 存在する場合、SenderKidはメッセージ保護を確認するために必要な重要な資料を特定する必要があります。（failinfo bit：badmessagecheck）
- If signature-based protection is used, the CMP protection certificate MUST be successfully validated, including path validation using a trust anchor, and MUST be authorized according to local policies. If the keyUsage extension is present in the CMP protection certificate, the digitalSignature bit MUST be set. (failInfo bit: badAlg, badMessageCheck, or signerNotTrusted)
- 署名ベースの保護が使用されている場合、信頼アンカーを使用したパス検証など、CMP保護証明書を正常に検証する必要があり、ローカルポリシーに従って承認されなければなりません。KMP保護証明書にKeyUSAGE拡張が存在する場合、DigitalSignatureビットを設定する必要があります。（failinfo bit：badalg、badmessagecheck、またはsignernottrusted）
- The sender of a request message MUST be authorized to request the operation according to PKI policies. (failInfo bit: notAuthorized)
- リクエストメッセージの送信者は、PKIポリシーに従って操作を要求することを許可する必要があります。（failinfo bit：notauthorized）
Note: The requirements for checking certificates given in [RFC5280] MUST be followed for signature-based CMP message protection. Unless the message is a positive ip/cp/kup, where the issuing CA certificate of the newly enrolled certificate is the same as the CMP protection certificate of that message, certificate status checking SHOULD be performed on the CMP protection certificates. If the response message contains the caPubs field to transfer new trust anchor information, the CMP protection is crucial and certificate status checking is REQUIRED. For other cases, it MAY be acceptable to omit certificate status checking when respective information is not available.
注：署名ベースのCMPメッセージ保護のために、[RFC5280]で指定された証明書をチェックする要件に従う必要があります。メッセージが正のIP/CP/KUPでない限り、新しく登録された証明書の発行CA証明書がそのメッセージのCMP保護証明書と同じである場合、CMP保護証明書で証明書のステータスチェックを実行する必要があります。応答メッセージに新しい信頼アンカー情報を転送するためにCapubsフィールドが含まれている場合、CMP保護が重要であり、証明書のステータスチェックが必要です。他のケースでは、それぞれの情報が利用できない場合、証明書ステータスチェックを省略することは許容される場合があります。
Depending on local policies, one or more of the input validation checks described below need to be implemented:
ローカルポリシーに応じて、以下に説明する入力検証チェックの1つ以上を実装する必要があります。
* If signature-based protection is used, the sender field MUST match the subject of the CMP protection certificate. (failInfo bit: badMessageCheck)
* 署名ベースの保護が使用される場合、送信者フィールドはCMP保護証明書の主題と一致する必要があります。（failinfo bit：badmessagecheck）
* If the messageTime is present and
* メッセージが存在する場合
- the receiving system has a reliable system time, the messageTime MUST be close to the current time of the receiving system, where the threshold will vary by use case. (failInfo bit: badTime)
- 受信システムには信頼できるシステム時間があり、メッセージは受信システムの現在の時刻に近く、しきい値はユースケースによって異なります。（failinfoビット：悪い時間）
- the receiving system does not have a reliable system time, the messageTime MAY be used for time synchronization.
- 受信システムには信頼できるシステム時間がありません。MessageTimeは、時間同期に使用できます。
This section describes how a PKI entity handles error conditions on messages it receives. Each error condition should be logged appropriately to allow root-cause analysis of failure cases.
このセクションでは、PKIエンティティが受信するメッセージのエラー条件を処理する方法について説明します。各エラー条件を適切に記録して、障害ケースのルート原因分析を可能にする必要があります。
An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in the upstream direction either.
EEはエラーメッセージを送信してはなりません。PKI管理エンティティは、上流の方向にエラーメッセージを送信してはなりません。
In case an EE rejects a newly issued certificate contained in an ip, cp, or kup message and implicit confirmation has not been granted, the EE MUST report this using a certConf message with "rejection" status and await the pkiConf response as described in Section 4.1.1.
EEがIP、CP、またはKUPメッセージに含まれる新たに発行された証明書を拒否した場合、暗黙の確認は付与されていません。EEは、「拒否」ステータスを持つ証明書メッセージを使用してこれを報告し、セクションで説明したようにPKICONF応答を待つ必要があります。4.1.1。
On all other error conditions regarding response messages, the EE or PKI management entity MUST regard the current PKI management operation as terminated with failure. The error conditions include:
応答メッセージに関する他のすべてのエラー条件では、EEまたはPKI管理エンティティは、現在のPKI管理操作を障害とともに終了したと見なす必要があります。エラー条件には以下が含まれます。
* invalid response message header, body type, protection, or extraCerts, according to the checks described in Section 3.5,
* セクション3.5で説明されているチェックに従って、無効な応答メッセージヘッダー、ボディタイプ、保護、またはエクストラアセート
* any issue detected with response message contents,
* 応答メッセージの内容で検出された問題、
* receipt of an error message from upstream,
* 上流からのエラーメッセージの受信、
* timeout occurred while waiting for a response, and
* 応答を待っている間にタイムアウトが発生しました
* rejection of a newly issued certificate while implicit confirmation has been granted.
* 暗黙の確認が付与されている間、新たに発行された証明書の拒否が認められています。
Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. The value set for such timeouts will vary by use case. Then they MUST also regard the current PKI management operation as terminated with failure and MUST NOT attempt to send an error message downstream.
上流のPKI管理エンティティは、PKI管理操作が終了したことを知るためのCMPメッセージを受け取りません。EEからのさらなるメッセージが期待される場合、接続の中断またはタイムアウトが発生します。このようなタイムアウトに設定された値は、ユースケースによって異なります。また、現在のPKI管理操作を障害とともに終了したと見なす必要があり、下流のエラーメッセージを送信しようとしてはなりません。
In case the PKI management entity detects an error condition, e.g., rejecting the request due to policy decision, in the body of an ir, cr, p10cr, kur, or rr message received from downstream, it MUST report the error in the specific response message, i.e., an ip, cp, kup, or rp with "rejection" status, as described in Sections 4.1.1 and 4.2. This can also happen in case of polling.
PKI管理エンティティがエラー条件を検出した場合、たとえば、ポリシー決定による要求を拒否し、IR、CR、P10CR、KUR、または下流から受信したRRメッセージの本文で、特定の応答のエラーを報告する必要がありますメッセージ、つまり、セクション4.1.1および4.2で説明されているように、「拒絶」ステータスのIP、CP、KUP、またはRP。これは、ポーリングの場合にも発生する可能性があります。
In case the PKI management entity detects any other error condition on requests (including pollReq, certConf, genm, and nested messages) received from downstream and on responses received from upstream (such as invalid message header, body type, protection, or extraCerts, according to the checks described in Section 3.5), it MUST report them downstream in the form of an error message as described in Section 3.6.4.
PKI管理エンティティが、下流から受け取ったリクエスト（Pollreq、certconf、genm、およびネストされたメッセージを含む）および上流から受け取った応答（無効なメッセージヘッダー、ボディタイプ、保護、またはエキストラメントなど、リクエスト（Pollreq、certconf、genm、およびネストされたメッセージを含む）が他のエラー条件を検出した場合、セクション3.5で説明したチェックに）、セクション3.6.4で説明されているように、エラーメッセージの形で下流に報告する必要があります。
Batching of messages using nested messages as described in Section 5.2.2.2 requires special error handling.
セクション5.2.2.2で説明されているように、ネストされたメッセージを使用したメッセージのバッチングには、特別なエラー処理が必要です。
If the error condition is on an upstream nested message containing batched requests, it MUST NOT attempt to respond to the individual requests included in it but to the nested message itself.
エラー条件がバッチリクエストを含む上流のネストメッセージにある場合、それに含まれる個々のリクエストではなく、ネストされたメッセージ自体に応答しないようにしてください。
In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.
PKI管理エンティティがネストされたメッセージに応じてエラーメッセージを受信した場合、ネストされたメッセージに含まれる各リクエストメッセージにエラーメッセージで応答することにより、エラーを伝播する必要があります。
In case a PKI management entity detects an error condition on the downstream nested message received in response to a nested message sent before and the body of the received nested message still parses, it MAY ignore this error condition and handle the included responses as described in Section 5.2.2.2. Otherwise, it MUST propagate the error by responding with an error message to each of the requests contained in the nested message it sent originally.
PKI管理エンティティが、前に送信されたネストされたメッセージに応じて受信した下流のネストされたメッセージのエラー条件を検出し、受け取ったネストされたメッセージの本文がまだ解析された場合、このエラー条件を無視し、セクションで説明したように含まれる応答を処理する可能性があります。5.2.2.2。それ以外の場合は、元々送信したネストされたメッセージに含まれる各リクエストにエラーメッセージで応答することにより、エラーを伝播する必要があります。
When sending any kind of negative response, including error messages, a PKI entity MUST indicate the error condition in the PKIStatusInfo structure of the respective message as described below. Then it MUST regard the current PKI management operation as terminated with failure.
エラーメッセージを含むあらゆる種類の否定的な応答を送信する場合、PKIエンティティは、以下に説明するように、それぞれのメッセージのpkistatusinfo構造のエラー条件を示す必要があります。次に、現在のPKI管理操作を障害とともに終了したと見なす必要があります。
The PKIStatusInfo structure is used to report errors. It may be part of various message types, in particular, ip, cp, kup, certConf, and error. The PKIStatusInfo structure consists of the following fields:
pkistatusinfo構造は、エラーを報告するために使用されます。これは、特にIP、CP、KUP、CERTCONF、およびエラーのさまざまなメッセージタイプの一部である可能性があります。pkistatusinfo構造は、次のフィールドで構成されています。
status:
状態：
Here, the PKIStatus value "rejection" MUST be used in case an error was detected. When a PKI management entity indicates delayed delivery of a CMP response message to the EE with an error message as described in Section 4.4, the status "waiting" MUST be used there.
ここでは、エラーが検出された場合に、pkistatus値「拒否」を使用する必要があります。PKI管理エンティティが、セクション4.4で説明されているようにエラーメッセージを使用してEEへのCMP応答メッセージの遅延配信を示す場合、ステータス「待機」をそこで使用する必要があります。
statusString:
スタトゥスリング：
Here, any human-readable valid value for logging or to display via a user interface should be added.
ここでは、ロギングまたはユーザーインターフェイスを介して表示するための人間の読み取り可能な有効な値を追加する必要があります。
failInfo:
failinfo：
badCertId:
badcertid：
A kur, certConf, or rr message references an unknown certificate.
KUR、CERTCONF、またはRRメッセージは、未知の証明書を参照しています。
badPOP:
バッドポップ：
An ir/cr/kur/p10cr contains an invalid proof-of-possession.
IR/CR/KUR/P10CRには、無効なプルーフオブポッセッションが含まれています。
certRevoked:
certrevoked：
Revocation is requested for a certificate that is already revoked.
すでに取り消されている証明書の取り消しは要求されます。
badCertTemplate:
badcerttemplate：
The contents of a certificate request are not accepted, e.g., a field is missing or has an unacceptable value or the given public key is already in use in some other certificate (depending on policy).
証明書要求の内容は受け入れられません。たとえば、フィールドが欠落しているか、容認できない値を持っているか、特定の公開キーが他の証明書ですでに使用されています（ポリシーに応じて）。
transactionIdInUse:
TransactionIdinuse：
This is sent by a PKI management entity in case the received request contains a transactionID that is currently in use for another transaction. An EE receiving such an error message should resend the request in a new transaction using a different transactionID.
これは、受信したリクエストに別のトランザクションに現在使用されているTransactionIDが含まれている場合に備えて、PKI管理エンティティによって送信されます。このようなエラーメッセージを受信するEEは、異なるトランザクションIDを使用して新しいトランザクションでリクエストを再送信する必要があります。
notAuthorized:
許可されていません：
The sender of a request message is not authorized for requesting the operation.
リクエストメッセージの送信者は、操作の要求を許可されていません。
systemUnavail:
SystemUnavail：
This is sent by a PKI management entity in case a back-end system is not available.
これは、バックエンドシステムが利用できない場合に備えて、PKI管理エンティティによって送信されます。
systemFailure:
SystemFailure：
This is sent by a PKI management entity in case a back-end system is currently not functioning correctly.
これは、バックエンドシステムが現在正しく機能していない場合に備えて、PKI管理エンティティによって送信されます。
Here, the PKIFailureInfo bits MAY be used in the way explained in Appendix F of [RFC4210]. PKIFailureInfo bits regarding the validation described in Section 3.5 are referenced there. The PKIFailureInfo bits referenced in Sections 5.1 and 6 are described here: badCertId: A kur, certConf, or rr message references an unknown certificate. badPOP: An ir/cr/kur/p10cr contains an invalid proof-of-possession. certRevoked: Revocation is requested for a certificate that is already revoked. badCertTemplate: The contents of a certificate request are not accepted, e.g., a field is missing or has an unacceptable value or the given public key is already in use in some other certificate (depending on policy). transactionIdInUse: This is sent by a PKI management entity in case the received request contains a transactionID that is currently in use for another transaction. An EE receiving such an error message should resend the request in a new transaction using a different transactionID. notAuthorized: The sender of a request message is not authorized for requesting the operation. systemUnavail: This is sent by a PKI management entity in case a back-end system is not available. systemFailure: This is sent by a PKI management entity in case a back-end system is currently not functioning correctly.
ここでは、[RFC4210]の付録Fで説明されている方法で、pkifailureinfoビットを使用できます。セクション3.5で説明されている検証に関するpkifailureinfoビットは、そこで参照されます。セクション5.1および6で参照されているPKifailureInfoビットは、ここで説明します：badcertid：a kur、certconf、またはrrメッセージは未知の証明書を参照します。バッドポップ：IR/CR/KUR/P10CRには、無効なプルーフオブポッセッションが含まれています。Certrevoked：すでに取り消されている証明書の取り消しは要求されます。badcerttemplate：証明書要求の内容は受け入れられません。たとえば、フィールドが欠落しているか、容認できない値を持っているか、特定の公開キーが他の証明書ですでに使用されています（ポリシーに応じて）。TransactionIdinuse：これは、受信したリクエストに別のトランザクションに現在使用されているTransactionIDが含まれている場合に備えて、PKI管理エンティティによって送信されます。このようなエラーメッセージを受信するEEは、異なるトランザクションIDを使用して新しいトランザクションでリクエストを再送信する必要があります。notouthorized：リクエストメッセージの送信者は、操作の要求を許可されていません。SystemUnavail：これは、バックエンドシステムが利用できない場合に備えて、PKI管理エンティティによって送信されます。SystemFailure：これは、バックエンドシステムが現在正しく機能していない場合に備えて、PKI管理エンティティによって送信されます。
An EE receiving a systemUnavail or systemFailure failInfo should resend the request in a new transaction after some time.
SystemUnavailまたはSystemFailure FailInfoを受信するEEは、しばらくして新しいトランザクションでリクエストを再送信する必要があります。
Detailed Message Description:
詳細なメッセージ説明：
Error Message -- error
Field Value
header
-- As described in Section 3.1
body
-- The message indicating the error that occurred
error REQUIRED
pKIStatusInfo REQUIRED
status REQUIRED
-- MUST have the value "rejection"
statusString OPTIONAL
-- This field should contain any human-readable text for
-- debugging, for logging, or to display in a GUI
failInfo OPTIONAL
-- MAY be present and contain the relevant PKIFailureInfo bits
protection RECOMMENDED
-- As described in Section 3.2
extraCerts RECOMMENDED
-- As described in Section 3.3
Protecting the error message may not be technically feasible if it is not clear which credential the recipient will be able to use when validating this protection, e.g., in case the request message was fundamentally broken. In these exceptional cases, the protection of the error message MAY be omitted.
エラーメッセージの保護は、この保護を検証するときに受信者がどの資格情報を使用できるかが明らかでない場合、たとえば、要求メッセージが根本的に壊れた場合に、技術的に実行不可能である可能性があります。これらの例外的な場合、エラーメッセージの保護は省略できます。
This section focuses on the communication of an EE with the PKI management entity it directly talks to. Depending on the network and PKI solution, this can be an RA or directly a CA. Handling of a message by a PKI management entity is described in Section 5.
このセクションでは、EEと直接話し合うPKI管理エンティティとの通信に焦点を当てています。ネットワークとPKIソリューションに応じて、これはRAまたは直接caです。PKI管理エンティティによるメッセージの処理については、セクション5で説明します。
The PKI management operations specified in this section cover the following:
このセクションで指定されているPKI管理操作は、以下をカバーしています。
* requesting a certificate with variations like initial enrollment, certificate updates, central key generation, and MAC-based protection
* 初期登録、証明書の更新、セントラルキー生成、Macベースの保護などのバリエーションの証明書を要求する
* revoking a certificate
* 証明書を取り消す
* support messages
* サポートメッセージ
* polling for delayed response messages
* 遅延応答メッセージのポーリング
These operations mainly specify the message body of the CMP messages and utilize the specification of the message header, protection, and extraCerts, as specified in Section 3. The messages are named by the respective field names in PKIBody, like ir, ip, cr, cp, etc.; see Section 5.1.2 of [RFC4210].
これらの操作は、主にCMPメッセージのメッセージ本文を指定し、セクション3で指定されているように、メッセージヘッダー、保護、およびエクストラメートの仕様を利用します。メッセージは、IR、IP、CrなどのPkibodyのそれぞれのフィールド名によって命名されます。CPなど。[RFC4210]のセクション5.1.2を参照してください。
The following diagram shows the EE state machine covering all PKI management operations described in this section, including negative responses, error messages described in Section 3.6.4, ip/cp/kup/error messages with status "waiting", and pollReq and pollRep messages as described in Section 4.4.
次の図は、ネガティブ応答、セクション3.6.4で説明されているエラーメッセージ、ステータス「待機」を伴うIP/CP/KUP/エラーメッセージ、PollreqおよびPollrepメッセージなど、このセクションで説明するすべてのPKI管理操作をカバーするEEステートマシンを示しています。セクション4.4で説明されているように。
On receiving messages from upstream, the EE MUST perform the general validation checks described in Section 3.5. In case an error occurs, the behavior is described in Section 3.6.
上流からメッセージを受信すると、EEはセクション3.5で説明した一般的な検証チェックを実行する必要があります。エラーが発生した場合、動作はセクション3.6で説明されています。
End Entity State Machine:
エンティティステートマシンの終了：
start
|
| send ir/cr/kur/p10cr/rr/genm
v
waiting for response
v
+--------------------------+--------------------------+
| | |
| receives ip/cp/kup with | received ip/cp/kup/error | received
| status "accepted" or | with status "waiting" | rp/genp or
| "grantedWithMods" | | ip/cp/kup/
| v | error
| +-------> polling | with status
| | | | "rejection"
| | received | send |
| | pollRep | pollReq |
| | v |
| | waiting for response |
| | v |
| +------------+--------+ |
| | | |
| received ip/cp/kup | | received |
| with status "accepted" | | rp/genp or |
| or "grantedWithMods" | | ip/cp/kup/error |
| | | with status |
+---------->+<-------------+ | "rejection" |
v | |
+-----------+-----+ | |
| | | |
| implicitConfirm | implicitConfirm | |
| granted | not granted | |
| | | |
| | send certConf | |
| v | |
| waiting for pkiConf*) | |
| | | |
| | received | |
| v pkiConf v |
+---------------->+------->+<-------+<----------------+
|
v
end
*)
*）
In case of a delayed delivery of pkiConf responses, the same polling mechanism is initiated as for rp or genp messages by sending an error message with status "waiting".
PKICONF応答の配信が遅れた場合、ステータス「待機」のあるエラーメッセージを送信することにより、RPまたはGENPメッセージと同じポーリングメカニズムが開始されます。
Note: All CMP messages belonging to the same PKI management operation MUST have the same transactionID because the message receiver identifies the elements of the operation in this way.
注：メッセージ受信機がこの方法で操作の要素を識別するため、同じPKI管理操作に属するすべてのCMPメッセージには同じトランザクションIDが必要です。
This section is aligned with CMP [RFC4210], CMP Updates [RFC9480], and CMP Algorithms [RFC9481].
このセクションは、CMP [RFC4210]、CMPの更新[RFC9480]、およびCMPアルゴリズム[RFC9481]と整合しています。
Guidelines as well as an algorithm use profile for this document are available in CMP Algorithms [RFC9481].
このドキュメントのガイドラインとアルゴリズムの使用プロファイルは、CMPアルゴリズム[RFC9481]で利用できます。
There are various approaches for requesting a certificate from a PKI.
PKIから証明書を要求するためのさまざまなアプローチがあります。
These approaches differ in the way the EE authenticates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as follows:
これらのアプローチは、EEが使用される要求の形でPKIに認証する方法、および認定されるキーペアの生成方法によって異なります。認証メカニズムは次のとおりです。
* using a certificate from an external PKI, e.g., a manufacturer-issued device certificate, and the corresponding private key
* 外部PKIからの証明書を使用する、たとえばメーカーが発行したデバイス証明書、および対応する秘密鍵を使用する
* using a private key and certificate issued from the same PKI that is addressed for requesting a certificate
* 証明書を要求するために対処された同じPKIから発行された秘密鍵と証明書を使用する
* using the certificate to be updated and the corresponding private key
* 更新する証明書を使用し、対応する秘密鍵
* using shared secret information known to the EE and the PKI management entity
* EEおよびPKI管理エンティティに知られている共有秘密情報を使用する
An EE requests a certificate indirectly or directly from a CA. When the PKI management entity handles the request as described in Section 5.1.1 and responds with a message containing the requested certificate, the EE MUST reply with a confirmation message unless implicitConfirm was granted. The PKI management entity MUST then handle it as described in Section 5.1.2 and respond with a confirmation, closing the PKI management operation.
EEは、CAから間接的または直接証明書を要求します。PKI管理エンティティがセクション5.1.1で説明されているようにリクエストを処理し、要求された証明書を含むメッセージで応答する場合、EEは、暗黙のコントリルムが付与されない限り、確認メッセージで返信する必要があります。次に、PKI管理エンティティは、セクション5.1.2で説明されているようにそれを処理し、確認で応答し、PKI管理操作を終了する必要があります。
The message sequences described in this section allow the EE to request certification of a locally or centrally generated public-private key pair. The public key and the subject name identifying the EE MUST be present in the certTemplate of the certificate request message.
このセクションで説明したメッセージシーケンスにより、EEはローカルまたは中央生成された官民性キーペアの認証を要求できます。EEを識別する公開鍵と件名は、証明書要求メッセージの証明書に存在する必要があります。
Note: If the EE does not know for which subject name to request the certificate, it can use the subject name from the CMP protection certificate in case of signature-based protection or the identifier of the shared secret in case of MAC-based protection.
注：EEが証明書を要求する件名名がわからない場合、署名ベースの保護の場合、またはMACベースの保護の場合に共有秘密の識別子の場合、CMP保護証明書のサブジェクト名を使用できます。
Typically, the EE provides a signature-based proof-of-possession of the private key associated with the public key contained in the certificate request, as defined by [RFC4211], Section 4.1, clause 3. To this end, it is assumed that the private key can technically be used for signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA, regardless of potentially intended restrictions of the key usage.
通常、EEは、[RFC4211]、セクション4.1、条項3で定義されているように、証明書リクエストに含まれる公開キーに関連付けられた秘密鍵の署名ベースのプルーフの署名ベースの入金を提供します。秘密鍵は、技術的に署名に使用できます。これは、主要な使用法の潜在的に意図された制限に関係なく、最も一般的なアルゴリズムRSA、ECDSA、およびEDDSAの場合です。
Note: Section 4 of [RFC4211] allows for providing proof-of-possession using any method that a key can be used for. In conformance with Section 8.1.5.1.1.2 of [NIST.SP.800-57p1r5], the newly generated private key may be used for self-signature, if technically possible, even if the keyUsage extension requested in the certificate request prohibits generation of digital signatures.
注：[RFC4211]のセクション4では、キーを使用できる方法を使用して、プルーフオブポッセッションを提供できます。[nist.sp.800-57p1R5]のセクション8.1.5.1.1.2に準拠している場合、証明書リクエストで要求されたキーユーザー拡張が生成を禁止する場合でも、技術的に可能であれば、新しく生成された秘密鍵は、技術的に可能であれば自己署名に使用できます。デジタル署名。
The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request message containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions.
要求するEEは、そのPOPを含むCMPリクエストメッセージの署名ベースまたはMacベースの保護により、その身元の証明の拘束力を提供します。上流のPKI管理エンティティは、このEEが要求されたサブジェクトおよびその他のフィールドおよび拡張機能を使用して証明書を取得することを許可されているかどうかを確認する必要があります。
The proof-of-possession is provided by signing the certReq containing the certTemplate with the subject name and public key. To bind this proof-of-possession to the proof-of-identity of the requesting EE, the subject name in the certTemplate needs to identify the same entity as the subject name in the CMP protection certificate or match the identifier used with MAC-based protection.
プルーフオブポッセッションは、certreqに件名と公開キーを含むcertreqに署名することにより提供されます。この所有の証明を要求のEEの証明に結合するには、CERTTEMPLATEの件名は、CMP保護証明書の主題名と同じエンティティを識別するか、MACベースの識別子と一致する必要があります。保護。
Note: This binding may be lost if a PKI management entity reprotects this request message.
注：PKI管理エンティティがこのリクエストメッセージを再検討すると、このバインディングが失われる場合があります。
The EE MAY indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message as described in Section 3.1.
EEは、セクション3.1で説明されているように、証明書リクエストメッセージのPKIHeaderにあるGeneralINFOフィールドの証明書プロファイルを使用する証明書プロファイルを示している場合があります。
In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it MUST properly authenticate the message and authorize the sender as a trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an Initialization Response (ip) message. Authorization can also be signature-based, using a certificate issued by another PKI that is explicitly authorized for this purpose. A certificate received in caPubs MUST NOT be accepted as a trust anchor if it is the root CA certificate of the certificate used for protecting the message.
EEが新しいトラストアンカーとしてインストールするためにCapubsフィールドにCA証明書を受け取った場合、メッセージを適切に認証し、送信者を新しいトラストアンカーの信頼できるソースとして承認する必要があります。この承認は、通常、初期化応答（IP）メッセージを保護するための共有秘密情報を使用して示されます。また、この目的のために明示的に許可されている別のPKIによって発行された証明書を使用して、承認を署名ベースにすることもできます。キャプブで受け取った証明書は、メッセージの保護に使用される証明書のルートCA証明書である場合、信託アンカーとして受け入れられてはなりません。
This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e.g., a manufacturer-issued IDevID certificate [IEEE.802.1AR_2018], to authenticate itself to the new PKI.
このPKI管理操作は、EEが外部PKIからの既存の証明書を使用して新しいPKIから証明書を要求するために使用する必要があります。
Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI" [BRSKI-AE] describes a generalization regarding enrollment protocols alternative to EST [RFC7030]. As replacement of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapping LDevID certificates.
注：ブートストラップリモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]環境、「BRSKI-AE：BRSKIの代替登録プロトコル」[BRSKI-AE]は、EST [RFC7030]に代わる登録プロトコルに関する一般化を説明しています。EST SimpleEnrollの交換として、BRSKI-AEはこのPKI管理操作を使用して、LDEVID証明書をブートストラップします。
Specific prerequisites augmenting the prerequisites in Section 3.4 are as follows:
セクション3.4の前提条件を増強する特定の前提条件は、次のとおりです。
* The certificate of the EE MUST have been enrolled by an external PKI, e.g., a manufacturer-issued device certificate.
* EEの証明書は、メーカーが発行したデバイス証明書など、外部PKIによって登録されている必要があります。
* The PKI management entity MUST have the trust anchor of the external PKI.
* PKI管理エンティティには、外部PKIの信頼アンカーが必要です。
* When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
* GeneralInfo Field CertProfileを使用する場合、EEは要求された証明書プロファイルを示すために必要な識別子を知っている必要があります。
Message Flow:
メッセージフロー：
Step# EE PKI management entity
1 format ir
2 -> ir ->
3 handle or
forward ir
4 format or receive ip
5 possibly grant
implicitConfirm
6 <- ip <-
7 handle ip
----------------- if implicitConfirm not granted -----------------
8 format certConf
9 -> certConf ->
10 handle or
forward certConf
11 format or receive pkiConf
12 <- pkiConf <-
13 handle pkiConf
For this PKI management operation, the EE MUST include a sequence of one CertReqMsg in the ir. If more certificates are required, further requests MUST be sent using separate PKI management operations.
このPKI管理操作では、EEはIRに1つのCertreQMSGのシーケンスを含める必要があります。より多くの証明書が必要な場合は、個別のPKI管理操作を使用してさらにリクエストを送信する必要があります。
The EE MUST include the generalInfo field implicitConfirm in the header of the ir message as described in Section 3.1, unless it requires certificate confirmation. This leaves the PKI management entities the choice of whether or not the EE must send a certConf message upon receiving a new certificate. Depending on the PKI policy and requirements for managing EE certificates, it can be important for PKI management entities to learn if the EE accepted the new certificate. In such cases, when responding with an ip message, the PKI management entity MUST NOT include the implicitConfirm extension. In case the EE included the generalInfo field implicitConfirm in the request message and the PKI management entity does not need any explicit confirmation from the EE, the PKI management entity MUST include the generalInfo field implicitConfirm in the response message. This prevents explicit certificate confirmation and saves the overhead of a further message round trip. Otherwise, the PKI management entity SHOULD include confirmWaitTime as described in Section 3.1.
EEは、証明書の確認が必要な場合を除き、セクション3.1で説明されているように、IRメッセージのヘッダーにgeneralInfoフィールドImplicitConfirmを含める必要があります。これにより、PKI管理エンティティは、EEが新しい証明書を受け取ったときにCERTCONFメッセージを送信する必要があるかどうかを選択します。PKIポリシーとEE証明書を管理するための要件に応じて、PKI管理エンティティがEEが新しい証明書を受け入れたかどうかを学習することが重要です。そのような場合、IPメッセージで応答する場合、PKI管理エンティティには、暗黙的な拡張機能を含めてはなりません。EEが要求メッセージにGeneralInfoフィールドImplicitConfirmを含め、PKI管理エンティティがEEからの明示的な確認を必要としない場合、PKI管理エンティティには、応答メッセージにGeneralINFOフィールドImplicitConfirmを含める必要があります。これにより、明示的な証明書の確認が防止され、さらにメッセージラウンドトリップのオーバーヘッドが保存されます。それ以外の場合、PKI管理エンティティには、セクション3.1で説明されているように、ConfirmWaittimeを含める必要があります。
If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation MUST be performed as follows. If the EE successfully received the certificate, it MUST send a certConf message in due time. On receiving a valid certConf message, the PKI management entity MUST respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time, it MUST handle this like a rejection by the EE. In case of rejection, depending on its policy, the PKI management entity MAY revoke the newly issued certificate, notify a monitoring system, or log the event internally.
EEが暗黙の確認または暗黙の確認を要求しなかった場合、PKI管理エンティティによって認められなかった場合、証明書の確認は次のように実行する必要があります。EEが証明書を正常に受け取った場合、適時にCERTCONFメッセージを送信する必要があります。有効なCERTCONFメッセージを受信すると、PKI管理エンティティはPKICONFメッセージで応答する必要があります。PKI管理エンティティが予想されるCERTCONFメッセージを時間内に受信しない場合、EEによる拒否のようにこれを処理する必要があります。拒否の場合、そのポリシーに応じて、PKI管理エンティティは、新たに発行された証明書を取り消し、監視システムに通知するか、イベントを内部的に記録する場合があります。
Note: Depending on PKI policy, a new certificate may be published by a PKI management entity, and explicit confirmation may be required. In this case, it is advisable not to do the publication until a positive certificate confirmation has been received. This way, the need to revoke the certificate on negative confirmation can be avoided.
注：PKIポリシーによっては、新しい証明書がPKI管理エンティティによって公開される場合があり、明示的な確認が必要になる場合があります。この場合、肯定的な証明書の確認が受信されるまで公開を行わないことをお勧めします。これにより、否定的な確認に関する証明書を取り消す必要性は回避できます。
If the certificate request was rejected by the CA, the PKI management entity MUST return an ip message containing the status code "rejection" as described in Section 3.6, and the certifiedKeyPair field SHALL be omitted. The EE MUST NOT react to such an ip message with a certConf message, and the PKI management operation MUST be terminated.
CAによって証明書要求が拒否された場合、PKI管理エンティティは、セクション3.6で説明されているように、ステータスコード「拒否」を含むIPメッセージを返す必要があり、認定Keypairフィールドは省略されなければなりません。EEは、CERTCONFメッセージを使用してそのようなIPメッセージに反応してはなりません。PKI管理操作は終了する必要があります。
Detailed Message Description:
詳細なメッセージ説明：
Initialization Request -- ir
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE for a new certificate
ir REQUIRED
-- MUST contain a sequence of one CertReqMsg
-- If more certificates are required, further PKI management
-- operations needs to be initiated
certReq REQUIRED
certReqId REQUIRED
-- MUST be 0
certTemplate REQUIRED
version OPTIONAL
-- MUST be 2 if supplied
subject REQUIRED
-- The EE's identity MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
publicKey OPTIONAL
-- MUST be present if local key generation is used
-- MAY be absent if central key generation is requested
algorithm OPTIONAL
-- MUST be present if local key generation is used and MUST
-- include the subject public key algorithm identifier
-- MAY be present if central key generation is requested and,
-- if present, informs the KGA of algorithm and parameter
-- preferences regarding the to-be-generated key pair
subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of local
-- key generation
-- MUST be a zero-length BIT STRING if central key generation
-- is requested
extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate, like subject alternative name, key
-- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE subject
-- name includes a subject alternative name.
popo OPTIONAL
-- MUST be present if local key generation is used
-- MUST be absent if central key generation is requested
signature OPTIONAL
-- MUST be used by an EE if the key can be used for signing, and
-- if used, it MUST have the type POPOSigningKey
poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the publicKey
-- algorithm field of the certTemplate
signature REQUIRED
-- MUST contain the signature value computed over the DER-encoded
-- certReq
raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
Initialization Response -- ip
Field Value
header
-- As described in Section 3.1
body
-- The response of the CA to the request as appropriate
ip REQUIRED
caPubs OPTIONAL
-- MAY be used if the certifiedKeyPair field is present
-- If used, it MUST contain only a trust anchor, e.g., root
-- certificate, of the certificate contained in certOrEncCert
response REQUIRED
-- MUST contain a sequence of one CertResponse
certReqId REQUIRED
-- MUST be 0
status REQUIRED
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection"
-- "waiting" only allowed with a polling use case as described
-- in Section 4.4
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods"
certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection"
certOrEncCert REQUIRED
-- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED
-- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL
-- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in Section 4.1.6 in case the
-- private key was generated centrally
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
-- MUST contain the chain of the certificate present in
-- certOrEncCert
-- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE sends a confirmation to the PKI
-- management entity to accept or reject the issued
-- certificates
certConf REQUIRED
-- MUST contain a sequence of one CertStatus
CertStatus REQUIRED
certHash REQUIRED
-- The hash algorithm to use MUST be the hash algorithm indicated
-- in the below hashAlg field. If the hashAlg field is not
-- set, it MUST be the hash algorithm defined by the algorithm
-- identifier of the certificate signature or the dedicated
-- hash algorithm defined in [RFC9481] for the used certificate
-- signature algorithm.
certReqId REQUIRED
-- MUST be 0
statusInfo OPTIONAL
-- PKIStatusInfo structure should be present
-- Omission indicates acceptance of the indicated certificate
status REQUIRED
-- positive values allowed: "accepted"
-- negative values allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted"
hashAlg OPTIONAL
-- The hash algorithm to use for calculating the above certHash
-- If used, the pvno field in the header MUST be cmp2021 (3).
-- For backward compatibility, use of this field is
-- NOT RECOMMENDED if the hash algorithm to use can be
-- identified by other means; see above.
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of this PKI management operation
PKI Confirmation -- pkiConf
Field Value
header
-- As described in Section 3.1
body
pkiconf REQUIRED
-- The content of this field MUST be NULL
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of this PKI management operation
This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The EE uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.
このPKI管理操作は、EEが既に証明書を持っているのと同じPKIの追加証明書を要求するために使用する必要があります。EEは、これらの既存の証明書のいずれかを使用して、それぞれの秘密鍵を使用して要求メッセージに署名することにより、認証します。
Specific prerequisites augmenting the prerequisites in Section 3.4 are as follows:
セクション3.4の前提条件を増強する特定の前提条件は、次のとおりです。
* The certificate used by the EE MUST have been enrolled by the PKI it requests another certificate from.
* EEが使用する証明書は、別の証明書を要求するPKIによって登録されている必要があります。
* When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
* GeneralInfo Field CertProfileを使用する場合、EEは要求された証明書プロファイルを示すために必要な識別子を知っている必要があります。
The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.1.1に記載されているものと同一であり、次の変更があります。
1. The body of the first request and response SHOULD be cr and cp. Otherwise, ir and ip MUST be used.
1. 最初の要求と応答の本文は、CRとCPでなければなりません。それ以外の場合、IRとIPを使用する必要があります。
1. Note: Since the difference between ir/ip and cr/cp is syntactically not essential, an ir/ip may be used in this PKI management operation.
1. 注：IR/IPとCR/CPの違いは構文的に必須ではないため、このPKI管理操作ではIR/IPを使用できます。
2. The caPubs field in the certificate response message MUST be absent.
2. 証明書の応答メッセージのCapubsフィールドはない必要があります。
This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certificate it wishes to update as the CMP protection certificate. Both for authenticating itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.
このPKI管理操作は、EEがまだ有効な証明書のいずれかの更新を要求するために使用する必要があります。EEは、CMP保護証明書として更新したい証明書を使用します。自分自身を認証することと、更新する証明書の所有権を証明するために、対応する秘密鍵でリクエストメッセージに署名します。
Specific prerequisites augmenting the prerequisites in Section 3.4 are as follows:
セクション3.4の前提条件を増強する特定の前提条件は、次のとおりです。
* The certificate the EE wishes to update MUST NOT be expired or revoked and MUST have been issued by the addressed CA.
* EEが更新を希望する証明書は、期限切れまたは取り消されてはなりません。
* A new public-private key pair should be used.
* 新しい官民キーペアを使用する必要があります。
* When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
* GeneralInfo Field CertProfileを使用する場合、EEは要求された証明書プロファイルを示すために必要な識別子を知っている必要があります。
The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.1.1に記載されているものと同一であり、次の変更があります。
1. The body of the first request and response MUST be kur and kup, respectively.
1. 最初の要求と応答の本文は、それぞれKurとKupでなければなりません。
2. Protection of the kur MUST be performed using the certificate to be updated.
2. KURの保護は、更新するために証明書を使用して実行する必要があります。
3. The subject field and/or the subjectAltName extension of the certTemplate MUST contain the EE subject name of the existing certificate to be updated, without modifications.
3. CertTemplateの件名フィールドおよび/またはsubjectaltname拡張機能には、変更なしで更新する既存の証明書のeeサブジェクト名を含める必要があります。
4. The certTemplate SHOULD contain the subject and/or subjectAltName extension and publicKey of the EE only.
4. certTemplateには、subjectおよび/またはsubjectaltname拡張機能とEEのPublicKeyのみを含める必要があります。
5. The oldCertId control MAY be used to make clear which certificate is to be updated.
5. OldCertidコントロールを使用して、どの証明書を更新するかを明確にすることができます。
6. The caPubs field in the kup message MUST be absent.
6. KupメッセージのCapubsフィールドはない必要があります。
As part of the certReq structure of the kur, the oldCertId control is added after the certTemplate field.
KURのcertreq構造の一部として、certtemplateフィールドの後にoldcertidコントロールが追加されます。
controls
type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present
value
issuer REQUIRED
serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate
-- to be updated
This PKI management operation can be used by an EE to request a certificate using the PKCS #10 [RFC2986] format to interoperate with CAs not supporting CRMF [RFC4211]. This offers a variation of the PKI management operations specified in Sections 4.1.1 to 4.1.3.
このPKI管理操作は、EEがPKCS＃10 [RFC2986]形式を使用して証明書を要求するために使用して、CRMF [RFC4211]をサポートしていないCAと相互運用することができます。これにより、セクション4.1.1〜4.1.3で指定されたPKI管理操作のバリエーションが提供されます。
In this PKI management operation, the public key and all further certificate template data MUST be contained in the subjectPKInfo and other certificationRequestInfo fields of the PKCS #10 structure.
このPKI管理操作では、PKCS＃10構造のsubjectpkinfoおよびその他の認証Requestinfoフィールドに、公開キーとすべてのさらなる証明書テンプレートデータを含める必要があります。
The prerequisites are the same as given in Section 4.1.2.
前提条件は、セクション4.1.2で与えられたものと同じです。
The message sequence for this PKI management operation is identical to that given in Sections 4.1.1 to 4.1.3, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.1.1〜4.1.3に記載されているものと同一であり、次の変更があります。
1. The body of the first request and response MUST be p10cr and cp, respectively.
1. 最初の要求と応答の本体は、それぞれP10CRとCPでなければなりません。
2. The certReqId in the cp message MUST be -1.
2. CPメッセージのcertreqidは-1でなければなりません。
Detailed Message Description:
詳細なメッセージ説明：
Certification Request -- p10cr
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE for a new certificate using a PKCS #10
-- certificate request
p10cr REQUIRED
certificationRequestInfo REQUIRED
version REQUIRED
-- MUST be 0 to indicate PKCS #10 v1.7
subject REQUIRED
-- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
subjectPKInfo REQUIRED
algorithm REQUIRED
-- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED
-- MUST include the public key to be certified
attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name,
-- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the
-- subjectPKInfo field.
signature REQUIRED
-- MUST contain the self-signature for proof-of-possession
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described for the underlying PKI management operation
This is a variant of the PKI management operations described in Sections 4.1.1, 4.1.2, and 4.1.4. It should be used by an EE to request a certificate of a new PKI in case it does not have a certificate to prove its identity to the target PKI but has some secret information shared with the PKI management entity. Therefore, the request and response messages are MAC-protected using this shared secret information. The distribution of this shared secret is out of scope for this document. The PKI management entity checking the MAC-based protection MUST replace this protection according to Section 5.2.3, as the next hop may not know the shared secret information.
これは、セクション4.1.1、4.1.2、および4.1.4で説明されているPKI管理操作のバリアントです。EEは、ターゲットPKIに対するアイデンティティを証明する証明書を持っていないが、PKI管理エンティティと共有されるいくつかの秘密情報がある場合に備えて、新しいPKIの証明書を要求するために使用する必要があります。したがって、リクエストと応答のメッセージは、この共有された秘密情報を使用してMAC保護されています。この共有秘密の分布は、このドキュメントの範囲外です。MACベースの保護をチェックするPKI管理エンティティは、次のホップが共有秘密情報を知らない可能性があるため、セクション5.2.3に従ってこの保護を置き換える必要があります。
Note: The entropy of the shared secret information is crucial for the level of protection when using MAC-based protection. Further guidance is available in the security considerations updated by CMP Updates [RFC9480].
注：MACベースの保護を使用する場合、共有された秘密情報のエントロピーは保護レベルに重要です。CMPアップデート[RFC9480]によって更新されたセキュリティに関する考慮事項では、さらなるガイダンスが利用可能です。
Specific prerequisites augmenting the prerequisites in Section 3.4 are as follows:
セクション3.4の前提条件を増強する特定の前提条件は、次のとおりです。
* Rather than using private keys, certificates, and trust anchors, the EE and the PKI management entity MUST share secret information.
* プライベートキー、証明書、信頼のアンカーを使用するのではなく、EEとPKI管理エンティティは秘密情報を共有する必要があります。
* Note: The shared secret information MUST be established out of band, e.g., by a service technician during initial local configuration.
* 注：共有された秘密情報は、例えば、最初のローカル構成中にサービス技術者がバンドから確立する必要があります。
* When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
* GeneralInfo Field CertProfileを使用する場合、EEは要求された証明書プロファイルを示すために必要な識別子を知っている必要があります。
The message sequence for this PKI management operation is identical to that given in Sections 4.1.1, 4.1.2, and 4.1.4, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.1.1、4.1.2、および4.1.4に記載されているものと同一であり、次の変更があります。
1. The protection of all messages MUST be MAC-based. Therefore, extraCerts fields of all messages do not contain CMP protection certificates and associated chains.
1. すべてのメッセージの保護は、Macベースでなければなりません。したがって、すべてのメッセージの外部フィールドには、CMP保護証明書と関連するチェーンが含まれていません。
2. The sender field MUST contain a name the PKI management entity can use to identify the shared secret information used for message protection. This name MUST be placed in the commonName field of the directoryName choice. The senderKID MUST contain the same name as in the commonName field of the sender field. In case the sending entity does not yet know for which name to request the certificate, it can use this commonName in the subject field of the certTemplate.
2. 送信者フィールドには、PKI管理エンティティがメッセージ保護に使用される共有秘密情報を識別するために使用できる名前を含める必要があります。この名前は、DirectoryName選択のCommonNameフィールドに配置する必要があります。SenderKidには、送信者フィールドのCommonNameフィールドと同じ名前が含まれている必要があります。送信エンティティが証明書を要求する名前をまだ把握していない場合は、CertTemplateの件名フィールドでこのCommonNameを使用できます。
See Section 6 of CMP Algorithms [RFC9481] for details on message authentication code algorithms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg field, e.g., used for key derivation, like a salt and an iteration count. Such parameters should remain constant for message protection throughout this PKI management operation to reduce the computational overhead.
使用するメッセージ認証コードアルゴリズム（MSG_MAC_ALG）の詳細については、CMPアルゴリズム[RFC9481]のセクション6を参照してください。通常、パラメーターは、塩や反復カウントなど、キー導入に使用される保護分野の一部です。このようなパラメーターは、計算オーバーヘッドを減らすために、このPKI管理操作全体でメッセージ保護のために一定のままでなければなりません。
This is a variant of the PKI management operations described in Sections 4.1.1 to 4.1.4 and the variant described in Section 4.1.5. It needs to be used in case an EE is not able to generate its new public-private key pair itself or central generation of the EE key material is preferred. Which PKI management entity will act as Key Generation Authority (KGA) and perform the key generation is a matter of the local implementation. This PKI management entity MUST use a certificate containing the additional extended key usage extension id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority.
これは、セクション4.1.1〜4.1.4で説明されているPKI管理操作のバリアントであり、セクション4.1.5で説明されているバリアントです。EEが新しい官民キーペア自体を生成できない場合、またはEEキー材料の中央生成が優先される場合に使用する必要があります。どのPKIマネジメントエンティティが主要生成局（KGA）として機能し、キージェネレーションを実行することはローカル実装の問題です。このPKI管理エンティティは、EEが合法的な主要生成権限として受け入れるために、追加の拡張キー使用量拡張ID-KP-CMKGAを含む証明書を使用する必要があります。
Note: As described in Section 5.3.1, the KGA can use the PKI management operation described in Section 4.1.2 to request the certificate for this key pair on behalf of the EE.
注：セクション5.3.1で説明したように、KGAはセクション4.1.2で説明されているPKI管理操作を使用して、EEに代わってこのキーペアの証明書を要求できます。
When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the certificate on behalf of the EE, as the old EE credential is not available to the KGA for protecting this message. Therefore, if the EE uses the PKI management operation described in Section 4.1.3, the KGA MUST act as described in Section 4.1.2 to request the certificate for the newly generated key pair on behalf of the EE from the CA.
EEがKURメッセージを使用して証明書更新の中央キー生成を要求する場合、KGAはKURメッセージを使用してEEに代わって証明書を要求することができません。これは、このメッセージを保護するためにKGAが使用できないためです。したがって、EEがセクション4.1.3で説明したPKI管理操作を使用している場合、KGAは、CAからEEに代わって新しく生成されたキーペアの証明書を要求するためにセクション4.1.2に記載されているとおりに行動する必要があります。
Generally speaking, it is strongly preferable to generate public-private key pairs locally at the EE. This is advisable to make sure that the entity identified in the newly issued certificate is the only entity that knows the private key.
一般的に言えば、EEで局所的に官民のキーペアを生成することが強く望まれます。これは、新しく発行された証明書で特定されたエンティティが、秘密鍵を知っている唯一のエンティティであることを確認することをお勧めします。
Reasons for central key generation may include the following:
中央キー生成の理由には、次のものが含まれます。
* lack of sufficient initial entropy
* 十分な初期エントロピーの欠如
* Note: Good random numbers are not only needed for key generation but also for session keys and nonces in any security protocol. Therefore, a decent security architecture should anyways support good random number generation on the EE side or provide enough initial entropy for the random number generator seed to guarantee good pseudorandom number generation. Yet maybe this is not the case at the time of requesting an initial certificate during manufacturing.
* 注：良好な乱数は、キー生成だけでなく、セキュリティプロトコルのセッションキーとノンセスにも必要です。したがって、とにかく適切なセキュリティアーキテクチャは、とにかくEE側の良好な乱数生成をサポートするか、ランダム数ジェネレーターシードに十分な初期エントロピーを提供して、良い擬似ランダム数生成を保証します。しかし、製造中に初期証明書を要求した時点ではそうではありません。
* lack of computational resources, in particular, for RSA key generation
* 特に、RSAキー生成のための計算リソースの不足
* Note: Since key generation could be performed in advance to the certificate enrollment communication, it is often not time critical.
* 注：キー生成は事前に証明書登録通信に実行できるため、多くの場合、時間が重要ではありません。
Note: As mentioned in Section 2, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.
注：セクション2で述べたように、プッシュモデルでは中央キー生成が必要になる場合があります。プッシュモデルでは、証明書の応答メッセージは、以前の要求メッセージなしでPKI管理エンティティによってEEに転送されます。
The EE requesting central key generation MUST omit the publicKey field from the certTemplate or, in case it has a preference on the key type to be generated, provide this preference in the algorithm sub-field and fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both variants indicate to the PKI management entity that a new key pair shall be generated centrally on behalf of the EE.
中央キー生成を要求するEEは、CertTemplateからPublicKeyフィールドを省略するか、生成されるキータイプを優先する場合は、アルゴリズムサブフィールドでこの好みを提供し、件名パブリックキーサブフィールドをゼロで埋める必要があります。長さビット文字列。両方のバリアントは、PKI管理エンティティに対して、EEに代わって新しいキーペアが中央に生成されることを示しています。
Note: As the protection of centrally generated keys in the response message has been extended to EncryptedKey by Section 2.7 of CMP Updates [RFC9480], EnvelopedData is the preferred alternative to EncryptedValue. In CRMF [RFC4211], Section 2.1, point 9, the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile requires using EnvelopedData, as specified in Section 6 of CMS [RFC5652]. When EnvelopedData is to be used in a PKI management operation, CMP v3 MUST be indicated in the message header already for the initial request message; see Section 2.20 of CMP Updates [RFC9480].
注：応答メッセージ内の中心に生成されたキーの保護は、CMP更新[RFC9480]のセクション2.7によって暗号化されたキーに拡張されているため、EnvelopedDataは暗号化されたValueに代わる好ましい代替手段です。CRMF [RFC4211]、セクション2.1、ポイント9では、暗号化されたバリューの使用は封筒構造を支持して廃止されました。したがって、このプロファイルは、CMS [RFC5652]のセクション6で指定されているように、封筒を使用する必要があります。EnvelopedDataがPKI管理操作で使用される場合、CMP V3は、最初のリクエストメッセージに対して既にメッセージヘッダーに示される必要があります。CMP更新[RFC9480]のセクション2.20を参照してください。
+----------------------------------+
| EnvelopedData |
| [RFC5652], Section 6 |
| +------------------------------+ |
| | SignedData | |
| | [RFC5652], Section 5 | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | |
| | | +----------------------+ | | |
| | | | private key | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+
Figure 3: Encrypted Private Key Container
図3：暗号化された秘密鍵コンテナ
The PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message also containing the newly issued certificate.
PKI Management Entityは、新しく発行された証明書も含まれている応答メッセージの認定Keypair構造のPrivateKeyフィールドのプライベートキーを提供します。
The private key MUST be provided as an AsymmetricKeyPackage structure as defined in [RFC5958].
秘密鍵は、[RFC5958]で定義されているように、非対称Keypackage構造として提供する必要があります。
This AsymmetricKeyPackage structure MUST be wrapped in a SignedData structure, as specified in Section 5 of CMS [RFC5652] and [RFC8933], and signed by the KGA generating the key pair. The signature MUST be performed using a private key related to a certificate asserting the extended key usage id-kp-cmKGA, as described in Section 2.2 of CMP Updates [RFC9480], to demonstrate authorization to generate key pairs on behalf of an EE. For response messages using signature-based protection, the EE MUST validate the signer certificate contained in the SignedData structure and SHOULD authorize the KGA considering any given id-kp-cmKGA extended key usage in the signer certificate. For response messages using MAC-based protection, the EE MAY omit the validation as it may not be possible or meaningful to the EE. In this case, the EE authorizes the KGA using the shard secret information.
この非対称KeyPackage構造は、CMS [RFC5652]および[RFC8933]のセクション5で指定されているように、署名Data構造に包まれ、KGAがキーペアを生成するKGAによって署名する必要があります。署名は、CMP更新[RFC9480]のセクション2.2で説明されているように、拡張キー使用ID-KP-CMKGAを主張する証明書に関連する秘密鍵を使用して実行する必要があり、EEに代わってキーペアを生成する認可を実証します。署名ベースの保護を使用した応答メッセージの場合、EEはSignedData構造に含まれる署名者証明書を検証する必要があり、特定のID-KP-CMKGAが署名者証明書に拡張されたキー使用量を考慮してKGAを承認する必要があります。MACベースの保護を使用した応答メッセージの場合、EEはEEにとって不可能または意味がある可能性があるため、検証を省略する場合があります。この場合、EEはShard Secret Informationを使用してKGAを承認します。
The SignedData structure MUST be wrapped in an EnvelopedData structure, as specified in Section 6 of CMS [RFC5652], encrypting it using a newly generated symmetric content-encryption key.
SignedData構造は、CMS [RFC5652]のセクション6で指定されているように、新しく生成された対称コンテンツ - 暗号化キーを使用して暗号化する封筒構造に包まれなければなりません。
This content-encryption key MUST be securely provided as part of the EnvelopedData structure to the EE using one of three key management techniques. The choice of the key management technique to be used by the PKI management entity depends on the authentication mechanism the EE chose to protect the request message. See Section 2.7 of CMP Updates [RFC9480] for details on which key management technique to use.
このコンテンツ暗号化キーは、3つの主要な管理手法のいずれかを使用して、EEの封筒構造の一部として安全に提供する必要があります。PKI管理エンティティが使用する重要な管理手法の選択は、EEがリクエストメッセージを保護するために選択した認証メカニズムに依存します。使用する主要な管理手法の詳細については、CMP更新[RFC9480]のセクション2.7を参照してください。
* Signature-based protection of the request message:
* リクエストメッセージの署名ベースの保護：
* In this case, the choice depends on the type of public key in the CMP protection certificate used by the EE in its request.
* この場合、選択は、その要求でEEが使用するCMP保護証明書の公開キーのタイプに依存します。
- The content-encryption key SHALL be protected using the key transport key management technique (see Section 4.1.6.1) if the key type supports this.
- キータイプがこれをサポートしている場合、コンテンツ - 結晶化キーは、キートランスポートキー管理手法（セクション4.1.6.1を参照）を使用して保護するものとします。
- The content-encryption key SHALL be protected using the key agreement key management technique (see Section 4.1.6.2) if the key type supports this.
- キータイプがこれをサポートしている場合は、キー契約キー管理手法（セクション4.1.6.2を参照）を使用して、コンテンツ - 結晶化キーは保護されます。
* MAC-based protection of the request message:
* リクエストメッセージのMacベースの保護：
- The content-encryption key SHALL be protected using the password-based key management technique (see Section 4.1.6.3) if and only if the EE used MAC-based protection for the request message.
- コンテンツ - 結晶化キーは、EEがリクエストメッセージにMacベースの保護を使用した場合にのみ、パスワードベースのキー管理手法（セクション4.1.6.3を参照）を使用して保護されます。
Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations are as follows:
それぞれの証明書登録PKI管理操作のものを増強する特定の前提条件は次のとおりです。
* If signature-based protection is used, the EE MUST be able to authenticate and authorize the KGA using suitable information, which includes a trust anchor.
* 署名ベースの保護が使用されている場合、EEは、信頼アンカーを含む適切な情報を使用してKGAを認証および承認できる必要があります。
* If MAC-based protection is used, the KGA MUST also know the shared secret information to protect the encrypted transport of the newly generated key pair. Consequently, the EE can also authorize the KGA.
* MACベースの保護が使用されている場合、KGAは、新しく生成されたキーペアの暗号化された輸送を保護するために共有された秘密情報も知っている必要があります。その結果、EEはKGAを承認することもできます。
* The PKI management entity MUST have a certificate containing the additional extended key usage extension id-kp-cmKGA for signing the SignedData structure containing the private key package.
* PKI管理エンティティには、プライベートキーパッケージを含むSignedData構造に署名するための追加の拡張キー使用量拡張ID-KP-CMKGAを含む証明書が必要です。
* For encrypting the SignedData structure, a fresh content-encryption key to be used by the symmetric encryption algorithm MUST be generated with sufficient entropy.
* SignedData構造を暗号化するには、対称暗号化アルゴリズムで使用する新しいコンテンツ暗号化キーを、十分なエントロピーで生成する必要があります。
* Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.
* 注：生成された秘密鍵の保護のセキュリティ強度は、生成された秘密鍵のセキュリティ強度と同じか高くなければなりません。
Detailed Description of the privateKey Field:
プライベートキーフィールドの詳細な説明：
privateKey REQUIRED
-- MUST be an EnvelopedData structure, as specified in
-- Section 6 of CMS [RFC5652]
version REQUIRED
-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- KeyTransRecipientInfo
-- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED
-- MUST contain a sequence of one RecipientInfo, which MUST be
-- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
-- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
-- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
encryptedContentInfo
REQUIRED
contentType REQUIRED
-- MUST be id-signedData
contentEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the algorithm used for
-- content encryption
-- The algorithm type MUST be PROT_SYM_ALG as specified in
-- [RFC9481], Section 5
encryptedContent REQUIRED
-- MUST be the SignedData structure, as specified in Section 5
-- of CMS [RFC5652] and [RFC8933], in encrypted form
version REQUIRED
-- MUST be 3
digestAlgorithms
REQUIRED
-- MUST contain a sequence of one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm; see [RFC8933]
encapContentInfo
REQUIRED
-- MUST contain the content that is to be signed
eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED
-- MUST be of type AsymmetricKeyPackage and
-- MUST contain a sequence of one OneAsymmetricKey element
version REQUIRED
-- MUST be 1 (indicating v2)
privateKeyAlgorithm
REQUIRED
-- The privateKeyAlgorithm field MUST contain the algorithm
-- identifier of the asymmetric key pair algorithm
privateKey REQUIRED
publicKey REQUIRED
-- MUST contain the public key corresponding to the private key
-- for simplicity and consistency with v2 of OneAsymmetricKey
certificates REQUIRED
-- MUST contain the certificate for the private key used to sign
-- the signedData content, together with its chain
-- The first certificate in this field MUST be the KGA
-- certificate used for protecting this content
-- Self-signed certificates should not be included and MUST NOT
-- be trusted based on their inclusion in any case
signerInfos REQUIRED
-- MUST contain a sequence of one SignerInfo element
version REQUIRED
-- MUST be 3
sid REQUIRED
subjectKeyIdentifier
REQUIRED
-- MUST be the subjectKeyIdentifier of the KGA certificate
digestAlgorithm
REQUIRED
-- MUST be the same as in the digestAlgorithms field of
-- encryptedContent
signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time
-- of a signature. It SHOULD be omitted if the transactionTime
-- field is not present in the PKIHeader.
-- For details on the signed attributes, see Sections 5.3 and
-- 11 of CMS [RFC5652] and [RFC8933]
signatureAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits
-- The signature algorithm type MUST be MSG_SIG_ALG, as
-- specified in [RFC9481], Section 3, and MUST be consistent
-- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED
-- MUST be the digital signature of the encapContentInfo
As stated in Section 1.8, all fields of the ASN.1 syntax that are defined in [RFC5652] but are not explicitly specified here SHOULD NOT be used.
セクション1.8で述べたように、[RFC5652]で定義されているがここで明示的に指定されていないASN.1構文のすべてのフィールドは使用しないでください。
This variant can be applied in combination with the PKI management operations specified in Sections 4.1.1 to 4.1.3 using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST contain a public key supporting key transport and allow for the key usage "keyEncipherment". The related key pair MUST be used for encipherment of the content-encryption key. For this key management technique, the KeyTransRecipientInfo structure MUST be used in the contentInfo field.
このバリアントは、CMPメッセージの署名ベースの保護を使用して、セクション4.1.1〜4.1.3で指定されたPKI管理操作と組み合わせて適用できます。リクエストメッセージの署名ベースの保護に使用されるEE証明書には、キートランスポートをサポートする公開キーが含まれており、キーの使用法「keyencipherment」を可能にする必要があります。関連するキーペアは、コンテンツ暗号化キーを抑えるために使用する必要があります。この主要な管理手法では、contentinfoフィールドでキートランスレシピエンティンフォー構造を使用する必要があります。
The KeyTransRecipientInfo structure included into the EnvelopedData structure is specified in Section 6.2.1 of CMS [RFC5652].
EnvelopedData構造に含まれるKeyTransrecipientInfo構造は、CMS [RFC5652]のセクション6.2.1で指定されています。
Detailed Description of the KeyTransRecipientInfo Structure:
keytransrecipientinfo構造の詳細な説明：
ktri REQUIRED
-- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
-- of CMS [RFC5652]
version REQUIRED
-- MUST be 2
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key transport
-- algorithm. The algorithm type MUST be KM_KT_ALG as
-- specified in [RFC9481], Section 4.2
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
This variant can be applied in combination with the PKI management operations specified in Sections 4.1.1 to 4.1.3, using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message MUST contain a public key supporting key agreement and allow for the key usage "keyAgreement". The related key pair MUST be used for establishment of the content-encryption key. For this key management technique, the KeyAgreeRecipientInfo structure MUST be used in the contentInfo field.
このバリアントは、CMPメッセージの署名ベースの保護を使用して、セクション4.1.1〜4.1.3で指定されたPKI管理操作と組み合わせて適用できます。リクエストメッセージの署名ベースの保護に使用されるEE証明書には、キー契約をサポートする公開キーが含まれており、キーの使用法「keyagreement」を許可する必要があります。関連するキーペアは、コンテンツ暗号化キーの確立に使用する必要があります。この重要な管理手法では、contentinfoフィールドでKeyAgreerecipientInfo構造を使用する必要があります。
The KeyAgreeRecipientInfo structure included into the EnvelopedData structure is specified in Section 6.2.2 of CMS [RFC5652].
EnvelopedData構造に含まれるKeyAgreerecipientInfo構造は、CMS [RFC5652]のセクション6.2.2で指定されています。
Detailed Description of the KeyAgreeRecipientInfo Structure:
keyagreerecipientinfo構造の詳細な説明：
kari REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in Section
-- 6.2.2 of CMS [RFC5652]
version REQUIRED
-- MUST be 3
originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the subjectKeyIdentifier
-- choice, and the subjectKeyIdentifier MUST equal the
-- senderKID in the PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
ukm RECOMMENDED
-- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
-- (ECMQV) is used; see [RFC5753]
-- SHOULD be present to ensure uniqueness of the key
-- encryption key
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key agreement
-- algorithm
-- The algorithm type MUST be KM_KA_ALG as specified in
-- [RFC9481], Section 4.1
-- The parameters field of the key agreement algorithm MUST
-- contain the key wrap algorithm. The algorithm type
-- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
recipientEncryptedKeys
REQUIRED
-- MUST contain a sequence of one RecipientEncryptedKey
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used
encryptedKey
REQUIRED
-- MUST be the encrypted content-encryption key
This variant can be applied in combination with the PKI management operation specified in Section 4.1.5, using MAC-based protection of CMP messages. The shared secret information used for the MAC-based protection MUST also be used for the encryption of the content-encryption key but with a different salt value applied in the key derivation algorithm. For this key management technique, the PasswordRecipientInfo structure MUST be used in the contentInfo field.
このバリアントは、CMPメッセージのMacベースの保護を使用して、セクション4.1.5で指定されたPKI管理操作と組み合わせて適用できます。MACベースの保護に使用される共有秘密情報は、コンテンツ暗号化キーの暗号化にも使用する必要がありますが、キー派生アルゴリズムには異なる塩値が適用されます。この重要な管理手法では、PasswordRecipientInfo構造をContentInfoフィールドで使用する必要があります。
Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the shared secret information SHALL NOT be less than the security strength of the centrally generated key pair. Further guidance is available in Section 9.
注：共有された秘密情報のエントロピーは、パスワードベースのキー管理手法を使用する場合、保護レベルに重要です。中心に生成されたキーペアの場合、共有された秘密情報のエントロピーは、中央生成されたキーペアのセキュリティ強度よりも少なくてはなりません。セクション9では、さらなるガイダンスが利用できます。
The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in Section 6.2.4 of CMS [RFC5652].
EnvelopedData構造に含まれるPasswordRecipientInfo構造は、CMS [RFC5652]のセクション6.2.4で指定されています。
Detailed Description of the PasswordRecipientInfo Structure:
PasswordRecipientInfo構造の詳細な説明：
pwri REQUIRED
-- MUST be PasswordRecipientInfo as specified in
-- Section 6.2.4 of CMS [RFC5652]
version REQUIRED
-- MUST be 0
keyDerivationAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key derivation
-- algorithm
-- The algorithm type MUST be KM_KD_ALG as specified in
-- [RFC9481], Section 4.4
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm type MUST be KM_KW_ALG as specified in
-- [RFC9481], Section 4.3
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
This PKI management operation should be used by an entity to request revocation of a certificate. Here, the revocation request is used by an EE to revoke one of its own certificates.
このPKI管理操作は、証明書の取り消しを要求するためにエンティティが使用する必要があります。ここで、取り消し要求は、独自の証明書の1つを取り消すためにEEによって使用されます。
The revocation request message MUST be signed using the certificate that is to be revoked to prove the authorization to revoke. The revocation request message is signature-protected using this certificate. This requires that the EE still possesses the private key. If this is not the case, the revocation has to be initiated by other means, e.g., revocation by the RA, as specified in Section 5.3.2.
取り消し要求メッセージは、取り消される証明書を使用して署名する必要があります。取り消し要求メッセージは、この証明書を使用して署名保護されています。これには、EEがまだ秘密鍵を持っていることが必要です。そうでない場合、セクション5.3.2で指定されているように、取り消しは他の手段、たとえばRAによる失効によって開始されなければなりません。
An EE requests revoking a certificate of its own at the CA that issued this certificate. The PKI management entity handles the request as described in Section 5.1.3, and responds with a message that contains the status of the revocation from the CA.
EEは、この証明書を発行したCAで独自の証明書を取り消すことを要求します。PKI管理エンティティは、セクション5.1.3で説明されているようにリクエストを処理し、CAからの取り消しのステータスを含むメッセージで応答します。
The specific prerequisite augmenting the prerequisites in Section 3.4 is as follows:
セクション3.4の前提条件を増強する特定の前提条件は次のとおりです。
* The certificate the EE wishes to revoke is not yet expired or revoked.
* EEが取り消したい証明書は、まだ期限切れまたは取り消されていません。
Message Flow:
メッセージフロー：
Step# EE PKI management entity
1 format rr
2 -> rr ->
3 handle or forward rr
4 format or receive rp
5 <- rp <-
6 handle rp
For this PKI management operation, the EE MUST include a sequence of one RevDetails structure in the rr message body. In the case no generic error occurred, the response to the rr MUST be an rp message containing a single status field.
このPKI管理操作では、EEはRRメッセージ本文に1つのRevdetails構造のシーケンスを含める必要があります。一般的なエラーが発生しなかった場合、RRへの応答は、単一のステータスフィールドを含むRPメッセージでなければなりません。
Detailed Message Description:
詳細なメッセージ説明：
Revocation Request -- rr
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE to revoke its certificate
rr REQUIRED
-- MUST contain a sequence of one element of type RevDetails
-- If more revocations are desired, further PKI management
-- operations need to be initiated
certDetails REQUIRED
-- MUST be present and is of type CertTemplate
serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the
-- certificate to be revoked
issuer REQUIRED
-- MUST contain the issuer attribute of the certificate to be
-- revoked
crlEntryDetails REQUIRED
-- MUST contain a sequence of one reasonCode of type CRLReason
-- (see [RFC5280], Section 5.3.1)
-- If the reason for this revocation is not known or shall not
-- be published, the reasonCode MUST be 0 (unspecified)
protection REQUIRED
-- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked
extraCerts REQUIRED
-- As described in Section 3.3
Revocation Response -- rp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity to the request as
-- appropriate
rp REQUIRED
status REQUIRED
-- MUST contain a sequence of one element of type PKIStatusInfo
status REQUIRED
-- positive value allowed: "accepted"
-- negative value allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if the status is "rejection"
-- MUST be absent if the status is "accepted"
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
The following support messages offer on-demand, in-band delivery of content relevant to the EE provided by a PKI management entity. CMP general messages and general response are used for this purpose. Depending on the environment, these requests may be answered by an RA or CA (see also Section 5.1.4).
以下のサポートメッセージは、PKI管理エンティティが提供するEEに関連するコンテンツのオンデマンドの帯域内配信を提供します。CMP一般的なメッセージと一般的な応答は、この目的に使用されます。環境に応じて、これらの要求はRAまたはCAによって回答される場合があります（セクション5.1.4も参照）。
The general messages and general response messages contain InfoTypeAndValue structures. In addition to those infoType values defined in [RFC4210] and CMP Updates [RFC9480], further OIDs MAY be used to define new PKI management operations or new general-purpose support messages as needed in specific environments.
一般的なメッセージと一般的な応答メッセージには、InfotypeandValue構造が含まれています。[RFC4210]およびCMP更新[RFC9480]で定義されているインフォタイプの値に加えて、特定の環境で必要に応じて、新しいPKI管理操作または新しい汎用サポートメッセージを定義するために、さらにOIDを使用できます。
The following contents are specified in this document:
このドキュメントでは、次の内容が指定されています。
* Get CA certificates.
* CA証明書を取得します。
* Get root CA certificate update.
* ルートCA証明書の更新を取得します。
* Get certificate request template.
* 証明書要求テンプレートを取得します。
* Get new Certificate Revocation Lists (CRLs).
* 新しい証明書の取り消しリスト（CRLS）を取得します。
The following message flow and contents are common to all general message (genm) and general response (genp) messages.
次のメッセージフローと内容は、すべての一般的なメッセージ（GENM）および一般応答（GENP）メッセージに共通しています。
Message Flow:
メッセージフロー：
Step# EE PKI management entity
1 format genm
2 -> genm ->
3 handle or forward genm
4 format or receive genp
5 <- genp <-
6 handle genp
Detailed Message Description:
詳細なメッセージ説明：
General Message -- genm
Field Value
header
-- As described in Section 3.1
body
-- A request by the EE for information
genm REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying one of the specific PKI
-- management operations described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
General Response -- genp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity providing
-- information
genp REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying the specific PKI management
-- operation described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
This PKI management operation can be used by an EE to request CA certificates from the PKI management entity.
このPKI管理操作は、EEがPKI管理エンティティからCA証明書を要求するために使用できます。
An EE requests CA certificates, e.g., for chain construction, from a PKI management entity by sending a general message with OID id-it-caCerts, as specified in Section 2.14 of CMP Updates [RFC9480]. The PKI management entity responds with a general response with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or no content in case no CA certificate is available.
EEは、CMP更新[RFC9480]のセクション2.14で指定されているように、OID ID-IT-CACERTSを使用して一般的なメッセージを送信することにより、PKI管理エンティティからチェーン構築用のCA証明書を要求します。PKI管理エンティティは、利用可能な中間および発行CA証明書を入力した一連の証明書を含む同じOIDで一般的な応答で応答します。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
The message sequence for this PKI management operation is as given above, with the following specific content:
このPKI管理操作のメッセージシーケンスは、次の特定のコンテンツとともに上記のとおりです。
1. the infoType OID to use is id-it-caCerts
1. 使用するインフォタイプOIDはID-IT-CACERTSです
2. the infoValue of the request MUST be absent
2. リクエストの情報値はない必要があります
3. if present, the infoValue of the response MUST contain a sequence of certificates
3. 存在する場合、応答の情報値には一連の証明書が含まれている必要があります
Detailed Description of the infoValue Field of genp:
Genpの情報値フィールドの詳細な説明：
infoValue OPTIONAL
-- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available
-- if present, MUST be a sequence of CMPCertificate
This PKI management operation can be used by an EE to request an updated root CA certificate as described in Section 4.4 of [RFC4210].
このPKI管理操作は、[RFC4210]のセクション4.4で説明されているように、更新されたルートCA証明書を要求するためにEEによって使用できます。
An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it-rootCaCert. If needed for unique identification, the EE MUST include the old root CA certificate in the message body as specified in Section 2.15 of CMP Updates [RFC9480]. The PKI management entity responds with a general response with OID id-it-rootCaKeyUpdate that either contains the update of the root CA certificate consisting of up to three certificates or no content in case no update is available.
EEは、OID ID-It-RootCacertを使用して一般的なメッセージを送信することにより、PKI管理エンティティからルートCA証明書の更新を要求します。一意の識別に必要な場合、EEは、CMP更新[RFC9480]のセクション2.15で指定されているように、メッセージ本文に古いルートCA証明書を含める必要があります。PKI管理エンティティは、oid-it-rootcakeyupdateを使用して一般的な応答で応答します。これは、更新が利用できない場合に最大3つの証明書またはコンテンツなしで構成されるルートCA証明書の更新を含むかどうか。
Note: This mechanism may also be used to update trusted non-root certificates, e.g., directly trusted intermediate or issuing CA certificates.
注：このメカニズムは、信頼できる非ルート証明書、たとえば直接信頼できる中間または発行CA証明書を更新するためにも使用できます。
The newWithNew certificate is the new root CA certificate and is REQUIRED to be present if available. The newWithOld certificate is REQUIRED to be present in the response message because it is needed for the receiving entity trusting the old root CA certificate to gain trust in the new root CA certificate. The oldWithNew certificate is OPTIONAL because it is only needed in rare scenarios where other entities may not already trust the old root CA.
NewWithNew証明書は新しいルートCA証明書であり、利用可能な場合は存在する必要があります。NewWithold証明書は、新しいルートCA証明書に信頼を得るために古いルートCA証明書を信頼する受信エンティティが必要であるため、応答メッセージに存在する必要があります。OldWithNewの証明書は、他のエンティティが古いルートCAをまだ信頼していないまれなシナリオでのみ必要であるため、オプションです。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
The message sequence for this PKI management operation is as given above, with the following specific content:
このPKI管理操作のメッセージシーケンスは、次の特定のコンテンツとともに上記のとおりです。
1. the infoType OID to use is id-it-rootCaCert in the request and id-it-rootCaKeyUpdate in the response
1. 使用するインフォタイプoidは、リクエストのid-it-rootcacertと応答でid-it-rootcakeyupdateです
2. the infoValue of the request SHOULD contain the root CA certificate the update is requested for
2. リクエストの情報値には、更新が要求されるルートCA証明書を含める必要があります
3. if present, the infoValue of the response MUST be a RootCaKeyUpdateContent structure
3. 存在する場合、応答の情報値はrootcakeyupdatecontent構造でなければなりません
Detailed Description of the infoValue Field of genm:
GENMの情報値フィールドの詳細な説明：
infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated if needed
-- for unique identification
Detailed Description of the infoValue Field of genp:
Genpの情報値フィールドの詳細な説明：
infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is
-- available
-- MUST be present if an update of the root CA certificate
-- is available and MUST be of type RootCaKeyUpdateContent
newWithNew REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the new root CA certificate
newWithOld REQUIRED
-- MUST be present if infoValue is present
-- MUST contain a certificate containing the new public
-- root CA key signed with the old private root CA key
oldWithNew OPTIONAL
-- MAY be present if infoValue is present
-- MUST contain a certificate containing the old public
-- root CA key signed with the new private root CA key
This PKI management operation can be used by an EE to request a template with parameters for future certificate requests.
このPKI管理操作は、EEが使用して、将来の証明書リクエストのパラメーターを備えたテンプレートを要求できます。
An EE requests certificate request parameters from the PKI management entity by sending a general message with OID id-it-certReqTemplate as specified in Section 2.16 of CMP Updates [RFC9480]. The EE MAY indicate the certificate profile to use in the id-it-certProfile extension of the generalInfo field in the PKIHeader of the general message as described in Section 3.1. The PKI management entity responds with a general response with the same OID that either contains requirements on the certificate request template or no content in case no specific requirements are imposed by the PKI. The CertReqTemplateValue contains requirements on certificate fields and extensions in a certTemplate. Optionally, it contains a keySpec field containing requirements on algorithms acceptable for key pair generation.
EEは、CMP更新[RFC9480]のセクション2.16で指定されているように、OID ID-IT-CertreQTemplateを使用して一般的なメッセージを送信することにより、PKI管理エンティティから証明書要求パラメーターを要求します。EEは、セクション3.1で説明されているように、一般的なメッセージのpkiheaderの一般的なgeneralinfoフィールドのID-it-certprofile拡張で使用する証明書プロファイルを示す場合があります。PKI管理エンティティは、PKIによって特定の要件が課されていない場合に、証明書要求テンプレートに要件を含むか、コンテンツが含まれていないのと同じOIDを使用して、一般的な応答で応答します。certreqTemplateValueには、証明書フィールドとextensionsの要件がCertTemplateの要件を含んでいます。オプションでは、キーペア生成に許容できるアルゴリズムに要件を含むキーセピックフィールドが含まれています。
The EE SHOULD follow the requirements from the received CertTemplate by including in the certificate requests all the fields requested, taking over all the field values provided and filling in any remaining fields values. The EE SHOULD NOT add further fields, name components, and extensions or their (sub)components. If deviating from the recommendations of the template, the certificate request might be rejected.
EEは、要求されたすべてのフィールドを証明書にリクエストし、提供されたすべてのフィールド値を引き継ぎ、残りのフィールド値に記入することにより、受信したCertTemplateからの要件に従う必要があります。EEは、さらにフィールド、名前コンポーネント、拡張機能またはその（サブ）コンポーネントを追加しないでください。テンプレートの推奨事項から逸脱している場合、証明書要求が拒否される可能性があります。
Note: We deliberately do not use "MUST" or "MUST NOT" here in order to allow more flexibility in case the rules given here are not sufficient for specific scenarios. The EE can populate the certificate request as wanted and ignore any of the requirements contained in the CertReqTemplateValue. On the other hand, a PKI management entity is free to ignore or replace any parts of the content of the certificate request provided by the EE. The CertReqTemplate PKI management operation offers means to ease a joint understanding of which fields and/or which field values should be used. An example is provided in Appendix A.
注：ここで指定されたルールが特定のシナリオに十分ではない場合に、より柔軟性を高めるために、ここで「必須」または「そうでない」を使用しないでください。EEは、希望どおりに証明書要求に登録でき、certreqtemplatevalueに含まれる要件を無視できます。一方、PKI管理エンティティは、EEが提供する証明書要求のコンテンツの部分を無視または交換することができます。CertreqTemplate PKI管理操作は、どのフィールドおよび/またはどのフィールド値を使用するかについての共同理解を容易にすることを提供します。例は、付録Aに記載されています。
In case a field of type Name, e.g., subject, is present in the CertTemplate but has the value NULL-DN (i.e., has an empty list of relative distinguished name (RDN) components), the field SHOULD be included in the certificate request and filled with content provided by the EE. Similarly, in case an X.509v3 extension is present but its extnValue is empty, this means that the extension SHOULD be included and filled with content provided by the EE. In case a Name component, for instance, a common name or serial number, is given but has an empty string value, the EE SHOULD fill in a value. Similarly, in case an extension has subcomponents (e.g., an IP address in a SubjectAltName field) with empty values, the EE SHOULD fill in a value.
タイプ名、例えば件名のフィールドがcerttemplateに存在するが、値null-dn（つまり、相対的な著名な名前（RDN）コンポーネントの空のリストがある）がある場合、フィールドは証明書リクエストに含める必要がありますEEが提供するコンテンツで満たされています。同様に、x.509v3拡張が存在するが、そのextnValueが空である場合、これは拡張を含めてEEが提供するコンテンツで満たす必要があることを意味します。たとえば、名前コンポーネントが共通名またはシリアル番号が指定されているが、文字列値が空の場合、EEは値を入力する必要があります。同様に、拡張機能に空の値を持つサブコンポーネント（たとえば、subjectaltnameフィールドのIPアドレス）がある場合、EEは値を埋める必要があります。
The EE MUST ignore (i.e., not include) empty fields, extensions, and subcomponents that it does not understand or does not know suitable values to fill in.
EEは、記入するのに適した値を理解していない、または知らない空のフィールド、拡張機能、およびサブコンポーネントを無視する（つまり、含まない）必要があります。
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue MUST be omitted. In case the PKI management entity wishes to make a stipulation on algorithms the EE may use for key generation, this MUST be specified using the keySpec field as specified in Section 2.16 of CMP Updates [RFC9480].
certreqtemplatevalueのcerttemplateにあるsubjectpublickeyinfoのタイプのpublickeyフィールドを省略する必要があります。PKI管理エンティティが、EEがキー生成に使用するアルゴリズムの規定を希望する場合、これはCMP更新[RFC9480]のセクション2.16で指定されているキーセピックフィールドを使用して指定する必要があります。
The keySpec field, if present, specifies the public key types optionally with parameters and/or RSA key lengths for which a certificate may be requested.
keyspecフィールドは、存在する場合、公開キーのタイプをオプションで指定します。
The value of a keySpec element with the OID id-regCtrl-algId, as specified in Section 2.16 of CMP Updates [RFC9480], MUST be of type AlgorithmIdentifier and give an algorithm other than RSA. For Elliptic Curve (EC) keys, the curve information MUST be specified as described in the respective standard documents.
CMPアップデート[RFC9480]のセクション2.16で指定されているように、OID ID-Regctrl-Algidを使用したキーセピック要素の値は、型アルゴリズム産物である必要があり、RSA以外のアルゴリズムを与える必要があります。楕円曲線（EC）キーの場合、それぞれの標準ドキュメントで説明されているように、曲線情報を指定する必要があります。
The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as specified in Section 2.16 of CMP Updates [RFC9480], MUST be a positive integer value and give an RSA key length.
CMPアップデート[RFC9480]のセクション2.16で指定されているように、OID ID-regctrl-rsakeylenを使用したキーセピック要素の値は、正の整数値であり、RSAキーの長さを与える必要があります。
In the CertTemplate of the CertReqTemplateValue, the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST be omitted.
certreqtemplatevalueのcerttemplateでは、Serialnumber、Signivingalg、Issueruid、およびsubjectuidフィールドを省略する必要があります。
The specific prerequisites augmenting the prerequisites in Section 3.4 is as follows:
セクション3.4の前提条件を強化する特定の前提条件は、次のとおりです。
* When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
* GeneralInfo Field CertProfileを使用する場合、EEは要求された証明書プロファイルを示すために必要な識別子を知っている必要があります。
The message sequence for this PKI management operation is as given above, with the following specific content:
このPKI管理操作のメッセージシーケンスは、次の特定のコンテンツとともに上記のとおりです。
1. the infoType OID to use is id-it-certReqTemplate
1. 使用するインフォタイプOIDは、ID-IT-CertreqTemplateです
2. the id-it-certProfile generalInfo field in the header of the request MAY contain the name of the requested certificate request template
2. リクエストのヘッダーにあるID-It-CertProfile generalInfoフィールドには、要求された証明書リクエストテンプレートの名前が含まれている場合があります
3. the infoValue of the request MUST be absent
3. リクエストの情報値はない必要があります
4. if present, the infoValue of the response MUST be a CertReqTemplateValue containing a CertTemplate structure and an optional keySpec field
4. 存在する場合、応答の情報値は、certreqtemplatevalueでなければなりません。
Detailed Description of the infoValue Field of genp:
Genpの情報値フィールドの詳細な説明：
InfoValue OPTIONAL
-- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any
-- requirements on the contents of the certificate template
certTemplate REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the required CertTemplate structure elements
-- The SubjectPublicKeyInfo field MUST be absent
keySpec OPTIONAL
-- MUST be absent if no requirements on the public key are
-- available
-- MUST be present if the PKI management entity has any
-- requirements on the keys generated
-- MUST contain a sequence of one AttributeTypeAndValue per
-- supported algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen
This PKI management operation can be used by an EE to request a new CRL. If a CA offers methods to access a CRL, it may include CRL distribution points or authority information access extensions into the issued certificates as specified in [RFC5280]. In addition, CMP offers CRL provisioning functionality as part of the PKI management operation.
このPKI管理操作は、EEが新しいCRLを要求するために使用できます。CAがCRLにアクセスする方法を提供する場合、[RFC5280]で指定されているように、CRL配信ポイントまたは権限情報アクセス拡張機能を発行された証明書に含めることができます。さらに、CMPはPKI管理操作の一部としてCRLプロビジョニング機能を提供します。
An EE requests a CRL update from the PKI management entity by sending a general message with OID id-it-crlStatusList. The EE MUST include the CRL source identifying the requested CRL and, if available, the thisUpdate time of the most current CRL instance it already has, as specified in Section 2.17 of CMP Updates [RFC9480]. The PKI management entity MUST respond with a general response with OID id-it-crls.
EEは、OID-IT-CRLSTATUSLISTで一般的なメッセージを送信することにより、PKI管理エンティティからCRLアップデートを要求します。EEには、要求されたCRLを識別するCRLソースを含める必要があります。利用可能な場合は、CMP更新のセクション2.17で指定されているように[RFC9480]のセクション2.17で指定されているように、既に現在のCRLインスタンスの最新のインスタンスのこの時間を含める必要があります。PKI管理エンティティは、OID ID-IT-CRLSを使用して一般的な応答で応答する必要があります。
The EE MUST identify the requested CRL either by a CRL distribution point name or issuer name.
EEは、CRL配布ポイント名または発行者名のいずれかで要求されたCRLを識別する必要があります。
Note: CRL distribution point names can be obtained from a cRLDistributionPoints extension of a certificate to be validated or from an issuingDistributionPoint extension of the CRL to be updated. CRL issuer names can be obtained from the cRLDistributionPoints extension of a certificate, from the issuer field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.
注：CRL配布ポイント名は、検証する証明書のcrldistributionPoints拡張から取得するか、更新するCRLの発行配信分布拡張から取得できます。CRL発行者名は、証明書のCRLDistributionPoints拡張、証明書またはCRLの権限識別子拡張機能の発行者フィールド、および証明書またはCRLの発行者フィールドから取得できます。
If a thisUpdate value was given, the PKI management entity MUST return the latest CRL available from the referenced source if this CRL is more recent than the given thisUpdate time. If no thisUpdate value was given, it MUST return the latest CRL available from the referenced source. In all other cases, the infoValue in the response message MUST be absent.
このupdate値が与えられた場合、PKI管理エンティティは、このCRLが特定のタイムよりも最近である場合、参照されたソースから利用可能な最新のCRLを返す必要があります。これが指定されていない場合、参照されたソースから利用可能な最新のCRLを返す必要があります。他のすべての場合、応答メッセージのInfoValueは存在しない必要があります。
The PKI management entity should treat a CRL distribution point name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CRL from an external location, as this location may be unavailable to that PKI management entity.
PKI管理エンティティは、CRL配信ポイント名を内部ポインターとして扱う必要があります。これは、PKI管理エンティティで直接利用可能なCRLを特定する必要があります。この場所はそのPKI管理エンティティが利用できない可能性があるため、外部の場所から任意のCRLを取得する方法として意図されていません。
In addition to the prerequisites specified in Section 3.4, the EE MUST know which CRL to request.
セクション3.4で指定された前提条件に加えて、EEはどのCRLを要求するかを知る必要があります。
Note: If the EE does not want to request a specific CRL, it MAY instead use a general message with OID id-it-currentCrl as specified in Section 5.3.19.6 of [RFC4210].
注：EEが特定のCRLを要求したくない場合、[RFC4210]のセクション5.3.19.6で指定されているように、OID ID-IT-CurrentCrlを使用して一般的なメッセージを使用する場合があります。
The message sequence for this PKI management operation is as given above, with the following specific content:
このPKI管理操作のメッセージシーケンスは、次の特定のコンテンツとともに上記のとおりです。
1. the infoType OID to use is id-it-crlStatusList in the request and id-it-crls in the response
1. 使用するインフォタイプOIDは、リクエストのID-IT-CRLSTATUSLISTであり、応答ではID-IT-CRLSです
2. the infoValue of the request MUST be present and contain a sequence of one CRLStatus structure
2. リクエストの情報値は存在し、1つのcrlstatus構造のシーケンスを含める必要があります
3. if present, the infoValue of the response MUST contain a sequence of one CRL
3. 存在する場合、応答の情報値には1つのCRLのシーケンスを含める必要があります
Detailed Description of the infoValue Field of genm:
GENMの情報値フィールドの詳細な説明：
infoValue REQUIRED
-- MUST contain a sequence of one CRLStatus element
source REQUIRED
-- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element.
thisUpdate OPTIONAL
-- MUST contain the thisUpdate field of the latest CRL the EE
-- has gotten from the issuer specified in the given dpn or
-- issuer field
-- MUST be omitted if the EE does not have any instance of the
-- requested CRL
Detailed Description of the infoValue Field of genp:
Genpの情報値フィールドの詳細な説明：
infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available
-- MUST contain a sequence of one CRL update from the referenced
-- source if a thisUpdate value was not given or a more recent
-- CRL is available
This is a variant of all PKI management operations described in this document. It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication or due to delays in handling the request. The polling mechanism has been specified in Section 5.3.22 of [RFC4210] and updated by [RFC9480].
これは、このドキュメントで説明されているすべてのPKI管理操作のバリアントです。通常、オフラインまたは非同期の上流通信またはリクエストの処理の遅延が原因で、PKI管理エンティティがリクエストメッセージにタイムリーに応答できない場合に開始されます。ポーリングメカニズムは、[RFC4210]のセクション5.3.22で指定されており、[RFC9480]によって更新されています。
Depending on the PKI architecture, the entity initiating delayed delivery is not necessarily the PKI management entity directly addressed by the EE.
PKIアーキテクチャに応じて、遅延配信を開始するエンティティは、必ずしもEEが直接扱うPKI管理エンティティではありません。
When initiating delayed delivery of a message received from an EE, the PKI management entity MUST respond with a message including the status "waiting". In response to an ir/cr/kur/p10cr message, it must place the status "waiting" in an ip/cp/kup message and for responses to other request message types in an error message. On receiving this response, the EE MUST store in its transaction context the senderNonce of the preceding request message because this value will be needed for checking the recipNonce of the final response to be received after polling. It sends a poll request with certReqId 0 if referring to the CertResponse element contained in the ip/cp/kup message, else -1 to refer to the whole message. In case the final response is not yet available, the PKI management entity that initiated the delayed delivery MUST answer with a poll response with the same certReqId. The included checkAfter time value indicates the minimum number of seconds that should elapse before the EE sends a new pollReq message to the PKI management entity. Polling earlier than indicated by the checkAfter value may increase the number of message round trips. This is repeated until a final response is available or any party involved gives up on the current PKI management operation, i.e., a timeout occurs.
EEから受信したメッセージの遅延配信を開始する場合、PKI管理エンティティは、ステータス「待機」を含むメッセージで応答する必要があります。IR/CR/KUR/P10CRメッセージに応じて、IP/CP/KUPメッセージにステータス「待機」を配置し、エラーメッセージの他のリクエストメッセージタイプへの応答を配置する必要があります。この応答を受信すると、EEはトランザクションのコンテキストで、ポーリング後に受信する最終的な応答の受信をチェックするためにこの値が必要になるため、前述のリクエストメッセージのSendernonceを保存する必要があります。IP/CP/KUPメッセージに含まれるCertResponse要素を参照する場合、CertreQid 0のポーリングリクエストを送信します。最終的な応答がまだ利用できない場合、遅延配信を開始したPKI管理エンティティは、同じcertreqidを使用した世論調査で回答する必要があります。含まれているチェックアフター時間値は、EEがPKI管理エンティティに新しいPollReqメッセージを送信する前に経過する最小秒数を示します。Checkafter値で示されるよりも早くポーリングすると、メッセージラウンドトリップの数が増加する可能性があります。これは、最終的な応答が利用可能になるか、関係する当事者が現在のPKI管理操作、つまりタイムアウトが発生するまで繰り返されます。
When the PKI management entity that initiated delayed delivery can provide the final response for the original request message of the EE, it MUST send this response to the EE. Using this response, the EE can continue the current PKI management operation as usual.
遅延配信を開始したPKI管理エンティティが、EEの元のリクエストメッセージの最終的な応答を提供できる場合、この応答をEEに送信する必要があります。この応答を使用して、EEは通常どおり現在のPKI管理操作を継続できます。
No specific prerequisites apply in addition to those of the respective PKI management operation.
それぞれのPKI管理操作に加えて、特定の前提条件は適用されません。
Message Flow:
メッセージフロー：
Step# EE PKI management entity
1 format request
message
2 -> request ->
3 handle or forward
request
4 format ip/cp/kup/error
with status "waiting"
response in case no
immediate final response
is available
5 <- ip/cp/kup/error <-
6 handle
ip/cp/kup/error
with status
"waiting"
-------------------------- start polling --------------------------
7 format pollReq
8 -> pollReq ->
9 handle or forward pollReq
10 in case the final response
for the original request
is available, continue
with step 14
otherwise, format or
receive pollRep with
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse and
continue with
step 7
----------------- end polling, continue as usual ------------------
14 format or receive
final response on
the original request
15 <- response <-
16 handle final
response
Detailed Message Description:
詳細なメッセージ説明：
Response with Status "waiting" -- ip/cp/kup/error
Field Value
header
-- As described in Section 3.1
body
-- As described for the respective PKI management operation, with
-- the following adaptations:
status REQUIRED -- in case of ip/cp/kup
pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be status "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo PROHIBITED
protection REQUIRED
-- As described in Section 3.2
extraCerts OPTIONAL
-- As described in Section 3.3
Polling Request -- pollReq
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE asking for the final response or for a
-- time to check again
pollReq REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of the PKI management operation
Polling Response -- pollRep
Field Value
header
-- As described in Section 3.1
body
-- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction
pollRep REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED
-- MUST be the time in seconds to elapse before a new pollReq
-- should be sent
reason OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of the PKI management operation
Final Response - Any Type of Response Message
Field Value
header
-- MUST be the header, as described for the response message
-- of the respective PKI management operation
body
-- The response of the PKI management entity to the initial
-- request, as described in the respective PKI management
-- operation
protection REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation
extraCerts REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation
This section focuses on request processing by a PKI management entity. Depending on the network and PKI solution design, this can be an RA or CA, any of which may include protocol conversion or central key generation (i.e., acting as a KGA).
このセクションでは、PKI管理エンティティによるリクエスト処理に焦点を当てています。ネットワークとPKIソリューションの設計に応じて、これはRAまたはCAである可能性があります。これには、プロトコル変換または中央キー生成（つまり、KGAとして機能する）が含まれる場合があります。
A PKI management entity may directly respond to request messages from downstream and report errors. In case the PKI management entity is an RA, it typically forwards the received request messages upstream after checking them and forwards respective response messages downstream. Besides responding to messages or forwarding them, a PKI management entity may request or revoke certificates on behalf of EEs. A PKI management entity may also need to manage its own certificates and thus act as an EE using the PKI management operations specified in Section 4.
PKI管理エンティティは、ダウンストリームからのリクエストメッセージに直接応答し、エラーをレポートする場合があります。PKI管理エンティティがRAである場合、通常、受け取ったリクエストメッセージをチェックして、それぞれの応答メッセージを下流に転送した後、上流のリクエストメッセージを転送します。メッセージに応答したり、それらを転送したりすることに加えて、PKI管理エンティティは、EESに代わって証明書を要求または取り消すことができます。PKI管理エンティティは、独自の証明書を管理する必要がある場合があり、セクション4で指定されたPKI管理操作を使用してEEとして機能する必要があります。
The PKI management entity terminating the PKI management operation at CMP level MUST respond to all received requests by returning a related CMP response message or an error. Any intermediate PKI management entity MAY respond, depending on the PKI configuration and policy.
CMPレベルでのPKI管理操作を終了するPKI管理エンティティは、関連するCMP応答メッセージまたはエラーを返すことにより、受信したすべての要求に応答する必要があります。中間のPKI管理エンティティは、PKIの構成とポリシーに応じて応答する場合があります。
In addition to the checks described in Section 3.5, the responding PKI management entity MUST check that a request that initiates a new PKI management operation does not use a transactionID that is currently in use. The failInfo bit value to use is transactionIdInUse as described in Section 3.6.4. If any of these verification steps or any of the essential checks described in Section 3.5 and in the following subsections fails, the PKI management entity MUST proceed as described in Section 3.6.
セクション3.5で説明したチェックに加えて、応答するPKI管理エンティティは、新しいPKI管理操作を開始するリクエストが現在使用されているTransactionIDを使用しないことを確認する必要があります。使用するFailInfoビット値は、セクション3.6.4で説明されているようにTransactionidinuseです。これらの検証手順のいずれかまたはセクション3.5で説明されている重要なチェックのいずれかおよび以下のサブセクションが失敗した場合、PKI管理エンティティはセクション3.6で説明されているとおり、進行する必要があります。
The responding PKI management entity MUST copy the sender field of the request to the recipient field of the response, MUST copy the senderNonce of the request to the recipNonce of the response, and MUST use the same transactionID for the response.
応答するPKI管理エンティティは、リクエストの送信者フィールドを応答の受信者フィールドにコピーし、リクエストのsendernonceを応答の受信にコピーする必要があり、応答に同じトランザクションIDを使用する必要があります。
An ir/cr/kur/p10cr message is used to request a certificate as described in Section 4.1. The responding PKI management entity MUST proceed as follows unless it initiates delayed delivery as described in Section 5.1.5.
IR/CR/KUR/P10CRメッセージは、セクション4.1で説明されているように証明書を要求するために使用されます。応答するPKI管理エンティティは、セクション5.1.5で説明されているように、遅延配信を開始しない限り、次のように続行する必要があります。
The PKI management entity MUST check the message body according to the applicable requirements from Section 4.1. Possible failInfo bit values used for error reporting in case a check failed include badCertId and badCertTemplate. It MUST verify the presence and value of the proof-of-possession (failInfo bit: badPOP) unless central key generation is requested. If a signature-based proof-of-possession is present, the PKI management entity MUST verify, based on local PKI policy, that the subject name in the certTemplate identifies the same entity as the subject name in the CMP protection certificate or matches the identifier used with MAC-based protection. In case this verification fails, the message MUST have been protected by an authorized PKI management entity (failInfo bit: notAuthorized). If the special POP value "raVerified" is given, the PKI management entity should check that the request message was signed using a certificate containing the cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management entity should also perform any further checks on the certTemplate contents (failInfo: badCertTemplate) according to any applicable PKI policy and certificate profile.
PKI管理エンティティは、セクション4.1からの該当する要件に従ってメッセージ本文を確認する必要があります。チェックに障害が発生した場合にエラー報告に使用される可能性のあるfailinfoビット値は、badcertidとbadcerttemplateが含まれます。中央のキー生成が要求されない限り、所有証明の存在と価値を検証する必要があります（failinfo bit：badpop）。署名ベースのプルーフオブポスセッションが存在する場合、PKI管理エンティティは、ローカルPKIポリシーに基づいて、CERTTEMPLATEの主題名がCMP保護証明書のサブジェクト名と同じエンティティを識別するか、識別子と一致することを確認する必要があります。Macベースの保護で使用されます。この検証が失敗した場合、メッセージは承認されたPKI管理エンティティによって保護されている必要があります（FailInfo BIT：NOTAUTHORIZED）。特別なポップ値「raverified」が与えられた場合、PKI管理エンティティは、CMCRA拡張キー使用量を含む証明書を使用して要求メッセージに署名されたことを確認する必要があります（failinfo bit：notauthorized）。PKI管理エンティティは、該当するPKIポリシーと証明書プロファイルに従って、CertTemplateコンテンツ（FailInfo：BadCertTemplate）のさらにチェックを実行する必要があります。
If the requested certificate is available, the PKI management entity MUST respond with a positive ip/cp/kup message as described in Section 4.1.
要求された証明書が利用可能な場合、PKI管理エンティティは、セクション4.1で説明されているように、肯定的なIP/CP/KUPメッセージで応答する必要があります。
Note: If central key generation is performed by the responding PKI management entity, the responding PKI management entity MUST include the private key in encrypted form in the response as specified in Section 4.1.6.
注：対応するPKI管理エンティティによって中央キー生成が実行される場合、応答するPKI管理エンティティには、セクション4.1.6で指定されているように、応答に暗号化された形式の秘密鍵を含める必要があります。
The prerequisites of the respective PKI management operation specified in Section 4.1 apply.
セクション4.1で指定されたそれぞれのPKI管理操作の前提条件が適用されます。
If the EE requested omission of the certConf message, the PKI management entity MUST handle it as described in Section 4.1.1. Therefore, it MAY grant this by including the implicitConfirm generalInfo field or including the confirmWaitTime field in the response header.
EEがCERTCONFメッセージの省略を要求した場合、PKI管理エンティティはセクション4.1.1で説明されているようにそれを処理する必要があります。したがって、ImplicitConfirm generalInfoフィールドを含めるか、応答ヘッダーに確認waittimeフィールドを含めることにより、これを許可する場合があります。
A PKI management entity MUST handle a certConf message if it has responded before with a positive ip/cp/kup message not granting implicit confirmation. It should check the message body according to the requirements given in Section 4.1.1 (failInfo bit: badCertId) and MUST react as described there.
PKI管理エンティティは、暗黙の確認を許可しない肯定的なIP/CP/KUPメッセージで以前に応答した場合、CertConfメッセージを処理する必要があります。セクション4.1.1（FailInfo Bit：BadCertid）に記載されている要件に従ってメッセージ本体を確認する必要があり、そこで説明したように反応する必要があります。
The prerequisites of the respective PKI management operation specified in Section 4.1 apply.
セクション4.1で指定されたそれぞれのPKI管理操作の前提条件が適用されます。
An rr message is used to request revocation of a certificate. The responding PKI management entity should check the message body according to the requirements in Section 4.2. It MUST make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or revoked (failInfo bit: certRevoked). On success, it MUST respond with a positive rp message, as described in Section 4.2.
RRメッセージは、証明書の取り消しを要求するために使用されます。応答するPKI管理エンティティは、セクション4.2の要件に従ってメッセージ本文を確認する必要があります。参照されている証明書が存在することを確認する必要があります（failinfo bit：badcertid）が扱われ、宛てられたCAによって発行されており、まだ期限切れまたは撤回されていません（failinfo bit：certrevoked）。成功すると、セクション4.2で説明されているように、肯定的なRPメッセージで応答する必要があります。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
A genm message is used to retrieve extra content. The responding PKI management entity should check the message body according to the applicable requirements in Section 4.3 and perform any further checks depending on the PKI policy. On success, it MUST respond with a genp message as described there.
GENMメッセージは、追加のコンテンツを取得するために使用されます。応答するPKI管理エンティティは、セクション4.3の該当する要件に従ってメッセージ本体を確認し、PKIポリシーに応じてさらにチェックを実行する必要があります。成功すると、そこに記載されているようにGenpメッセージで応答する必要があります。
Note: The responding PKI management entity may generate the response from scratch or reuse the contents of previous responses. Therefore, it may be worth caching the body of the response message as long as the contained information is valid and current, such that further requests for the same contents can be answered immediately.
注：応答するPKI管理エンティティは、ゼロから応答を生成するか、以前の応答の内容を再利用する場合があります。したがって、含まれている情報が有効かつ最新である限り、応答メッセージの本文をキャッシュする価値があるため、同じコンテンツのさらなる要求にすぐに回答できるようにする価値があります。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
This functional extension can be used by a PKI management entity in case the response to a request takes longer than usual. In this case, the PKI management entity should completely validate the request as usual and then start processing the request itself or forward it further upstream as soon as possible. In the meantime, it MUST respond with an ip/cp/kup/error message including the status "waiting" and handle subsequent polling as described in Section 4.4.
この機能的拡張は、リクエストへの応答が通常よりも時間がかかる場合に備えて、PKI管理エンティティで使用できます。この場合、PKI管理エンティティは通常どおりリクエストを完全に検証し、リクエスト自体の処理を開始するか、できるだけ早く上流に転送する必要があります。それまでの間、ステータス「待機」を含むIP/CP/KUP/エラーメッセージで応答する必要があり、セクション4.4で説明されているように後続のポーリングを処理する必要があります。
Typically, as stated in Section 5.2.3, an intermediate PKI management entity should not change the sender and recipient nonces even in case it modifies a request or a response message. In the special case of delayed delivery initiated by an intermediate PKI management entity, there is an exception. Between the EE and this PKI management entity, pollReq and pollRep messages are exchanged handling the nonces as usual. Yet when the final response from upstream has arrived at the PKI management entity, this response contains the recipNonce copied (as usual) from the senderNonce in the original request message. The PKI management entity that initiated the delayed delivery MAY replace the recipNonce in the response message with the senderNonce of the last received pollReq because the downstream entities, including the EE, might expect it in this way. Yet the check specified in Section 3.5 allows alternate use of the senderNonce of the original request.
通常、セクション5.2.3に記載されているように、中間のPKI管理エンティティは、リクエストまたは応答メッセージを変更した場合でも、送信者と受信者のノンセットを変更してはなりません。中間PKI管理エンティティによって開始された遅延配信の特別なケースでは、例外があります。EEとこのPKI管理エンティティの間で、PollreqとPollrepメッセージは、通常どおりNoncesを処理することが交換されます。しかし、上流からの最終的な応答がPKI管理エンティティに到着したとき、この応答には、元のリクエストメッセージのsendernonceから（通常どおり）コピーされたRecipnonceが含まれています。遅延配信を開始したPKI管理エンティティは、回答メッセージのRecipnonceを、EEを含む下流のエンティティがこの方法でそれを期待する可能性があるため、最後に受け取ったPollreqのSendernonceに置き換えることができます。しかし、セクション3.5で指定されたチェックは、元のリクエストのsendernonceを代替することを可能にします。
No specific prerequisites apply in addition to those of the respective PKI management operation.
それぞれのPKI管理操作に加えて、特定の前提条件は適用されません。
In case the PKI solution consists of intermediate PKI management entities (i.e., LRA or RA), each CMP request message coming from an EE or any other downstream PKI management entity MUST either be forwarded to the next (upstream) PKI management entity as described in this section, or answered as described in Section 5.1. Any received response message or a locally generated error message MUST be forwarded to the next (downstream) PKI entity.
PKIソリューションが中間PKI管理エンティティ（つまり、LRAまたはRA）で構成されている場合、EEまたはその他の下流のPKI管理エンティティからの各CMP要求メッセージは、次の（上流）PKI管理エンティティに転送する必要があります。このセクション、またはセクション5.1で説明されているように回答します。受信した応答メッセージまたはローカルで生成されたエラーメッセージは、次の（下流の）PKIエンティティに転送する必要があります。
In addition to the checks described in Section 3.5, the forwarding PKI management entity MAY verify the proof-of-possession for ir/cr/kur/p10cr messages. If one of these verification procedures fails, the RA proceeds as described in Section 3.6.
セクション3.5で説明されているチェックに加えて、転送PKI管理エンティティは、IR/CR/KUR/P10CRメッセージの所有証明を検証する場合があります。これらの検証手順のいずれかが失敗した場合、RAはセクション3.6で説明されているように進行します。
A PKI management entity SHOULD NOT change the received message unless its role in the PKI system requires it. This is because changes to the message header or body imply reprotection. Changes to the protection breaks end-to-end authentication of the message source. Changes to the certificate template in a certificate request breaks proof-of-possession. More details are available in the following subsections. Concrete PKI system specifications may define when to do so in more detail.
PKIシステムでの役割が必要とされない限り、PKI管理エンティティは受信したメッセージを変更しないでください。これは、メッセージヘッダーまたはボディの変更が再検出を意味するためです。保護の変更は、メッセージソースのエンドツーエンド認証を破ります。証明書リクエストの証明書テンプレートの変更は、所有の証明を破ります。詳細については、次のサブセクションをご覧ください。コンクリートPKIシステムの仕様では、いつより詳細に行うかを定義する場合があります。
This is particularly relevant in the upstream communication of a request message.
これは、要求メッセージの上流通信に特に関連しています。
Each forwarding PKI management entity has one or more functionalities. It may:
各転送PKI管理エンティティには、1つ以上の機能があります。それはかもしれません：
* verify the identities of EEs and make authorization decisions for certification request processing based on local PKI policy,
* EESのIDを確認し、ローカルPKIポリシーに基づいて認証要求処理のための承認決定を下します。
* add or modify fields of certificate request messages,
* 証明書要求メッセージのフィールドを追加または変更し、
* replace a MAC-based protection with a signature-based protection that can also be verified further upstream and vice versa,
* Macベースの保護を署名ベースの保護に置き換えます。これは、さらに上流で検証することもでき、その逆も同様です。
* double-check if the messages transferred back and forth are properly protected and well-formed,
* 前後に転送されたメッセージが適切に保護されており、よく形成されている場合は、再確認してください。
* provide an authentic indication that it has performed all required checks,
* 必要なすべてのチェックを実行したという本物の兆候を提供し、
* initiate a delayed delivery due to delays transferring messages or handling requests, or
* メッセージの転送または処理リクエストの遅延により、配信の遅延を開始する、または
* collect messages from multiple RAs and forward them jointly.
* 複数のRAからメッセージを収集し、共同で転送します。
Note: PKI management entities forwarding messages may also store data from a message in a database for later usage or audit purposes. They may also support traversal of a network boundary.
注：PKI管理エンティティの転送メッセージは、後の使用または監査目的で、データベースにメッセージからデータを保存することもできます。また、ネットワーク境界のトラバーサルをサポートする場合があります。
The decision if a message should be forwarded is:
メッセージを転送する必要があるかどうかの決定は次のとおりです。
* unchanged with the original protection,
* 元の保護に変更されていない、
* unchanged with an additional protection, or
* 追加の保護が変更されていない、または
* changed with an additional protection
* 追加の保護で変更されました
depending on the PKI solution design and the associated security policy, e.g., as defined in the certificate policy (CP) / certification practice statement (CPS) documents [RFC3647].
PKIソリューションの設計と関連するセキュリティポリシーに応じて、例えば、証明書ポリシー（CP） /認証実践ステートメント（CPS）文書[RFC3647]で定義されています。
A PKI management entity SHOULD add or MAY replace a protection of a message if it
PKI管理エンティティは、メッセージの保護を追加または置き換える必要があります。
* needs to securely indicate that it has done checks or validations on the message to one of the next (upstream) PKI management entities or
* 次の（上流の）PKI管理エンティティのいずれかへのメッセージでチェックまたは検証を行ったことを安全に示す必要があります。
* needs to protect the message using a key and certificate from a different PKI.
* 別のPKIからキーと証明書を使用してメッセージを保護する必要があります。
If retaining end-to-end message authentication is required, an additional protection SHALL be added instead of replacing the original protection.
エンドツーエンドのメッセージ認証を保持する必要がある場合、元の保護を交換する代わりに追加の保護を追加するものとします。
A PKI management entity MUST replace a protection of a message if it
PKI管理エンティティは、メッセージの保護を置き換える必要があります
* performs changes to the header or the body of the message or
* メッセージのヘッダーまたは本文の変更を実行するか
* needs to convert from or to a MAC-based protection.
* Macベースの保護からまたはMacベースの保護に変換する必要があります。
This is particularly relevant in the upstream communication of certificate request messages.
これは、証明書要求メッセージの上流通信に特に関連しています。
Note that the message protection covers only the header and the body and not the extraCerts. The PKI management entity MAY change the extraCerts in any of the following message adaptations, e.g., to sort, add, or delete certificates to support subsequent PKI entities. This may be particularly helpful to augment upstream messages with additional certificates or to reduce the number of certificates in downstream messages when forwarding to constrained devices.
メッセージ保護は、ヘッダーとボディのみをカバーし、エクストラメートではないことに注意してください。PKI管理エンティティは、次のメッセージ適応のいずれかでエクストラメートを変更する場合があります。たとえば、証明書を並べ替え、追加、または削除して、後続のPKIエンティティをサポートします。これは、追加の証明書を使用して上流のメッセージを強化したり、制約付きデバイスに転送する際に下流のメッセージの証明書の数を減らすことが特に役立つ場合があります。
This variant means that a PKI management entity forwards a CMP message without changing the header, body, or protection. In this case, the PKI management entity acts more like a proxy, e.g., on a network boundary, implementing no specific RA-like security functionality that requires an authentic indication to the PKI. Still, the PKI management entity might implement checks that result in refusing to forward the request message and instead responding as specified in Section 3.6.
このバリアントは、PKI管理エンティティがヘッダー、ボディ、または保護を変更せずにCMPメッセージを転送することを意味します。この場合、PKI管理エンティティはプロキシのように機能します。たとえば、ネットワーク境界では、PKIに対する本物の表示を必要とする特定のRA様セキュリティ機能を実装しません。それでも、PKI管理エンティティは、リクエストメッセージの転送を拒否し、セクション3.6で指定されているように応答することを拒否するチェックを実装する場合があります。
This variant of forwarding a message or the one described in Section 5.2.2.1 MUST be used for kur messages and for central key generation.
メッセージを転送するこのバリアントまたはセクション5.2.2.1で説明されているものは、KURメッセージおよび中央キー生成に使用する必要があります。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
This variant of forwarding a message means that a PKI management entity adds another protection to PKI management messages before forwarding them.
メッセージを転送するこのバリアントは、PKI管理エンティティがPKI管理メッセージに別の保護を追加する前に別の保護を追加することを意味します。
The nested message is a PKI management message containing a PKIMessages sequence as its body, containing one or more CMP messages.
ネストされたメッセージは、1つ以上のCMPメッセージを含む、その本体としてのpkimessagesシーケンスを含むPKI管理メッセージです。
As specified in the updated Section 5.1.3.4 of [RFC4210] (also see Section 2.6 of CMP Updates [RFC9480]), there are various use cases for adding another protection by a PKI management entity. Specific procedures are described in more detail in the following sections.
[RFC4210]の更新されたセクション5.1.3.4で指定されているように（CMP更新のセクション2.6 [RFC9480]も参照）、PKI管理エンティティによる別の保護を追加するためのさまざまなユースケースがあります。特定の手順については、次のセクションで詳しく説明します。
Detailed Message Description:
詳細なメッセージ説明：
Nested Message - nested
Field Value
header
-- As described in Section 3.1
body
-- Container to provide additional protection to original
-- messages and to bundle request messages or alternatively
-- response messages
PKIMessages REQUIRED
-- MUST be a sequence of one or more CMP messages
protection REQUIRED
-- As described in Section 3.2, using the CMP protection key of
-- the PKI management entity
extraCerts REQUIRED
-- As described in Section 3.3
This variant means that a PKI management entity forwards a CMP message while authentically indicating successful validation and approval of a request message without changing the original message authentication.
このバリアントは、PKI管理エンティティがCMPメッセージを転送しながら、元のメッセージ認証を変更せずにリクエストメッセージの検証と承認の成功を認証することを意味します。
By adding a protection using its own CMP protection key, the PKI management entity provides a proof of verifying and approving the message, as described above. Thus, the PKI management entity acts as an actual registration authority (RA), which implements important security functionality of the PKI. Applying an additional protection is specifically relevant when forwarding a message that requests a certificate update or central key generation. This is because the original protection of the EE needs to be preserved while adding an indication of approval by the PKI management entity.
PKI管理エンティティは、独自のCMP保護キーを使用して保護を追加することにより、上記のようにメッセージを検証および承認する証拠を提供します。したがって、PKI管理エンティティは、PKIの重要なセキュリティ機能を実装する実際の登録機関（RA）として機能します。追加の保護を適用することは、証明書の更新または中央キー生成を要求するメッセージを転送するときに特に関連します。これは、PKI管理エンティティによる承認の兆候を追加しながら、EEの元の保護を保存する必要があるためです。
The PKI management entity wrapping the original request message in a nested message structure MUST copy the values of the senderNonce and transactionID header fields of the original message to the respective header fields of the nested message and apply signature-based protection. The additional signature serves as proof of verification and authorization by this PKI management entity.
ネストされたメッセージ構造で元の要求メッセージをラップするPKI管理エンティティは、元のメッセージのSendernonceおよびTransactionIDヘッダーフィールドの値を、ネストされたメッセージのそれぞれのヘッダーフィールドにコピーし、署名ベースの保護を適用する必要があります。追加の署名は、このPKI管理エンティティによる検証と承認の証明として機能します。
The PKI management entity receiving such a nested message that contains a single request message MUST validate the additional protection signature on the nested message and check the authorization for the approval it implies. Other fields in the header of the nested message can be ignored.
単一のリクエストメッセージを含むこのようなネストされたメッセージを受信するPKI管理エンティティは、ネストされたメッセージの追加の保護署名を検証し、それが暗示する承認を確認する必要があります。ネストされたメッセージのヘッダー内の他のフィールドは無視できます。
The PKI management entity responding to the request contained in the nested message sends the response message as described in Section 5.1, without wrapping it in a nested message.
ネストされたメッセージに含まれるリクエストに応答するPKI管理エンティティは、ネストされたメッセージに包むことなく、セクション5.1で説明されているように応答メッセージを送信します。
Note: When responding to the inner request message, it must be considered that the verification and approval activity described in this section has already been performed by the PKI management entity that protected the nested message.
注：内側のリクエストメッセージに応答する場合、このセクションで説明されている検証と承認活動は、ネストされたメッセージを保護するPKI管理エンティティによってすでに実行されていると考える必要があります。
Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is the same as the one used in the included message.
注：この形式のネストメッセージは、ネストされたメッセージのヘッダーのトランザクションIDが含まれているメッセージで使用されているものと同じであるという事実によって特徴付けられます。
The specific prerequisite augmenting the prerequisites in Section 3.4 is as follows:
セクション3.4の前提条件を増強する特定の前提条件は次のとおりです。
* The PKI management entity MUST be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.
* PKI管理エンティティは、それぞれの要求を検証し、PKIポリシーに従って要求の承認を実行する許可を持つことができる必要があります。
Message Flow:
メッセージフロー：
Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle or forward nested
4 format or receive response
5 <- response <-
6 forward response
A PKI management entity MAY bundle any number of PKI management messages for batch processing or to transfer a bulk of PKI management messages using the nested message structure. In this use case, nested messages are used both on the upstream interface for transferring request messages towards the next PKI management entity and on its downstream interface for response messages.
PKI管理エンティティは、バッチ処理のために任意の数のPKI管理メッセージをバンドルするか、ネストされたメッセージ構造を使用して大量のPKI管理メッセージを転送する場合があります。このユースケースでは、ネストされたメッセージは、次のPKI管理エンティティにリクエストメッセージを転送するための上流インターフェイスの両方と、応答メッセージの下流インターフェイスの両方で使用されます。
This PKI management operation is typically used on the interface between an LRA and an RA to bundle several messages for offline or asynchronous delivery. In this case, the LRA needs to initiate delayed delivery, as described in Section 5.1.5. If the RA needs different routing information per the nested PKI management message provided upstream, a suitable mechanism may need to be implemented to ensure that the downstream delivery of the response is done to the right requester. Since this mechanism strongly depends on the requirements of the target architecture, it is out of scope of this document.
このPKI管理操作は、通常、LRAとRAの間のインターフェイスで使用され、オフラインまたは非同期配信のためにいくつかのメッセージをバンドルします。この場合、セクション5.1.5で説明されているように、LRAは遅延送達を開始する必要があります。RAが上流に提供されたネストされたPKI管理メッセージごとに異なるルーティング情報を必要とする場合、適切なメカニズムを実装する必要がある場合があります。このメカニズムはターゲットアーキテクチャの要件に大きく依存するため、このドキュメントの範囲外です。
A nested message containing requests is generated locally at the PKI management entity. For the upstream nested message, the PKI management entity acts as a protocol endpoint; therefore, a fresh transactionID and a fresh senderNonce MUST be used in the header of the nested message. An upstream nested message may contain request messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. While building the upstream nested message, the PKI management entity must store the sender, transactionID, and senderNonce fields of all bundled messages together with the transactionID of the upstream nested message.
リクエストを含むネストされたメッセージは、PKI管理エンティティでローカルに生成されます。上流のネストされたメッセージの場合、PKI管理エンティティはプロトコルエンドポイントとして機能します。したがって、新鮮なTransactionIDと新鮮なSendernonceをネストされたメッセージのヘッダーに使用する必要があります。上流のネストされたメッセージには、要求メッセージ、例えばIR、CR、P10CR、KUR、POLLREQ、CERTCONF、RR、またはGENMが含まれる場合があります。上流のネストされたメッセージを構築する際、PKI管理エンティティは、すべてのバンドルされたメッセージの送信者、TransactionID、およびSendernonceフィールドを、上流のネストされたメッセージのトランザクションIDとともに保存する必要があります。
Such an upstream nested message is sent to the next PKI management entity. The upstream PKI management entity that unbundles it MUST handle each of the included request messages as usual. It MUST answer with a downstream nested message. This downstream nested message MUST use the transactionID of the upstream nested message and return the senderNonce of the upstream nested message as the recipNonce of the downstream nested message. The downstream nested message MUST bundle all available individual response messages (e.g., ip, cp, kup, pollRep, pkiConf, rp, genp, or error) for all original request messages of the upstream nested message. While unbundling the downstream nested message, the former PKI management entity must determine lost and unexpected responses based on the previously stored transactionIDs. When it forwards the unbundled responses, any extra messages MUST be dropped, and any missing response message MUST be answered with an error message (failInfo bit: systemUnavail) to inform the respective requester about the failed certificate management operation.
このような上流のネストされたメッセージは、次のPKI管理エンティティに送信されます。包帯を解除する上流のPKI管理エンティティは、通常どおり、含まれている各リクエストメッセージを処理する必要があります。下流のネストされたメッセージで答える必要があります。この下流のネストされたメッセージは、上流のネストされたメッセージのTransactionIDを使用し、下流のネストされたメッセージのrecionnceとして上流のネストされたメッセージのSendernonceを返す必要があります。下流のネストされたメッセージは、上流のネストされたメッセージのすべての元のリクエストメッセージに対して、利用可能なすべての応答メッセージ（IP、CP、KUP、KUP、PKICONF、RP、GENP、またはエラーなど）をバンドルする必要があります。下流のネストされたメッセージを解除している間、以前のPKI管理エンティティは、以前に保存されていたTransactionIDに基づいて、失われた予期しない応答を決定する必要があります。バンドルされていない応答を転送する場合、追加のメッセージをドロップする必要があり、失敗した証明書管理操作についてそれぞれのリクエスターに通知するために、エラーメッセージ（Failinfo Bit：SystemUnavail）で欠落している応答メッセージを回答する必要があります。
Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is different to those used in the included messages.
注：この形式のネストメッセージは、ネストされたメッセージのヘッダーのトランザクションIDが含まれているメッセージで使用されているメッセージとは異なるという事実によって特徴付けられます。
The protection of the nested messages MUST NOT be regarded as an indication of verification or approval of the bundled PKI request messages.
ネストされたメッセージの保護は、バンドルされたPKI要求メッセージの検証または承認の兆候と見なされてはなりません。
No specific prerequisites apply in addition to those specified in Section 3.4.
セクション3.4で指定されているものに加えて、特定の前提条件は適用されません。
Message Flow:
メッセージフロー：
Step# PKI management entity PKI management entity
1 format nested
2 -> nested ->
3 handle or forward nested
4 format or receive nested
5 <- nested <-
6 handle nested
The following two alternatives can be used by any PKI management entity forwarding a CMP message with or without changes while providing its own protection and, in this way, asserting approval of the message.
次の2つの代替案は、CMPメッセージを変更した場合となしでCMPメッセージを転送しながら、独自の保護を提供し、このようにしてメッセージの承認を主張することで使用できます。
If retaining end-to-end message authentication is required, an additional protection SHALL be added instead of replacing the original protection.
エンドツーエンドのメッセージ認証を保持する必要がある場合、元の保護を交換する代わりに追加の保護を追加するものとします。
By replacing the existing protection using its own CMP protection key, the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual registration authority (RA), which implements important security functionality of the PKI such as verifying the proof of requester identity and authorization.
独自のCMP保護キーを使用して既存の保護を交換することにより、PKI管理エンティティは、上記のようにメッセージを検証および承認する証拠を提供します。したがって、PKI管理エンティティは、実際の登録機関（RA）として機能します。これは、リクエスターの身元の証明と承認の確認など、PKIの重要なセキュリティ機能を実装します。
Note: By replacing the message protection, the binding of a signature-based proof-of-possession to the proof-of-identity given by the original message protection gets lost. To enable the CA to verify this binding, the original message can be provided in the origPKIMessage generalInfo field.
注：メッセージ保護を交換することにより、元のメッセージ保護によって与えられた署名ベースの所有権の拘束力が失われることになります。CAがこのバインディングを検証できるようにするには、元のメッセージをOrigpKimessage GeneralInfoフィールドで提供できます。
Before replacing the existing protection with a new protection, the PKI management entity:
既存の保護を新しい保護に置き換える前に、PKI管理エンティティ：
* MUST validate the protection of the received message,
* 受信したメッセージの保護を検証する必要があります。
* should check the content of the message,
* メッセージの内容を確認する必要があります。
* may do any modifications that it wants to perform, and
* 実行したい変更を行うことができます。
* MUST check that the sender of the original message, as authenticated by the message protection, is authorized for the given operation.
* メッセージ保護によって認証されているように、元のメッセージの送信者が指定された操作に対して許可されていることを確認する必要があります。
* for certificate requests, MUST verify the binding of signature-based proof-of-possession to the proof-of-identity as described in Section 5.1.1.
* 証明書リクエストの場合、セクション5.1.1で説明されているように、署名ベースの所有権の拘束力のある所有権の拘束力を確認することを検証する必要があります。
These message adaptations MUST NOT be applied to kur messages described in Section 4.1.3 since their original protection using the key and certificate to be updated needs to be preserved.
これらのメッセージの適応は、最新のキーと証明書を使用した元の保護を保存する必要があるため、セクション4.1.3で説明されているKURメッセージに適用してはなりません。
These message adaptations MUST NOT be applied to certificate request messages described in Section 4.1.6 for central key generation since their original protection needs to be preserved up to the KGA, which needs to use it for encrypting the new private key for the EE.
これらのメッセージの適応は、元の保護をKGAまで保存する必要があるため、セントラルキー生成のセクション4.1.6で説明されている証明書要求メッセージに適用してはなりません。
In both the kur and central key generation cases, if a PKI management entity needs to state its approval of the original request message, it MUST provide this using a nested message as specified in Section 5.2.2.1.
KURと中央のキー生成ケースの両方で、PKI管理エンティティが元のリクエストメッセージの承認を述べる必要がある場合、セクション5.2.2.1で指定されたネストされたメッセージを使用してこれを提供する必要があります。
When an intermediate PKI management entity modifies a message, it MUST NOT change the transactionID, the senderNonce, or the recipNonce, apart from the exception for the recipNonce given in Section 5.1.5.
中間PKI管理エンティティがメッセージを変更する場合、セクション5.1.5で与えられたレシピノースの例外を除き、TransactionID、Sendernonce、またはRecipnonceを変更してはなりません。
This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or body while preserving any included proof-of-possession.
メッセージを転送するこのバリアントは、PKI管理エンティティが、含まれているプルーフオブポッセッションを保持しながら、メッセージヘッダーまたはボディを変更しない場合またはなしでCMPメッセージを転送することを意味します。
This variant is typically used when an RA replaces an existing MAC-based protection with its own signature-based protection; because the upstream PKI management entity does not know the respective shared secret information, replacing the protection is useful.
このバリアントは、通常、RAが既存のMacベースの保護を独自の署名ベースの保護に置き換えるときに使用されます。上流のPKI管理エンティティはそれぞれの共有秘密情報を知らないため、保護を交換することは有用です。
Note: A signature-based proof-of-possession of a certificate request will be broken if any field in the certTemplate structure is changed.
注：certTemplate構造のフィールドが変更された場合、証明書リクエストの署名ベースの入金の証明が破損します。
In case the PKI management entity breaks an existing proof-of-possession, the message adaptation described in Section 5.2.3.2 needs to be applied instead.
PKI管理エンティティが既存の所有の証明を破る場合、セクション5.2.3.2で説明されているメッセージの適応を代わりに適用する必要があります。
The specific prerequisite augmenting the prerequisites in Section 3.4 is as follows:
セクション3.4の前提条件を増強する特定の前提条件は次のとおりです。
* The PKI management entity MUST be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.
* PKI管理エンティティは、それぞれの要求を検証し、PKIポリシーに従って要求の承認を実行する許可を持つことができる必要があります。
This variant of forwarding a message needs to be used if a PKI management entity breaks any included proof-of-possession in a certificate request message, for instance, because it forwards an ir or cr message with modifications of the certTemplate, i.e., modification, addition, or removal of fields.
たとえば、PKI管理エンティティが証明書リクエストメッセージに含まれたプルーフオブポッセッションを破損する場合、メッセージを転送するこのバリアントは、certtemplateの変更、つまり変更、修正、つまり、IRまたはCRメッセージを転送するため、使用する必要があります。追加、またはフィールドの除去。
The PKI management entity MUST verify the proof-of-possession contained in the original message using the included public key. If successful, the PKI management entity MUST change the popo field value to raVerified.
PKI管理エンティティは、含まれている公開キーを使用して元のメッセージに含まれる所有証明の証明を検証する必要があります。成功した場合、PKI管理エンティティはPOPOフィールド値を変更してラバリファイ化合を変更する必要があります。
Specific prerequisites augmenting the prerequisites in Section 3.4 are as follows:
セクション3.4の前提条件を増強する特定の前提条件は、次のとおりです。
* The PKI management entity MUST be authorized to replace the proof-of-possession (after verifying it) with raVerified.
* PKI管理エンティティは、（検証した後）、Raverifiedに置き換えることを許可する必要があります。
* The PKI management entity MUST be able to validate the respective request and have the authorization to perform approval of the request according to the PKI policies.
* PKI管理エンティティは、それぞれの要求を検証し、PKIポリシーに従って要求の承認を実行する許可を持つことができる必要があります。
Detailed Description of the popo Field of the certReq Structure:
Certreq構造のPopoフィールドの詳細な説明：
popo
raVerified REQUIRED
-- MUST have the value NULL and indicates that the PKI
-- management entity verified the popo of the original message
A PKI management entity may need to request a PKI management operation on behalf of another PKI entity. In this case, the PKI management entity initiates the respective PKI management operation as described in Section 4, acting in the role of the EE.
PKI管理エンティティは、別のPKIエンティティに代わってPKI管理操作を要求する必要がある場合があります。この場合、PKI管理エンティティは、EEの役割で作用するセクション4で説明されているように、それぞれのPKI管理操作を開始します。
Note: The request message protection will not authenticate the EE, but it will authenticate the RA acting on behalf of the EE.
注：要求メッセージ保護はEEを認証しませんが、EEに代わって作用するRAを認証します。
A PKI management entity may use one of the PKI management operations described in Section 4.1 to request a certificate on behalf of another PKI entity. It either generates the key pair itself and inserts the new public key in the subjectPublicKey field of the request certTemplate, or it uses a certificate request received from downstream, e.g., by means of a different protocol. In the latter case, it MUST verify the received proof-of-possession if this proof breaks, e.g., due to transformation from PKCS #10 [RFC2986] to CRMF [RFC4211]. It MUST also verify, based on local PKI policy, that the subject name in the certTemplate identifies the EE.
PKI管理エンティティは、セクション4.1で説明されているPKI管理操作の1つを使用して、別のPKIエンティティに代わって証明書を要求する場合があります。キーペア自体を生成し、Request CertTemplateの件名Publickeyフィールドに新しい公開キーを挿入するか、たとえば異なるプロトコルによって下流から受信した証明書要求を使用します。後者の場合、PKCS＃10 [RFC2986]からCRMF [RFC4211]への変換により、この証明が壊れた場合、受け取った証明の証明を検証する必要があります。また、ローカルPKIポリシーに基づいて、certTemplateの件名がEEを識別することも確認する必要があります。
No specific prerequisites apply in addition to those specified in Section 4.1.
セクション4.1で指定されているものに加えて、特定の前提条件は適用されません。
Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the one described in Section 5.2.3 because, in both cases, the message is protected by the PKI management entity.
注：上流のPKI管理エンティティは、このPKI管理操作をセクション5.2.3で説明するものと区別することはできません。どちらの場合も、メッセージはPKI管理エンティティによって保護されているためです。
The message sequence for this PKI management operation is identical to the respective PKI management operation given in Section 4.1, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.1に記載されているそれぞれのPKI管理操作と同一であり、次の変更があります。
1. The request messages MUST be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation.
1. リクエストメッセージは、この操作でEEの役割を引き受けるPKI管理エンティティのCMP保護キーを使用して署名する必要があります。
2. If inclusion of a proper proof-of-possession is not possible, the PKI management entity MUST verify the POP provided from downstream and use "raVerified" in its upstream request.
2. 適切なプルーフオブポッセッションを含めることが不可能な場合、PKI管理エンティティは、下流から提供されたPOPを確認し、上流のリクエストで「raverified」を使用する必要があります。
3. The binding of the proof-of-possession to the proof-of-identity of the requesting EE cannot be provided when acting on behalf of the EE.
3. EEに代わって行動する場合、要求するEEの同一性の証明の証明の拘束力は提供できません。
A PKI management entity may use the PKI management operation described in Section 4.2 to revoke a certificate of another PKI entity. This revocation request message MUST be signed by the PKI management entity using its own CMP protection key to prove to the PKI authorization to revoke the certificate on behalf of that PKI entity.
PKI管理エンティティは、セクション4.2で説明されているPKI管理操作を使用して、別のPKIエンティティの証明書を取り消すことができます。この取り消し要求メッセージは、独自のCMP保護キーを使用してPKI管理エンティティによって署名され、PKIエンティティに代わって証明書を取り消すためにPKI許可を証明する必要があります。
No specific prerequisites apply in addition to those specified in Section 4.2.
セクション4.2で指定されているものに加えて、特定の前提条件は適用されません。
Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the ones described in Section 5.2.3.
注：上流のPKI管理エンティティは、このPKI管理操作をセクション5.2.3で説明したものと区別することはできません。
The message sequence for this PKI management operation is identical to that given in Section 4.2, with the following changes:
このPKI管理操作のメッセージシーケンスは、セクション4.2で与えられたものと同じであり、次の変更があります。
1. The rr message MUST be signed using the CMP protection key of the PKI management entity acting on behalf of the EE in this operation.
1. RRメッセージは、この操作でEEに代わって行動するPKI管理エンティティのCMP保護キーを使用して署名する必要があります。
CMP messages are designed to be self-contained, such that, in principle, any reliable transfer mechanism can be used. EEs will typically support only one transfer mechanism. PKI management entities SHOULD offer HTTP and MAY offer CoAP where required. Piggybacking of CMP messages on any other reliable transfer protocol MAY be used, and file-based transfer MAY be used in case offline transfer is required.
CMPメッセージは、原則として、信頼できる転送メカニズムを使用できるように、自己完結型になるように設計されています。EESは通常、1つの転送メカニズムのみをサポートします。PKI管理エンティティはHTTPを提供する必要があり、必要に応じてCOAPを提供する場合があります。他の信頼できる転送プロトコルでのCMPメッセージのピギーバックを使用することができ、オフライン転送が必要な場合にファイルベースの転送を使用できます。
Independently of the means of transfer, it can happen that messages are lost or that a communication partner does not respond. To prevent waiting indefinitely, each PKI entity that sends CMP requests should use a configurable per-request timeout, and each PKI management entity that handles CMP requests should use a configurable timeout in case a further request message is to be expected from the client side within the same transaction. In this way, a hanging transaction can be closed cleanly with an error as described in Section 3.6 (failInfo bit: systemUnavail), and related resources (for instance, any cached extraCerts) can be freed.
転送の手段とは無関係に、メッセージが失われたり、通信パートナーが応答しないことが起こります。待機を無期限に防ぐために、CMPリクエストを送信する各PKIエンティティは、構成可能なリケストごとのタイムアウトを使用する必要があります。同じトランザクション。このようにして、セクション3.6（FailInfo Bit：SystemUnavail）で説明されているようにエラーを使用して、吊りトランザクションをきれいに閉じることができ、関連するリソース（たとえば、キャッシュされたエクストラメート）を解放できます。
Moreover, there are various situations where the delivery of messages gets delayed. For instance, a serving PKI management entity might take longer than expected to form a response due to administrative processes, resource constraints, or upstream message delivery delays. The transport layer itself may cause delays, for instance, due to offline transport, network segmentation, or intermittent network connectivity. Part of these issues can be detected and handled at CMP level using pollReq and pollRep messages as described in Section 4.4, while others are better handled at transfer level. Depending on the transfer protocol and system architecture, solutions for handling delays at transfer level may be present and can be used for CMP connections, for instance, connection reestablishment and message retransmission.
さらに、メッセージの配信が遅延するさまざまな状況があります。たとえば、サービスを提供するPKI管理エンティティは、管理プロセス、リソースの制約、または上流のメッセージ配信の遅延により、予想よりも時間がかかる場合があります。たとえば、輸送層自体は、オフライントランスポート、ネットワークセグメンテーション、または断続的なネットワーク接続により、遅延を引き起こす可能性があります。これらの問題の一部は、セクション4.4で説明されているように、PollreqおよびPollrepメッセージを使用してCMPレベルで検出および処理できますが、その他は転送レベルでより適切に処理されます。転送プロトコルとシステムアーキテクチャに応じて、転送レベルで遅延を処理するためのソリューションが存在する場合があり、たとえば接続の再確立やメッセージの再送信など、CMP接続に使用できます。
Note: Long timeout periods are helpful to maximize chances to handle minor delays at lower layers without the need for polling.
注：長いタイムアウト期間は、投票を必要とせずに下層で軽微な遅延を処理する機会を最大化するのに役立ちます。
Note: When using TCP and similar reliable connection-oriented transport protocols, which is typical in conjunction with HTTP, there is the option to keep the connection alive over multiple request-response message pairs. This may improve efficiency.
注：HTTPと組み合わせて典型的なTCPおよび同様の信頼できる接続指向のトランスポートプロトコルを使用する場合、複数のリクエスト応答メッセージペアで接続を生かし続けるオプションがあります。これにより、効率が向上する可能性があります。
When conveying CMP messages in HTTP, CoAP, or MIME-based transfer protocols, the Internet media type "application/pkixcmp" MUST be set for transfer encoding as specified in Section 3.4 of CMP over HTTP [RFC6712] and Section 2.3 of CMP over CoAP [RFC9482].
HTTP、COAP、またはMIMEベースの転送プロトコルでCMPメッセージを伝達する場合、インターネットメディアタイプ「アプリケーション/PKIXCMP」は、CMPを介したCMPのセクション3.4で指定されているように、COAPを超えるCMPのCMPのセクション2.3で指定されているように、転送エンコードに設定する必要があります。[RFC9482]。
This transfer mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transfer is used, the specifications described in [RFC6712] and updated by CMP Updates [RFC9480] MUST be followed.
この転送メカニズムは、PKIエンティティがHTTPを介してCMPメッセージを転送するために使用できます。HTTP転送を使用する場合、[RFC6712]で説明され、CMP更新で更新された仕様[RFC9480]に従う必要があります。
PKI management operations MUST use a URI path consisting of '/.well-known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 3.3 of CMP Updates [RFC9480]. It SHOULD be followed by an operation label depending on the type of PKI management operation.
PKI管理操作は、CMP更新[RFC9480]のセクション3.3で指定されているように、「/.well-known/cmp」または「/.well-nowncmp/p/ <name>」で構成されるURIパスを使用する必要があります。PKI管理操作の種類に応じて、オペレーションラベルが続く必要があります。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
+============================+====================+=========+
| PKI Management Operation | URI Path Segment | Details |
+============================+====================+=========+
| Enrolling an End Entity to | initialization | Section |
| a New PKI | | 4.1.1 |
+----------------------------+--------------------+---------+
| Enrolling an End Entity to | certification | Section |
| a Known PKI | | 4.1.2 |
+----------------------------+--------------------+---------+
| Updating a Valid | keyupdate | Section |
| Certificate | | 4.1.3 |
+----------------------------+--------------------+---------+
| Enrolling an End Entity | pkcs10 | Section |
| Using a PKCS #10 Request | | 4.1.4 |
+----------------------------+--------------------+---------+
| Revoking a Certificate | revocation | Section |
| | | 4.2 |
+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get Certificate Request | getcertreqtemplate | Section |
| Template | | 4.3.3 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+
| Batching Messages | nested | Section |
| | | 5.2.2.2 |
| Note: This path element is | | |
| applicable only between | | |
| PKI management entities. | | |
+----------------------------+--------------------+---------+
Table 1: HTTP URI Path Segment <operation>
表1：HTTP URIパスセグメント<操作>
If operation labels are used:
操作ラベルが使用されている場合：
* independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.
* 使用されるバリアントとは無関係に（セクション4.1.5、4.1.6、および4.4を参照）、PKI管理操作に対応する操作ラベルを使用するものとします。
* any certConf or pollReq messages SHALL be sent to the same endpoint as determined by the PKI management operation.
* CERTCONFまたはPOLLREQメッセージは、PKI管理操作によって決定されたのと同じエンドポイントに送信されます。
* when a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.
* セクション5.2.2.1で説明されているように単一の要求メッセージがネストされている場合、使用するラベルは、基礎となるPKI管理操作と同じでなければなりません。
By sending a request to its preferred endpoint, the PKI entity will recognize, via the HTTP response status code, whether a configured URI is supported by the PKI management entity.
優先エンドポイントにリクエストを送信することにより、PKIエンティティは、HTTP応答ステータスコードを介して、構成されたURIがPKI管理エンティティによってサポートされているかどうかを認識します。
In case a PKI management entity receives an unexpected HTTP status code from upstream, it MUST respond downstream with an error message as described in Section 3.6, using a failInfo bit corresponding to the status code, e.g., systemFailure.
PKI管理エンティティが上流から予期しないHTTPステータスコードを受信した場合、セクション3.6で説明されているように、ステータスコード、たとえばSystemFailureに対応するFailinfoビットを使用して、エラーメッセージで下流に応答する必要があります。
For certificate management, the major security goal is integrity and data origin authentication. For delivery of centrally generated keys, confidentiality is also a must. These goals are sufficiently achieved by CMP itself, also in an end-to-end fashion.
証明書管理の場合、主要なセキュリティ目標は整合性とデータ起源の認証です。中央に生成されたキーの配信には、機密性も必須です。これらの目標は、エンドツーエンドの方法で、CMP自体によって十分に達成されます。
If a second line of defense is required or general privacy concerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS should be used with certificate-based authentication to further protect the HTTP transfer as described in [RFC9110]. In addition, the recommendations provided in [RFC9325] should be followed.
第2の防衛線が必要な場合、または一般的なプライバシーの懸念が存在する場合、TLSを使用してホップバイホップベースで機密性を提供できます。[RFC9110]で説明されているように、HTTP転送をさらに保護するために、TLSを証明書ベースの認証とともに使用する必要があります。さらに、[RFC9325]で提供される推奨事項に従う必要があります。
Note: The requirements for checking certificates given in [RFC5280] and either [RFC5246] or [RFC8446] must be followed for the TLS layer. Certificate status checking should be used for the TLS certificates of all communication partners.
注：[RFC5280]および[RFC5246]または[RFC8446]で指定された証明書をチェックするための要件に、TLSレイヤーについては従わなければなりません。証明書のステータスチェックは、すべての通信パートナーのTLS証明書に使用する必要があります。
TLS with mutual authentication based on shared secret information may be used in case no suitable certificates for certificate-based authentication are available, e.g., a PKI management operation with MAC-based protection is used.
共有秘密情報に基づいた相互認証のTLSは、証明書ベースの認証に適した証明書が利用できない場合に使用できます。たとえば、Macベースの保護を備えたPKI管理操作が使用されます。
Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based TLS authentication. A pre-shared key (PSK) mechanism may be used with shared secret information with an entropy of at least 128 bits. Otherwise, a password-authenticated key exchange (PAKE) protocol is recommended.
注：共有された秘密情報のエントロピーは、Shard Secret InformationベースのTLS認証を使用して利用可能な保護レベルに不可欠です。少なくとも128ビットのエントロピーを備えた共有秘密情報とともに、事前に共有キー（PSK）メカニズムを使用できます。それ以外の場合は、パスワードを認識したキーエクスチェンジ（ペイク）プロトコルをお勧めします。
Note: The provisioning of client certificates and PSKs is out of scope of this document.
注：クライアント証明書とPSKのプロビジョニングは、このドキュメントの範囲外です。
This transfer mechanism can be used by a PKI entity to transfer CMP messages over CoAP [RFC7252], e.g., in constrained environments. If CoAP transfer is used, the specifications described in CMP over CoAP [RFC9482] MUST be followed.
この転送メカニズムは、PKIエンティティがCOAP [RFC7252]を介してCMPメッセージを転送するために使用できます。COAP転送を使用する場合、COAP [RFC9482]を介したCMPで説明されている仕様に従う必要があります。
PKI management operations MUST use a URI path consisting of '/.well-known/cmp' or '/.well-known/cmp/p/<name>' as specified in Section 2.1 of CMP over CoAP [RFC9482]. It SHOULD be followed by an operation label depending on the type of PKI management operation.
PKI管理操作は、COAP [RFC9482]を超えるCMPのセクション2.1で指定されているように、「/.well-known/cmp」または「/.well-nowncmp/p/ <name>」で構成されるURIパスを使用する必要があります。PKI管理操作の種類に応じて、オペレーションラベルが続く必要があります。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
Batching Messages
バッチメッセージ
Note: This path element is applicable only between PKI management entities.
注：このパス要素は、PKI管理エンティティ間でのみ適用されます。
+=======================================+=========+=========+
| PKI Management Operation | URI | Details |
| | Path | |
| | Segment | |
+=======================================+=========+=========+
| Enrolling an End Entity to a New PKI | ir | Section |
| | | 4.1.1 |
+---------------------------------------+---------+---------+
| Enrolling an End Entity to a Known | cr | Section |
| PKI | | 4.1.2 |
+---------------------------------------+---------+---------+
| Updating a Valid Certificate | kur | Section |
| | | 4.1.3 |
+---------------------------------------+---------+---------+
| Enrolling an End Entity Using a PKCS | p10 | Section |
| #10 Request | | 4.1.4 |
+---------------------------------------+---------+---------+
| Revoking a Certificate | rr | Section |
| | | 4.2 |
+---------------------------------------+---------+---------+
| Get CA Certificates | crts | Section |
| | | 4.3.1 |
+---------------------------------------+---------+---------+
| Get Root CA Certificate Update | rcu | Section |
| | | 4.3.2 |
+---------------------------------------+---------+---------+
| Get Certificate Request Template | att | Section |
| | | 4.3.3 |
+---------------------------------------+---------+---------+
| CRL Update Retrieval | crls | Section |
| | | 4.3.4 |
+---------------------------------------+---------+---------+
| Batching Messages | nest | Section |
| | | 5.2.2.2 |
| Note: This path element is applicable | | |
| only between PKI management entities. | | |
+---------------------------------------+---------+---------+
Table 2: CoAP URI Path Segment <operation>
表2：Coap URIパスセグメント<OPERATION>
If operation labels are used:
操作ラベルが使用されている場合：
* independently of any variants used (see Sections 4.1.5, 4.1.6, and 4.4), the operation label corresponding to the PKI management operation SHALL be used.
* 使用されるバリアントとは無関係に（セクション4.1.5、4.1.6、および4.4を参照）、PKI管理操作に対応する操作ラベルを使用するものとします。
* any certConf or pollReq messages SHALL be sent to the same endpoint, as determined by the PKI management operation.
* CERTCONFまたはPOLLREQメッセージは、PKI管理操作によって決定されたのと同じエンドポイントに送信されます。
* when a single request message is nested as described in Section 5.2.2.1, the label to use SHALL be the same as for the underlying PKI management operation.
* セクション5.2.2.1で説明されているように単一の要求メッセージがネストされている場合、使用するラベルは、基礎となるPKI管理操作と同じでなければなりません。
By sending a request to its preferred endpoint, the PKI entity will recognize, via the CoAP response status code, whether a configured URI is supported by the PKI management entity. The CoAP-inherent discovery mechanisms MAY also be used.
優先エンドポイントにリクエストを送信することにより、PKIエンティティは、COAP応答ステータスコードを介して、構成されたURIがPKI管理エンティティによってサポートされているかどうかを認識します。Coap-inherentの発見メカニズムも使用できます。
In case a PKI management entity receives an unexpected CoAP status code from upstream, it MUST respond downstream with an error message, as described in Section 3.6, using a failInfo bit corresponding to the status code, e.g., systemFailure.
PKI管理エンティティが上流から予期しないCOAPステータスコードを受信した場合、セクション3.6で説明されているように、ステータスコード、たとえばSystemFailureに対応するFailinfoビットを使用して、エラーメッセージで下流に応答する必要があります。
Like for HTTP transfer, to offer a second line of defense or to provide hop-by-hop privacy protection, DTLS may be utilized as described in CMP over CoAP [RFC9482]. If DTLS is utilized, the same boundary conditions (peer authentication, etc.) as those stated for TLS to protect HTTP transfer in Section 6.1 apply to DTLS likewise.
HTTP転送のように、第2の防衛ラインを提供したり、ホップバイホップのプライバシー保護を提供するために、COAP [RFC9482]を介してCMPで説明されているようにDTLは利用できます。DTLが使用されている場合、セクション6.1のHTTP転送を保護するためにTLSに記載されているものと同じ境界条件（ピア認証など）が同様にDTLに適用されます。
Note: The provisioning of client certificates and PSKs is out of scope of this document.
注：クライアント証明書とPSKのプロビジョニングは、このドキュメントの範囲外です。
CMP messages MAY also be transferred on some other reliable protocol, e.g., Extensible Authentication Protocol (EAP) or Message Queuing Telemetry Transport (MQTT). Connection, delay, and error handling mechanisms similar to those specified for HTTP in [RFC6712] need to be implemented.
CMPメッセージは、他の信頼できるプロトコル、たとえば拡張可能な認証プロトコル（EAP）またはメッセージキューイングテレメトリー輸送（MQTT）で転送される場合があります。[RFC6712]でHTTPに指定されたものと同様の接続、遅延、およびエラー処理メカニズムを実装する必要があります。
A more detailed specification is out of scope of this document and would need to be given, for instance, in the scope of the transfer protocol used.
より詳細な仕様は、このドキュメントの範囲外であり、たとえば、使用される転送プロトコルの範囲で提供する必要があります。
For transferring CMP messages between PKI entities, any mechanism that is able to store and forward binary objects of sufficient length and with sufficient reliability while preserving the order of messages for each transaction can be used.
PKIエンティティ間でCMPメッセージを転送するには、各トランザクションのメッセージの順序を保持しながら、十分な長さのバイナリオブジェクトを十分に信頼性を維持および転送できるメカニズムを使用できます。
The transfer mechanism should be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases, the PKI entities MUST report an error as specified in Section 3.6, as far as possible.
転送メカニズムは、メッセージの損失、過度の遅延、およびおそらく他の伝送エラーを示すことができるはずです。そのような場合、PKIエンティティは、セクション3.6で指定されたエラーを可能な限り報告する必要があります。
CMP messages MAY be transferred between PKI entities using file-based mechanisms, for instance, when an EE is offline or a PKI management entity performs delayed delivery. Each file MUST contain the ASN.1 DER encoding of one CMP message only, where the message may be nested. There MUST be no extraneous header or trailer information in the file. The filename extension ".pki" MUST be used.
たとえば、EEがオフラインまたはPKI管理エンティティが遅延配信を実行する場合、ファイルベースのメカニズムを使用してPKIエンティティ間でCMPメッセージを転送する場合があります。各ファイルには、1つのCMPメッセージのみのasn.1 derエンコードが含まれている必要があります。メッセージがネストされる場合があります。ファイルには無関係なヘッダーまたはトレーラー情報がないはずです。Filename拡張子 ".pki"を使用する必要があります。
Other asynchronous transfer protocols, e.g., email or website upload/ download, MAY transfer CMP messages between PKI entities. A MIME wrapping is defined for those environments that are MIME-native. The MIME wrapping is specified in Section 3.1 of [RFC8551].
その他の非同期転送プロトコル、たとえば、電子メールやウェブサイトのアップロード/ダウンロードは、PKIエンティティ間でCMPメッセージを転送する場合があります。Mimeラッピングは、Mime-Nativeの環境に対して定義されています。MIMEラッピングは、[RFC8551]のセクション3.1で指定されています。
The ASN.1 DER encoding of the CMP messages MUST be transferred using the "application/pkixcmp" content type and base64-encoded content transfer encoding, as specified in Section 3.4 of CMP over HTTP [RFC6712]. A filename MUST be included either in a "content-type" or a "content-disposition" statement. The filename extension ".pki" MUST be used.
CMPメッセージのASN.1 derエンコードは、HTTP [RFC6712]を介したCMPのセクション3.4で指定されているように、「アプリケーション/PKIXCMP」コンテンツタイプとBase64エンコードコンテンツ転送エンコードを使用して転送する必要があります。ファイル名は、「コンテンツタイプ」または「コンテンツ配置」ステートメントのいずれかに含める必要があります。Filename拡張子 ".pki"を使用する必要があります。
This section defines which level of support for the various features specified in this profile is required for each type of PKI entity.
このセクションでは、このプロファイルで指定されているさまざまな機能のサポートレベルが、各タイプのPKIエンティティに必要なレベルを定義します。
The following table provides an overview of the PKI management operations specified in Sections 4 and 5 and states whether support by conforming EE, RA, and CA implementations is mandatory, recommended, optional, or not applicable. Variants amend or change behavior of base PKI management operations and are therefore also included.
次の表は、セクション4および5で指定されたPKI管理操作の概要と、EE、RA、およびCAの実装に準拠したサポートが必須、推奨、オプション、または適用されないかどうかを示します。バリアントは、基本PKI管理操作の動作を修正または変更するため、含まれています。
The PKI management operation specifications in Section 4 assume that either the RA or CA is the PKI management entity that terminates the Certificate Management Protocol. If the RA terminates CMP, it either responds directly as described in Section 5.1, or it forwards the certificate management operation towards the CA not using CMP. Section 5.2 describes different options of how an RA can forward a CMP message using CMP. Section 5.3 offers the option that an RA operates on behalf on an EE and therefore takes the role of the EE in Section 4.
セクション4のPKI管理操作仕様は、RAまたはCAが証明書管理プロトコルを終了するPKI管理エンティティであると想定しています。RAがCMPを終了する場合、セクション5.1で説明されているように直接応答するか、CMPを使用していないCAに証明書管理操作を転送します。セクション5.2では、RAがCMPを使用してCMPメッセージを転送する方法のさまざまなオプションについて説明します。セクション5.3では、RAがEEに代わって動作するオプションを提供し、したがってセクション4でEEの役割を担っています。
+==========+=============================+========+========+========+
| ID | PKI Management Operations | EE | RA | CA |
| | and Variants | | | |
+==========+=============================+========+========+========+
| Generic | Generic Aspects of PKI | MUST | MUST | MUST |
| | Messages and PKI | | | |
| | Management Operations, | | | |
| | Section 3 | | | |
+----------+-----------------------------+--------+--------+--------+
| IR | Enrolling an End Entity to | MUST | MAY | MUST |
| | a New PKI, Section 4.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| CR | Enrolling an End Entity to | MAY | MAY | MAY |
| | a Known PKI, Section 4.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| KUR | Updating a Valid | MUST | MAY | MUST |
| | Certificate, Section 4.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| P10CR | Enrolling an End Entity | MAY | MAY | MAY |
| | Using a PKCS #10 Request, | | | |
| | Section 4.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| MAC | Using MAC-Based Protection | MAY | SHOULD | MAY |
| | for Enrollment (IR, CR, | | 1) | |
| | and P10CR if supported), | | | |
| | Section 4.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| CKeyGen | Adding Central Key Pair | MAY | MAY | MAY |
| | Generation to Enrollment | | | |
| | (IR, CR, KUR, and P10CR if | | | |
| | supported), Section 4.1.6 | | | |
+----------+-----------------------------+--------+--------+--------+
| RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD |
| | Section 4.2 | | 2) | 3) |
+----------+-----------------------------+--------+--------+--------+
| CACerts | Get CA Certificates, | MAY | MAY | MAY |
| | Section 4.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RootUpd | Get Root CA Certificate | MAY | MAY | MAY |
| | Update, Section 4.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| ReqTempl | Get Certificate Request | MAY | MAY | MAY |
| | Template, Section 4.3.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| CRLUpd | CRL Update Retrieval, | MAY | MAY | MAY |
| | Section 4.3.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| Polling | Handling Delayed Delivery, | MAY | MAY | MAY |
| | Section 4.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertResp | Responding to a | N/A | MAY | MUST |
| | Certificate Request (IR, | | | |
| | CR, KUR, and P10CR if | | | |
| | supported), Section 5.1.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertConf | Responding to a | N/A | MAY | MUST |
| | Confirmation Message, | | | |
| | Section 5.1.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevResp | Responding to a Revocation | N/A | MAY | SHOULD |
| | Request, Section 5.1.3 | | | |
+----------+-----------------------------+--------+--------+--------+
| GenResp | Responding to a Support | N/A | MAY | MAY |
| | Message (CACerts, RootUpd, | | | |
| | ReqTempl, CRLUpd if | | | |
| | supported), Section 5.1.4 | | | |
+----------+-----------------------------+--------+--------+--------+
| InitPoll | Initiating Delayed | N/A | MAY | MAY |
| | Delivery, Section 5.1.5 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdKeep | Forwarding Messages - Not | N/A | MUST | N/A |
| | Changing Protection, | | | |
| | Section 5.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddS | Forwarding Messages - | N/A | MUST | MUST |
| | Adding Protection to a | | | |
| | Request Message, | | | |
| | Section 5.2.2.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdAddB | Forwarding Messages - | N/A | MAY | MAY |
| | Batching Messages, | | | |
| | Section 5.2.2.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdReqKP | Forwarding Messages - Not | N/A | SHOULD | N/A |
| | Changing Proof-of- | | 1) | |
| | Possession, | | | |
| | Section 5.2.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| FwdReqBP | Forwarding Messages - | N/A | MAY | MAY |
| | Using raVerified, | | | |
| | Section 5.2.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
| CertROnB | Acting on Behalf of Other | N/A | MAY | N/A |
| | PKI Entities - Requesting | | | |
| | a Certificate, | | | |
| | Section 5.3.1 | | | |
+----------+-----------------------------+--------+--------+--------+
| RevROnB | Acting on Behalf of Other | N/A | SHOULD | SHOULD |
| | PKI Entities - Revoking a | | 2) | 3) |
| | Certificate, Section 5.3.2 | | | |
+----------+-----------------------------+--------+--------+--------+
Table 3: Level of Support for PKI Management Operations and Variants
表3：PKI管理操作とバリアントのサポートレベル
1) The RA should be able to change the CMP message protection from MAC-based to signature-based protection; see Section 5.2.3.1.
1) RAは、Macベースから署名ベースの保護にCMPメッセージ保護を変更できるはずです。セクション5.2.3.1を参照してください。
2) The RA should be able to request certificate revocation on behalf of an EE (see Section 5.3.2), e.g., in order to handle incidents.
2) RAは、EEに代わって証明書の取り消しを要求できるはずです（たとえば、インシデントを処理するために、セクション5.3.2を参照）。
3) An alternative would be to perform revocation at the CA without using CMP, for instance, using a local administration interface.
3) 別の方法は、CMPを使用せずにCAで取り消しを実行することです。たとえば、ローカルな管理インターフェイスを使用します。
CMP does not have specific needs regarding message transfer, except that, for each request message sent, eventually a sequence of one response message should be received. Therefore, virtually any reliable transfer mechanism can be used, such as HTTP, CoAP, and file-based offline transfer. Thus, this document does not require any specific transfer protocol to be supported by conforming implementations.
CMPにはメッセージ転送に関する特定のニーズはありませんが、送信されるリクエストメッセージごとに、最終的には1つの応答メッセージのシーケンスを受信する必要があります。したがって、HTTP、COAP、およびファイルベースのオフライン転送など、実質的に信頼性の高い転送メカニズムを使用できます。したがって、このドキュメントでは、実装の適合によって特定の転送プロトコルをサポートする必要はありません。
On different links between PKI entities (e.g., EE-RA and RA-CA), different transfer mechanisms, as specified in Section 6, may be used.
PKIエンティティ（EE-RAおよびRA-CAなど）間の異なるリンクでは、セクション6で指定されているように、さまざまな転送メカニズムを使用できます。
HTTP SHOULD be supported and CoAP MAY be supported at all PKI entities for maximizing general interoperability at transfer level. Yet full flexibility is retained to choose whatever transfer mechanism is suitable, for instance, for devices and system architectures with specific constraints.
HTTPをサポートし、転送レベルで一般的な相互運用性を最大化するために、すべてのPKIエンティティでCOAPをサポートする必要があります。しかし、たとえば、特定の制約を備えたデバイスやシステムアーキテクチャに適した転送メカニズムを選択するために、完全な柔軟性が保持されます。
The following table lists the name and level of support specified for each transfer mechanism.
次の表には、各転送メカニズムに指定されたサポートの名前とレベルを示します。
+=========+=======================+========+========+========+
| ID | Message Transfer Type | EE | RA | CA |
+=========+=======================+========+========+========+
| HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD |
| | Section 6.1 | | | |
+---------+-----------------------+--------+--------+--------+
| CoAP | CoAP Transfer, | MAY | MAY | MAY |
| | Section 6.2 | | | |
+---------+-----------------------+--------+--------+--------+
| Piggyb | Piggybacking on Other | MAY | MAY | MAY |
| | Reliable Transfer, | | | |
| | Section 6.3 | | | |
+---------+-----------------------+--------+--------+--------+
| Offline | Offline Transfer, | MAY | MAY | MAY |
| | Section 6.4 | | | |
+---------+-----------------------+--------+--------+--------+
Table 4: Level of Support for Message Transfer Types
表4：メッセージ転送タイプのサポートレベル
IANA has registered the following content in the "CMP Well-Known URI Path Segments" registry (see <https://www.iana.org/assignments/cmp>), as defined in [RFC8615].
IANAは、[rfc8615]で定義されているように、「<https://www.iana.org/assignments/cmp>を参照」レジストリ（<https://www.iana.org/assignments/cmp>を参照）に次のコンテンツを登録しています。
+====================+==========================+===============+
| Path Segment | Description | Reference |
+====================+==========================+===============+
| initialization | Enrolling an End Entity | RFC 9483, |
| | to a New PKI over HTTP | Section 4.1.1 |
+--------------------+--------------------------+---------------+
| certification | Enrolling an End Entity | RFC 9483, |
| | to a Known PKI over HTTP | Section 4.1.2 |
+--------------------+--------------------------+---------------+
| keyupdate | Updating a Valid | RFC 9483, |
| | Certificate over HTTP | Section 4.1.3 |
+--------------------+--------------------------+---------------+
| pkcs10 | Enrolling an End Entity | RFC 9483, |
| | Using a PKCS #10 Request | Section 4.1.4 |
| | over HTTP | |
+--------------------+--------------------------+---------------+
| revocation | Revoking a Certificate | RFC 9483, |
| | over HTTP | Section 4.2 |
+--------------------+--------------------------+---------------+
| getcacerts | Get CA Certificates over | RFC 9483, |
| | HTTP | Section 4.3.1 |
+--------------------+--------------------------+---------------+
| getrootupdate | Get Root CA Certificate | RFC 9483, |
| | Update over HTTP | Section 4.3.2 |
+--------------------+--------------------------+---------------+
| getcertreqtemplate | Get Certificate Request | RFC 9483, |
| | Template over HTTP | Section 4.3.3 |
+--------------------+--------------------------+---------------+
| getcrls | CRL Update Retrieval | RFC 9483, |
| | over HTTP | Section 4.3.4 |
+--------------------+--------------------------+---------------+
| nested | Batching Messages over | RFC 9483, |
| | HTTP | Section |
| | | 5.2.2.2 |
+--------------------+--------------------------+---------------+
| ir | Enrolling an End Entity | RFC 9483, |
| | to a New PKI over CoAP | Section 4.1.1 |
+--------------------+--------------------------+---------------+
| cr | Enrolling an End Entity | RFC 9483, |
| | to a Known PKI over CoAP | Section 4.1.2 |
+--------------------+--------------------------+---------------+
| kur | Updating a Valid | RFC 9483, |
| | Certificate over CoAP | Section 4.1.3 |
+--------------------+--------------------------+---------------+
| p10 | Enrolling an End Entity | RFC 9483, |
| | Using a PKCS #10 Request | Section 4.1.4 |
| | over CoAP | |
+--------------------+--------------------------+---------------+
| rr | Revoking a Certificate | RFC 9483, |
| | over CoAP | Section 4.2 |
+--------------------+--------------------------+---------------+
| crts | Get CA Certificates over | RFC 9483, |
| | CoAP | Section 4.3.1 |
+--------------------+--------------------------+---------------+
| rcu | Get Root CA Certificate | RFC 9483, |
| | Update over CoAP | Section 4.3.2 |
+--------------------+--------------------------+---------------+
| att | Get Certificate Request | RFC 9483, |
| | Template over CoAP | Section 4.3.3 |
+--------------------+--------------------------+---------------+
| crls | CRL Update Retrieval | RFC 9483, |
| | over CoAP | Section 4.3.4 |
+--------------------+--------------------------+---------------+
| nest | Batching Messages over | RFC 9483, |
| | CoAP | Section |
| | | 5.2.2.2 |
+--------------------+--------------------------+---------------+
Table 5: New "CMP Well-Known URI Path Segments" Registry Entries
表5：新しい「CMPよく知られているURIパスセグメント」レジストリエントリ
The security considerations laid out in CMP [RFC4210] and updated by CMP Updates [RFC9480], CMP Algorithms [RFC9481], CRMF [RFC4211], Algorithm Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over CoAP [RFC9482] apply.
CMP [RFC4210]に配置され、CMP更新[RFC9480]、CMPアルゴリズム[RFC9481]、CRMF [RFC4211]、アルゴリズム要件の更新[RFC9045]、CMPがHTTPを超えるCMP [RFC6712]、CMPを超えるCMP [RFC9045]、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMP、CMPなどのセキュリティに関する考慮事項があります。] 適用する。
Trust anchors for chain validations are often provided in the form of self-signed certificates. All trust anchors MUST be stored on the device with integrity protection. In some cases, a PKI entity may not have sufficient storage for the complete certificates. In such cases, it may only store, e.g., a hash of each self-signed certificate and require receiving the certificate in the extraCerts field, as described in Section 3.3. If such self-signed certificates are provided in-band in the messages, they MUST be verified using information from the trust store of the PKI entity.
チェーン検証のための信頼アンカーは、多くの場合、自己署名証明書の形で提供されます。すべてのトラストアンカーは、整合性保護を備えたデバイスに保存する必要があります。場合によっては、PKIエンティティには完全な証明書に十分なストレージがない場合があります。そのような場合、セクション3.3で説明されているように、たとえば、たとえば、各自己署名証明書のハッシュのみを保存し、エクストラメートフィールドで証明書を受け取る必要があります。このような自己署名証明書がメッセージ内の帯域内で提供されている場合、PKIエンティティのトラストストアからの情報を使用して確認する必要があります。
For TLS using shared secret information-based authentication, both PSK and PAKE provide the same amount of protection against a real-time authentication attack, which is directly the amount of entropy in the shared secret. The difference between a pre-shared key (PSK) and a password-authenticated key exchange (PAKE) protocol is in the level of long-term confidentiality of the TLS messages against brute-force decryption, where a PSK-based cipher suite only provides security according to the entropy of the shared secret, while a PAKE-based cipher suite provides full security independent of the entropy of the shared secret.
共有秘密情報ベースの認証を使用したTLSの場合、PSKとPakeの両方が、共有秘密のエントロピーの量であるリアルタイム認証攻撃に対して同じ量の保護を提供します。事前共有キー（PSK）とパスワード認識キーエクスチェンジ（パケ）プロトコルの違いは、PSKベースの暗号スイートが提供するブルートフォース復号化に対するTLSメッセージの長期的な機密性のレベルにあります。セキュリティ共有秘密のエントロピーによると、ペイクベースの暗号スイートは共有秘密のエントロピーとは無関係に完全なセキュリティを提供します。
[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>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key
Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP)", RFC 6712,
DOI 10.17487/RFC6712, September 2012,
<https://www.rfc-editor.org/info/rfc6712>.
[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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>.
[RFC9045] Housley, R., "Algorithm Requirements Update to the
Internet X.509 Public Key Infrastructure Certificate
Request Message Format (CRMF)", RFC 9045,
DOI 10.17487/RFC9045, June 2021,
<https://www.rfc-editor.org/info/rfc9045>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, November 2023,
<https://www.rfc-editor.org/info/rfc9480>.
[RFC9481] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray,
"Certificate Management Protocol (CMP) Algorithms",
RFC 9481, DOI 10.17487/RFC9481, November 2023,
<https://www.rfc-editor.org/info/rfc9481>.
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
November 2023, <https://www.rfc-editor.org/info/rfc9482>.
[BRSKI-AE] von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
Alternative Enrollment Protocols in BRSKI", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-ae-05, 28
June 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-anima-brski-ae-05>.
[BRSKI-PRM]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-10,
23 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-10>.
[ETSI-3GPP.33.310]
3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 16.6.0, December 2020,
<http://www.3gpp.org/ftp/Specs/html-info/33310.htm>.
[ETSI-EN.319411-1]
ETSI, "Electronic Signatures and Infrastructures (ESI);
Policy and security requirements for Trust Service
Providers issuing certificates; Part 1: General
requirements", V1.3.1, ETSI EN 319 411-1, May 2021,
<https://www.etsi.org/deliver/
etsi_en/319400_319499/31941101/01.03.01_60/
en_31941101v010301p.pdf>.
[HTTP-CMP] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- HTTP Transfer
for the Certificate Management Protocol (CMP)", Work in
Progress, Internet-Draft, draft-ietf-lamps-rfc6712bis-03,
10 February 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-rfc6712bis-03>.
[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>.
[IEEE.802.1AR_2018]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>.
[NIST.CSWP.04162018]
National Institute of Standards and Technology (NIST),
"Framework for Improving Critical Infrastructure
Cybersecurity", Version 1.1,
DOI 10.6028/NIST.CSWP.04162018, April 2018,
<http://nvlpubs.nist.gov/nistpubs/CSWP/
NIST.CSWP.04162018.pdf>.
[NIST.SP.800-57p1r5]
Barker, E., "Recommendation for Key Management: Part 1 -
General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[PKIX-CMP] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", Work in Progress, Internet-
Draft, draft-ietf-lamps-rfc4210bis-07, 19 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-07>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
[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>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
[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>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RFC8649] Housley, R., "Hash Of Root Key Certificate Extension",
RFC 8649, DOI 10.17487/RFC8649, August 2019,
<https://www.rfc-editor.org/info/rfc8649>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[SZTP-CSR] Watsen, K., Housley, R., and S. Turner, "Conveying a
Certificate Signing Request (CSR) in a Secure Zero Touch
Provisioning (SZTP) Bootstrapping Request", Work in
Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2 March 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-sztp-csr-14>.
[UNISIG.Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, V1.0.0, December 2015,
<https://www.era.europa.eu/system/files/2023-01/
sos3_index083_-_subset-137_v100.pdf>.
Suppose the server requires that the certTemplate contains:
サーバーがcertTemplateに以下が含まれることを要求すると仮定します。
* the issuer field with a value to be filled in by the EE,
* EEによって記入される値を持つ発行者フィールド、
* the subject field with a common name to be filled in by the EE and two organizational unit fields with given values "myDept" and "myGroup",
* EEと2つの組織ユニットフィールドが記入する共通名を持つ主題フィールド「MyDept」と「MyGroup」を持つ2つの組織ユニットフィールド
* the publicKey field contains an Elliptic Curve Cryptography (ECC) key on curve secp256r1 or an RSA public key of length 2048,
* PublicKeyフィールドには、曲線SECP256R1または長さ2048のRSA公開キーに楕円曲線暗号化（ECC）キーが含まれています。
* the subjectAltName extension with DNS name "www.myServer.com" and an IP address to be filled in,
* dns名「www.myserver.com」と入力するIPアドレスを備えたsubjectaltname拡張機能
* the keyUsage extension marked critical with the value digitalSignature and keyAgreement, and
* Value DigitalSignatureとKeyAgreementで重要とマークされたKeyUSAGE拡張、および
* the extKeyUsage extension with values to be filled in by the EE.
* EEによって記入される値を持つextKeyUSAGE拡張。
Then the infoValue with certTemplate and keySpec fields returned to the EE will be encoded as follows:
次に、eeに返されたcerttemplateおよびkeyspecフィールドを使用した情報値は次のようにエンコードされます。
SEQUENCE {
SEQUENCE {
[3] {
SEQUENCE {}
}
[5] {
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
UTF8String ""
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String "myDept"
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
UTF8String "myGroup"
}
}
}
}
[9] {
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates {
SEQUENCE {
[2] "www.myServer.com"
[7] ""
}
}
}
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
OCTET STRING, encapsulates {
BIT STRING 3 unused bits
"10001"B
}
}
SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11)
SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
}
}
SEQUENCE {
OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12)
INTEGER 2048
}
}
}
We thank the various reviewers of this document.
この文書のさまざまなレビュアーに感謝します。
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
David von Oheimb
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com
Steffen Fries
Siemens AG
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: steffen.fries@siemens.com
URI: https://www.siemens.com