Internet Engineering Task Force (IETF) D. von Oheimb, Ed.
Request for Comments: 9733 S. Fries
Category: Standards Track H. Brockhaus
ISSN: 2070-1721 Siemens
March 2025
This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of Enrollment over Secure Transport (EST). It supports certificate enrollment protocols such as the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.
このドキュメントでは、代替登録（BRSKI-AE）を備えたBRSKIとして知られるリモートセキュアなキーインフラストラクチャ（BRSKI）プロトコルのブートストラップの拡張機能を定義しています。Brski-aeは、Brskiを拡張して、セキュアな輸送（EST）よりも当初指定された登録の使用ではなく、証明書登録メカニズムをサポートします。認証メッセージに認証された自己完結型の署名されたオブジェクトを使用する証明書管理プロトコル（CMP）などの証明書登録プロトコルをサポートし、ネットワークデバイスのオンボーディングシナリオで柔軟性を可能にします。拡張機能は、既存の登録メカニズムが実行可能または最適ではない可能性のあるユースケースに対処し、適切な代替登録プロトコルを統合するためのフレームワークを提供します。このドキュメントは、BRSKIリファレンスアーキテクチャを更新して、これらの代替方法に対応し、さまざまなネットワーク環境にわたって安全でスケーラブルな展開を確保しています。
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/rfc9733.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9733で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Supported Scenarios
2. Terminology and Abbreviations
3. Basic Requirements and Mapping to Solutions
3.1. Solution Options for Proof of Possession
3.2. Solution Options for Proof of Identity
4. Adaptations to BRSKI
4.1. Architecture
4.2. Message Exchange
4.2.1. Pledge - Registrar Discovery
4.2.2. Pledge - Registrar - MASA Voucher Exchange
4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
4.2.5. Pledge - Registrar Enrollment Status Telemetry
4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI
5. Instantiation with Existing Enrollment Protocols
5.1. BRSKI-CMP: BRSKI-AE Instantiated with CMP
5.2. Support of Other Enrollment Protocols
6. IANA Considerations
7. Security Considerations
8. Privacy Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Application Examples
A.1. Rolling Stock
A.2. Building Automation
A.3. Substation Automation
A.4. Electric Vehicle Charging Infrastructure
A.5. Infrastructure Isolation Policy
A.6. Sites with Insufficient Levels of Operational Security
Acknowledgments
Contributors
Authors' Addresses
Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] is typically used with Enrollment over Secure Transport (EST) [RFC7030] as the enrollment protocol for operator-specific device certificates, employing HTTP over TLS for secure message transfer. BRSKI-AE is a variant using alternative enrollment protocols with authenticated self-contained objects for the device certificate enrollment.
ブートストラップリモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]は、通常、セキュアな輸送（EST）[RFC7030]を登録して、オペレーター固有のデバイス証明書の登録プロトコルとして使用され、セキュアなメッセージ転送のためにTLSを超えるHTTPを使用します。Brski-aeは、デバイス証明書の登録に認証された自己完結型オブジェクトを備えた代替登録プロトコルを使用したバリアントです。
This approach offers several distinct advantages. It allows for the authentication of the origin of requests and responses independently of message transfer mechanisms. This capability facilitates end-to-end authentication (i.e., end-to-end proof of origin) across multiple transport hops and supports the asynchronous operation of certificate enrollment. Consequently, this provides architectural flexibility in determining the location and timing for the ultimate authentication and authorization of certification requests while ensuring that the integrity and authenticity of the enrollment messages are maintained with full cryptographic strength.
このアプローチは、いくつかの明確な利点を提供します。これにより、メッセージ転送メカニズムとは無関係にリクエストと応答の起源を認証できます。この機能は、複数の輸送ホップにわたってエンドツーエンドの認証（つまり、エンドツーエンドの原点の証明）を容易にし、証明書登録の非同期操作をサポートします。したがって、これにより、登録メッセージの完全性と信頼性が完全な暗号強度で維持されるようにしながら、認証要求の究極の認証と認証の場所とタイミングを決定する際のアーキテクチャの柔軟性が提供されます。
This specification carries over the main characteristics of BRSKI, namely:
この仕様は、BRSKIの主な特徴を引き継ぎます。
* The pledge is assumed to have received its Initial Device IDentifier (IDevID) [IEEE_802.1AR-2018] credentials during its manufacturing. It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA) [RFC8995], to the registrar (which is the access point of the target domain), and to possibly further components of the domain where it will be operated.
* 誓約は、製造中に初期デバイス識別子（IDEVID）[IEEE_802.1AR-2018]資格情報を受け取ったと想定されています。それらを使用して、メーカー認定署名機関（MASA）[RFC8995]、レジストラ（ターゲットドメインのアクセスポイント）、および操作のあるドメインのさらなるコンポーネントに自らを認証します。
* The pledge first obtains via the voucher [RFC8366] exchange a trust anchor for authenticating entities in the domain such as the domain registrar.
* 誓約は、最初にバウチャー[RFC8366]を介して、ドメインレジストラなどのドメイン内のエンティティを認証するための信頼アンカーを交換します。
* The pledge then obtains its Locally Significant Device IDentifier (LDevID) [IEEE_802.1AR-2018]. To this end, the pledge generates a private key, called an "LDevID secret". Then, it requests via the domain registrar from the PKI of its new domain a domain-specific device certificate, called an "LDevID certificate". On success, it receives the LDevID certificate along with its certificate chain.
* その後、誓約は、局所的に重要なデバイス識別子（LDEVID）[IEEE_802.1AR-2018]を取得します。この目的のために、誓約は「ldevid Secret」と呼ばれる秘密鍵を生成します。次に、新しいドメインのPKIからドメインレジストラを介して、「LDEVID証明書」と呼ばれるドメイン固有のデバイス証明書を要求します。成功すると、証明書チェーンとともにLDEVID証明書を受け取ります。
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID certificate enrollment through the use of an alternative protocol to EST that:
BRSKI-AEの目的は、代替プロトコルを使用してLDEVID証明書の登録を可能にすることにより、次のことを可能にすることでBRSKIを強化することです。
* supports end-to-end authentication over multiple transport hops and
* 複数のトランスポートホップとエンドツーエンド認証をサポートします
* facilitates secure message exchanges over any type of transfer mechanism, including asynchronous delivery.
* 非同期配信を含むあらゆるタイプの転送メカニズムにわたって安全なメッセージ交換を促進します。
It may be observed that the BRSKI voucher exchange between the pledge, registrar, and MASA involves the use of authenticated self-contained objects, which inherently possess these properties.
誓約、レジストラ、およびMASAの間のBRSKIバウチャー交換には、これらのプロパティを本質的に所有する認証された自己完結型オブジェクトの使用が含まれることが観察される場合があります。
The existing well-known URI structure used for BRSKI and EST messages is extended by introducing an additional path element that specifies the enrollment protocol being employed.
BRSKIおよびESTメッセージに使用される既存の有名なURI構造は、採用されている登録プロトコルを指定する追加のパス要素を導入することにより拡張されます。
This specification allows the registrar to offer multiple enrollment protocols, enabling pledges and their developers to select the most appropriate one based on the defined overall approach and specific endpoints.
この仕様により、レジストラは複数の登録プロトコルを提供することができ、誓約とその開発者は、定義された全体的なアプローチと特定のエンドポイントに基づいて最も適切なものを選択できるようにします。
It may be important to note that [RFC8995] specifies the use of HTTP over TLS, but variations such as Constrained BRSKI [cBRSKI], which uses the Constrained Application Protocol (CoAP) over DTLS, are possible as well. In this context, "HTTP" and "TLS" are used as references to the most common implementation, though variants using CoAP and/or DTLS are implied where applicable, as the distinctions are not pertinent here.
[RFC8995]はTLSよりもHTTPの使用を指定していることに注意することが重要かもしれませんが、DTLよりも制約されたアプリケーションプロトコル（COAP）を使用する制約付きBrski [Cbrski]などのバリエーションも可能です。この文脈では、「HTTP」と「TLS」が最も一般的な実装への参照として使用されますが、COAPおよび/またはDTLを使用したバリアントは、ここでは区別がないため、該当する場合は暗示されます。
This specification, together with its referenced documents, is sufficient to support BRSKI with the Certificate Management Protocol (CMP) [RFC9480] as profiled in the Lightweight CMP Profile (LCMPP) [RFC9483]. Integrating BRSKI with an enrollment protocol or profile other than the LCMPP will necessitate additional IANA registrations, as detailed in this document. Furthermore, additional specifications may be required for the details of the protocol or profile, which fall outside the scope of this document.
この仕様は、その参照されたドキュメントとともに、軽量CMPプロファイル（LCMPP）[RFC9483]でプロファイルされているように、証明書管理プロトコル（CMP）[RFC9480]でBRSKIをサポートするのに十分です。LCMPP以外の登録プロトコルまたはプロファイルとBRSKIを統合するには、このドキュメントで詳述されているように、追加のIANA登録が必要になります。さらに、このドキュメントの範囲外にあるプロトコルまたはプロファイルの詳細には、追加の仕様が必要になる場合があります。
BRSKI-AE is designed for use in scenarios such as the following:
Brski-aeは、次のようなシナリオで使用するように設計されています。
* When pledges and/or the target domain leverage an existing certificate enrollment protocol other than EST, such as CMP.
* 誓約および/またはターゲットドメインが、CMPなどのEST以外の既存の証明書登録プロトコルを活用する場合。
* When the application context precludes the use of EST for certificate enrollment due to factors such as when:
* アプリケーションコンテキストが、次のような要因により、証明書登録にESTの使用を排除する場合：
- The Registration Authority (RA) is not co-located with the registrar and requires end-to-end authentication of requesters, which EST does not support over multiple transport hops.
- 登録機関（RA）はレジストラと共同で開催されておらず、ESTが複数の輸送ホップでサポートしていないリクエスターのエンドツーエンド認証を必要とします。
- The RA or Certification Authority (CA) operator mandates auditable proof of origin for Certificate Signing Requests (CSRs), which cannot be provided by TLS as it only offers transient source authentication.
- RAまたは認証局（CA）オペレーターは、TLSが一時的なソース認証のみを提供するため、TLSが提供することはできない証明書署名リクエスト（CSR）に対して、監査可能な原産地証明を義務付けています。
- Certificates are requested for key types, such as Key Encapsulation Mechanism (KEM) keys, that do not support signing or other single-shot proof-of-possession methods as those described in [RFC6955]. EST, which relies on CSRs in PKCS #10 format [RFC2986], does not accommodate these key types because it necessitates proof-of-possession methods that operate within a single message, whereas proof of possession for KEM keys requires prior receipt of a fresh challenge value.
- [RFC6955]に記載されているように、署名やその他のシングルショットの証明の方法をサポートしていないキーカプセル化メカニズム（KEM）キーなどのキータイプの証明書が要求されます。PKCS＃10形式[RFC2986]のCSRSに依存するESTは、単一のメッセージ内で動作するプルーフオブポッセッション方法を必要とするため、これらの重要なタイプに対応していませんが、KEMキーの所有証明には新たなチャレンジ値を事前に受信する必要があります。
- The pledge implementation employs security libraries that do not support EST or uses a TLS library lacking support for the "tls-unique" value [RFC5929], which EST requires for the strong binding of source authentication.
- 誓約の実装では、ESTがソース認証の強力な拘束力を必要とする「TLS-Unique」値[RFC5929]をサポートしていないTLSライブラリをサポートしていない、または使用するセキュリティライブラリを採用しています。
* When full RA functionality is not available on-site within the target domain, and connectivity to an off-site RA may be intermittent or entirely offline.
* ターゲットドメイン内で完全なRA機能がオンサイトで利用できない場合、およびオフサイトRAへの接続は断続的または完全にオフラインである場合があります。
* When authoritative actions by a local RA at the registrar are insufficient for fully and reliably authorizing pledge certification requests, potentially due to a lack of access to necessary data or inadequate security measures, such as the local storage of private keys.
* レジストラのローカルRAによる権威あるアクションが、必要なデータへのアクセスが不足しているため、またはプライベートキーのローカルストレージなどの不十分なセキュリティ対策のために、誓約認証要求を完全かつ確実に許可するには不十分な場合。
Bootstrapping may be managed in various ways depending on the application domain. Appendix A provides illustrative examples from different industrial control system environments and operational contexts that motivate the support of alternative enrollment protocols.
ブートストラップは、アプリケーションドメインに応じてさまざまな方法で管理できます。付録Aは、代替登録プロトコルのサポートを動機付けるさまざまな産業制御システム環境と運用コンテキストからの例示的な例を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document relies on the terminology defined in [RFC8995], [RFC5280], and [IEEE_802.1AR-2018], which is partly repeated here. Several further terms are also described here.
このドキュメントは、[RFC8995]、[RFC5280]、および[IEEE_802.1AR-2018]で定義されている用語に依存しており、ここで部分的に繰り返されます。ここでは、さらにいくつかの用語について説明します。
To be independent of the terminology of a specific enrollment protocol, this document utilizes generic terminology regarding PKI management operations.
特定の登録プロトコルの用語とは独立しているため、このドキュメントはPKI管理操作に関する汎用用語を利用しています。
The following terminology is used in this document:
このドキュメントでは、次の用語が使用されています。
asynchronous:
非同期：
the time-wise interrupted delivery of messages, here, between a pledge and some backend system (e.g., an RA).
ここでは、誓約といくつかのバックエンドシステム（例えば、RA）の間のメッセージの時間的に中断された配信。
attribute request:
属性リクエスト：
a message requesting content to be included in the certification request.
認定リクエストにコンテンツを含めるように要求するメッセージ。
attribute response:
属性応答：
a message providing the answer to the attribute request.
属性要求に対する回答を提供するメッセージ。
authenticated self-contained object:
認証された自己完結型オブジェクト：
a data structure that is cryptographically bound to the identity of its originator by an attached digital signature on the actual object, using a private key of the originator such as the IDevID secret.
Idevid Secretなどのオリジネーターの秘密鍵を使用して、実際のオブジェクトに添付されたデジタル署名によって、そのオリジネーターのアイデンティティに暗号化されたデータ構造。
backend:
バックエンド：
the placement of a domain component separately from the domain registrar; it may be on-site or off-site.
ドメインレジストラとは別にドメインコンポーネントの配置。オンサイトまたはオフサイトである場合があります。
CA certs request:
CA証明書のリクエスト：
a message requesting CA certificates.
CA証明書を要求するメッセージ。
CA certs response:
CA証明書の応答：
a message providing the answer to a CA certs request.
CA証明書リクエストに対する回答を提供するメッセージ。
certificate confirm:
証明書確認：
a message stating to the backend PKI that the requester of a certificate received the new certificate and accepted it.
証明書の要求者が新しい証明書を受け取って受け入れたことをバックエンドPKIに示すメッセージ。
certification request:
認定リクエスト：
a message requesting a certificate with proof of identity.
アイデンティティの証明を備えた証明書を要求するメッセージ。
certification response:
認定応答：
a message providing the answer to a certification request.
認定リクエストへの回答を提供するメッセージ。
local RA:
ローカルRA：
the same as LRA.
LRAと同じです。
off-site:
オフサイト：
the locality of a component, service, or functionality (such as RA or CA) that is not at the site of the registrar. This may be a central site or a cloud service, to which connection may be intermittent.
レジストラのサイトにないコンポーネント、サービス、または機能（RAやCAなど）の局所性。これは、中央のサイトまたはクラウドサービスである可能性があり、接続が断続的である可能性があります。
on-site:
現場で：
the locality of a component, service, or functionality at the site of the registrar.
レジストラのサイトでのコンポーネント、サービス、または機能の局所性。
PKI/registrar confirm:
PKI/レジストラ確認：
an acknowledgment of the PKI on the certificate confirm.
証明書のPKIの承認確認。
pledge:
誓約：
a device that is to be bootstrapped into a target domain. It requests an LDevID using IDevID credentials installed by its manufacturer.
ターゲットドメインにブートストラップされるデバイス。メーカーがインストールしたIDEVID資格情報を使用してLDEVIDを要求します。
registrar:
レジストラ：
short for domain registrar.
ドメインレジストラの略。
site:
サイト：
the locality where an entity such as a pledge, registrar, or PKI component is deployed. The target domain may have multiple sites.
誓約、レジストラ、PKIコンポーネントなどのエンティティが展開される地域。ターゲットドメインには複数のサイトがある場合があります。
synchronous:
同期：
the time-wise uninterrupted delivery of messages, here, between a pledge and a registrar or backend system (e.g., the MASA).
ここでは、誓約とレジストラまたはバックエンドシステム（MASAなど）の間のメッセージの途切れない配信。
target domain:
ターゲットドメイン：
the domain that a pledge is going to be bootstrapped into.
誓約がブートストラップされるドメイン。
The following abbreviations are used in this document:
このドキュメントでは、次の略語が使用されています。
BRSKI:
Brski：
Bootstrapping Remote Secure Key Infrastructure [RFC8995]
ブートストラップリモートセキュアなキーインフラストラクチャ[RFC8995]
BRSKI-AE:
Brski-ae：
BRSKI with Alternative Enrollment. Refers to a variation of BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol between the pledge and the registrar, is replaced by enrollment protocols that support end-to-end authentication of the pledge to the RA, such as CMP.
代替登録を備えたBrski。誓約とレジストラの間の登録プロトコルであるBrski-estが、CMPなどのRAへの誓約のエンドツーエンド認証をサポートする登録プロトコルに置き換えるBrski [RFC8995]のバリエーションを指します。
CA:
CA:
Certification Authority
認証機関
CMC:
CMC:
Certificate Management over CMS
CMSを超える証明書管理
CMP:
CMP:
Certificate Management Protocol [RFC4210] [RFC9480]
証明書管理プロトコル[RFC4210] [RFC9480]
CMS:
CMS:
Cryptographic Message Syntax
暗号化メッセージ構文
CRMF:
CRMF：
Certificate Request Message Format
証明書リクエストメッセージフォーマット
CSR:
CSR:
Certificate Signing Request
証明書署名リクエスト
EST:
EST:
Enrollment over Secure Transport [RFC7030]
安全な輸送の登録[RFC7030]
IDevID:
IDEVID：
Initial Device IDentifier (of a pledge, provided by the manufacturer and comprising of a private key and the related X.509 certificate with its chain).
初期デバイス識別子（メーカーが提供し、秘密鍵とそのチェーンを使用した関連X.509証明書で構成される誓約の誓約）。
LCMPP:
LCMPP：
Lightweight CMP Profile [RFC9483]
軽量CMPプロファイル[RFC9483]
LDevID:
ldevid：
Locally Significant Device IDentifier (of a pledge, provided by its target domain and comprising of a private key and the related X.509 certificate with its chain).
局所的に重要なデバイス識別子（誓約のターゲットドメインによって提供され、秘密鍵とそのチェーンを使用した関連X.509証明書で構成される）。
LRA:
LRA:
Local Registration Authority. A subordinate RA that is close to entities being enrolled and separate from a subsequent RA. In BRSKI-AE, it is needed if a backend RA is used; in this case, the LRA is co-located with the registrar.
地方登録機関。登録されており、その後のRAから分離されているエンティティに近い下位RA。Brski-aeでは、バックエンドRAを使用する場合が必要です。この場合、LRAはレジストラと共同で開催されます。
MASA:
マサ：
Manufacturer Authorized Signing Authority. Provides vouchers.
製造業者は署名権限を認めました。バウチャーを提供します。
RA:
RA:
Registration Authority. The PKI component to which a CA typically delegates certificate management functions such as authenticating pledges and performing authorization checks on certification requests.
登録機関。CAが通常、誓約の認証や認証要求の承認チェックを実行するなどの証明書管理機能を委任するPKIコンポーネント。
SCEP:
SCEP：
Simple Certificate Enrolment Protocol
簡単な証明書登録プロトコル
Based on the intended target scenarios described in Section 1.1 and the application examples described in Appendix A, the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests.
セクション1.1で説明されている目的のターゲットシナリオと付録Aで説明したアプリケーションの例に基づいて、認証された自己完結型オブジェクトを認証リクエストを運ぶコンテナとしてサポートするために次の要件が導出されます。
The following properties are required for a certification request:
認定リクエストには、次のプロパティが必要です。
* Proof of possession: demonstrates access to the private key corresponding to the public key contained in a certification request. This is typically achieved by a self-signature using the corresponding private key but can also be achieved indirectly; see [RFC4210], Section 4.3.
* 所有証明：認証要求に含まれる公開キーに対応する秘密鍵へのアクセスを示します。これは通常、対応する秘密鍵を使用して自己署名によって達成されますが、間接的に達成することもできます。[RFC4210]、セクション4.3を参照してください。
* Proof of identity (also called "proof of origin"): provides data origin authentication of the certification request. Typically, this is achieved by a signature using the pledge IDevID secret over some data, which needs to include a sufficiently strong identifier of the pledge, such as the device serial number typically included in the subject of the IDevID certificate.
* アイデンティティの証明（「原産地の証明」とも呼ばれます）：認証要求のデータ原点認証を提供します。通常、これは、いくつかのデータに対する誓約IDEVIDの秘密を使用して署名によって達成されます。これには、IDEVID証明書の主題に通常含まれるデバイスのシリアル番号など、誓約の十分に強力な識別子を含める必要があります。
The remainder of this section gives a non-exhaustive list of solution examples, based on existing technology described in IETF documents.
このセクションの残りの部分は、IETFドキュメントで説明されている既存の技術に基づいて、ソリューションの例の網羅的ではないリストを示しています。
Certificate Signing Request (CSR) objects are data structures protecting only the integrity of the contained data and providing proof of possession for a (locally generated) private key. Important types of CSR data structures are:
証明書署名要求（CSR）オブジェクトは、含まれるデータの整合性のみを保護し、（ローカルに生成された）秘密鍵の所有証明を提供するデータ構造です。CSRデータ構造の重要なタイプは次のとおりです。
* PKCS #10 [RFC2986]: This very common form of CSR is self-signed to protect its integrity and to prove possession of the private key that corresponds to the public key included in the request.
* PKCS＃10 [RFC2986]：CSRのこの非常に一般的な形式は、その完全性を保護し、リクエストに含まれる公開鍵に対応する秘密鍵の所有を証明するために自己署名されています。
* Certificate Request Message Format (CRMF) [RFC4211]: This less common but more general CSR format supports several ways of integrity protection and proof of possession. Typically a self-signature is used, which is generated over (part of) the structure with the private key corresponding to the included public key. CRMF also supports further proof-of-possession methods for types of keys that do not have signing capability. For details, see [RFC4211], Section 4.
* 証明書リクエストメッセージフォーマット（CRMF）[RFC4211]：これはあまり一般的ではないが一般的なCSR形式は、整合性の保護と所持の証明のいくつかの方法をサポートしています。通常、自己署名が使用されます。これは、含まれている公開キーに対応する秘密鍵を持つ構造の上に生成されます。CRMFは、署名機能を持たないキーの種類のさらなるプルーフオブポッセッション方法もサポートしています。詳細については、[RFC4211]、セクション4を参照してください。
It should be noted that the integrity protection of CSRs includes the public key because it is part of the data signed by the corresponding private key. Yet, this signature does not provide data origin authentication, (i.e., proof of identity of the requester) because the key pair involved is new and therefore does not yet have a confirmed identity associated with it.
CSRの整合性保護には、対応する秘密鍵によって署名されたデータの一部であるため、公開鍵が含まれていることに注意する必要があります。しかし、この署名は、データの起源認証（つまり、要求者のIDの証明）を提供しません。これは、関与する重要なペアが新しく、したがって、それに関連する確認されたIDがまだないためです。
Binding a Certificate Signing Request (CSR) to an existing authenticated credential (which in the BRSKI context is the IDevID certificate) enables proof of origin, which in turn supports an authorization decision on the CSR.
証明書署名要求（CSR）を既存の認証された資格情報（BRSKIコンテキストではIDEVID証明書はIDEVID証明書です）に拘束する原点の証明を可能にし、CSRに関する承認決定をサポートします。
The binding of data origin authentication to the CSR is typically delegated to the protocol used for certificate management. This binding may be achieved through security options in an underlying transport protocol such as TLS if the authorization of the certification request is (sufficiently) done at the next communication hop. Depending on the key type, the binding can also be done in a stronger, transport-independent way by wrapping the CSR with a signature.
CSRへのデータ起源認証の拘束力は、通常、証明書管理に使用されるプロトコルに委任されます。この拘束力は、次の通信ホップで認証要求の承認が（十分に）行われた場合、TLSなどの基礎となる輸送プロトコルのセキュリティオプションを通じて達成できます。キータイプに応じて、CSRを署名で包むことにより、バインディングをより強力な輸送に依存しない方法で実行することもできます。
This requirement is addressed by existing enrollment protocols in various ways, such as:
この要件は、以下など、さまざまな方法で既存の登録プロトコルによって対処されます。
* EST [RFC7030] and its variant EST-coaps [RFC9148] utilize PKCS #10 to encode CSRs. While such a CSR has not been designed to include proof of origin, there is a limited, indirect way of binding it to the source authentication of the underlying TLS session. This is achieved by including in the CSR the "tls-unique" value [RFC5929] resulting from the TLS handshake. As this is optionally supported by the EST "/simpleenroll" endpoint used in BRSKI, and the TLS handshake employed in BRSKI includes certificate-based client authentication of the pledge with its IDevID credentials, the proof of pledge identity being an authenticated TLS client can be bound to the CSR.
* EST [RFC7030]とそのバリアントESTコップ[RFC9148]は、PKCS＃10を利用してCSRSをエンコードします。このようなCSRは、原点の証明を含めるように設計されていませんが、基礎となるTLSセッションのソース認証に結合する限定的で間接的な方法があります。これは、CSRにTLSの握手に起因する「TLS-Unique」値[RFC5929]を含めることによって達成されます。これはオプションでBRSKIで使用されるEST「/simpleEnroll」エンドポイントによってサポートされているため、BRSKIで採用されているTLSハンドシェイクには、そのIDEVID資格による誓約の証明書ベースのクライアント認証が含まれています。
Yet, this binding is only valid in the context of the TLS session established with the registrar acting as the EST server and typically also as an RA. So even such a cryptographic binding of the authenticated pledge identity to the CSR is not visible nor verifiable to authorization points outside the registrar, such as a (second) RA in the backend. What the registrar needs to do is authenticate and pre-authorize the pledge and indicate this to the (second) RA. This is done by signing the forwarded certification request with its private key and a related certificate that has the id-kp-cmcRA extended key usage attribute.
ただし、このバインディングは、レジストラがESTサーバーとして機能するTLSセッションのコンテキストでのみ有効です。通常はRAとしても機能します。したがって、CSRに対する認証された誓約アイデンティティのそのような暗号化結合でさえ、バックエンドの（2番目の）RAなど、レジストラの外側の承認ポイントに表示されないか検証できません。レジストラがしなければならないことは、誓約を認証して事前に認めることであり、これを（2番目の）RAに示すことです。これは、秘密キーとID-KP-CMCRAが拡張キー使用属性を備えた関連証明書を備えた転送された認証要求に署名することによって行われます。
[RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS #10 with a Full PKI Request message sent to the "/fullcmc" endpoint. This would allow for source authentication at the message level, such that the registrar could forward it to external RAs in a meaningful way. This approach is so far not sufficiently described and likely has not been implemented.
[RFC7030]、セクション2.5スケッチCSRは、「/fullCMC」エンドポイントに送信された完全なPKIリクエストメッセージを使用して、PKCS＃10ごとにフォーマットされています。これにより、メッセージレベルでソース認証が可能になり、レジストラが意味のある方法で外部RAに転送できます。このアプローチはこれまでのところ十分に説明されておらず、おそらく実装されていない可能性があります。
* The Simple Certificate Enrolment Protocol (SCEP) [RFC8894] supports using a shared secret (passphrase) or an existing certificate to protect CSRs based on SCEP Secure Message Objects using Cryptographic Message Syntax (CMS) wrapping [RFC5652]. Note that the wrapping using an existing IDevID in SCEP is referred to as "renewal". This way, SCEP does not rely on the security of the underlying message transfer.
* 単純な証明書登録プロトコル（SCEP）[RFC8894]は、共有秘密（パスフレーズ）または既存の証明書を使用して、暗号化メッセージの構文（CMS）ラッピング[RFC5652]を使用してSCEPセキュアメッセージオブジェクトに基づいてCSRを保護することをサポートします。SCEPで既存のIDEVIDを使用したラッピングは「更新」と呼ばれることに注意してください。これにより、SCEPは基礎となるメッセージ転送のセキュリティに依存していません。
* CMP [RFC4210] [RFC9480] supports using a shared secret (passphrase) or an existing certificate, which may be an IDevID credential, to authenticate certification requests via the PKIProtection structure in a PKIMessage. The certification request is typically encoded utilizing CRMF, while PKCS #10 is supported as an alternative. Thus, CMP does not rely on the security of the underlying message transfer.
* CMP [RFC4210] [RFC9480]は、pkimessageのpkip路構造を介して認証要求を認証するために、共有秘密（passphrase）または既存の証明書を使用して、idevid資格である可能性のある既存の証明書を使用してサポートします。認証要求は通常、CRMFを使用してエンコードされますが、PKCS＃10は代替としてサポートされています。したがって、CMPは、基礎となるメッセージ転送のセキュリティに依存していません。
* Certificate Management over CMS (CMC) [RFC5272] also supports utilizing a shared secret (passphrase) or an existing certificate to protect certification requests, which can be either in a CRMF or PKCS #10 structure. The proof of identity can be provided as part of a Full CMC Request based on CMS [RFC5652] and signed with an existing IDevID secret. Thus, CMC does not rely on the security of the underlying message transfer.
* CMS（CMC）の証明書管理（CMC）[RFC5272]は、CRMFまたはPKCS＃10構造のいずれかである可能性のある認証要求を保護するために、共有秘密（PassPhrase）または既存の証明書を使用することもサポートしています。アイデンティティの証明は、CMS [RFC5652]に基づく完全なCMC要求の一部として提供され、既存のIDEVID秘密で署名できます。したがって、CMCは、基礎となるメッセージ転送のセキュリティに依存していません。
To sum up, EST does not meet the requirements for authenticated self-contained objects, but SCEP, CMP, and CMC do. This document primarily focuses on CMP as it has more industry adoption than CMC and SCEP has issues not detailed here.
要約すると、ESTは認証された自己完結型オブジェクトの要件を満たしていませんが、SCEP、CMP、およびCMC DO。このドキュメントは、CMCやSCEPにはここで詳しく説明されていない問題があるよりも多くの業界採用があるため、主にCMPに焦点を当てています。
To enable using alternative certificate enrollment protocols supporting end-to-end authentication, asynchronous enrollment, and more general system architectures, BRSKI-AE provides some generalizations on BRSKI [RFC8995]. This way, authenticated self-contained objects such as those described in Section 3 above can be used for certificate enrollment, and RA functionality can be deployed freely in the target domain. Parts of the RA functionality can even be distributed over several nodes.
エンドツーエンド認証、非同期登録、およびより一般的なシステムアーキテクチャをサポートする代替証明書登録プロトコルを使用できるようにするために、BRSKI-AEはBRSKI [RFC8995]に関するいくつかの一般化を提供します。これにより、上記のセクション3で説明されているような認証された自己完結型オブジェクトは、証明書の登録に使用でき、RA機能はターゲットドメインに自由に展開できます。RA機能の一部は、いくつかのノードに分布することもできます。
The enhancements are kept to a minimum to ensure the reuse of already defined architecture elements and interactions. In general, the communication follows the BRSKI model and utilizes the existing BRSKI architecture elements. In particular, the pledge initiates communication with the domain registrar and interacts with the MASA as usual for voucher request and response processing.
拡張機能は、すでに定義されているアーキテクチャ要素と相互作用の再利用を確保するために最小限に抑えられます。一般に、通信はBRSKIモデルに従い、既存のBRSKIアーキテクチャ要素を利用します。特に、誓約はドメインレジストラとの通信を開始し、バウチャーの要求と応答処理のために通常どおりMASAと対話します。
The key element of BRSKI-AE is that the authorization of a certification request MUST be performed based on an authenticated self-contained object. The certification request is bound in a self-contained way to a proof of origin based on the IDevID credentials. Consequently, the certification request MAY be transferred using any mechanism or protocol. Authentication and authorization of the certification request can be done by the domain registrar and/or by backend domain components. As mentioned in Section 1.1, these components may be offline or off-site. The registrar and other on-site domain components may have no or only temporary (intermittent) connectivity to them.
Brski-aeの重要な要素は、認証された自己完結型オブジェクトに基づいて認証要求の承認を実行する必要があることです。認証要求は、自己完結型の方法で、IDEVID資格情報に基づいた原産地の証明に縛られています。したがって、認証要求は、メカニズムまたはプロトコルを使用して転送される場合があります。認証要求の認証と承認は、ドメインレジストラおよび/またはバックエンドドメインコンポーネントによって実行できます。セクション1.1で述べたように、これらのコンポーネントはオフラインまたはオフサイトである場合があります。レジストラおよびその他のオンサイトドメインコンポーネントには、それらへの一時的な（断続的な）接続がない場合があります。
This leads to generalizations in the placement and enhancements of the logical elements as shown in Figure 1.
これは、図1に示すように、論理要素の配置と強化の一般化につながります。
+------------------------+
+--------------Drop-Ship--------------| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| |
V | BRSKI-
+--------+ ......................................... | MASA
| | . . |
| | . +-------+ +--------------+ . |
| Pledge | . | Join | | Domain |<----+
| |<------>| Proxy |<-------->| Registrar | .
| | . | | | w/ LRA or RA | .
| IDevID | . +-------+ +--------------+ .
| | BRSKI-AE over TLS ^ .
+--------+ using, e.g., LCMPP | .
. | .
...............................|.........
on-site (local) domain components |
|
| e.g., LCMPP
|
.............................................|...............
. Public-Key Infrastructure (PKI) v .
. +---------+ +---------------------------------------+ .
. | |<----+ Registration Authority RA | .
. | CA +---->| (unless part of Domain Registrar) | .
. +---------+ +---------------------------------------+ .
.............................................................
backend (central or off-site) domain components
Figure 1: Architecture Overview Using Backend PKI Components
図1：バックエンドPKIコンポーネントを使用したアーキテクチャの概要
The architecture overview in Figure 1 has the same logical elements as BRSKI but with a more flexible placement of the authentication and authorization checks on certification requests. Depending on the application scenario, the registrar MAY still do all of these checks (as is the case in BRSKI) or only do part of them.
図1のアーキテクチャの概要には、BRSKIと同じ論理要素がありますが、認証要求の認証と認証チェックのより柔軟な配置があります。アプリケーションシナリオに応じて、レジストラは引き続きこれらのチェックをすべて行うことができます（BRSKIの場合のように）、またはそれらの一部のみを行うことができます。
The following list describes the on-site components in the target domain of the pledge shown in Figure 1.
次のリストでは、図1に示す誓約のターゲットドメインのオンサイトコンポーネントについて説明します。
* Join Proxy: This has the same requirements as in [RFC8995] (see [RFC8995], Section 4).
* 参加：これは[RFC8995]と同じ要件を持っています（[RFC8995]、セクション4を参照）。
* Domain Registrar (including LRA or RA functionality): In BRSKI-AE, the domain registrar has mostly the same functionality as in BRSKI, namely to act as the gatekeeper of the domain for onboarding new devices and to facilitate the communication of pledges with their MASA and the domain PKI. Yet, there are some generalizations and specific requirements:
* ドメインレジストラ（LRAまたはRA機能を含む）：BRSKI-AEでは、ドメインレジストラはBRSKIとほとんど同じ機能を持っています。つまり、新しいデバイスをオンボーディングするためのドメインのゲートキーパーとして機能し、MASAおよびドメインPKIとの誓約の通信を促進します。しかし、いくつかの一般化と特定の要件があります。
1. The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. To this end, the URI scheme for addressing endpoints at the registrar is generalized (see Section 4.3).
1. レジストラは、認証要求のために認証された自己完結型オブジェクトを使用して、少なくとも1つの証明書登録プロトコルをサポートする必要があります。この目的のために、レジストラでエンドポイントに対処するためのURIスキームが一般化されています（セクション4.3を参照）。
2. Rather than having full RA functionality, the registrar MAY act as a Local Registration Authority (LRA) and delegate part of its involvement in certificate enrollment to a backend RA. In such scenarios, the registrar optionally checks certification requests it receives from pledges and forwards them to the backend RA, which performs the remaining parts of the enrollment request validation and authorization. Note that to this end, the backend RA may need information regarding the authorization of pledges from the registrar or from other sources. On the way back, the registrar forwards responses by the PKI to the pledge on the same channel.
2. レジストラは、完全なRA機能を持つのではなく、ローカル登録機関（LRA）として機能し、証明書登録への関与の一部をバックエンドRAへの関与の一部に委任することができます。このようなシナリオでは、レジストラはオプションで誓約から受け取った認定要求をチェックし、登録要求の検証と承認の残りの部分を実行するバックエンドRAに転送します。この目的のために、バックエンドRAは、レジストラまたは他のソースからの誓約の承認に関する情報が必要になる場合があることに注意してください。帰り道、レジストラは、PKIによる同じチャネルの誓約に応答を転送します。
To support end-to-end authentication of the pledge across the registrar to the backend RA, the certification request signed by the pledge needs to be upheld and forwarded by the registrar. Therefore, for its communication with the PKI, the registrar cannot use an enrollment protocol that is different from the enrollment protocol used between the pledge and the registrar.
レジストラ全体でバックエンドRAへの誓約のエンドツーエンド認証をサポートするには、誓約によって署名された認証要求を登録官によって支持し、転送する必要があります。したがって、PKIとの通信のために、レジストラは、誓約とレジストラの間で使用される登録プロトコルとは異なる登録プロトコルを使用できません。
3. The use of a certificate enrollment protocol with authenticated self-contained objects gives freedom with how to transfer enrollment messages between the pledge and an RA. BRSKI demands that the RA accept certification requests for LDevIDs only with the consent of the registrar. BRSKI-AE also guarantees this in the case that the RA is not part of the registrar, even if the message exchange with backend systems is unprotected and involves further transport hops. See Section 7 for details on how this can be achieved.
3. 認証された自己完結型オブジェクトを使用した証明書登録プロトコルの使用は、誓約とRAの間に登録メッセージを転送する方法と自由を与えます。BRSKIは、RAがレジストラの同意を得てのみLDEVIDの認証要求を受け入れることを要求します。Brski-aeは、バックエンドシステムとのメッセージ交換が保護されておらず、さらなる輸送ホップを含む場合でも、RAがレジストラの一部ではない場合にこれを保証します。これを達成する方法の詳細については、セクション7を参照してください。
Despite the above generalizations of the enrollment phase, the final step of BRSKI, namely the enrollment status telemetry, is kept as it is.
上記の登録フェーズの一般化にもかかわらず、BRSKIの最終ステップ、つまり登録ステータステレメトリはそのまま保持されます。
The following list describes the components provided by the vendor or manufacturer outside the target domain.
次のリストでは、ターゲットドメイン外のベンダーまたはメーカーが提供するコンポーネントについて説明します。
* MASA: This has the functionality as described in [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in [RFC8995].
* MASA：これには、[RFC8995]で説明されている機能があります。[RFC8995]に記載されているように、ドメインレジストラを介してMASAとのバウチャー交換が実行されます。
Note: The definition of the interaction with the MASA in Section 5 of [RFC8995] implies that it may be synchronous (using voucher requests with nonces) or asynchronous (using nonceless voucher requests).
注：[RFC8995]のセクション5のMASAとの相互作用の定義は、それが同期（Noncesを使用したバウチャー要求を使用）または非同期（非無知なバウチャーリクエストを使用）である可能性があることを意味します。
* Ownership Tracker: This is as defined in [RFC8995].
* 所有権トラッカー：これは[RFC8995]で定義されています。
The following list describes backend target domain components, which may be located on-site or off-site in the target domain.
次のリストでは、バックエンドターゲットドメインコンポーネントについて説明します。これは、ターゲットドメインの現場またはオフサイトで配置される場合があります。
* RA: This performs centralized certificate management functions as a PKI for the domain operator. In case these functions are not entirely performed by the domain registrar, it performs the final validation and authorization of certification requests. Otherwise, the RA co-located with the domain registrar directly connects to the CA.
* RA：これにより、ドメイン演算子のPKIとして集中化された証明書管理機能が実行されます。これらの機能がドメインレジストラによって完全に実行されない場合、認定リクエストの最終的な検証と承認を実行します。それ以外の場合、ドメインレジストラと共同住宅がCAに直接接続します。
* CA (also called "domain CA"): This generates domain-specific certificates according to certification requests that have been authenticated and authorized by the registrar and/or an extra RA.
* CA（「ドメインCA」とも呼ばれます）：これは、レジストラおよび/または追加のRAによって認証および承認された認証要求に従ってドメイン固有の証明書を生成します。
Based on the diagram in [RFC8995], Section 2.1 and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differences with the original approach as follows.
[RFC8995]、セクション2.1、およびアーキテクチャの変化の図に基づいて、元のプロトコルの流れは、次のように元のアプローチとの共通性と違いを示すいくつかのフェーズに分割されます。
* Discover: This is mostly as in step (1) of [RFC8995]. For details, see Section 4.2.1.
* 発見：これは主に[RFC8995]のステップ（1）と同じです。詳細については、セクション4.2.1を参照してください。
* Identify: This is the same as in step (2) of [RFC8995].
* 識別：これは[RFC8995]のステップ（2）と同じです。
* Voucher exchange: This is the same as in steps (3) and (4) of [RFC8995].
* バウチャー交換：これは、[RFC8995]の手順（3）および（4）と同じです。
* Voucher status telemetry: This is the same as directly after step (4) in [RFC8995].
* バウチャーステータステレメトリ：これは、[RFC8995]のステップ（4）の直後と同じです。
* Certificate enrollment phase: The use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevID certificate.
* 証明書の登録フェーズ：ステップ（5）でのESTの使用は、LDEVID証明書を要求するために認証された自己完結型オブジェクトを使用する証明書登録プロトコルを採用するように変更されます。
It is REQUIRED to use the (D)TLS channel established between the pledge and registrar to transport the certificate enrollment request and response messages. To this end, the enrollment protocol, the pledge, and the registrar need to support the use of this existing channel for certificate enrollment. Due to this architecture, the pledge does not need to establish additional connections for certificate enrollment and the registrar retains full control over the certificate enrollment traffic.
誓約とレジストラの間に確立された（d）TLSチャネルを使用して、証明書の登録要求と応答メッセージを輸送する必要があります。この目的のために、登録プロトコル、誓約、およびレジストラは、証明書登録のためにこの既存のチャネルの使用をサポートする必要があります。このアーキテクチャのため、誓約は証明書の登録のために追加の接続を確立する必要はなく、レジストラは証明書登録トラフィックの完全な制御を保持します。
* Enrollment status telemetry: This is the final exchange of step (5) of [RFC8995].
* 登録ステータステレメトリ：これは、[RFC8995]のステップ（5）の最終交換です。
The behavior of a pledge described in [RFC8995], Section 2.1 is kept, with one major exception. After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects, as explained in Section 3. Section 5 discusses selected suitable enrollment protocols and applicable options.
[RFC8995]に記載されている誓約の動作は、セクション2.1が保持され、1つの大きな例外を除きます。インプリントステップ（4）を終了した後、セクション3で説明されているように、登録ステップ（5）は、認証された自己完結型オブジェクトを使用して登録プロトコルで実行する必要があります。
An abstract overview of the BRSKI-AE protocol can be found in the graphics on slide 4 of [BRSKI-AE-overview].
Brski-aeプロトコルの抽象的な概要は、[Brski-ae-overview]のSlide 4のグラフィックスに記載されています。
Discovery as specified in [RFC8995], Section 4 does not support the discovery of registrars with enhanced feature sets. A pledge cannot find out in this way whether discovered registrars support the certificate enrollment protocol it expects, such as CMP.
[RFC8995]で指定されている発見は、セクション4では、機能セットを強化したレジストラの発見をサポートしていません。この方法で、発見されたレジストラがCMPなどの予想される証明書登録プロトコルをサポートしているかどうかを誓約することはできません。
As a more general solution, the BRSKI discovery mechanism can be extended to provide up-front information on the capabilities of registrars. For further discussion, see [BRSKI-discovery].
より一般的な解決策として、BRSKI発見メカニズムを拡張して、レジストラの機能に関する前向きな情報を提供することができます。詳細については、[Brski-discovery]を参照してください。
In the absence of such a generally applicable solution, BRSKI-AE deployments may use their particular way of doing discovery. Section 5.1 defines a minimalist approach that MAY be used for CMP.
このような一般的に適用可能なソリューションがない場合、Brski-aeの展開は、発見を行う特定の方法を使用する場合があります。セクション5.1は、CMPに使用できるミニマリストアプローチを定義しています。
The voucher exchange is performed as specified in [RFC8995].
バウチャー交換は[RFC8995]で指定されているように実行されます。
The voucher status telemetry is performed as specified in [RFC8995], Section 5.7.
バウチャーステータステレメトリは、[RFC8995]、セクション5.7で指定されているとおりに実行されます。
The specification in this section replaces the EST integration for PKI bootstrapping described in [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the final phase; see below).
このセクションの仕様は、[RFC8995]、セクション5.9（[RFC8995]、セクション5.9.4に記載されているPKIブートストラップのEST統合に置き換えられます。
The certificate enrollment phase may involve the transmission of several messages. Details can depend on the application scenario, the employed enrollment protocol, and other factors.
証明書登録フェーズには、いくつかのメッセージの送信が含まれる場合があります。詳細は、アプリケーションシナリオ、採用された登録プロトコル、およびその他の要因に依存します。
The only message exchange REQUIRED is for the actual certification request and response. Further message exchanges MAY be performed as needed.
必要な唯一のメッセージ交換は、実際の認証要求と応答です。必要に応じて、さらなるメッセージ交換が実行される場合があります。
Note: The message exchanges marked OPTIONAL in Figure 2 below cover all those supported by the use of EST in BRSKI. The last OPTIONAL one, namely certificate confirmation, is not supported by EST but by CMP and other enrollment protocols.
注：以下の図2でオプションのマークされたメッセージ交換は、BRSKIでのESTの使用によってサポートされているすべてのものをカバーしています。最後のオプションのもの、つまり証明書確認は、ESTではなく、CMPおよびその他の登録プロトコルによってサポートされています。
+------+ +---------+ +--------+
|Pledge| |Domain | |Operator|
| | |Registrar| |RA/CA |
| | |(JRC) | |(PKI) |
+------+ +---------+ +--------+
| | |
|[OPTIONAL request of CA certificates]| |
|------- CA Certs Request (1) ------->| |
| | [OPTIONAL forwarding] |
| |--- CA Certs Request ----->|
| |<-- CA Certs Response -----|
|<------ CA Certs Response (2) -------| |
| | |
|[OPTIONAL request of attributes | |
| to include in Certification Request]| |
|------- Attribute Request (3) ------>| |
| | [OPTIONAL forwarding] |
| |--- Attribute Request ---->|
| |<-- Attribute Response ----|
|<------ Attribute Response (4) ------| |
| | |
|[REQUIRED certification request] | |
|------- Certification Request (5) -->| |
| | [OPTIONAL forwarding] |
| |---Certification Request-->|
| |<--Certification Resp. ---|
|<----- Certification Response (6) ---| |
| | |
|[OPTIONAL certificate confirmation] | |
|------- Certificate Confirm (7) ---->| |
| | [OPTIONAL forwarding] |
| |--- Certificate Confirm--->|
| |<-- PKI Confirm -----------|
|<------ PKI/Registrar Confirm (8) ---| |
Figure 2: Certificate Enrollment Message Flow
図2：証明書登録メッセージフロー
It may be noted that connections between the registrar and the PKI components of the operator (RA, CA, etc.) may be intermittent or offline. Messages should be sent as soon as sufficient transfer capacity is available.
レジストラとオペレーターのPKIコンポーネント（RA、CAなど）の接続は、断続的またはオフラインである可能性があることに注意してください。十分な転送容量が利用可能になり次第、メッセージを送信する必要があります。
The label '[OPTIONAL forwarding]' in Figure 2 means that on receiving a request message of the given type from a pledge, the registrar MAY answer the request directly. In this case, it MUST authenticate its responses with the same credentials as used for authenticating itself at the TLS level for the voucher exchange. Otherwise, the registrar MUST forward the request to the RA and forward any resulting response back to the pledge.
図2のラベル「[オプション転送]」は、誓約から指定されたタイプのリクエストメッセージを受信すると、レジストラがリクエストに直接回答できることを意味します。この場合、バウチャーエクスチェンジのTLSレベルで認証するために使用されるのと同じ資格情報で応答を認証する必要があります。それ以外の場合、レジストラは要求をRAに転送し、結果として生じる応答を誓約に転送する必要があります。
The decision of whether to forward a request or to answer it directly can depend on various static and dynamic factors. They include the application scenario, the capabilities of the registrar, the capabilities of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request.
リクエストを転送するか、それに直接答えるかの決定は、さまざまな静的要因と動的要因に依存する可能性があります。それらには、アプリケーションシナリオ、レジストラの機能、レジストラと共同住宅されたローカルRAの機能、使用されている登録プロトコル、およびリクエストの特定のコンテンツが含まれます。
Note that there are several options for how the registrar could be able to directly answer requests for CA certificates or for certification request attributes. It could cache responses obtained from the domain PKI and later use their contents for responding to requests asking for the same data. The contents could also be explicitly provisioned at the registrar.
レジストラがCA証明書のリクエストまたは認証要求属性のリクエストに直接回答する方法については、いくつかのオプションがあることに注意してください。ドメインPKIから取得した応答をキャッシュし、後でコンテンツを使用して、同じデータを要求するリクエストに応答することができます。内容は、レジストラで明示的にプロビジョニングすることもできます。
Further note that certification requests typically need to be handled by the backend PKI, but the registrar can answer them directly with an error response in case it determines that such a request should be rejected, for instance, because it is not properly authenticated or authorized. Also, certificate confirmation messages will usually be forwarded to the backend PKI, but if the registrar knows that they are not needed or wanted there, it can acknowledge such messages directly.
さらに、認証要求は通常、バックエンドPKIによって処理される必要があることに注意してください。ただし、レジストラは、適切に認証または承認されていないため、そのような要求を拒否する必要があると判断した場合に、エラー応答で直接回答できます。また、証明書確認メッセージは通常、バックエンドPKIに転送されますが、レジストラがそこに必要であるか、望んでいないことを知っている場合、そのようなメッセージを直接確認できます。
The following list provides an abstract description of the flow depicted in Figure 2.
次のリストは、図2に示すフローの抽象的な説明を提供します。
* CA Certs Request (1): The pledge optionally requests the latest relevant CA certificates. This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert (which is contained in the voucher and which may be just the domain registrar certificate).
* CA証明書リクエスト（1）：誓約はオプションで最新の関連するCA証明書を要求します。これにより、誓約には、ピン留めドメイン洞窟（バウチャーに含まれており、ドメインレジストラ証明書にすぎない場合がある）を超えた現在のCA証明書の完全なセットが保証されます。
* CA Certs Response (2): This MUST contain any intermediate CA certificates that the pledge may need to validate certificates and MAY contain the LDevID trust anchor.
* CA証明書の応答（2）：これには、誓約が証明書を検証する必要がある可能性があり、LDEVIDトラストアンカーが含まれる場合がある中間CA証明書を含める必要があります。
* Attribute Request (3): Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. Nevertheless, there are cases in which the pledge may also include additional attributes that are specific to the target domain in the Certification Request (5). To get these attributes in advance, the attribute request may be used.
* 属性要求（3）：通常、自動化されたブートストラップは、誓約のローカル管理構成なしで発生します。それにもかかわらず、誓約には、認証要求のターゲットドメインに固有の追加の属性も含まれる場合があります（5）。これらの属性を事前に取得するには、属性要求を使用できます。
* Attribute Response (4): This MUST contain the attributes requested in (3) to be included in the subsequent Certification Request (5).
* 属性応答（4）：これには、（3）で要求された属性がその後の認証要求（5）に含まれるように要求されている必要があります。
For example, [RFC8994], Section 6.11.7.2 specifies how the attribute request is used to signal to the pledge the 'acp-node-name' field required for enrollment into an Autonomic Control Plane (ACP) domain.
たとえば、[RFC8994]、セクション6.11.7.2は、属性要求が自律制御プレーン（ACP）ドメインへの登録に必要な「ACPノード」フィールドを誓約するために属性要求を使用する方法を指定します。
* Certification Request (5): This MUST contain the authenticated self-contained object ensuring both the proof of possession of the corresponding private key and the proof of identity of the requester.
* 認証要求（5）：これには、対応する秘密鍵の所有証明とリクエスターの身元証明の両方を保証する認証された自己完結型オブジェクトが含まれている必要があります。
* Certification Response (6): On success, this MUST contain the requested certificate and MAY include further information, like certificates of intermediate CAs and any additional trust anchors.
* 認定応答（6）：成功すると、これには要求された証明書が含まれている必要があり、中間CAの証明書や追加の信頼アンカーなどのさらなる情報を含めることができます。
* Certificate Confirm (7): This is an optional confirmation that is sent after the requested certificate has been received and validated. If sent, it MUST contain a positive or negative confirmation by the pledge to the PKI whether the certificate was successfully enrolled and fits its needs.
* 証明書確認（7）：これは、要求された証明書が受信され、検証された後に送信されるオプションの確認です。送信された場合、証明書が正常に登録され、そのニーズに合っているかどうか、PKIに対する誓約による肯定的または否定的な確認が含まれている必要があります。
* PKI/Registrar Confirm (8): This is an acknowledgment by the PKI that MUST be sent on reception of the Certificate Confirm.
* PKI/レジストラ確認（8）：これは、証明書確認書の受信時に送信する必要があるPKIによる承認です。
The generic messages described above may be implemented using any certificate enrollment protocol that supports authenticated self-contained objects for the certification request as described in Section 3. Examples are available in Section 5.
上記の一般的なメッセージは、セクション3で説明されているように、認証要求の認証された自己完結型オブジェクトをサポートする証明書登録プロトコルを使用して実装できます。例はセクション5で入手できます。
Note that the optional certificate confirmation by the pledge to the PKI described above is independent of the mandatory enrollment status telemetry done between the pledge and the registrar in the final phase of BRSKI-AE, which is described next.
上記のPKIに対する誓約によるオプションの証明書確認は、BRSKI-AEの最終段階で誓約とレジストラの間で行われた強制登録ステータステレメトリとは無関係であり、次に説明します。
The enrollment status telemetry is performed as specified in [RFC8995], Section 5.9.4.
登録ステータステレメトリは、[RFC8995]、セクション5.9.4で指定されているとおりに実行されます。
In [RFC8995], this is described as part of the certificate enrollment step, but due to the generalization of the enrollment protocol described in this document, it is regarded as a separate phase here.
[RFC8995]では、これは証明書登録ステップの一部として説明されていますが、このドキュメントで説明されている登録プロトコルの一般化により、ここでは別のフェーズと見なされます。
BRSKI-AE extends the addressing scheme outlined in [RFC8995], Section 5 to support alternative enrollment protocols that utilize authenticated, self-contained objects for certification requests (also see Section 5). These extensions are designed to be compatible with existing Registration Authorities (RAs) and Certification Authorities (CAs) that already support such enrollment protocols, enabling their use without requiring any modifications.
BRSKI-AEは、セクション5 [RFC8995]に概説されているアドレス指定スキームを拡張して、認証された自己完結型のオブジェクトを認証要求に使用する代替登録プロトコルをサポートします（セクション5も参照）。これらの拡張機能は、既存の登録当局（RAS）および認定当局（CAS）と互換性があるように設計されており、そのような登録プロトコルを既にサポートしており、変更を必要とせずに使用できます。
The addressing scheme in [RFC8995] for certification requests, related CA certificates, and CSR attributes retrieval functions uses the definition from EST [RFC7030]. An example of simple enrollment is: "/.well-known/est/simpleenroll". This approach is generalized to the following notation: "/.well-known/<enrollment-protocol>/<request>" in which "<enrollment-protocol>" refers to a certificate enrollment protocol. Note that here, enrollment is considered a message sequence that contains at least a certification request and a certification response. The following conventions are used to provide maximal compatibility with BRSKI:
認証要求、関連するCA証明書、およびCSR属性の検索関数の[RFC8995]のアドレス指定スキームは、EST [RFC7030]の定義を使用します。単純な登録の例は、「/.Well-Nownest/SimpleenRoll」です。このアプローチは、次の表記に一般化されています。「/.Well-Nowned/<enrollment-Protocol>/<questocol>」では、「<Enrollment-Protocol>」は証明書登録プロトコルを指します。ここでは、登録は、少なくとも認定リクエストと認証応答を含むメッセージシーケンスと見なされることに注意してください。次の規則は、BRSKIとの最大の互換性を提供するために使用されます。
* "<enrollment-protocol>": This MUST reference the protocol being used. Existing values include 'est' [RFC7030] as in [RFC8995] and 'cmp' as in [RFC9483] and Section 5.1 below. Values for other existing protocols such as CMC and SCEP, as well as newly defined protocols, are outside the scope of this document. For use of the "<enrollment-protocol>" and "<request>" URI components, they would need to be specified in a suitable RFC and placed into the "Well-Known URIs" registry, just as EST in [RFC7030].
* 「<Enrollment-Protocol>」：これは、使用されているプロトコルを参照する必要があります。既存の値には、[RFC8995]のような「EST」[RFC7030]および[RFC9483]および以下のセクション5.1のような「cmp」が含まれます。CMCやSCEPなどの他の既存のプロトコル、および新たに定義されたプロトコルの値は、このドキュメントの範囲外です。「<Enrollment-Protocol>」と「<question>」URIコンポーネントを使用するには、適切なRFCで指定し、[RFC7030]のESTと同様に「よく知られているURIS」レジストリに配置する必要があります。
* "<request>": If present, this path component MUST describe the operation requested depending on the enrollment protocol being used. Enrollment protocols are expected to define their request endpoints, as is done by existing protocols (also see Section 5).
* 「<question>」：存在する場合、このパスコンポーネントは、使用されている登録プロトコルに応じて要求された操作を記述する必要があります。登録プロトコルは、既存のプロトコルによって行われるように、要求エンドポイントを定義することが期待されています（セクション5も参照）。
Well-known URIs for various endpoints on the domain registrar are already defined as part of the base BRSKI specification or indirectly by EST. In addition, alternative enrollment endpoints MAY be supported by the registrar.
ドメインレジストラ上のさまざまなエンドポイントのよく知られているURIは、基本BRSKI仕様の一部として、またはESTによって間接的に定義されています。さらに、代替の登録エンドポイントがレジストラによってサポートされる場合があります。
A pledge SHOULD use the endpoints defined for the enrollment protocol(s) that it can use. It will recognize whether the protocol it uses and the specific request it wants to perform are understood and supported by the domain registrar. This is done by sending the request to the respective endpoint according to the above addressing scheme and then evaluating the HTTP status code of the response. If the pledge uses endpoints that are not standardized, it risks that the registrar does not recognize a request and thus may reject it even if the registrar supports the intended protocol and operation.
誓約は、使用できる登録プロトコルに定義されたエンドポイントを使用する必要があります。使用するプロトコルと実行したい特定のリクエストがドメインレジストラによって理解およびサポートされているかどうかを認識します。これは、上記のアドレス指定スキームに従ってリクエストをそれぞれのエンドポイントに送信し、応答のHTTPステータスコードを評価することによって行われます。誓約が標準化されていないエンドポイントを使用している場合、レジストラがリクエストを認識しないため、レジストラが意図したプロトコルと操作をサポートしていても拒否する可能性があります。
The following list of endpoints provides an illustrative example of a domain registrar supporting several options for EST as well as for CMP to be used in BRSKI-AE. The listing contains the supported endpoints to which the pledge may connect for bootstrapping. This includes the voucher handling as well as the enrollment endpoints. The CMP-related enrollment endpoints are defined as well-known URIs in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483].
次のエンドポイントのリストは、ESTとBRSKI-AEで使用するCMPのいくつかのオプションをサポートするドメインレジストラの例を示しています。リストには、ブートストラップのために誓約が接続できるサポートされているエンドポイントが含まれています。これには、バウチャーの取り扱いと登録エンドポイントが含まれます。CMP関連の登録エンドポイントは、CMP更新[RFC9480]および軽量CMPプロファイル[RFC9483]でよく知られているURIとして定義されています。
* /.well-known/brski/voucherrequest
* /.well-nking/brski/voucherrequest
* /.well-known/brski/voucher_status
* /.well-nking/brski/voucher_status
* /.well-known/brski/enrollstatus
* /.well-known/brski/enrollstatus
* /.well-known/est/cacerts
* /.well-known/est/cacerts
* /.well-known/est/csrattrs
* /.well-known/est/csrattrs
* /.well-known/est/fullcmc
* /.WELL-NOWNES/EST/FULLCMC
* /.well-known/cmp/getcacerts
* /.well-nking/cmp/getCacerts
* /.well-known/cmp/getcertreqtemplate
* /.well-nking/cmp/getcertreqtemplate
* /.well-known/cmp/initialization
* /.well-known/cmp/initialization
* /.well-known/cmp/pkcs10
* /.well-known/cmp/pkcs10
This section maps the generic requirements to support proof of possession and proof of identity to selected existing certificate enrollment protocols and specifies further aspects of using such enrollment protocols in BRSKI-AE.
このセクションは、一般的な要件をマッピングして、所有の証明とアイデンティティの証明を選択した既存の証明書登録プロトコルにサポートし、Brski-aeでそのような登録プロトコルを使用することのさらなる側面を指定します。
In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) from [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in the LCMPP sufficiently meets the required functionality.
このドキュメントでは、LCMPPで定義されたCMPのサブセットが必要な機能を十分に満たしているように、[RFC4210]および[RFC9480]ではなく[RFC9483]ではなく[RFC9483]ではなく、[RFC9483]からの軽量CMPプロファイル（LCMPP）に従います。
Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The following specific requirements apply (refer to Figure 2):
CMPを使用する場合、LCMPP [RFC9483]の順守が必要です。次の特定の要件が適用されます（図2を参照）：
* The validation of server response messages performed by the CMP client within the pledge MUST be based on the trust anchor established beforehand via the BRSKI voucher, i.e., on the pinned-domain-cert.
* 誓約内でCMPクライアントによって実行されたサーバー応答メッセージの検証は、BRSKIバウチャーを介して、つまりピン留めドメイン洞窟で、事前に確立された信頼アンカーに基づいている必要があります。
Note that the integrity and authenticity checks on the RA/CA by the CMP client can be stronger than for EST because they do not need to be performed hop-by-hop but are usually end-to-end.
CMPクライアントによるRA/CAの整合性と信頼性のチェックは、ホップバイホップを実行する必要がないが、通常はエンドツーエンドであるため、ESTよりも強力になる可能性があることに注意してください。
* CA Certs Request (1) and Response (2): Requesting CA certificates is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.1.
* CA証明書リクエスト（1）および応答（2）：CA証明書の要求はオプションです。サポートされている場合、[RFC9483]、セクション4.3.1で指定されているように実装されます。
* Attribute Request (3) and Response (4): Requesting certification request attributes is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.3.
* 属性要求（3）および応答（4）：認証要求属性の要求はオプションです。サポートされている場合、[RFC9483]、セクション4.3.3で指定されているように実装されます。
Alternatively, the registrar MAY modify the requested certificate contents as specified in [RFC9483], Section 5.2.3.2.
あるいは、レジストラは、[RFC9483]、セクション5.2.3.2で指定されているように、要求された証明書の内容を変更する場合があります。
* Certification Request (5) and Response (6): Certificates SHALL be requested and provided as specified in the LCMPP from [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based on PKCS #10).
* 認証要求（5）および応答（6）：証明書は、[RFC9483]、セクション4.1.1（CRMFに基づく）または[RFC9483]、[RFC9483]、セクション4.1.4（PKCS＃10に基づく）のLCMPPで指定されているように要求および提供されます。
Proof of possession SHALL be provided in a manner suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message as outlined in [RFC9483], Section 3.2 using the IDevID secret.
所有証明は、キータイプに適した方法で提供されるものとします。アイデンティティの証明は、[RFC9483]で概説されている認証要求メッセージの署名ベースの保護によって提供されるものとします。
When the registrar forwards a certification request from the pledge to a backend RA/CA, it is RECOMMENDED that the registrar wraps the original certification request in a nested message signed with its own credentials, as described in [RFC9483], Section 5.2.2.1. This approach explicitly conveys the registrar's consent to the RA while retaining the original certification request with the proof of origin provided by the pledge's signature.
レジストラが誓約からバックエンドRA/CAに認定要求を転送する場合、[RFC9483]、セクション5.2.2.1で説明されているように、レジストラは独自の資格情報で署名されたネストされたメッセージで元の認証要求をラップすることをお勧めします。このアプローチは、RAに対するレジストラの同意を明示的に伝え、元の認証要求を誓約の署名によって提供された原点を保持します。
If additional trust anchors beyond the pinned-domain-cert need to be conveyed to the pledge, this SHOULD be done in the 'caPubs' field of the certification response rather than through a CA Certs Response.
ピン留めドメイン洞窟を超えた追加の信頼が誓約に伝えられる必要がある場合、これはCA証明書の応答ではなく、認証応答の「カプブ」フィールドで行う必要があります。
* Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit confirmation of new certificates to the RA/CA MAY be used as specified in [RFC9483], Section 4.1.1.
* 証明書の確認（7）およびPKI/レジストラの確認（8）：RA/CAへの新しい証明書の明示的な確認は、[RFC9483]、セクション4.1.1で指定されているように使用できます。
Note that independent of the certificate confirmation within CMP, enrollment status telemetry with the registrar at the BRSKI level will be performed as described in [RFC8995], Section 5.9.4.
CMP内の証明書確認とは無関係に、BRSKIレベルのレジストラとの登録ステータステレメトリは、[RFC8995]、セクション5.9.4で説明されているように実行されることに注意してください。
* If delayed delivery of CMP messages is needed (e.g., to support enrollment over an asynchronous channel), it SHALL be performed as specified in Sections 4.4 and 5.1.2 of [RFC9483].
* CMPメッセージの遅延配信が必要な場合（例えば、非同期チャネル上の登録をサポートするために）、[RFC9483]のセクション4.4および5.1.2で指定されているように実行するものとします。
The mechanisms for exchanging messages between the registrar and backend PKI components (i.e., RA and/or CA) are outside the scope of this document. CMP's independence from the message transfer mechanism allows for flexibility in choosing the appropriate exchange method based on the application scenario. For the applicable security and privacy considerations, refer to Sections 7 and 8. Further guidance can be found in [RFC9483], Section 6.
レジストラとバックエンドのPKIコンポーネント（つまり、RAおよび/またはCA）間でメッセージを交換するメカニズムは、このドキュメントの範囲外です。メッセージ転送メカニズムからのCMPの独立性により、アプリケーションシナリオに基づいて適切な交換方法を選択する柔軟性が可能になります。該当するセキュリティとプライバシーの考慮事項については、セクション7および8を参照してください。さらなるガイダンスは[RFC9483]、セクション6にあります。
BRSKI-AE with CMP can also be combined with Constrained BRSKI [cBRSKI], using CoAP for enrollment message transport as described by CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific parts of [cBRSKI] do not apply.
CMPを使用したBrski-aeは、CMP [RFC9482]のCOAP転送で説明されているように、登録メッセージトランスポートにCOAPを使用して、制約付きBRSKI [CBRSKI]と組み合わせることもできます。このようなシナリオでは、[cbrski]のEST固有の部分は適用されません。
For BRSKI-AE scenarios where a general solution for discovering registrars with CMP support is not available (cf. Section 4.2.1), the following minimalist approach MAY be used: Perform discovery as defined in [RFC8995], Appendix B, but use the service name "brski-reg-cmp" (as defined in Section 6) instead of "brski-registrar" (as defined in [RFC8995], Section 8.6). Note that this approach does not support join proxies.
CMPサポートでレジストラを発見するための一般的なソリューションが利用できないBRSKI-AEシナリオの場合（セクション4.2.1を参照）、次のミニマリストアプローチを使用できます。8.6）。このアプローチは、参加者の参加をサポートしていないことに注意してください。
Further instantiations of BRSKI-AE can be done. They are left for future work.
Brski-aeのさらなるインスタンス化を行うことができます。彼らは将来の仕事のために残されています。
In particular, CMC [RFC5272] (using its in-band source authentication options) and SCEP [RFC8894] (using its 'renewal' option) could be used.
特に、CMC [RFC5272]（帯域内のソース認証オプションを使用）およびSCEP [RFC8894]（「更新」オプションを使用）を使用できます。
The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might also be used here. For EST-fullCMC, further specification is necessary.
[RFC7030]でスケッチされたESTのFullCMCバリアントは、ここでも使用できます。est-fullcmcの場合、さらに仕様が必要です。
IANA has registered the following service name in the "Service Name and Transport Protocol Port Number Registry" <https://www.iana.org/assignments/service-names-port-numbers>.
IANAは、「サービス名とトランスポートプロトコルポート番号レジストリ」<https://www.iana.org/assignments/service-names-port-numbers>に次のサービス名を登録しています。
Service Name:
サービス名：
brski-reg-cmp
BRSKI-REG-CMP
Transport Protocol(s):
輸送プロトコル：
tcp
TCP
Description:
説明：
Bootstrapping Remote Secure Key Infrastructure registrar with CMP capabilities according to the Lightweight CMP Profile (LCMPP) [RFC9483]
Lightweight CMPプロファイル（LCMPP）に従って、CMP機能を備えたリモートセキュアーキーインフラストラクチャレジストラ[RFC9483]をブートストラップする
Assignee:
譲受人：
IESG <iesg@ietf.org>
iesg <iesg@ietf.org>
Contact:
接触：
IETF <chair@ietf.org>
ietf <chear@ietf.org>
Reference:
参照：
RFC 9733
RFC 9733
Note: We chose the suffix "cmp" here rather than some other abbreviation like "lcmpp" mainly because this document defines the normative CMP instantiation of BRSKI-AE, which implies adherence to the LCMPP is necessary and sufficient.
注：「LCMPP」のような他のいくつかの略語ではなく、ここで接尾辞「cmp」を選択しました。これは、このドキュメントがBrski-aeの規範的なCMPインスタンス化を定義しているため、LCMPPへの順守が必要であり、十分です。
The security considerations laid out in [RFC8995], Section 11 apply to the discovery and voucher exchange as well as for the status exchange information.
[RFC8995]に記載されているセキュリティ上の考慮事項、セクション11は、発見とバウチャーの交換、およびステータス交換情報に適用されます。
In particular, even if the registrar delegates part or all of its RA role during certificate enrollment to a separate system, it still must be made sure that the registrar takes part in the decision on accepting or declining a request to join the domain, as required in [RFC8995], Section 5.3. As this also pertains to obtaining a valid domain-specific certificate, it must be made sure that a pledge cannot circumvent the registrar in the decision of whether it is granted an LDevID certificate by the CA. There are various ways to fulfill this, including:
特に、レジストラが別のシステムへの証明書の登録中にRAの役割の一部またはすべてを代表していても、[RFC8995]で必要に応じてドメインに参加する要求を受け入れるか拒否する決定に登録官が参加することを確認する必要があります。セクション5.3。これは有効なドメイン固有の証明書を取得することにも関係しているため、CA。以下を含むさまざまな方法があります。
* implicit consent;
* 暗黙の同意;
* the registrar signaling its consent to the RA out-of-band before or during the enrollment phase, for instance, by entering the pledge identity in a database;
* レジストラは、たとえば、データベースに誓約IDを入力することにより、登録段階の前または登録段階の間にRAのアウトオブバンドに同意します。
* the registrar providing its consent using an extra message that is transferred on the same channel as the enrollment messages, possibly in a TLS tunnel; and
* レジストラは、登録メッセージと同じチャネルで、おそらくTLSトンネルで転送される追加のメッセージを使用して同意を提供します。そして
* the registrar explicitly stating its consent by signing the authenticated self-contained certificate enrollment request message in addition to the pledge.
* レジストラは、誓約に加えて、認証された自己完結型証明書登録要求メッセージに署名することにより、その同意を明示的に述べています。
Note: If EST was used, the registrar could give implicit consent on a certification request by forwarding the request to a PKI entity using a connection authenticated with a certificate containing an id-kp-cmcRA extension.
注：ESTが使用された場合、レジストラは、ID-KP-CMCRA拡張機能を含む証明書で認証された接続を使用して、リクエストをPKIエンティティに転送することにより、認証要求に暗黙の同意を与えることができます。
When CMP is used, the security considerations laid out in the LCMPP from [RFC9483] apply.
CMPを使用すると、[RFC9483]からLCMPPに記載されているセキュリティ上の考慮事項が適用されます。
The privacy considerations laid out in [RFC8995], Section 10 apply as well.
[RFC8995]にレイアウトされたプライバシーに関する考慮事項、セクション10も適用されます。
Note that CMP messages themselves are not encrypted. This may give eavesdroppers insight into which devices are bootstrapped into the domain. In turn, this might also be used to selectively block the enrollment of certain devices.
CMPメッセージ自体は暗号化されていないことに注意してください。これにより、デバイスがドメインにブートストラップされていることに関する盗聴者の洞察が得られる場合があります。次に、これは特定のデバイスの登録を選択的にブロックするためにも使用される場合があります。
To prevent such issues, the underlying message transport channel can be encrypted. This is already provided by TLS between the pledge and the registrar, and for the onward exchange with backend systems, encryption may need to be added.
このような問題を防ぐために、基礎となるメッセージ輸送チャネルを暗号化できます。これは、誓約とレジストラの間のTLSによって既に提供されており、バックエンドシステムとの以前の交換の場合、暗号化を追加する必要がある場合があります。
[IEEE_802.1AR-2018]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, November 2023,
<https://www.rfc-editor.org/info/rfc9483>.
[BRSKI-AE-overview]
von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "Update
on BRSKI-AE: Alternative Enrollment Protocols in BRSKI",
IETF 116 - ANIMA Working Group Presentation, March 2023,
<https://datatracker.ietf.org/meeting/116/materials/
slides-116-anima-update-on-brski-ae-alternative-
enrollment-protocols-in-brski-00>.
[BRSKI-discovery]
Eckert, T., Ed. and E. Dijk, "BRSKI discovery and
variations", Work in Progress, Internet-Draft, draft-ietf-
anima-brski-discovery-05, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-discovery-05>.
[cBRSKI] Richardson, M., Van der Stok, P., Kampanakis, P., and E.
Dijk, "Constrained Bootstrapping Remote Secure Key
Infrastructure (cBRSKI)", Work in Progress, Internet-
Draft, draft-ietf-anima-constrained-voucher-27, 3 March
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
anima-constrained-voucher-27>.
[IEC-62351-9]
International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and
communications security - Part 9: Cyber security key
management for power system equipment", IEC 62351-9:2023,
June 2023, <https://webstore.iec.ch/en/publication/66864>.
[ISO-IEC-15118-2]
International Organization for Standardization, "Road
vehicles - Vehicle-to-Grid Communication Interface - Part
2: Network and application protocol requirements",
ISO 15118-2:2014, April 2014,
<https://www.iso.org/standard/55366.html>.
[NERC-CIP-005-5]
North American Electric Reliability Council, "Cyber
Security - Electronic Security Perimeter", CIP 005-5,
December 2013.
[OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1
(Draft)", December 2019.
[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>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
May 2013, <https://www.rfc-editor.org/info/rfc6955>.
[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>.
[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>.
[RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol",
RFC 8894, DOI 10.17487/RFC8894, September 2020,
<https://www.rfc-editor.org/info/rfc8894>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/info/rfc9148>.
[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>.
[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>.
[UNISIG-Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, Version 1.0.0, December 2015,
<https://www.era.europa.eu/system/files/2023-01/
sos3_index083_-_subset-137_v100.pdf>.
This informative annex provides some details about application examples.
この有益な付録は、アプリケーションの例に関するいくつかの詳細を提供します。
Rolling stock or railroad cars contain a variety of sensors, actuators, and controllers. These communicate within the railroad car but also exchange information with other railroad cars of the same train and with track-side equipment and/or possibly with backend systems. These devices are typically unaware of backend system connectivity. Enrolling certificates may be done during maintenance cycles of the railroad car but can already be prepared during operation. Such asynchronous enrollment will include generating certification requests, which are collected and later forwarded for processing whenever the railroad car gets connectivity with the backend PKI of the operator. The authorization of the certification request is then done based on the operator's asset/inventory information in the backend.
ローリングストックまたは鉄道車両には、さまざまなセンサー、アクチュエーター、コントローラーが含まれています。これらは鉄道車両内で通信しますが、同じ列車の他の鉄道車両や、トラックサイドの機器、および/または場合によってはバックエンドシステムと情報を交換します。これらのデバイスは通常、バックエンドシステムの接続を認識していません。登録証明書は、鉄道車両のメンテナンスサイクル中に行うことができますが、操作中はすでに準備できます。同期登録などには、鉄道車両がオペレーターのバックエンドPKIと接続されるたびに収集され、その後処理のために転送される認定リクエストの生成が含まれます。認定要求の承認は、バックエンド内のオペレーターの資産/在庫情報に基づいて行われます。
UNISIG has included a CMP profile for the enrollment of TLS client and server X.509 certificates of on-board and track-side components in the Subset-137, which specifies the ETRAM/ETCS online key management for train control systems [UNISIG-Subset-137].
UNISIGには、TLSクライアントとサーバーX.509の登録用のCMPプロファイルが含まれており、サブセット-137のオンボードおよびトラックサイドコンポーネントの証明書が含まれています。
In building automation scenarios, a detached building or the basement of a building may be equipped with sensors, actuators, and controllers that are connected to each other in a local network but with only limited or no connectivity to a central building management system. This problem may occur during installation time but also during operation. In such a situation, a service technician collects the necessary data and transfers it between the local network and the central building management system, e.g., using a laptop or a mobile phone. This data may comprise parameters and settings required in the operational phase of the sensors/actuators, like a component certificate issued by the operator to authenticate against other components and services.
建物の自動化シナリオでは、地元のネットワークで互いに接続されているが、中央の建物管理システムへの接続が制限されていない、または接続されていないセンサー、アクチュエーター、およびコントローラーを装備することができます。この問題は、設置時間だけでなく、操作中にも発生する可能性があります。このような状況では、サービス技術者が必要なデータを収集し、ラップトップや携帯電話を使用して、ローカルネットワークと中央建築管理システムの間に転送します。このデータは、他のコンポーネントやサービスに対して認証するためにオペレーターが発行したコンポーネント証明書など、センサー/アクチュエーターの運用フェーズで必要なパラメーターと設定を含む場合があります。
The collected data may be provided by a domain registrar already existing in the local network. In this case, connectivity to the backend PKI may be facilitated by the service technician's laptop. Alternatively, the data can also be collected from the pledges directly and provided to a domain registrar deployed in a different network in preparation for the operational phase. In this case, connectivity to the domain registrar may also be facilitated by the service technician's laptop.
収集されたデータは、ローカルネットワークに既に存在するドメインレジストラによって提供される場合があります。この場合、バックエンドPKIへの接続は、サービス技術者のラップトップによって促進される場合があります。または、データは誓約から直接収集し、運用フェーズに備えて別のネットワークに展開されたドメインレジストラに提供することもできます。この場合、ドメインレジストラへの接続は、サービス技術者のラップトップによって促進される場合があります。
In electrical substation automation scenarios, a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices (IEDs) operated in a substation. Communication between the substation and control center is performed through a proxy/gateway/DMZ, which terminates protocol flows. Note that [NERC-CIP-005-5] requires inspection of protocols at the boundary of a security perimeter (in this case, the substation). In addition, security management in substation automation assumes central support of several enrollment protocols to support the various capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies mandatory support of two enrollment protocols for the infrastructure side, SCEP [RFC8894] and EST [RFC7030], while an IED may support only one of them.
電気変電所の自動化シナリオでは、コントロールセンターは通常、PKIサービスをホストして、変電所で動作するインテリジェント電子デバイス（IED）の証明書を発行します。変電所とコントロールセンター間の通信は、プロキシ/ゲートウェイ/DMZを介して実行され、プロトコルフローを終了します。[NERC-CIP-005-5]では、セキュリティ周辺（この場合は変電所）の境界でプロトコルの検査が必要であることに注意してください。さらに、変電所自動化のセキュリティ管理は、さまざまなベンダーからのIEDのさまざまな機能をサポートするために、いくつかの登録プロトコルの中心的なサポートを想定しています。IEC標準IEC62351-9 [IEC-62351-9]は、インフラストラクチャ側の2つの登録プロトコルの必須サポート、SCEP [RFC8894]およびEST [RFC7030]を指定しますが、IEDはその1つだけをサポートする場合があります。
For electric vehicle charging infrastructure, protocols have been defined for the interaction between the electric vehicle and the charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as between the charging point and the charging point operator (e.g., OCPP [OCPP]). Depending on the authentication model, unilateral or mutual authentication is required. In both cases, the charging point uses an X.509 certificate to authenticate itself in TLS channels between the electric vehicle and the charging point. The management of this certificate depends, among other things, on the selected backend connectivity protocol. In the case of OCPP, this protocol is meant to be the only communication protocol between the charging point and the backend, carrying all information to control the charging operations and maintain the charging point itself. This means that the certificate management needs to be handled in-band of OCPP. This requires the ability to encapsulate the certificate management messages in a transport-independent way. Authenticated self-containment will support this by allowing the transport without a separate enrollment protocol, binding the messages to the identity of the communicating endpoints.
電気自動車充電インフラストラクチャの場合、電気自動車と充電ポイント（例：ISO 15118-2 [ISO-IEC-15118-2]）と充電ポイントと充電ポイント演算子の間の相互作用のためにプロトコルが定義されています（例：OCPP [OCPP]）。認証モデルに応じて、一方的または相互認証が必要です。どちらの場合も、充電ポイントはX.509証明書を使用して、電気自動車と充電ポイント間のTLSチャネルで認証します。この証明書の管理は、とりわけ選択されたバックエンド接続プロトコルに依存します。OCPPの場合、このプロトコルは、充電ポイントとバックエンドの間の唯一の通信プロトコルであることを意図しており、充電操作を制御し、充電ポイント自体を維持するためにすべての情報を運びます。これは、証明書管理をOCPPのバンド内で処理する必要があることを意味します。これには、トランスポートに依存しない方法で証明書管理メッセージをカプセル化する機能が必要です。認証された自己受胎は、別の登録プロトコルなしでトランスポートを許可し、通信エンドポイントのIDにメッセージを結合することにより、これをサポートします。
The approach described in this section refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI services will be allowed in carefully controlled short periods of time (for example, when a batch of new devices is deployed) and forbidden or prevented at other times.
このセクションで説明するアプローチは、セキュリティ上の理由で、ポリシーの問題として、ネットワークインフラストラクチャが通常インターネットから分離されている場合を参照しています。そのような場合、外部PKIサービスへの制限されたアクセスは、慎重に制御された短期間（たとえば、新しいデバイスのバッチが展開される場合）で許可され、他の時間で禁止または防止されます。
The RA performing (at least part of) the authorization of a certification request is a critical PKI component and therefore requires higher operational security than components utilizing the issued certificates for their security features. CAs may also demand higher security in the registration procedures from RAs, which domain registrars with co-located RAs may not be able to fulfill. In particular, the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates, i.e., those placed in trust stores of browsers, which may be used to connect with devices in the domain. In case the on-site components of the target domain cannot be operated securely enough for the needs of an RA, this service should be transferred to an off-site backend component that has a sufficient level of security.
RAを実行するRA（少なくとも一部）認証リクエストの承認は重要なPKIコンポーネントであるため、セキュリティ機能に発行された証明書を利用するコンポーネントよりも高い運用セキュリティが必要です。CASは、RASからの登録手続きのより高いセキュリティを要求する場合があります。RASは、共同配置されたRAを持つドメインレジストラが満たすことができない可能性があります。特に、CA/ブラウザフォーラムは現在、公的に信頼された証明書、つまりドメイン内のデバイスに接続するために使用できるブラウザーの信頼ストアに配置された証明書の証明書発行手順のセキュリティ要件を増やしています。ターゲットドメインのオンサイトコンポーネントをRAのニーズに合わせて十分に操作できない場合は、このサービスを十分なレベルのセキュリティを持つオフサイトバックエンドコンポーネントに転送する必要があります。
We thank Eliot Lear for his contributions as a co-author at an earlier draft stage.
Eliot Learは、以前のドラフト段階で共著者としての貢献に感謝します。
We thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows.
ブライアン・E・カーペンター、マイケル・リチャードソン、ジョルジオ・ロマネンギに、ユースケースとコールフローに関する意見と議論をしてくれたことに感謝します。
Moreover, we thank Toerless Eckert (document shepherd); Barry Leiba (SECdir review); Mahesh Jethanandani (IETF area director); Meral Shirazipour (Gen-ART reviewer); Reshad Rahman (YANGDOCTORS reviewer); Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, and Éric Vyncke (IESG reviewers); Michael Richardson (ANIMA design team member); and Rajeev Ranjan, Rufus Buschart, Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for their reviews with suggestions for improvements.
さらに、Toerless Eckert（Document Shepherd）に感謝します。Barry Leiba（Secdir Review）;Mahesh Jethanandani（IETFエリアディレクター）;Meral Shirazipour（Gen-Art Reviewer）;Reshad Rahman（Yangdoctors Reviewer）;Deb Cooley、Gunter Van de Velde、John Scudder、Murray Kucherawy、Roman Danyliw、およびEric Vyncke（IESGレビュアー）;マイケルリチャードソン（アニマデザインチームメンバー）;Rajeev Ranjan、Rufus Buschart、Andreas Reiter、Szofia Fazekas-Zisch（Siemensの同僚）は、改善の提案を受けてレビューをしています。
Eliot Lear
Cisco Systems
Richtistrasse 7
CH-8304 Wallisellen
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
David von Oheimb (editor)
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com/
Steffen Fries
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: steffen.fries@siemens.com
URI: https://www.siemens.com/
Hendrik Brockhaus
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com/