Internet Engineering Task Force (IETF) A. Wiethuechter, Ed.
Request for Comments: 9575 S. Card
Category: Standards Track AX Enterprize, LLC
ISSN: 2070-1721 R. Moskowitz
HTT Consulting
June 2024
The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed.
ドローンリモート識別プロトコル（DRIP）に加えて、レジストリへの信頼ポリシーと定期的なアクセスは、無人の航空機システム（UAS）リモート識別（RID）を増強し、オブザーバーでさえ、受信したRIDメッセージおよび観測されたUAの信頼性のローカルリアルタイム評価を可能にしますインターネットアクセスが不足しています。このドキュメントでは、添付のRID認証メッセージに送信されるドリップメッセージの種類とフォーマットを定義して、添付および最近デタッチされたメッセージが登録されたDRIPエンティティタグ（DET）の登録所有者によって署名されたことを確認します。
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/rfc9575.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9575で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. DRIP Entity Tag (DET) Authentication Goals for Broadcast
RID
2. Terminology
2.1. Required Terminology
2.2. Definitions
3. UAS RID Authentication Background and Procedures
3.1. DRIP Authentication Protocol Description
3.1.1. Usage of DNS
3.1.2. Providing UAS RID Trust
3.2. ASTM Authentication Message Framing
3.2.1. Authentication Page
3.2.2. Authentication Payload Field
3.2.3. SAM Data Format
3.2.4. ASTM Broadcast RID Constraints
4. DRIP Authentication Formats
4.1. UA-Signed Evidence Structure
4.2. DRIP Link
4.3. DRIP Wrapper
4.3.1. Wrapped Count and Format Validation
4.3.2. Wrapper over Extended Transports
4.3.3. Wrapper Limitations
4.4. DRIP Manifest
4.4.1. Hash Count and Format Validation
4.4.2. Manifest Ledger Hashes
4.4.3. Hash Algorithms and Operation
4.5. DRIP Frame
5. Forward Error Correction
5.1. Encoding
5.2. Decoding
5.3. FEC Limitations
6. Requirements and Recommendations
6.1. Legacy Transports
6.2. Extended Transports
6.3. Authentication
6.4. Operational
6.4.1. DRIP Wrapper
6.4.2. UAS RID Trust Assessment
7. Summary of Addressed DRIP Requirements
8. IANA Considerations
8.1. IANA DRIP Registry
9. Security Considerations
9.1. Replay Attacks
9.2. Wrapper vs Manifest
9.3. VNA Timestamp Offsets for DRIP Authentication Formats
9.4. DNS Security in DRIP
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Authentication States
A.1. None: Black
A.2. Partial: Gray
A.3. Unsupported: Brown
A.4. Unverifiable: Yellow
A.5. Verified: Green
A.6. Trusted: Blue
A.7. Questionable: Orange
A.8. Unverified: Red
A.9. Conflicting: Purple
Appendix B. Operational Recommendation Analysis
B.1. Page Counts vs Frame Counts
B.1.1. Special Cases
B.2. Full Authentication Example
B.2.1. Raw Example
Acknowledgments
Authors' Addresses
The initial regulations (e.g., [FAA-14CFR]) and standards (e.g., [F3411]) for Unmanned Aircraft Systems (UAS) Remote Identification (RID) and tracking do not address trust. However, this is a requirement that needs to be addressed for various different parties that have a stake in the safe operation of National Airspace Systems (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations.
無人航空機システム（UAS）リモート識別（RID）および追跡の初期規制（[FAA-14CFR]）と標準（[F3411]など）は信頼に対応していません。ただし、これは、National Airspace Systems（NAS）の安全な運用に出資しているさまざまな関係者に対して対処する必要がある要件です。ドローンリモートIDプロトコル（DRIPの）目標は、特に緊急事態で、インターネットとローカルのみの接続されたシナリオの両方で、RIDを信頼できるようにする方法を指定することです。
UAS often operate in a volatile environment. A small Unmanned Aircraft (UA) offers little capacity for computation and communication. UAS RID must also be accessible with ubiquitous and inexpensive devices without modification. This limits options. Most current small UAS are Internet of Things (IoT) devices even if they are not typically thought of as such. Thus many IoT considerations apply here. Some DRIP work, currently strongly scoped to UAS RID, is likely to be applicable to some other IoT use cases.
UAはしばしば揮発性環境で動作します。小さな無人航空機（UA）は、計算と通信の能力をほとんど提供しません。UAS RIDは、変更せずにユビキタスで安価なデバイスでアクセスできる必要があります。これにより、オプションが制限されます。現在のほとんどの小さなUASは、通常、そのように考えられていなくても、モノのインターネット（IoT）デバイスです。したがって、多くのIoTの考慮事項はここで適用されます。現在、UAS RIDに強くスコープされているいくつかの点滴作業は、他のIoTユースケースに適用できる可能性があります。
Generally, two communication schemes for UAS RID are considered: Broadcast and Network. This document focuses on adding trust to Broadcast RID (Section 3.2 of [RFC9153] and Section 1.2.2 of [RFC9434]). As defined in [F3411] and outlined in [RFC9153] and [RFC9434], Broadcast RID is a one-way Radio Frequency (RF) transmission of Media Access Control (MAC) layer messages over Bluetooth or Wi-Fi.
一般に、UAS RIDの2つの通信スキームが考慮されます：ブロードキャストとネットワーク。このドキュメントは、ブロードキャストRID（[RFC9153]のセクション3.2および[RFC9434]のセクション1.2.2）に信頼を追加することに焦点を当てています。[F3411]で定義され、[RFC9153]および[RFC9434]で概説されているように、Broadcast RIDは、BluetoothまたはWi-Fiを介したメディアアクセス制御（MAC）レイヤーメッセージの一元配置無線周波数（RF）伝送です。
Senders can make any claims the RID message formats allow. Observers have no standardized means to assess the trustworthiness of message content, nor verify whether the messages were sent by the UA identified therein, nor confirm that the UA identified therein is the one they are visually observing. Indeed, Observers have no way to detect whether the messages were sent by a UA or spoofed by some other transmitter (e.g., a laptop or smartphone) anywhere in direct wireless broadcast range. Authentication is the primary strategy for mitigating this issue.
送信者は、RIDメッセージフォーマットが許可する請求を行うことができます。オブザーバーには、メッセージコンテンツの信頼性を評価する標準化された手段はありません。また、そこに識別されたUAによってメッセージが送信されたかどうかを確認することも、そこで特定されたUAが視覚的に観察しているものであることを確認しません。実際、オブザーバーは、メッセージがUAによって送信されたのか、他の送信機（例えば、ラップトップやスマートフォン）によって直接ワイヤレスブロードキャスト範囲のどこにもスプーフィングされているかどうかを検出する方法がありません。認証は、この問題を軽減するための主要な戦略です。
ASTM [F3411] Authentication Messages (Message Type 0x2), when used with DET-based formats [RFC9374], enable a high level of trust that the content of other ASTM Messages was generated by their claimed registered source. These messages are designed to provide the Observers with trustworthy and immediately actionable information. Appendix A provides a high-level overview of the various states of trustworthiness that may be used along with these formats.
ASTM [F3411]認証メッセージ（メッセージタイプ0x2）は、DETベースの形式[RFC9374]で使用されると、他のASTMメッセージのコンテンツが登録済みのソースによって生成されたという高レベルの信頼を可能にします。これらのメッセージは、オブザーバーに信頼できる即時実用的な情報を提供するように設計されています。付録Aでは、これらの形式とともに使用できるさまざまな信頼性状態の高レベルの概要を説明します。
This authentication approach also provides some error correction (Section 5) as mandated by the United States (US) Federal Aviation Administration (FAA) [FAA-14CFR], which is missing from [F3411] over Legacy Transports (Bluetooth 4.x).
また、この認証アプローチは、レガシー輸送（Bluetooth 4.x）を介して[F3411]から欠落している米国（米国）連邦航空局（FAA）[FAA-14CFR] [FAA-14CFR]によって義務付けられているエラー修正（セクション5）も提供します。
These DRIP enhancements to ASTM's specification for RID and tracking [F3411] further support the important use case of Observers who may be offline at the time of observation.
ASTMのRIDおよび追跡の仕様[F3411]のこれらの点滴強化は、観察時にオフラインになっている可能性のあるオブザーバーの重要なユースケースをさらにサポートしています。
Section 7 summarizes the DRIP requirements [RFC9153] addressed herein.
セクション7は、ここで扱っているDRIP要件[RFC9153]をまとめたものです。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document makes use of the terms (CAA, Observer, USS, UTM, etc.) defined in [RFC9153]. Other terms (such as DIME) are from [RFC9434], while others (HI, DET, RAA, HDA, etc.) are from [RFC9374].
このドキュメントでは、[RFC9153]で定義されている用語（CAA、オブザーバー、USS、UTMなど）を使用しています。他の用語（DIMEなど）は[RFC9434]からのものであり、他の用語（HI、DET、RAA、HDAなど）は[RFC9374]からです。
In addition, the following terms are defined for this document:
さらに、このドキュメントでは、次の用語が定義されています。
Extended Transports:
拡張輸送：
Use of extended advertisements (Bluetooth 5.x), service info (Wi-Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons with the vendor-specific information element as specified in [F3411]. Must use ASTM Message Pack (Message Type 0xF).
拡張広告（Bluetooth 5.x）、サービス情報（Wi-Fi Neighbor Awareness Networking（NAN））、または[F3411]で指定されているベンダー固有の情報要素を備えたIEEE 802.11ビーコンの使用。ASTMメッセージパック（メッセージタイプ0xf）を使用する必要があります。
Legacy Transports:
レガシートランスポート：
Use of broadcast frames (Bluetooth 4.x) as specified in [F3411].
[F3411]で指定されているブロードキャストフレーム（Bluetooth 4.x）の使用。
Manifest:
マニフェスト：
An immutable list of items being transported (in this specific case over wireless communication).
輸送されるアイテムの不変のリスト（この特定のケースでは、ワイヤレス通信に関する）。
Observation Session:
観察セッション：
The period of time during which a given Observer's receiver is processing (even if only intermittently) a series of UAS RID messages, at least some of which use DRIP extensions to [F3411], all nominally from the same UA executing a single flight operation.
特定のオブザーバーの受信機が（断続的にのみであっても）一連のUAS RIDメッセージを処理している期間（少なくとも一部は[F3411]にドリップエクステンションを使用し、すべて同じUAが単一のフライト操作を実行していることからです。
Note: For the remainder of this document, _Broadcast Endorsement: Parent, Child_ will be abbreviated as _BE: Parent, Child_. For example, _Broadcast Endorsement: RAA, HDA_ will be abbreviated as _BE: RAA, HDA_.
注：このドキュメントの残りの部分では、_BROADCASTの承認：親、child_は_be：parent、child_として略されます。たとえば、_Broadcastの承認：RAA、HDA_は_be：raa、hda_として略されます。
[F3411] defines Authentication Message framing only. It does not define authentication formats or methods. It explicitly anticipates several signature options but does not fully define those. Annex A1 of [F3411] defines a Broadcast Authentication Verifier Service, which has a heavy reliance on Observer real-time connectivity to the Internet. Fortunately, [F3411] also allows third-party standard Authentication Types using the Type 0x5 Specific Authentication Method (SAM), several of which DRIP defines herein.
[F3411]認証メッセージフレーミングのみを定義します。認証形式や方法は定義されていません。いくつかの署名オプションを明示的に予測していますが、それらを完全に定義していません。[F3411]の付録A1は、インターネットへのオブザーバーのリアルタイム接続に大きく依存しているブロードキャスト認証検証剤サービスを定義しています。幸いなことに、[F3411]は、タイプ0x5固有の認証法（SAM）を使用してサードパーティの標準認証タイプを許可します。
The standardization of specific formats to support the DRIP requirements in UAS RID for trustworthy communications over Broadcast RID is an important part of the chain of trust for a UAS ID. Per Section 5 of [RFC9434], Authentication formats are needed to relay information for Observers to determine trust. No existing formats (defined in [F3411] or other organizations leveraging this feature) provide functionality to satisfy this goal, resulting in the work reflected in this document.
ブロードキャストRIDを介した信頼できるコミュニケーションのためにUAS RIDのDRIP要件をサポートする特定の形式の標準化は、UAS IDの信頼チェーンの重要な部分です。[RFC9434]のセクション5ごとに、観察者が信頼を決定するための情報を中継するには、認証形式が必要です。既存の形式（[F3411]やこの機能を活用している他の組織で定義されている）は、この目標を満たす機能を提供しないため、このドキュメントに反映されている作業が得られます。
Like most aviation matters, the overall objectives here are security and ultimately safety oriented. Since DRIP depends on DNS for some of its functions, DRIP usage of DNS needs to be protected per best security practices. Many participating nodes will have limited local processing power and/or poor, low-bandwidth QoS paths. Appropriate and feasible security techniques will be highly dependent on the UAS and Observer situation. Therefore, specification of particular DNS security options, transports, etc. is outside the scope of this document (see also Section 9.4).
ほとんどの航空問題と同様に、ここでの全体的な目的はセキュリティであり、最終的には安全志向です。DRIPはいくつかの機能のDNSに依存するため、DNSのDRIP使用は、最良のセキュリティ慣行に従って保護する必要があります。多くの参加ノードには、ローカル処理能力および/または低帯域幅QoSパスが限られています。適切で実行可能なセキュリティ手法は、UASおよびオブザーバーの状況に大きく依存します。したがって、特定のDNSセキュリティオプション、トランスポートなどの仕様は、このドキュメントの範囲外です（セクション9.4も参照）。
In DRIP, Observers MUST validate all signatures received. This requires that the Host Identity (HI) correspond to a DET [RFC9374]. HI's MAY be retrieved from a local cache, if present. The local cache is pre-configured with well-known HIs (such as those of CAA DIMEs) and is further populated by received Broadcast Endorsements (BEs) (Section 3.1.2.1) and DNS lookups (when available).
点滴では、オブザーバーは受信したすべての署名を検証する必要があります。これには、ホストID（HI）がDet [RFC9374]に対応する必要があります。こんにちは、存在する場合はローカルキャッシュから取得できます。ローカルキャッシュは、有名なHIS（CAA Dimesのような）で事前に構成されており、受信した放送承認（BES）（セクション3.1.2.1）およびDNSルックアップ（利用可能な場合）がさらに入力されます。
The Observer MUST perform a DNS query, when connectivity allows, to obtain a previously unknown HI. If a query cannot be performed, the message SHOULD be cached by the Observer to be validated once the HI is obtained.
オブザーバーは、接続性が許可されている場合、以前は未知のHIを取得するために、DNSクエリを実行する必要があります。クエリを実行できない場合、HIが取得されたら、メッセージを観察者が検証するためにメッセージをキャッシュする必要があります。
A more comprehensive specification of DRIP's use of DNS is out of scope for this document and can be found in [DRIP-REG].
DRIPのDNSの使用のより包括的な仕様は、このドキュメントの範囲外であり、[Drip-Reg]にあります。
For DRIP, two actions together provide a mechanism for an Observer to trust in UAS RID using Authentication Messages.
点滴の場合、2つのアクションが一緒になって、オブザーバーが認証メッセージを使用してUAS RIDを信頼するメカニズムを提供します。
First is the transmission of an entire trust chain via Broadcast Endorsements (Section 3.1.2.1). This provides a hierarchy of DIMEs down to and including an individual UA's registration of a claimed DET and corresponding HI (public key). This alone cannot be trusted as having any relevance to the observed UA because replay attacks are trivial.
1つ目は、ブロードキャストの承認を介したトラストチェーン全体の送信です（セクション3.1.2.1）。これにより、請求されたDETおよび対応するHI（公開鍵）の個々のUAの登録を含むダイムの階層を提供します。リプレイ攻撃は些細なことであるため、これだけで観測されたUAに関連するものとして信頼することはできません。
After an Observer has gathered such a complete key trust chain (from pre-configured cache entries, Broadcast Endorsements received over the air and/or DNS lookups) and verified all of its links, that device can trust that the claimed DET and corresponding public key are properly registered, but the UA has not yet been proven to possess the corresponding private key.
オブザーバーがこのような完全なキートラストチェーンを収集した後（事前に構成されたキャッシュエントリ、空中および/またはDNS検索を受けた放送の支持から）、そのリンクをすべて確認した後、そのデバイスは主張されたDetと対応する公開鍵を信頼できると信頼できます適切に登録されていますが、UAはまだ対応する秘密鍵を所有していることがまだ証明されていません。
Second is for the UA to prove possession by dynamically signing data that is unique and unpredictable but easily verified by the Observer (Section 3.1.2.2). Verification of this signed data MUST be performed by the Observer as part of the received UAS RID information trust assessment (Section 6.4.2).
2番目は、UAがユニークで予測不可能なデータに動的に署名することにより、所有権を証明することですが、オブザーバーによって簡単に検証されます（セクション3.1.2.2）。この署名されたデータの検証は、受信したUAS RID Information Trust Assessment（セクション6.4.2）の一部としてオブザーバーが実行する必要があります。
Observers receive DRIP Link Authentication Messages (Section 4.2) containing Broadcast Endorsements by DIMEs of child DET registrations. A series of these Endorsements confirms a path through the hierarchy, defined in [DRIP-REG], from the DET Prefix Owner all the way to an individual UA DET registration.
オブザーバーは、Dime of Child Det登録による放送承認を含むDRIPリンク認証メッセージ（セクション4.2）を受け取ります。これらの承認のシリーズは、[Drip-Reg]で定義された階層を通るパスを確認し、Detプレフィックスの所有者から個々のUA DET登録までです。
To prove possession of the private key associated with the DET, the UA MUST sign and send data that is unique and unpredictable but easily validated by the Observer. The data can be an ASTM Message that fulfills the requirements to be unpredictable but easily validated. An Observer receives this UA-signed Evidence from DRIP-based Authentication Messages (Sections 4.3 or 4.4). The Observer must verify the signature (cryptographically, as specified in Section 3.1.1) and validate the signed content (via non-cryptographic means, as specified in Section 6.3).
DETに関連する秘密鍵の所有を証明するには、UAはユニークで予測不可能であるが、オブザーバーによって簡単に検証されるデータに署名して送信する必要があります。データは、予測不可能であるが簡単に検証される要件を満たすASTMメッセージにすることができます。オブザーバーは、点滴ベースの認証メッセージ（セクション4.3または4.4）からこのUAに署名した証拠を受け取ります。オブザーバーは、署名（セクション3.1.1で指定されているように暗号化的に）を検証し、署名されたコンテンツを検証する必要があります（セクション6.3で指定されているように、非暗号化手段を介して）。
Whether the content is true is a separate question that DRIP cannot address, but validation performed using observable and/or out-of-band data (Section 6) is possible and encouraged.
コンテンツが真であるかどうかは、DRIPが対処できない別の質問ですが、観察可能および/または帯域外データ（セクション6）を使用して実行される検証が可能であり、奨励されています。
The Authentication Message (Message Type 0x2) is unique in the ASTM [F3411] Broadcast standard, as it is the only message that can be larger than the Legacy Transport size. To address this limitation around transport size, it is defined as a set of "pages", each of which fits into a single Legacy Transport frame. For Extended Transports, pages are still used but they are all in a single frame.
認証メッセージ（メッセージタイプ0x2）は、レガシートランスポートサイズよりも大きい唯一のメッセージであるため、ASTM [F3411]ブロードキャスト標準で一意です。輸送サイズに関するこの制限に対処するために、それは「ページ」のセットとして定義され、それぞれが単一のレガシートランスポートフレームに収まります。拡張トランスポートの場合、ページは引き続き使用されますが、それらはすべて単一のフレームにあります。
Informational Note: Message Pack (Message Type 0xF) is also larger than the Legacy Transport size but is limited for use only on Extended Transports where it can be supported.
情報ノート：メッセージパック（メッセージタイプ0xf）もレガシートランスポートサイズよりも大きくなりますが、サポートできる拡張トランスポートでのみ使用するために制限されています。
The following subsections are a brief overview of the Authentication Message format defined in [F3411] for better context on how DRIP Authentication fills and uses various fields already defined by ASTM [F3411].
次のサブセクションは、ASTM [F3411]によって既に定義されているさまざまなフィールドをどのように埋めて使用するかについてのより良いコンテキストのために、[F3411]で定義された認証メッセージ形式の簡単な概要です。
This document leverages Authentication Type 0x5 (Specific Authentication Method (SAM)) as the principal authentication container, defining a set of SAM Types in Section 4. Authentication Type is encoded in every Authentication Page in the _Page Header_. The SAM Type is defined as a field in the _Authentication Payload_ (see Section 3.2.3).
このドキュメントは、認証タイプ0x5（特定の認証方法（SAM））を主要な認証コンテナとして活用し、セクション4のSAMタイプのセットを定義します。認証タイプは、_Page Header_のすべての認証ページでエンコードされています。SAMタイプは、_Authentication Payload_のフィールドとして定義されます（セクション3.2.3を参照）。
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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| |
| |
| Authentication Payload |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 1: Standard ASTM Authentication Message Page
図1：標準のASTM認証メッセージページ
_Page Header_:
_page header _：
(1 octet)
（1オクテット）
Authentication Type (4 bits) and Page Number (4 bits)
認証タイプ（4ビット）とページ番号（4ビット）
_Authentication Payload_:
_authentication payload _：
(23 octets per page)
（1ページあたり23オクテット）
Authentication Payload, including headers. Null padded. See Section 3.2.2.
ヘッダーを含む認証ペイロード。ヌルパッド付き。セクション3.2.2を参照してください。
The Authentication Message is structured as a set of pages per Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15) that can be sent for a single Authentication Message, with each page carrying a maximum 23-octet _Authentication Payload_. See Section 3.2.4 for more details. Over Legacy Transports, these messages are "fragmented", with each page sent in a separate Legacy Transport frame.
認証メッセージは、図1のページのセットとして構造化されています。単一の認証メッセージに送信できる技術的な最大16ページ（インデックス付き0〜15）があり、各ページは最大23-OCTET _Authentication Payload_を搭載しています。詳細については、セクション3.2.4を参照してください。レガシートランスポートの上で、これらのメッセージは「断片化」されており、各ページは別のレガシートランスポートフレームに送信されます。
Either as a single Authentication Message or a set of fragmented Authentication Message Pages, the structure is further wrapped by outer ASTM framing and the specific link framing.
単一の認証メッセージまたは断片化された認証メッセージページのセットとして、構造はさらに外側のASTMフレーミングと特定のリンクフレーミングによってラップされます。
Figure 2 is the source data view of the data fields found in the Authentication Message as defined by [F3411]. This data is placed into the _Authentication Payload_ shown in Figure 1, which spans multiple _Authentication Pages_.
図2は、[F3411]で定義されている認証メッセージにあるデータフィールドのソースデータビューです。このデータは、複数の_Authentication Pages_に及ぶ図1に示す_Authentication Payload_に配置されます。
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
+---------------+---------------+---------------+---------------+
| Authentication Headers |
| +---------------+---------------+
| | |
+---------------+---------------+ |
. .
. Authentication Data / Signature .
. .
| |
+---------------+---------------+---------------+---------------+
| ADL | |
+---------------+ |
. .
. Additional Data .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 2: ASTM Authentication Message Fields
図2：ASTM認証メッセージフィールド
_Authentication Headers_:
_authentication headers _：
(6 octets)
（6オクテット）
As defined in [F3411].
[F3411]で定義されているとおり。
_Authentication Data / Signature_:
_authentication data / signature _：
(0 to 255 octets)
（0〜255オクテット）
Opaque authentication data. The length of this payload is known through a field in the _Authentication Headers_ (defined in [F3411]).
不透明な認証データ。このペイロードの長さは、_authentication headers_のフィールド（[f3411]で定義）を通じて知られています。
_Additional Data Length (ADL)_:
_ADDITIONALデータ長（ADL）_：
(1 octet - unsigned)
（1オクテット - 署名なし）
Length in octets of _Additional Data_. The value of _ADL_ is calculated as the minimum of 361 - Authentication Data / Signature Length and 255. Only present with _Additional Data_.
_additionalデータのオクテットの長さ_。_ADL_の値は、最小361-認証データ /署名長、255として計算されます。
_Additional Data:_
_追加データ：_
(_ADL_ octets)
（_adl_オクテット）
Data that follows the _Authentication Data / Signature_ but is not considered part of the _Authentication Data_, and thus is not covered by a signature. For DRIP, this field is used to carry Forward Error Correction (FEC) generated by transmitters and parsed by receivers as defined in Section 5.
_authentication data / signature _に続くが、_authentication data _の一部とは見なされないため、署名の対象ではありません。点滴の場合、このフィールドは、送信機によって生成され、セクション5で定義されているようにレシーバーによって解析された進行エラー補正（FEC）に使用されます。
Figure 3 is the general format to hold authentication data when using SAM and is placed inside the _Authentication Data / Signature_ field in Figure 2.
図3は、SAMを使用するときに認証データを保持する一般的な形式であり、図2の_Authenticationデータ / Signature_フィールド内に配置されます。
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
+---------------+---------------+---------------+---------------+
| SAM Type | |
+---------------+ |
. .
. SAM Authentication Data .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 3: SAM Data Format
図3：SAMデータ形式
_SAM Type_:
_SAMタイプ_：
(1 octet)
（1オクテット）
The following SAM Types are allocated to DRIP:
次のSAMタイプは、滴下に割り当てられます。
+==========+=============================+
| SAM Type | Description |
+==========+=============================+
| 0x01 | DRIP Link (Section 4.2) |
+----------+-----------------------------+
| 0x02 | DRIP Wrapper (Section 4.3) |
+----------+-----------------------------+
| 0x03 | DRIP Manifest (Section 4.4) |
+----------+-----------------------------+
| 0x04 | DRIP Frame (Section 4.5) |
+----------+-----------------------------+
Table 1: DRIP SAM Types
表1：ドリップSAMタイプ
Note: ASTM International is the owner of these code points as they are defined in [F3411]. In accordance with Annex 5 of [F3411], the International Civil Aviation Organization (ICAO) has been selected by ASTM as the registrar to manage allocations of these code points. The list is available at [ASTM-Remote-ID].
注：ASTM Internationalは、[F3411]で定義されているため、これらのコードポイントの所有者です。[F3411]のAnnex 5に従って、国際民間航空機関（ICAO）がASTMによってレジストラとして選択され、これらのコードポイントの割り当てを管理しています。リストは[ASTM-Remote-ID]で利用できます。
_SAM Authentication Data_:
_SAM認証データ_：
(0 to 200 octets)
（0〜200オクテット）
Contains opaque authentication data formatted as defined by the preceding SAM Type.
前のSAMタイプで定義されているようにフォーマットされた不透明な認証データが含まれています。
A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and other Civil Aviation Authorities (CAA) mandate transmitting simultaneously over both 4.x and 5.x. The same application-layer information defined in [F3411] MUST be transmitted over all the physical-layer interfaces performing RID, because Observer transports may be limited. If an Observer can support multiple transports, it should use (display, report, etc.) the latest data regardless of the transport over which that data was received.
UAには、Bluetooth（4.xおよび5.x）、Wi-Fi Nan、またはIEEE 802.11ビーコンを使用してブロードキャストするオプションがあります。セクション6を参照してください。Bluetooth、FAA、およびその他の民間航空当局（CAA）が4.xと5.xの両方で同時に送信します。[F3411]で定義されているのと同じアプリケーション層情報は、オブザーバーの輸送が制限される可能性があるため、RIDを実行するすべての物理層インターフェイスに送信する必要があります。オブザーバーが複数のトランスポートをサポートできる場合、そのデータが受信された輸送に関係なく、最新のデータを使用（表示、レポートなど）を使用する必要があります。
Bluetooth 4.x presents a payload-size challenge in that it can only transmit 25 octets of payload per frame, while other transports can support larger payloads per frame. As [F3411] message formats are the same for all media, and their framing was designed to fit within these legacy constraints, Extended Transports cannot send larger messages; instead, the Message Pack format encapsulates multiple messages (each of which fits within these legacy constraints).
Bluetooth 4.xは、フレームごとに25オクテットのペイロードしか送信できないという点でペイロードサイズの課題を提示しますが、他のトランスポートはフレームごとの大きなペイロードをサポートできます。[F3411]メッセージ形式はすべてのメディアで同じであり、それらのフレーミングはこれらのレガシーの制約に収まるように設計されているため、拡張トランスポートはより大きなメッセージを送信できません。代わりに、メッセージパック形式は複数のメッセージをカプセル化します（それぞれがこれらのレガシーの制約に適合します）。
By definition Extended Transports provide FEC, but Legacy Transports lack FEC. Thus over Legacy Transports, paged Authentication Messages may suffer the loss of one or more pages. This would result in delivery to the Observer application of incomplete (typically unusable) messages, so DRIP FEC (Section 5) is specified to enable recovery of a single lost page and thereby reduce the likelihood of receiving incompletely reconstructable Authentication Messages. Authentication Messages sent using Extended Transports do not suffer this issue, as the full message (all pages) is sent using a single Message Pack. Furthermore, the use of one-way RF broadcasts prohibits the use of any congestion-control or loss-recovery schemes that require ACKs or NACKs.
定義により、拡張トランスポートはFECを提供しますが、レガシートランスポートにはFECがありません。したがって、レガシートランスポートを介して、ページング認証メッセージは1つ以上のページの損失に苦しむ可能性があります。これにより、不完全な（通常は使用できない）メッセージのオブザーバーアプリケーションへの配信が行われるため、DRIP FEC（セクション5）が指定され、単一の失われたページの回復が可能になり、不完全に再構築可能な認証メッセージを受信する可能性が減ります。拡張トランスポートを使用して送信された認証メッセージは、この問題に苦しむことはありません。完全なメッセージ（すべてのページ）は単一のメッセージパックを使用して送信されます。さらに、一元配置RF放送の使用は、ACKまたはNACKを必要とする渋滞制御または損失回復スキームの使用を禁止しています。
To keep consistent formatting across the different transports (Legacy and Extended) and their independent restrictions, the authentication data being sent is REQUIRED to fit within the page limit that the most constrained existing transport can support. Under Broadcast RID, the Extended Transport that can hold the least amount of authentication data is Bluetooth 5.x at 9 pages.
さまざまなトランスポート（レガシーと拡張）と独立した制限全体にわたって一貫したフォーマットを維持するには、最も制約されている既存の輸送がサポートできるページ制限内に送信される認証データが必要です。放送RIDでは、認証データの最小量を保持できる拡張トランスポートは、9ページでBluetooth 5.xです。
As such, DRIP transmitters are REQUIRED to adhere to the following when using the Authentication Message:
そのため、認証メッセージを使用する場合は、次のようなものを順守するには、点滴送信機が必要です。
1. _Authentication Data / Signature_ data MUST fit in the first 9 pages (Page Numbers 0 through 8).
1. _Authentication Data / Signature_データは、最初の9ページ（ページ番号0〜8）に適合する必要があります。
2. The _Length_ field in the _Authentication Headers_ (which encodes the length in octets of _Authentication Data / Signature_ only) MUST NOT exceed the value of 201. This includes the SAM Type but excludes _Additional Data_.
2. _authentication headers_の_length_フィールド（_authentication data / signature_のみのオクテットの長さをエンコードする）は、201の値を超えてはなりません。
In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for Authentication to keep a common time format in Broadcast payloads.
ASTM [F3411]では、タイムスタンプは、2019-01-01 00:00:00:00の時代を備えたUNIXスタイルのタイムスタンプです。DRIPの場合、この形式は認証に採用され、ブロードキャストペイロードの一般的な時間形式を維持します。
Under DRIP, there are two timestamps defined: Valid Not Before (VNB) and Valid Not After (VNA).
DRIPの下には、2つのタイムスタンプが定義されています。
Valid Not Before (VNB) Timestamp:
以前（VNB）タイムスタンプの有効：
(4 octets)
（4オクテット）
Timestamp denoting the recommended time at which to start trusting data. MUST follow the format defined in [F3411] as described above. MUST be set no earlier than the time the signature (across a given structure) is generated.
データの信頼を開始するための推奨時間を示すタイムスタンプ。上記のように[F3411]で定義されている形式に従う必要があります。（特定の構造全体で）署名が生成される時間よりも早く設定する必要があります。
Valid Not After (VNA) Timestamp:
有効ではない（VNA）タイムスタンプ：
(4 octets)
（4オクテット）
Timestamp denoting the recommended time at which to stop trusting data. MUST follow the format defined in [F3411] as described above. Has an offset (relative to VNB) to avoid replay attacks. The exact offset is not defined in this document. Best practice for identifying an acceptable offset should be used and should take into consideration the UA environment, propagation characteristics of the messages being sent, and clock differences between the UA and Observers. For UA signatures in scenarios typical as of 2024, a reasonable offset would be to set VNA approximately 2 minutes after VNB; see Appendix B for examples that may aid in tuning this value.
データの信頼を停止する推奨時間を示すタイムスタンプ。上記のように[F3411]で定義されている形式に従う必要があります。リプレイ攻撃を避けるためのオフセット（VNBと比較して）があります。正確なオフセットは、このドキュメントでは定義されていません。許容可能なオフセットを特定するためのベストプラクティスを使用する必要があり、UA環境、送信されるメッセージの伝播特性、およびUAとオブザーバーのクロックの違いを考慮する必要があります。2024年の時点で典型的なシナリオのUA署名の場合、合理的なオフセットは、VNBの約2分後にVNAを設定することです。この値の調整に役立つ可能性のある例については、付録Bを参照してください。
All formats defined in this section are contained in the _Authentication Data / Signature_ field in Figure 2 and use the Specific Authentication Method (SAM, Authentication Type 0x5). The first octet of the _Authentication Data / Signature_ of Figure 2 is used to multiplex among these various formats.
このセクションで定義されているすべての形式は、図2の_Authenticationデータ / Signature_フィールドに含まれており、特定の認証方法（SAM、認証タイプ0x5）を使用します。図2の_authenticationデータ /署名_の最初のオクテットは、これらのさまざまな形式の中で多重化するために使用されます。
When sending data over a medium that does not have underlying FEC, for example Legacy Transports, then FEC (per Section 5) MUST be used.
基礎となるFEC、たとえばレガシートランスポートを持たない媒体を介してデータを送信する場合、FEC（セクション5ごと）を使用する必要があります。
Examples of Link, Wrapper, and Manifest are shown as part of an operational schedule in Appendix B.2.1.
リンク、ラッパー、マニフェストの例は、付録B.2.1の運用スケジュールの一部として示されています。
The _UA-Signed Evidence Structure_ (Figure 4) is used by the UA during flight to sign over information elements using the private key associated with the current UA DET. It is encapsulated by the _SAM Authentication Data_ field of Figure 3.
_UAに署名した証拠構造_（図4）は、飛行中にUAによって使用され、現在のUA DETに関連付けられた秘密鍵を使用して情報要素を介して署名します。図3の_SAM認証データ_フィールドによってカプセル化されています。
This structure is used by the DRIP Wrapper (Section 4.3), Manifest (Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST NOT use it, as it will not fit in the ASTM Authentication Message with its intended content (i.e., a Broadcast Endorsement).
この構造は、点滴ラッパー（セクション4.3）、マニフェスト（セクション4.4）、およびフレーム（セクション4.5）によって使用されます。DRIPリンク（セクション4.2）は、意図したコンテンツ（つまり、ブロードキャストの承認）を使用してASTM認証メッセージに収まらないため、使用してはなりません。
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by UA |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by UA |
+---------------+---------------+---------------+---------------+
| |
. .
. Evidence .
. .
| |
+---------------+---------------+---------------+---------------+
| |
| UA |
| DRIP Entity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| UA Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 4: Endorsement Structure for UA-Signed Evidence
図4：UAに署名した証拠の承認構造
_Valid Not Before (VNB) Timestamp by UA_:
_valid not fore（vnb）タイムスタンプby UA_：
(4 octets)
（4オクテット）
See Section 3.2.4.3. Set by the UA.
セクション3.2.4.3を参照してください。UAによって設定されています。
_Valid Not After (VNA) Timestamp by UA_:
_valid not not after（vna）タイムスタンプby ua_：
(4 octets)
（4オクテット）
See Section 3.2.4.3. Set by the UA.
セクション3.2.4.3を参照してください。UAによって設定されています。
_Evidence_:
_証拠_：
(0 to 112 octets)
（0〜112オクテット）
The _Evidence_ field MUST be filled in with data in the form of an opaque object specified in the DRIP Wrapper (Section 4.3), Manifest (Section 4.4), or Frame (Section 4.5).
_evidence_フィールドは、点滴ラッパー（セクション4.3）、マニフェスト（セクション4.4）、またはフレーム（セクション4.5）で指定された不透明なオブジェクトの形式のデータで記入する必要があります。
_UA DRIP Entity Tag_:
_UA DRIP ENTITY TAG_：
(16 octets)
（16オクテット）
This is a DET [RFC9374] currently being used by the UA for authentication; it is assumed to be a Specific Session ID (a type of UAS ID typically also used by the UA in the Basic ID Message).
これは、認証のために現在UAによって使用されているDet [RFC9374]です。これは、特定のセッションID（基本IDメッセージでUAでも使用されるUAS IDのタイプ）であると想定されています。
_UA Signature_:
_ua signature _：
(64 octets)
（64オクテット）
Signature over the concatenation of preceding fields (_VNB_, _VNA_, _Evidence_, and _UA DET_) using the keypair of the UA DET. The signature algorithm is specified by the Hierarchical Host Identity Tags (HHIT) Suite ID of the DET.
UA DETのキーペイアを使用して、前のフィールド（_VNB_、_VNA_、_EVIDENCE_、_UA DET_）の連結に関する署名。署名アルゴリズムは、DETの階層ホストIDタグ（HHIT）スイートIDによって指定されています。
When using this structure, the UA is minimally self-endorsing its DET. The HI of the UA DET can be looked up by mechanisms described in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see Sections 4.2 and 6.3).
この構造を使用する場合、UAは最小限の自己監視をしています。UA DetのHIは、[Drip-Reg]で説明されているメカニズムまたはブロードキャストの承認から抽出することで調べることができます（セクション4.2および6.3を参照）。
This SAM Type (Figure 5) is used to transmit Broadcast Endorsements. For example, the _BE: HDA, UA_ is sent (see Section 6.3) as a DRIP Link message.
このSAMタイプ（図5）は、ブロードキャストの承認を送信するために使用されます。たとえば、_BE：HDA、UA_は、点滴リンクメッセージとして送信されます（セクション6.3を参照）。
DRIP Link is important as its contents are used to provide trust in the DET/HI pair that the UA is currently broadcasting. This message does not require Internet connectivity to perform signature verification of the contents when the DIME DET/HI is in the Observer's cache. It also provides the UA HI, when it is filled with a BE: HDA, UA, so that connectivity is not required when performing signature verification of other DRIP Authentication Messages.
ドリップリンクは、UAが現在放送しているDet/Hiペアに信頼を提供するためにその内容を使用するため、重要です。このメッセージでは、DIME DET/HIがオブザーバーのキャッシュに含まれている場合、コンテンツの署名検証を実行するためにインターネット接続を必要としません。また、be：hda、uaで満たされている場合、ua hiを提供するため、他の点滴認証メッセージの署名検証を実行するときに接続性は必要ありません。
Various Broadcast Endorsements are sent during each UAS flight operation to ensure that the full Broadcast Endorsement chain is available offline. See Section 6.3 for further details.
すべてのUASフライトオペレーション中にさまざまな放送の承認が送信され、完全な放送承認チェーンがオフラインで利用できるようにします。詳細については、セクション6.3を参照してください。
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by Parent |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by Parent |
+---------------+---------------+---------------+---------------+
| |
| DET |
| of Child |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| HI of Child |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
| |
| DET |
| of Parent |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| Signature by Parent |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 5: Broadcast Endorsement / DRIP Link
図5：ブロードキャストの承認 /ドリップリンク
_VNB Timestamp by Parent_:
_VNB Parent by by Parent _：
(4 octets)
（4オクテット）
See Section 3.2.4.3. Set by Parent Entity.
セクション3.2.4.3を参照してください。親エンティティによって設定されています。
_VNA Timestamp by Parent_:
_VNA Timestamp by Parent _：
(4 octets)
（4オクテット）
See Section 3.2.4.3. Set by Parent Entity.
セクション3.2.4.3を参照してください。親エンティティによって設定されています。
_DET of Child_:
_Det of Child _：
(16 octets)
（16オクテット）
DRIP Entity Tag of Child Entity.
児童エンティティのドリップエンティティタグ。
_HI of Child_:
_hi of Child _：
(32 octets)
（32オクテット）
Host Identity of Child Entity.
子エンティティのホストアイデンティティ。
_DET of Parent_:
_det of parent _：
(16 octets)
（16オクテット）
DRIP Entity Tag of Parent Entity in DIME Hierarchy.
DIME階層における親エンティティのドリップエンティティタグ。
_Signature by Parent_:
_signature by parent _：
(64 octets)
（64オクテット）
Signature over concatenation of preceding fields (_VNB_, _VNA_, _DET of Child_, _HI of Child_, and _DET of Parent_) using the keypair of the Parent DET.
Parent Det。
This DRIP Authentication Message is used in conjunction with other DRIP SAM Types (such as the Manifest or the Wrapper) that contain data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that is guaranteed to be unique, unpredictable, and easily cross-checked by the receiving device.
このDRIP認証メッセージは、一意で予測不可能で、簡単であることが保証されているデータ（例：ASTMロケーションメッセージ/ベクトルメッセージ、メッセージタイプ0x2など）を含む他のDRIP SAMタイプ（マニフェストやラッパーなど）と組み合わせて使用されます。受信デバイスによってクロスチェックされています。
A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement chain MUST be included in each DRIP Manifest (Section 4.4).
ブロードキャスト承認チェーンの最終リンク（be：hda on ua）のハッシュは、各ドリップマニフェスト（セクション4.4）に含める必要があります。
Note: The Endorsement that proves a DET is registered MUST come from its immediate parent in the registration hierarchy, e.g., a DRIP Identity Management Entity (DIME) [DRIP-REG]. In the definitive hierarchy, the parent of the UA is its HHIT Domain Authority (HDA), the parent of an HDA is its Registered Assigning Authority (RAA), etc. It is also assumed that all DRIP-aware entities use a DET as their identifier during interactions with other DRIP-aware entities.
注：DETが登録されていることを証明する承認は、登録階層の直接の親から来なければなりません。決定的な階層では、UAの親はそのHHITドメイン局（HDA）であり、HDAの親はその登録機関（RAA）などです。他のドリップアウェアエンティティとの相互作用中の識別子。
This SAM Type is used to wrap and sign over a list of other [F3411] Broadcast RID messages.
このSAMタイプは、他の[F3411]ブロードキャストRIDメッセージのリストをラップおよびサインするために使用されます。
The _Evidence_ field of the _UA-Signed Evidence Structure_ (Section 4.1) is populated with up to four ASTM Messages [F3411] in a contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 are allowed and must be in Message Type order as defined by [F3411]. These messages MUST include the Message Type and Protocol Version octet and MUST NOT include the Message Counter octet (thus are fixed at 25 octets in length).
_UAに署名した証拠構造_（セクション4.1）の_evidence_フィールドには、隣接するオクテットシーケンスに最大4つのASTMメッセージ[F3411]が入力されています。ASTMメッセージタイプ0x0、0x1、0x3、0x4、および0x5のみが許可されており、[F3411]で定義されているメッセージタイプの順序である必要があります。これらのメッセージには、メッセージタイプとプロトコルバージョンのオクテットを含める必要があり、メッセージカウンターオクテットを含めてはなりません（したがって、長さは25オクテットで固定されています）。
When decoding a DRIP Wrapper on a receiver, a calculation of the number of messages wrapped and a validation MUST be performed by using the number of octets (defined as wrapperLength) between the _VNA Timestamp by UA_ and the _UA DET_ as shown in Figure 6.
レシーバーに点滴ラッパーをデコードする場合、図6に示すように、_VNAタイムスタンプと_UA DET_の間のオクテットの数（ラッパー長として定義）を使用して、ラップされたメッセージの数の計算と検証を実行する必要があります。
<CODE BEGINS>
if (wrapperLength MOD 25) != 0 {
return DECODE_FAILURE;
}
wrappedCount = wrapperLength / 25;
if (wrappedCount == 0) {
// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport
}
else if (wrappedCount > 4) {
return DECODE_FAILURE;
} else {
// DECODE_SUCCESS; treat as standard DRIP Wrapper
}
<CODE ENDS>
Figure 6: Pseudocode for Wrapper Validation and Number of Messages Calculation
図6：ラッパーの検証とメッセージの数の計算のためのPseudocode
When using Extended Transports, an optimization to DRIP Wrapper can be made to sign over co-located data in an ASTM Message Pack (Message Type 0xF).
拡張トランスポートを使用する場合、ドリップラッパーへの最適化を作成して、ASTMメッセージパック（メッセージタイプ0xf）で共同で配置されたデータに署名できます。
To perform this optimization, the _UA-Signed Evidence Structure_ is filled with the ASTM Messages to be in the ASTM Message Pack, the signature is generated, and then the _Evidence_ field is cleared, leaving the encoded form shown in Figure 7.
この最適化を実行するために、_UAに署名したエビデンス構造_は、ASTMメッセージパックにあるASTMメッセージで満たされ、署名が生成され、_evidence_フィールドがクリアされ、エンコードされたフォームが図7に示されています。
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
+---------------+---------------+---------------+---------------+
| VNB Timestamp by UA |
+---------------+---------------+---------------+---------------+
| VNA Timestamp by UA |
+---------------+---------------+---------------+---------------+
| |
| UA |
| DRIP Entity Tag |
| |
+---------------+---------------+---------------+---------------+
| |
| |
| |
| |
| |
| |
| |
| UA Signature |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 7: DRIP Wrapper over Extended Transports
図7：拡張輸送上のドリップラッパー
To verify the signature, the receiver MUST concatenate all the messages in the Message Pack (excluding the Authentication Message found in the same Message Pack) in ASTM Message Type order and set the _Evidence_ field of the _UA-Signed Evidence Structure_ before performing signature verification.
署名を確認するには、受信者は、ASTMメッセージタイプの順序でメッセージパック内のすべてのメッセージ（同じメッセージパックで見つかった認証メッセージを除く）を連結し、署名検証を実行する前に_UAに署名したエビデンス構造_の_evidence_フィールドを設定する必要があります。
The functionality of a Wrapper in this form is equivalent to Message Set Signature (Authentication Type 0x3) when running over Extended Transports. The Wrapper provides the same format but over both Extended and Legacy Transports, which allows the transports to be similar. Message Set Signature also implies using the ASTM validator system architecture, which depends on Internet connectivity for verification that the receiver may not have at the time an Authentication Message is received. This is something the Wrapper, and all DRIP Authentication Formats, avoid when the UA key is obtained via a DRIP Link Authentication Message.
この形式のラッパーの機能は、拡張トランスポートを実行する際のメッセージセット署名（認証タイプ0x3）と同等です。ラッパーは同じ形式を提供しますが、拡張輸送とレガシートランスポートの両方で、輸送が似ています。メッセージセットの署名は、ASTM Validatorシステムアーキテクチャを使用することも意味します。これは、認証メッセージが受信された時点で受信者が持っていないことを確認するためにインターネット接続に依存します。これはラッパーであり、すべてのDRIP認証形式であり、DRIPリンク認証メッセージを介してUAキーが取得されたときの避けてください。
The primary limitation of the Wrapper is the bounding of up to four ASTM Messages that can be sent within it. Another limitation is that the format cannot be used as a surrogate for messages it is wrapping due to the potential that an Observer on the ground does not support DRIP. Thus, when a Wrapper is being used, the wrapped data must effectively be sent twice, once as a single-framed message (as specified in [F3411]) and again within the Wrapper.
ラッパーの主な制限は、その内部で送信できる最大4つのASTMメッセージの境界です。もう1つの制限は、形式を、地面の観察者が点滴をサポートしない可能性のために、メッセージの代理として使用できないことです。したがって、ラッパーが使用されている場合、ラップデータを1回（[F3411]で指定した）、ラッパー内で1回、ラッパーとして1回、ラッパー内で効果的に2回送信する必要があります。
This SAM Type is used to create message manifests that contain hashes of previously sent ASTM Messages.
このSAMタイプは、以前に送信されたASTMメッセージのハッシュを含むメッセージマニフェストを作成するために使用されます。
By hashing previously sent messages and signing them, we gain trust in a UA's previous reports without retransmitting them. This is a way to evade the limitation of a maximum of four messages in the Wrapper (Section 4.3.3) and greatly reduce overhead.
以前に送信されたメッセージをハッシュして署名することにより、それらを再送信することなくUAの以前のレポートに信頼を獲得します。これは、ラッパー内の最大4つのメッセージの制限を回避し（セクション4.3.3）、オーバーヘッドを大幅に削減する方法です。
Observers MUST hash all received ASTM Messages and cross-check them against hashes in received Manifests.
オブザーバーは、すべてASTMメッセージを受け取り、受信したマニフェストのハッシュに対してクロスチェックする必要があります。
Judicious use of a Manifest enables an entire Broadcast RID message stream to be strongly authenticated with less than 100% overhead relative to a completely unauthenticated message stream (see Section 6.3 and Appendix B).
マニフェストの賢明な使用により、放送のRIDメッセージストリーム全体が、完全に認知されていないメッセージストリームと比較して、100％未満のオーバーヘッドで強く認証されます（セクション6.3および付録Bを参照）。
The _Evidence_ field of the _UA-Signed Evidence Structure_ (Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast RID messages (up to 11) and three special hashes (Section 4.4.2). All of these hashes MUST be concatenated to form a contiguous octet sequence in the _Evidence_ field. It is RECOMMENDED that the maximum number of ASTM Message Hashes used be 10 (see Appendix B.1.1.2).
_UAに署名した証拠構造_（セクション4.1）の_evidence_フィールドには、[F3411]放送RIDメッセージ（最大11）と3つの特別なハッシュ（セクション4.4.2）の8オクテットハッシュが入力されています。これらのハッシュはすべて連結して、_evidence_フィールドに連続的なオクテットシーケンスを形成する必要があります。使用されるASTMメッセージハッシュの最大数は10にすることをお勧めします（付録B.1.1.2を参照）。
The _Previous Manifest Hash_, _Current Manifest Hash_, and _DRIP Link (BE: HDA, UA) Hash_ MUST always come before the _ASTM Message Hashes_ as seen in Figure 8.
_ previous manifest hash_、_ current manifest hash_、および_drip link（be：hda、ua）hash_は、図8に示すように_ astmメッセージhashes_の前に常に来なければなりません。
An Observer MUST use the Manifest to verify each ASTM Message hashed therein that it has previously received. It can do this without having received them all. A Manifest SHOULD typically encompass a single transmission cycle of messages being sent; see Section 6.4 and Appendix B.
オブザーバーは、マニフェストを使用して、以前に受け取った各ASTMメッセージがハッシュしたことを確認する必要があります。それらをすべて受け取ってもこれを行うことができます。マニフェストは、通常、送信されるメッセージの単一の伝送サイクルを含む必要があります。セクション6.4と付録Bを参照してください。
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
+---------------+---------------+---------------+---------------+
| Previous Manifest |
| Hash |
+---------------+---------------+---------------+---------------+
| Current Manifest |
| Hash |
+---------------+---------------+---------------+---------------+
| DRIP Link (BE: HDA, UA) |
| Hash |
+---------------+---------------+---------------+---------------+
| |
. .
. ASTM Message Hashes .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 8: DRIP Manifest Evidence Structure
図8：点滴マニフェストエビデンス構造
_Previous Manifest Hash_:
_previousマニフェストhash_：
(8 octets)
（8オクテット）
Hash of the previously sent Manifest Message.
以前に送信されたマニフェストメッセージのハッシュ。
_Current Manifest Hash_:
_currentマニフェストhash_：
(8 octets)
（8オクテット）
Hash of the current Manifest Message.
現在のマニフェストメッセージのハッシュ。
_DRIP Link (BE: HDA, UA)_:
_DRIPリンク（BE：HDA、UA）_：
(8 octets)
（8オクテット）
Hash of the DRIP Link Authentication Message carrying BE: HDA, UA (see Section 4.2).
DRIPリンク認証メッセージのハッシュBE：HDA、UA（セクション4.2を参照）。
_ASTM Message Hash_:
_astmメッセージhash_：
(8 octets)
（8オクテット）
Hash of a single full ASTM Message using hash operations described in Section 4.4.3.
セクション4.4.3で説明したハッシュ操作を使用した単一の完全なASTMメッセージのハッシュ。
When decoding a DRIP Manifest on a receiver, a calculation of the number of hashes and a validation can be performed by using the number of octets between the _UA DET_ and the _VNB Timestamp by UA_ (defined as manifestLength) such as shown in Figure 9.
レシーバーに点滴マニフェストをデコードする場合、_UA DET_と_VNBタイムスタンプの間のオクテットの数を使用して、図9に示すような_VNBタイムスタンプ（マニフェストレングスとして定義）を使用して、ハッシュ数と検証を実行できます。
<CODE BEGINS>
if (manifestLength MOD 8) != 0 {
return DECODE_FAILURE
}
hashCount = (manifestLength / 8) - 3;
<CODE ENDS>
Figure 9: Pseudocode for Manifest Sanity Check and Number of Hashes Calculation
図9：マニフェストの正気チェックとハッシュの数の計算のための擬似コード
The following three special hashes are included in all Manifests:
次の3つの特別なハッシュは、すべてのマニフェストに含まれています。
* the _Previous Manifest Hash_ links to the previous Manifest.
* _ previous manifest hash_は、以前のマニフェストにリンクします。
* the _Current Manifest Hash_ is of the Manifest in which it appears.
* _currentマニフェストhash_は、表示されるマニフェストのものです。
* the _DRIP Link (BE: HDA, UA) Hash_ ties the endorsed UA key to the Manifest chain.
* _Dripリンク（BE：HDA、UA）Hash_は、マニフェストチェーンに承認されたUAキーを結びます。
The Previous and Current hashes act as a ledger of provenance for the Manifest chain, which should be traced back if the Observer and UA were within Broadcast RID wireless range of each other for an extended period of time.
前および現在のハッシュは、マニフェストチェーンの出所台帳として機能します。これは、オブザーバーとUAが長期間にわたって放送されたワイヤレス範囲内にある場合に追跡する必要があります。
The _DRIP Link (BE: HDA, UA)_ is included so there is a direct signature by the UA over the Broadcast Endorsement (see Section 4.2). Typical operation would expect that the list of _ASTM Message Hashes_ contain nonce-like data. To enforce a binding between the BE: HDA, UA and avoid trivial replay attack vectors (see Section 9.1), at least one _ASTM Message Hash_ MUST be from an [F3411] message that satisfies the fourth requirement in Section 6.3. At least once per Observation Session, the Observer must process that message as specified in Section 6.3.
_Dripリンク（BE：HDA、UA）_が含まれているため、ブロードキャストの承認に関するUAによる直接的な署名があります（セクション4.2を参照）。典型的な操作では、_ASTMメッセージHashes_のリストには非CEのようなデータが含まれていることが予想されます。be：hda、uaの間に結合を実施し、些細なリプレイ攻撃ベクトルを避けるために（セクション9.1を参照）、少なくとも1つの_astmメッセージhash_は、セクション6.3の4番目の要件を満たす[F3411]メッセージからのものでなければなりません。観察セッションごとに少なくとも一度、オブザーバーはセクション6.3で指定されているようにそのメッセージを処理する必要があります。
The hash algorithm used for the Manifest is the same hash algorithm used in creation of the DET [RFC9374] that is signing the Manifest. This is encoded as part of the DET using the HHIT Suite ID.
マニフェストに使用されるハッシュアルゴリズムは、マニフェストに署名しているDET [RFC9374]の作成に使用されるハッシュアルゴリズムと同じです。これは、HHITスイートIDを使用してDETの一部としてエンコードされます。
DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as follows:
cshake128 [nist.sp.800-185]を使用するDetsは、次のようにハッシュを計算します。
cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")
For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/ cSHAKE128) [RFC9374], use the construct appropriate for the associated hash. For example, the hash for "2" (ECDSA/SHA-384) is computed as follows:
「5」（EDDSA/ CSHAKE128）[RFC9374]以外のオーキッド生成アルゴリズム（OGA）の場合、関連するハッシュに適したコンストラクトを使用します。たとえば、「2」のハッシュ（ECDSA/SHA-384）は次のように計算されます。
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )
When building a Manifest, this process MUST be followed:
マニフェストを構築するときは、このプロセスに従う必要があります。
1. The _Previous Manifest Hash_
1. _ previous manifest hash_
a. is filled with a random nonce if and only if this is the first manifest being generated;
a. これが生成された最初のマニフェストである場合にのみ、ランダムなノンセで満たされています。
b. otherwise, it contains the previous manifest's _Current Manifest Hash_.
b. それ以外の場合、以前のマニフェストの_current manifest hash_が含まれています。
2. The _Current Manifest Hash_ is filled with null.
2. _currentマニフェストハッシュ_はnullで満たされています。
3. _ASTM Message Hashes_ are filled per Section 4.4.3.1 or Section 4.4.3.2.
3. _ASTMメッセージHashes_は、セクション4.4.3.1またはセクション4.4.3.2に従って記入されています。
4. A hash, as defined above in this section, is calculated over the _Previous Manifest Hash_, _Current Manifest Hash_ (null filled), and _ASTM Message Hashes_.
4. このセクションで上記で定義されているように、ハッシュは、_ previous Manifest hash_、_ current manifest hash_（null fill）、および_ astmメッセージhashes_で計算されます。
5. The _Current Manifest Hash_ (null filled) is replaced with the hash generated in Step r.
5. _currentマニフェストhash_（null fill）は、ステップrで生成されたハッシュに置き換えられます。
Under this transport, DRIP hashes the full ASTM Message being sent over the Bluetooth Advertising frame. This is the 25-octet object that starts with the Message Type and Protocol Version octet along with the 24 octets of message data. The hash MUST NOT include the Message Counter octet.
このトランスポートの下で、DRIPは、Bluetooth広告フレームを介して送信される完全なASTMメッセージをハッシュします。これは、メッセージタイプとプロトコルバージョンのオクテットと24オクテットのメッセージデータから始まる25オクテットオブジェクトです。ハッシュには、メッセージカウンターオクテットを含めてはなりません。
For paged ASTM Messages (currently only Authentication Messages), all of the pages are concatenated together in Page Number order and hashed as one object.
ページングされたASTMメッセージ（現在認証メッセージのみ）の場合、すべてのページはページ番号の順序で一緒に連結され、1つのオブジェクトとしてハッシュされます。
Under this transport, DRIP hashes the full ASTM Message Pack (Message Type 0xF) regardless of its content. The hash MUST NOT include the Message Counter octet.
このトランスポートの下で、DRIPは、コンテンツに関係なく完全なASTMメッセージパック（メッセージタイプ0xf）をハッシュします。ハッシュには、メッセージカウンターオクテットを含めてはなりません。
This SAM Type is defined to enable use of the _UA-Signed Evidence Structure_ (Section 4.1) in the future beyond the previously defined formats (Wrapper and Manifest) by the inclusion of a single octet to signal the format of _Evidence_ data (up to 111 octets).
このSAMタイプは、_UAに署名した証拠構造_（セクション4.1）の使用を可能にするために定義されています。_evidence_データの形式を通知するために単一のオクテットを含めることにより、以前に定義された形式（ラッパーとマニフェスト）を超えて将来的に使用できるようになります（最大111オクテット）。
The content format of _Frame Evidence Data_ is not defined in this document. Other specifications MUST define the contents and register for a _Frame Type_. At the time of publication (2024), there are no defined Frame Types; only an Experimental range has been defined.
_Frame Evidence Data_のコンテンツ形式は、このドキュメントでは定義されていません。その他の仕様は、内容を定義し、_frame Type_に登録する必要があります。出版時（2024年）には、定義されたフレームタイプはありません。実験範囲のみが定義されています。
Observers MUST check the signature of the structure (Section 4.1) per Section 3.1.2.2 and MAY, if the specification of _Frame Type_ is known, parse the content in _Frame Evidence Data_.
オブザーバーは、セクション3.1.2.2ごとに構造の署名（セクション4.1）をチェックする必要があり、_Frame Type_の仕様が既知の場合は、_Frame Evidence Data _でコンテンツを解析することができます。
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
+---------------+---------------+---------------+---------------+
| Frame Type | |
+---------------+ .
. Frame Evidence Data .
. .
| |
+---------------+---------------+---------------+---------------+
Figure 10: DRIP Frame
図10：ドリップフレーム
_Frame Type_:
_Frame Type_：
(1 octet)
（1オクテット）
As shown in Figure 10, the _Frame Type_ takes the first octet, which leaves 111 octets available for _Frame Evidence Data_. See Section 8.1 for Frame Type allocations.
図10に示すように、_Frame Type_は最初のオクテットを取ります。これにより、_Frame Evidence Data _が利用可能な111個のオクテットが残ります。フレームタイプの割り当てについては、セクション8.1を参照してください。
For Broadcast RID, FEC is provided by the lower layers in Extended Transports. The Bluetooth 4.x Legacy Transport does not support FEC, so the following application-level scheme is used with DRIP Authentication to add some FEC. When sending data over a medium that does not have underlying FEC, for example Bluetooth 4.x, this section MUST be used.
ブロードキャストRIDの場合、FECは拡張輸送の下層層によって提供されます。Bluetooth 4.xレガシートランスポートはFECをサポートしていないため、次のアプリケーションレベルスキームをDRIP認証で使用してFECを追加します。基礎となるFEC（Bluetooth 4.xなど）がない媒体を介してデータを送信する場合、このセクションを使用する必要があります。
The Bluetooth 4.x lower layers have error detection but not correction. Any frame in which Bluetooth detects an error is dropped and not delivered to higher layers (in our case, DRIP). Thus it can be treated as an erasure.
Bluetooth 4.x下層にはエラー検出がありますが、修正はありません。Bluetoothがエラーを検出するフレームは削除され、より高い層に配信されません（この場合、ドリップ）。したがって、それは消去として扱うことができます。
DRIP standardizes a single page FEC scheme using XOR parity across all page data of an Authentication Message. This allows the correction of a single erased page in an Authentication Message. If more than a single page is missing, then handling of an incomplete Authentication Message is determined by higher layers.
DRIPは、認証メッセージのすべてのページデータにわたってXORパリティを使用して、単一のページFECスキームを標準化します。これにより、認証メッセージ内の単一の消去ページを修正できます。単一のページ以上が欠落している場合、不完全な認証メッセージの処理は、より高いレイヤーによって決定されます。
Other FEC schemes, to protect more than a single page of an Authentication Message or multiple [F3411] Messages, are left for future standardization if operational experience proves it necessary and/or practical.
認証メッセージまたは複数の[F3411]メッセージの単一ページ以上を保護する他のFECスキームは、運用体験が必要および/または実用的であることが証明されている場合、将来の標準化のために残されます。
The data added during FEC is not included in the _Authentication Data / Signature_, but instead in the _Additional Data_ field of Figure 2. This may cause the Authentication Message to exceed 9 pages, up to a maximum of 16 pages.
FEC中に追加されたデータは、_Authentication Data / Signature _に含まれていませんが、代わりに図2の_Additional Data_フィールドに含まれています。これにより、認証メッセージが最大16ページまで9ページを超える可能性があります。
When encoding, two things are REQUIRED:
エンコードするとき、2つのことが必要です。
1. The FEC data MUST start on a new Authentication Page. To do this, the results of parity encoding MUST be placed in the _Additional Data_ field of Figure 2 with null padding before it to line up with the next page. The _Additional Data Length_ field MUST be set to number of padding octets + number of parity octets.
1. FECデータは、新しい認証ページで開始する必要があります。これを行うには、パリティエンコードの結果を、次のページに並ぶために、ヌルパディングの前に図2の_additional data_フィールドに配置する必要があります。_ADDITIONALデータの長さ_フィールドは、オクテットのパディング数 +パリティオクテットの数に設定する必要があります。
2. The _Last Page Index_ field (in Page 0) MUST be incremented from what it would have been without FEC by the number of pages required for the _Additional Data Length_ field, null padding, and FEC.
2. _LastページIndex_フィールド（ページ0）は、_ Addditional Data Length_フィールド、Null Padding、およびFECに必要なページ数によってFECなしであったものから増加する必要があります。
To generate the parity, a simple XOR operation using the previous parity page and current page is used. Only the 23-octet _Authentication Payload_ field of Figure 1 is used in the XOR operations. For Page 0, a 23-octet null pad is used for the previous parity page.
パリティを生成するには、前のパリティページと現在のページを使用した単純なXOR操作を使用します。図1の23-OCTET _Authentication Payload_フィールドのみがXOR操作で使用されます。ページ0の場合、前のパリティページには23オクテットのヌルパッドが使用されます。
Figure 11 shows an example of the last two pages (out of N) of an Authentication Message using DRIP Single Page FEC. The _Additional Data Length_ is set to 33, as there are always 23 octets of FEC data and there are 10 octets of padding in this example to line it up into Page N.
図11は、DRIPシングルページFECを使用した認証メッセージの最後の2ページ（n）の例を示しています。_ ADDITIONALデータの長さ_は33に設定されています。FECデータのオクテットが常に23オクターで、この例には10オクテットのパディングがあり、ページNに並んでいます。
Page N-1:
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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| Authentication Data / Signature |
| |
| +---------------+---------------+---------------+
| | ADL=33 | |
+---------------+---------------+ |
| Null Padding |
| |
+---------------+---------------+---------------+---------------+
Page N:
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
+---------------+---------------+---------------+---------------+
| Page Header | |
+---------------+ |
| |
| Forward Error Correction |
| |
| |
| |
+---------------+---------------+---------------+---------------+
Figure 11: Example Single Page FEC Encoding
図11：シングルページFECエンコーディングの例
Frame decoding is independent of the transmit media. However, the decoding process can determine from the first Authentication Page that there may be a Bluetooth 4.x FEC page at the end. The decoding process MUST test for the presence of FEC and apply it as follows.
フレームデコードは、送信メディアとは無関係です。ただし、デコードプロセスは、最初の認証ページから、最後にBluetooth 4.x FECページがある可能性があることを決定できます。デコードプロセスは、FECの存在をテストし、次のように適用する必要があります。
To determine if FEC has been used, a check of the _Last Page Index_ is performed. In general, if the _Last Page Index_ field is one greater than that necessary to hold _Length_ octets of Authentication Data, then FEC has been used. Note that if _Length_ octets are exhausted exactly at the end of an Authentication Page, the _Additional Data Length_ field will occupy the first octet of the following page. The remainder of this page will be null padded under DRIP to align the FEC to its own page. In this case, the _Last Page Index_ will have been incremented once for initializing the _Additional Data Length_ field and once for the FEC page, for a total of two additional pages, as in the last row of Table 5.
FECが使用されているかどうかを判断するために、_Lastページインデックス_のチェックが実行されます。一般に、_LastページIndex_フィールドが、認証データの_Length_オクテットを保持するために必要なものよりも大きい場合、FECが使用されています。_Length_オクテットが認証ページの最後に正確に使い果たされている場合、_ ADDITIONAL DATA LENGTH_フィールドは次のページの最初のオクテットを占めることに注意してください。このページの残りの部分は、FECを独自のページに揃えるために、DRIPの下でヌルパッドにされます。この場合、_ LASTページインデックス_は、_ ADDITIONAL DATA LENGTH_フィールドを初期化するために1回、FECページの1回、表5の最後の行のように合計2ページの追加ページを1回増やします。
To decode FEC in DRIP, a rolling XOR is used on each _Authentication Page_ received in the current Authentication Message. A Message Counter, outside of the ASTM Message but specified in [F3411], is used to signal a different Authentication Message and to correlate pages to messages. This Message Counter is only a single octet in length, so it will roll over (to 0x00) after reaching its maximum value (0xFF). If only a single page is missing in the Authentication Message the resulting parity octets should be the data of the erased page.
DRIPでFECをデコードするには、現在の認証メッセージで受信した各_Authentication Page_でローリングXORが使用されます。[F3411]で指定されているASTMメッセージの外側にあるメッセージカウンターは、異なる認証メッセージを信号にし、ページをメッセージと相関させるために使用されます。このメッセージカウンターは長さが単一のオクテットのみであるため、最大値（0xff）に達した後（0x00まで）ロールオーバー（0x00まで）になります。認証メッセージに1ページのみが欠落している場合、結果のパリティオクテットは消去ページのデータである必要があります。
Authentication Page 0 contains various important fields, only located on that page, that help decode the full ASTM Authentication Message. If Page 0 has been reconstructed, the _Last Page Index_ and _Length_ fields MUST be validated by DRIP. The pseudocode in Figure 12 can be used for both checks.
認証ページ0には、そのページにのみあるさまざまな重要なフィールドが含まれており、完全なASTM認証メッセージをデコードするのに役立ちます。Page 0が再構築されている場合、_Last Page Index_および_Length_フィールドは、DRIPによって検証する必要があります。図12の擬似コードは、両方のチェックに使用できます。
<CODE BEGINS>
function decode_check(auth_pages[], decoded_lpi, decoded_length) {
// check decoded_lpi does not exceed maximum value
if (decoded_lpi >= 16) {
return DECODE_FAILURE
}
// check that decoded length does not exceed DRIP maximum value
if (decoded_length > 201) {
return DECODE_FAILURE
}
// grab the page at index where length ends and extract its data
auth_data = auth_pages[(decoded_length - 17) / 23].data
// find the index of last auth byte
last_auth_byte = (17 + (23 * last_auth_page)) - decoded_length
// look for non-nulls after the last auth byte
if (auth_data[(last_auth_byte + 2):] has non-nulls) {
return DECODE_FAILURE
}
// check that byte directly after last auth byte is null
if (auth_data[last_auth_byte + 1] equals null) {
return DECODE_FAILURE
}
// we set our presumed Additional Data Length (ADL)
presumed_adl = auth_data[last_auth_byte + 1]
// use the presumed ADL to calculate a presumed
//Last Page Index (LPI, a field defined in [F3411])
presumed_lpi = (presumed_adl + decoded_length - 17) / 23
// check that presumed LPI and decoded LPI match
if (presumed_lpi not equal decoded_lpi) {
return DECODE_FAILURE
}
return DECODE_SUCCESS
}
<CODE ENDS>
Figure 12: Pseudocode for Decode Checks
図12：デコードチェック用の擬似コード
The worst-case scenario is when the _Authentication Data / Signature_ ends perfectly on a page boundary (Page N-1). This means the _Additional Data Length_ would start the next page (Page N) and have 22 octets worth of null padding to align the FEC to begin at the start of the next page (Page N+1). In this scenario, an entire page (Page N) is being wasted just to carry the _Additional Data Length_.
最悪のシナリオは、_authentication data / signature_がページ境界（ページn-1）で完全に終了する場合です。これは、_ADDITIONALデータの長さ_が次のページ（ページN）を開始し、22オクテット相当のNULLパディングを持ち、FECを整列させて次のページの開始時に開始することを意味します（ページN+1）。このシナリオでは、ページ全体（ページN）が_ADDITIONALデータの長さを運ぶためだけに無駄になっています。
Under DRIP, the goal is to bring reliable receipt of the paged Authentication Message using Legacy Transports. FEC (Section 5) MUST be used, per mandated RID rules (for example, the US FAA RID Rules [FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x).
DRIPの下で、目標は、レガシートランスポートを使用して、ページ化された認証メッセージを信頼できる受信をもたらすことです。FEC（セクション5）は、義務付けられたRIDルール（たとえば、米国FAA RIDルール[FAA-14CFR]）に従って、レガシートランスポート（Bluetooth 4.xなど）を使用する場合に使用する必要があります。
Under [F3411], Authentication Messages are transmitted at the static rate (at least every 3 seconds). Any DRIP Authentication Messages containing dynamic data (such as the DRIP Wrapper) MAY be sent at the dynamic rate (at least every 1 second).
[F3411]では、認証メッセージは静的レートで（少なくとも3秒ごとに）送信されます。動的データ（ドリップラッパーなど）を含むドリップ認証メッセージは、動的速度（少なくとも1秒ごと）で送信できます。
Under the ASTM specification, Extended Transports of RID must use the Message Pack (Message Type 0xF) format for all transmissions. Under Message Pack, ASTM Messages are sent together (in Message Type order) in a single frame (up to 9 single-frame equivalent messages under Legacy Transports). Message Packs are required by [F3411] to be sent at a rate of 1 per second (like dynamic messages).
ASTM仕様では、RIDの拡張トランスポートは、すべての送信にメッセージパック（メッセージタイプ0xf）形式を使用する必要があります。メッセージパックの下で、ASTMメッセージは単一のフレーム（レガシートランスポートの下で最大9つの単一フレーム等価メッセージ）で（メッセージタイプの順序で）一緒に送信されます。[F3411]は、[F3411]が1秒あたり1倍のレートで送信する必要があります（動的メッセージなど）。
Message Packs are sent only over Extended Transports that provide FEC. Thus, the DRIP decoders will never be presented with a Message Pack from which a constituent Authentication Page has been dropped; DRIP FEC could never provide benefit to a Message Pack, only consume its precious payload space. Therefore, DRIP FEC (Section 5) MUST NOT be used in Message Packs.
メッセージパックは、FECを提供する拡張トランスポートにのみ送信されます。したがって、DRIPデコーダーには、構成要素認証ページがドロップされたメッセージパックが表示されません。ドリップFECはメッセージパックに利益をもたらすことはできず、貴重なペイロードスペースのみを消費します。したがって、DRIP FEC（セクション5）はメッセージパックで使用してはなりません。
To fulfill the requirements in [RFC9153], a UA MUST:
[RFC9153]の要件を満たすには、UAが必要です。
1. send DRIP Link (Section 4.2) using the _BE: Apex, RAA_ (partially satisfying GEN-3); at least once per 5 minutes. Apex in this context is the DET prefix owner.
1. _be：apex、raa_（部分的に満足のいくgen-3）を使用して、ドリップリンク（セクション4.2）を送信します。少なくとも5分に1回。このコンテキストの頂点は、DETプレフィックスの所有者です。
2. send DRIP Link (Section 4.2) using the BE: RAA, HDA (partially satisfying GEN-3); at least once per 5 minutes.
2. be：raa、hda（部分的に満足のいくGen-3）を使用して、ドリップリンク（セクション4.2）を送信します。少なくとも5分に1回。
3. send DRIP Link (Section 4.2) using the BE: HDA, UA (satisfying ID-5, GEN-1 and partially satisfying GEN-3); at least once per minute.
3. BE：HDA、UA（満足のあるID-5、GEN-1、および部分的に満足のいくGEN-3）を使用して、ドリップリンク（セクション4.2）を送信します。少なくとも1分に1回。
4. send any other DRIP Authentication Format (non-DRIP Link) where the UA is dynamically signing data that is guaranteed to be unique, unpredictable, and easily cross checked by the receiving device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5 seconds.
4. UAがユニークで予測不可能であり、受信デバイスによって簡単にチェックされることが保証されているデータ（ID-5、Gen-1、Gen-2を満たす）を動的に署名している他のDRIP認証形式（非DRIPリンク）を送信します。;少なくとも5秒に1回。
An Observer's receiver must verify the signature (cryptographically, as specified in Section 3.1.1) on each of the 4 messages sent in the operations specified immediately above and the Observer MUST validate the signed content (via non-cryptographic means) of the 4th message sent in the last operation immediately above (the non-DRIP Link message).
オブザーバーのレシーバーは、上の指定された操作で送信された4つのメッセージのそれぞれについて、セクション3.1.1で指定されているように、暗号化されているように、暗号化されている）を検証する必要があり、オブザーバーは4番目のメッセージの署名コンテンツ（非暗号化手段を介して）を検証する必要があります。上の最後の操作で送信されました（非DRIPリンクメッセージ）。
These transmission, receiver verification, and Observer validation requirements collectively satisfy GEN-3.
これらの送信、受信機の検証、およびオブザーバーの検証要件は、Gen-3を集合的に満たします。
UAS operation may impact the frequency of sending DRIP Authentication Messages. When a UA dwells at an approximate location, and the channel is heavily used by other devices, less frequent message authentication may be effective (to minimize RF packet collisions) for an Observer. Contrast this with a UA transiting an area, where authenticated messages SHOULD be sufficiently frequent for an Observer to have a high probability of receiving an adequate number for validation during the transit.
UAS操作は、DRIP認証メッセージの送信頻度に影響を与える可能性があります。UAがおおよその場所に住んでいて、チャネルが他のデバイスで非常に使用される場合、観察者にとってメッセージ認証が効果的でない場合（RFパケット衝突を最小限に抑えるため）。これをUAと対照的に、領域を通過する領域と対照的に、オブザーバーがトランジット中に検証のために適切な数を受信する可能性が高いため、認証されたメッセージが十分に頻繁に行われるはずです。
A RECOMMENDED operational configuration (in alignment with Section 6.3) with rationale can be found in Appendix B. It recommends the following once per second:
根拠を持つ推奨される運用構成（セクション6.3との整合）は、付録Bにあります。次の1秒を推奨します。
* Under Legacy Transport:
* レガシー輸送の下：
- Two sets of those ASTM Messages required by a CAA in its jurisdiction (example: Basic ID, Location/Vector, and System) and one set of other ASTM Messages (example: Self ID, Operator ID)
- CAAがその管轄区域（例：基本ID、位置/ベクトル、およびシステム）と他のASTMメッセージの1つ（例：self id、operator id）で必要とするASTMメッセージの2つのセット
- An FEC-protected DRIP Manifest enabling authentication of those ASTM Messages sent
- 送信されたASTMメッセージの認証を可能にするFEC保護されたドリップマニフェスト
- A single page of an FEC-protected DRIP Link
- FEC保護されたドリップリンクの単一ページ
* Under Extended Transport:
* 延長輸送の下：
- A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper (per Section 4.3.2)
- ASTMメッセージのメッセージパック（最大4）と点滴ラッパー（セクション4.3.2ごと）
- A Message Pack of a DRIP Link
- 点滴リンクのメッセージパック
If DRIP Wrappers are sent, they MUST be sent in addition to any required ASTM Messages in a given jurisdiction. An implementation MUST NOT send DRIP Wrappers in place of any required ASTM Messages it may encapsulate. Thus, messages within a Wrapper are sent twice: once in the clear and once authenticated within the Wrapper.
点滴ラッパーが送信される場合、特定の管轄区域で必要なASTMメッセージに加えて送信する必要があります。実装は、カプセル化する可能性のある必要なASTMメッセージの代わりにドリップラッパーを送信してはなりません。したがって、ラッパー内のメッセージは2回送信されます。1回はクリアで、ラッパー内で認証された1回。
The DRIP Wrapper has a specific use case for DRIP-aware Observers. For an Observer plotting Location/Vector Messages (Message Type 0x2) on a map, display of an embedded Location/Vector Message in a DRIP Wrapper can be marked differently (e.g., via color) to signify trust in the Location/Vector data.
ドリップラッパーには、点滴を受けたオブザーバーに特定のユースケースがあります。地図上の場所/ベクトルメッセージ（メッセージタイプ0x2）をプロットするオブザーバーの場合、ドリップラッパーに埋め込まれた位置/ベクトルメッセージの表示は、位置/ベクトルデータへの信頼を示すために、異なる方法でマークを付けることができます。
As described in Section 3.1.2, the Observer MUST perform validation of the data being received in Broadcast RID. This is because trust in a key is different from trust that an observed UA possesses that key.
セクション3.1.2で説明されているように、オブザーバーはブロードキャストRIDで受信されるデータの検証を実行する必要があります。これは、キーへの信頼が、観察されたUAがそのキーを持っている信頼とは異なるためです。
A chain of DRIP Links provides trust in a key. A message, signed by that key, containing data that changes rapidly and is not predictable far in advance (relative to typical operational flight times) but that can be validated by Observers, provides trust that some agent with access to that data also possesses that key. If the validation involves correlating physical world observations of the UA with claims in that data, then the probability is high that the observed UA is (or is collaborating with or observed in real time by) the agent with the key.
ドリップリンクのチェーンは、キーに信頼を提供します。そのキーによって署名されたメッセージは、迅速に変化し、事前に（典型的な運用飛行時間と比較して）予測可能ではないが、オブザーバーが検証できるデータを含むメッセージは、そのデータにもアクセスできるエージェントがそのキーを持っているという信頼を提供します。検証がUAの物理的世界観察をそのデータのクレームと相関させる場合、観測されたUAがキーを持つエージェントをエージェントにしている（またはリアルタイムで協力している、または観察されている）という確率が高い。
At least once per Observation session, after signature verification of any DRIP Authentication Message containing UAS RID information elements (e.g., DRIP Wrapper, Section 4.3), the Observer must use other sources of information to correlate against and perform validation (as specified in Section 6.3). An example of another source of information is a visual confirmation of the UA position.
観測セッションごとに少なくとも1回、UAS RID情報要素（ドリップラッパー、セクション4.3など）を含む滴下認証メッセージの署名検証の後、オブザーバーは他の情報源を使用して検証と相関および実行する必要があります（セクション6.3で指定されています。）。別の情報源の例は、UA位置の視覚的確認です。
When correlation of these different data streams does not match in acceptable thresholds, the data MUST be rejected as if the signature failed to validate. Acceptable threshold limits and what happens after such a rejection are out of scope for this document.
これらの異なるデータストリームの相関が許容可能なしきい値で一致しない場合、署名が検証できなかったかのようにデータを拒否する必要があります。許容可能なしきい値制限と、このような拒絶後に起こることは、このドキュメントの範囲外です。
The following requirements as defined in [RFC9153] are addressed in this document:
[RFC9153]で定義されている以下の要件は、このドキュメントで説明されています。
ID-5:
ID-5：
Non-spoofability
不適切な可能性
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), or DRIP Frame (Section 4.5).
ドリップラッパー（セクション4.3）、ドリップマニフェスト（セクション4.4）、またはドリップフレーム（セクション4.5）を使用してアドレス指定されます。
GEN-1:
Gen-1：
Provable Ownership
証明可能な所有権
Addressed using the DRIP Link (Section 4.2) and DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), or DRIP Frame (Section 4.5).
ドリップリンク（セクション4.2）とドリップラッパー（セクション4.3）、ドリップマニフェスト（セクション4.4）、またはドリップフレーム（セクション4.5）を使用してアドレス指定されます。
GEN-2:
Gen-2：
Provable Binding
証明可能な結合
Addressed using the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4) or DRIP Frame (Section 4.5).
ドリップラッパー（セクション4.3）、ドリップマニフェスト（セクション4.4）またはドリップフレーム（セクション4.5）を使用してアドレス指定されます。
GEN-3:
Gen-3：
Provable Registration
証明可能な登録
Addressed using the DRIP Link (Section 4.2).
ドリップリンクを使用してアドレス指定されます（セクション4.2）。
IANA has created the "DRIP SAM Types" and "DRIP Frame Types" registries within the "Drone Remote ID Protocol" registry group (https://www.iana.org/assignments/drip).
IANAは、「ドローンリモートIDプロトコル」レジストリグループ（https://www.iana.org/assignments/drip）内に「DRIP SAMタイプ」および「ドリップフレームタイプ」レジストリを作成しました。
DRIP SAM Types:
ドリップサムタイプ：
This registry is a mirror for SAM Types containing the subset of allocations used by DRIP Authentication Messages. Future additions MUST be done through ASTM's designated registrar, which is ICAO [ASTM-Remote-ID] at the time of publication of this RFC (2024). The registration procedure for DRIP (only) SAM Types is Standards Action [RFC8126]. Requests for new DRIP SAM Type registrations will be coordinated by IANA and the ASTM-designated registrar of all SAM Types before being documented in Standards Track RFCs. The following values have been allocated to the IETF:
このレジストリは、DRIP認証メッセージで使用される割り当てのサブセットを含むSAMタイプのミラーです。将来の追加は、このRFC（2024）の公開時にICAO [ASTM-Remote-ID]であるASTMの指定レジストラを介して行う必要があります。DRIP（のみ）SAMタイプの登録手順は標準アクション[RFC8126]です。新しいDRIP SAMタイプの登録のリクエストは、IANAおよびすべてのSAMタイプのASTM指定レジストラによって調整され、標準トラックRFCに文書化されます。次の値はIETFに割り当てられています。
+==========+===========+=======================================+
| SAM Type | Name | Description |
+==========+===========+=======================================+
| 0x01 | DRIP Link | Format to hold Broadcast Endorsements |
+----------+-----------+---------------------------------------+
| 0x02 | DRIP | Authenticate full ASTM Messages |
| | Wrapper | |
+----------+-----------+---------------------------------------+
| 0x03 | DRIP | Authenticate hashes of ASTM Messages |
| | Manifest | |
+----------+-----------+---------------------------------------+
| 0x04 | DRIP | Format for future DRIP authentication |
| | Frame | |
+----------+-----------+---------------------------------------+
Table 2: DRIP SAM Types
表2：ドリップSAMタイプ
DRIP Frame Types:
ドリップフレームタイプ：
This 8-bit value registry is for Frame Types in DRIP Frame Authentication Messages. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]) for values 0x01 to 0x9F and First Come First Served (Section 4.4 of [RFC8126]) for values 0xA0 to 0xEF. The following values are defined:
この8ビット値レジストリは、ドリップフレーム認証メッセージのフレームタイプ用です。このレジストリへの将来の追加は、値0x01から0x9Fの専門家レビュー（[RFC8126]のセクション4.5）を通じて行われ、値0xa0から0xefの最初に最初に提供されます（[RFC8126]のセクション4.4）。次の値が定義されています。
+=============+==============+===============================+
| Frame Type | Name | Description |
+=============+==============+===============================+
| 0x00 | Reserved | Reserved |
+-------------+--------------+-------------------------------+
| 0x01 - 0xEF | Unassigned | |
+-------------+--------------+-------------------------------+
| 0xF0-0xFF | Experimental | Reserved for Experimental Use |
+-------------+--------------+-------------------------------+
Table 3: DRIP Frame Types
表3：ドリップフレームタイプ
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 (mailto:drip-reg-review@ietf.org) and be evaluated by one or more designated experts within a three-week review period. 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 DRIP Frame Type.
登録リクエストは、drip-reg-review@ietf.org（mailto：drip-reg-review@ietf.org）に送信し、3週間のレビュー期間内に1人以上の指定された専門家によって評価される必要があります。そのレビュー期間内に、指定された専門家は登録要求を承認または拒否し、決定をレビューリストと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の注意を引くことができます。
[F3411] (regardless of transport) lacks replay protection, as it more fundamentally lacks fully specified authentication. An attacker can spoof the UA sender MAC address and UAS ID, replaying (with or without modification) previous genuine messages, and/or crafting entirely new messages. Using DRIP in [F3411] Authentication Message framing enables verification that messages were signed with registered keys, but when naively used may be vulnerable to replay attacks. Technologies such as Single Emitter Identification can detect such attacks, but they are not readily available and can be prohibitively expensive, especially for typical Observer devices such as smartphones.
[F3411]（輸送に関係なく）は、より根本的に完全に指定された認証が欠けているため、リプレイ保護がありません。攻撃者は、UA Sender MACアドレスとUAS IDをスプーフィングし、以前の本物のメッセージを再生（変更なしで）リプレイすること、および/またはまったく新しいメッセージを作成できます。[F3411]でのDRIPを使用すると、認証メッセージフレーミングにより、メッセージが登録キーで署名されたことを確認できますが、単純に使用される場合は、リプレイ攻撃に対して脆弱です。単一のエミッター識別などのテクノロジーは、このような攻撃を検出できますが、特にスマートフォンなどの典型的なオブザーバーデバイスでは、容易に利用できず、法外に高価になる可能性があります。
Replay attack detection using DRIP requires Observer devices to combine information from multiple Broadcast RID messages and from sources other than Broadcast RID. A complete chain of Link messages (Section 4.2) from an Endorsement root of trust to the claimed sender must be collected and verified by the Observer device to provide trust in a key. Successful signature verification, using that public key, of a Wrapper (Section 4.3) or Manifest (Section 4.4) message, authenticating content that is nonce-like (see below), provides trust that the sender actually possesses the corresponding private key.
DRIPを使用したリプレイ攻撃の検出には、複数のブロードキャストRIDメッセージとブロードキャストRID以外のソースからの情報を組み合わせるために、オブザーバーデバイスが必要です。信頼の承認ルートから主張された送信者へのリンクメッセージの完全なチェーン（セクション4.2）は、キーへの信頼を提供するために、オブザーバーデバイスによって収集および検証する必要があります。ラッパー（セクション4.3）またはマニフェスト（セクション4.4）メッセージ、非CEのようなコンテンツ（以下を参照）の認証コンテンツ（以下を参照）の公開キーを使用した成功した署名検証は、送信者が実際に対応する秘密鍵を持っているという信頼を提供します。
The term "nonce-like" describes data that is unique, changes frequently, is not accurately predictable long in advance, and is easily validated (i.e., can be checked quickly at low computational cost using readily available data) by the Observer. A Location/ Vector Message is an obvious choice. This is described in Section 3.1.2.2 and Section 6.3 (requirement 4). A Location/Vector Message [F3411] reporting precise UA position and velocity at a precise and very recent time can be checked by the Observer against visual observations of UA within both RF and Visual Line of Sight.
「NonCe-like」という用語は、一意であり、頻繁に変更され、長い間正確に予測可能ではないデータを記述し、オブザーバーによって簡単に検証され、簡単に検証できます（つまり、容易に利用可能なデータを使用して低い計算コストで迅速にチェックできます）。場所/ベクトルメッセージは明らかな選択です。これは、セクション3.1.2.2およびセクション6.3（要件4）で説明されています。正確なUAの位置と速度を正確に、そしてごく最近の時間に報告する位置/ベクトルメッセージ[F3411]は、RFと視覚線の両方のUAの視覚観測に対してオブザーバーがチェックできます。
For normative specification of the foregoing, see Sections 3.1.2 and 6.4.2. As non-normative clarification, the requirements are satisfied as follows:
前述の規範的仕様については、セクション3.1.2および6.4.2を参照してください。非規範的な明確化として、要件は次のように満たされます。
The public key corresponding to a given DET (i.e., the key attested in the DRIP Link (BE: HDA, UA) that is the last link in the relevant chain of DRIP Links) is used by an Observer's receiver to try to authenticate some signed message.
特定のDETに対応する公開鍵（つまり、点滴リンクの関連するチェーンの最後のリンクであるドリップリンク（be：hda、ua）で証明されているキー）は、オブザーバーのレシーバーが署名を認証するために使用していますメッセージ。
If the signature check passes,
署名チェックが合格した場合、
_and_ the message was a Wrapper or Manifest,
_and_メッセージはラッパーまたはマニフェストでした、
_and_ the wrapped or manifested message contained content that was nonce-like,
_and_ラップまたは顕在化されたメッセージには、ノンセのようなコンテンツが含まれていました、
_and_ the Observer validated that content by non-cryptographic means (e.g., if the wrapped or manifested message was a Location/ Vector Message and the UA was visually observed to be in approximately the claimed location at the reported time),
_and_オブザーバーは、非暗号化手段によるコンテンツを検証しました（例えば、ラップまたはマニフェストされたメッセージが場所/ベクトルメッセージであり、UAが報告された時点で請求された場所に視覚的に観察された場合）
_only then_ can the Observer trust that the currently observed sending UA actually possesses the corresponding private key (and thus owns the corresponding DET).
_only then_オブザーバーは、現在観察されているUAが実際に対応する秘密鍵を持っている（したがって対応するDETを所有している）と信頼できます。
Messages that pass signature verification with trusted keys could still be replays if they contain only static information (e.g., Broadcast Endorsements (Section 4.2), [F3411] Basic ID, or [F3411] Operator ID), or information that cannot be readily validated (e.g., [F3411] Self-ID). Replay of Link messages is harmless (unless sent so frequently as to cause RF data link congestion) and indeed can increase the likelihood of an Observer device collecting an entire trust chain in a short time window. Replay of other messages ([F3411] Basic ID, [F3411] Operator ID, or [F3411] Self-ID) remains a vulnerability, unless they are combined with messages containing nonce-like data ([F3411] Location/Vector or [F3411] System) in a Wrapper or Manifest. For specification of this last requirement, see Section 4.4.2.
信頼できるキーで署名検証を渡すメッセージは、静的情報のみを含む場合でもリプレイになる可能性があります（例：ブロードキャストの承認（セクション4.2）、[F3411] Basic ID、または[F3411]オペレーターID）、または容易に検証できない情報（[F3411]オペレーターID）（例：[F3411] self id）。リンクメッセージのリプレイは無害です（RFデータリンクの混雑を引き起こすほど頻繁に送信されない限り）。実際、オブザーバーデバイスが短い時間枠でトラストチェーン全体を収集する可能性を高めることができます。他のメッセージのリプレイ（[F3411] Basic ID、[F3411]オペレーターID、または[F3411] Self ID）のリプレイは、非CEのようなデータ（[F3411]の位置/ベクトルまたは[F3411を含むメッセージと組み合わされない限り、脆弱性のままです。]システム）ラッパーまたはマニフェスト。この最後の要件の仕様については、セクション4.4.2を参照してください。
Implementations have a choice of using Wrapper (Section 4.3), Manifest (Section 4.4), or a combination to satisfy the fourth requirement in Section 6.3.
実装には、セクション6.3の4番目の要件を満たすために、ラッパー（セクション4.3）、マニフェスト（セクション4.4）、または組み合わせを使用する選択肢があります。
Wrapper is an attached signature on the full content of one or more [F3411] messages, providing strong authentication. Wrapper is an attached signature of the full content of one or more [F3411] messages, providing strong authentication. However, the size limitation means it cannot support such signatures over other Authentication Messages; thus, it cannot provide a direct binding to any part of the trust chain (Sections 3.1.2 and 6.4.2).
ラッパーは、1つ以上の[F3411]メッセージの完全なコンテンツの署名添付署名であり、強力な認証を提供します。ラッパーは、1つ以上の[F3411]メッセージの完全なコンテンツの添付の署名であり、強力な認証を提供します。ただし、サイズの制限は、他の認証メッセージよりもそのような署名をサポートできないことを意味します。したがって、信頼チェーンのどの部分にも直接結合することはできません（セクション3.1.2および6.4.2）。
Manifest explicitly provides the binding of the last link in the trust chain (with the inclusion of the hash of the Link containing BE: HDA, UA). The use of hashes and their length also allows for a larger number (11 vs 4) of [F3411] messages to be authenticated, making it more efficient compared to the Wrapper. However, the detached signature requires additional Observer overhead in storing and comparing hashes of received messages (some of which may not be received) with those in a Manifest.
マニフェストは、トラストチェーンの最後のリンクの結合を明示的に提供します（be：hda、uaを含むリンクのハッシュを含めることで）。ハッシュとその長さの使用により、[F3411]メッセージの数（11対4）が認証され、ラッパーと比較してより効率的になります。ただし、分離された署名では、受信メッセージのハッシュ（その一部は受信されない可能性がある）とマニフェストのハッシュを保存および比較する際に、追加のオブザーバーオーバーヘッドが必要です。
Appendix B contains a breakdown of frame counts and an example of a schedule using both Manifest and Wrapper. Typical operation may see (as an example) 2x Basic ID, 2x Location/Vector, 2x System, 1x Operator ID and 1x Self ID broadcast per second to comply with jurisdiction mandates. Each of these messages is a single frame in size. A Link message is 8 frames long (including FEC). This is a base frame count of *16 frames*.
付録Bには、フレームカウントの内訳と、マニフェストとラッパーの両方を使用したスケジュールの例が含まれています。典型的な操作は、（例として）2倍の基本ID、2x位置/ベクトル、2xシステム、1xオペレーターID、および1倍のセルフIDブロードキャストで、管轄権の委任状を遵守する場合があります。これらの各メッセージは、サイズが単一のフレームです。リンクメッセージの長さは8フレーム（FECを含む）です。これは、 *16フレーム *のベースフレームカウントです。
When Wrapper is used, up to four of the previous messages (except the Link) can be authenticated. For this comparison, we will sign all the messages we can in two Wrappers. This results in _20 frames_ (with FEC). Due to size constraints, the Link message is left unauthenticated. The total frame count using Wrappers is *36 frames* (wrapper frame count + base frame count).
ラッパーを使用すると、以前のメッセージのうち最大4つ（リンクを除く）を認証できます。この比較のために、2つのラッパーでできるすべてのメッセージに署名します。これにより、_20フレーム_（FECを使用）になります。サイズの制約により、リンクメッセージは認識されていません。ラッパーを使用した合計フレームカウントは * 36フレーム *（ラッパーフレームカウント +ベースフレームカウント）です。
When Manifest is used, up to 10 previous messages can be authenticated. For this example, all messages (8) are hashed (including the Link) resulting in a single Manifest that is _9 frames_ (with FEC). The total frame count using Manifest is *25 frames* (manifest frame count + base frame count).
マニフェストを使用すると、最大10個の以前のメッセージを認証できます。この例では、すべてのメッセージ（8）がハッシュ（リンクを含む）であり、_9 frames_（FECを使用）である単一のマニフェストになります。マニフェストを使用した合計フレームカウントは * 25フレーム *（マニフェストフレームカウント +ベースフレームカウント）です。
Note the discussion of VNA Timestamp offsets here is in the context of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets are set by the DIME and have their own set of considerations in [DRIP-REG].
ここでのVNAタイムスタンプのオフセットの説明は、ドリップラッパー（セクション4.3）、ドリップマニフェスト（セクション4.4）、およびドリップフレーム（セクション4.5）のコンテキストにあります。ドリップリンク（セクション4.2）の場合、これらのオフセットはDIMEによって設定され、[DRIP-REG]に独自の考慮事項があります。
The offset of the _VNA Timestamp by UA_ is one that needs careful consideration for any implementation. The offset should be shorter than any given flight duration (typically less than an hour) but be long enough to be received and processed by Observers (larger than a few seconds). It is recommended that 3-5 minutes should be sufficient to serve this purpose in any scenario, but it is not limited by design.
UA_による_VNAタイムスタンプのオフセットは、実装を慎重に検討する必要があるものです。オフセットは、特定の飛行時間（通常は1時間未満）よりも短くする必要がありますが、オブザーバーが受信して処理するのに十分な長さ（数秒を超える）である必要があります。あらゆるシナリオでこの目的を果たすのに3〜5分で十分であることをお勧めしますが、設計によって制限されません。
As stated in Section 3.1 specification of particular DNS security options, transports, etc. is outside the scope of this document. The main specification for DNS operations in DRIP [DRIP-REG] will specify applicable best common security practices (e.g., from [RFC9364]).
セクション3.1で述べたように、特定のDNSセキュリティオプション、トランスポートなどの仕様は、このドキュメントの範囲外です。DRIP [DRIP-REG]のDNS操作の主な仕様では、該当する最良の一般的なセキュリティプラクティス（[RFC9364]から）を指定します。
[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>.
[NIST.SP.800-185]
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST
Special Publication 800-185, DOI 10.6028/NIST.SP.800-185,
December 2016,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-185.pdf>.
[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>.
[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>.
[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>.
[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>.
[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>.
[ASTM-Remote-ID]
International Civil Aviation Organization (ICAO), "Remote
ID Number Registration", December 2023,
<https://www.icao.int/airnavigation/IATF/Pages/ASTM-
Remote-ID.aspx>.
[DRIP-REG] Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tag (DET)
Identity Management Architecture", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-16, 31 May
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
drip-registries-16>.
[FAA-14CFR]
Federal Aviation Administration (FAA), "Remote
Identification of Unmanned Aircraft", January 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>.
[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>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
ASTM Authentication has only three states: None, Invalid, and Valid. This is because, under ASTM, the authentication is done by an external service hosted somewhere on the Internet so it is assumed an authoritative response will always be returned. This classification becomes more complex in DRIP with the support of "offline" scenarios where an Observer does not have Internet connectivity. With the use of asymmetric cryptography, this means that the public key (PK) must somehow be obtained. [DRIP-REG] provides more detail on how these keys are stored on the DNS and how DRIP Authentication Messages can be used to send PKs over Broadcast RID.
ASTM認証には3つの状態しかありません。なし、無効、有効です。これは、ASTMでは、認証がインターネット上のどこかでホストされている外部サービスによって行われるため、権威ある応答が常に返されると想定されるためです。この分類は、オブザーバーがインターネット接続を持たない「オフライン」シナリオのサポートにより、ドリップでより複雑になります。非対称暗号化の使用により、これは公開鍵（PK）を何らかの形で取得する必要があることを意味します。[Drip-Reg]は、これらのキーがDNSにどのように保存されているか、およびDRIP認証メッセージを使用してBroadcast RIDを介してPKSを送信する方法の詳細を提供します。
There are a few keys of interest: the PK of the UA and the PKs of relevant DIMEs. This document describes how to send the PK of the UA over the Broadcast RID messages. The keys of DIMEs are sent over Broadcast RID using the same mechanisms (see Sections 4.2 and 6.3) but MAY be sent at a far lower rate due to potential operational constraints (such as saturation of limited bandwidth). As such, there are scenarios where part of the key-chain may be unavailable at the moment a full Authentication Message is received and processed.
興味のある鍵はいくつかあります。UAのPKと関連するダイムのPKです。このドキュメントでは、ブロードキャストRIDメッセージを介してUAのPKを送信する方法について説明します。ダイムのキーは、同じメカニズムを使用して放送上で送信されます（セクション4.2および6.3を参照）が、潜在的な操作上の制約（限られた帯域幅の飽和など）のためにはるかに低いレートで送信される場合があります。そのため、キーチェーンの一部が完全な認証メッセージが受信され処理されている現時点で利用できない場合があるシナリオがあります。
The intent of this informative appendix is to recommend a way to classify these various states and convey it to the user through colors and state names/text. These states can apply to either a single Authentication Message, a DET (and its associated public key), and/or a sender.
この有益な付録の意図は、これらのさまざまな状態を分類し、色と状態名/テキストを介してユーザーに伝える方法を推奨することです。これらの状態は、単一の認証メッセージ、DET（および関連する公開鍵）、および/または送信者のいずれかに適用できます。
Table 4 briefly describes each state and recommends an associated color.
表4は、各状態を簡単に説明し、関連する色を推奨します。
+==============+========+===================================+
| State | Color | Details |
+==============+========+===================================+
| None | Black | No Authentication has been or is |
| | | being received (as yet) |
+--------------+--------+-----------------------------------+
| Partial | Gray | Authentication being received but |
| | | missing pages |
+--------------+--------+-----------------------------------+
| Unsupported | Brown | Authentication Type / SAM Type of |
| | | received message not supported |
+--------------+--------+-----------------------------------+
| Unverifiable | Yellow | Data needed for signature |
| | | verification is missing |
+--------------+--------+-----------------------------------+
| Verified | Green | Valid signature verification and |
| | | content validation |
+--------------+--------+-----------------------------------+
| Trusted | Blue | Evidence of Verified and DIME is |
| | | marked as only registering DETs |
| | | for trusted entities |
+--------------+--------+-----------------------------------+
| Unverified | Red | Invalid signature verification or |
| | | content validation |
+--------------+--------+-----------------------------------+
| Questionable | Orange | Evidence of both"Verified and |
| | | Unverified for the same claimed |
| | | sender |
+--------------+--------+-----------------------------------+
| Conflicting | Purple | Evidence of both Trusted and |
| | | Unverified for the same claimed |
| | | sender |
+--------------+--------+-----------------------------------+
Table 4: Authentication State Names, Colors, and Descriptions
表4：認証状態名、色、および説明
The default state where authentication information has not yet been received and is not currently being received.
認証情報がまだ受信されておらず、現在受信されていないデフォルトの状態。
A pending state where Authentication Pages are being received, but a full Authentication Message has yet to be compiled.
認証ページが受信されている保留中の状態ですが、完全な認証メッセージはまだコンパイルされていません。
A state wherein authentication data is being or has been received but cannot be used, as the Authentication Type or SAM Type is not supported by the Observer.
認証データが受信されているか、受信されているが使用できない状態。認証タイプまたはSAMタイプはオブザーバーによってサポートされていないためです。
A pending state where a full Authentication Message has been received but other information, such as public keys to verify signatures, is missing.
完全な認証メッセージが受信されたが、署名を検証するためのパブリックキーなどの他の情報が欠落している保留中の状態。
A state where all Authentication Messages that have been received from that claimed sender up to that point pass signature verification and the requirement of Section 6.4.2 has been met.
そのポイントまで送信者を主張したすべての認証メッセージが署名検証とセクション6.4.2の要件が満たされている状態。
A state where all Authentication Messages that have been received from that claimed sender up to that point have passed signature verification, the requirement of Section 6.4.2 has been met, and the public key of the sending UA has been marked as trusted.
その時点までの送信者から受信されたすべての認証メッセージが署名の検証に合格した状態、セクション6.4.2の要件が満たされ、送信UAの公開鍵は信頼されているとマークされています。
The sending UA key will have been marked as trusted if the relevant DIMEs only register DETs (of subordinate DIMEs, UAS operators, and UA) that have been vetted as per their published registration policies, and those DIMEs have been marked, by the owner (individual or organizational) of the Observer, as per that owner's policy, as trusted to register DETs only for trusted parties.
送信UAキーは、関連するダイムのみが（下位ダイム、UASオペレーター、およびUAの）登録登録のみが、公開された登録ポリシーに従って審査され、所有者によってマークされている場合（信頼できるものとしてマークされます。その所有者のポリシーによると、オブザーバーの個人または組織）は、信頼できる当事者のみを登録することを信頼しているように。
A state where there is a mix of Authentication Messages received that are Verified (Appendix A.5) and Unverified (Appendix A.8).
確認された（付録A.5）および未検証（付録A.8）を受け取った認証メッセージの組み合わせがある状態。
State transitions from Verified to Questionable if a subsequent message fails verification, so it would have otherwise been marked Unverified. State transitions from Unverified to Questionable if a subsequent message passes verification or validation, so it would otherwise have been marked Verified. It may transition from either of those states upon mixed results on the requirement of Section 6.4.2.
以降のメッセージが検証に失敗したかどうかを確認したものから疑わしい状態の遷移であるため、それ以外の場合は未検証とマークされていたでしょう。以降のメッセージが検証または検証に合格した場合、未検証から疑わしい状態への遷移があるため、それ以外の場合は検証がマークされています。セクション6.4.2の要件に関する混合結果に伴うこれらの状態のいずれかから移行する可能性があります。
A state where all Authentication Messages that have been received from that claimed sender up to that point failed signature verification or the requirement of Section 6.4.2.
その時点までの送信者から受信されたすべての認証メッセージが、署名の検証またはセクション6.4.2の要件に失敗した状態。
A state where there is a mix of Authentication Messages received that are Trusted (Appendix A.6) and Unverified (Appendix A.8) and the public key of the aircraft is marked as trusted.
信頼されている（付録A.6）および未検証（付録A.8）と航空機の公開鍵が受信された認証メッセージが混在している状態は、信頼できるとマークされています。
State transitions from Trusted to Conflicting if a subsequent message fails verification, so it would have otherwise been marked Unverified. State transitions from Unverified to Conflicting if a subsequent message passes verification or validation and policy checks, so it would otherwise have been marked Trusted. It may transition from either of those states upon mixed results on the requirement of Section 6.4.2.
後続のメッセージが検証に失敗した場合、信頼から矛盾する状態の移行があるため、それ以外の場合は未検証のマークが付けられていたでしょう。以降のメッセージが検証または検証とポリシーチェックを通過した場合、未検証から矛盾への州の移行を行うため、それ以外の場合は信頼されています。セクション6.4.2の要件に関する混合結果に伴うこれらの状態のいずれかから移行する可能性があります。
The recommendations in Section 6.4 may seem heavy-handed and specific. This informative appendix lays out the math and assumptions made that resulted in those recommendations and provides an example.
セクション6.4の推奨事項は、強引で具体的に見えるかもしれません。この有益な付録には、これらの推奨事項をもたらし、例を提供する数学と仮定が作成されています。
In all jurisdictions known to the authors of this document as of its publication (2024), at least the following ASTM Messages are required to be transmitted at least once per second:
この文書の著者にその出版物（2024）の著者に知られているすべての管轄区域において、少なくとも次のASTMメッセージを少なくとも1秒あたりに1回送信する必要があります。
* Basic ID (0x1)
* 基本ID（0x1）
* Location (0x2)
* 場所（0x2）
* System (0x4)
* システム（0x4）
Europe also requires:
ヨーロッパも必要です：
* Operator ID Message (0x5)
* オペレーターIDメッセージ（0x5）
Japan requires not one but two Basic ID messages:
日本には1つではなく2つの基本的なIDメッセージが必要です。
* one carrying a manufacturer assigned serial number
* メーカーがシリアル番号を割り当てたものを運ぶもの
* one carrying a CAA assigned registration number
* 登録番号を割り当てたCAAを運ぶもの
Japan also requires:
日本も必要です：
* Authentication (0x2) using their own unique scheme
* 独自の独自のスキームを使用した認証（0x2）
In all jurisdictions, one further message is optional, but highly recommended for carriage of additional information on the nature of the emergency if the Emergency value is sent in the Operational Status field of the Location/Vector Message:
すべての管轄区域で、さらに1つのメッセージはオプションですが、緊急事態値が場所/ベクトルメッセージの運用ステータスフィールドに送信される場合、緊急事態の性質に関する追加情報の運送には強くお勧めします。
* Self ID (0x3)
* 自己ID（0x3）
To improve the likelihood of successful timely receipt of regulator required RID data elements, most implementations send at a higher rate, whether by repeating the same messages in the same one second interval, or updating message content and sending messages more frequently than once per second. Excessive sending rate, however, could congest the RF spectrum, leading to collisions and counter-intuitively actually reducing the likelihood of timely receipt of RID data.
レギュレーターのタイムリーな受領を成功させる可能性を改善するために、DATA要素が必要なデータ要素が必要な場合、ほとんどの実装は、同じ1秒の間隔で同じメッセージを繰り返すか、メッセージコンテンツを更新し、メッセージを1秒よりも頻繁に送信するかどうかにかかわらず、より高いレートで送信されます。ただし、過度の送信率はRFスペクトルを混雑させる可能性があり、衝突と直感的に実際には、RIDデータのタイムリーな受領の可能性を直感的に減らします。
There are two formulas to determine the number of Authentication Pages required. The following formula is for Wrapper:
必要な認証ページの数を決定するための2つの式があります。次の式はラッパー用です。
wrapper_struct_size = 89 + (25 * num_astm_messages)
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1
The following formula is for Manifest:
次の式はマニフェスト用です。
manifest_struct_size = 89 + (8 * (num_astm_hashes + 3))
manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1
A similar formula can be applied to Links, as they are of fixed size:
同様の式は、固定サイズのリンクに適用できます。
link_page_count = ceiling((137 - 17) / 23) + 1 = 7
Comparing Wrapper and Manifest Authentication Message page counts against total frame counts, we have the following:
ラッパーとマニフェスト認証メッセージページのカウントを合計フレームカウントと比較すると、以下があります。
+==========+=========+==========+=================+===============+
| ASTM | Wrapper | Manifest | ASTM Messages + | ASTM Messages |
| Messages | (w/FEC) | (w/FEC) | Wrapper (w/FEC) | + Manifest |
| | | | | (w/FEC) |
+==========+=========+==========+=================+===============+
| 0 | 5 (6) | 6 (7) | 5 (6) | 6 (7) |
+----------+---------+----------+-----------------+---------------+
| 1 | 6 (7) | 6 (7) | 7 (8) | 7 (8) |
+----------+---------+----------+-----------------+---------------+
| 2 | 7 (8) | 6 (7) | 9 (10) | 8 (9) |
+----------+---------+----------+-----------------+---------------+
| 3 | 8 (9) | 7 (8) | 11 (12) | 10 (11) |
+----------+---------+----------+-----------------+---------------+
| 4 | 9 (10) | 7 (8) | 13 (14) | 11 (12) |
+----------+---------+----------+-----------------+---------------+
| 5 | N/A | 7 (8) | N/A | 12 (13) |
+----------+---------+----------+-----------------+---------------+
| 6 | N/A | 8 (9) | N/A | 14 (15) |
+----------+---------+----------+-----------------+---------------+
| 7 | N/A | 8 (9) | N/A | 15 (16) |
+----------+---------+----------+-----------------+---------------+
| 8 | N/A | 8 (9) | N/A | 16 (17) |
+----------+---------+----------+-----------------+---------------+
| 9 | N/A | 9 (10) | N/A | 18 (19) |
+----------+---------+----------+-----------------+---------------+
| 10 | N/A | 9 (10) | N/A | 19 (20) |
+----------+---------+----------+-----------------+---------------+
| 11 | N/A | 9 (11) | N/A | 20 (22) |
+----------+---------+----------+-----------------+---------------+
Table 5: Page and Frame Counts
表5：ページとフレームカウント
Link shares the same page counts as Manifest with 5 ASTM Messages.
リンクは、5つのASTMメッセージを使用して、マニフェストと同じページを共有します。
Zero ASTM Messages (see Table 5) is where Extended Wrapper (Section 4.3.2) without FEC is used in Message Packs. With a maximum of nine "message slots" in a Message Pack, an Extended Wrapper fills five slots; thus it can authenticate up to four ASTM Messages co-located in the same Message Pack.
ゼロASTMメッセージ（表5を参照）は、FECのない拡張ラッパー（セクション4.3.2）がメッセージパックで使用される場所です。メッセージパックに最大9つの「メッセージスロット」があるため、拡張ラッパーが5つのスロットを埋めます。したがって、同じメッセージパックに共同住宅された最大4つのASTMメッセージを認証できます。
Eleven ASTM Messages (see Table 5) is where a Manifest with FEC invokes the situation mentioned in Section 5.3.
11のASTMメッセージ（表5を参照）は、FECのマニフェストがセクション5.3に記載されている状況を呼び出す場所です。
Eleven is the maximum number of ASTM Message Hashes that can be supported resulting in 14 total hashes. This completely fills the _Evidence_ field of the _UA-Signed Evidence Structure_ making its total size 200 octets. This fits on exactly 9 Authentication Pages ((201 - 17) / 23 == 8), so when the ADL is added, it is placed on the next page (Page 10). Per rule 1 in Section 5.1, this means that all of Page 10 is null padded (expect the ADL octet) and FEC data fills Page 11, resulting in a plus-two page count when FEC is applied.
11は、サポートできるASTMメッセージハッシュの最大数であり、合計14のハッシュになります。これにより、_UAに署名された証拠構造の_evidence_フィールドが完全に埋められます_合計サイズ200オクテットを作成します。これは、正確に9つの認証ページ（（201-17） / 23 == 8）に適合するため、ADLが追加されると、次のページ（10ページ）に配置されます。セクション5.1のルール1によると、これはページ10のすべてがヌルパッド（ADLオクテットを予想）で、FECデータが11ページに記入され、FECが適用されたときにプラス2ページのカウントが得られることを意味します。
This drives the recommendation is Section 4.4 to only use up to 10 ASTM Message Hashes, not 11.
これにより、推奨事項はセクション4.4であり、11ではなく最大10のASTMメッセージハッシュのみを使用します。
This example (Figure 13) is focused on showing that 100% of ASTM Messages can be authenticated over Legacy Transports with up to 125% overhead in Authentication Pages. Extended Transports are not shown in this example, because, for those, Authentication with DRIP is achieved using Extended Wrapper (Section 4.3.2). Two ASTM Message Packs are sent in a given cycle: one containing up to four ASTM Messages and an Extended Wrapper (authenticating the pack), and one containing a Link message with a Broadcast Endorsement and up to two other ASTM Messages.
この例（図13）は、ASTMメッセージの100％が、認証ページで最大125％のオーバーヘッドでレガシートランスポートを介して認証できることを示すことに焦点を当てています。これらの例では、拡張ラッパーを使用してDRIPによる認証が達成されるため、この例には拡張トランスポートは示されていません（セクション4.3.2）。2つのASTMメッセージパックは、特定のサイクルで送信されます。1つは最大4つのASTMメッセージと拡張ラッパー（パックの認証）と、ブロードキャストの承認と最大2つのASTMメッセージを含むリンクメッセージを含む1つです。
This example transmit scheme covers and meets every known regulatory case enabling manufacturers to use the same firmware worldwide.
この例は、メーカーが世界中で同じファームウェアを使用できるようにするすべての既知の規制ケースをカバーして満たしています。
+------------------------------------------------------+
| Frame Slots |
| 00 - 04 | 05 - 07 | 08 - 16 | 17 |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[1] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[2] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[3] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[4] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[5] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[6] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[7] |
+-------------------+---------------+---------+--------+
A = Basic ID Message (0x0) ID Type 1
B = Basic ID Message (0x0) ID Type 2
C = Basic ID Message (0x0) ID Type 3
D = Basic ID Message (0x0) ID Type 4
V = Location/Vector Message (0x1)
I = Self ID Message (0x3)
S = System Message (0x4)
O = Operator ID Message (0x5)
L[y,z] = DRIP Link Authentication Message (0x2)
W[y,z] = DRIP Wrapper Authentication Message (0x2)
M[y,z] = DRIP Manifest Authentication Message (0x2)
y = Start Page
z = End Page
# = Empty Frame Slot
* = Message in DRIP Manifest Authentication Message
Figure 13: Example of a Fully Authenticated Legacy Transport Transmit Schedule
図13：完全に認証されたレガシー輸送送信スケジュールの例
Every common required message (Basic ID, Location/Vector, and System) is sent twice along with Operator ID and Self ID in a single second. The Manifest is over all messages (8) in slots 00 - 04 and 05 - 07.
すべての一般的な必要なメッセージ（基本ID、位置/ベクトル、およびシステム）は、1秒でオペレーターIDと自己IDとともに2回送信されます。マニフェストは、スロット00-04および05-07のすべてのメッセージ（8）を超えています。
In two seconds, either a Link or Wrapper is sent. The content and order of Links and Wrappers runs as follows:
2秒で、リンクまたはラッパーのいずれかが送信されます。リンクとラッパーのコンテンツと順序は次のように実行されます。
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location/Vector (0x1), System (0x4)
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location/Vector (0x1), System (0x4)
Link: IANA on UAS RID Apex
After perfect receipt of all messages for a period of 8 seconds, all messages sent during that period have been authenticated using the Manifest (except for the Authentication Messages themselves). Within 136 seconds, the entire Broadcast Endorsement chain is received and can be validated. Interspersed in this schedule are 4 messages sent not only in their basic [F3411] form, but also in DRIP Wrapper messages, together with their attached signatures, to defend against the possibility of attack against the detached signatures provided by the Manifest messages.
すべてのメッセージを8秒間完全に受信した後、その期間中に送信されたすべてのメッセージは、マニフェストを使用して認証されました（認証メッセージ自体を除く）。136秒以内に、放送承認チェーン全体が受信され、検証できます。このスケジュールに散在するのは、基本的な[F3411]フォームだけでなく、マニフェストメッセージによって提供される分離された署名に対する攻撃の可能性を防御するために、添付の署名とともにドリップラッパーメッセージにも送信される4つのメッセージです。
Assuming the following DET and HI:
次のdetとhiを仮定する：
2001:3f:fe00:105:a29b:3ff4:2226:c04e
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813
The following ASTM Messages are to be sent in a single second:
次のASTMメッセージは、1秒で送信されます。
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
32004578616d706c652053656c662049440000000000000000
420000000000000000000100000000000000000010ea510900
52004578616d706c65204f70657261746f7220494400000000
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
420000000000000000000100000000000000000010ea510900
This is a Link with FEC that would be spread out over 8 seconds:
これは、8秒間にわたって広がるFECとのリンクです。
2250078910ea510904314b8564b17e66662001003ffe000105
2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7
2252f5ed0ac08a81975034297bea2b000418132001003ffe00
22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222
2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46
2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94
2256d9ad97940d280000000000000000000000000000000000
2257a03b0f7a6feb0d198167045058cfc49f73129917024d22
This is a Wrapper with FEC that would be spread out over 8 seconds:
これは、8秒間にわたって広がるFECのラッパーです。
2250078b10ea510902e0dd7c6560115e671200000000000000
22510000000000000000000000000060220000420000000000
2252000000000100000000000000000010ea5109002001003f
2253fe000105a29b3ff42226c04ef0ecad581a030ca790152a
22542f08df5762a463e24a742d1c530ec977bbe0d113697e2b
2255b909d6c7557bdaf1227ce86154b030daadda4a6b8474de
22569a62f6c375020826000000000000000000000000000000
2257f5e8eebcb04f8c2197526053e66c010d5d7297ff7c1fe0
This is the Manifest with FEC sent in the same second as the original messages:
これは、元のメッセージと同じ秒でFECが送信されたマニフェストです。
225008b110ea510903e0dd7c6560115e670000000000000000
2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01
22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928
22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
22552226c04efb729846e7d110903797066fd96f49a77c5a48
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83
The authors acknowledge the following individuals:
著者は、次の個人を認めています。
* Ryan Quigley, James Mussi, and Joseph Stanton of AX Enterprize, LLC for early prototyping to find holes in earlier drafts of this specification.
* この仕様の初期のドラフトで穴を見つけるための早期プロトタイピングのために、Ryan Quigley、James Mussi、Axe Enterprize、LLCのJoseph Stanton。
* Carsten Bormann for the simple approach of using bit-column-wise parity for erasure (dropped frame) FEC.
* Carsten Bormann消去（ドロップされたフレーム）FECのためにビットコラムのパリティを使用する簡単なアプローチのためのCarsten Bormann。
* Soren Friis for pointing out that Wi-Fi implementations would not always give access to the MAC Address, as was originally used in calculation of the hashes for DRIP Manifest. Also, for confirming that Message Packs (0xF) can only carry up to 9 ASTM frames worth of data (9 Authentication Pages).
* Soren Friisは、DRIPマニフェストのハッシュの計算で当初使用されていたように、Wi-Fiの実装が常にMacアドレスにアクセスできるとは限らないことを指摘しています。また、メッセージパック（0xF）が最大9つのASTMフレーム相当のデータ（9認証ページ）しか持ち運ぶことができることを確認するために。
* Gabriel Cox (chair of the working group that produced [F3411]) for reviewing the specification for the SAM Type request as the ASTM Designated Expert.
* ASTM指定の専門家としてSAMタイプ要求の仕様をレビューするために、Gabriel Cox（[F3411]を生成したワーキンググループの議長）。
* Mohamed Boucadair (Document Shepherd) for his many patches and comments.
* Mohamed Boucadair（Document Shepherd）の多くのパッチとコメント。
* Eric Vyncke (DRIP AD) for his guidance regarding the document's path to publication.
* Eric Vyncke（ドリップ広告）は、文書の出版への道に関する指導について。
The authors also thank the following reviewers:
著者はまた、次のレビュアーに感謝します。
* Rick Salz (secdir)
* リック・サルツ（秒）
* Matt Joras (genart)
* マットジョラス（ジェネルト）
* Di Ma (dnsdir)
* di ma（dnsdir）
* Gorry Fairhurst (tsvart)
* ゴリーフェアハースト（TSVART）
* Carlos Bernardos (intdir)
* カルロス・ベルナルド（intdir）
* Behcet Sarikaya (iotdir)
* Behcet Sarikaya（Iotdir）
* Martin Duke (IESG)
* マーティンデューク（IESG）
* Roman Danyliw (IESG)
* ローマのダニリュー（IESG）
* Murray Kucherawy (IESG)
* マレー・クチェハウィー（IESG）
* Erik Kline (IESG)
* エリック・クライン（IESG）
* Warren Kumari (IESG)
* ウォーレン・クマリ（IESG）
* Paul Wouters (IESG)
* PaulWouters（IESG）
Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Stuart Card
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com