[要約] RFC 9374 は、UAS RIDにおける信頼性のある識別子としてHHITsを使用し、それをDRIP Entity Tags (DETs)と呼ぶことを説明しています。DETは、第三者識別子の承認のためのレジストリ（DNS、RDAPなど）の発見を提供する明示的な階層を含む主張を提供します。
Internet Engineering Task Force (IETF) R. Moskowitz
Request for Comments: 9374 HTT Consulting
Updates: 7343, 7401 S. Card
Category: Standards Track A. Wiethuechter
ISSN: 2070-1721 AX Enterprize, LLC
A. Gurtov
Linköping University
March 2023
This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.
このドキュメントでは、階層ホストIDタグ（HHIT）を自己挿入IPv6アドレスとして使用することを説明しています。これにより、無人航空機システムリモート識別（UAS RID）および追跡で使用する信頼できる識別子が説明されています。
Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement.
RIDのコンテキスト内で、HHITはDRIPエンティティタグ（DETS）と呼ばれます。HHITSは、サードパーティの識別子承認にレジストリ（DNS、RDAPなど）発見を提供する、含まれている明示的な階層に対するクレームを提供します。
This document updates RFCs 7343 and 7401.
このドキュメントは、RFCS 7343および7401を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9374.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9374で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. HHIT Statistical Uniqueness Different from UUID or X.509
Subject
2. Terms and Definitions
2.1. Requirements Terminology
2.2. Notation
2.3. Definitions
3. The Hierarchical Host Identity Tag (HHIT)
3.1. HHIT Prefix for RID Purposes
3.2. HHIT Suite IDs
3.2.1. HDA Custom HIT Suite IDs
3.3. The Hierarchy ID (HID)
3.3.1. The Registered Assigning Authority (RAA)
3.3.2. The HHIT Domain Authority (HDA)
3.4. Edwards-Curve Digital Signature Algorithm for HHITs
3.4.1. HOST_ID
3.4.2. HIT_SUITE_LIST
3.5. ORCHIDs for HHITs
3.5.1. Adding Additional Information to the ORCHID
3.5.2. ORCHID Encoding
3.5.3. ORCHID Decoding
3.5.4. Decoding ORCHIDs for HIPv2
4. HHITs as DRIP Entity Tags
4.1. Nontransferablity of DETs
4.2. Encoding HHITs in CTA 2063-A Serial Numbers
4.3. Remote ID DET as one Class of HHITs
4.4. Hierarchy in ORCHID Generation
4.5. DRIP Entity Tag (DET) Registry
4.6. Remote ID Authentication Using DETs
5. DRIP Entity Tags (DETs) in DNS
6. Other UAS Traffic Management (UTM) Uses of HHITs Beyond DET
7. Summary of Addressed DRIP Requirements
8. IANA Considerations
8.1. New Well-Known IPv6 Prefix for DETs
8.2. New IANA DRIP Registry
8.2.1. HHIT Prefixes
8.2.2. HHIT Suite IDs
8.3. IANA CGA Registry Update
8.4. IANA HIP Registry Updates
9. Security Considerations
9.1. Post-Quantum Computing Is Out of Scope
9.2. DET Trust in ASTM Messaging
9.3. DET Revocation
9.4. Privacy Considerations
9.5. Collision Risks with DETs
10. References
10.1. Normative References
10.2. Informative References
Appendix A. EU U-Space RID Privacy Considerations
Appendix B. The 14/14 HID split
B.1. DET Encoding Example
Appendix C. Base32 Alphabet
Appendix D. Calculating Collision Probabilities
Acknowledgments
Authors' Addresses
Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non-spoofable (ID-5), and identify a registry where the ID is listed (ID-2); all within a 19-character identifier (ID-1).
ドローンリモートIDプロトコル（DRIP）要件[RFC9153]無人の航空機システムリモートID（UAS ID）を一意（ID-4）、非スプーフィング可能（ID-5）として説明し、IDがリストされているレジストリを識別します（IDを特定します-2）;すべて19文字の識別子（ID-1）内。
This RFC is a foundational document of DRIP, as it describes the use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the UAS Remote ID (see Section 3 of [DRIP-ARCH]). All other DRIP-related technologies will enable or use HHITs as multipurpose remote identifiers. HHITs add explicit hierarchy to the 128-bit HITs, enabling DNS HHIT queries (Host ID for authentication, e.g., [DRIP-AUTH]) and use with a Differentiated Access Control (e.g., Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party identification endorsement (e.g., [DRIP-AUTH]).
このRFCは、階層ホストIDタグ（HHITS）（セクション3）の使用を自己挿入IPv6アドレスとして使用することを説明しているため、UASリモートIDとして使用する信頼できる識別子を説明しているため、DRIPの基礎文書です。ドリップアーチ]）。他のすべての点滴関連テクノロジーは、HHITを多目的リモート識別子として有効または使用します。HHITは128ビットヒットに明示的な階層を追加し、DNS HHITクエリ（認証のホストID、[DRIP-AUTH]）を有効にし、差別化されたアクセス制御（例：登録データアクセスプロトコル（RDAP）[RFC9224]）で使用します。サードパーティの識別承認の場合（例：[drip-auth]）。
The addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP.
階層をヒットに追加することは[RFC7401]の拡張であり、[RFC7343]の更新が必要です。このドキュメントでは、ホストID（HIS）にEDDSA（セクション3.4）も追加されるため、[RFC7401]の多くのホストIDプロトコル（HIP）パラメーターが更新されますが、これらは股関節を使用しない点滴実装では必要ありません。
HHITs as used within the context of UAS are labeled as DRIP Entity Tags (DETs). Throughout this document, HHIT and DET will be used appropriately. HHIT will be used when covering the technology, and DET will be used in the context of UAS RID.
UASのコンテキスト内で使用されるHHITは、DRIPエンティティタグ（DETS）としてラベル付けされています。このドキュメント全体で、HHITとDETは適切に使用されます。HHITはテクノロジーをカバーするときに使用され、DETはUAS RIDのコンテキストで使用されます。
HHITs provide self-claims of the HHIT registry. A HHIT can only be in a single registry within a registry system (e.g., DNS).
HHITは、HHITレジストリの自己請求を提供します。HHITは、レジストリシステム（DNSなど）内の単一のレジストリにのみ存在できます。
HHITs are valid, though non-routable, IPv6 addresses [RFC8200]. As such, they fit in many ways within various IETF technologies.
HHITは有効ですが、IPv6は有効ですが、IPv6アドレスは[RFC8200]です。そのため、さまざまなIETFテクノロジー内に多くの点で適合しています。
HHITs are statistically unique through the cryptographic hash feature of second-preimage resistance. The cryptographically bound addition of the hierarchy and a HHIT registration process [DRIP-REG] provide complete, global HHIT uniqueness. If the HHITs cannot be looked up with services provided by the DRIP Identity Management Entity (DIME) identified via the embedded hierarchical information or its registration validated by registration endorsement messages [DRIP-AUTH], then the HHIT is either fraudulent or revoked/expired. In-depth discussion of these processes are out of scope for this document.
HHITは、2番目のプレイマージ抵抗の暗号化ハッシュ機能を介して統計的に一意です。階層とHHIT登録プロセスの暗号化に結合した追加[DRIP-REG]は、完全なグローバルなHHITユニーク性を提供します。HHITは、埋め込み階層情報または登録承認メッセージ[DRIP-Auth]によって検証された登録を介して識別されたDRIP ID管理エンティティ（DIME）が提供するサービスを調べることができない場合、HHITは詐欺または改造/期限切れのいずれかです。これらのプロセスの詳細な議論は、このドキュメントの範囲外です。
This contrasts with using general identifiers (e.g., Universally Unique IDentifiers (UUIDs) [RFC4122] or device serial numbers) as the subject in an X.509 [RFC5280] certificate. In either case, there can be no unique proof of ownership/registration.
これは、X.509 [RFC5280]証明書の被験者として、一般識別子（例：普遍的に一意の識別子（UUIDS）[RFC4122]またはデバイスのシリアル番号）を使用することとは対照的です。どちらの場合でも、所有権/登録の独自の証拠はありません。
For example, in a multi-Certificate Authority (multi-CA) PKI alternative to HHITs, a Remote ID as the Subject (Section 4.1.2.6 of [RFC5280]) can occur in multiple CAs, possibly fraudulently. CAs within the PKI would need to implement an approach to enforce assurance of the uniqueness achieved with HHITs.
たとえば、HHITSに代わる多認識機関（マルチCA）PKIでは、主題としてのリモートID（[RFC5280]のセクション4.1.2.6）が複数のCAで、おそらく詐欺的に発生する可能性があります。PKI内のCASは、HHITで達成された一意性の保証を強制するためのアプローチを実装する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "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.
このドキュメントの「必須」、「必要」、「必須」、「必須」、「必要」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、「オプション」BCP 14 [RFC2119] [RFC8174]に記載されているように解釈されます。
The document includes a set of algorithms and recommends the ones that should be supported by implementations. The following term is used for that purpose: RECOMMENDED.
ドキュメントには一連のアルゴリズムが含まれており、実装によってサポートされるべきアルゴリズムを推奨します。その目的のために次の用語が使用されます：推奨。
|
|
Signifies concatenation of information, e.g., X | Y is the concatenation of X and Y.
情報の連結、例えばx |yはxとyの連結です。
This document uses the terms defined in Section 2.2 of [RFC9153] and in Section 2 of [DRIP-ARCH]. The following terms are used in the document:
このドキュメントでは、[RFC9153]のセクション2.2および[DRIP-ARCH]のセクション2で定義されている用語を使用します。ドキュメントでは、次の用語が使用されています。
cSHAKE (The customizable SHAKE function [NIST.SP.800-185]):
cshake（カスタマイズ可能なシェイク関数[nist.sp.800-185]）：
Extends the SHAKE scheme [NIST.FIPS.202] to allow users to customize their use of the SHAKE function.
Shakeスキーム[nist.fips.202]を拡張して、ユーザーがシェイク機能の使用をカスタマイズできるようにします。
HDA (HHIT Domain Authority):
HDA（HHITドメインオーソリティ）：
The 14-bit field that identifies the HHIT Domain Authority under a Registered Assigning Authority (RAA). See Figure 1.
登録された割り当て当局（RAA）の下でHHITドメイン当局を識別する14ビットフィールド。図1を参照してください。
HHIT (Hierarchical Host Identity Tag):
HHIT（階層ホストIDタグ）：
A HIT with extra hierarchical information not found in a standard HIT [RFC7401].
標準ヒット[RFC7401]には見られない追加の階層情報を含むヒット。
HI (Host Identity):
こんにちは（ホストID）：
The public key portion of an asymmetric key pair as defined in [RFC9063].
[RFC9063]で定義されている非対称キーペアの公開キー部分。
HID (Hierarchy ID):
HID（階層ID）：
The 28-bit field providing the HIT Hierarchy ID. See Figure 1.
ヒット階層IDを提供する28ビットフィールド。図1を参照してください。
HIP (Host Identity Protocol):
HIP（ホストIDプロトコル）：
The origin of HI, HIT, and HHIT [RFC7401].
HI、HIT、およびHHIT [RFC7401]の起源。
HIT (Host Identity Tag):
ヒット（ホストIDタグ）：
A 128-bit handle on the HI. HITs are valid IPv6 addresses.
HIの128ビットハンドル。ヒットは有効なIPv6アドレスです。
Keccak (KECCAK Message Authentication Code):
Keccak（Keccakメッセージ認証コード）：
The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule. In particular, it refers to all the functions referenced from [NIST.FIPS.202] and [NIST.SP.800-185].
すべてのスポンジのファミリーは、基礎となる関数としてのKeccak-F順列とパディングルールとしての多価パッドを使用して機能します。特に、[nist.fips.202]および[nist.sp.800-185]から参照されているすべての機能を指します。
KMAC (KECCAK Message Authentication Code [NIST.SP.800-185]):
KMAC（Keccakメッセージ認証コード[nist.sp.800-185]）：
A Pseudo Random Function (PRF) and keyed hash function based on KECCAK.
擬似ランダム関数（PRF）およびKeccakに基づいてキー付きハッシュ機能。
RAA (Registered Assigning Authority):
RAA（登録機関）：
The 14-bit field identifying the business or organization that manages a registry of HDAs. See Figure 1.
HDAのレジストリを管理するビジネスまたは組織を識別する14ビットフィールド。図1を参照してください。
RVS (Rendezvous Server):
RVS（Rendezvousサーバー）：
A Rendezvous Server such as the HIP Rendezvous Server for enabling mobility, as defined in [RFC8004].
[RFC8004]で定義されているように、モビリティを有効にするための股関節ランデブーサーバーなどのランデブーサーバー。
SHAKE (Secure Hash Algorithm KECCAK [NIST.FIPS.202]):
シェイク（安全なハッシュアルゴリズムKeccak [nist.fips.202]）：
A secure hash that allows for an arbitrary output length.
任意の出力長を可能にする安全なハッシュ。
XOF (eXtendable-Output Function [NIST.FIPS.202]):
XOF（拡張可能な出力関数[nist.fips.202]）：
A function on bit strings (also called messages) in which the output can be extended to any desired length.
出力を任意の長さに拡張できるビット文字列（メッセージとも呼ばれます）の関数。
The HHIT is a small but important enhancement over the flat Host Identity Tag (HIT) space, constructed as an Overlay Routable Cryptographic Hash IDentifier (ORCHID) [RFC7343]. By adding two levels of hierarchical administration control, the HHIT provides for device registration/ownership, thereby enhancing the trust framework for HITs.
HHITは、オーバーレイのルーティング可能な暗号ハッシュ識別子（蘭）[RFC7343]として構築された、フラットホストIDタグ（ヒット）スペースに対する小さいながらも重要な強化です。2つのレベルの階層管理制御を追加することにより、HHITはデバイスの登録/所有権を提供し、それによりヒットの信頼フレームワークを強化します。
The 128-bit HHITs represent the HI in only a 64-bit hash, rather than the 96 bits in HITs. 4 of these 32 freed up bits expand the Suite ID to 8 bits, and the other 28 bits are used to create a hierarchical administration organization for HIT domains. HHIT construction is defined in Section 3.5. The input values for the encoding rules are described in Section 3.5.1.
128ビットHHITは、ヒットの96ビットではなく、64ビットハッシュのみでHIを表します。これらの32のFreed Upビットのうち4ビットはスイートIDを8ビットに拡張し、他の28ビットを使用して、ヒットドメイン用の階層管理組織を作成します。HHIT構造は、セクション3.5で定義されています。エンコードルールの入力値は、セクション3.5.1で説明されています。
A HHIT is built from the following fields (Figure 1):
HHITは、次のフィールドから構築されています（図1）：
* p = an IPv6 prefix (max 28 bit)
* P = IPv6プレフィックス（最大28ビット）
* 28-bit HID which provides the structure to organize HITs into administrative domains. HIDs are further divided into two fields:
* 28ビットHIDは、ヒットを管理ドメインに整理するための構造を提供します。HIDはさらに2つのフィールドに分割されます。
- 14-bit Registered Assigning Authority (RAA) (Section 3.3.1)
- 14ビット登録機関（RAA）（セクション3.3.1）
- 14-bit HHIT Domain Authority (HDA) (Section 3.3.2)
- 14ビットHHITドメインオーソリティ（HDA）（セクション3.3.2）
* 8-bit HHIT Suite ID (HHSI)
* 8ビットHHITスイートID（HHSI）
* ORCHID hash (92 - prefix length, e.g., 64) See Section 3.5 for more details.
* Orchid Hash（92-プレフィックスの長さ、例えば64）詳細については、セクション3.5を参照してください。
14 bits| 14 bits 8 bits
+-------+-------+ +--------------+
| RAA | HDA | |HHIT Suite ID |
+-------+-------+ +--------------+
\ | ____/ ___________/
\ \ _/ ___/
\ \/ /
| p bits | 28 bits |8bits| o=92-p bits |
+--------------+------------+-----+------------------------+
| IPv6 Prefix | HID |HHSI | ORCHID hash |
+--------------+------------+-----+------------------------+
Figure 1: HHIT Format
図1：HHIT形式
The Context ID (generated with openssl rand) for the ORCHID hash is:
Orchid HashのコンテキストID（OpenSSL RANDで生成）は次のとおりです。
Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40
Context IDs are allocated out of the namespace introduced for Cryptographically Generated Addresses (CGA) Type Tags [RFC3972].
コンテキストIDは、暗号化されたアドレス（CGA）タイプタグ[RFC3972]に導入された名前空間から割り当てられます。
The IPv6 HHIT prefix MUST be distinct from that used in the flat-space HIT as allocated in [RFC7343]. Without this distinct prefix, the first 4 bits of the RAA would be interpreted as the HIT Suite ID per HIPv2 [RFC7401].
IPv6 HHITプレフィックスは、[RFC7343]に割り当てられているように、フラットスペースヒットで使用されるものとは異なる必要があります。この明確なプレフィックスがなければ、RAAの最初の4ビットは、HIPV2 [RFC7401]ごとにヒットスイートIDとして解釈されます。
Initially, the IPv6 prefix listed in Table 1 is assigned for DET use. It has been registered in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890].
最初に、表1にリストされているIPv6プレフィックスは、DET使用のために割り当てられています。「IANA IPv6特殊目的アドレスレジストリ」[RFC6890]に登録されています。
+==========+======+==============+
| HHIT Use | Bits | Value |
+==========+======+==============+
| DET | 28 | 2001:30::/28 |
+----------+------+--------------+
Table 1: Initial DET IPv6 Prefix
表1：最初のDET IPv6プレフィックス
Other prefixes may be added in the future either for DET use or other applications of HHITs. For a prefix to be added to the registry in Section 8.2, its usage and HID allocation process have to be publicly available.
HHITの使用または他のアプリケーションのいずれかのために、将来、他の接頭辞を追加することができます。セクション8.2のレジストリにプレフィックスを追加するには、その使用法とHID割り当てプロセスを公開する必要があります。
The HHIT Suite IDs specify the HI and hash algorithms. These are a superset of the 4-bit and 8-bit HIT Suite IDs as defined in Section 5.2.10 of [RFC7401].
HHITスイートIDは、HIおよびハッシュアルゴリズムを指定します。これらは、[RFC7401]のセクション5.2.10で定義されているように、4ビットおよび8ビットヒットスイートIDのスーパーセットです。
The HHIT values 1 - 15 map to the basic 4-bit HIT Suite IDs. HHIT values 17 - 31 map to the extended 8-bit HIT Suite IDs. HHIT values unique to HHIT will start with value 32.
HHIT値1-15基本的な4ビットヒットスイートIDにマップします。HHIT値17-31拡張された8ビットヒットスイートIDにマップします。HHITに固有のHHIT値は、値32で開始されます。
As HHIT introduces a new Suite ID, EdDSA/cSHAKE128, and because this is of value to HIPv2, it will be allocated out of the 4-bit HIT space and result in an update to HIT Suite IDs. Future HHIT Suite IDs may be allocated similarly, or they may come out of the additional space made available by going to 8 bits.
HHITが新しいスイートIDであるEDDSA/CSHAKE128を導入すると、これはHIPV2に価値があるため、4ビットヒットスペースから割り当てられ、ヒットスイートIDのアップデートが得られます。将来のHHITスイートIDは、同様に割り当てられるか、8ビットに移動することで利用可能な追加スペースから出てくる場合があります。
The following HHIT Suite IDs are defined:
次のHHITスイートIDが定義されています。
+=================+=============+
| HHIT Suite | Value |
+=================+=============+
| RESERVED | 0 |
+-----------------+-------------+
| RSA,DSA/SHA-256 | 1 [RFC7401] |
+-----------------+-------------+
| ECDSA/SHA-384 | 2 [RFC7401] |
+-----------------+-------------+
| ECDSA_LOW/SHA-1 | 3 [RFC7401] |
+-----------------+-------------+
| EdDSA/cSHAKE128 | 5 |
+-----------------+-------------+
Table 2: Initial HHIT Suite IDs
表2：初期HHITスイートID
Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs (see Table 3).
8ビットHHITスイートIDのサポートにより、HDAカスタムヒットスイートIDが可能になります（表3を参照）。
+===================+=======+
| HHIT Suite | Value |
+===================+=======+
| HDA Private Use 1 | 254 |
+-------------------+-------+
| HDA Private Use 2 | 255 |
+-------------------+-------+
Table 3: HDA Custom HIT Suite IDs
表3：HDAカスタムヒットスイートID
These custom HIT Suite IDs, for example, may be used for large-scale experimentation with post-quantum computing hashes or similar domain-specific needs. Note that currently there is no support for domain-specific HI algorithms.
たとえば、これらのカスタムヒットスイートIDは、質量のコンピューティングハッシュまたは同様のドメイン固有のニーズを使用した大規模な実験に使用できます。現在、ドメイン固有のHIアルゴリズムにはサポートがないことに注意してください。
They should not be used to create a "de facto standardization". Section 8.2 states that additional Suite IDs can be made through IETF Review.
「事実上の標準化」を作成するために使用しないでください。セクション8.2では、IETFレビューを通じて追加のスイートIDを作成できると述べています。
The HID provides the structure to organize HITs into administrative domains. HIDs are further divided into two fields:
HIDは、ヒットを管理ドメインに整理するための構造を提供します。HIDはさらに2つのフィールドに分割されます。
* 14-bit Registered Assigning Authority (RAA)
* 14ビット登録機関（RAA）
* 14-bit HHIT Domain Authority (HDA)
* 14ビットHHITドメインオーソリティ（HDA）
The rationale for splitting the HID into two 14-bit domains is described in Appendix B.
HIDを2つの14ビットドメインに分割する理論的根拠は、付録Bで説明されています。
The two levels of hierarchy allow for Civil Aviation Authorities (CAAs) to have it least one RAA for their National Air Space (NAS). Within its RAAs, the CAAs can delegate HDAs as needed. There may be other RAAs allowed to operate within a given NAS; this is a policy decision of each CAA.
階層の2つのレベルにより、民間航空当局（CAA）が国立空域（NAS）のために少なくとも1つのRAAを持つことができます。そのRAAの中で、CAASは必要に応じてHDAを委任できます。特定のNAS内での運転が許可されている他のRAAがあるかもしれません。これは、各CAAのポリシー決定です。
An RAA is a business or organization that manages a registry of HDAs. For example, the Federal Aviation Authority (FAA) or Japan Civil Aviation Bureau (JCAB) could be RAAs.
RAAは、HDAのレジストリを管理するビジネスまたは組織です。たとえば、連邦航空局（FAA）または日本民間航空局（JCAB）はRAASである可能性があります。
The RAA is a 14-bit field (16,384 RAAs). Management of this space is further described in [DRIP-REG]. An RAA MUST provide a set of services to allocate HDAs to organizations. It SHOULD have a public policy on what is necessary to obtain an HDA. The RAA need not maintain any HIP-related services. At minimum, it MUST maintain a DNS zone for the HDA zone delegation for discovering HIP RVS servers [RFC8004] for the HID. Zone delegation is covered in [DRIP-REG].
RAAは14ビットフィールド（16,384 RAAS）です。このスペースの管理は、[Drip-Reg]でさらに説明されています。RAAは、HDAを組織に割り当てるための一連のサービスを提供する必要があります。HDAを取得するために必要なものについて公共政策が必要です。RAAは、股関節関連サービスを維持する必要はありません。少なくとも、HIDの股関節RVSサーバー[RFC8004]を発見するためのHDAゾーン委任のDNSゾーンを維持する必要があります。ゾーン委任は[Drip-Reg]でカバーされています。
As DETs under administrative control may be used in many different domains (e.g., commercial, recreation, military), RAAs should be allocated in blocks (e.g., 16-19) with consideration of the likely size of a particular usage. Alternatively, different prefixes can be used to separate different domains of use of HHITs.
多くの異なるドメイン（たとえば、商業、レクリエーション、軍事）で行政管理下で使用される可能性があるため、特定の使用量の可能性を考慮して、RAAはブロック（例：16-19）に割り当てる必要があります。あるいは、異なるプレフィックスを使用して、HHITの使用の異なるドメインを分離することができます。
The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA. It may be a zone in a HHIT-specific DNS zone. Assume that the RAA is decimal 100. The PTR record could be constructed as follows (where 20010030 is the DET prefix):
UAS DNSツリー内のRAA DNSゾーンは、そのRAAのPTRである可能性があります。HHIT固有のDNSゾーンのゾーンである可能性があります。RAAが10進数100であると仮定します。PTRレコードは次のように構築できます（20010030がDETプレフィックスです）。
100.20010030.hhit.arpa. IN PTR raa.example.com.
Note that if the zone 20010030.hhit.arpa is ultimately used, a registrar will need to manage this for all HHIT applications. Thus, further thought will be needed in the actual DNS zone tree and registration process [DRIP-REG].
Zone 20010030.hhit.arpaが最終的に使用される場合、レジストラはすべてのHHITアプリケーションでこれを管理する必要があることに注意してください。したがって、実際のDNSゾーンツリーと登録プロセス[DRIP-REG]でさらに考えが必要になります。
An HDA may be an Internet Service Provider (ISP), UAS Service Supplier (USS), or any third party that takes on the business to provide UAS services management, HIP RVSs or other needed services such as those required for HHIT and/or HIP-enabled devices.
HDAは、インターネットサービスプロバイダー（ISP）、UASサービスサプライヤー（USS）、またはUASサービス管理、股関節RVSS、またはHHITおよび/または股関節に必要なサービスなどのその他の必要なサービスを提供するためにビジネスに参加する第三者である場合があります - 有効なデバイス。
The HDA is a 14-bit field (16,384 HDAs per RAA) assigned by an RAA and is further described in [DRIP-REG]. An HDA must maintain public and private UAS registration information and should maintain a set of RVS servers for UAS clients that may use HIP. How this is done and scales to the potentially millions of customers are outside the scope of this document; they are covered in [DRIP-REG]. This service should be discoverable through the DNS zone maintained by the HDA's RAA.
HDAは、RAAによって割り当てられた14ビットフィールド（RAAあたり16,384 HDA）であり、[Drip-Reg]でさらに説明されています。HDAは、パブリックおよびプライベートUAS登録情報を維持する必要があり、股関節を使用する可能性のあるUASクライアント向けのRVSサーバーのセットを維持する必要があります。これがどのように行われ、潜在的に何百万人もの顧客がこのドキュメントの範囲外にあることを拡大します。[Drip-Reg]で覆われています。このサービスは、HDAのRAAによって維持されているDNSゾーンを通じて発見できる必要があります。
An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such a policy is out of scope for this document.
RAAは、個々の組織に値のブロックを割り当てることができます。これは、個々のRAAの委任に関するポリシー次第です。このようなポリシーは、このドキュメントの範囲外です。
The Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] is specified here for use as HIs per HIPv2 [RFC7401].
Edwards-Curve Digital Signature Algorithm（EDDSA）[RFC8032]は、HIPV2 [RFC7401]として使用するためにここで指定されています。
The intent in this document is to add EdDSA as a HI algorithm for DETs, but doing so impacts the HIP parameters used in a HIP exchange. Sections 3.4.1 through 3.4.2 describe the required updates to HIP parameters. Other than the HIP DNS RR (Resource Record) [RFC8005], these should not be needed in a DRIP implementation that does not use HIP.
このドキュメントの意図は、EDDSAをDETSのHIアルゴリズムとして追加することですが、そうすることは、股関節交換で使用される股関節パラメーターに影響を与えます。セクション3.4.1〜3.4.2股関節パラメーターに必要な更新について説明します。股関節DNS RR（リソースレコード）[RFC8005]を除いて、これらは股関節を使用しない点滴実装では必要ありません。
See Section 3.2 for use of the HIT Suite in the context of DRIP.
DRIPのコンテキストでヒットスイートの使用については、セクション3.2を参照してください。
The HOST_ID parameter specifies the public key algorithm, and for elliptic curves, a name. The HOST_ID parameter is defined in Section 5.2.9 of [RFC7401]. Table 4 adds a new HI Algorithm.
host_idパラメーターは、公開キーアルゴリズムを指定し、楕円曲線の場合は名前を指定します。HOST_IDパラメーターは、[RFC7401]のセクション5.2.9で定義されています。表4に新しいHIアルゴリズムを追加します。
+===================+=======+===========+
| Algorithm profile | Value | Reference |
+===================+=======+===========+
| EdDSA | 13 | [RFC8032] |
+-------------------+-------+-----------+
Table 4: New EdDSA Host ID
表4：新しいEDDSAホストID
The addition of EdDSA as a HI algorithm requires a subfield in the HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for ECDSA when used in a HIP exchange.
HIアルゴリズムとしてEDDSAを追加するには、股関節交換で使用された場合にECDSAに対して行われたように、股関節host_idパラメーター（[rfc7401]のセクション5.2.9）のサブフィールドが必要です。
For HIP hosts that implement EdDSA as the algorithm, the following EdDSA curves are represented by the fields in Figure 2.
EDDSAをアルゴリズムとして実装するHIPホストの場合、次のEDDSA曲線は図2のフィールドで表されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EdDSA Curve | NULL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EdDSA Curves Fields
図2：EDDSA曲線フィールド
EdDSA Curve:
eddsa曲線：
Curve label
曲線ラベル
Public Key:
公開鍵：
Represented in Octet-string format [RFC8032]
Octet-String形式で表される[RFC8032]
For hosts that implement EdDSA as a HIP algorithm, the following EdDSA curves are defined. Recommended curves are tagged accordingly:
EDDSAを股関節アルゴリズムとして実装するホストの場合、次のEDDSA曲線が定義されています。それに応じて、推奨される曲線にタグが付けられています。
+===========+==============+===========================+
| Algorithm | Curve | Values |
+===========+==============+===========================+
| EdDSA | RESERVED | 0 |
+-----------+--------------+---------------------------+
| EdDSA | EdDSA25519 | 1 [RFC8032] (RECOMMENDED) |
+-----------+--------------+---------------------------+
| EdDSA | EdDSA25519ph | 2 [RFC8032] |
+-----------+--------------+---------------------------+
| EdDSA | EdDSA448 | 3 [RFC8032] (RECOMMENDED) |
+-----------+--------------+---------------------------+
| EdDSA | EdDSA448ph | 4 [RFC8032] |
+-----------+--------------+---------------------------+
Table 5: EdDSA Curves
表5：EDDSA曲線
The HIP DNS RR is defined in [RFC8005]. It uses the values defined for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK Algorithm field.
股関節DNS RRは[RFC8005]で定義されています。PKアルゴリズムフィールドにIPSeckey RR [RFC4025]の「アルゴリズムタイプ」に定義された値を使用します。
The 'Algorithm Type' value and EdDSA HI encoding are assigned per [RFC9373].
「アルゴリズムのタイプ」値とeddsa hiエンコードは、[RFC9373]ごとに割り当てられます。
The HIT_SUITE_LIST parameter contains a list of the HIT suite IDs that the HIP Responder supports. The HIT_SUITE_LIST allows the HIP Initiator to determine which source HIT Suite IDs are supported by the Responder. The HIT_SUITE_LIST parameter is defined in Section 5.2.10 of [RFC7401].
HIT_SUITE_LISTパラメーターには、HIP ResponderがサポートするヒットスイートIDのリストが含まれています。HIT_SUITE_LISTを使用すると、HIPイニシエーターは、どのソースHITスイートIDがレスポンダーによってサポートされているかを判断できます。HIT_SUITE_LISTパラメーターは、[RFC7401]のセクション5.2.10で定義されています。
The following HIT Suite ID is defined:
次のヒットスイートIDが定義されています。
+=================+=======+
| HIT Suite | Value |
+=================+=======+
| EdDSA/cSHAKE128 | 5 |
+-----------------+-------+
Table 6: HIT Suite ID
表6：スイートIDをヒットします
Table 7 provides more detail on the above HIT Suite combination.
表7は、上記のヒットスイートの組み合わせの詳細を示します。
The output of cSHAKE128 is variable per the needs of a specific ORCHID construction. It is at most 96 bits long and is directly used in the ORCHID (without truncation).
CSHAKE128の出力は、特定のラン構造のニーズごとに変動します。最大96ビットの長さで、ランで直接使用されます（切り捨てなし）。
+=======+===========+=========+===========+====================+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+=======+===========+=========+===========+====================+
| 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed |
| | | | | with cSHAKE128, |
| | | | | output is variable |
+-------+-----------+---------+-----------+--------------------+
Table 7: HIT Suites
表7：スイートをヒットします
This section improves on ORCHIDv2 [RFC7343] with three enhancements:
このセクションでは、3つの機能強化を備えたorchidv2 [RFC7343]で改善されています。
* the inclusion of an optional "Info" field between the Prefix and ORCHID Generation Algorithm (OGA) ID.
* プレフィックスとオーキッドジェネレーションアルゴリズム（OGA）IDの間にオプションの「情報」フィールドを含める。
* an increase in flexibility on the length of each component in the ORCHID construction, provided the resulting ORCHID is 128 bits.
* オーキッド構造の各コンポーネントの長さの柔軟性の増加は、結果として生じるランが128ビットである場合、
* the use of cSHAKE [NIST.SP.800-185] for the hashing function.
* ハッシュ関数へのcshake [nist.sp.800-185]の使用。
The cSHAKE XOF hash function based on Keccak [Keccak] is a variable output length hash function. As such, it does not use the truncation operation that other hashes need. The invocation of cSHAKE specifies the desired number of bits in the hash output. Further, cSHAKE has a parameter 'S' as a customization bit string. This parameter will be used for including the ORCHID Context Identifier in a standard fashion.
Keccak [Keccak]に基づくCSHAKE XOFハッシュ関数は、可変出力長ハッシュ関数です。そのため、他のハッシュが必要とする切り捨て操作は使用しません。Cshakeの呼び出しは、ハッシュ出力に必要なビット数を指定します。さらに、Cshakeには、カスタマイズビット文字列としてパラメーター「s」があります。このパラメーターは、標準的な方法で蘭のコンテキスト識別子を含めるために使用されます。
This ORCHID construction includes the fields in the ORCHID in the hash to protect them against substitution attacks. It also provides for inclusion of additional information (in particular, the hierarchical bits of the HHIT) in the ORCHID generation. This should be viewed as an update to ORCHIDv2 [RFC7343], as it can produce ORCHIDv2 output.
このラン構造には、ハッシュの蘭の畑が含まれており、代替攻撃からそれらを保護します。また、オーキッド世代に追加情報（特に、HHITの階層ビット）を含めることもできます。これは、orchidv2出力を生成できるため、orchidv2 [rfc7343]の更新と見なす必要があります。
The following subsections define the new general ORCHID construct with the specific application for HHITs. Thus items like the hash size are only discussed in terms of how they impact the HHIT's 64-bit hash. Other hash sizes should be discussed for other specific uses of this new ORCHID construct.
次のサブセクションでは、HHITの特定のアプリケーションを使用して、新しい一般的なオーキッドコンストラクトを定義します。したがって、ハッシュサイズのような項目は、HHITの64ビットハッシュにどのように影響するかという点でのみ説明されています。他のハッシュサイズについては、この新しい蘭構造の他の特定の使用について説明する必要があります。
ORCHIDv2 [RFC7343] is defined as consisting of three components:
orchidv2 [rfc7343]は、3つのコンポーネントで構成されるものとして定義されています。
ORCHID := Prefix | OGA ID | Encode_96( Hash )
where:
ただし：
Prefix
プレフィックス
A constant 28-bit-long bitstring value (IPv6 prefix)
一定の28ビット長いビットストリング値（IPv6プレフィックス）
OGA ID
OGA ID
A 4-bit-long identifier for the Hash_function in use within the specific usage context. When used for HIT generation, this is the HIT Suite ID.
特定の使用状況内で使用されているHASH_FUNCTIONの4ビット識別子。ヒット生成に使用する場合、これはヒットスイートIDです。
Encode_96( )
encode_96（）
An extraction function in which output is obtained by extracting the middle 96-bit-long bitstring from the argument bitstring.
引数ビットストリングから中央の96ビット長いビットストリングを抽出することによって出力が得られる抽出関数。
The new ORCHID function is as follows:
新しい蘭関数は次のとおりです。
ORCHID := Prefix (p) | Info (n) | OGA ID (o) | Hash (m)
where:
ただし：
Prefix (p)
プレフィックス（P）
An IPv6 prefix of length p (max 28 bits long).
長さPのIPv6プレフィックス（長さ28ビット）。
Info (n)
情報（n）
n bits of information that define a use of the ORCHID. 'n' can be zero, which means no additional information.
蘭の使用を定義するnビットの情報。「n」はゼロになる可能性があります。つまり、追加情報はありません。
OGA ID (o)
oga id（o）
A 4- or 8-bit long identifier for the Hash_function in use within the specific usage context. When used for HIT generation, this is the HIT Suite ID [IANA-HIP]. When used for HHIT generation, this is the HHIT Suite ID [HHSI].
特定の使用状況で使用されているHASH_FUNCTIONの4ビットまたは8ビットの長い識別子。ヒット生成に使用する場合、これはヒットスイートID [iana-hip]です。HHIT生成に使用する場合、これはHHITスイートID [HHSI]です。
Hash (m)
ハッシュ（M）
An extraction function in which output is 'm' bits.
出力が「M」ビットである抽出関数。
Sizeof(p + n + o + m) = 128 bits
sizeof（p n o m）= 128ビット
The ORCHID length MUST be 128 bits. For HHITs with a 28-bit IPv6 prefix, there are 100 bits remaining to be divided in any manner between the additional information ("Info"), OGA ID, and the hash output. Consideration must be given to the size of the hash portion, taking into account risks like pre-image attacks. 64 bits, as used here for HHITs, may be as small as is acceptable. The size of 'n', for the HID, is then determined as what is left; in the case of the 8-bit OGA used for HHIT, this is 28 bits.
蘭の長さは128ビットでなければなりません。28ビットのIPv6プレフィックスを備えたHHITSの場合、追加情報（「情報」）、OGA ID、およびハッシュ出力の間にあらゆる方法で分割される100ビットがあります。イメージ前の攻撃などのリスクを考慮して、ハッシュ部分のサイズを考慮する必要があります。64ビットは、ここでHHITSに使用されているように、許容できるほど小さくなる可能性があります。HIDの「n」のサイズは、残っているものとして決定されます。HHITに使用される8ビットOGAの場合、これは28ビットです。
This update adds a different encoding process to that currently used in ORCHIDv2. The input to the hash function explicitly includes all the header content plus the Context ID. The header content consists of the Prefix, the Additional Information ("Info"), and the OGA ID (HIT Suite ID). Secondly, the length of the resulting hash is set by the sum of the length of the ORCHID header fields. For example, a 28-bit prefix with 28 bits for the HID and 8 bits for the OGA ID leaves 64 bits for the hash length.
この更新により、Orchidv2で現在使用されているエンコードプロセスに別のエンコードプロセスが追加されます。ハッシュ関数への入力には、すべてのヘッダーコンテンツとコンテキストIDが明示的に含まれます。ヘッダーコンテンツは、プレフィックス、追加情報（「情報」）、およびOGA ID（ヒットスイートID）で構成されています。第二に、結果のハッシュの長さは、ランヘッダーフィールドの長さの合計によって設定されます。たとえば、HIDに28ビット、OGA IDの8ビットを備えた28ビットのプレフィックスは、ハッシュの長さに64ビットを残します。
To achieve the variable length output in a consistent manner, the cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. The cSHAKE function call is:
一貫した方法で可変長さ出力を実現するために、Cshakeハッシュが使用されます。この目的のために、CShake128が適切です。cshake関数呼び出しは次のとおりです。
cSHAKE128(Input, L, "", Context ID)
Input := Prefix | Additional Information | OGA ID | HOST_ID
L := Length in bits of the hash portion of ORCHID
For full Suite ID support (those that use fixed length hashes like SHA256), the following hashing can be used (Note: this does not produce output identical to ORCHIDv2 for a /28 prefix and Additional Information of zero length):
完全なスイートIDサポート（SHA256のような固定長ハッシュを使用するもの）の場合、次のハッシュを使用できます（注：これは、A /28プレフィックスとゼロ長の追加情報のORCHIDV2と同一の出力を生成しません）：
Hash[L](Context ID | Input)
Input := Prefix | Additional Information | OGA ID | HOST_ID
L := Length in bits of the hash portion of ORCHID
Hash[L] := An extraction function in which output is obtained
by extracting the middle L-bit-long bitstring
from the argument bitstring.
The middle L-bits are those bits from the source number where either there is an equal number of bits before and after these bits, or there is one more bit prior (when the difference between hash size and L is odd).
中央のLビットは、これらのビットの前後に同じ数のビットがあるか、もう1つのビットがあるか、もう1つのビットがあるソース番号からのビットです（ハッシュサイズとLの違いが奇妙な場合）。
HHITs use the Context ID defined in Section 3.
HHITは、セクション3で定義されているコンテキストIDを使用します。
This section discusses how to provide backwards compatibility for ORCHIDv2 [RFC7343] as used in HIPv2 [RFC7401].
このセクションでは、HIPV2 [RFC7401]で使用されているOrchidv2 [RFC7343]の後方互換性を提供する方法について説明します。
For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]). 'Info' is zero-length (i.e., not included), and OGA ID is 4-bit. Thus, the HI Hash is 96 bits in length. Further, the Prefix and OGA ID are not included in the hash calculation. Thus, the following ORCHID calculations for fixed output length hashes are used:
HIPV2の場合、プレフィックスは2001：20 ::/28（[RFC7343]のセクション6）です。「情報」はゼロ長（つまり、含まれていません）であり、OGA IDは4ビットです。したがって、HIハッシュの長さは96ビットです。さらに、プレフィックスとOGA IDはハッシュ計算に含まれていません。したがって、固定出力長ハッシュの次の蘭計算が使用されます。
Hash[L](Context ID | Input)
Input := HOST_ID
L := 96
Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA
Hash[L] := An extraction function in which output is obtained
by extracting the middle L-bit-long bitstring
from the argument bitstring.
For variable output length hashes use:
可変出力の長さのハッシュを使用して使用します。
Hash[L](Context ID | Input)
Input := HOST_ID
L := 96
Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA
Hash[L] := The L-bit output from the hash function
Then, the ORCHID is constructed as follows:
次に、ランは次のように構築されます。
Prefix | OGA ID | Hash Output
With this update, the decoding of an ORCHID is determined by the Prefix and OGA ID. ORCHIDv2 [RFC7343] decoding is selected when the Prefix is: 2001:20::/28.
この更新により、蘭のデコードはプレフィックスとOGA IDによって決定されます。orchidv2 [rfc7343]デコードは、プレフィックスが2001：20 ::/28の場合に選択されます。
For HHITs, the decoding is determined by the presence of the HHIT Prefix as specified in Section 8.2.
HHITの場合、デコードは、セクション8.2で指定されているHHITプレフィックスの存在によって決定されます。
This section is included to provide backwards compatibility for ORCHIDv2 [RFC7343] as used for HIPv2 [RFC7401].
このセクションは、HIPV2 [RFC7401]に使用されるOrchidv2 [RFC7343]の逆方向の互換性を提供するために含まれています。
HITs are identified by a Prefix of 2001:20::/28. The next 4 bits are the OGA ID. The remaining 96 bits are the HI Hash.
ヒットは、2001年：20 ::/28のプレフィックスによって識別されます。次の4ビットはOGA IDです。残りの96ビットはHIハッシュです。
HHITs for UAS ID (called, DETs) use the new EdDSA/SHAKE128 HIT suite defined in Section 3.4 (GEN-2 in [RFC9153]). This hierarchy, cryptographically bound within the HHIT, provides the information for finding the UA's HHIT registry (ID-3 in [RFC9153]).
UAS IDのHHIT（呼び出し、DETS）は、セクション3.4（[RFC9153]のGEN-2）で定義されている新しいEDDSA/SHAKE128ヒットスイートを使用します。HHIT内に暗号化されたこの階層は、UAのHHITレジストリ（[RFC9153]のID-3）を見つけるための情報を提供します。
The ASTM Standard Specification for Remote ID and Tracking [F3411-22a] adds support for DETs. This is only available via the new UAS ID type 4, "Specific Session ID (SSI)".
リモートIDおよび追跡[F3411-22A]のASTM標準仕様は、DETSのサポートを追加します。これは、新しいUAS IDタイプ4「特定のセッションID（SSI）」を介してのみ利用できます。
This new SSI uses the first byte of the 20-byte UAS ID for the SSI Type, thus restricting the UAS ID of this type to a maximum of 19 bytes. The SSI Types initially assigned are:
この新しいSSIは、SSIタイプに20バイトUAS IDの最初のバイトを使用するため、このタイプのUAS IDを最大19バイトに制限します。最初に割り当てられたSSIタイプは次のとおりです。
SSI 1:
SSI 1：
IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.
IETF -DRIPドローンリモートIDプロトコル（DRIP）エンティティID。
SSI 2:
SSI 2：
3GPP - IEEE 1609.2-2016 HashedID8
3GPP -IEEE 1609.2-2016 Hashedid8
A HI and its DET SHOULD NOT be transferable between UAs or even between replacement electronics (e.g., replacement of damaged controller CPU) for a UA. The private key for the HI SHOULD be held in a cryptographically secure component.
HIとそのDETは、UASの間で、またはUAの交換用エレクトロニクス（損傷したコントローラーCPUの交換など）の間でさえ移行してはなりません。HIの秘密鍵は、暗号化されたコンポーネントに保持する必要があります。
In some cases, it is advantageous to encode HHITs as a CTA 2063-A Serial Number [CTA2063A]. For example, the FAA Remote ID Rules [FAA_RID] state that a Remote ID Module (i.e., not integrated with UA controller) must only use "the serial number of the unmanned aircraft"; CTA 2063-A meets this requirement.
場合によっては、HHITをCTA 2063-Aシリアル番号[CTA2063A]としてエンコードすることが有利です。たとえば、FAAリモートIDルール[FAA_RID]は、リモートIDモジュール（つまり、UAコントローラーと統合されていない）は「無人航空機のシリアル番号」のみを使用する必要があると述べています。CTA 2063-Aはこの要件を満たしています。
Encoding a HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows:
CTA 2063-A形式内でHHITをエンコードするのは簡単ではありません。CTA 2063-A形式は次のように定義されています。
Serial Number := MFR Code | Length Code | MFR SN
where:
ただし：
MFR Code
MFRコード
4 character code assigned by ICAO (International Civil Aviation Organization, a UN Agency).
4 ICAO（国際民間航空機関、国連機関）によって割り当てられた4文字コード。
Length Code
長さコード
1 character Hex encoding of MFR SN length (1-F).
MFR SNの長さ（1-F）の1文字ヘックスエンコード。
MFR SN
MFR SN
US-ASCII alphanumeric code (0-9, A-Z except O and I). Maximum length of 15 characters.
US-ASCII英数字コード（OおよびIを除くA-Z）。15文字の最大長。
There is no place for the HID; there will need to be a mapping service from Manufacturer Code to HID. The HHIT Suite ID and ORCHID hash will take the full 15 characters (as described below) of the MFR SN field.
HIDの場所はありません。メーカーコードからHIDにマッピングサービスが必要です。HHITスイートIDとOrchid Hashは、MFR SNフィールドの15文字（以下で説明する）を完全に取得します。
A character in a CTA 2063-A Serial Number "shall include any combination of digits and uppercase letters, except the letters O and I, but may include all digits". This would allow for a Base34 encoding of the binary HHIT Suite ID and ORCHID hash in 15 characters. Although, programmatically, such a conversion is not hard, other technologies (e.g., credit card payment systems) that have used such odd base encoding have had performance challenges. Thus, here a Base32 encoding will be used by also excluding the letters Z and S (because they are too similar to the digits 2 and 5, respectively). See Appendix C for the encoding scheme.
CTA 2063-aシリアル番号の文字は、文字oとiを除き、桁と大文字の任意の組み合わせを含むが、すべての数字が含まれる場合がある」。これにより、15文字でバイナリHHITスイートIDとランハッシュのBase34エンコードが可能になります。プログラムでは、このような変換は難しくありませんが、このような奇妙なベースエンコードを使用した他のテクノロジー（クレジットカード支払いシステムなど）にはパフォーマンスの課題がありました。したがって、ここでは、文字zとsを除外することによってBase32エンコードが使用されます（それぞれ数字2と5に似ているため）。エンコーディングスキームについては、付録Cを参照してください。
The low-order 72 bits (HHIT Suite ID | ORCHID hash) of the HHIT SHALL be left-padded with 3 bits of zeros. This 75-bit number will be encoded into the 15-character MFR SN field using the digit/letters as described above. The manufacturer MUST use a Length Code of F (15).
HHITの低次の72ビット（HHITスイートID |オーキッドハッシュ）には、3ビットのゼロで左パッドされなければなりません。この75ビット番号は、上記のように数字/文字を使用して15文字のMFR SNフィールドにエンコードされます。メーカーは、F（15）の長さコードを使用する必要があります。
Note: The manufacturer MAY use the same Manufacturer Code with a Length Code of 1 - E (1 - 14) for other types of serial numbers.
注：メーカーは、他のタイプのシリアル番号に対して1 -E（1-14）の長さコードを持つ同じメーカーコードを使用できます。
Using the sample DET from Section 5 that is for HDA=20 under RAA=10 and having the ICAO CTA MFR Code of 8653, the 20-character CTA 2063-A Serial Number would be:
RAA = 10の下でHDA = 20用のセクション5からのサンプルDETを使用し、8653のICAO CTA MFRコードを使用すると、20文字のCTA 2063-Aシリアル番号は次のとおりです。
8653F02T7B8RA85D19LX
A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to high-order 58 bits (Prefix | HID) of the HHIT. That is, given a Manufacturer Code, a returned Prefix|HID value is reliable. Definition of this mapping service is out of scope of this document.
マッピングサービス（例：DNS）は、4文字のメーカーコードをHHITの高次58ビット（プレフィックス| hid）に4文字のメーカーコードからの信頼できる（例：DNSSEC [RFC4034]を介して）変換）を提供する必要があります。つまり、メーカーのコードが与えられている場合、返されたプレフィックス| HID値は信頼できます。このマッピングサービスの定義は、このドキュメントの範囲外です。
It should be noted that this encoding would only be used in the Basic ID Message (Section 2.2 of [RFC9153]). The DET is used in the Authentication Messages (i.e., the messages that provide framing for authentication data only).
このエンコードは、基本的なIDメッセージ（[RFC9153]のセクション2.2）でのみ使用されることに注意する必要があります。DETは、認証メッセージ（つまり、認証データのみのフレーミングのみを提供するメッセージ）で使用されます。
UAS Remote ID DET may be one of a number of uses of HHITs. However, it is out of the scope of the document to elaborate on other uses of HHITs. As such these follow-on uses need to be considered in allocating the RAAs (Section 3.3.1) or HHIT prefix assignments (Section 8).
UASリモートID DETは、HHITの多くの使用の1つである可能性があります。ただし、HHITの他の使用について詳しく説明することは、ドキュメントの範囲外です。そのため、これらのフォローオンの使用は、RAAS（セクション3.3.1）またはHHITプレフィックスの割り当て（セクション8）の割り当てで考慮する必要があります。
ORCHIDS, as defined in [RFC7343], do not cryptographically bind an IPv6 prefix or the OGA ID (the HIT Suite ID) to the hash of the HI. At the time ORCHID was being developed, the rationale was attacks against these fields are Denial-of-Service (DoS) attacks against protocols using ORCHIDs and thus it was up to those protocols to address the issue.
[RFC7343]で定義されている蘭は、IPv6プレフィックスまたはOGA ID（ヒットスイートID）をHIのハッシュに暗号化しないでください。Orchidが開発されていたとき、理論的根拠は、これらのフィールドに対する攻撃であり、Orchidsを使用したプロトコルに対するサービス拒否（DOS）攻撃であり、したがって、問題に対処するためのプロトコル次第でした。
HHITs, as defined in Section 3.5, cryptographically bind all content in the ORCHID through the hashing function. A recipient of a DET that has the underlying HI can directly trust and act on all content in the HHIT. This provides a strong, self-claim for using the hierarchy to find the DET Registry based on the HID (Section 4.5).
セクション3.5で定義されているHHITは、ハッシュ機能を介して蘭のすべてのコンテンツを暗号化します。基礎となるHIを持っているDETの受信者は、HHITのすべてのコンテンツに直接信頼し、行動できます。これは、階層を使用してHIDに基づいてDETレジストリを見つけるための強力な自己訴訟を提供します（セクション4.5）。
DETs are registered to HDAs. The registration process defined in [DRIP-REG] ensures DET global uniqueness (ID-4 in Section 4.2.1 of [RFC9153]). It also allows the mechanism to create UAS public/ private data that are associated with the DET (REG-1 and REG-2 in Section 4.4.1 of [RFC9153]).
DETはHDASに登録されます。[DRIP-REG]で定義されている登録プロセスにより、Det Globalの一意性が保証されます（[RFC9153]のセクション4.2.1のID-4）。また、メカニズムは、[RFC9153]のセクション4.4.1のREG-1およびREG-2）に関連付けられているUASパブリック/プライベートデータを作成することもできます。
The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an 88-byte self-proof evidence (timestamps, HHIT, and signature of these) to provide proof to Observers of Remote ID ownership (GEN-1 in Section 4.1.1 of [RFC9153]). In practice, the Wrapper and Manifest authentication formats (Sections 6.3.3 and 6.3.4 of [DRIP-AUTH]) implicitly provide this self-proof evidence. A lookup service like DNS can provide the HI and registration proof (GEN-3 in [RFC9153]).
DETの根底にあるEDDSA25519 HI（セクション3.4）は、88バイトの自己防止証拠（タイムスタンプ、HHIT、およびこれらの署名）で使用できます。[rfc9153]）。実際には、ラッパーとマニフェスト認証形式（[drip-auth]のセクション6.3.3および6.3.4）は、この自己防御の証拠を暗黙的に提供します。DNSのようなルックアップサービスは、HIおよび登録証明を提供できます（[RFC9153]のGen-3）。
Similarly, for Observers without Internet access, a 200-byte offline self-endorsement (Section 3.1.2 of [DRIP-AUTH]) could provide the same Remote ID ownership proof. This endorsement would contain the HDA's signing of the UA's HHIT, itself signed by the UA's HI. Only a small cache (also Section 3.1.2 of [DRIP-AUTH]) that contains the HDA's HI/HHIT and HDA meta-data is needed by the Observer. However, such an object would just fit in the ASTM Authentication Message (Section 2.2 of [RFC9153]) with no room for growth. In practice, [DRIP-AUTH] provides this offline self-endorsement in two authentication messages: the HDA's endorsement of the UA's HHIT registration in a Link authentication message whose hash is sent in a Manifest authentication message.
同様に、インターネットアクセスのないオブザーバーの場合、200バイトのオフラインの自己保護（[drip-auth]のセクション3.1.2）が同じリモートIDの所有権を提供できます。この承認には、UAのHIによって署名されたUAのHHITのHDAの署名が含まれます。HDAのHI/HHITおよびHDAメタデータを含む小さなキャッシュ（[DRIP-Auth]のセクション3.1.2）のみが、観察者が必要としています。ただし、そのようなオブジェクトは、成長の余地がなく、ASTM認証メッセージ（[RFC9153]のセクション2.2）に適合します。実際には、[DRIP-AUTH]は、2つの認証メッセージでこのオフラインの自己承認を提供します。HDAのHDAが、ハッシュがマニフェスト認証メッセージで送信されるリンク認証メッセージでのUAのHHIT登録の承認です。
Hashes of any previously sent ASTM messages can be placed in a Manifest authentication message (GEN-2 in [RFC9153]). When a Location/Vector Message (i.e., a message that provides UA location, altitude, heading, speed, and status) hash along with the hash of the HDA's UA HHIT endorsement are sent in a Manifest authentication message and the Observer can visually see a UA at the claimed location, the Observer has very strong proof of the UA's Remote ID.
以前に送信されたASTMメッセージのハッシュは、マニフェスト認証メッセージ（[RFC9153]のGen-2）に配置できます。位置/ベクトルメッセージ（つまり、UAロケーション、高度、見出し、速度、ステータスを提供するメッセージ）とHDAのUA HHIT承認のハッシュとともにハッシュがマニフェスト認証メッセージで送信され、オブザーバーは視覚的に見ることができます。UAが主張されている場所で、オブザーバーはUAのリモートIDの非常に強力な証拠を持っています。
This behavior and how to mix these authentication messages into the flow of UA operation messages are detailed in [DRIP-AUTH].
この動作とこれらの認証メッセージをUA操作メッセージのフローに組み合わせる方法は、[DRIP-Auth]で詳しく説明されています。
There are two approaches for storing and retrieving DETs using DNS. The following are examples of how this may be done. This serves as guidance to the actual deployment of DETs in DNS. However, this document does not provide a recommendation about which approach to use. Further DNS-related considerations are covered in [DRIP-REG].
DNSを使用してDETを保存および取得するための2つのアプローチがあります。以下は、これがどのように行われるかの例です。これは、DNSでのDETの実際の展開のガイダンスとして機能します。ただし、このドキュメントでは、使用するアプローチに関する推奨事項は提供されません。さらにDNS関連の考慮事項は、[Drip-Reg]で説明されています。
* As FQDNs, for example, "20010030.hhit.arpa.".
* たとえば、fqdnsとして、「20010030.hhit.arpa」として。
* Reverse DNS lookups as IPv6 addresses per [RFC8005].
* [RFC8005]あたりのIPv6アドレスとしての逆DNSルックアップ。
A DET can be used to construct an FQDN that points to the USS that has the public/private information for the UA (REG-1 and REG-2 in Section 4.4.1 of [RFC9153]). For example, the USS for the HHIT could be found via the following: assume the RAA is decimal 100 and the HDA is decimal 50. The PTR record is constructed as follows:
DETを使用して、UAのパブリック/個人情報を持つUSSを指すFQDNを構築することができます（[RFC9153]のセクション4.4.1のREG-1およびREG-2）。たとえば、HHITのUSSは次のことを介して見つけることができます。RAAが10進数で、HDAは小数50であると仮定します。PTRレコードは次のように作成されます。
100.50.20010030.hhit.arpa. IN PTR foo.uss.example.org.
The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response.
HDAは、そのゾーンにDNSサービスを提供し、HHITの詳細応答を提供する必要があります。
The DET reverse lookup can be a standard IPv6 reverse look up, or it can leverage off the HHIT structure. Using the allocated prefix for HHITs 2001:30::/28 (see Section 3.1), the RAA is decimal 10 and the HDA is decimal 20, the DET is:
Det Reverse Lookupは、標準のIPv6リバースルックアップであるか、HHIT構造を活用できます。HHITS 2001：30 ::/28に割り当てられたプレフィックスを使用して（セクション3.1を参照）、RAAは10進10で、HDAは10進数です。
2001:30:280:1405:a3ad:1952:ad0:a69e
See Appendix B.1 for how the upper 64 bits, above, are constructed. A DET reverse lookup could be:
上記の64ビットの構築方法については、付録B.1を参照してください。Det Reverse Lookupは次のとおりです。
a69e.0ad0.1952.a3ad.1405.0280.20.10.20010030.hhit.arpa.
or:
または：
a3ad19520ad0a69e.5.20.10.20010030.hhit.arpa.
A 'standard' ip6.arpa RR has the advantage of only one Registry service supported.
「標準」IP6.ARPA RRには、サポートされているレジストリサービスが1つだけの利点があります。
$ORIGIN 5.0.4.1.0.8.2.0.0.3.0.0.1.0.0.2.ip6.arpa.
e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR
a3ad1952ad0a69e.20.10.20010030.hhit.arpa.
This DNS entry for the DET can also provide a revocation service. For example, instead of returning the HI RR it may return some record showing that the HI (and thus DET) has been revoked. Guidance on revocation service will be provided in [DRIP-REG].
DETのこのDNSエントリは、取り消しサービスを提供することもできます。たとえば、HI RRを返す代わりに、HI（およびDET）が取り消されたことを示す記録を返す可能性があります。取り消しサービスに関するガイダンスは、[Drip-Reg]で提供されます。
HHITs will be used within the UTM architecture beyond DET (and USS in UA ID registration and authentication), for example, as a Ground Control Station (GCS) HHIT ID. Some GCS will use its HHIT for securing its Network Remote ID (to USS HHIT) and Command and Control (C2, Section 2.2.2 of [RFC9153]) transports.
HHITは、たとえば地上統制ステーション（GCS）HHIT IDとして、Detを超えてUTMアーキテクチャ（およびUA ID登録と認証のUSS）内で使用されます。一部のGCは、そのHHITを使用して、ネットワークリモートID（USS HHIT）とコマンドおよびコントロール（[RFC9153]のセクション2.2.2）輸送を保護します。
Observers may have their own HHITs to facilitate UAS information retrieval (e.g., for authorization to private UAS data). They could also use their HHIT for establishing a HIP connection with the UA Pilot for direct communications per authorization. Details about such issues are out of the scope of this document.
オブザーバーは、UAS情報検索を容易にするために独自のHHITを持っている場合があります（たとえば、プライベートUASデータへの承認のため）。また、承認ごとに直接通信するために、UAパイロットとの股関節接続を確立するためにHHITを使用することもできます。このような問題に関する詳細は、このドキュメントの範囲外です。
This document provides the details to solutions for GEN 1 - 3, ID 1 - 5, and REG 1 - 2 requirements that are described in [RFC9153].
このドキュメントは、[RFC9153]で説明されているGen 1-3、ID 1-5、およびReg 1-2の要件のソリューションへの詳細を提供します。
Since the DET format is not compatible with [RFC7343], IANA has allocated the following prefix per this template for the "IANA IPv6 Special-Purpose Address Registry" [IPv6-SPECIAL].
DET形式は[RFC7343]と互換性がないため、IANAは「IANA IPv6 Special-Purposeアドレスレジストリ」[IPv6-Special]のこのテンプレートに従って次のプレフィックスを割り当てました。
Address Block:
アドレスブロック：
2001:30::/28
2001：30 ::/28
Name:
名前：
Drone Remote ID Protocol Entity Tags (DETs) Prefix
ドローンリモートIDプロトコルエンティティタグ（DETS）プレフィックス
Reference
参照
This document
このドキュメント
Allocation Date:
割り当て日：
2022-12
2022-12
Termination Date:
退職日：
N/A
n/a
Source:
ソース：
True
真実
Destination:
行き先：
True
真実
Forwardable:
フォローダブル：
True
真実
Globally Reachable:
グローバルに到達可能：
True
真実
Reserved-by-Protocol:
プロトコルごとに予約済み：
False
間違い
IANA has created the "Drone Remote ID Protocol" registry. The following two subregistries have been created within the "Drone Remote ID Protocol" group.
IANAは、「ドローンリモートIDプロトコル」レジストリを作成しました。「ドローンリモートIDプロトコル」グループ内で、次の2つのサブレジストリが作成されました。
Initially, for DET use, one 28-bit prefix has been assigned out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890]. Future additions to this subregistry are to be made through Expert Review (Section 4.5 of [RFC8126]). Entries with network-specific prefixes may be present in the registry.
当初、Det使用のために、[RFC6890]に従って、IANA IPv6 Special目的アドレスブロック、つまり2001 ::/23の1つの28ビットプレフィックスが割り当てられています。このサブレジストリへの将来の追加は、専門家のレビュー（[RFC8126]のセクション4.5）を通じて行われます。ネットワーク固有のプレフィックスを備えたエントリは、レジストリに存在する場合があります。
+==========+======+==============+===========+
| HHIT Use | Bits | Value | Reference |
+==========+======+==============+===========+
| DET | 28 | 2001:30::/28 | RFC 9374 |
+----------+------+--------------+-----------+
Table 8: Registered DET IPv6 Prefix
表8：登録されたDET IPv6プレフィックス
Criteria that should be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality and whether the registration description is clear and fits the purpose of this registry.
指定された専門家が適用すべき基準には、提案された登録が既存の機能を複製しているかどうか、登録の説明が明確であるかどうかを決定することが含まれます。
Registration requests MUST be sent to drip-reg-review@ietf.org and be evaluated within a three-week review period on the advice of one or more designated experts. Within that review period, the designated experts will either approve or deny the registration request, and communicate their decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions to successfully register the prefix.
登録リクエストは、drip-reg-review@ietf.orgに送信され、1人以上の指定された専門家のアドバイスについて3週間のレビュー期間内に評価される必要があります。そのレビュー期間内に、指定された専門家は登録要求を承認または拒否し、決定をレビューリストとIANAに伝えます。拒否には、説明を含める必要があり、該当する場合は、プレフィックスを正常に登録するための提案を含める必要があります。
Registration requests that are undetermined for a period longer than 28 days can be brought to the IESG's attention for resolution.
28日以上にわたって未定の登録要求は、解決のためにIESGの注意を引くことができます。
This 8-bit value subregistry is a superset of the 4/8-bit "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry [IANA-HIP]. Future additions to this subregistry are to be made through IETF Review (Section 4.8 of [RFC8126]). The following HHIT Suite IDs are defined.
この8ビット値サブレジストリは、「ホストIDプロトコル（HIP）パラメーター」レジストリ[IANA-HIP]の4/8ビット「ヒットスイートID」サブレジストリのスーパーセットです。このサブレジストリへの将来の追加は、IETFレビュー（[RFC8126]のセクション4.8）を通じて行われます。次のHHITスイートIDが定義されています。
+===================+=======+===========+
| HHIT Suite | Value | Reference |
+===================+=======+===========+
| RESERVED | 0 | RFC 9374 |
+-------------------+-------+-----------+
| RSA,DSA/SHA-256 | 1 | [RFC7401] |
+-------------------+-------+-----------+
| ECDSA/SHA-384 | 2 | [RFC7401] |
+-------------------+-------+-----------+
| ECDSA_LOW/SHA-1 | 3 | [RFC7401] |
+-------------------+-------+-----------+
| EdDSA/cSHAKE128 | 5 | RFC 9374 |
+-------------------+-------+-----------+
| HDA Private Use 1 | 254 | RFC 9374 |
+-------------------+-------+-----------+
| HDA Private Use 2 | 255 | RFC 9374 |
+-------------------+-------+-----------+
Table 9: Registered HHIT Suite IDs
表9：登録されたHHITスイートID
The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be replicated as HIT Suite IDs (Section 8.4) as is 5 here. Higher values (32 - 255) are for those Suite IDs that need not or cannot be accommodated as a HIT Suite ID.
HHITスイートID値1-31は、ここで5と同様に、ヒットスイートID（セクション8.4）として複製する必要があるIDに予約されています。より高い値（32-255）は、ヒットスイートIDとして対応する必要がない、または収容できないスイートIDのためです。
This document has been added as a reference for the "CGA Extension Type Tags" registry [IANA-CGA]. IANA has the following Context ID in this registry:
このドキュメントは、「CGA拡張タイプのタグ」レジストリ[IANA-CGA]のリファレンスとして追加されています。IANAには、このレジストリに次のコンテキストIDがあります。
Context ID:
コンテキストID：
The Context ID (Section 3) shares the namespace introduced for CGA Type Tags. The following Context ID is defined per the rules in Section 8 of [RFC3972]:
コンテキストID（セクション3）は、CGAタイプのタグに導入された名前空間を共有します。次のコンテキストIDは、[RFC3972]のセクション8のルールに従って定義されています。
+===========================================+===========+
| CGA Type Tag | Reference |
+===========================================+===========+
| 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 | RFC 9374 |
+-------------------------------------------+-----------+
Table 10: CGA Extension Type Tags
表10：CGA拡張タイプのタグ
IANA has updated the "Host Identity Protocol (HIP) Parameters" registry [IANA-HIP] as described below.
IANAは、以下に説明するように、「ホストIDプロトコル（HIP）パラメーター」レジストリ[IANA-HIP]を更新しました。
Host ID:
ホストID：
This document defines the new EdDSA Host ID with value 13 (Section 3.4.1) in the "HI Algorithm" subregistry of the "Host Identity Protocol (HIP) Parameters" registry.
このドキュメントでは、「Hi Algorithm」の「Host Identity Identity Protocol（HIP）パラメーター」のサブレジストリで、値13（セクション3.4.1）を持つ新しいEDDSAホストIDを定義します。
+===================+=======+===========+
| Algorithm Profile | Value | Reference |
+===================+=======+===========+
| EdDSA | 13 | [RFC8032] |
+-------------------+-------+-----------+
Table 11: Registered HI Algorithm
表11：登録されたHIアルゴリズム
EdDSA Curve Label:
EDDSAカーブラベル：
This document specifies a new algorithm-specific subregistry named "EdDSA Curve Label". The values for this subregistry are defined in Section 3.4.1.1. Future additions to this subregistry are to be made through IETF Review (Section 4.8 of [RFC8126]).
このドキュメントは、「Eddsa Curve Label」という名前の新しいアルゴリズム固有のサブレジストリを指定します。このサブレジストリの値は、セクション3.4.1.1で定義されています。このサブレジストリへの将来の追加は、IETFレビュー（[RFC8126]のセクション4.8）を通じて行われます。
+===========+==============+=========+============+
| Algorithm | Curve | Value | Reference |
+===========+==============+=========+============+
| EdDSA | RESERVED | 0 | RFC 9374 |
+-----------+--------------+---------+------------+
| EdDSA | EdDSA25519 | 1 | [RFC8032] |
+-----------+--------------+---------+------------+
| EdDSA | EdDSA25519ph | 2 | [RFC8032] |
+-----------+--------------+---------+------------+
| EdDSA | EdDSA448 | 3 | [RFC8032] |
+-----------+--------------+---------+------------+
| EdDSA | EdDSA448ph | 4 | [RFC8032] |
+-----------+--------------+---------+------------+
| | | 5-65535 | Unassigned |
+-----------+--------------+---------+------------+
Table 12: Registered EdDSA Curve Labels
表12：登録されたEDDSA曲線ラベル
HIT Suite ID:
ヒットスイートID：
This document defines the new HIT Suite of EdDSA/cSHAKE with value 5 (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry.
このドキュメントでは、「HOT SUITE ID」サブレジストリの「HIT SUITE ID（HIP）パラメーター」レジストリで、値5（セクション3.4.2）のEDDSA/CSHAKEの新しいヒットスイートを定義します。
+=================+=======+===========+
| Suite ID | Value | Reference |
+=================+=======+===========+
| EdDSA/cSHAKE128 | 5 | RFC 9374 |
+-----------------+-------+-----------+
Table 13: Registered HIT Suite of EdDSA/cSHAKE
表13：eddsa/cshakeの登録ヒットスイート
The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.
ヒットスイートID 4ビット値1-15および8ビット値0x00-0x0fは、ここで5と同様にHHITスイートID（セクション8.2）として複製する必要があります。
The 64-bit hash in HHITs presents a real risk of second pre-image cryptographic hash attack (see Section 9.5). There are no known (to the authors) studies of hash size impact on cryptographic hash attacks.
HHITSの64ビットハッシュは、2回目のイメージ前の暗号化ハッシュ攻撃の実際のリスクを示しています（セクション9.5を参照）。暗号化ハッシュ攻撃に対するハッシュサイズの影響に関する（著者に）既知の研究はありません。
However, with today's computing power, producing 2^64 EdDSA keypairs and then generating the corresponding HHIT is economically feasible. Consider that a *single* bitcoin mining ASIC can do on the order of 2^46 sha256 hashes per second or about 2^62 hashes in a single day. The point being, 2^64 is not prohibitive, especially as this can be done in parallel.
ただし、今日のコンピューティング能力により、2^64 EDDSAキーピアを生成し、対応するHHITを生成することは経済的に実行可能です。*シングル *ビットコインマイニングASICは、1秒あたり2^46 SHA256ハッシュ、または1日で約2^62ハッシュを行うことができることを考えてください。ポイントは、2^64は禁止されていません。特に、これは並行して行うことができるためです。
Note that the 2^64 attempts is for stealing a specific HHIT. Consider a scenario of a street photography company with 1,024 UAs (each with its own HHIT); an attacker may well be satisfied stealing any one of them. Then, rather than needing to satisfy a 64-bit condition on the cSHAKE128 output, an attacker only needs to satisfy what is equivalent to a 54-bit condition (since there are 2^10 more opportunities for success).
2^64の試行は、特定のHHITを盗むためのものであることに注意してください。1,024 UAS（それぞれ独自のHHITを備えた）を持つストリートフォトグラフィーカンパニーのシナリオを考えてみましょう。攻撃者は、それらのいずれかを盗むことに満足するかもしれません。次に、CSHAKE128出力の64ビット条件を満たす必要があるのではなく、攻撃者は54ビット条件に相当するものを満たす必要があります（成功する機会が2^10^10^10があるため）。
Thus, although the probability of a collision or pre-image attack is low in a collection of 1,024 HHITs out of a total population of 2^64 (per Section 9.5), it is computationally and economically feasible. Therefore, the HHIT registration is a MUST and HHIT/HI registration validation SHOULD be performed by Observers either through registry lookups or via broadcasted registration proofs (Section 3.1.2 of [DRIP-AUTH]).
したがって、2^64（セクション9.5ごとに）の総人口のうち1,024 Hhitのコレクションでは、衝突または前の攻撃の確率が低いですが、計算可能および経済的に実現可能です。したがって、HHIT登録は必須であり、HHIT/HI登録検証は、レジストリ検索またはブロードキャスト登録証明（[DRIP-Auth]のセクション3.1.2）を介してオブザーバーが実行する必要があります。
The DET Registry services effectively block attempts to "take over" or "hijack" a DET. It does not stop a rogue attempting to impersonate a known DET. This attack can be mitigated by the receiver of messages containing DETs using DNS to find the HI for the DET. As such, use of DNSSEC by the DET registries is recommended to provide trust in HI retrieval.
DETレジストリサービスは、DETを「引き継ぐ」または「ハイジャック」しようとする試みを効果的にブロックします。既知のdetになりすまそうとする不正を止めません。この攻撃は、DNSを使用したDETを含むメッセージの受信者がDETのHIを見つけることによって軽減できます。そのため、HI検索に信頼を提供するために、DNSSECの使用を推奨することをお勧めします。
Another mitigation of HHIT hijacking is when the HI owner (UA) supplies an object containing the HHIT that is signed by the HI private key of the HDA as detailed in [DRIP-AUTH].
HHITハイジャックのもう1つの緩和は、HI所有者（UA）が[drip-auth]に詳述されているように、HDAのHI秘密鍵によって署名されたHHITを含むオブジェクトを提供する場合です。
The two risks with HHITs are the use of an invalid HID and forced HIT collisions. The use of a DNS zone (e.g., "det.arpa.") is strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service [DRIP-REG], through its HHIT uniqueness enforcement, provides against forced or accidental HHIT hash collisions.
HHITの2つのリスクは、無効なHIDと強制ヒット衝突の使用です。DNSゾーンの使用（例：「det.arpa。」）は、無効な隠れ家に対する強力な保護です。HDAの下でのヒットのためにHDAのRVを照会することは、未登録のクライアントとの会話から保護されます。レジストリサービス[Drip-Reg]は、その独自性の執行を通じて、強制的または偶発的なHHITハッシュ衝突に対して提供されます。
Cryptographically Generated Addresses (CGAs) provide an assurance of uniqueness. This is two-fold. The address (in this case the UAS ID) is a hash of a public key and a Registry hierarchy naming. Collision resistance (and more importantly, the implied second-preimage resistance) makes attacks statistically challenging. A registration process [DRIP-REG] within the HDA provides a level of assured uniqueness unattainable without mirroring this approach.
暗号化されたアドレス（CGA）は、一意性の保証を提供します。これは2つあります。アドレス（この場合はUAS ID）は、公開キーとレジストリ階層の命名のハッシュです。衝突抵抗（そして、さらに重要なことに、暗黙の2番目のプレイマージ抵抗）は、攻撃を統計的に困難にします。HDA内の登録プロセス[DRIP-REG]は、このアプローチを反映せずに達成不可能なレベルの保証された一意性を提供します。
The second aspect of assured uniqueness is the digital signing (evidence) process of the DET by the HI private key and the further signing (evidence) of the HI public key by the Registry's key. This completes the ownership process. The observer at this point does not know what owns the DET but is assured, other than the risk of theft of the HI private key, that this UAS ID is owned by something and it is properly registered.
保証された一意性の2番目の側面は、HI秘密鍵によるDETのデジタル署名（証拠）プロセスと、レジストリのキーによるHI公開鍵のさらなる署名（証拠）です。これにより、所有プロセスが完了します。この時点でのオブザーバーは、HIの秘密鍵の盗難のリスクを除いて、このUAS IDが何かが所有し、適切に登録されていることを除いて、DETを所有しているものを知りませんが、保証されています。
As stated in Section 8.1 of [DRIP-ARCH], there has been no effort to address post-quantum computing cryptography. UAs and Broadcast Remote ID communications are so constrained that current post-quantum computing cryptography is not applicable. In addition, because a UA may use a unique DET for each operation, the attack window could be limited to the duration of the operation.
[DRIP-ARCH]のセクション8.1で述べたように、Quantum後のコンピューティング暗号化に対処する努力はありませんでした。UASと放送リモートID通信は非常に制約があるため、現在の質量コンピューティング暗号化は適用されません。さらに、UAは各操作に一意のDETを使用する可能性があるため、攻撃ウィンドウは操作の期間に制限される可能性があります。
HHITs contain the ID for the cryptographic suite used in its creation, a future algorithm that is safe for post-quantum computing that fits the Remote ID constraints may readily be added.
HHITSには、その作成で使用される暗号化スイートのIDが含まれています。これは、リモートIDの制約に適合するポストカンタムコンピューティングに安全な将来のアルゴリズムを容易に追加できます。
The DET in the ASTM Basic ID Message (Msg Type 0x0, the actual Remote ID message) does not provide any assertion of trust. Truncating 4 bytes from a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 16) within this Basic ID Message is the best that can be done. This is not trustable, as it is too open to a hash attack. Minimally, it takes 88 bytes (Section 4.6) to prove ownership of a DET with a full EdDSA signature. Thus, no attempt has been made to add DET trust directly within the very small Basic ID Message.
ASTM Basic IDメッセージ（MSGタイプ0x0、実際のリモートIDメッセージ）のDetは、信頼の主張を提供しません。この基本的なIDメッセージ内で、HHITのHI署名（UA IDフィールドは20バイト、HHITは16）から4バイトを切り捨てます。これは、ハッシュ攻撃に対して開かれすぎているため、信頼できません。最終的には、完全なEDDSA署名でDETの所有権を証明するには、88バイト（セクション4.6）が必要です。したがって、非常に小さな基本的なIDメッセージ内にDet Trustを直接追加する試みは行われていません。
The ASTM Authentication Message (Msg Type 0x2) as shown in Section 4.6 can provide actual ownership proofs in a practical manner. The endorsements and evidence include timestamps to defend against replay attacks, but they do not prove which UA sent the message. The messages could have been sent by a dog running down the street with a Broadcast Remote ID module strapped to its back.
セクション4.6に示すASTM認証メッセージ（MSGタイプ0x2）は、実際の所有権の証明を実用的に提供できます。承認と証拠には、リプレイ攻撃から守るためのタイムスタンプが含まれていますが、どのUAがメッセージを送信したかを証明していません。メッセージは、ブロードキャストのリモートIDモジュールが背中に縛り付けられた状態で、通りを駆け抜ける犬によって送信された可能性があります。
Proof of UA transmission comes, for example, when the Authentication Message includes proof of the ASTM Location/Vector Message (Msg Type 0x1) and a) the observer can see the UA or b) the location information is validated by ground multilateration. Only then does an observer gain full trust in the DET of the UA.
UA送信の証明は、たとえば、認証メッセージにASTMの位置/ベクトルメッセージ（MSGタイプ0x1）の証明とa）の証明が含まれている場合、オブザーバーはUAまたはbを見ることができます）場所情報は地上の多面化によって検証されます。その場合にのみ、オブザーバーはUAのDETに完全な信頼を獲得します。
DETs obtained via the Network RID path provide a different approach to trust. Here the UAS SHOULD be securely communicating to the USS, thus asserting DET trust.
ネットワークRIDパスを介して取得されたDETは、信頼に対する異なるアプローチを提供します。ここで、UASはUSSと安全に通信し、Det Trustを主張する必要があります。
The DNS entry for the DET can also provide a revocation service. For example, instead of returning the HI RR, it may return some record showing that the HI (and thus DET) has been revoked. Guidance on revocation service will be provided in [DRIP-REG].
DETのDNSエントリは、取り消しサービスを提供することもできます。たとえば、HI RRを返す代わりに、HI（およびDET）が取り消されたことを示す記録を返す可能性があります。取り消しサービスに関するガイダンスは、[Drip-Reg]で提供されます。
There is no expectation of privacy for DETs; it is not part of the normative privacy requirements listed in Section 4.3.1 of [RFC9153]. DETs are broadcast in the clear over the open air via Bluetooth and Wi-Fi. They will be collected and collated with other public information about the UAS. This will include DET registration information and location and times of operations for a DET. A DET can be for the life of a UA if there is no concern about DET/UA activity harvesting.
Detsのプライバシーの期待はありません。[RFC9153]のセクション4.3.1にリストされている規範的なプライバシー要件の一部ではありません。Detsは、BluetoothとWi-Fiを介して屋外でクリアで放送されます。それらは収集され、UASに関する他の公開情報と照合されます。これには、登録登録情報と、detの操作の場所と時間が含まれます。DET/UAの活動の収穫に懸念がない場合、DETはUAの存続に至る可能性があります。
Further, the Media Access Control (MAC) address of the wireless interface used for Remote ID broadcasts are a target for UA operation aggregation that may not be mitigated through MAC address randomization. For Bluetooth 4 Remote ID messaging, the MAC address is used by observers to link the Basic ID Message that contains the RID with other Remote ID messages, thus it must be constant for a UA operation. This use of MAC addresses to link messages may not be needed with the Bluetooth 5 or Wi-Fi PHYs. These PHYs provide for a larger message payload and can use the Message Pack (Msg Type 0xF) and the Authentication Message to transmit the RID with other Remote ID messages. However, sending the RID in a Message Pack or Authentication Message is not mandatory, so using the MAC address for UA message linking must be allowed. That is, the MAC address should be stable for at least a UA operation.
さらに、リモートIDブロードキャストに使用されるワイヤレスインターフェイスのメディアアクセス制御（MAC）アドレスは、MACアドレスのランダム化を介して軽減されないUA操作集約のターゲットです。Bluetooth 4リモートIDメッセージングの場合、Macアドレスはオブザーバーによって使用され、他のリモートIDメッセージにridを含む基本的なIDメッセージをリンクするため、UA操作には一定でなければなりません。メッセージをリンクするためにMACアドレスを使用するこの使用は、Bluetooth 5またはWi-Fi Physでは必要ない場合があります。これらのPhysは、より大きなメッセージペイロードを提供し、メッセージパック（MSGタイプ0xF）と認証メッセージを使用して、RIDを他のリモートIDメッセージで送信できます。ただし、メッセージパックまたは認証メッセージでRIDを送信することは必須ではないため、UAメッセージのリンクにMACアドレスを使用することを許可する必要があります。つまり、MACアドレスは、少なくともUA操作で安定している必要があります。
Finally, it is not adequate to simply change the DET and MAC for a UA per operation to defeat tracking the history of the UA's activity.
最後に、UAのアクティビティの歴史を追跡するために、操作ごとにUAのDETとMACを単純に変更するだけではありません。
Any changes to the UA MAC may have impacts to C2 setup and use. A constant GCS MAC may well defeat any privacy gains in UA MAC and RID changes. UA/GCS binding is complicated if the UA MAC address can change; historically, UAS design assumed these to be "forever" and made setup a one-time process. Additionally, if IP is used for C2, a changing MAC may mean a changing IP address to further impact the UAS bindings. Finally, an encryption wrapper's identifier (such as ESP [RFC4303] SPI) would need to change per operation to ensure operation tracking separation.
UA Macの変更は、C2セットアップと使用に影響を与える可能性があります。一定のGCS MACは、UA Macのプライバシー利益を打ち負かし、RIDの変更を行う可能性があります。UA MACアドレスが変更できる場合、UA/GCSバインディングは複雑です。歴史的に、UASデザインはこれらを「永遠に」と想定し、セットアップを1回限りのプロセスにしました。さらに、IPがC2に使用される場合、MACを変更すると、UASバインディングにさらに影響を与えるためにIPアドレスが変化することを意味する場合があります。最後に、暗号化ラッパーの識別子（ESP [RFC4303] SPIなど）は、操作追跡の分離を確保するために、操作ごとに変更する必要があります。
Creating and maintaining UAS operational privacy is a multifaceted problem. Many communication pieces need to be considered to truly create a separation between UA operations. Changing the DET is only the start of the changes that need to be implemented.
UAS運用プライバシーを作成および維持することは、多面的な問題です。UA操作間の分離を真に作成するには、多くの通信作品を考慮する必要があります。Detを変更することは、実装する必要がある変更の開始にすぎません。
These privacy realities may present challenges for the European Union (EU) U-space (Appendix A) program.
これらのプライバシーの現実は、欧州連合（EU）Uスペース（付録A）プログラムの課題を提示する可能性があります。
The 64-bit hash size here for DETs does have an increased risk of collisions over the 96-bit hash size used for the ORCHID [RFC7343] construct. There is a 0.01% probability of a collision in a population of 66 million. The probability goes up to 1% for a population of 663 million. See Appendix D for the collision probability formula.
ここでの64ビットハッシュサイズは、蘭[RFC7343]コンストラクトに使用される96ビットハッシュサイズにわたって衝突のリスクが高くなります。6600万人の人口で衝突の確率は0.01％です。人口6億6,300万人の確率は1％になります。衝突確率式については、付録Dを参照してください。
However, this risk of collision is within a single "Additional Information" value, i.e., an RAA/HDA domain. The UAS/USS registration process should include registering the DET and MUST reject a collision, forcing the UAS to generate a new HI and thus HHIT and reapplying to the DET registration process (Section 6 of [DRIP-REG]).
ただし、この衝突のリスクは、単一の「追加情報」値、つまりRAA/HDAドメイン内にあります。UAS/USS登録プロセスには、DETの登録を含める必要があり、衝突を拒否し、UASに新しいHIを生成するように強制し、したがって、登録プロセス（[DRIP-REG]のセクション6）にHHITと再適用する必要があります。
Thus an adversary trying to generate a collision and 'steal' the DET would run afoul of this registration process and associated validation process mentioned in Section 1.1.
したがって、衝突を生成し、Detを「盗む」ことを試みる敵は、この登録プロセスとセクション1.1で言及された関連する検証プロセスに違反します。
[NIST.FIPS.202]
Dworkin, M. J. and National Institute of Standards and
Technology, "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", DOI 10.6028/nist.fips.202,
July 2015, <http://dx.doi.org/10.6028/nist.fips.202>.
[NIST.SP.800-185]
Kelsey, J., Change, S., Perlner, R., and National
Institute of Standards and Technology, "SHA-3 derived
functions: cSHAKE, KMAC, TupleHash and ParallelHash",
DOI 10.6028/nist.sp.800-185, December 2016,
<http://dx.doi.org/10.6028/nist.sp.800-185>.
[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>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <https://www.rfc-editor.org/info/rfc7343>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[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>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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>.
[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>.
[RFC9373] Moskowitz, R., Kivinen, T., and M. Richardson, "EdDSA
Value for IPSECKEY", RFC 9373, DOI 10.17487/RFC9373, March
2023, <https://www.rfc-editor.org/info/rfc9373>.
[CFRG-COMMENT]
Gajcowski, N., "Please review draft-ietf-drip-rid",
message to the CFRG mailing list, 23 September 2021,
<https://mailarchive.ietf.org/arch/msg/cfrg/
tAJJq60W6TlUv7_pde5cw5TDTCU/>.
[CORUS] CORUS, "SESAR Concept of Operations for U-space", 9
September 2019, <https://www.sesarju.eu/node/3411>.
[CTA2063A] ANSI/CTA, "Small Unmanned Aerial Systems Serial Numbers",
September 2019, <https://shop.cta.tech/products/small-
unmanned-aerial-systems-serial-numbers>.
[DRIP-ARCH]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-31, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
arch-31>.
[DRIP-AUTH]
Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-29, 15 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-29>.
[DRIP-REG] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET)
Identity Management Architecture", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-07, 5 December
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
drip-registries-07>.
[F3411-22a]
ASTM International, "Standard Specification for Remote ID
and Tracking - F3411-22a", July 2022,
<https://www.astm.org/f3411-22a.html>.
[FAA_RID] United States Federal Aviation Administration (FAA),
"Remote Identification of Unmanned Aircraft", 15 January
2021, <https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>.
[HHSI] IANA, "Hierarchical HIT (HHIT) Suite IDs",
<https://www.iana.org/assignments/drip>.
[IANA-CGA] IANA, "Cryptographically Generated Addresses (CGA) Message
Type Name Space",
<https://www.iana.org/assignments/cga-message-types>.
[IANA-HIP] IANA, "Host Identity Protocol (HIP) Parameters",
<https://www.iana.org/assignments/hip-parameters>.
[IPv6-SPECIAL]
IANA, "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special-
registry/>.
[Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and
R. Van Keer, "Keccak Team",
<https://keccak.team/index.html>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
2005, <https://www.rfc-editor.org/info/rfc4025>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[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>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
<https://www.rfc-editor.org/info/rfc9063>.
[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>.
[RFC9224] 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>.
The EU is defining a future of airspace management known as U-space within the Single European Sky ATM Research (SESAR) undertaking. The Concept of Operation for EuRopean UTM Systems (CORUS) project proposed low-level Concept of Operations [CORUS] for UAS in the EU. It introduces strong requirements for UAS privacy based on European General Data Protection Regulation (GDPR) regulations. It suggests that UAs are identified with agnostic IDs, with no information about UA type, the operators, or flight trajectory. Only authorized persons should be able to query the details of the flight with a record of access.
EUは、単一のヨーロッパSky ATM Research（SESAR）事業内のUスペースとして知られる空域管理の将来を定義しています。欧州UTMシステム（CORUS）プロジェクトの操作の概念は、EUのUAS向けに低レベルの運用概念[Corus]を提案しました。欧州の一般データ保護規則（GDPR）規制に基づいて、UASプライバシーの強力な要件を導入しています。UAは、UAタイプ、オペレーター、または飛行軌道に関する情報がない、不可知論のIDで識別されることを示唆しています。許可された人のみが、アクセスの記録でフライトの詳細を照会できるはずです。
Due to the high privacy requirements, a casual observer can only query U-space if it is aware of a UA seen in a certain area. A general observer can use a public U-space portal to query UA details based on the UA transmitted "Remote identification" signal. Direct remote identification (DRID) is based on a signal transmitted by the UA directly. Network remote identification (NRID) is only possible for UAs being tracked by U-Space and is based on the matching the current UA position to one of the tracks.
プライバシー要件が高いため、カジュアルなオブザーバーは、特定の領域で見られるUAを認識している場合にのみUスペースを照会できます。一般的なオブザーバーは、パブリックUスペースポータルを使用して、UA送信された「リモート識別」信号に基づいてUAの詳細を照会できます。直接リモート識別（DRID）は、UAによって直接送信される信号に基づいています。ネットワークリモート識別（NRID）は、UASがUスペースで追跡されるためにのみ可能であり、現在のUA位置をトラックの1つに一致させることに基づいています。
This is potentially a contrary expectation as that presented in Section 9.4. U-space will have to deal with this reality within the GDPR regulations. Still, DETs as defined here present a large step in the right direction for agnostic IDs.
これは、セクション9.4で示されているように、潜在的に反対の期待です。Uスペースは、GDPR規制の中でこの現実に対処する必要があります。それでも、ここで定義されているようにDETは、不可知論のIDの正しい方向への大きなステップを示しています。
The project lists "E-Identification" and "E-Registrations" services as to be developed. These services can use DETs and follow the privacy considerations outlined in this document for DETs.
このプロジェクトには、開発される「電子識別」および「e-Registrations」サービスがリストされています。これらのサービスは、Detsを使用して、このドキュメントに概説されているプライバシーに関する考慮事項に従うことができます。
If an "agnostic ID" above refers to a completely random identifier, it creates a problem with identity resolution and detection of misuse. On the other hand, a classical HIT has a flat structure which makes its resolution difficult. The DET (HHIT) provides a balanced solution by associating a registry with the UA identifier. This is not likely to cause a major conflict with U-space privacy requirements, as the registries are typically few at a country level (e.g., civil personal, military, law enforcement, or commercial).
上記の「不可知論的ID」が完全にランダムな識別子を指す場合、IDはIDの解決と誤用の検出に問題を引き起こします。一方、古典的なヒットには、その解像度を困難にするフラットな構造があります。DET（HHIT）は、レジストリをUA識別子に関連付けることにより、バランスの取れたソリューションを提供します。これは、レジストリが国レベルでは通常ほとんどないため、Uスペースのプライバシー要件との大きな競合を引き起こす可能性は低いです（たとえば、市民の個人、軍事、法執行機関、または商業）。
The following explains the logic for dividing the 28 bits of the HID into two 14-bit components.
以下は、28ビットのHIDを2つの14ビットコンポーネントに分割するためのロジックを説明しています。
At this writing, the International Civil Aviation Organization (ICAO) has 193 member "States", and each may want to control RID assignment within its National Air Space (NAS). Some members may want separate RAAs to use for Civil, general Government, and Military use. They may also want allowances for competing Civil RAA operations. It is reasonable to plan for eight RAAs per ICAO member (plus regional aviation organizations like in the EU). Thus, as a start, a space of 4,096 RAAs is advised.
この執筆では、国際民間航空機関（ICAO）には193のメンバー「州」があり、それぞれが国家空間（NAS）内でRIDの割り当てを制御したい場合があります。一部のメンバーは、市民、一般政府、および軍事使用に使用するために別々のRaasを望んでいる場合があります。彼らはまた、競合する民間のRAA作戦の手当を望んでいるかもしれません。ICAOメンバーごとに8つのRAA（EUのような地域の航空組織）を計画することは合理的です。したがって、開始として、4,096のRaasのスペースが推奨されます。
There will be requests by commercial entities for their own RAA allotments. Examples could include international organizations that will be using UAS and international delivery service associations. These may be smaller than the RAA space needed by ICAO member States and could be met with a 2,048 space allotment; however, as will be seen, these might as well be 4,096 as well.
商業エンティティからのRAAの割り当ての要求があります。例には、UASおよび国際配信サービス協会を使用する国際機関が含まれます。これらは、ICAO加盟国が必要とするRAAスペースよりも小さい場合があり、2,048のスペース割り当てで満たすことができます。ただし、ご覧のように、これらも4,096である可能性があります。
This may well cover currently understood RAA entities. In the future, there will be new applications, branching off into new areas, so yet another space allocation should be set aside. If this is equal to all that has been reserved, we should allow for 16,384 (2^14) RAAs.
これは、現在理解されているRAAエンティティをカバーする可能性があります。将来的には、新しいアプリケーションが新しい領域に分岐するため、さらに別のスペースの割り当てを確保する必要があります。これが予約されているすべてのものと等しい場合、16,384（2^14）RAASを許可する必要があります。
The HDA allocation follows a different logic from that of RAAs. Per Appendix D, an HDA should be able to easily assign 63M RIDs and even manage 663M with a "first come, first assigned" registration process. For most HDAs, this is more than enough, and a single HDA assignment within their RAA will suffice. Most RAAs will only delegate to a couple of HDAs for their operational needs. But there are major exceptions that point to some RAAs needing large numbers of HDA assignments.
HDA割り当ては、RAASのロジックとは異なるロジックに従います。付録Dによると、HDAは63mのRIDを簡単に割り当て、663mを「最初に割り当てられた」登録プロセスで663mを管理できる必要があります。ほとんどのHDAでは、これで十分であり、RAA内の単一のHDA割り当てで十分です。ほとんどのRaasは、運用上のニーズのためにいくつかのHDAにのみ委任します。しかし、多数のHDA割り当てが必要ないくつかのRAAを指し示す主要な例外があります。
Delivery service operators like Amazon (est. 30K delivery vans) and UPS (est. 500K delivery vans) may choose, for anti-tracking reasons, to use unique RIDs per day or even per operation. 30K delivery UAs could need between 11M and 44M RIDs. Anti-tracking would be hard to provide if the HID were the same for a delivery service fleet, so such a company may turn to an HDA that provides this service to multiple companies so that who's UA is who's is not evident in the HID. A USS providing this service could well use multiple HDA assignments per year, depending on strategy.
Amazon（Est。30kDelivery Vans）やUPS（Est。500kDelivery Vans）などの配送サービスオペレーターは、追跡対策の理由で、1日あたりまたは操作あたりのユニークなRIDを使用することができます。30K配送UASには、11m〜44mのRIDが必要になる場合があります。HIDが配達サービス艦隊で同じである場合、アンチトラッキングを提供するのは困難です。そのため、このような会社は、このサービスを複数の企業に提供するHDAに目を向ける可能性があります。このサービスを提供するUSSは、戦略に応じて、年間複数のHDA割り当てを使用できます。
Perhaps a single RAA providing HDAs for delivery service (or a similar purpose) UAS could 'get by' with a 2048 HDA space (11 bits). So the HDA space could well be served with only 12 bits allocated out of the 28-bit HID space. However, as this is speculation and deployment experience will take years, a 14-bit HDA space has been selected.
おそらく、配達サービス（または同様の目的）のためにHDAを提供する単一のRAAが、2048 HDAスペース（11ビット）で「通り抜ける」ことができます。したがって、HDAスペースは、28ビットHIDスペースから割り当てられた12ビットのみで提供できます。ただし、これは推測であり、展開の経験が数年かかるため、14ビットHDAスペースが選択されています。
There may also be 'small' ICAO member States that opt for a single RAA and allocate their HDAs for all UAs that are permitted in their NAS. The HDA space is large enough that a portion may be used for government needs as stated above and small commercial needs. Alternatively, the State may use a separate, consecutive RAA for commercial users. Thus it would be 'easy' to recognize State-approved UA by HID high-order bits.
また、単一のRAAを選択し、NASで許可されているすべてのUAにHDAを割り当てる「小さな」ICAO加盟国があります。HDAスペースは十分に大きいため、上記の商業的ニーズと小さな商業的ニーズが述べているように、一部が政府のニーズに使用される可能性があります。あるいは、州は商業ユーザーに別の連続したRAAを使用する場合があります。したがって、高次ビットを隠すことにより、状態承認のUAを認識することは「簡単」です。
The upper 64 bits of DET appear to be oddly constructed from nibbled fields, when typically seen in 8-bit representations. The following works out the construction of the example in Section 5.
DETの上部64ビットは、8ビット表現で通常見られるとき、奇妙にかわいいフィールドから構築されているように見えます。以下は、セクション5の例の構築を説明します。
In that example, the prefix is 2001:30::/28, the RAA is decimal 10, and the HDA is decimal 20. Below is the RAA and HDA in 14-bit format:
その例では、プレフィックスは2001：30 ::/28で、RAAは10進数、HDAは10進20です。以下は14ビット形式のRAAとHDAです。
RAA 10 = 00000000001010
HDA 20 = 00000000010100
The leftmost 4 bits of the RAA, all zeros, combine with the prefix to form 2001:0030:, which leaves the remaining RAA and HDA to combine to:
すべてのゼロの左端の4ビット、すべてのゼロはプレフィックスと組み合わせて2001：0030：を形成し、残りのRAAとHDAを組み合わせて次のようにします。
0000|0010|1000|0000|0001|0100|
Which when combined with the OGA of x05 is 0280:1405, thus the whole upper 64 bits are 2001:0030:0280:1405.
X05のOGAと組み合わせると、0280：1405であるため、上部64ビット全体は2001：0030：0280：1405です。
The alphabet used in CTA 2063-A Serial Number does not map to any published Base32 encoding scheme. Therefore, the following Base32 Alphabet is used.
CTA 2063-Aシリアル番号で使用されるアルファベットは、公開されているBase32エンコードスキームにマッピングされません。したがって、次のBase32アルファベットが使用されます。
Each 5-bit group is used as an index into an array of 32 printable characters. The character referenced by the index is placed in the output string. These characters, identified below, are selected from US-ASCII digits and uppercase letters.
各5ビットグループは、32の印刷可能な文字の配列へのインデックスとして使用されます。インデックスで参照される文字は、出力文字列に配置されます。以下で特定されたこれらの文字は、US-ASCII桁と大文字から選択されています。
+=====+========+=====+==========+=====+==========+=====+==========+
|Value|Encoding|Value| Encoding |Value| Encoding |Value| Encoding |
+=====+========+=====+==========+=====+==========+=====+==========+
| 0|0 | 8| 8 | 16| G | 24| Q |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 1|1 | 9| 9 | 17| H | 25| R |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 2|2 | 10| A | 18| J | 26| T |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 3|3 | 11| B | 19| K | 27| U |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 4|4 | 12| C | 20| L | 28| V |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 5|5 | 13| D | 21| M | 29| W |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 6|6 | 14| E | 22| N | 30| X |
+-----+--------+-----+----------+-----+----------+-----+----------+
| 7|7 | 15| F | 23| P | 31| Y |
+-----+--------+-----+----------+-----+----------+-----+----------+
Table 14: The Base 32 Alphabet
表14：ベース32アルファベット
The accepted formula for calculating the probability of a collision is:
衝突の確率を計算するための受け入れられた式は次のとおりです。
p = 1 - e^({-k^2/(2n)})
p = 1 -e^（{-k^2/（2n）}）
P:
P：
Collision Probability
衝突確率
n:
N：
Total possible population
総人口の総
k:
K：
Actual population
実際の人口
The following table provides the approximate population size for a collision for a given total population.
次の表は、特定の総人口の衝突のおおよその人口サイズを示しています。
+==================+============================================+
| Total Population | Deployed Population With Collision Risk of |
| +=====================================+======+
| | .01% | 1% |
+==================+=====================================+======+
| 2^96 | 4T | 42T |
+------------------+-------------------------------------+------+
| 2^72 | 1B | 10B |
+------------------+-------------------------------------+------+
| 2^68 | 250M | 2.5B |
+------------------+-------------------------------------+------+
| 2^64 | 66M | 663M |
+------------------+-------------------------------------+------+
| 2^60 | 16M | 160M |
+------------------+-------------------------------------+------+
Table 15: Approximate Population Size With Collision Risk
表15：衝突リスクのある人口サイズの近似
Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil Aviation Administration.
ガルトフ博士は、スウェーデンの民間航空局のサイバーセキュリティに関する顧問です。
Quynh Dang of NIST gave considerable guidance on using Keccak and the supporting NIST documents. Joan Deamen of the Keccak team was especially helpful in many aspects of using Keccak. Nicholas Gajcowski [CFRG-COMMENT] provided a concise hash pre-image security assessment via the CFRG list.
Quynh Dang of Nistは、KeccakとサポートNISTドキュメントを使用することにかなりのガイダンスを与えました。KeccakチームのJoan Deamenは、Keccakの使用の多くの面で特に役立ちました。Nicholas Gajcowski [CFRG-Comment]は、CFRGリストを介して簡潔なハッシュプレイメージのセキュリティ評価を提供しました。
Many thanks to Michael Richardson and Brian Haberman for the iotdir review, Magnus Nystrom for the secdir review, Elwyn Davies for the genart review, and the DRIP co-chair and document shepherd, Mohamed Boucadair for his extensive comments and help on document clarity. And finally, many thanks to the Area Directors: Roman Danyliw, Erik Kline, Murray Kucherawy, Warren Kumari, John Scudder, Paul Wouters, and Sarker Zaheduzzaman, for the IESG review.
IoTDIRレビューのマイケルリチャードソンとブライアンハーバーマン、Secdirレビューのマグナスナイストロム、GenArtレビューのエルウィンデイビス、およびドキュメントの共同議長とドキュメントのシェパードであるMohamed Boucadairのドキュメントとドキュメントの共同議長に感謝します。そして最後に、IESGレビューのために、Roman Danyliw、Erik Kumariy、Murray Kumherawy、Warren Kumari、John Scudder、Paul Wouters、Sarker Zaheduzzamanの地域監督に感謝します。
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Stuart W. Card
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Adam Wiethuechter
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Andrei Gurtov
Linköping University
IDA
SE-58183 Linköping
Sweden
Email: gurtov@acm.org