Internet Engineering Task Force (IETF) A. Wiethuechter, Ed.
Request for Comments: 9886 AX Enterprize, LLC
Category: Standards Track J. Reid
ISSN: 2070-1721 RTFM llp
December 2025
This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote Identification and other services.
この文書は、Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME) のドメイン ネーム システム (DNS) 機能を定義します。これは、DRIP エンティティ タグ (DET) を中心に構築されており、階層型レジストリ構造と関連プロセスを標準化し、信頼性が高くスケーラブルな無人航空機システム (UAS) に関連する情報の登録と検索を容易にします。レジストリ システムは、DET の発行、発見、検証をサポートし、UAS とそのオペレーターの安全な識別と関連付けを可能にします。また、さまざまなクラスのレジストリ (ルート、組織、個人) 間の相互作用と、登録データの整合性を維持する際のそれぞれの役割も定義します。このアーキテクチャにより、UAS リモート識別やその他のサービスのコンテキストにおけるプライバシー、トレーサビリティ、および法規制遵守要件をサポートしながら、分散型のフェデレーション運用が可能になります。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9886.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9886 で入手できます。
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. General Concept
1.2. Scope
2. Terminology
2.1. Required Terminology
2.2. Additional Definitions
3. DET Hierarchy in DNS
3.1. Use of Existing DNS Models
3.1.1. DNS Model Considerations for DIMEs
4. Public Information Registry
5. Resource Records
5.1. HHIT Resource Record
5.1.1. Text Representation
5.1.2. Field Descriptions
5.2. UAS Broadcast RID Resource Record
5.2.1. Text Representation
5.2.2. Field Descriptions
6. IANA Considerations
6.1. DET Prefix Delegation
6.2. IANA DRIP Registry
6.2.1. DRIP RAA Allocations
6.2.2. HHIT Entity Types
7. Security Considerations
7.1. DNS Operational and Registration Considerations
7.2. DET and Public Key Exposure
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Example Zone Files and RRType Contents
A.1. Example RAA
A.1.1. Authentication HHIT
A.1.2. Delegation of HDA
A.2. Example HDA
A.2.1. Authentication and Issue HHITs
A.2.2. Registrant HHIT and BRID
Acknowledgements
Authors' Addresses
Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information from RID is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 1, which is the same as Figure 4 of [RFC9434]).
レジストリは、無人航空機システム (UAS) の遠隔識別 (RID) の基礎です。ブロードキャスト RID 経由で送信できる運用情報は非常に限られていますが、拡張情報が必要になる場合があります。RID からの情報の最も重要な要素は、関連するレジストリ内の拡張情報を検索するための一意のキーである UAS ID です ([RFC9434] の図 4 と同じ図 1 を参照)。
*************** ***************
* UAS1 * * UAS2 *
* * * *
* +--------+ * DAA/V2V * +--------+ *
* | UA o--*----------------------------------------*--o UA | *
* +--o--o--+ * * +--o--o--+ *
* | | * +------+ Lookups +------+ * | | *
* | | * | GPOD o------. .------o PSOD | * | | *
* | | * +------+ | | +------+ * | | *
* | | * | | * | | *
* C2 | | * V2I ************ V2I * | | C2 *
* | '-----*--------------* *--------------*-----' | *
* | * * * * | *
* | o====Net-RID===* *====Net-RID===o | *
* +--o--+ * * Internet * * +--o--+ *
* | GCS o-----*--------------* *--------------*-----o GCS | *
* +-----+ * Registration * * Registration * +-----+ *
* * (and UTM) * * (and UTM) * *
*************** ************ ***************
| | |
+----------+ | | | +----------+
| Public o---' | '---o Private |
| Registry | | | Registry |
+----------+ | +----------+
+--o--+
| DNS |
+-----+
DAA: Detect And Avoid
GPOD: General Public Observer Device
PSOD: Public Safety Observer Device
V2I: Vehicle-to-Infrastructure
V2V: Vehicle-to-Vehicle
Figure 1: Global UAS RID Usage Scenario (Figure 4 of RFC 9434)
図 1: グローバル UAS RID 使用シナリオ (RFC 9434 の図 4)
When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID, extended information can be retrieved from a DRIP Identity Management Entity (DIME), which manages registration of and associated lookups from DETs. In this document it is assumed the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), but a DIME can be independent or handled by another entity as well.
DRIP エンティティ タグ (DET) [RFC9374] が RID の UAS ID として使用される場合、拡張情報は、DET の登録および DET からの関連ルックアップを管理する DRIP アイデンティティ管理エンティティ (DIME) から取得できます。この文書では、DIME が UAS サービス サプライヤー (USS) ([RFC9434] の付録 A.2) の機能であると仮定しますが、DIME は独立していることも、別のエンティティによって処理されることもできます。
DRIP Entity Tags (DETs) embed a hierarchy scheme that is mapped onto the Domain Name System (DNS) [STD13]. DIMEs enforce registration and information access of data associated with a DET while also providing the trust inherited from being a member of the hierarchy. Other identifiers and their methods are out of scope for this document.
DRIP エンティティ タグ (DET) には、ドメイン ネーム システム (DNS) [STD13] にマッピングされる階層スキームが埋め込まれています。DIME は、DET に関連付けられたデータの登録と情報アクセスを強制すると同時に、階層のメンバーであることから継承された信頼も提供します。他の識別子とそのメソッドは、このドキュメントの範囲外です。
Authoritative name servers of the DNS provide the public information such as the cryptographic keys, endorsements and certificates of DETs, and pointers to private information resources. Cryptographic (public) keys are used to authenticate anything signed by a DET, such as in the Authentication Messages defined in [RFC9575] for Broadcast RID. Endorsements and certificates are used to endorse the claim of being part of the hierarchy.
DNS の権威ネーム サーバーは、暗号キー、DET の承認と証明書、およびプライベート情報リソースへのポインタなどの公開情報を提供します。暗号 (公開) キーは、ブロードキャスト RID の [RFC9575] で定義されている認証メッセージなど、DET によって署名されたものを認証するために使用されます。承認と証明書は、階層の一部であるという主張を承認するために使用されます。
This document does not specify AAA mechanisms used by Private Information Registries to store and protect Personally Identifiable Information (PII).
この文書では、個人情報レジストリが個人識別情報 (PII) を保存および保護するために使用する AAA メカニズムについては規定しません。
The scope of this document is the DNS registration of DETs with the DNS delegation of the reverse domain of the IPv6 prefix (2001:30::/28 for DETs) and RRsets used to handle DETs.
このドキュメントの範囲は、IPv6 プレフィックス (DET の場合は 2001:30::/28) の逆ドメインの DNS 委任による DET の DNS 登録と、DET の処理に使用される RRset です。
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 makes use of the terms and abbreviations from previous DRIP documents. Below are subsets, grouped by original document, of terms used this document. Please see those documents for additional context, definitions, and any further referenced material.
この文書では、以前の DRIP 文書の用語と略語が使用されています。以下は、この文書で使用されている用語のサブセットを元の文書ごとにグループ化したものです。追加のコンテキスト、定義、その他の参照資料については、これらのドキュメントを参照してください。
From Section 2.2 of [RFC9153], this document uses: AAA, CAA, GCS, ICAO, PII, Observer, Operator, UA, UAS, USS, and UTM.
[RFC9153] のセクション 2.2 より、この文書では AAA、CAA、GCS、ICAO、PII、オブザーバー、オペレーター、UA、UAS、USS、および UTM を使用します。
From Section 2 of [RFC9434], this document uses: Certificate, DIME, and Endorsement.
[RFC9434] のセクション 2 に基づいて、この文書では証明書、DIME、および承認を使用します。
From Section 2 of [RFC9374], this document uses: HDA, HID, and RAA.
[RFC9374] のセクション 2 から、この文書では HDA、HID、および RAA を使用します。
[RFC9374] defines the Hierarchical Host Identity Tags (HHIT) and further specifies an instance of them used for UAS RID called DET. The DET is a 128-bit value that is an IPv6 address intended primarily as an identifier rather than locator. The format is shown in Figure 2 and further information is in [RFC9374].
[RFC9374] は階層型ホスト識別タグ (HHIT) を定義し、さらに DET と呼ばれる UAS RID に使用されるそれらのインスタンスを指定します。DET は 128 ビット値で、ロケーターではなく主に識別子として使用される IPv6 アドレスです。フォーマットは図 2 に示されており、詳細情報は [RFC9374] にあります。
+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28 bits) | (28 bits) | (8 bits) | (64 bits) |
+-------------+--------------+---------------+-------------+
/ \
/ \
/ \-----------------------------\
/ \
/ \
+--------------------------------+-----------------------+
| Registered Assigning Authority | HHIT Domain Authority |
| (14 bits) | (14 bits) |
+--------------------------------+-----------------------+
Figure 2: DRIP Entity Tag Breakdown
図 2: DRIP エンティティ タグの内訳
[RFC9374] assigns the IPv6 prefix 2001:30::/28 for DETs. Its corresponding domain name for reverse lookups is 3.0.0.1.0.0.2.ip6.arpa.. The IAB has administrative control of this domain name.
[RFC9374] は、DET に IPv6 プレフィックス 2001:30::/28 を割り当てます。逆引き参照に対応するドメイン名は 3.0.0.1.0.0.2.ip6.arpa. です。IAB はこのドメイン名の管理制御を持っています。
Due to the nature of the hierarchy split and its relationship to nibble reversing of the IPv6 address (Section 2.5 of RFC 3596 [STD88]), the upper level of the hierarchy (i.e., Registered Assigning Authority (RAA)) "borrows" the upper two bits of their respective HHIT Domain Authority (HDA) space for DNS delegation. As such, the IPv6 prefix of RAAs is 2001:3x:xxx0::/44 and HDAs is 2001:3x:xxxy:yy00::/56 with respective nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa. and y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa..
階層分割の性質と、IPv6 アドレスのニブル反転 (RFC 3596 [STD88] のセクション 2.5) との関係により、階層の上位レベル (つまり、Registered Assigning Authority (RAA)) は、DNS 委任のためにそれぞれの HHIT Domain Authority (HDA) スペースの上位 2 ビットを「借用」します。したがって、RAA の IPv6 プレフィックスは 2001:3x:xxx0::/44、HDA は 2001:3x:xxxy:yy00::/56 で、それぞれのニブル逆方向ドメインは x.x.x.x.3.0.0.1.0.0.2.ip6.arpa です。および y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa..
This document preallocates a subset of RAAs based on the ISO 3166-1 Numeric Nation Code [ISO3166-1]. This is to support the initial use case of DETs in UAS RID on an international level. See Section 6.2.1 for the RAA allocations.
この文書は、ISO 3166-1 Numeric Nation Code [ISO3166-1] に基づいて RAA のサブセットを事前に割り当てます。これは、UAS RID における DET の初期ユースケースを国際レベルでサポートするためです。RAA の割り当てについては、セクション 6.2.1 を参照してください。
The HDA values of 0, 4096, 8192, and 12288 are reserved for operational use of an RAA (a by-product of the above mentioned borrowing of bits), in particular to specify when to register with the apex and endorse delegations of HDAs in their namespace.
HDA 値 0、4096、8192、および 12288 は、RAA (上記のビット借用の副産物) の運用上の使用のために予約されており、特に apex に登録する時期を指定し、名前空間内の HDA の委任を承認するために予約されています。
The administration, management, and policy for the operation of a DIME at any level in the hierarchy (Apex, RAA or HDA) is out of scope for this document. For RAAs or DETs allocated on a per-country basis, these considerations should be determined by the appropriate national authorities, presumably the Civil Aviation Authority (CAA).
階層内の任意のレベル (Apex、RAA、または HDA) での DIME の運用に関する管理、管理、およびポリシーは、このドキュメントの範囲外です。国ごとに割り当てられた RAA または DET の場合、これらの考慮事項は、適切な国内当局、おそらく民間航空局 (CAA) によって決定される必要があります。
DRIP relies on the DNS and as such roughly follows the registrant-registrar-registry model. In the UAS ecosystem, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting.
DRIP は DNS に依存しているため、登録者-レジストラー-レジストリ モデルにほぼ準拠しています。UAS エコシステムでは、登録者は無人航空機を所有/制御するエンド ユーザーになります。彼らは、DET および DNS で公開されるその他の情報に対して最終的な責任を負います。登録者は、レジストラと呼ばれるエージェントを使用して、レジストリとのやり取りを管理します。レジストラは通常、DNS ホスティングなどのオプションの追加サービスを提供します。
The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex, which contains delegation information for domain names. Registries generally provide services such as the Registration Data Access Protocol (RDAP) [STD95] or equivalent to publish metadata about the registered domain names and their registrants and registrars.
レジストリは、登録されたドメイン名と、ドメイン名所有者や関連レジストラの連絡先詳細などの関連メタデータのデータベースを維持します。レジストリは、ゾーンの頂点にドメイン名の委任情報を含む DNS サービスを提供します。レジストリは通常、登録データ アクセス プロトコル (RDAP) [STD95] などのサービス、または登録されたドメイン名とその登録者およびレジストラに関するメタデータを公開する同等のサービスを提供します。
Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services from a registrar who pays for services provided by the registry.
登録者はレジストラと契約を結び、レジストラもレジストリと契約を結びます。支払いもこのモデルに従います。登録者はレジストラからサービスを購入し、レジストラはレジストリが提供するサービスの料金を支払います。
By definition, there can only be one registry for a domain name. A registry can have an arbitrary number of registrars who compete with each other on price, service, and customer support.
定義上、1 つのドメイン名に対して存在できるレジストリは 1 つだけです。レジストリには、価格、サービス、カスタマー サポートに関して相互に競争する任意の数のレジストラを含めることができます。
Apex
Registry/Registrar
(IANA)
+=========================+
| 3.0.0.1.0.0.2.ip6.arpa. |
+============o============+
|
--------------------------------------|-------------------------
National |
Registries/Registrars |
(RAA) |
|
+--------------+--------------o-+---------------+
| | | |
+=====o====+ +====o=====+ +=====o====+ +=====o====+
| 0.0.0.0. | | 1.0.0.0. | | 2.0.0.0. | | 3.0.0.0. |
+====o=====+ +====o=====+ +====o=====+ +====o=====+
|
---------------------------------------|------------------------
Local |
Registries/Registrars |
(HDA) |
|
+--------------+---------------o--------...-----+
| | | |
+=====o====+ +====o=====+ +====o=====+ +=====o====+
| 1.0.0. | | 2.0.0. | | 3.0.0. | | f.f.f. |
+====o=====+ +=====o====+ +====o=====+ +====o=====+
|
---------------------------------------|------------------------
Local |
Registrants |
+=====================o================+
| x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.5.0. |
+======================================+
Figure 3: Example DRIP DNS Model
図 3: DRIP DNS モデルの例
While the registrant-registrar-registry model is mature and well understood, it may not be appropriate for DRIP registrations in some circumstances. It could add costs and complexity to develop policies and contracts as outlined above. On the other hand, registries and registrars offer customer service and support and can provide the supporting infrastructure for reliable DNS and RDAP service.
登録者-レジストラ-レジストリ モデルは成熟しており、よく理解されていますが、状況によっては DRIP 登録には適切ではない場合があります。上で概説したポリシーや契約の作成にコストがかかり、複雑さが増す可能性があります。一方、レジストリとレジストラは顧客サービスとサポートを提供し、信頼性の高い DNS および RDAP サービスのサポート インフラストラクチャを提供できます。
Another approach could be to handle DRIP registrations in a comparable way to how IP address space gets provisioned. Here, blocks of addresses get delegated to a "trusted" third party, typically an ISP, who then issues IP addresses to its customers. For DRIP, blocks of IP addresses could be delegated from the 3.0.0.1.0.0.2.ip6.arpa. domain (reverse domain of prefix allocated by [RFC9374]) to an entity chosen by the appropriate Civil Aviation Authority (CAA). This third party would be responsible for the corresponding DNS and RDAP infrastructure for these IP address blocks. They would also provision the HHIT records [RFC9374] for these IP addresses. In principle, a manufacturer or vendor of UAS devices could provide that role. This is shown as an example in Figure 3.
もう 1 つのアプローチは、IP アドレス空間がプロビジョニングされる方法と同様の方法で DRIP 登録を処理することです。ここでは、アドレスのブロックが「信頼できる」サードパーティ (通常は ISP) に委任され、そのサードパーティが顧客に IP アドレスを発行します。DRIP の場合、IP アドレスのブロックは 3.0.0.1.0.0.2.ip6.arpa から委任できます。適切な民間航空局 (CAA) によって選択されたエンティティにドメイン ([RFC9374] によって割り当てられたプレフィックスの逆ドメイン) を割り当てます。このサードパーティは、これらの IP アドレス ブロックに対応する DNS および RDAP インフラストラクチャを担当します。また、これらの IP アドレスに対して HHIT レコード [RFC9374] もプロビジョニングします。原則として、UAS デバイスのメーカーまたはベンダーがその役割を提供できます。これを図 3 に例として示します。
Dynamic DRIP registration is another possible solution, for example when the operator of a UAS device registers its corresponding HHIT record and other resources before a flight and deletes them afterwards. This may be feasible in controlled environments with well-behaved actors. However, this approach may not scale since each device is likely to need credentials for updating the IT infrastructure that provisions the DNS.
動的 DRIP 登録は、たとえば、UAS デバイスのオペレーターが対応する HHIT レコードおよびその他のリソースを飛行前に登録し、その後それらを削除する場合などに考えられるもう 1 つの解決策です。これは、行儀の良いアクターがいる制御された環境では実現可能かもしれません。ただし、各デバイスは DNS をプロビジョニングする IT インフラストラクチャを更新するために認証情報を必要とする可能性が高いため、このアプローチは拡張できない可能性があります。
Registration policies (pricing, renewals, registrar, and registrant agreements, etc.) will need to be developed. These considerations should be determined by the CAA, perhaps in consultation with local stakeholders to assess the cost-benefits of these approaches (and others). All of these are out of scope for this document. The specifics for the UAS RID use case are detailed in the rest of document.
登録ポリシー (価格設定、更新、レジストラと登録者の契約など) を策定する必要があります。これらの考慮事項は、CAA によって決定されるべきであり、おそらく地元の関係者と協議して、これらのアプローチ (およびその他) の費用対効果を評価する必要があります。これらはすべて、このドキュメントの範囲外です。UAS RID の使用例の詳細については、ドキュメントの残りの部分で詳しく説明します。
Per [RFC9434], all information classified as public is stored in the DNS, specifically authoritative name servers, to satisfy REG-1 from [RFC9153].
[RFC9434] に従って、[RFC9153] の REG-1 を満たすために、パブリックとして分類されたすべての情報は DNS、特に権威ネーム サーバーに保存されます。
Authoritative name servers use domain names as identifiers and data is stored in Resource Records (RRs) with associated RRTypes. This document defines two new RRTypes, one for HHIT metadata (HHIT, Section 5.1) and another for UAS Broadcast RID information (BRID, Section 5.2). The former RRType is particularly important as it contains a URI (as part of the certificate) that points to Private Information resources.
権威ネーム サーバーはドメイン名を識別子として使用し、データは関連する RRType とともにリソース レコード (RR) に保存されます。この文書は 2 つの新しい RRType を定義します。1 つは HHIT メタデータ用 (HHIT、セクション 5.1)、もう 1 つは UAS ブロードキャスト RID 情報 (BRID、セクション 5.2) 用です。前者の RRType は、個人情報リソースを指す URI (証明書の一部として) を含むため、特に重要です。
DETs, being IPv6 addresses, are to be under ip6.arpa. (nibble reversed per Section 2.5 of RFC 3596 [STD88]) and MUST resolve to an HHIT RRType. Depending on local circumstances or additional use cases, other RRTypes MAY be present (for example the inclusion of the DS RRTypes or equivalent when using DNSSEC). For UAS RID, the BRID RRType MUST be present to provide the Broadcast Endorsements (BEs) defined in Section 3.1.2.1 of [RFC9575].
DET は IPv6 アドレスであり、ip6.arpa の下に置かれます。(RFC 3596 [STD88] のセクション 2.5 に従ってニブル反転)、HHIT RRType に解決されなければなりません。ローカルの状況または追加の使用例に応じて、他の RRType が存在してもよい (たとえば、DNSSEC を使用する場合の DS RRType または同等のものが含まれる)。UAS RID の場合、[RFC9575] のセクション 3.1.2.1 で定義されているブロードキャストエンドースメント (BE) を提供するために、BRID RRType が存在しなければなりません (MUST)。
DNSSEC MUST be used for apex entities (those which use a self-signed Canonical Registration Certificate) and is RECOMMENDED for other entities. When a DIME decides to use DNSSEC, they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by the frequency of updates, size of the zone, and policies.
DNSSEC は、頂点エンティティ (自己署名正規登録証明書を使用するエンティティ) に使用しなければならず (MUST)、他のエンティティにも使用することが推奨されます。DIME が DNSSEC を使用することを決定した場合、暗号アルゴリズムと鍵管理のフレームワークを定義する必要があります [RFC6841]。これは、更新の頻度、ゾーンのサイズ、およびポリシーの影響を受ける可能性があります。
UAS-specific information, such as physical characteristics, may also be stored in DNS but is out of scope for this document.
物理的特性などの UAS 固有の情報も DNS に保存される場合がありますが、このドキュメントの範囲外です。
A DET IPv6 address gets mapped into domain names using the scheme defined in Section 2.5 of RFC 3596 [STD88]. However, DNS lookups of these names query for HHIT and/or BRID resource records rather than the PTR resource records conventionally used in reverse lookups of IP addresses. For example, the HHIT resource record for the DET 2001:30::1 would be returned from a DNS lookup for the HHIT QTYPE for 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.a rpa..
DET IPv6 アドレスは、RFC 3596 [STD88] のセクション 2.5 で定義されているスキームを使用してドメイン名にマッピングされます。ただし、これらの名前の DNS ルックアップでは、IP アドレスの逆引きで従来使用されていた PTR リソース レコードではなく、HHIT および/または BRID リソース レコードがクエリされます。たとえば、DET 2001:30::1 の HHIT リソース レコードは、1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.a rpa. の HHIT QTYPE の DNS ルックアップから返されます。
The HHIT RRType provides the public key for signature verification and URIs via the certificate. The BRID RRType provides static Broadcast RID information such as the Broadcast Endorsements sent as described in [RFC9575].
HHIT RRType は、証明書を介して署名検証用の公開キーと URI を提供します。BRID RRType は、[RFC9575] で説明されているように送信されるブロードキャスト エンドースメントなどの静的なブロードキャスト RID 情報を提供します。
The HHIT Resource Record (HHIT, RRType 67) is a metadata record for various bits of HHIT-specific information that isn't available in the pre-existing HIP RRType. The HHIT RRType does not replace the HIP RRType [RFC8005]. The primary advantage of the HHIT RRType over the existing RRType is the mandatory inclusion of the Canonical Registration Certificate containing an entity's public key signed by the registrar, or other trust anchor, to confirm registration.
HHIT リソース レコード (HHIT、RRType 67) は、既存の HIP RRType では利用できない HHIT 固有の情報のさまざまなビットのメタデータ レコードです。HHIT RRType は HIP RRType [RFC8005] を置き換えるものではありません。既存の RRType に対する HHIT RRType の主な利点は、登録を確認するために、レジストラまたは他のトラスト アンカーによって署名されたエンティティの公開キーを含む正規登録証明書が必須であることです。
The data MUST be encoded in the Concise Binary Object Representation (CBOR) [RFC8949] bytes. The Concise Data Definition Language (CDDL) [RFC8610] of the data is provided in Figure 4.
データは、Concise Binary Object Representation (CBOR) [RFC8949] バイトでエンコードされなければなりません (MUST)。データの簡潔データ定義言語 (CDDL) [RFC8610] を図 4 に示します。
The data are represented in base64 [RFC4648] and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields but these do not appear in the zone file representation; only a single logical base64 string will appear.
データはbase64 [RFC4648]で表現され、空白で区切られた任意の数の部分文字列(base64の単一桁まで)に分割でき、これらを連結して完全なオブジェクトを取得します。これらの部分文字列は、標準のかっこを使用して複数行にまたがることができます。データには内部サブフィールドがありますが、これらはゾーン ファイル表現には表示されないことに注意してください。単一の論理 Base64 文字列のみが表示されます。
The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610].
データは、表示のみを目的として、[RFC8610] の付録 G で定義されている拡張診断表記法を使用して表すことができます (MAY)。
hhit-rr = [
hhit-entity-type: uint,
hid-abbreviation: tstr .size(15),
canonical-registration-cert: bstr
]
Figure 4: HHIT Wire Format CDDL
図 4: HHIT ワイヤ形式 CDDL
All fields of the HHIT RRType MUST be included to be properly formed.
適切に形成するには、HHIT RRType のすべてのフィールドを含める必要があります。
HHIT Entity Type:
HHIT エンティティ タイプ:
The HHIT Entity Type field is a number with values defined in Section 6.2.2. It is envisioned that there may be many types of HHITs in use. In some cases, it may be helpful to understand the role of the HHITs in the ecosystem, like that described in [drip-dki]. This field provides such context. This field MAY provide a signal of additional information and/or different handling of the data beyond what is defined in this document.
HHIT エンティティ タイプ フィールドは、セクション 6.2.2 で定義された値を持つ数値です。多くの種類の HHIT が使用されていることが想定されます。場合によっては、[drip-dki] で説明されているように、エコシステムにおける HHIT の役割を理解することが役立つ場合があります。このフィールドはそのようなコンテキストを提供します。このフィールドは、この文書で定義されているものを超える追加情報および/またはデータの異なる処理の信号を提供してもよい(MAY)。
HID Abbreviation:
HIDの略称:
The HID Abbreviation field is a string that provides an abbreviation to the HID (Hierarchy ID) structure of a DET for display devices. The convention for such abbreviations is a matter of local policy. Absent of such a policy, this field MUST be filled with the four character hexadecimal representations of the RAA and HDA (in that order) with a separator character, such as a space, in between. For example, a DET with an RAA value of 10 and HDA value of 20 would be abbreviated as: 000A 0014.
HID Abbreviation フィールドは、表示デバイスの DET の HID (階層 ID) 構造の省略形を提供する文字列です。このような略語の規則は、ローカル ポリシーの問題です。このようなポリシーがない場合、このフィールドには、RAA と HDA の 4 文字の 16 進表現を (この順序で) スペースなどの区切り文字を挟んで入力しなければなりません (MUST)。たとえば、RAA 値が 10、HDA 値が 20 の DET は、000A 0014 と省略されます。
Canonical Registration Certificate:
正規登録証明書:
The Canonical Registration Certificate field is for a certificate-endorsing registration of the DET. It MUST be encoded as X.509 DER [RFC5280]. This certificate MAY be self-signed when the entity is acting as a root of trust (i.e., an apex). Such self-signed behavior is defined by policy, such as in [drip-dki], and is out of scope for this document. This certificate is part of a chain of certificates that can be used to validate inclusion in the hierarchy.
Canonical Registration Certificate フィールドは、DET の証明書承認登録用です。X.509 DER [RFC5280] としてエンコードされなければなりません (MUST)。エンティティが信頼のルート (つまり、頂点) として機能する場合、この証明書は自己署名されてもよい(MAY)。このような自己署名動作は、[drip-dki] などのポリシーによって定義されており、このドキュメントの範囲外です。この証明書は、階層に含まれていることを検証するために使用できる証明書チェーンの一部です。
The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format to hold information typically sent over UAS Broadcast RID that is static. It can act as a data source if information is not received over Broadcast RID or for cross validation. The primary function for DRIP is to include of one or more Broadcast Endorsements as defined in [RFC9575] in the auth field. These Endorsements are generated by the registrar upon successful registration and broadcast by the entity.
UAS ブロードキャスト RID リソース レコード (BRID、RRType 68) は、通常は静的な UAS ブロードキャスト RID を介して送信される情報を保持するための形式です。情報がブロードキャスト RID 経由で受信されない場合、または相互検証のためにデータ ソースとして機能します。DRIP の主な機能は、[RFC9575] で定義されている 1 つ以上のブロードキャスト承認を認証フィールドに含めることです。これらの承認は、登録が成功するとレジストラによって生成され、エンティティによってブロードキャストされます。
The data MUST be encoded in CBOR [RFC8949] bytes. The CDDL [RFC8610] of the data is provided in Figure 5.
データは CBOR [RFC8949] バイトでエンコードされなければなりません (MUST)。データの CDDL [RFC8610] を図 5 に示します。
The data are represented in base64 [RFC4648] and may be divided into any number of white-space-separated substrings, down to single base64 digits, which are concatenated to obtain the full object. These substrings can span lines using the standard parenthesis. Note that the data has internal subfields but these do not appear in the zone file representation; only a single logical base64 string will appear.
データはbase64 [RFC4648]で表現され、空白で区切られた任意の数の部分文字列(base64の単一桁まで)に分割でき、それらを連結して完全なオブジェクトを取得します。これらの部分文字列は、標準のかっこを使用して複数行にまたがることができます。データには内部サブフィールドがありますが、これらはゾーン ファイル表現には表示されないことに注意してください。単一の論理 Base64 文字列のみが表示されます。
The data MAY, for display purposes only, be represented using the Extended Diagnostic Notation as defined in Appendix G of [RFC8610]. All byte strings longer than a length of 20 SHOULD be displayed as base64 when possible.
データは、表示のみを目的として、[RFC8610] の付録 G で定義されている拡張診断表記法を使用して表すことができます (MAY)。長さ 20 を超えるすべてのバイト文字列は、可能な場合は Base64 として表示されるべきです(SHOULD)。
bcast-rr = {
uas_type => nibble-field,
uas_ids => [+ uas-id-grp],
? auth => [+ auth-grp],
? self_id => self-grp,
? area => area-grp,
? classification => classification-grp,
? operator_id => operator-grp
}
uas-id-grp = [
id_type: &uas-id-types,
uas_id: bstr .size(20)
]
auth-grp = [
a_type: &auth-types,
a_data: bstr .size(1..362)
]
area-grp = [
area_count: 1..255,
area_radius: float, # in decameters
area_floor: float, # wgs84-hae in meters
area_ceiling: float # wgs84-hae in meters
]
classification-grp = [
class_type: 0..8,
class: nibble-field,
category: nibble-field
]
self-grp = [
desc_type: 0..255,
description: tstr .size(23)
]
operator-grp = [
operator_id_type: 0..255,
operator_id: bstr .size(20)
]
uas-id-types = (none: 0, serial: 1, session_id: 4)
auth-types = (none: 0, specific_method: 5)
nibble-field = 0..15
uas_type = 0
uas_ids = 1
auth = 2
self_id = 3
area = 4
classification = 5
operator_id = 6
Figure 5: BRID Wire Format CDDL
図 5: BRID ワイヤ形式の CDDL
The field names and their general typing are taken from the ASTM data dictionary (Tables 1 and 2) [F3411]. See that document for additional context and background information on aviation application-specific interpretation of the field semantics. The explicitly enumerated values included in the CDDL above are relevant to DRIP for its operation. Other values may be valid but are outside the scope of DRIP operation. Application-specific fields, such as UAS Type, are transported and authenticated by DRIP but are regarded as opaque user data to DRIP.
フィールド名とその一般的な型付けは、ASTM データ ディクショナリ (表 1 および 2) [F3411] から取得されます。航空アプリケーション固有のフィールド セマンティクスの解釈に関する追加のコンテキストと背景情報については、そのドキュメントを参照してください。上記の CDDL に含まれる明示的に列挙された値は、DRIP の動作に関連します。他の値も有効である可能性がありますが、DRIP 操作の範囲外です。UAS タイプなどのアプリケーション固有のフィールドは、DRIP によって転送および認証されますが、DRIP にとっては不透明なユーザー データとみなされます。
The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa., is managed by IANA. IANA will liaise, as needed, with the International Civil Aviation Organization (ICAO) to verify the authenticity of delegations to CAAs (see Section 6.2.1.4).
DET プレフィックスの逆ドメイン、つまり 3.0.0.1.0.0.2.ip6.arpa. は IANA によって管理されています。IANA は必要に応じて国際民間航空機関 (ICAO) と連絡を取り、CAA への代表団の信頼性を検証します (セクション 6.2.1.4 を参照)。
IANA has created the registry for RAA Allocations under the "Drone Remote ID Protocol" registry group <https://www.iana.org/assignments/ drip>.
IANA は、「Drone Remote ID Protocol」レジストリ グループ <https://www.iana.org/assignments/drip> の下に RAA 割り当て用のレジストリを作成しました。
RAA Allocations:
RAA の割り当て:
a 14-bit value used to represent RAAs. Future additions to this registry are to be made based on the following range and policy table:
RAA を表すために使用される 14 ビット値。このレジストリへの将来の追加は、次の範囲とポリシーの表に基づいて行われます。
+===========+======================+================================+
| RAA Range | Allocation | Policy |
+===========+======================+================================+
| 0 - 3 | Reserved | |
+-----------+----------------------+--------------------------------+
| 4 - 3999 | ISO 3166-1 | IESG Approval (Section 4.10 of |
| | Countries | [RFC8126]), Section 6.2.1.4 |
+-----------+----------------------+--------------------------------+
| 4000 - | Reserved | |
| 8191 | | |
+-----------+----------------------+--------------------------------+
| 8192 - | Unassigned | First Come First Served |
| 15359 | | (Section 4.4 of [RFC8126]) |
+-----------+----------------------+--------------------------------+
| 15360 - | Private | Private Use (Section 4.1 of |
| 16383 | Use | [RFC8126]), Section 6.2.1.5 |
+-----------+----------------------+--------------------------------+
Table 1: RAA Ranges
表 1: RAA 範囲
Value:
値：
The RAA value delegated for this entry.
このエントリに委任された RAA 値。
Name:
名前：
Name of the delegated RAA. For the ISO 3166-1 Countries (Section 6.2.1.4), this should be the name of the country.
委任された RAA の名前。ISO 3166-1 の国 (セクション 6.2.1.4) の場合、これは国の名前である必要があります。
Reference:
参照：
A publicly accessible link to the policy requirements for prospective HDA operators to register under this RAA. This field is OPTIONAL.
将来の HDA オペレーターがこの RAA に基づいて登録するためのポリシー要件への公的にアクセス可能なリンク。このフィールドはオプションです。
Contact:
接触：
Contact details of the administrator of this RAA that prospective HDA operators can make informational queries to.
将来の HDA オペレーターが情報の問い合わせを行うことができる、この RAA の管理者の連絡先の詳細。
Value:
Name:
Reference:
Contact:
NS RRType Content (HDA=0):
NS RRType Content (HDA=4096):
NS RRType Content (HDA=8192):
NS RRType Content (HDA=12288):
Figure 6: RAA Delegation Request Form
図 6: RAA 委任リクエストフォーム
The NS RRType Content (HDA=X) fields are used by IANA to perform the DNS delegations under 3.0.0.1.0.0.2.ip6.arpa.. See Section 6.2.1.3 for technical details.
NS RRType Content (HDA=X) フィールドは、3.0.0.1.0.0.2.ip6.arpa. に基づいて DNS 委任を実行するために IANA によって使用されます。技術的な詳細については、セクション 6.2.1.3 を参照してください。
To support DNS delegation in 3.0.0.1.0.0.2.ip6.arpa., a single RAA is given 4 delegations by borrowing the upper two bits of HDA space (see Figure 7 for an example). This enables a clean nibble boundary in the DNS to delegate from (i.e., the prefix 2001:3x:xxx0::/44). These HDAs (0, 4096, 8192 and 12288) are reserved for the RAA.
3.0.0.1.0.0.2.ip6.arpa. で DNS 委任をサポートするために、HDA スペースの上位 2 ビットを借用することにより、単一の RAA に 4 つの委任が与えられます (例については、図 7 を参照)。これにより、DNS 内のクリーンなニブル境界を委任できるようになります (つまり、プレフィックス 2001:3x:xxx0::/44)。これらの HDA (0、4096、8192、および 12288) は RAA 用に予約されています。
7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | x | RAA=16376 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | 0 | 0 | 0 | E | F | F HDA=0,x=00
0 | 0 | 0 | 1 | E | F | F HDA=4096,x=01
0 | 0 | 0 | 2 | E | F | F HDA=8192,x=10
0 | 0 | 0 | 3 | E | F | F HDA=12288,x=11
Figure 7: Example Bit Borrowing of RAA=16376
図 7: RAA=16376 のビット借用の例
The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified and documented by IANA. Each Nation is assigned 4 RAAs that are left to the national authority for their purpose. For RAAs under this range, a shorter prefix of 2001:3x:xx00::/40 MAY be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs) assigned to them.
ISO 3166-1 数値国家コードと RAA 間のマッピングは、IANA によって指定および文書化されています。各国家には 4 つの RAA が割り当てられ、その目的は国家当局に委ねられています。この範囲内の RAA の場合、2001:3x:xx00::/40 という短いプレフィックスが各 CAA に委任されてもよく、これは各 CAA に割り当てられた 4 つの RAA (および予約された HDA) をすべてカバーします。
The registration policy for this range is set to IESG Approval (Section 4.10 of [RFC8126]) and IANA will liaise with the ICAO to verify the authenticity of delegation requests (using Figure 6) by CAAs.
この範囲の登録ポリシーは IESG 承認 ([RFC8126] のセクション 4.10) に設定されており、IANA は ICAO と連携して、CAA による委任要求 (図 6 を使用) の信頼性を検証します。
If nibble-reversed lookup in DNS is desired, it can only be provided by private DNS servers as zone delegations from the global root will not be performed for this address range. Thus the RAAs (with its subordinate HDAs) in this range may be used in like manner and IANA will not delegate any value in this range to any party (as per Private Use, Section 4.1 of [RFC8126]).
DNS でのニブル反転ルックアップが必要な場合は、グローバル ルートからのゾーン委任がこのアドレス範囲に対して実行されないため、プライベート DNS サーバーによってのみ提供できます。したがって、この範囲の RAA (その下位 HDA を含む) も同様の方法で使用でき、IANA はこの範囲の値をいかなる当事者にも委任しません ([RFC8126] の私的使用、セクション 4.1 に従って)。
One anticipated acceptable use of the private range is for experimentation and testing prior to request allocation or assignment from IANA.
プライベート範囲の想定される許容可能な用途の 1 つは、IANA からの割り当てまたは割り当てを要求する前の実験とテストです。
This document requests a new registry for HHIT Entity Types under the "Drone Remote ID Protocol" registry group <https://www.iana.org/assignments/drip>.
この文書では、「Drone Remote ID Protocol」レジストリ グループ <https://www.iana.org/assignments/drip> の下に HHIT エンティティ タイプ用の新しいレジストリを要求します。
HHIT Entity Type:
HHIT エンティティ タイプ:
Numeric, field of the HHIT RRType to encode the HHIT Entity Type. All entries in this registry are under the First Come First Served policy (Section 4.4 of [RFC8126]).
HHIT エンティティ タイプをエンコードする HHIT RRType の数値フィールド。このレジストリ内のすべてのエントリは、先着順ポリシー ([RFC8126] のセクション 4.4) に従っています。
Value:
値：
HHIT Type value of the entry.
HHIT エントリのタイプ値。
HHIT Type:
HHIT タイプ:
Name of the entry and an optional abbreviation.
エントリの名前とオプションの略語。
Reference:
参照：
Public document allocating the value and any additional information such as semantics. This can be a URL pointing to an Internet-Draft, IETF RFC, or web page among others.
値とセマンティクスなどの追加情報を割り当てる公開ドキュメント。これは、インターネット ドラフト、IETF RFC、または Web ページなどを指す URL にすることができます。
Value:
HHIT Type:
Reference:
Figure 8: HHIT Type Registration Form
図 8: HHIT タイプ登録フォーム
The following values are defined by this document:
この文書では次の値が定義されています。
+=======+===========================================+===========+
| Value | HHIT Type | Reference |
+=======+===========================================+===========+
| 0 | Not Defined | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 1 | DRIP Identity Management Entity (DIME) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 5 | Apex | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 9 | Registered Assigning Authority (RAA) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 13 | HHIT Domain Authority (HDA) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 16 | Unmanned Aircraft (UA) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 17 | Ground Control Station (GCS) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 18 | Unmanned Aircraft System (UAS) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 19 | Remote Identification (RID) Module | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 20 | Pilot | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 21 | Operator | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 22 | Discovery & Synchronization Service (DSS) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 23 | UAS Service Supplier (USS) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 24 | Network RID Service Provider (SP) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 25 | Network RID Display Provider (DP) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 26 | Supplemental Data Service Provider (SDSP) | RFC 9886 |
+-------+-------------------------------------------+-----------+
| 27 | Crowd Sourced RID Finder | RFC 9886 |
+-------+-------------------------------------------+-----------+
Table 2: HHIT Entity Type Initial Values
表 2: HHIT エンティティ タイプの初期値
The Registrar and Registry are commonly used concepts in the DNS. These components connect the DIME with the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate except when national regulations prevent it. [BCP237] provides suitable guidance.
レジストラとレジストリは、DNS で一般的に使用される概念です。これらのコンポーネントは DIME を DNS 階層に接続するため、国の規制がそれを妨げる場合を除き、運用は、特にセキュリティ (DNSSEC の実行など) において、必要に応じてベスト コモン プラクティスに従う必要があります。[BCP237] は適切なガイダンスを提供します。
If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. [RFC6841] documents a framework for DNSSEC policies and DNSSEC Practice Statements. A self-signed entity (i.e., an entity that self-signed its certificate as part of the HHIT RRType) MUST use DNSSEC.
DNSSEC を使用する場合は、DNSSEC 実践声明を作成し、公開する必要があります (SHOULD)。DNSSEC がどのように展開され、どのようなセキュリティ対策が講じられているかを説明する必要があります。[RFC6841] は、DNSSEC ポリシーと DNSSEC 実践声明のフレームワークを文書化しています。自己署名エンティティ (つまり、HHIT RRType の一部として証明書に自己署名したエンティティ) は、DNSSEC を使用しなければなりません (MUST)。
The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected that registry-registrar activity will use the Extensible Provisioning Protocol (EPP) [STD69] or equivalent. The registry SHOULD provide a lookup service such as RDAP [STD95] or equivalent to publish public information about registered domain names.
レジストリとレジストラの相互作用のためのインターフェイスとプロトコルの仕様は、この文書では意図的に指定されていません。これらは、国が定めた政策と一般的な地域の状況によって異なります。レジストリとレジストラ間のアクティビティでは、Extensible Provisioning Protocol (EPP) [STD69] または同等のものを使用することが予想されます。レジストリは、登録されたドメイン名に関する公開情報を公開するために、RDAP [STD95] または同等の検索サービスを提供する必要があります (SHOULD)。
Decisions about DNS or registry best practices and other operational matters that influence security SHOULD be made by the CAA, ideally in consultation with local stakeholders.
DNS やレジストリのベスト プラクティス、およびセキュリティに影響を与えるその他の運用上の問題に関する決定は、理想的には地元の利害関係者と協議して、CAA によって行われる必要があります (SHOULD)。
The guidance above is intended to reduce the likelihood of interoperability problems and minimize security and stability concerns. For instance, validation and authentication of DNS responses depends on DNSSEC. If this is not used, entities using DRIP will be vulnerable to DNS spoofing attacks and could be exposed to bogus data. DRIP DNS responses that have not been validated by DNSSEC could contain bogus data that have the potential to create serious security problems and operational concerns for DRIP entities. These threats include denial-of-service attacks, replay attacks, impersonation or cloning of UAVs, hijacking of DET registrations, injection of corrupt metadata, and compromising established trust architecture/relationships. Some regulatory and legal considerations are expected to be simplified by providing a lookup service for access to public information about registered domain names for DETs.
上記のガイダンスは、相互運用性の問題の可能性を軽減し、セキュリティと安定性に関する懸念を最小限に抑えることを目的としています。たとえば、DNS 応答の検証と認証は DNSSEC に依存します。これを使用しない場合、DRIP を使用するエンティティは DNS スプーフィング攻撃に対して脆弱になり、偽のデータにさらされる可能性があります。DNSSEC によって検証されていない DRIP DNS 応答には、DRIP エンティティに重大なセキュリティ上の問題や運用上の問題を引き起こす可能性のある偽のデータが含まれている可能性があります。これらの脅威には、サービス拒否攻撃、リプレイ攻撃、UAV のなりすましやクローン作成、DET 登録のハイジャック、破損したメタデータの挿入、確立された信頼アーキテクチャ/関係の侵害などが含まれます。DET の登録ドメイン名に関する公開情報にアクセスするための検索サービスを提供することにより、規制および法的考慮事項の一部が簡素化されることが期待されます。
When DNSSEC is not in use, due to the length of the ORCHID hash selected for DETs (Section 3.5 of [RFC9374]), clients MUST "walk" the tree of certificates locating each certificate by performing DNS lookups of HHIT RRTypes for each DET verifying inclusion into the hierarchy. The collection of these certificates (which provide both signature protection from the parent entity and the public key of the entity) is the only way without DNSSEC to prove valid registration.
DET に対して選択された ORCHID ハッシュの長さ ([RFC9374] のセクション 3.5) により、DNSSEC が使用されていない場合、クライアントは、階層への包含を検証する各 DET に対して HHIT RRType の DNS ルックアップを実行することにより、各証明書を見つける証明書ツリーを「ウォーク」しなければなりません (MUST)。これらの証明書 (親エンティティからの署名保護とエンティティの公開キーの両方を提供する) を収集することが、DNSSEC を使用せずに有効な登録を証明する唯一の方法です。
The contents of the BRID RRType auth key, containing Endorsements as described in Section 4.2 of [RFC9575], are a shadow of the X.509 certificate found in the HHIT RRType. The validation of these Endorsements follow the guidelines written in Section 6.4.2 of [RFC9575] for Broadcast RID Observers and when present MUST also be validated.
[RFC9575] のセクション 4.2 で説明されている承認を含む BRID RRType 認証キーの内容は、HHIT RRType にある X.509 証明書の影です。これらの承認の検証は、ブロードキャスト RID オブザーバー向けに [RFC9575] のセクション 6.4.2 に書かれたガイドラインに従い、存在する場合は検証されなければなりません (MUST)。
DETs are built upon asymmetric keys. As such the public key must be revealed to enable clients to perform signature verifications. [RFC9374] security considerations cover various attacks on such keys. While unlikely, the forging of a corresponding private key is possible if given enough time (and computational power).
DET は非対称キーに基づいて構築されます。したがって、クライアントが署名検証を実行できるようにするには、公開キーを公開する必要があります。[RFC9374] のセキュリティに関する考慮事項では、そのような鍵に対するさまざまな攻撃がカバーされています。可能性は低いですが、十分な時間 (および計算能力) が与えられれば、対応する秘密キーの偽造は可能です。
When practical, it is RECOMMENDED that no RRTypes under a DET's specific domain name be published unless and until it is required for use by other parties. Such action would cause at least the HHIT RRType to not be in the DNS, protecting the public key in the certificate from being exposed before its needed. The combination of this "just in time" publishing mechanism and DNSSEC is out of scope for this document.
現実的な場合は、他の当事者による使用が要求されるまで、DET の特定のドメイン名の RRType を公開しないことが推奨されます。このようなアクションにより、少なくとも HHIT RRType が DNS 内に存在しなくなり、証明書内の公開キーが必要になる前に公開されないよう保護されます。この「ジャストインタイム」公開メカニズムと DNSSEC の組み合わせは、このドキュメントの範囲外です。
Optimally this requires that the UAS somehow signal to the DIME that a flight using a Specific Session ID will soon be underway or complete. It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active.
最適には、UAS が、特定のセッション ID を使用するフライトが間もなく開始されるか完了することを何らかの方法で DIME に通知する必要があります。また、セッション ID を使用した特定の操作がアクティブになったときに USS (DIME である場合もそうでない場合もある) が信号を送信する場合、UTM で容易になる場合もあります。
[F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>.
[ISO3166-1]
ISO, "Codes for the representation of names of countries
and their subdivisions - Part 1: Country code",
ISO 3166-1:2020, August 2020,
<https://www.iso.org/standard/72482.html>.
[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>.
[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>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[BCP237] Best Current Practice 237,
<https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-drip-dki-09, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
dki-09>.
[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>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/info/rfc6841>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
2023, <https://www.rfc-editor.org/info/rfc9434>.
[RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag (DET) Authentication Formats and Protocols for
Broadcast Remote Identification (RID)", RFC 9575,
DOI 10.17487/RFC9575, June 2024,
<https://www.rfc-editor.org/info/rfc9575>.
[STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following:
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[STD69] Internet Standard 69,
<https://www.rfc-editor.org/info/std69>.
At the time of writing, this STD comprises the following:
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
August 2009, <https://www.rfc-editor.org/info/rfc5732>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734,
DOI 10.17487/RFC5734, August 2009,
<https://www.rfc-editor.org/info/rfc5734>.
[STD88] Internet Standard 88,
<https://www.rfc-editor.org/info/std88>.
At the time of writing, this STD comprises the following:
Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[STD95] Internet Standard 95,
<https://www.rfc-editor.org/info/std95>.
At the time of writing, this STD comprises the following:
Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
An example zone file ip6.arpa., run by IANA, is not shown. It would contain NS RRTypes to delegate to a respective RAA. To avoid any future collisions with production deployments an apex of ip6.example.com. is used instead of ip6.arpa.. All hexadecimal strings in the examples are broken into the lengths of a word, for document formatting purposes.
IANA によって実行されるゾーン ファイル ip6.arpa. の例は示されていません。これには、それぞれの RAA に委任する NS RRType が含まれます。実稼働デプロイメントとの将来の衝突を回避するために、ip6.example.com の頂点。ip6.arpa. の代わりに使用されます。文書の書式設定のために、例内のすべての 16 進文字列は単語の長さに分割されています。
An RAA with a HID of RAA=16376, HDA=0 and HDA with a the HID RAA=16376, HDA=10 were used in the examples.
この例では、RAA=16376、HDA=0 の HID を持つ RAA と、RAA=16376、HDA=10 の HID を持つ HDA が使用されました。
$ORIGIN 5.0.0.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
7.b.0.a.1.9.e.1.7.5.1.a.0.6.e.5. IN HHIT (
gwppM2ZmOCAwMDAwWQFGMIIBQjCB9aAD
AgECAgE1MAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
NTcxZTkxYTBiNzAeFw0yNTA0MDkyMDU2
MjZaFw0yNTA0MDkyMTU2MjZaMB0xGzAZ
BgNVBAMMEkRSSVAtUkFBLUEtMTYzNzYt
MDAqMAUGAytlcAMhAJmQ1bBLcqGAZtQJ
K1LH1JlPt8Fr1+jB9ED/qNBP8eE/o0ww
SjAPBgNVHRMBAf8EBTADAQH/MDcGA1Ud
EQEB/wQtMCuHECABAD/+AAAFXmChVx6R
oLeGF2h0dHBzOi8vcmFhLmV4YW1wbGUu
Y29tMAUGAytlcANBALUPjhIB3rwqXQep
r9/VDB+hhtwuWZIw1OUkEuDrF6DCkgc7
5widXnXa5/uDfdKL7dZ83mPHm2Tf32Dv
b8AzEw8=
)
Figure 9: RAA Auth HHIT RRType Example
図 9: RAA 認証 HHIT RRType の例
Figure 10 shows the CBOR decoded RDATA in the HHIT RRType found in Figure 9.
図 10 は、図 9 にある HHIT RRType 内の CBOR デコードされた RDATA を示しています。
[
10, # Reserved (RAA Auth from DKI)
"3ff8 0000",
h'308201423081F5A00302010202013530
0506032B6570302B312930270603550403
0C20323030313030336666653030303030
3535653630613135373165393161306237
301E170D3235303430393230353632365A
170D3235303430393231353632365A301D
311B301906035504030C12445249502D52
41412D412D31363337362D30302A300506
032B65700321009990D5B04B72A18066D4
092B52C7D4994FB7C16BD7E8C1F440FFA8
D04FF1E13FA34C304A300F0603551D1301
01FF040530030101FF30370603551D1101
01FF042D302B87102001003FFE0000055E
60A1571E91A0B7861768747470733A2F2F
7261612E6578616D706C652E636F6D3005
06032B6570034100B50F8E1201DEBC2A5D
07A9AFDFD50C1FA186DC2E599230D4E524
12E0EB17A0C292073BE7089D5E75DAE7FB
837DD28BEDD67CDE63C79B64DFDF60EF6F
C033130F'
]
Figure 10: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded HHIT RRType CBOR
図 10: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 デコードされた HHIT RRType CBOR
Figure 11 shows the decoded DER X.509 found in Figure 10.
図 11 は、図 10 で見つかったデコードされた DER X.509 を示しています。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 53 (0x35)
Signature Algorithm: ED25519
Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
Validity
Not Before: Apr 9 20:56:26 2025 GMT
Not After : Apr 9 21:56:26 2025 GMT
Subject: CN = DRIP-RAA-A-16376-0
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
99:90:d5:b0:4b:72:a1:80:66:d4:09:2b:52:c7:d4:
99:4f:b7:c1:6b:d7:e8:c1:f4:40:ff:a8:d0:4f:f1:
e1:3f
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:5:5E60:A157:1E91:A0B7,
URI:https://raa.example.com
Signature Algorithm: ED25519
Signature Value:
b5:0f:8e:12:01:de:bc:2a:5d:07:a9:af:df:d5:0c:1f:a1:86:
dc:2e:59:92:30:d4:e5:24:12:e0:eb:17:a0:c2:92:07:3b:e7:
08:9d:5e:75:da:e7:fb:83:7d:d2:8b:ed:d6:7c:de:63:c7:9b:
64:df:df:60:ef:6f:c0:33:13:0f
Figure 11: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 Decoded Certificate
図 11: 2001:3f:fe00:5:5e60:a157:1e91:a0b7 デコードされた証明書
$ORIGIN c.d.f.f.3.0.0.1.0.0.2.ip6.example.com.
a.0.0. IN NS ns1.hda-10.example.com
Figure 12: HDA Delegation Example
図 12: HDA 委任の例
$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
0.a.9.0.7.2.4.d.5.4.e.e.5.1.6.6.5.0. IN HHIT (
gw5pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
AgECAgFfMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwMDA1NWU2MGEx
NTcxZTkxYTBiNzAeFw0yNTA0MDkyMTAz
MTlaFw0yNTA0MDkyMjAzMTlaMB4xHDAa
BgNVBAMME0RSSVAtSERBLUEtMTYzNzYt
MTAwKjAFBgMrZXADIQDOaB424RQa61YN
bna8eWt7fLRU5GPMsfEt4wo4AQGAP6NM
MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV
HREBAf8ELTArhxAgAQA//gAKBWYV7kXU
JwmghhdodHRwczovL3JhYS5leGFtcGxl
LmNvbTAFBgMrZXADQQAhMpOSOmgMkJY1
f+B9nTgawUjK4YEERBtczMknHDkOowX0
ynbaLN60TYe9hqN6+CJ3SN8brJke3hpM
gorvhDkJ
)
8.2.e.6.5.2.b.6.7.3.4.d.e.0.6.2.5.0. IN HHIT (
gw9pM2ZmOCAwMDBhWQFHMIIBQzCB9qAD
AgECAgFYMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwYTA1NjYxNWVl
NDVkNDI3MDlhMDAeFw0yNTA0MDkyMTA1
MTRaFw0yNTA0MDkyMjA1MTRaMB4xHDAa
BgNVBAMME0RSSVAtSERBLUktMTYzNzYt
MTAwKjAFBgMrZXADIQCCM/2utQaLwUhZ
0ROg7fz43AeBTj3Sdl5rW4LgTQcFl6NM
MEowDwYDVR0TAQH/BAUwAwEB/zA3BgNV
HREBAf8ELTArhxAgAQA//gAKBSYO1Ddr
JW4ohhdodHRwczovL2hkYS5leGFtcGxl
LmNvbTAFBgMrZXADQQBa8lZyftxHJqDF
Vgv4Rt+cMUmc8aQwet4UZdO3yQOB9uq4
sLVAScaZCWjC0nmeRkgVRhize1esfyi3
RRU44IAE
)
Figure 13: HDA Auth/Issue HHIT RRType Example
図 13: HDA 認証/発行 HHIT RRType の例
Figure 14 shows the CBOR decoded RDATA in the HHIT RRType found in Figure 13.
図 14 は、図 13 にある HHIT RRType 内の CBOR デコードされた RDATA を示しています。
[
14, # Reserved (HDA Auth from DKI)
"3ff8 000a",
h'308201433081F6A00302010202015F30
0506032B6570302B312930270603550403
0C20323030313030336666653030303030
3535653630613135373165393161306237
301E170D3235303430393231303331395A
170D3235303430393232303331395A301E
311C301A06035504030C13445249502D48
44412D412D31363337362D3130302A3005
06032B6570032100CE681E36E1141AEB56
0D6E76BC796B7B7CB454E463CCB1F12DE3
0A380101803FA34C304A300F0603551D13
0101FF040530030101FF30370603551D11
0101FF042D302B87102001003FFE000A05
6615EE45D42709A0861768747470733A2F
2F7261612E6578616D706C652E636F6D30
0506032B6570034100213293923A680C90
96357FE07D9D381AC148CAE18104441B5C
CCC9271C390EA305F4CA76DA2CDEB44D87
BD86A37AF8227748DF1BAC991EDE1A4C82
8AEF843909'
]
Figure 14: 2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded HHIT RRType CBOR
図 14: 2001:3f:fe00:a05:6615:ee45:d427:9a0 デコードされた HHIT RRType CBOR
Figure 15 shows the decoded DER X.509 found in Figure 14.
図 15 は、図 14 で見つかったデコードされた DER X.509 を示しています。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 95 (0x5f)
Signature Algorithm: ED25519
Issuer: CN = 2001003ffe0000055e60a1571e91a0b7
Validity
Not Before: Apr 9 21:03:19 2025 GMT
Not After : Apr 9 22:03:19 2025 GMT
Subject: CN = DRIP-HDA-A-16376-10
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
ce:68:1e:36:e1:14:1a:eb:56:0d:6e:76:bc:79:6b:
7b:7c:b4:54:e4:63:cc:b1:f1:2d:e3:0a:38:01:01:
80:3f
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:6615:EE45:D427:9A0,
URI:https://raa.example.com
Signature Algorithm: ED25519
Signature Value:
21:32:93:92:3a:68:0c:90:96:35:7f:e0:7d:9d:38:1a:c1:48:
ca:e1:81:04:44:1b:5c:cc:c9:27:1c:39:0e:a3:05:f4:ca:76:
da:2c:de:b4:4d:87:bd:86:a3:7a:f8:22:77:48:df:1b:ac:99:
1e:de:1a:4c:82:8a:ef:84:39:09
Figure 15: 2001:3f:fe00:a05:6615:ee45:d427:9a0 Decoded Certificate
図 15: 2001:3f:fe00:a05:6615:ee45:d427:9a0 デコードされた証明書
Figure 16 shows the CBOR decoded RDATA in the HHIT RRType found in Figure 13.
図 16 は、図 13 にある HHIT RRType 内の CBOR デコードされた RDATA を示しています。
[
15, # Reserved (HDA Issue from DKI)
"3ff8 000a",
h'308201433081F6A00302010202015830
0506032B6570302B312930270603550403
0C20323030313030336666653030306130
3536363135656534356434323730396130
301E170D3235303430393231303531345A
170D3235303430393232303531345A301E
311C301A06035504030C13445249502D48
44412D492D31363337362D3130302A3005
06032B65700321008233FDAEB5068BC148
59D113A0EDFCF8DC07814E3DD2765E6B5B
82E04D070597A34C304A300F0603551D13
0101FF040530030101FF30370603551D11
0101FF042D302B87102001003FFE000A05
260ED4376B256E28861768747470733A2F
2F6864612E6578616D706C652E636F6D30
0506032B65700341005AF256727EDC4726
A0C5560BF846DF9C31499CF1A4307ADE14
65D3B7C90381F6EAB8B0B54049C6990968
C2D2799E4648154618B37B57AC7F28B745
1538E08004'
]
Figure 16: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded HHIT RRType CBOR
図 16: 2001:3f:fe00:a05:260e:d437:6b25:6e28 デコードされた HHIT RRType CBOR
Figure 17 shows the decoded DER X.509 found in Figure 16.
図 17 は、図 16 で見つかったデコードされた DER X.509 を示しています。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 88 (0x58)
Signature Algorithm: ED25519
Issuer: CN = 2001003ffe000a056615ee45d42709a0
Validity
Not Before: Apr 9 21:05:14 2025 GMT
Not After : Apr 9 22:05:14 2025 GMT
Subject: CN = DRIP-HDA-I-16376-10
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
82:33:fd:ae:b5:06:8b:c1:48:59:d1:13:a0:ed:fc:
f8:dc:07:81:4e:3d:d2:76:5e:6b:5b:82:e0:4d:07:
05:97
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:260E:D437:6B25:6E28,
URI:https://hda.example.com
Signature Algorithm: ED25519
Signature Value:
5a:f2:56:72:7e:dc:47:26:a0:c5:56:0b:f8:46:df:9c:31:49:
9c:f1:a4:30:7a:de:14:65:d3:b7:c9:03:81:f6:ea:b8:b0:b5:
40:49:c6:99:09:68:c2:d2:79:9e:46:48:15:46:18:b3:7b:57:
ac:7f:28:b7:45:15:38:e0:80:04
Figure 17: 2001:3f:fe00:a05:260e:d437:6b25:6e28 Decoded Certificate
図 17: 2001:3f:fe00:a05:260e:d437:6b25:6e28 デコードされた証明書
$ORIGIN 5.0.a.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.example.com.
2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN HHIT (
gxJpM2ZmOCAwMDBhWQEYMIIBFDCBx6AD
AgECAgFUMAUGAytlcDArMSkwJwYDVQQD
DCAyMDAxMDAzZmZlMDAwYTA1MjYwZWQ0
Mzc2YjI1NmUyODAeFw0yNTA0MDkyMTEz
MDBaFw0yNTA0MDkyMjEzMDBaMAAwKjAF
BgMrZXADIQDJLi+dl+iWD5tfFlT4sJA5
+drcW88GHqxPDOp56Oh3+qM7MDkwNwYD
VR0RAQH/BC0wK4cQIAEAP/4ACgUTCCRp
mkvGsoYXaHR0cHM6Ly9oZGEuZXhhbXBs
ZS5jb20wBQYDK2VwA0EA0DbcdngC7/BB
/aLjZmLieo0ZFCDbd/KIxAy+3X2KtT4J
todVxRMPAkN6o008gacbNfTG8p9npEcD
eYhesl2jBQ==
)
2.b.6.c.b.4.a.9.9.6.4.2.8.0.3.1. IN BRID (
owAAAYIEUQEgAQA//gAKBRMIJGmaS8ay
AogFWIkB+t72Zwrt9mcgAQA//gAABV5g
oVcekaC3mZDVsEtyoYBm1AkrUsfUmU+3
wWvX6MH0QP+o0E/x4T8gAQA//gAABV5g
oVcekaC3vC9m1JguvXt7W2o4wxPumaT1
IP3TQN3fQP28hpInSIlsSwq8UCNjm2ad
7pdTvm2EqfOJQNPKClvRZm4qTO5FDAVY
iQGX4PZnp+72ZyABAD/+AAoFZhXuRdQn
CaDOaB424RQa61YNbna8eWt7fLRU5GPM
sfEt4wo4AQGAPyABAD/+AAAFXmChVx6R
oLfv3q+mLRB3ya5TmjY8+3CzdoDZT9RZ
+XpN5hDiA6JyyxBJvUewxLzPNhTXQp8v
ED71XAE82tMmt3fB4zbzWNQLBViJAQrh
9mca7/ZnIAEAP/4ACgUmDtQ3ayVuKIIz
/a61BovBSFnRE6Dt/PjcB4FOPdJ2Xmtb
guBNBwWXIAEAP/4ACgVmFe5F1CcJoIjy
CriJCxAyAWTOHPmlHL02MKSpsHviiTze
qwBH9K/Rrz41CYix9HazAIOAZO8FcfU5
M+WLLJZoaQWBHnMbTQwFWIkB3OL2Z+zw
9mcgAQA//gAKBRMIJGmaS8ayyS4vnZfo
lg+bXxZU+LCQOfna3FvPBh6sTwzqeejo
d/ogAQA//gAKBSYO1DdrJW4ogOfc8jTi
mYLmTOOyFZoUx2jOOwtB1jnqUJr6bYaw
MoPrR3MlKGBGWsVz1yXNqUURoCqYdwsY
e61vd5i6YJqnAQ==
)
Figure 18: Registrant HHIT/BRID RRType Example
図 18: 登録者の HHIT/BRID RRType の例
Figure 19 shows the CBOR decoded RDATA in the HHIT RRType found in Figure 18.
図 19 は、図 18 にある HHIT RRType 内の CBOR デコードされた RDATA を示しています。
[
18, # Uncrewed Aircraft System (UAS)
"3ff8 000a",
h'308201143081C7A00302010202015430
0506032B6570302B312930270603550403
0C20323030313030336666653030306130
3532363065643433373662323536653238
301E170D3235303430393231313330305A
170D3235303430393232313330305A3000
302A300506032B6570032100C92E2F9D97
E8960F9B5F1654F8B09039F9DADC5BCF06
1EAC4F0CEA79E8E877FAA33B3039303706
03551D110101FF042D302B87102001003F
FE000A05130824699A4BC6B28617687474
70733A2F2F6864612E6578616D706C652E
636F6D300506032B6570034100D036DC76
7802EFF041FDA2E36662E27A8D191420DB
77F288C40CBEDD7D8AB53E09B68755C513
0F02437AA34D3C81A71B35F4C6F29F67A4
470379885EB25DA305'
]
Figure 19: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded HHIT RRType CBOR
図 19: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 デコードされた HHIT RRType CBOR
Figure 20 shows the decoded DER X.509 found in Figure 19.
図 20 は、図 19 で見つかったデコードされた DER X.509 を示しています。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 84 (0x54)
Signature Algorithm: ED25519
Issuer: CN = 2001003ffe000a05260ed4376b256e28
Validity
Not Before: Apr 9 21:13:00 2025 GMT
Not After : Apr 9 22:13:00 2025 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
c9:2e:2f:9d:97:e8:96:0f:9b:5f:16:54:f8:b0:90:
39:f9:da:dc:5b:cf:06:1e:ac:4f:0c:ea:79:e8:e8:
77:fa
X509v3 extensions:
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:A05:1308:2469:9A4B:C6B2,
URI:https://hda.example.com
Signature Algorithm: ED25519
Signature Value:
d0:36:dc:76:78:02:ef:f0:41:fd:a2:e3:66:62:e2:7a:8d:19:
14:20:db:77:f2:88:c4:0c:be:dd:7d:8a:b5:3e:09:b6:87:55:
c5:13:0f:02:43:7a:a3:4d:3c:81:a7:1b:35:f4:c6:f2:9f:67:
a4:47:03:79:88:5e:b2:5d:a3:05
Figure 20: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded Certificate
図 20: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 デコードされた証明書
Figure 21 shows the CBOR decoded RDATA of the BRID RRType in Figure 18.
図 21 は、図 18 の BRID RRType の CBOR デコードされた RDATA を示しています。
{
0: 0,
1: [4, h'012001003FFE000A05130824699A4BC6B2'],
2: [
5,
h'01FADEF6670AEDF6672001003FFE0000
055E60A1571E91A0B79990D5B04B72A180
66D4092B52C7D4994FB7C16BD7E8C1F440
FFA8D04FF1E13F2001003FFE0000055E60
A1571E91A0B7BC2F66D4982EBD7B7B5B6A
38C313EE99A4F520FDD340DDDF40FDBC86
922748896C4B0ABC5023639B669DEE9753
BE6D84A9F38940D3CA0A5BD1666E2A4CEE
450C',
5,
h'0197E0F667A7EEF6672001003FFE000A
056615EE45D42709A0CE681E36E1141AEB
560D6E76BC796B7B7CB454E463CCB1F12D
E30A380101803F2001003FFE0000055E60
A1571E91A0B7EFDEAFA62D1077C9AE539A
363CFB70B37680D94FD459F97A4DE610E2
03A272CB1049BD47B0C4BCCF3614D7429F
2F103EF55C013CDAD326B777C1E336F358
D40B',
5,
h'010AE1F6671AEFF6672001003FFE000A
05260ED4376B256E288233FDAEB5068BC1
4859D113A0EDFCF8DC07814E3DD2765E6B
5B82E04D0705972001003FFE000A056615
EE45D42709A088F20AB8890B10320164CE
1CF9A51CBD3630A4A9B07BE2893CDEAB00
47F4AFD1AF3E350988B1F476B300838064
EF0571F53933E58B2C96686905811E731B
4D0C',
5,
h'01DCE2F667ECF0F6672001003FFE000A
05130824699A4BC6B2C92E2F9D97E8960F
9B5F1654F8B09039F9DADC5BCF061EAC4F
0CEA79E8E877FA2001003FFE000A05260E
D4376B256E2880E7DCF234E29982E64CE3
B2159A14C768CE3B0B41D639EA509AFA6D
86B03283EB4773252860465AC573D725CD
A94511A02A98770B187BAD6F7798BA609A
A701'
]
}
Figure 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 Decoded BRID RRType CBOR
図 21: 2001:3f:fe00:a05:1308:2469:9a4b:c6b2 デコードされた BRID RRType CBOR
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundation for the content and processes of this architecture and document. The authors would also like to thank the DRIP chairs and AD, the reviewers from the various Directorates, and the members of the IESG at time of publication.
DRIP レジストリ概念に関する初期の取り組みについて、Stuart Card (AX Enterprize, LLC) と Bob Moskowitz (HTT Consulting, LLC) に感謝します。彼らの初期の貢献により、このアーキテクチャとドキュメントの内容とプロセスの基礎が築かれました。著者らはまた、出版時の DRIP 議長と AD、さまざまな局の査読者、IESG のメンバーに感謝したいと思います。
Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com