Internet Engineering Task Force (IETF) B. Sipos
Request for Comments: 9891 RKF Engineering
Category: Experimental November 2025
ISSN: 2070-1721
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node. The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID and as an ACME Identifier type "bundleEID".
この文書は、ACME サーバーが ACME クライアントの遅延耐性ネットワーク (DTN) ノード ID を検証できるようにする自動証明書管理環境 (ACME) プロトコルの拡張機能を指定します。DTN ノード ID は、バンドル プロトコル (BP) で「シングルトン エンドポイント」、つまり単一の BP ノードに登録されているエンドポイントに名前を付けるために使用される識別子です。DTN ノード ID は、BundleEID の Other Name 形式を持つ otherName タイプの証明書サブジェクト代替名 (SAN) ID として、および ACME 識別子タイプ「bundleEID」としてエンコードされます。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書は Internet Standards Track 仕様ではありません。試験、実験実装、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネット コミュニティ向けの実験プロトコルを定義します。このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。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/rfc9891.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9891 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Scope
1.2. Authorization Strategy
1.3. Use of CDDL
1.4. Terminology
1.5. Experiment Scope
2. Bundle EID ACME Identifier
2.1. Subsets of Bundle EID
3. DTN Node ID Validation
3.1. DTN Node ID Challenge Object
3.2. DTN Node ID Response Object
3.3. ACME Node ID Validation Challenge Bundle
3.3.1. Challenge Bundle Checks
3.4. ACME Node ID Validation Response Bundles
3.4.1. Response Bundle Checks
3.5. Multi-Perspective Validation
4. Bundle Integrity Gateway
5. Certificate Request Profile
5.1. Multiple Identity Claims
5.2. Generating Encryption-Only or Signing-Only Bundle Security
Certificates
6. Security Considerations
6.1. Threat: Passive Leak of Validation Data
6.2. Threat: BP Node Impersonation
6.3. Threat: Bundle Replay
6.4. Threat: Denial of Service
6.5. Inherited Security Considerations
6.6. Out-of-Scope BP Agent Communication
7. IANA Considerations
7.1. ACME Identifier Types
7.2. ACME Validation Methods
7.3. Bundle Administrative Record Types
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Administrative Record Types CDDL
Appendix B. Example Authorization
B.1. Challenge Bundle
B.2. Response Bundle
Acknowledgements
Author's Address
Although the original purpose of the Automatic Certificate Management Environment (ACME) [RFC8555] was to allow Public Key Infrastructure using X.509 (PKIX) Certification Authorities (CAs) to validate network domain names of clients, the same mechanism can be used to validate any of the subject identity claims supported by the PKIX profile [RFC5280].
自動証明書管理環境 (ACME) [RFC8555] の本来の目的は、X.509 (PKIX) 認証局 (CA) を使用して公開鍵インフラストラクチャがクライアントのネットワーク ドメイン名を検証できるようにすることでしたが、同じメカニズムを使用して、PKIX プロファイル [RFC5280] でサポートされているサブジェクト ID 要求の検証にも使用できます。
In this specification, the claim being validated is a Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID, which is used to represent a Bundle Protocol (BP) Endpoint ID (EID) in a Delay-Tolerant Networking (DTN) overlay network. A DTN Node ID is any EID that can uniquely identify a BP Node, as defined in Section 4.2.5.2 of [RFC9171], which is equivalent to the EID being usable as a singleton endpoint. One common EID used as a Node ID is the Administrative EID, which is guaranteed to exist on any BP Node. At the time of writing, the URI schemes "dtn" and "ipn" as defined in Section 4.2.5.1 of [RFC9171] are valid for a singleton endpoint and, thus, a Node ID. Because the BundleEID claim is new to ACME, a new ACME Identifier type "bundleEID" is needed to manage this claim within ACME messaging.
この仕様では、検証されるクレームは、BundleEID の Other Name 形式を持つ otherName タイプのサブジェクト代替名 (SAN) ID です。これは、遅延耐性ネットワーキング (DTN) オーバーレイ ネットワーク内のバンドル プロトコル (BP) エンドポイント ID (EID) を表すために使用されます。DTN ノード ID は、[RFC9171] のセクション 4.2.5.2 で定義されているように、BP ノードを一意に識別できる任意の EID であり、シングルトン エンドポイントとして使用できる EID と同等です。ノード ID として使用される一般的な EID の 1 つは管理 EID であり、これはどの BP ノードにも存在することが保証されています。執筆時点では、[RFC9171] のセクション 4.2.5.1 で定義されている URI スキーム "dtn" および "ipn" は、シングルトン エンドポイント、つまりノード ID に対して有効です。BundleEID クレームは ACME にとって新しいものであるため、ACME メッセージング内でこのクレームを管理するには、新しい ACME 識別子の種類「bundleEID」が必要です。
Once an ACME server validates a Node ID, either as a pre-authorization of an identifier type "bundleEID" or as one of the authorizations of an order containing an identifier type "bundleEID", the client can finalize the order using an associated Certificate Signing Request (CSR). Because a single order can contain multiple identifiers of multiple types, there can be operational issues for a client attempting to, and possibly failing to, validate those multiple identifiers as described in Section 5.1. Once a certificate is issued for a Node ID, how the ACME client configures the BP Agent with the new certificate is an implementation matter.
ACME サーバーが識別子タイプ「bundleEID」の事前承認または識別子タイプ「bundleEID」を含む注文の承認の 1 つとしてノード ID を検証すると、クライアントは関連する証明書署名要求 (CSR) を使用して注文を完了できます。単一の注文には複数のタイプの複数の識別子が含まれる可能性があるため、セクション 5.1 で説明されているように、クライアントがそれらの複数の識別子を検証しようとしたり失敗したりすると、運用上の問題が発生する可能性があります。ノード ID に対して証明書が発行されると、ACME クライアントが新しい証明書を使用して BP エージェントをどのように構成するかは実装の問題になります。
This document describes the ACME message contents [RFC8555], Bundle Protocol version 7 (BPv7) payloads [RFC9171], and Bundle Protocol Security (BPSec) operations [RFC9172] needed to validate claims of Node ID ownership.
この文書は、ノード ID の所有権の主張を検証するために必要な ACME メッセージの内容 [RFC8555]、バンドル プロトコル バージョン 7 (BPv7) ペイロード [RFC9171]、およびバンドル プロトコル セキュリティ (BPSec) 操作 [RFC9172] について説明します。
This document does not address:
この文書では次のことについては扱いません。
* Mechanisms for communication between an ACME client or ACME server and their associated BP Agent(s), depicted as steps 1, 2, 5, and 6 of Figure 1. This document only describes exchanges between ACME client-server pairs and between their respective associated BP Agents.
* ACME クライアントまたは ACME サーバーとそれらに関連付けられた BP エージェント間の通信メカニズム。図 1 のステップ 1、2、5、および 6 として示されています。このドキュメントでは、ACME クライアントとサーバーのペア間およびそれぞれに関連付けられた BP エージェント間の交換についてのみ説明します。
* Specific BP extension blocks or BPSec contexts necessary to fulfill the security requirements of this protocol. The exact security context needed, and its parameters, is network specific.
* このプロトコルのセキュリティ要件を満たすために必要な特定の BP 拡張ブロックまたは BPSec コンテキスト。必要な正確なセキュリティ コンテキストとそのパラメータはネットワーク固有です。
* Policies or mechanisms for defining or configuring Bundle integrity gateways, or trusting integrity gateways on an individual entity or across a network.
* バンドル整合性ゲートウェイを定義または構成するためのポリシーまたはメカニズム、または個々のエンティティ上またはネットワーク全体で整合性ゲートウェイを信頼するためのポリシーまたはメカニズム。
* Mechanisms for locating or identifying other Bundle entities (peers) within a network or across an internet. The mapping of a Node ID to a potential Convergence-Layer (CL) protocol and network address is left to implementation and configuration of the BP Agent and its various potential routing strategies.
* ネットワーク内またはインターネット上で他のバンドル エンティティ (ピア) を検索または識別するためのメカニズム。潜在的なコンバージェンス層 (CL) プロトコルおよびネットワーク アドレスへのノード ID のマッピングは、BP エージェントとそのさまざまな潜在的なルーティング戦略の実装と構成に委ねられます。
* Logic for routing Bundles along a path toward a Bundle's endpoint. This protocol is involved only in creating Bundles at a source and handling them at a destination.
* バンドルのエンドポイントに向かうパスに沿ってバンドルをルーティングするためのロジック。このプロトコルは、ソースでのバンドルの作成と宛先でのそれらのバンドルの処理にのみ関与します。
* Logic for performing rate control and congestion control of Bundle transfers. The ACME server is responsible for rate control of validation requests.
* バンドル転送のレート制御と輻輳制御を実行するロジック。ACME サーバーは、検証リクエストのレート制御を担当します。
* Policies or mechanisms for an ACME server to choose a prioritized list of acceptable hash algorithms or for an ACME client to choose a set of acceptable hash algorithms.
* ACME サーバーが許容可能なハッシュ アルゴリズムの優先順位付きリストを選択するため、または ACME クライアントが許容可能なハッシュ アルゴリズムのセットを選択するためのポリシーまたはメカニズム。
* Policies or mechanisms for provisioning, deploying, or accessing certificates and private keys; deploying or accessing Certificate Revocation Lists (CRLs); or configuring security parameters on an individual entity or across a network.
* 証明書と秘密キーのプロビジョニング、展開、またはアクセスのためのポリシーまたはメカニズム。証明書失効リスト (CRL) の展開またはアクセス。または、個々のエンティティ上またはネットワーク全体でセキュリティ パラメータを構成します。
* Policies or mechanisms for an ACME server to handle mixed-use certificate signing requests. This specification is focused only on single-use DTN-specific PKIX profiles.
* ACME サーバーが混合使用の証明書署名要求を処理するためのポリシーまたはメカニズム。この仕様は、使い捨て DTN 固有の PKIX プロファイルのみに焦点を当てています。
The basic unit of data exchange in a DTN is a Bundle [RFC9171], which consists of a data payload with accompanying metadata. An EID is used as the destination of a Bundle and can indicate either a singleton or a group destination. A Node ID is used to identify the source of a Bundle and is used for routing through intermediate nodes, including the final node(s) used to deliver a Bundle to its destination endpoint. A Node ID can also be used as an endpoint for Bundles conveying administrative records as explained in Section 6 of [RFC9171]. More detailed descriptions of the rationale and capabilities of these networks can be found in the "Delay-Tolerant Networking Architecture" [RFC4838].
DTN におけるデータ交換の基本単位はバンドル [RFC9171] であり、これは付随するメタデータを伴うデータ ペイロードで構成されます。EID はバンドルの宛先として使用され、シングルトンまたはグループの宛先を示すことができます。ノード ID はバンドルのソースを識別するために使用され、バンドルを宛先エンドポイントに配信するために使用される最終ノードを含む中間ノードを介したルーティングに使用されます。ノード ID は、[RFC9171] のセクション 6 で説明されているように、管理記録を伝達するバンドルのエンドポイントとしても使用できます。これらのネットワークの理論的根拠と機能の詳細については、「遅延耐性ネットワーキング アーキテクチャ」[RFC4838] を参照してください。
When an ACME client requests a pre-authorization or an order with an identifier type "bundleEID" (Section 2), the ACME server offers a "bp-nodeid-00" challenge type (Section 3) to validate that Node ID. If the ACME client attempts the authorization challenge to validate a Node ID, the ACME server sends an ACME Node ID Validation Challenge Bundle with a destination of the Node ID being validated. The BP Agent on that node receives the Challenge Bundle, generates an ACME Key Authorization digest, and sends an ACME Node ID Validation Response Bundle in reply. An Integrity Gateway on the client side of the DTN can be used to attest to the source of the Response Bundle. Finally, the ACME server receives the Response Bundle and checks that the digest was generated for the associated ACME challenge and from the client account key associated with the original request. This workflow is shown in Figure 1.
ACME クライアントが識別子タイプ「bundleEID」(セクション 2) で事前承認または注文をリクエストすると、ACME サーバーはそのノード ID を検証するために「bp-nodeid-00」チャレンジ タイプ (セクション 3) を提供します。ACME クライアントがノード ID を検証するために認証チャレンジを試行すると、ACME サーバーは検証中のノード ID を宛先として ACME ノード ID 検証チャレンジ バンドルを送信します。そのノード上の BP エージェントは、チャレンジ バンドルを受信し、ACME キー認証ダイジェストを生成し、応答として ACME ノード ID 検証応答バンドルを送信します。DTN のクライアント側の Integrity Gateway を使用して、応答バンドルのソースを証明できます。最後に、ACME サーバーは応答バンドルを受信し、関連付けられた ACME チャレンジに対して、元のリクエストに関連付けられたクライアント アカウント キーからダイジェストが生成されたことを確認します。このワークフローを図 1 に示します。
+------------+ +------------+
| ACME |<===== HTTPS Exchanges =====>| ACME |
| Client | | Server |
+------------+ +------------+
| | ^
(1) Enable or (6) Disable (2) Send | |
Validation from Server Challenge | |(5) Indicate
| Non-DTN | | Response
~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~
V DTN V |
++------------++ ++------------++
|| Admin Elem.|| || Admin Elem.||-+
|+------------+| (3) Challenge |+------------+| |
| Client's |<------------- Bundle -----| Server's | |
| BP Agent | | BP Agent | |
+--------------+ +--------------+ |
| +----^---------+
| +-------------+ |
| | Integrity | (4) Response |
+---->| Gateway |------ Bundle --------+
+-------------+
Figure 1: The Relationships and Flows Between Node ID Validation Entities
図 1: ノード ID 検証エンティティ間の関係とフロー
Because the DTN Node ID is used both for routing Bundles between BP Agents and for multiplexing administrative services within a BP Agent, there is no possibility to separate the ACME validation of a Node ID from normal Bundle handling for that same Node ID. This leaves administrative record types as a way to keep the Node ID unchanged while disambiguating from other service data Bundles.
DTN ノード ID は、BP エージェント間のバンドルのルーティングと、BP エージェント内の管理サービスの多重化の両方に使用されるため、ノード ID の ACME 検証を、同じノード ID に対する通常のバンドル処理から分離することはできません。これにより、他のサービス データ バンドルとのあいまいさを解消しながら、ノード ID を変更しないままにする方法として、管理レコード タイプが残されます。
There is nothing in this protocol that requires network-topological co-location of either the ACME client or ACME server with their respective associated BP Agent. While ACME requires a low-enough latency network to perform HTTPS exchanges between the ACME client and server, the client's BP Agent (the one being validated) could be on the far side of a long-delay or multi-hop BP network. The means by which the ACME client or server communicates with its associated BP Agent is an implementation matter.
このプロトコルには、ACME クライアントまたは ACME サーバーと、それぞれに関連付けられている BP エージェントとのネットワーク トポロジ上のコロケーションを必要とするものは何もありません。ACME では、ACME クライアントとサーバー間で HTTPS 交換を実行するために十分な遅延の低いネットワークが必要ですが、クライアントの BP エージェント (検証対象のエージェント) は遅延の長い BP ネットワークまたはマルチホップ BP ネットワークの向こう側にある可能性があります。ACME クライアントまたはサーバーが関連する BP エージェントと通信する手段は実装の問題です。
This document defines Concise Binary Object Representation (CBOR) structure using the Concise Data Definition Language (CDDL) [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:
この文書は、簡潔なデータ定義言語 (CDDL) [RFC8610] を使用して、簡潔なバイナリ オブジェクト表現 (CBOR) 構造を定義します。CDDL 構造全体は、XPath 式を使用してこのドキュメントの XML バージョンから抽出できます。
'//sourcecode[@type="cddl"]'
The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content.
次の最初のフラグメントは、CBOR コンテンツの例を含む、このドキュメントの CDDL のトップレベルのシンボルを定義します。
start = acme-record / bundle / tstr
The definitions for the rule bundle and socket $admin-record are taken from Appendix B of [RFC9171].
ルールバンドルとソケット $admin-record の定義は、[RFC9171] の付録 B から取得されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Because this document combines two otherwise unrelated contexts, ACME and DTN, when a protocol term applies to one of those areas and is used in the other its name is prefixed with either "ACME" or "DTN" respectively. Thus, within the ACME context the term is "DTN Node ID" while in the DTN context the name is just "Node ID".
この文書は、ACME と DTN という、無関係な 2 つのコンテキストを組み合わせているため、プロトコル用語がそれらの領域の一方に適用され、もう一方の領域で使用される場合、その名前にはそれぞれ「ACME」または「DTN」という接頭辞が付けられます。したがって、ACME コンテキスト内ではこの用語は「DTN ノード ID」ですが、DTN コンテキストでは名前は単に「ノード ID」です。
In this document, several terms are shortened for the sake of brevity. These terms are as follows:
このドキュメントでは、簡潔にするためにいくつかの用語が短縮されています。これらの用語は次のとおりです。
Challenge Object:
チャレンジオブジェクト:
This is a shortened form of the full "DTN Node ID Challenge Object". It is a JSON object created by the ACME server for challenge type "bp-nodeid-00" as defined in Section 3.1.
これは、完全な「DTN ノード ID チャレンジ オブジェクト」の短縮形です。これは、セクション 3.1 で定義されているチャレンジ タイプ「bp-nodeid-00」に対して ACME サーバーによって作成された JSON オブジェクトです。
Response Object:
応答オブジェクト:
This is a shortened form of the full "DTN Node ID Response Object". It is a JSON object created by the ACME client to authorize a challenge type "bp-nodeid-00" as defined in Section 3.2.
これは、完全な「DTN ノード ID 応答オブジェクト」の短縮形です。これは、セクション 3.2 で定義されているチャレンジ タイプ「bp-nodeid-00」を承認するために ACME クライアントによって作成される JSON オブジェクトです。
Challenge Bundle:
チャレンジバンドル:
This is a shortened form of the full "ACME Node ID Validation Challenge Bundle". It is a Bundle created by the BP Agent managed by the ACME server to challenge a Node ID claim as defined in Section 3.3.
これは、完全な「ACME Node ID Validation Challenge Bundle」の短縮形です。これは、セクション 3.3 で定義されているノード ID 要求に異議を唱えるために、ACME サーバーによって管理される BP エージェントによって作成されるバンドルです。
Response Bundle:
応答バンドル:
This is a shortened form of the full "ACME Node ID Validation Response Bundle". It is a Bundle created by the BP Agent managed by the ACME client to validate a Node ID claim as defined in Section 3.4.
これは、完全な「ACME Node ID Validation Response Bundle」の短縮形です。これは、セクション 3.4 で定義されているノード ID クレームを検証するために、ACME クライアントによって管理される BP エージェントによって作成されるバンドルです。
Because this is a document produced by the ACME WG, the following DTN BP terms are defined here to clarify how they are used by this ACME identifier type and validation mechanism.
これは ACME WG によって作成された文書であるため、次の DTN BP 用語がこの ACME 識別子のタイプと検証メカニズムでどのように使用されるかを明確にするためにここで定義されています。
Endpoint ID:
エンドポイントID:
An EID is an identifier for the ultimate destination of a Bundle, independent of any intermediate forwarding needed to reach that destination. An endpoint can be a singleton or not, so an EID can also represent a single entity or a set of entities. This is formally defined in Section 4.2.5.1 of [RFC9171].
EID は、バンドルの最終的な宛先の識別子であり、その宛先に到達するために必要な中間転送とは独立しています。エンドポイントはシングルトンであってもなくてもよいため、EID は単一のエンティティまたはエンティティのセットを表すこともできます。これは、[RFC9171] のセクション 4.2.5.1 で正式に定義されています。
Node ID:
ノードID:
A Node ID is an identifier (that is not guaranteed to be unique) for a specific node in a network in the form of a singleton EID. A single node can have any number of Node IDs, but a typical (and expected) form of Node ID is the Administrative EID (described below). This is formally defined in Section 4.2.5.2 of [RFC9171].
ノード ID は、シングルトン EID の形式で表される、ネットワーク内の特定のノードの識別子 (一意であることが保証されていない) です。単一ノードは任意の数のノード ID を持つことができますが、ノード ID の典型的な (そして予期される) 形式は管理 EID (後述) です。これは、[RFC9171] のセクション 4.2.5.2 で正式に定義されています。
Administrative EID:
管理 EID:
An Administrative EID is unique for a node within a specific URI scheme. Although any Node ID can be a valid Bundle Source and Destination, the Administrative EID is a minimum required Node ID for any node operating in a particular URI scheme. For the "dtn" scheme, this is the empty demux part; for the "ipn" scheme, this is the service number zero. These are formally defined under Section 4.2.5.1 of [RFC9171].
管理 EID は、特定の URI スキーム内のノードに対して一意です。どのノード ID も有効なバンドル ソースおよびバンドル宛先として使用できますが、管理 EID は、特定の URI スキームで動作するノードに最低限必要なノード ID です。「dtn」スキームの場合、これは空の demux 部分です。「ipn」スキームの場合、これはサービス番号 0 です。これらは、[RFC9171] のセクション 4.2.5.1 で正式に定義されています。
The emergent properties of DTN naming and BP security are still being developed and explored, especially between different organizational and administrative domains. Thus, the Experimental status of this document is related more to the practical utility of this kind of Node ID validation than to the validation method itself. The original use case is in large or cross-organizational networks where a BP Node can be trusted to be allocated and added to a network, but the method of certificate validation and issuance is desired to be in-band on the network rather than configured solely through a side channel using bespoke or manual protocols. Because this mechanism is so similar to other validation methods, specifically email address validation [RFC8823], it is expected to have few implementation difficulties or interoperability issues.
DTN 命名と BP セキュリティの新たな特性は、特に異なる組織ドメインと管理ドメイン間で依然として開発および調査されています。したがって、この文書の実験ステータスは、検証方法自体よりも、この種のノード ID 検証の実際の有用性に関連しています。本来の使用例は、BP ノードの割り当てとネットワークへの追加を信頼できる大規模なネットワークまたは組織間のネットワークで行われますが、証明書の検証と発行の方法は、特注または手動のプロトコルを使用してサイド チャネルのみで構成するのではなく、ネットワーク上の帯域内で行うことが望まれます。このメカニズムは他の検証方法、特に電子メール アドレス検証 [RFC8823] と非常に似ているため、実装上の困難や相互運用性の問題はほとんどないと予想されます。
Part of the experimental nature of the validation method defined in Section 3, and BP more generally, is understanding its vulnerability to different kinds of on-path attacks. Some attacks could be based on the topology of the BP overlay network, while others could be based on the underlying (IP) network topology. Because not all of the attack surfaces of this validation method are known or fully understood, the usefulness of the multi-perspective technique described in Section 3.5 is also not assured. The point of those multi-perspective requirements is that both the ACME client and server have consistent logic for handling the technique.
セクション 3 で定義された検証方法、より一般的には BP の実験的性質の一部は、さまざまな種類のオンパス攻撃に対するその脆弱性を理解することです。一部の攻撃は BP オーバーレイ ネットワークのトポロジに基づいている可能性がありますが、他の攻撃は基盤となる (IP) ネットワーク トポロジに基づいている可能性があります。この検証方法の攻撃対象領域のすべてが知られているか完全に理解されているわけではないため、セクション 3.5 で説明されているマルチパースペクティブ手法の有用性も保証されていません。これらのマルチパースペクティブ要件のポイントは、ACME クライアントとサーバーの両方がこの手法を処理するための一貫したロジックを備えていることです。
The usefulness of the integrity gateway defined in Section 4 to this validation method is experimental: the way that naming authority in a DTN is either allocated, delegated, or enforced is not a settled matter. How the organization running the CA (and its ACME server) can delegate some level of trust to a different organization running a connected DTN with a security gateway is also not defined. The organization running the integrity gateway would need to apply some minimal amount of policy to nodes running behind it, such as patterns to their Node IDs, which would behave conceptually similar to delegation of subdomains in the Domain Name System (DNS), but without the online interaction of DNS.
この検証方法に対するセクション 4 で定義された整合性ゲートウェイの有用性は実験的なものであり、DTN 内の命名権限が割り当て、委任、強制される方法はまだ決まっていません。CA (およびその ACME サーバー) を実行している組織が、セキュリティ ゲートウェイを使用して接続された DTN を実行している別の組織に一定レベルの信頼を委任する方法も定義されていません。整合性ゲートウェイを実行している組織は、その背後で実行されているノードに、ノード ID のパターンなど、最小限のポリシーを適用する必要があります。これは概念的にはドメイン ネーム システム (DNS) のサブドメインの委任と同様に動作しますが、DNS のオンライン対話は必要ありません。
A successful experiment of this validation method would involve using the ACME protocol along with this Node ID validation to allow issuing of identity certificates across administrative domains. One possible scenario for this would be an issuing CA and an ACME server on the edge of a BP transit network operated by some agency. This transit network is used by edge nodes and accessed via edge routers of a peer network operated by a second agency. The nodes of the peer network are trusted by the second agency but not the first. The transit network can refuse to route traffic from the peer network that is not traceable to a valid identity certificate, which the edge nodes can obtain via the ACME server.
この検証方法の実験が成功するには、このノード ID 検証とともに ACME プロトコルを使用して、管理ドメイン全体で ID 証明書を発行できるようにする必要があります。この場合に考えられるシナリオの 1 つは、発行 CA と、何らかの機関が運営する BP 中継ネットワークのエッジにある ACME サーバーです。この中継ネットワークはエッジ ノードによって使用され、第 2 機関が運営するピア ネットワークのエッジ ルーター経由でアクセスされます。ピア ネットワークのノードは、2 番目の機関によって信頼されていますが、最初の機関では信頼されません。トランジット ネットワークは、エッジ ノードが ACME サーバー経由で取得できる有効な ID 証明書まで追跡できないピア ネットワークからのトラフィックのルーティングを拒否できます。
A valuable result from any experiment, even an unsuccessful one, would be feedback about this method to improve later versions. That feedback could include improvements to object or message structure, random versus deterministic token values, client or server procedures, or naming more generally.
失敗した実験であっても、実験から得られる貴重な結果は、後のバージョンを改善するためのこの方法に関するフィードバックとなります。そのフィードバックには、オブジェクトまたはメッセージの構造、ランダムなトークン値と決定的なトークン値、クライアントまたはサーバーのプロシージャ、またはより一般的な名前付けの改善が含まれる可能性があります。
This specification is the first to make use of a Bundle EID to identify a claim for a certificate request in ACME. In this document, the only purpose for which a Bundle EID ACME identifier is validated is as a DTN Node ID (see Section 3), but other specifications can define challenge types for other EID uses.
この仕様は、ACME での証明書要求のクレームを識別するためにバンドル EID を利用する最初の仕様です。この文書では、バンドル EID ACME 識別子が DTN ノード ID として検証される唯一の目的 (セクション 3 を参照) ですが、他の仕様では、他の EID 用途のためのチャレンジ タイプを定義できます。
Every ACME identifier type "bundleEID" SHALL have a value containing a text URI consistent with the requirements of Section 4.2.5.1 of [RFC9171] using one of the schemes available from the "Bundle Protocol URI Scheme Types" registry [IANA-BP]. Any identifier type "bundleEID" value that fails to properly percent-decode SHALL be rejected with an ACME error type of "malformed".
すべての ACME 識別子タイプ「bundleEID」は、「バンドル プロトコル URI スキーム タイプ」レジストリ [IANA-BP] から利用可能なスキームの 1 つを使用して、[RFC9171] のセクション 4.2.5.1 の要件と一致するテキスト URI を含む値を持つものとします (SHALL)。正しくパーセントデコードできない識別子タイプ「bundleEID」値は、「不正な形式」の ACME エラー タイプで拒否されます(SHALL)。
An ACME server supporting identifier type "bundleEID" SHALL decode and normalize (based on scheme-specific syntax) all such received identifier values. Any identifier type "bundleEID" value for which the scheme-specific part does not match the scheme-specific syntax SHALL be rejected with an ACME error type of "malformed". Any identifier type "bundleEID" value that uses a scheme not handled by the ACME server SHALL be rejected with an ACME error type of "rejectedIdentifier".
識別子タイプ「bundleEID」をサポートする ACME サーバーは、受信したすべての識別子の値を (スキーム固有の構文に基づいて) デコードおよび正規化するものとします (SHALL)。スキーム固有の部分がスキーム固有の構文と一致しない識別子タイプ「bundleEID」値は、ACME エラー タイプ「不正な形式」で拒否されます(SHALL)。ACME サーバーによって処理されないスキームを使用する識別子タイプ「bundleEID」値は、ACME エラー タイプ「rejectedIdentifier」で拒否されます(SHALL)。
When an ACME server needs to request proof that a client controls a Bundle EID, it SHALL create an authorization with the identifier type "bundleEID". An ACME server SHALL NOT attempt to dereference a Bundle EID value on its own. It is the responsibility of an ACME validation method to ensure the EID ownership using a method authorized by the ACME client.
ACME サーバーがクライアントがバンドル EID を制御していることの証明を要求する必要がある場合、識別子タイプ「bundleEID」を持つ認可を作成するものとします (SHALL)。ACME サーバーは、それ自体でバンドル EID 値を参照解除しようとしてはなりません (SHALL NOT)。ACME クライアントによって許可された方法を使用して EID の所有権を確認するのは、ACME 検証方法の責任です。
An identifier for the Node ID of "dtn://example/" would be formatted as:
「dtn://example/」というノード ID の識別子は次のようにフォーマットされます。
{
"type": "bundleEID",
"value": "dtn://example/"
}
A PKIX certificate SAN identity containing an Other Name form of BundleEID can hold any EID value (as a text URI). But the certificate profile used by the TCP CL in Section 4.4 of [RFC9174] and supported by the ACME validation method in Section 3 requires that the value hold a Node ID (Section 1.4).
BundleEID の Other Name 形式を含む PKIX 証明書 SAN ID は、任意の EID 値を (テキスト URI として) 保持できます。しかし、[RFC9174] のセクション 4.4 で TCP CL によって使用され、セクション 3 の ACME 検証メソッドによってサポートされる証明書プロファイルでは、値がノード ID (セクション 1.4) を保持する必要があります。
In addition to the narrowing of that certificate profile, this validation method requires that the client's BP Agent respond to administrative records sent to the Node ID being validated. Typically, this is limited to an Administrative EID (Section 1.4) destination. However, the administrative element of a BP Node is not prohibited from receiving administrative records for, or sending records from, other Node IDs in order to support this validation method.
この検証方法では、証明書プロファイルの絞り込みに加えて、検証対象のノード ID に送信された管理レコードにクライアントの BP エージェントが応答する必要があります。通常、これは管理 EID (セクション 1.4) の宛先に限定されます。ただし、BP ノードの管理要素は、この検証方法をサポートするために、他のノード ID の管理レコードを受信したり、他のノード ID からレコードを送信したりすることを禁止されません。
Neither that certificate profile nor this validation method support operating on non-singleton EIDs, but other validation methods could be defined to do so in order to support other certificate profiles.
その証明書プロファイルもこの検証方法も非シングルトン EID での動作をサポートしていませんが、他の証明書プロファイルをサポートするために他の検証方法を定義することもできます。
The DTN Node ID validation method proves control over a Node ID by requiring the ACME client to configure a BP Agent to respond to specific Challenge Bundles sent from the ACME server. The ACME server validates control of the Node ID by verifying that received Response Bundles correspond with the BP Node and client account key being validated.
DTN ノード ID 検証方法は、ACME サーバーから送信された特定のチャレンジ バンドルに応答するように BP エージェントを構成することを ACME クライアントに要求することで、ノード ID の制御を証明します。ACME サーバーは、受信した応答バンドルが検証対象の BP ノードおよびクライアント アカウント キーに対応していることを確認することで、ノード ID の制御を検証します。
Similar to the ACME use case for email-address validation [RFC8823], this challenge splits the token into several parts, each part being transported by a different channel, and the Key Authorization result requires combining all parts of the token. A separate challenge identifier is used as a filter by BP Agents similar to the challenge "from" used by email validation in Section 3 of [RFC8823].
電子メール アドレス検証 [RFC8823] の ACME ユースケースと同様に、このチャレンジではトークンがいくつかの部分に分割され、各部分が異なるチャネルによって転送され、鍵認証の結果にはトークンのすべての部分を組み合わせる必要があります。別のチャレンジ識別子は、[RFC8823] のセクション 3 の電子メール検証で使用されるチャレンジ「from」と同様に、BP エージェントによってフィルターとして使用されます。
The token parts are as follows:
トークン部分は次のとおりです。
token-chal:
トークンチャル:
This token is unique to each ACME authorization. It is contained in the Challenge Object of Section 3.1. Each authorization can consist of multiple Challenge Bundles (e.g., taking different routes), but they all share the same token-chal value. This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization). This token does not appear on the BP channel; thus, any eavesdropper knowing the client's account key thumbprint (e.g., from some other validation method) is not able to impersonate the client.
このトークンは、各 ACME 認証に固有です。これはセクション 3.1 のチャレンジ オブジェクトに含まれています。各承認は複数のチャレンジ バンドルで構成されます (たとえば、異なるルートを取るなど) が、それらはすべて同じ token-chal 値を共有します。これにより、キー認可が特定の ACME チャレンジ (および親 ACME 認可) にバインドされることが保証されます。このトークンは BP チャネルには表示されません。したがって、クライアントのアカウント キーの拇印を知っている盗聴者は（たとえば、他の検証方法によって）クライアントになりすますことができません。
token-bundle:
トークンバンドル:
This token is unique to each Challenge Bundle sent by the ACME server. It is contained in the Challenge Bundle of Section 3.3 and Response Bundle of Section 3.4. This ensures that the Key Authorization is bound to the ability to receive the Challenge Bundle and not just having access to the ACME Challenge Object. This token is also accessible to DTN on-path eavesdroppers.
このトークンは、ACME サーバーによって送信される各チャレンジ バンドルに固有です。これはセクション 3.3 のチャレンジ バンドルとセクション 3.4 のレスポンス バンドルに含まれています。これにより、キー認証は、ACME チャレンジ オブジェクトへのアクセスだけでなく、チャレンジ バンドルを受信する機能にもバインドされます。このトークンは、DTN パス上の盗聴者もアクセスできます。
Because multiple Challenge Bundles can be sent to validate the same Node ID, the token-bundle in the response is needed to correlate with the expected Key Authorization digest.
同じノード ID を検証するために複数のチャレンジ バンドルを送信できるため、応答内のトークン バンドルを予期されるキー認証ダイジェストと相関させる必要があります。
The DTN Node ID Challenge Object SHALL only be allowed for an EID usable as a DTN Node ID, which is defined per-scheme in Section 4.2.5.1 of [RFC9171]. When an ACME server supports Node ID validation, the ACME server SHALL provide a Challenge Object in accordance with Section 3.1. Once this Challenge Object is defined, the ACME client may begin the validation.
DTN ノード ID チャレンジ オブジェクトは、[RFC9171] のセクション 4.2.5.1 でスキームごとに定義される DTN ノード ID として使用可能な EID に対してのみ許可されるものとします (SHALL)。ACME サーバーがノード ID 検証をサポートする場合、ACME サーバーはセクション 3.1 に従ってチャレンジ オブジェクトを提供するものとします(SHALL)。このチャレンジ オブジェクトが定義されると、ACME クライアントは検証を開始できます。
To initiate a Node ID validation, the ACME client performs the following steps:
ノード ID 検証を開始するには、ACME クライアントは次の手順を実行します。
1. The ACME client POSTs a newOrder or newAuthz request including the identifier type "bundleEID" for the desired Node ID. From either of these entry points, an authorization for the identifier type "bundleEID" is indicated by the ACME server. See Section 7.4 of [RFC8555] for more details.
1. ACME クライアントは、目的のノード ID の識別子タイプ「bundleEID」を含む newOrder または newAuthz リクエストを POST します。これらのエントリ ポイントのいずれかから、識別子タイプ「bundleEID」の承認が ACME サーバーによって示されます。詳細については、[RFC8555] のセクション 7.4 を参照してください。
2. The ACME client obtains the id-chal and token-chal from the Challenge Object (Section 3.1) contained in an authorization object associated with the order in accordance with Section 7.1.4 of [RFC8555].
2. ACME クライアントは、[RFC8555] のセクション 7.1.4 に従って、注文に関連付けられた認可オブジェクトに含まれるチャレンジ オブジェクト (セクション 3.1) から id-chal と token-chal を取得します。
3. The ACME client indicates to the administrative element of its BP Agent the id-chal that is authorized for use along with the associated token-chal and client account key thumbprint. The ACME client waits, if necessary, until the Agent is configured before proceeding to the next step.
3. ACME クライアントは、BP エージェントの管理要素に、関連付けられたトークン chal およびクライアント アカウント キーの拇印とともに使用が許可されている id chal を示します。ACME クライアントは、必要に応じて、エージェントが設定されるまで待機してから、次のステップに進みます。
4. The ACME client POSTs a Response Object (Section 3.2) to the challenge URL on the ACME server in accordance with Section 7.5.1 of [RFC8555]. The payload object is constructed in accordance with Section 3.2.
4. ACME クライアントは、[RFC8555] のセクション 7.5.1 に従って、応答オブジェクト (セクション 3.2) を ACME サーバー上のチャレンジ URL に POST します。ペイロード オブジェクトはセクション 3.2 に従って構築されます。
5. The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its id-chal payload, in accordance with Section 3.3.
5. 管理要素は、セクション 3.3 に従って、その id-chal ペイロードを含む、承認された ACME パラメータとともにチャレンジ バンドルが受信されるのを待ちます。
6. The administrative element concatenates token-bundle with token-chal (each as base64url-encoded text strings) and computes the Key Authorization in accordance with Section 8.1 of [RFC8555] using the full token and client account key thumbprint.
6. 管理要素は、token-bundle を token-chal (それぞれ、base64url でエンコードされたテキスト文字列として) と連結し、完全なトークンとクライアント アカウント キーの拇印を使用して、[RFC8555] のセクション 8.1 に従ってキー認証を計算します。
7. The administrative element chooses the highest-priority hash algorithm supported by both the client and server, uses that algorithm to compute the digest of the Key Authorization result, and generates a Response Bundle to send back to the ACME server in accordance with Section 3.4.
7. 管理要素は、クライアントとサーバーの両方でサポートされている最も優先度の高いハッシュ アルゴリズムを選択し、そのアルゴリズムを使用してキー認証結果のダイジェストを計算し、セクション 3.4 に従って ACME サーバーに送り返す応答バンドルを生成します。
8. The ACME client waits for the authorization to be finalized on the ACME server in accordance with Section 7.5.1 of [RFC8555].
8. ACME クライアントは、[RFC8555] のセクション 7.5.1 に従って、ACME サーバー上で認可が完了するのを待ちます。
9. Once the challenge is completed (successfully or not), the ACME client indicates to the BP Agent that the id-chal is no longer usable. If the authorization fails, the ACME client MAY retry the challenge from Step 3.
9. チャレンジが完了すると (成功または失敗にかかわらず)、ACME クライアントは BP エージェントに、id-chal が使用できなくなったことを示します。認可が失敗した場合、ACME クライアントはステップ 3 からのチャレンジを再試行してもよい(MAY)。
The ACME server verifies the client's control over a Node ID by performing the following steps:
ACME サーバーは、次の手順を実行して、ノード ID に対するクライアントの制御を検証します。
1. The ACME server receives a newOrder or newAuthz request including the identifier type "bundleEID", where the URI value is a Node ID.
1. ACME サーバーは、識別子タイプ「bundleEID」を含む newOrder または newAuthz リクエストを受信します。ここで、URI 値はノード ID です。
2. The ACME server generates an authorization for the Node ID with challenge type "bp-nodeid-00" in accordance with Section 3.1.
2. ACME サーバーは、セクション 3.1 に従って、チャレンジ タイプ「bp-nodeid-00」を持つノード ID の認可を生成します。
3. The ACME server receives a POST to the challenge URL indicated from the authorization object. The payload is handled in accordance with Section 3.2.
3. ACME サーバーは、認可オブジェクトから示されたチャレンジ URL への POST を受信します。ペイロードはセクション 3.2 に従って処理されます。
4. The ACME server sends, via the administrative element of its BP Agent, one or more Challenge Bundles in accordance with Section 3.3. Each Challenge Bundle contains a distinct, random token-bundle to be able to correlate with a Response Bundle. Computing an expected Key Authorization digest is not necessary until a response is received with a chosen hash algorithm.
4. ACME サーバーは、BP エージェントの管理要素を介して、セクション 3.3 に従って 1 つ以上のチャレンジ バンドルを送信します。各チャレンジ バンドルには、レスポンス バンドルと関連付けることができる、個別のランダムなトークン バンドルが含まれています。選択したハッシュ アルゴリズムで応答を受信するまでは、予想されるキー認証ダイジェストを計算する必要はありません。
5. The ACME server waits for a Response Bundle(s) for a limited interval of time (based on the Response Object of Section 3.2). Responses are encoded in accordance with Section 3.4.
5. ACME サーバーは、限られた時間間隔で応答バンドルを待機します (セクション 3.2 の応答オブジェクトに基づいて)。応答はセクション 3.4 に従ってエンコードされます。
6. Once received and decoded, the ACME server checks the contents of each Response Bundle in accordance with Section 3.4.1. After all Challenge Bundles have either been responded to or timed-out, the ACME server policy (see Section 3.5) determines whether the validation is successful. If validation is not successful, a client may retry the challenge that starts in Step 3.
6. 受信してデコードすると、ACME サーバーはセクション 3.4.1 に従って各応答バンドルの内容をチェックします。すべてのチャレンジ バンドルが応答されるかタイムアウトになった後、ACME サーバー ポリシー (セクション 3.5 を参照) によって検証が成功したかどうかが判断されます。検証が成功しなかった場合、クライアントはステップ 3 から始まるチャレンジを再試行できます。
When responding to a Challenge Bundle, a BP Agent SHALL send a single Response Bundle in accordance with Section 3.4. A BP Agent SHALL respond to ACME challenges only within the interval of time and only for the id-chal indicated by the ACME client. A BP Agent SHALL respond to multiple Challenge Bundles with the same ACME parameters but different Bundle identities (source Node ID and timestamp); these correspond with the ACME server validating via multiple routing paths.
チャレンジ バンドルに応答する場合、BP エージェントはセクション 3.4 に従って単一の応答バンドルを送信するものとします (SHALL)。BP エージェントは、ACME クライアントによって指定された ID-chal に対してのみ、一定時間内でのみ ACME チャレンジに応答するものとします (SHALL)。BP エージェントは、同じ ACME パラメータを持つが異なるバンドル ID (ソース ノード ID とタイムスタンプ) を持つ複数のチャレンジ バンドルに応答するものとします (SHALL)。これらは、複数のルーティング パスを介して検証する ACME サーバーに対応します。
The DTN Node ID Challenge Object is included by the ACME server as defined in Section 7.5 of [RFC8555] when it supports validating Node IDs.
DTN ノード ID チャレンジ オブジェクトは、ノード ID の検証をサポートする場合、[RFC8555] のセクション 7.5 で定義されているように ACME サーバーによって組み込まれます。
The DTN Node ID Challenge Object has the following content:
DTN ノード ID チャレンジ オブジェクトには次の内容が含まれます。
type (required, string):
タイプ (必須、文字列):
The string "bp-nodeid-00".
文字列「bp-nodeid-00」。
id-chal (required, string):
id-chal (必須、文字列):
This is a random value associated with a challenge that allows a client to filter valid Challenge Bundles (Section 3.3). The same value is used for all Challenge Bundles associated with an ACME challenge, including multi-perspective validation using multiple sources as described in Section 3.5. This value SHALL have at least 128 bits of entropy. It SHALL NOT contain any characters outside the base64url alphabet as described in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be stripped. See BCP 106 [RFC4086] for additional information on randomness requirements.
これは、クライアントが有効なチャレンジ バンドルをフィルタリングできるようにするチャレンジに関連付けられたランダムな値です (セクション 3.3)。セクション 3.5 で説明されているように、複数のソースを使用したマルチパースペクティブ検証を含む、ACME チャレンジに関連付けられたすべてのチャレンジ バンドルに同じ値が使用されます。この値には少なくとも 128 ビットのエントロピーが含まれているものとします (SHALL)。[RFC4648] のセクション 5 で説明されているように、base64url アルファベット以外の文字を含めてはなりません (SHALL NO)。末尾の「=」埋め込み文字は削除されます(SHALL)。ランダム性要件の追加情報については、BCP 106 [RFC4086] を参照してください。
token-chal (required, string):
token-chal (必須、文字列):
This is a random value, used as part of the Key Authorization algorithm, which is communicated to the ACME client only over the ACME channel. This value SHALL have at least 128 bits of entropy. It SHALL NOT contain any characters outside the base64url alphabet as described in Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be stripped. See BCP 106 [RFC4086] for additional information on randomness requirements.
これはキー認証アルゴリズムの一部として使用されるランダム値であり、ACME チャネル経由でのみ ACME クライアントに通信されます。この値には少なくとも 128 ビットのエントロピーが含まれているものとします (SHALL)。[RFC4648] のセクション 5 で説明されているように、base64url アルファベット以外の文字を含めてはなりません (SHALL NO)。末尾の「=」埋め込み文字は削除されます(SHALL)。ランダム性要件の追加情報については、BCP 106 [RFC4086] を参照してください。
{
"type": "bp-nodeid-00",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"id-chal": "dDtaviYTPUWFS3NK37YWfQ",
"token-chal": "tPUZNY4ONIk6LxErRFEjVw"
}
The token-chal value included in this object applies to the entire challenge and may correspond with multiple separate token-bundle values when multiple Challenge Bundles are sent for a single validation.
このオブジェクトに含まれる token-chal 値はチャレンジ全体に適用され、単一の検証のために複数のチャレンジ バンドルが送信される場合、複数の個別のトークン バンドル値に対応する場合があります。
The DTN Node ID Response Object is sent by the ACME client when it authorizes validation of a Node ID as defined in Section 7.5.1 of [RFC8555]. Because a DTN has the potential for significantly longer (but roughly predictable) delays than a non-DTN network, the ACME client is able to inform the ACME server if a particular validation round-trip is expected to take longer than non-DTN network delays (on the order of seconds).
DTN ノード ID 応答オブジェクトは、[RFC8555] のセクション 7.5.1 で定義されているように、ACME クライアントがノード ID の検証を許可するときに、ACME クライアントによって送信されます。DTN は非 DTN ネットワークよりも大幅に長い (ただし、おおよそ予測可能) 遅延が発生する可能性があるため、ACME クライアントは、特定の検証ラウンドトリップに非 DTN ネットワークの遅延よりも長くかかる (数秒程度) と予想される場合に ACME サーバーに通知できます。
The DTN Node ID Response Object has the following content:
DTN ノード ID 応答オブジェクトには次の内容が含まれます。
rtt (optional, number):
rtt (オプション、数値):
An expected Round-Trip Time (RTT), in seconds, between sending a Challenge Bundle and receiving a Response Bundle. This value is a hint to the ACME server for how long to wait for responses but is not authoritative. The minimum RTT value SHALL be zero. There is no special significance to zero-value RTT, it simply indicates the response is expected in less than the least significant unit used by the ACME client.
チャレンジ バンドルの送信からレスポンス バンドルの受信までの予想ラウンドトリップ時間 (RTT) (秒単位)。この値は、ACME サーバーに対する応答の待機時間を示すヒントですが、権限はありません。最小 RTT 値はゼロであるものとします (SHALL)。ゼロ値の RTT には特別な意味はありません。単に、ACME クライアントが使用する最下位単位よりも小さい応答が期待されることを示します。
{
"rtt": 300.0
}
A Response Object SHALL NOT be sent until the BP Agent has been configured to properly respond to the challenge. The RTT value is meant to indicate any node-specific path delays expected to be encountered from the ACME server. Because there is no requirement on the path (or paths) regarding which Bundles may traverse between the ACME server and the BP Agent, and the ACME server can attempt some path diversity, the RTT value SHOULD be pessimistic.
BP エージェントがチャレンジに適切に応答するように設定されるまで、応答オブジェクトを送信してはなりません (SHALL)。RTT 値は、ACME サーバーから発生すると予想されるノード固有のパス遅延を示すことを目的としています。ACME サーバーと BP エージェントの間でバンドルが通過できるパスに関する要件はなく、ACME サーバーはパスの多様性を試みることができるため、RTT 値は悲観的である必要があります (SHOULD)。
A default Bundle response interval, used when the object does not contain an RTT, SHOULD be a configurable parameter of the ACME server. If the ACME client indicated an RTT value in the object, the response interval SHOULD be twice the RTT (with limiting logic applied as described below). The lower limit on the response interval is network specific, but it SHOULD NOT be shorter than one second. The upper limit on response interval is network specific, but it SHOULD NOT be longer than one minute (60 seconds) for a terrestrial-only DTN.
オブジェクトに RTT が含まれていない場合に使用されるデフォルトのバンドル応答間隔は、ACME サーバーの設定可能なパラメータであるべきです (SHOULD)。ACME クライアントがオブジェクトで RTT 値を示した場合、応答間隔は RTT の 2 倍である必要があります (以下で説明するように制限ロジックが適用されます)。応答間隔の下限はネットワークによって異なりますが、1 秒より短くすべきではありません。応答間隔の上限はネットワーク固有ですが、地上専用 DTN の場合は 1 分 (60 秒) を超えてはなりません。
Each ACME Node ID Validation Challenge Bundle SHALL be structured and encoded in accordance with BPv7 [RFC9171].
各 ACME ノード ID 検証チャレンジ バンドルは、BPv7 [RFC9171] に従って構造化およびエンコードされるものとします (SHALL)。
Each Challenge Bundle has parameters as listed here:
各チャレンジ バンドルには、以下に示すパラメータがあります。
Bundle Processing Control Flags:
バンドル処理制御フラグ:
The primary block flags SHALL indicate that the payload is an administrative record. The primary block flags SHALL indicate that user application acknowledgement is requested; this flag distinguishes the Challenge Bundle from the Response Bundle.
プライマリ ブロック フラグは、ペイロードが管理記録であることを示すものとします (SHALL)。プライマリ ブロック フラグは、ユーザー アプリケーションの確認応答が要求されていることを示すものとします (SHALL)。このフラグは、チャレンジ バンドルとレスポンス バンドルを区別します。
Destination EID:
宛先EID:
The Destination EID SHALL be the ACME-server-normalized Node ID being validated.
宛先 EID は、検証対象の ACME サーバーで正規化されたノード ID であるものとします。
Source Node ID:
ソースノードID:
The Source Node ID SHALL indicate the Node ID of a BP Agent of the ACME server performing the challenge.
ソース ノード ID は、チャレンジを実行する ACME サーバーの BP エージェントのノード ID を示すものとします (SHALL)。
Creation Timestamp and Lifetime:
作成タイムスタンプと有効期間:
The Creation Timestamp SHALL be set to the time at which the challenge was generated. The Lifetime SHALL indicate the response interval (of Section 3.2) for which the ACME server will accept responses to this challenge.
作成タイムスタンプは、チャレンジが生成された時刻に設定されるものとします (SHALL)。ライフタイムは、ACME サーバーがこのチャレンジに対する応答を受け入れる応答間隔 (セクション 3.2 の) を示すものとします (SHALL)。
Administrative Record Type Code:
管理記録タイプコード:
This is set to the ACME Node ID Validation type code defined in Section 7.3.
これは、セクション 7.3 で定義されている ACME ノード ID 検証タイプ コードに設定されます。
Administrative Record Content:
管理記録の内容:
The Challenge Bundle administrative record content SHALL consist of a CBOR map containing the following three pairs:
チャレンジ バンドルの管理レコードのコンテンツは、次の 3 つのペアを含む CBOR マップで構成されます。
* One pair SHALL consist of key 1 with a value of ACME challenge id-chal, copied from the Challenge Object, represented as a CBOR byte string.
* 1 つのペアは、CBOR バイト文字列として表される、チャレンジ オブジェクトからコピーされた ACME チャレンジ ID-chal の値を持つキー 1 で構成されます(SHALL)。
* One pair SHALL consist of key 2 with a value of ACME challenge token-bundle, represented as a CBOR byte string. The token-bundle is a random value that uniquely identifies the Challenge Bundle. This value SHALL have at least 128 bits of entropy. See BCP 106 [RFC4086] for additional information on randomness requirements.
* 1 つのペアは、CBOR バイト文字列として表される ACME チャレンジ トークン バンドルの値を持つキー 2 で構成されるものとします (SHALL)。トークンバンドルは、チャレンジ バンドルを一意に識別するランダムな値です。この値には少なくとも 128 ビットのエントロピーが含まれているものとします (SHALL)。ランダム性要件の追加情報については、BCP 106 [RFC4086] を参照してください。
* One pair SHALL consist of key 4 with a value of an array containing acceptable hash algorithm identifiers. The array SHALL be ordered in descending preference, with the first item being the most preferred. The array SHALL contain at least one item. Each algorithm identifier SHALL correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry [IANA-COSE].
* 1 つのペアは、キー 4 と、許容可能なハッシュ アルゴリズム識別子を含む配列の値で構成されます。配列は優先順位の降順に並べるものとし、最初の項目が最も優先されます。配列には少なくとも 1 つの項目が含まれているものとします (SHALL)。各アルゴリズム識別子は、「COSE Algorithms」レジストリ [IANA-COSE] に登録されたアルゴリズムの Value 列 (整数またはテキスト文字列) に対応するものとします (SHALL)。
This structure is part of the extension CDDL in Appendix A. An example full Challenge Bundle is included in Appendix B.1.
この構造は付録 A の拡張 CDDL の一部です。完全なチャレンジ バンドルの例は付録 B.1 に含まれています。
For interoperability, entities that use this validation method SHALL support the hash algorithm "SHA-256" (value -16) [RFC9054]. This requirement allows for different implementations to be configured to use an interoperable algorithm, but does not preclude the use of other algorithms with either higher or lower priority.
相互運用性のために、この検証方法を使用するエンティティは、ハッシュ アルゴリズム "SHA-256" (値 -16) [RFC9054] をサポートするものとします (SHALL)。この要件により、相互運用可能なアルゴリズムを使用するようにさまざまな実装を構成できますが、優先順位の高いまたは低い他のアルゴリズムの使用が妨げられるわけではありません。
If the BP Agent generating a Challenge Bundle does not have a well-synchronized clock or the agent responding to the challenge is expected to not have a well-synchronized clock, the Bundle SHALL include a Bundle Age extension block in accordance with Section 4.4.2 of [RFC9171].
チャレンジバンドルを生成する BP エージェントが十分に同期したクロックを持たない場合、またはチャレンジに応答するエージェントが十分に同期したクロックを持たないと予想される場合、バンドルには [RFC9171] のセクション 4.4.2 に従ってバンドル期間延長ブロックを含めるものとします (SHALL)。
Challenge Bundles SHALL include a Block Integrity Block (BIB) in accordance with Section 4 or with a Security Source identical to the Bundle Source Node. Challenge Bundles SHALL NOT be directly encrypted by the Block Confidentiality Block (BCB) method or any other method (see Section 6.1).
チャレンジ バンドルには、セクション 4 に従って、またはバンドル ソース ノードと同一のセキュリティ ソースを伴うブロック整合性ブロック (BIB) が含まれるものとします (SHALL)。チャレンジ バンドルは、ブロック機密性ブロック (BCB) 方式またはその他の方式で直接暗号化してはなりません (セクション 6.1 を参照)。
A proper Challenge Bundle meets all of the following criteria:
適切なチャレンジ バンドルは、次の基準をすべて満たしています。
* The Challenge Bundle was received within the time interval allowed for the challenge. The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the Challenge Bundle.
* チャレンジ バンドルは、チャレンジに許可された時間内に受信されました。許可される間隔は、作成タイムスタンプから始まり、チャレンジ バンドルの存続期間まで延長されます。
* The Challenge Bundle contains a BIB that covers at least the primary block and payload. That BIB has a Security Source that is trusted and passes security-context-specific validation (i.e., Message Authentication Code (MAC) or signature verification).
* チャレンジ バンドルには、少なくともプライマリ ブロックとペイロードをカバーする BIB が含まれています。その BIB には、信頼されており、セキュリティ コンテキスト固有の検証 (つまり、メッセージ認証コード (MAC) または署名検証) に合格するセキュリティ ソースがあります。
* The challenge payload contains the id-chal as indicated in the ACME Challenge Object.
* チャレンジ ペイロードには、ACME チャレンジ オブジェクトで示されている id-chal が含まれています。
* The challenge payload contains a token-bundle matching the definition in Section 3.3.
* チャレンジ ペイロードには、セクション 3.3 の定義に一致するトークン バンドルが含まれています。
* The challenge payload contains at least one hash algorithm identifier acceptable to the client.
* チャレンジ ペイロードには、クライアントが受け入れ可能なハッシュ アルゴリズム識別子が少なくとも 1 つ含まれています。
Failure to match any of the above SHALL cause the Challenge Bundle to be otherwise ignored by the BP Agent. It is an implementation matter of how to react to such failures, which could include logging the event, incrementing counters, or raising alarms.
上記のいずれかに一致しない場合、チャレンジ バンドルは BP エージェントによって無視されます。このような障害にどのように対応するかは実装の問題であり、イベントのログ記録、カウンタの増加、アラームの発生などが考えられます。
Each ACME Node ID Validation Response Bundle SHALL be structured and encoded in accordance with BPv7 [RFC9171].
各 ACME ノード ID 検証応答バンドルは、BPv7 [RFC9171] に従って構造化され、エンコードされるものとします (SHALL)。
Each Response Bundle has parameters as listed here:
各応答バンドルには、次に示すパラメータがあります。
Bundle Processing Control Flags:
バンドル処理制御フラグ:
The primary block flags SHALL indicate that the payload is an administrative record. The primary block flags SHALL NOT indicate that user application acknowledgement is requested; this flag distinguishes the Response Bundle from the Challenge Bundle.
プライマリ ブロック フラグは、ペイロードが管理記録であることを示すものとします (SHALL)。プライマリ ブロック フラグは、ユーザー アプリケーションの承認が要求されていることを示してはなりません (SHALL NOT)。このフラグは、レスポンス バンドルとチャレンジ バンドルを区別します。
Destination EID:
宛先EID:
The Destination EID SHALL be identical to the Source Node ID of the Challenge Bundle to which this response corresponds.
宛先 EID は、この応答が対応するチャレンジ バンドルのソース ノード ID と同一であるものとします。
Source Node ID:
ソースノードID:
The Source Node ID SHALL be identical to the Destination EID of the Challenge Bundle to which this response corresponds.
ソース ノード ID は、この応答が対応するチャレンジ バンドルの宛先 EID と同一であるものとします。
Creation Timestamp and Lifetime:
作成タイムスタンプと有効期間:
The Creation Timestamp SHALL be set to the time at which the response was generated. The response Lifetime SHALL indicate the response interval remaining if the Challenge Bundle indicated a limited Lifetime.
作成タイムスタンプは、応答が生成された時刻に設定されるものとします (SHALL)。応答ライフタイムは、チャレンジ バンドルが制限されたライフタイムを示した場合、残りの応答間隔を示すものとします (SHALL)。
Administrative Record Type Code:
管理記録タイプコード:
Set to the ACME Node ID Validation type code defined in Section 7.3.
セクション 7.3 で定義されている ACME ノード ID 検証タイプ コードに設定します。
Administrative Record Content:
管理記録の内容:
The Response Bundle administrative record content SHALL consist of a CBOR map containing the following three pairs:
応答バンドルの管理レコードのコンテンツは、次の 3 つのペアを含む CBOR マップで構成されるものとします。
* One pair SHALL consist of key 1 with value of ACME challenge id-chal, copied from the Request Bundle, represented as a CBOR byte string.
* 1 つのペアは、リクエスト バンドルからコピーされ、CBOR バイト文字列として表される ACME チャレンジ ID-chal の値を持つキー 1 で構成されます。
* One pair SHALL consist of key 2 with value of ACME challenge token-bundle, copied from the Request Bundle, represented as a CBOR byte string.
* 1 つのペアは、リクエスト バンドルからコピーされ、CBOR バイト文字列として表される ACME チャレンジ トークン バンドルの値を持つキー 2 で構成されます。
* One pair SHALL consist of key 3 with value of a two-element array containing the pair of a hash algorithm identifier and the hash byte string. The algorithm identifier SHALL correspond to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry [IANA-COSE].
* 1 つのペアは、ハッシュ アルゴリズム識別子とハッシュ バイト文字列のペアを含む 2 要素配列の値を持つキー 3 で構成されます。アルゴリズム識別子は、「COSE Algorithms」レジストリ [IANA-COSE] に登録されたアルゴリズムの Value 列 (整数またはテキスト文字列) に対応するものとします (SHALL)。
This structure is part of the extension CDDL in Appendix A. An example full Response Bundle is included in Appendix B.2.
この構造は、付録 A の拡張 CDDL の一部です。完全な応答バンドルの例は、付録 B.2 に含まれています。
If the BP Agent responding to a Challenge Bundle does not have a well-synchronized clock, it SHALL use any information about last-hop delays and (if present) Bundle Age extension data to infer the age of the Challenge Bundle and Lifetime of the Response Bundle.
チャレンジ バンドルに応答する BP エージェントが適切に同期されたクロックを持っていない場合、ラストホップ遅延に関する情報と (存在する場合) バンドル期間拡張データを使用して、チャレンジ バンドルの期間と応答バンドルの有効期間を推測するものとします (SHALL)。
Response Bundles SHALL include a BIB in accordance with Section 4. Response Bundles SHALL NOT be directly encrypted by BCB or any other method (see Section 6.1 for explanation).
応答バンドルには、セクション 4 に従って BIB が含まれるものとします (SHALL)。応答バンドルは、BCB またはその他の方法で直接暗号化されてはなりません (説明についてはセクション 6.1 を参照)。
A proper Response Bundle meets all of the following criteria:
適切な応答バンドルは、次の基準をすべて満たしています。
* The Response Bundle was received within the time interval allowed for the challenge. The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the associated Challenge Bundle. The interval of the Challenge Bundle is used here because the interval of the Response Bundle could be made to disagree with the Challenge Bundle.
* 応答バンドルは、チャレンジに許可された時間間隔内に受信されました。許可される間隔は、作成タイムスタンプから始まり、関連付けられたチャレンジ バンドルの存続期間まで延長されます。レスポンス バンドルの間隔はチャレンジ バンドルと一致しない可能性があるため、ここではチャレンジ バンドルの間隔が使用されます。
* The Response Bundle Source Node ID is identical to the Node ID being validated. The comparison of Node IDs SHALL use the comparison logic of the NODE-ID from Section 4.4.1 of [RFC9174].
* 応答バンドルのソース ノード ID は、検証されるノード ID と同一です。ノード ID の比較には、[RFC9174] のセクション 4.4.1 の NODE-ID の比較ロジックを使用するものとします (SHALL)。
* The Response Bundle contains a BIB that covers at least the primary block and payload. That BIB has a Security Source that is trusted and passes security-context-specific validation.
* 応答バンドルには、少なくともプライマリ ブロックとペイロードをカバーする BIB が含まれています。その BIB には、信頼できるセキュリティ ソースがあり、セキュリティ コンテキスト固有の検証に合格します。
* The response payload contains the same id-chal and token-bundle as sent in the Challenge Bundle (this is also how the two Bundles are correlated).
* 応答ペイロードには、チャレンジ バンドルで送信されたものと同じ id-chal および token-bundle が含まれています (これは、2 つのバンドルが関連付けられる方法でもあります)。
* The response payload contains a hash algorithm identifier acceptable to the server (as indicated in the Challenge Bundle).
* 応答ペイロードには、サーバーが受け入れ可能なハッシュ アルゴリズム識別子が含まれています (チャレンジ バンドルで示されているように)。
* The response payload contains the expected Key Authorization digest computed by the ACME server.
* 応答ペイロードには、ACME サーバーによって計算された予期されるキー認証ダイジェストが含まれています。
Any of the failures above SHALL cause that single-perspective validation to fail. Any of the failures above SHOULD be distinguished as subproblems to the ACME client. The lack of a response within the expected response interval, as defined in Section 3.2, SHALL also be treated as a validation failure.
上記のいずれかの失敗により、単一視点の検証が失敗するものとします。上記の障害はいずれも、ACME クライアントに対するサブ問題として区別されるべきです (SHOULD)。セクション 3.2 で定義されているように、予想される応答間隔内に応答がない場合も、検証失敗として扱われるものとします (SHALL)。
To avoid on-path attacks in certain networks, an ACME server can perform a single validation using multiple Challenge Bundle sources or via multiple routing paths. This technique is called "multi-perspective validation" as recommended in Section 10.2 of [RFC8555] and an implementation is used by the Let's Encrypt service in its operational deployment [LE-multi-perspective]. The utility of a multi-perspective validation is part of the experimental nature (see Section 1.5) of this specification.
特定のネットワークでのオンパス攻撃を回避するために、ACME サーバーは複数のチャレンジ バンドル ソースを使用するか、複数のルーティング パスを介して単一の検証を実行できます。この手法は、[RFC8555] のセクション 10.2 で推奨されているように「マルチパースペクティブ検証」と呼ばれ、実装は Let's Encrypt サービスの運用展開 [LE-multi-perspective] で使用されます。多視点検証の有用性は、この仕様の実験的性質 (セクション 1.5 を参照) の一部です。
When required by policy, an ACME server SHALL send multiple Challenge Bundles from different sources in the BP network. When multiple Challenge Bundles are sent for a single validation, it is a matter of ACME server policy to determine whether or not the validation as a whole is successful. The result of each single-source validation is defined as success or failure in Section 3.4.1.
ポリシーで必要な場合、ACME サーバーは BP ネットワーク内の異なるソースから複数のチャレンジ バンドルを送信するものとします (SHALL)。単一の検証のために複数のチャレンジ バンドルが送信された場合、検証全体が成功したかどうかは ACME サーバー ポリシーによって決まります。各単一ソース検証の結果は、セクション 3.4.1 で成功または失敗として定義されます。
A RECOMMENDED validation policy is to succeed if the challenge from a primary Bundle source is successful and if there is no more than one failure from a secondary source. The determination of which perspectives are considered primary or secondary is an implementation matter.
推奨される検証ポリシーは、プライマリ バンドル ソースからのチャレンジが成功し、セカンダリ ソースからの失敗が 1 つしかない場合に成功することです。どの視点が主または副次的であるとみなされるかの決定は、実装上の問題です。
Regardless of whether a validation is single- or multi-perspective, a validation failure SHALL be indicated by an ACME error type of "incorrectResponse". Each specific perspective failure SHOULD be indicated to the ACME client as a validation subproblem.
検証が単一視点であるか複数視点であるかに関係なく、検証の失敗は「incorrectResponse」という ACME エラー タイプによって示されるものとします (SHALL)。それぞれの特定のパースペクティブ障害は、検証サブ問題として ACME クライアントに示される必要があります (SHOULD)。
This section defines a BIB use that closely resembles the function of DKIM email signing [RFC6376]. In this mechanism, a routing node in a DTN subnetwork attests to the origination of a Bundle by adding a BIB before forwarding it. The Bundle receiver then need not trust the source of the Bundle, it only needs to trust this Security Source node. The receiver needs policy configuration to know which Security Sources are permitted to attest for which Bundle sources. The utility of an integrity gateway is part of the experimental nature (Section 1.5) of this specification.
このセクションでは、DKIM 電子メール署名 [RFC6376] の機能によく似た BIB の使用を定義します。このメカニズムでは、DTN サブネットワーク内のルーティング ノードは、バンドルを転送する前に BIB を追加することで、バンドルの発信元を証明します。バンドル受信者はバンドルのソースを信頼する必要はなくなり、このセキュリティ ソース ノードを信頼するだけで済みます。受信者は、どのセキュリティ ソースがどのバンドル ソースの証明を許可されているかを知るためにポリシー設定が必要です。完全性ゲートウェイの有用性は、この仕様の実験的な性質 (セクション 1.5) の一部です。
An integrity gateway SHALL validate the Source Node ID of a Bundle, using local-network-specific means, before adding a BIB to the Bundle. The exact means by which an integrity gateway validates a Bundle's source is network specific, but it could use physical-layer, network-layer, or BP-convergence-layer authentication. The Bundle source could also add its own BIB with a local-network-specific security context or local-network-specific key material (i.e., a group key shared within the local network).
整合性ゲートウェイは、BIB をバンドルに追加する前に、ローカルネットワーク固有の手段を使用して、バンドルのソース ノード ID を検証するものとします (SHALL)。整合性ゲートウェイがバンドルのソースを検証する正確な手段はネットワーク固有ですが、物理層、ネットワーク層、または BP コンバージェンス層の認証を使用する可能性があります。バンドル ソースは、ローカル ネットワーク固有のセキュリティ コンテキストまたはローカル ネットワーク固有のキー マテリアル (つまり、ローカル ネットワーク内で共有されるグループ キー) を含む独自の BIB を追加することもできます。
When an integrity gateway adds a BIB, it SHALL be in accordance with BPSec [RFC9172] requirements. The BIB integrity SHALL cover both the payload block and the primary block, either directly as a target or as additional authenticated data for the payload block MAC/signature. The Security Source of this BIB SHALL be either the Bundle source Node ID itself or a routing node trusted by the destination node (see Section 6.2).
整合性ゲートウェイが BIB を追加するときは、BPSec [RFC9172] の要件に準拠する必要があります (SHALL)。BIB の整合性は、ペイロード ブロックとプライマリ ブロックの両方を、直接ターゲットとして、またはペイロード ブロックの MAC/署名の追加認証データとしてカバーするものとします (SHALL)。この BIB のセキュリティ ソースは、バンドル ソース ノード ID 自体、または宛先ノードによって信頼されるルーティング ノードのいずれかでなければなりません (セクション 6.2 を参照)。
The ultimate purpose of this ACME validation is to allow a CA to issue certificates following the profiles of Section 4.4.2 of [RFC9174] and Section 4 of [BPSEC-COSE]. These purposes are referred to here as "Bundle security certificates".
この ACME 検証の最終的な目的は、CA が [RFC9174] のセクション 4.4.2 および [BPSEC-COSE] のセクション 4 のプロファイルに従って証明書を発行できるようにすることです。これらの目的を、ここでは「バンドル セキュリティ証明書」と呼びます。
The ACME identifier type "bundleEID" correlates to the PKIX certificate and certificate request "NODE-ID" as defined in Section 4.4.1 of [RFC9174]. This NODE-ID is present in certificate requests with an extensionRequest attribute (see [RFC2985]) containing a SAN extension with identities of type otherName having an Other Name form of BundleEID, identified by id-on-bundleEID from the "SMI Security for PKIX Other Name Forms" registry [IANA-SMI]. Because the BundleEID Other Name form is encoded as an IA5String, it SHALL be treated as being in the percent-encoded form of Section 2.1 of [RFC3986].
ACME 識別子タイプ「bundleEID」は、[RFC9174] のセクション 4.4.1 で定義されているように、PKIX 証明書および証明書要求「NODE-ID」に相関します。この NODE-ID は、「SMI Security for PKIX Other Name Forms」レジストリ [IANA-SMI] の id-on-bundleEID によって識別される、BundleEID の Other Name 形式を持つ otherName タイプのアイデンティティを持つ SAN 拡張を含む、extensionRequest 属性 ([RFC2985] を参照) を持つ証明書リクエストに存在します。BundleEID Other Name 形式は IA5String としてエンコードされているため、[RFC3986] のセクション 2.1 のパーセントエンコード形式として扱われるものとします (SHALL)。
One defining aspect of Bundle security certificates is the Extended Key Usage key purpose id-kp-bundleSecurity [IANA-SMI], as defined in Section 4.4.2.1 of [RFC9174]. When requesting a certificate that includes a NODE-ID, the CSR SHOULD include an Extended Key Usage of id-kp-bundleSecurity. When a Bundle security certificate is issued based on a validated NODE-ID, the certificate SHALL include an Extended Key Usage of id-kp-bundleSecurity.
バンドル セキュリティ証明書の定義の 1 つの側面は、[RFC9174] のセクション 4.4.2.1 で定義されている拡張キー使用法キー目的 id-kp-bundleSecurity [IANA-SMI] です。NODE-ID を含む証明書を要求する場合、CSR には id-kp-bundleSecurity の拡張キー使用法を含める必要があります (SHOULD)。バンドル セキュリティ証明書が検証された NODE-ID に基づいて発行される場合、証明書には id-kp-bundleSecurity の拡張キー使用法が含まれるものとします (SHALL)。
A single Bundle security CSR MAY contain a mixed set of SAN identifiers, including combinations of IP-ID [RFC9525], DNS-ID [RFC9525], and NODE-ID [RFC9174] types. These correspond with ACME identifier type "ip", "dns", and "bundleEID", respectively.
単一のバンドル セキュリティ CSR には、IP-ID [RFC9525]、DNS-ID [RFC9525]、および NODE-ID [RFC9174] タイプの組み合わせを含む、SAN 識別子の混合セットを含めることができます (MAY)。これらは、それぞれ ACME 識別子のタイプ「ip」、「dns」、「bundleEID」に対応します。
There is no restriction on how a certificate combines these claims, but each identifier SHALL be validated by an ACME server to issue such a certificate as part of an associated ACME order. This is no different than the existing behavior of ACME [RFC8555] but is mentioned here to make sure that CA policy handles such situations, especially related to validation failure of an identifier in the presence of multiple identifiers. Existing validation mechanisms are defined for identifier type "ip" [RFC8738] and "dns" [RFC8555] among others [IANA-ACME].
証明書がこれらのクレームをどのように組み合わせるかについて制限はありませんが、関連する ACME オーダーの一部としてそのような証明書を発行するために、各識別子は ACME サーバーによって検証されるものとします (SHALL)。これは ACME [RFC8555] の既存の動作と何ら変わりませんが、特に複数の識別子が存在する場合の識別子の検証失敗に関連する状況を CA ポリシーが確実に処理できるようにするためにここで言及されています。既存の検証メカニズムは、特に識別子タイプ「ip」[RFC8738] および「dns」[RFC8555] に対して定義されています [IANA-ACME]。
The specific use case of TLS-based security for the TCP CL in Section 4.4 of [RFC9174] allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node ID of the entity. These authentications apply to each identifier type, used for different network layers, at different points during secure session establishment.
[RFC9174] のセクション 4.4 にある TCP CL の TLS ベースのセキュリティの特定の使用例では、証明書がエンティティの DNS 名とエンティティのノード ID の両方を認証することが許可されており、一部のネットワーク ポリシーでは要求されています。これらの認証は、安全なセッション確立中のさまざまな時点で、さまざまなネットワーク層に使用される各識別子のタイプに適用されます。
ACME extensions specified in this document can be used to request encryption-only or signing-only Bundle security certificates. The validity of a request for either a restricted-use or unrestricted-use certificate is dependent on both CA policy to issue such certificates as well as constraints based on the requested key and algorithm types.
このドキュメントで指定されている ACME 拡張機能は、暗号化専用または署名専用のバンドル セキュリティ証明書を要求するために使用できます。使用制限付き証明書または使用制限なし証明書の要求の有効性は、そのような証明書を発行する CA ポリシーと、要求されたキーおよびアルゴリズムのタイプに基づく制約の両方に依存します。
In order to request a signing-only Bundle security certificate, the CSR SHALL include the key usage extension with the digitalSignature and/or nonRepudiation bits set and no other bits set.
署名専用バンドルのセキュリティ証明書を要求するために、CSR には、digitalSignature および/または nonRepudiation ビットが設定され、その他のビットが設定されていないキー使用拡張を含める必要があります (SHALL)。
In order to request an encryption-only Bundle security certificate, the CSR SHALL include the key usage extension with the keyEncipherment or keyAgreement bits set and no other bits set.
暗号化のみのバンドル セキュリティ証明書を要求するために、CSR には keyEncipherment または keyAgreement ビットが設定され、他のビットが設定されていないキー使用拡張を含める必要があります (SHALL)。
Presence of both of the above sets of key usage bits in the CSR, as well as absence of key usage extension in the CSR, signals the ACME server to issue a Bundle security certificate suitable for both signing and encryption.
CSR に上記のキー使用ビットのセットが両方とも存在し、CSR にキー使用拡張が存在しない場合、ACME サーバーに署名と暗号化の両方に適したバンドル セキュリティ証明書を発行するように指示します。
This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552].
このセクションでは、BCP 72 [RFC3552] のガイダンスに基づいて、セキュリティに関する考慮事項を脅威のカテゴリに分けます。
Because this challenge mechanism is used to bootstrap security between DTN Nodes, the challenge and its response are likely to be transferred in plaintext. The only ACME data present on-the-wire is a random token and a cryptographic digest, so there is no sensitive data to be leaked within the Node ID Validation Bundle exchange. Because each challenge uses a separate token pair, there is no value in an on-path attacker seeing the tokens from past challenges and/or responses.
このチャレンジ メカニズムは DTN ノード間のセキュリティをブートストラップするために使用されるため、チャレンジとその応答は平文で転送される可能性があります。回線上に存在する ACME データはランダム トークンと暗号ダイジェストのみであるため、ノード ID 検証バンドル交換内で機密データが漏洩することはありません。各チャレンジは個別のトークン ペアを使用するため、パス上の攻撃者が過去のチャレンジおよび/または応答からのトークンを確認することに価値はありません。
It is possible for intermediate BP Nodes to encapsulate-and-encrypt Challenge Bundles and/or Response Bundles while they traverse untrusted networks, but that is a DTN configuration matter outside of the scope of this document.
中間 BP ノードが信頼できないネットワークを通過する際に、チャレンジ バンドルやレスポンス バンドルをカプセル化して暗号化することは可能ですが、それは DTN 設定の問題であり、このドキュメントの範囲外です。
As described in Section 10.1 of [RFC8555], it is possible for an active attacker to alter data on both ACME client channel and the DTN validation channel.
[RFC8555] のセクション 10.1 で説明されているように、アクティブな攻撃者が ACME クライアント チャネルと DTN 検証チャネルの両方のデータを変更する可能性があります。
The primary mitigation is to delegate Bundle integrity sourcing to a trusted routing node near, in the sense of Bundle routing topology, the Bundle source node as defined in Section 4. This is functionally similar to DKIM email signing [RFC6376] and provides some level of secure Bundle origination.
主な緩和策は、バンドルのルーティング トポロジの意味で、セクション 4 で定義されているバンドル ソース ノードに近い信頼できるルーティング ノードにバンドルの整合性ソースを委任することです。これは機能的に DKIM 電子メール署名 [RFC6376] と同様であり、ある程度の安全なバンドル生成を提供します。
Another way to mitigate on-path attacks is to attempt validation of the same Node ID from multiple sources, hopefully via multiple Bundle routing paths, as defined in Section 3.5. It is not a trivial task to guarantee Bundle routing though, so more advanced techniques such as onion routing (using Bundle-in-Bundle encapsulation) could be employed.
オンパス攻撃を軽減するもう 1 つの方法は、セクション 3.5 で定義されているように、できれば複数のバンドル ルーティング パスを介して、複数のソースから同じノード ID の検証を試みることです。ただし、バンドル ルーティングを保証するのは簡単な作業ではないため、オニオン ルーティング (バンドルインバンドル カプセル化を使用) などのより高度な技術を使用することもできます。
It is possible for an on-path attacker to replay both Challenge Bundles or Response Bundles. Even in a properly configured DTN, it is possible that intermediate Bundle routers would use multi-path forwarding of a singleton-destination Bundle.
パス上の攻撃者がチャレンジ バンドルまたはレスポンス バンドルの両方をリプレイする可能性があります。適切に設定された DTN であっても、中間バンドル ルーターがシングルトン宛先バンドルのマルチパス転送を使用する可能性があります。
Ultimately, the point of the ACME Bundle exchange is to derive a Key Authorization value and its cryptographic digest, and to communicate that digest back to the ACME server for validation, so the uniqueness of the Key Authorization directly determines the scope of replay validity. The uniqueness of each token-bundle to each Challenge Bundle ensures that the Key Authorization is unique to the Challenge Bundle. The uniqueness of each token-chal to the ACME challenge ensures that the Key Authorization is unique to that ACME challenge and not based solely on values visible to on-path eavesdroppers.
最終的に、ACME バンドル交換のポイントは、キー認証値とその暗号ダイジェストを取得し、検証のためにそのダイジェストを ACME サーバーに送り返すことです。そのため、キー認証の一意性がリプレイの有効性の範囲を直接決定します。各チャレンジ バンドルに対する各トークン バンドルの一意性により、キー認証がチャレンジ バンドルに固有であることが保証されます。ACME チャレンジに対する各トークン チャレンジの一意性により、キー認証がその ACME チャレンジに一意であり、パス上の盗聴者に見える値のみに基づいていないことが保証されます。
Having each Bundle's primary block and payload block covered by a BIB from a trusted Security Source (see Section 4) ensures that a replayed Bundle cannot be altered in the blocks used by ACME. All together, these properties mean that there is no degraded security caused by replay of either a Challenge Bundle or a Response Bundle even in the case where the primary or payload block is not covered by a BIB. The worst that can come of Bundle replay is the waste of network resources as described in Section 6.4.
各バンドルのプライマリ ブロックとペイロード ブロックを信頼できるセキュリティ ソース (セクション 4 を参照) からの BIB でカバーすることで、再生されたバンドルが ACME によって使用されるブロック内で変更されないことが保証されます。これらの特性を総合すると、プライマリ ブロックまたはペイロード ブロックが BIB でカバーされていない場合でも、チャレンジ バンドルまたはレスポンス バンドルのいずれかの再生によってセキュリティが低下しないことを意味します。バンドルのリプレイによって起こり得る最悪の事態は、セクション 6.4 で説明されているようにネットワーク リソースの浪費です。
The behaviors described in this section all amount to a potential denial-of-service to a BP Agent.
このセクションで説明する動作はすべて、BP エージェントに対する潜在的なサービス拒否に相当します。
A malicious entity can continually send Challenge Bundles to a BP Agent. The victim BP Agent can ignore Challenge Bundles that do not conform to the specific time interval and challenge token for which the ACME client has informed the BP Agent that challenges are expected. The victim BP Agent can require all Challenge Bundles to be BIB-signed to ensure authenticity of the challenge.
悪意のあるエンティティは、継続的にチャレンジ バンドルを BP エージェントに送信する可能性があります。被害者の BP エージェントは、ACME クライアントがチャレンジが予期されることを BP エージェントに通知した特定の時間間隔とチャレンジ トークンに準拠していないチャレンジ バンドルを無視できます。被害者の BP エージェントは、チャレンジの信頼性を保証するために、すべてのチャレンジ バンドルに BIB 署名を要求できます。
A malicious entity can continually send Response Bundles to a BP Agent. The victim BP Agent can ignore Response Bundles that do not conform to the specific time interval or Source Node ID or challenge token for an active Node ID validation.
悪意のあるエンティティは、BP エージェントに応答バンドルを継続的に送信する可能性があります。被害者の BP エージェントは、特定の時間間隔、ソース ノード ID、またはアクティブなノード ID 検証のチャレンジ トークンに準拠しない応答バンドルを無視できます。
Similar to other validation methods, an ACME server validating a DTN Node ID could be used as a denial-of-service amplifier. For this reason, any ACME server can rate-limit validation activities for individual clients and individual certificate requests.
他の検証方法と同様に、DTN ノード ID を検証する ACME サーバーは、サービス妨害増幅器として使用される可能性があります。このため、どの ACME サーバーでも、個々のクライアントおよび個々の証明書要求に対する検証アクティビティをレート制限できます。
Because this protocol relies on ACME for part of its operation, the security considerations of ACME [RFC8555] apply to all ACME client-server exchanges during Node ID validation.
このプロトコルは動作の一部で ACME に依存しているため、ACME [RFC8555] のセキュリティに関する考慮事項は、ノード ID 検証中のすべての ACME クライアント/サーバー交換に適用されます。
Because this protocol relies on BPv7 for part of its operation, the security considerations of BPv7 [RFC9171] and BPSec [RFC9172] apply to all BP messaging during Node ID validation.
このプロトコルは動作の一部で BPv7 に依存しているため、BPv7 [RFC9171] および BPSec [RFC9172] のセキュリティに関する考慮事項は、ノード ID 検証中のすべての BP メッセージングに適用されます。
Although messaging between an ACME client or ACME server and its associated BP Agent are out-of-scope for this document, both of those channels are critical to Node ID validation security. Either channel can potentially leak data or provide attack vectors if not properly secured. These channels need to protect against spoofing of messaging in both directions to avoid interruption of normal validation sequencing and to prevent false validations from succeeding.
ACME クライアントまたは ACME サーバーとそれに関連する BP エージェント間のメッセージングはこのドキュメントの範囲外ですが、これらのチャネルはどちらもノード ID 検証のセキュリティにとって重要です。どちらのチャネルも、適切に保護されていない場合、データが漏洩したり、攻撃ベクトルを提供したりする可能性があります。これらのチャネルは、通常の検証シーケンスの中断を回避し、誤った検証が成功するのを防ぐために、両方向のメッセージングのなりすましから保護する必要があります。
The ACME server and its BP Agent exchange the outgoing id-chal, token-bundle, and Key Authorization digest, but these values do not need to be confidential (they are also in plaintext over the BP channel).
ACME サーバーとその BP エージェントは、発信 ID chal、トークンバンドル、およびキー認証ダイジェストを交換しますが、これらの値は機密である必要はありません (これらの値は、BP チャネル上でも平文で送信されます)。
Depending on implementation details, the ACME client might transmit the client account key thumbprint to its BP Agent to allow computing the Key Authorization digest on the BP Agent. If an ACME client does transmit its client account key thumbprint to a BP Agent, it is important that this data is kept confidential because it provides the binding of the client account key to the Node ID validation (as well as for all other types of ACME validation). Avoiding this transmission would require a full round-trip between BP Agent and ACME client, which can be undesirable if the two are separated by a long-delay network.
実装の詳細に応じて、ACME クライアントはクライアント アカウント キーの拇印を BP エージェントに送信して、BP エージェント上でキー認証ダイジェストを計算できるようにする場合があります。ACME クライアントがクライアント アカウント キーの拇印を BP エージェントに送信する場合、このデータは機密性を保つことが重要です。これは、このデータによってクライアント アカウント キーがノード ID 検証 (および他のすべての種類の ACME 検証) にバインドされるためです。この送信を回避するには、BP エージェントと ACME クライアントの間で完全な往復が必要になりますが、この 2 つが遅延の長いネットワークによって分離されている場合、これは望ましくない可能性があります。
This specification adds to the "Automated Certificate Management Environment (ACME) Protocol" registry group and the "Bundle Protocol" registry group.
この仕様は、「自動証明書管理環境 (ACME) プロトコル」レジストリ グループと「バンドル プロトコル」レジストリ グループに追加されます。
Within the "Automated Certificate Management Environment (ACME) Protocol" registry group [IANA-ACME], the following entry has been added to the "ACME Identifier Types" registry.
「自動証明書管理環境 (ACME) プロトコル」レジストリ グループ [IANA-ACME] 内で、次のエントリが「ACME Identifier Types」レジストリに追加されました。
+===========+===========+
| Label | Reference |
+===========+===========+
| bundleEID | RFC 9891 |
+-----------+-----------+
Table 1
Within the "Automated Certificate Management Environment (ACME) Protocol" registry group [IANA-ACME], the following entry has been added to the "ACME Validation Methods" registry.
「自動証明書管理環境 (ACME) プロトコル」レジストリ グループ [IANA-ACME] 内で、次のエントリが「ACME Validation Methods」レジストリに追加されました。
+==============+=================+======+===========+
| Label | Identifier Type | ACME | Reference |
+==============+=================+======+===========+
| bp-nodeid-00 | bundleEID | Y | RFC 9891 |
+--------------+-----------------+------+-----------+
Table 2
Within the "Bundle Protocol" registry group [IANA-BP], the following entry has been added to the "Bundle Administrative Record Types" registry.
「バンドル プロトコル」レジストリ グループ [IANA-BP] 内で、次のエントリが「バンドル管理レコード タイプ」レジストリに追加されました。
+=========================+=======+==============+===========+
| Bundle Protocol Version | Value | Description | Reference |
+=========================+=======+==============+===========+
| 7 | 255 | ACME Node ID | RFC 9891 |
| | | Validation | |
+-------------------------+-------+--------------+-----------+
Table 3
[IANA-ACME]
IANA, "Automated Certificate Management Environment (ACME)
Protocol", <https://www.iana.org/assignments/acme/>.
[IANA-BP] IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>.
[IANA-COSE]
IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose/>.
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<https://www.iana.org/assignments/smi-numbers/>.
[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>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[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>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, August
2022, <https://www.rfc-editor.org/info/rfc9054>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[BPSEC-COSE]
Sipos, B., "Bundle Protocol Security (BPSec) COSE
Context", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpsec-cose-12, 12 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-cose-12>.
[LE-multi-perspective]
Aas, J., McCarney, D., and R. Shoemaker, "Multi-
Perspective Validation Improves Domain Validation
Security", 19 February 2020,
<https://letsencrypt.org/2020/02/19/multi-perspective-
validation.html>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC8738] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension",
RFC 8738, DOI 10.17487/RFC8738, February 2020,
<https://www.rfc-editor.org/info/rfc8738>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>.
The extension of BPv7 from Appendix B of [RFC9171] for the ACME Bundles in Sections 3.3 and 3.4 is the following CDDL:
セクション 3.3 および 3.4 の ACME バンドルに関する [RFC9171] の付録 B からの BPv7 の拡張は、次の CDDL です。
; All ACME records have the same structure
$admin-record /= [0xFF, acme-record]
acme-record = acme-challenge-record / acme-response-record
acme-challenge-record = {
id-chal,
token-bundle,
alg-list
}
acme-response-record = {
id-chal,
token-bundle,
key-auth-digest
}
id-chal = (1: bstr)
token-bundle = (2: bstr)
key-auth-digest = (3: [
alg: alg-id,
value: bstr
])
alg-list = (4: [+ alg-id])
; From the IANA COSE registry, only hash algorithms allowed
alg-id = tstr / int
This example is a Bundle exchange for the ACME server with Node ID "dtn://acme-server/" performing a verification for ACME client Node ID "dtn://acme-client/". The example Bundles use no block CRC or BPSec integrity, which is for simplicity and is not recommended for normal use. The provided figures are extended diagnostic notation [RFC8610].
この例は、ノード ID「dtn://acme-server/」を持つ ACME サーバーのバンドル交換で、ACME クライアント ノード ID「dtn://acme-client/」の検証を実行します。バンドルの例では、ブロック CRC または BPSec の整合性を使用していません。これは簡略化のためであり、通常の使用には推奨されません。提供される図は拡張診断表記 [RFC8610] です。
For this example, the ACME client key thumbprint has the base64url-encoded value of:
この例では、ACME クライアント キーの拇印には、base64url でエンコードされた次の値があります。
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
and the ACME-server generated token-chal has the base64url-encoded value of:
ACME サーバーが生成した token-chal には、base64url でエンコードされた次の値があります。
"tPUZNY4ONIk6LxErRFEjVw"
For the single Challenge Bundle in this example, the token-bundle (transported as byte string via BP) has the base64url-encoded value of:
この例の単一のチャレンジ バンドルの場合、トークン バンドル (BP 経由でバイト文字列として転送される) には、base64url でエンコードされた次の値があります。
"p3yRYFU4KxwQaHQjJ2RdiQ"
The minimal-but-valid Challenge Bundle is shown in Figure 2. This challenge requires that the ACME client respond within a 60-second time window.
最小限だが有効なチャレンジ バンドルを図 2 に示します。このチャレンジでは、ACME クライアントが 60 秒の時間枠内に応答する必要があります。
[_
[
7, / BP version /
0x22, / flags: user-app-ack, payload-is-an-admin-record /
0, / CRC type: none /
[1, "//acme-client/"], / destination /
[1, "//acme-server/"], / source /
[1, 0], / report-to: none /
[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
60000 / lifetime: 60s /
],
[
1, / block type code /
1, / block number /
0, / flags /
0, / CRC type: none /
<<[ / type-specific data /
0xFF, / record-type-code /
{ / record-content /
1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
4: [-16] / alg-list: SHA-256 /
}
]>>
]
]
Figure 2: Example Challenge Bundle
図 2: チャレンジ バンドルの例
When the tokens are combined with the key thumbprint, the full Key Authorization value is the following, folded across lines for readability using the "single backslash" strategy of Section 7 of [RFC8792].
トークンが鍵の拇印と結合される場合、完全な鍵認証値は次のようになります。これは、[RFC8792] のセクション 7 の「単一のバックスラッシュ」戦略を使用して、読みやすくするために複数の行にわたって折り畳まれています。
/ NOTE: '\' line wrapping per RFC 8792 /
"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.\
LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
The minimal-but-valid Response Bundle is shown in Figure 3. This response indicates that there are 30 seconds remaining in the response time window.
最小限だが有効な応答バンドルを図 3 に示します。この応答は、応答時間枠が 30 秒残っていることを示しています。
[_
[
7, / BP version /
0x02, / flags: payload-is-an-admin-record /
0, / CRC type: none /
[1, "//acme-server/"], / destination /
[1, "//acme-client/"], / source /
[1, 0], / report-to: none /
[1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /
30000 / lifetime: 30s /
],
[
1, / block type code /
1, / block number /
0, / flags /
0, / CRC type: none /
<<[ / block-type-specific data /
0xFF, / record-type-code /
{ / record-content /
1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
3: [-16, b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew']
/ SHA-256 key auth. digest /
}
]>>
]
]
Figure 3: Example Response Bundle
図 3: 応答バンドルの例
This specification is based on DTN use cases related to PKIX certificate issuance.
この仕様は、PKIX 証明書の発行に関連する DTN の使用例に基づいています。
The workflow and terminology of this validation method were originally copied from the work of Alexey Melnikov for email validation [RFC8823].
この検証方法のワークフローと用語は、もともと電子メール検証のための Alexey Melnikov の著作 [RFC8823] からコピーされたものです。
Brian Sipos
RKF Engineering Solutions, LLC
7500 Old Georgetown Road
Suite 1275
Bethesda, MD 20814-6198
United States of America
Email: brian.sipos+ietf@gmail.com