Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness
draft-wiethuechter-drip-det-tada-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Adam Wiethuechter | ||
| Last updated | 2025-07-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wiethuechter-drip-det-tada-00
drip Working Group A. Wiethuechter
Internet-Draft AX Enterprize, LLC
Intended status: Standards Track 28 July 2025
Expires: 29 January 2026
Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain
Awareness
draft-wiethuechter-drip-det-tada-00
Abstract
This document standardizes usage of Drone Remote Identification
Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
(UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
and Advanced Air Mobility (AAM). DETs can serve as Session IDs for
privacy, Authentication Key IDs for accountability, and encryption
key IDs for confidentiality.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 January 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wiethuechter Expires 29 January 2026 [Page 1]
Internet-Draft det-tada July 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Additional Definitions . . . . . . . . . . . . . . . . . 5
3. Interactions & Responsibilities . . . . . . . . . . . . . . . 5
3.1. UAS Observers . . . . . . . . . . . . . . . . . . . . . . 6
3.2. UAS Operators . . . . . . . . . . . . . . . . . . . . . . 7
3.3. UAS Manufacturers . . . . . . . . . . . . . . . . . . . . 7
3.4. HDA Operators . . . . . . . . . . . . . . . . . . . . . . 8
3.5. RAA Operators . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Apex Operators . . . . . . . . . . . . . . . . . . . . . 10
4. Requirements for DIME Operation . . . . . . . . . . . . . . . 11
4.1. Common UAS RID Data Model . . . . . . . . . . . . . . . . 11
4.2. Registration . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Interaction Model . . . . . . . . . . . . . . . . . . 13
4.2.3. Interface & Encoding . . . . . . . . . . . . . . . . 15
4.2.4. Registration Model . . . . . . . . . . . . . . . . . 17
4.2.5. Response Model . . . . . . . . . . . . . . . . . . . 19
4.3. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Public Information Registries . . . . . . . . . . . . 21
4.3.2. Private Information Registries . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5.1. RAA Delegation for CAAs . . . . . . . . . . . . . . . . . 23
5.2. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . 23
5.3. RDAP Extensions Registry . . . . . . . . . . . . . . . . 24
5.4. Media Types . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. application/drip+cwt Registration . . . . . . . . . . 24
5.4.2. application/drip+jwt Registration . . . . . . . . . . 25
5.5. DRIP CBOR/JSON Keys . . . . . . . . . . . . . . . . . . . 26
5.5.1. Review Criteria . . . . . . . . . . . . . . . . . . . 27
5.5.2. CBOR/JSON Key Fields . . . . . . . . . . . . . . . . 27
5.5.3. Registration Form . . . . . . . . . . . . . . . . . . 27
5.5.4. Initial Values . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Wiethuechter Expires 29 January 2026 [Page 2]
Internet-Draft det-tada July 2025
6.1. Cryptographic Materials . . . . . . . . . . . . . . . . . 31
7. Privacy & Transparency Considerations . . . . . . . . . . . . 31
7.1. DETs as Session ID and Authentication Key ID . . . . . . 31
7.2. Selective Encryption . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. HID Abbreviation . . . . . . . . . . . . . . . . . . 36
Appendix B. Compliance Submission Forms . . . . . . . . . . . . 38
Appendix C. CSR Examples . . . . . . . . . . . . . . . . . . . . 38
Appendix D. Compliance Testing . . . . . . . . . . . . . . . . . 39
D.1. Registration Interface . . . . . . . . . . . . . . . . . 40
D.2. Public Query Interface . . . . . . . . . . . . . . . . . 40
D.3. Private Query Interface . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
1.1. Purpose
This document provides to stakeholders in a National Airspace System
(NAS), such as a Civil Aviation Authority (CAA) and its constituents,
a point of entry into a set of relevant standards. These standards
provide guidance to enable trustworthy Air Domain Awareness (ADA)
primarily via cooperative technologies. Such technologies can
include, but are not limited to, Unmanned Aircraft (UA) Systems (UAS)
Remote Identification (RID), UAS Traffic Management (UTM) and
Advanced Air Mobility (AAM).
This document specifies an interoperable manner of achieving the
stated objectives in an international context to be used by CAAs in a
relevant Means of Compliance (MOC). One such MOC is ASTM [F3586] for
UAS RID to comply with the United States (US) CAA regulations.
A CAA MAY override any technical specification in this document but
MUST, if claiming compliance with this document, provide the reason
and an alternative specification satisfying the same objective.
1.2. Background
[RFC9153] provides comprehensive background on the UAS RID use-case
and the UTM/AAM context.
Trustworthiness revolves around identification and authentication.
[RFC9374] defines the Drone Remote Identification Protocol (DRIP)
Entity Tag (DET), a trustable identifier backed by asymmetric
cryptography. [RFC9575] standardizes authentication of DETs and
associated information using strong cryptography suited for
Wiethuechter Expires 29 January 2026 [Page 3]
Internet-Draft det-tada July 2025
constrained mobile wireless links (typical of Broadcast RID).
Broadcast and Network RID are defined by ASTM [F3411] which
designates the International Civil Aviation Organization (ICAO) to
maintain code-points for Specific Session ID Types and Specific
Authentication Methods (SAMs) [ICAO-NUMBERS]. ICAO includes DETs as
a Specific Session ID Type and lists the four DRIP SAMs.
DETs generated by registrants (typically a UAS Operator or UAS) are
merely proposed until they are registered within the hierarchy
consisting of at least two levels above the leaf DET: Registered
Assigning Authority (RAA) and Hierarchial Host Identity Tag (HHIT)
Domain Authority (HDA). The registry system, made up of DRIP
Identity Management Entities (DIMEs) acting as either RAAs or HDAs,
ensures uniqueness within the hierarchy, endorses inclusion through
X.509 certificates, and provides access to public and private
information associated with a DET registration. Public information
is served using the Domain Name System (DNS) and is specified in
[DET-DNS]. Private information, such as Personally Identifiable
Information (PII), is served using the Registration Data Access
Protocol (RDAP, [STD95]) and protected through policy based
differentiated access.
This document specifies fundamental registration processes and
interactions surrounding the Private Information Registry function
defined in the DRIP Architecture ([RFC9434]).
1.3. Scope
Participating entities are assumed in this document to be in
compliance with relevant existing UAS standards such as ASTM [F3411],
[F3548] and [ICAO-ACCP].
This document governs use of a DET in the following cases:
* An entity that uses a Session ID (some participating entities,
e.g. HDAs, may not need Session IDs), MUST use a DET for that
Session ID.
* An entity that participates in DRIP interactions (even if not
needing a Session ID), MUST use a DET for the DRIP public key ID
in those interactions.
* An entity that requires a strongly cryptographically verifiable IP
compatible identifier, MAY use a DET for any other legal purpose.
* An entity SHOULD NOT use a DET as a locator in physical or logical
space (e.g. as a globally routable IPv6 address outside of an
overlay network), as deconflation is intended, see [RFC9063].
Wiethuechter Expires 29 January 2026 [Page 4]
Internet-Draft det-tada July 2025
The archetypal case is a UAS for which the DET serves as both the UAS
ID (first case above) and the Authentication Key ID (second case).
Author Note: narrow context for at least first bullet above.
2. Terminology
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.
2.1. Additional Definitions
This document makes use of terms (PII, USS, etc.) defined in
[RFC9153], [RFC9434] and [RFC9374]. For convenience of the reader,
some of the major definitions are restated here.
DRIP Identity Management Entity (DIME): Originally defined in
[RFC9434] and expanded technically in [DET-DNS]. An entity
providing registrar and registry services specifically for DETs.
They can act as either an Registered Assigning Authority (RAA) or
Hierarchial Host Identity Tag (HHIT) Domain Authority (HDA).
Web Token: In the context of this specification; a Web Token can be
either a Concise Binary Object Representation (CBOR, [STD94]) Web
Token (CWT, [RFC8392]) or JavaScript Object Notation (JSON,
[STD90]) Web Token (JWT, [RFC7519]).
3. Interactions & Responsibilities
This section outlines the various entity roles in the ecosystem. For
each, it summarizes motivations for participating in that DRIP role,
as well as the interactions and responsibilities they have in doing
so. All entity roles, except as otherwise noted, each entity in a
given role MUST register a DET with a parent entity in the
corresponding parental role (e.g. an HDA must register with an RAA),
as per Section 4.2, and MUST use it subsequently in all DRIP
interactions requiring an entity ID.
Wiethuechter Expires 29 January 2026 [Page 5]
Internet-Draft det-tada July 2025
3.1. UAS Observers
An Observer is typically an individual who has a device capable of
wirelessly receiving Broadcast RID whether it be an opportunistic
passerby with a local-only (i.e. non-Internet connected) smartphone
application or a widely deployed sensing system with various IP-based
back-hauls. Each has their own motivations for detecting a UAS in
their area and querying for additional information. Typically in
DRIP, Observers are expected to use DNS (when able) to obtain at
least the public keys of unknown DETs and use it to validate
signatures found in ASTM [F3411] Authentication Messages. Some
Observers may be granted, by cognizant authorities, authorization to
perform more detailed queries of further information, that is
considered private (as not explicitly classified as public, placed in
DNS, and/or transmitted in cleartext in Broadcast RID).
Author Note: Broadcast RID here can be dropped or substituted for
some phrase comparing Observers to a sensor head, but distinct
from a Display-only Observer. If that makes sense and if it is a
good distinction to have? One could say Display Applications are
in a way Observers (albeit very far removed from the field in most
cases where the term is used). Unless we make them their own
class of users that could use DETs (and for what?)
All Observers supporting DRIP:
* MUST adhere to relevant details of Section 6.4.2 of [RFC9575] with
regards to receive processing of DRIP SAMs.
- Processing of SAMs MAY be deferred or outsourced to a dedicated
system.
* RECOMMEND display all DETs following [RFC5952] or as described in
Appendix A.
Author Note: as justification for "processing MAY be deferred":
Intention here was to allow for Observers not needing to fully
process data if desired and push said processing to SDSPs. An
example is a slim Finder concept that does no parsing of RID data,
just extraction out of transport framing.
Observers authorized by cognizant authorities to access any private
(in addition to all public) information recorded as part of the
registration process also:
* MUST support RDAP authentication/authorization mechanisms allowed
by the cognizant authority.
Wiethuechter Expires 29 January 2026 [Page 6]
Internet-Draft det-tada July 2025
- Those RECOMMENDED for global harmonization are identified in
Section 4.3.2.4.
* MUST register to authentication systems as required by the
cognizant authority.
- A DIME MAY be used as part of an authentication system.
3.2. UAS Operators
UAS Operators is used herein as a catch-all term for several more
specific UAS related roles: Remote Pilot, Pilot In Command (PIC),
party (typically an organization) to whom or which the UAS is
registered with the cognizant CAA, etc. DRIP does not attempt to
clarify the definition of Operator to match any specific CAA, instead
using the ambiguity to group these roles based on their similar DRIP
interactions.
A UAS Operator's desire to use DETs can be any number of the
following operational factors:
* Confidentiality of flights through Session IDs.
* Privacy of Remote Pilots by encrypting their Ground Control
Station (GCS) position.
- This option may be constrained by their jurisdiction's RID
regulations.
* Reputation of their UAS based on observation and reports of
behavior supported by Authentication.
To participate a UAS Operator SHOULD use a DET, registered either
with an RAA or HDA, as part of any interactions in DRIP, such as
registering a UAS Session ID for their UA. A UAS Operator MAY use
another cryptographic scheme for interactions but it MUST be
asymmetric with their public key accessible to all domain
participants via a standardized method for the cryptographic purpose
of signature verification.
3.3. UAS Manufacturers
While UAS Manufactures do not have a direct requirement for DRIP,
they typically wish to maintain good reputation of their brands and
are often driven by market forces. Such forces include requirements
and preferences of both UAS Observers and Operators.
Wiethuechter Expires 29 January 2026 [Page 7]
Internet-Draft det-tada July 2025
This document assumes a UAS Manufacturer is already in compliance
with ASTM [F3411]. Thus those that wish to support DRIP also:
* MUST provide a mechanism, typically through a GCS, to generate and
register a DET for use as either a Session ID, Authentication Key
ID or both.
- MUST bind DET to both UAS Serial Number and Operator. Binding
MAY be indirect if system can verify Serial Number already
registered to Operator.
- SHOULD be issued in a manner that keeps private key ONLY ever
on UA, does not expose it to GCS etc., but MAY be done in
manner that exposes it to GCS or Operator if necessary.
- SHOULD allow user selection of a parent DIME (typically HDA)
using a URI, Hierarchy ID (HID) value, or both
- MAY support registering multiple DETs in a batch transaction
* SHOULD provide a mechanism to enable, during registration,
subsequent encryption of selected fields (e.g. pilot/GCS
location), only if the CAA allows it.
* MUST follow Section 6 of [RFC9575] as it relates to transmission
of SAMs, when using DET as an Authentication Key ID
* MUST, in the [F3411] Basic ID Message, set the UAS ID Type to 4,
Specific Session ID Type to 1, and DET in network byte order, when
using DET as a UAS Session ID
* MAY use a DET, following Section 4.2 of [RFC9374], as a UAS Serial
Number
- It is expected that the UAS Manufacturer runs their own HDA,
under which these DETs are registered
3.4. HDA Operators
In the UTM context, it is expected that the HDA function will be
provided by a UAS Service Supplier (USS) to its clients (e.g. UAS
Operators). This can be in-house or out-sourced to a service bureau
more specialized in cryptographically verifiable identifiers usable
to access data and systems on networks. Outside the UTM context, an
HDA can be a stand-alone provider to any registrant desiring a DET,
or more generally HHIT.
Being associated with a USS has some operational benefits:
Wiethuechter Expires 29 January 2026 [Page 8]
Internet-Draft det-tada July 2025
* Ease for UAS Operators to use both Session IDs and UTM together
* Binding between the DET and Operational Intent
- Enables safer use of encryption
- Ability to keep DET private until just before an operation goes
active
An HDA Operator:
* MUST register, with its parent RAA, one or more DETs, and use it
or them in DRIP interactions
* MUST implement interfaces and functions described in Section 4
* MUST maintain DET registrations with relevant PII as required by
their jurisdiction
* MUST fulfill the requirements of their jurisdiction
* SHOULD NOT provide to clients the ability to enable encryption of
data elements considered PII, especially in Broadcast RID
As part of a USS an HDA Operator also:
* MAY provide encryption ID services, if allowed by jurisdiction
* MAY have its registration interfaces (Section 4.2) be integrated
into relevant USS interfaces and functions
* SHOULD defer the publishing of a client DET in DNS when it is
bound with an Operational Intent until it is "active"
- Methods to sync an Operational Intent in a USS state and DET
state in HDA are out of scope for this document
3.5. RAA Operators
In the context of this document, RAA Operators are typically CAAs or
other cognizant authorities of a Nation State. Each Nation State is
allocated four RAA values that are used at their discretion. To
obtain these allocations, a Nation State contacts the Apex operator
for the UAS or other applicable hierarchy, currently IANA on behalf
of ICAO, requesting their provisioning providing any details required
by the Apex Operator to configure domain delegations.
Wiethuechter Expires 29 January 2026 [Page 9]
Internet-Draft det-tada July 2025
Each RAA has the responsibility to delegate HDAs under them.
Allocation methods of HDA values are at the discretion of the RAA
Operator and their policies. Any requirements to operate under an
RAA, beyond those as defined in this document to operate as an HDA,
are out of scope for this document.
An RAA Operator:
* MUST obtain an RAA value(s) from the Apex Operator and provide
content for NS RRType(s), see Section 5
* MUST register, with its parent (if any), one or more DETs, and use
it or them in DRIP interactions
* MUST implement interfaces and functions described in Section 4
* MUST maintain DET registrations with relevant PII as required by
their jurisdiction
* MUST provide requirements for prospective HDA Operators, and
SHOULD do so publicly via an easily located web site
* MUST ensure HDA Operator compliance with this specification
Author Note: subsection or appendix on a potential RAA scheme for
CAA? i.e. 1x MIL, 1x GOV, 1x COMMERCIAL, 1x SPARE with some
example guidance on HDA allocation?
3.6. Apex Operators
TODO
Review(SWC): we need to introduce the concept of Apex early in the
document and give it a section immediately after this one, as even
though IANA won't get involved in DRIP certificates, and CAAs will
mutually cross-certify through the ACCP/TFP for now (maybe
forever), there is in fact an Apex already, as IANA has to
delegate the DET zones -- it is just that IANA won't do _all_ of
the things ultimately expected of the Apex for a given [industry
sector's] DET hierarchy
Wiethuechter Expires 29 January 2026 [Page 10]
Internet-Draft det-tada July 2025
4. Requirements for DIME Operation
The requirements below apply to both RAA and HDA Operators with a
focus on how HDA Operators provide registration and related services
for their clients (i.e. UAS Operators and their UAS). All data
models are represented in this document using the Concise Data
Definition Language (CDDL, [RFC8610]) using the prelude defined in
Appendix E of [RFC8610].
4.1. Common UAS RID Data Model
A common data model is specified by DRIP for various UAS RID elements
typically transmitted over ASTM [F3411].
The field names and their general typing of Figure 1 are borrowed
from the ASTM [F3411] data dictionary (Table 1 and Table 2). See
that document for additional context and background information on
aviation application-specific interpretation of the field semantics.
The contents of this model are considered opaque to DRIP.
The model is an expansion upon the BRID RRType model defined in
Section 5.2 of [DET-DNS].
uas-datum = {
? timestamp => utc,
? uas_type => 0..15,
? uas_ids => [
+ [
id_type: 0..15,
uas_id: uas-id
]
],
? ua_status => 0..15,
? ua_position => [
lla: position,
barometric_altitude: number / null
],
? ua_bearing => uint,
? ua_speed => [
vertical: number / null,
horizontal: number / null
],
? ua_height => [
agl: bool,
height: number
],
? accuracy => [
vertical: 0..15,
Wiethuechter Expires 29 January 2026 [Page 11]
Internet-Draft det-tada July 2025
horizontal: 0..15,
altitude: 0..15,
barometric: 0..15,
timestamp: 0..15
],
? auth => [
+ [
auth_type: 0..15,
data: auth-data
]
],
? self_id => [
desc_type: 0..255,
desc: tstr .size 23
],
? operator_position => position,
? classification => [
region: 0..8,
category: 0..15,
class: 0..15
],
? area => [
count: 1..255,
radius: number,
floor: number,
ceiling: number
],
? operator_id => [
operator_type: 0..255,
operator_id: tstr .size 20
],
? compliance => [+ uint]
}
Figure 1: Common UAS RID CDDL
The mapping between JSON keys (as strings) and CBOR keys (as unsigned
integers) for Figure 1 are defined in Section 5.5.
Author Note: do we specify the enumeration for compliance in this
document? Is it an IANA registry?
4.2. Registration
This section defines the interaction model, data models and methods
for registration of a DET into a DIME for global interoperability.
Standardization of additional methods and data models to register to
a DIME (DETs or otherwise) is out of scope for this document.
Wiethuechter Expires 29 January 2026 [Page 12]
Internet-Draft det-tada July 2025
4.2.1. Disclaimer
DRIP does NOT provide protection against incorrect (e.g. fraudulent)
data entered during registration or asserted subsequently. DRIP does
protect against alteration (intentional or unintentional) of data
subsequent to its assertion by the cryptographic signer. The signer
might be the proximate sender (e.g. UA transmitting Broadcast RID) or
might be an attestor far away and long ago (e.g. root Certificate
Authority). It is the duty of the operator of each DIME, or the
party on whose behalf the DIME is being operated, to validate the
registration data. The RAA (e.g. CAA) SHOULD provide services to
obtain this goal, see Section 4.2.4.2.
4.2.2. Interaction Model
Registration of DETs uses the interaction model shown in Figure 2.
registrant dime
| |
(0) GEN_DET/HI | |
(1) GEN_CSR | |
|----(2) INPUT----->|
| | (3) VALID_INPUT?
|<-------FAIL-------|
| | (4) DUPE_HI?
|<-------FAIL-------|
| | (5) DUPE_DET?
|<-------FAIL-------|
| | (6) GEN_CERTS
| | (7) UPDATE_DATABASE
| | (8) UPDATE_NS
|<----(9) OUTPUT----|
Figure 2: Simplified DET Registration Z-Diagram
(0) GEN_DET/HI: The registrant that plans to use the identity and
its cryptographic properties SHOULD generate the asymmetric key-
pair of their choosing and MUST protect the private key with Best
Current Practices. The registrant MAY derive the corresponding
DET. How the registrant obtains the desired HID for DET
generation is out of scope for this document.
(1) GEN_CSR: The registrant MUST generate a Certificate Signing
Request (CSR) for their HI/DET. See Section 4.2.4.1 for more
details.
(2) INPUT: The registrant MUST format and send the required
Wiethuechter Expires 29 January 2026 [Page 13]
Internet-Draft det-tada July 2025
information for a given service registration as specified by the
DIME using Section 4.2.3.
(3) VALID_INPUT?: The DIME, upon receipt of service registration
inputs, MUST validate the input data. This may be simply
performing syntax checks to ensure the data is properly formatted
all the way to full semantic validation (see Section 4.2.4.2).
Signed data MUST have their signatures verified before further
processing. Failure of input validation SHOULD returns errors to
the registrant.
(4) DUPE_HI?: The DIME MUST check that the proposed HI is not a
already in use within the specified HID scope. The registrant
SHOULD be notified with an error if duplication is detected.
(5) DUPE_DET?: The DIME MUST check that the proposed DET, derived
from the HI, is not a already in use within the specified HID
scope. If the registrant proposed a DET with HID outside that of
the DIME, it MUST be rejected. If the registrant only provided
the HI, the DIME MUST generate the DET using the HID for which
that DIME is authoritative. The registrant SHOULD be notified
with an error if duplication is detected.
(6) GEN_CERTS: The DIME, after all the above validation, MUST
generate a Broadcast Endorsement using the provided HI and DET
from the registrant as the evidence. This Endorsement is used in
[RFC9575]. The DIME MUST also generate a corresponding X.509
certificate as per Section 4.2.5.1, confirming that the DIME has
accepted the registrant's DET/HI pair for registration. Other
Certificates MAY be generated during registration but are out of
scope for this document.
(7) UPDATE_DATABASE: The DIME MUST update the Private Information
Registry with all registration data required by the jurisdiction
or the DIME's own policy, typically including PII, all of which
must be protected by AAA as per applicable regulation and policy.
It MAY include additional metadata or public information. How the
Private Information Registry is updated is out of scope for this
document.
(8) UPDATE_NS: The DIME MUST update the Authoritative Name Server
with any public information that was part of the registration.
This information MUST be stored as described in [DET-DNS].
(9) OUTPUT: The DIME, upon successful updates of the Private
Information Registry and Authoritative Name Server, responds
according to Section 4.2.3.
Wiethuechter Expires 29 January 2026 [Page 14]
Internet-Draft det-tada July 2025
4.2.3. Interface & Encoding
Registration request and response data MUST be encapsulated in a Web
Token (either CWT [RFC8392] or JWT [RFC7519]). For Session IDs and
Authentication Key IDs the registrant usually is the Operator (or a
proxy for the Operator such as the GCS) but MAY be the UA directly if
the UA has a long term cryptographic identity.
The method for a registrant to find a DIME is out of scope for this
document. DIMEs MUST use [RFC8615] to provide DRIP-related
interfaces and perform redirects to the relevant URIs. DIME
registration endpoints MUST use POST expecting a Web Token from
registrants. During a request a registrant MUST encrypt the Web
Token in accordance with PRIV-2 of Section 4.3.1 of [RFC9153] as
during a request it typically includes PII. An example is shown in
Figure 3.
Author Note: /.well-known/ could be a single URI like register-
hhit or more specific ones like uas-operator and uas-session. Do
we have a preference?
POST /.well-known/register-hhit HTTP/1.1
Host: uss.example.com
Accept: application/drip+cwt, application/drip+jwt
Content-Type: application/drip+cwt
Content-Length: <CWT length>
[ CWT from registrant ]
Figure 3: Example REST Registration API (request)
HTTP/1.1 308 Permanent Redirect
Accept: application/drip+cwt, application/drip+jwt
Location: hda.example.net/foo/bar
Allow: POST
Figure 4: Example REST Registration API (redirect)
Author Note: per Section 15.4.2 of RFC9110, a 301 MAY change POST
to GET on the re-request. We do not want this behavior so intend
to use 308 instead (as it suggests). However, RFC9205 indicates
that mapping application behavior to HTTP Status Codes is bad
practice and does not say anything about specifying a specific
redirect code for a request. There are some behaviors during
registration where it would make sense for DRIP to explicitly
specify the expected Status Code rather than leave it up to
implementor (see Section 4.2.4.2). What should I do?
Wiethuechter Expires 29 January 2026 [Page 15]
Internet-Draft det-tada July 2025
Author Note: per RFC9205 it is recommended to use the Link header
of HTTP (RFC8288) instead of redirects. So we would use ./well-
known/ and then perform a Link to the specific server resource
(either local or remote)? I think using a HTTP Redirect makes
more sense, just need to specify that 308 MUST be used and that
the server MUST set the Location header field of the HTTP response
so clients re-request the POST using the Location value.
The DIME responds, upon successful registration, with their own Web
Token contain the data model defined in Section 4.2.5. The Web Token
SHOULD be encrypted, if containing any PII. An example is shown in
Figure 5.
HTTP/1.1 200 OK
Accept: application/drip+cwt, application/drip+jwt
Content-Type: application/drip+cwt
[ CWT from DIME ]
Figure 5: Example REST Registration API (response)
This document allocates application/drip+cwt, application/drip+jwt
and application/drip to the Media Types registry. It also allocates
register-hhit to the /.well-known/ registry.
4.2.3.1. Using CoAP for Registration
Support of the Constrained Application Protocol (CoAP, [RFC7252]) is
OPTIONAL.
When using CoAP, DTLS SHOULD be used when possible and MUST send the
data models (Section 4.2.4 and Section 4.2.5) encoded as CBOR. When
DTLS is not possible, and CoAP is instead used with UDP, model data
MUST be encapsulated, signed and encrypted in a CWT as above.
4.2.3.2. Guidance on Registration Errors
The following registration failure conditions and response are
informative:
* Upon invalid input from the registrant, the DIME SHOULD respond
with either 400 (Bad Request) or 403 (Forbidden) as appropriate.
* Upon a duplicate HI or DET, the DIME SHOULD respond with 409
(Conflict).
* Any other processing failure of registration by a DIME SHOULD be
responded with an appropriate Server Error status code.
Wiethuechter Expires 29 January 2026 [Page 16]
Internet-Draft det-tada July 2025
Care should be given when responding with 403 (Forbidden) to not
expose any information that could be used to socially engineer a fake
request. For example, when following Section 4.2.4.2, it would be
unwise for the HDA to detail an exact reason for the rejection. A
malicious registrant could spam the endpoint, farming information on
what UAS Serial Numbers, Operator IDs and their potential bindings
exist to exploit.
It should be noted that the above would be avoided with properly
configured systems since signature validation and denial of service
mitigations would be before the HDA even attempts to ascertain
validation from the RAA.
4.2.4. Registration Model
The data sent to the DIME for a given registration is policy driven.
For example a Session ID registration SHOULD include a CAA specific
identifier of the Operator to enable the private binding of the
Session ID to both the Serial Number (found in the CSR) but also the
Operator themselves.
registration-content = {
csr_list: [
+ csr: [
idx: hash,
entity_type: uint,
csr: x509,
vnb: utc / null,
vna: utc / 1..15638400 / null,
meta: { metadata }
]
],
metadata
}
Figure 6: Registration Model CDDL
The data model defined in Figure 6 is what is minimally required for
a DIME to be functional. Additional fields SHOULD be registered to
IANA under Section 5.5 for global harmonization. RAAs and HDAs MAY
use their respective keys and their associated maps to define
additional keys to be included in a registration. A dedicated
Private Use space is provided for RAAs and HDAs to define keys and
their uses.
The uas map item uses the data model found in Section 4.1 to carry
any static information expected to also be found over Broadcast RID.
It MUST NOT include in the uas_ids key the UAS Serial Number when a
Wiethuechter Expires 29 January 2026 [Page 17]
Internet-Draft det-tada July 2025
Session ID is being registered. It also MUST NOT contain the
operator_location key, as this information is usually considered PII
and typically is dynamic or unknown at time of registration. The
DIME MUST fill in the auth key with any SAMs related to a
registration and place the data model into DNS with Section 5.2 of
[DET-DNS] when the registrant entity is required to use Broadcast RID
and expecting to use [RFC9575].
The registrant can select from a number of options to encode the
values of valid not before (vnb) and valid not after (vna) for time
of applicability of an individual CSR (csr-data). The use of the
time or tdate types allow for absolute time references. The use of
the uint type for vna specifies a positive offset in seconds from an
absolute time. When null is used the registrant is informing the
DIME that for vnb the DIME MUST use the current time as vnb during
registration and for vna the DIME MUST set vna to a time such that
the default DIME policy for maximum delta between vnb and vna is not
exceeded.
Implementation Note: due to not differentiating between integers
and floats in its number type, implementations using JSON as the
encoded format MUST check the value of vna to determine if its
being used as an offset or absolute time.
As an example of the use of vnb and vna, a registrant may set
vnb=null and vna=3600. The DIME in this instance would use the
current absolute time at receipt of the registration request for vnb
and then apply the offset specified by vna to obtain an absolute time
for vna that is 3600 seconds after vnb. These absolute times of vnb
and vna are then used in the certificate being created by the DIME to
endorse the registration Section 4.2.5.1.
4.2.4.1. Certificate Signing Request
Author Note: RGM, does this section suffice to define the CSR
models or do we need some more like what is in [DKI]?
An X.509 CSR MUST be used to convey the various cryptographic and
identity properties of an entity during a registration. For CSRs the
content of the following fields for DRIP should be noted:
Subject: As defined in Section 4.1.2.6 of [RFC5280]. This field is
filled in based on the type of entity being registered. When the
attribute type is set to SERIAL_NUMBER, it MUST contain the ANSI/
CTA 2063-A UAS Serial Number encoded as a string. Other attribute
types are subject to policy and are out of scope for this
document.
Wiethuechter Expires 29 January 2026 [Page 18]
Internet-Draft det-tada July 2025
Extensions: When the registrant knows which HID and/or Suite ID they
want the CSR SHOULD contain the Subject Alternate Name extension
as defined in Section 4.2.1.6 of [RFC5280] using ipAddress
containing the fully formed DET and MUST mark the extension as
critical. This DIME MUST check to ensure that the DET located in
the extension is properly generated with the included public key
of this CSR. If the registrant does not know or care the value of
their HID and/or Suite ID, the Extensions field MUST NOT appear
and the DIME will use its HID for DET generation using the public
key provided by this CSR.
Appendix C contains examples of common CSRs used in DET registration.
4.2.4.2. Validating Fields
In certain circumstances field contents may only be properly
validated by other entities outside of DRIP. For example the binding
between UAS Serial Number and Operator ID should already be known by
the CAA, as typically this information is required out of band of
DRIP directly to the CAA in some form. The CAA should provide or
itself have access to an "oracle" that can validate these claimed
bindings for registration to proceed. If such an "oracle" is not
consulted there is a risk that information being registered is
fraudulent and DRIP has no method or authority to confirm the claims.
If such information is accepted, future information queries by
authorities can result in bogus data being returned, with no binding
to an actual UAS or Operator.
The CAA SHOULD, as part of its capacity as an RAA onboarding an HDA,
provide data models, communication framework and any authentication
mechanisms to query the oracle directly if the CAA allows HDAs to
perform the queries themselves. Otherwise the RAA MUST provide an
HTTPS POST interface that consumes a Web Token generated by the HDA
containing the registrant Web Token. If the RAA is not configured or
does not wish to handle such requests it MUST respond with 501 (Not
Implemented), HDAs should proceed without validation as if validation
was successful.
If the RAA is configured to validate registration requests, it sends
the data to the "oracle", via a mechanism out of scope for this
document. When the "oracle" marks data as invalid the RAA MUST
signal to the HDA that the registration is to be denied. Otherwise
the RAA returns a Web Token to the HDA containing an X.509
Certificate with the Subject set to the same contents as the
registrant CSR.
4.2.5. Response Model
Wiethuechter Expires 29 January 2026 [Page 19]
Internet-Draft det-tada July 2025
response-content = [
+ [
idx: hash,
entity_type: uint,
certs: {
canonical_cert: x509,
? be_chain: [+ be: endorsement],
* &(tstr , int) => any
}
]
]
Figure 7: Response Model CDDL
The canonical_cert key MUST be the certificate defined in
Section 4.2.5.1. The be_chain contains the Broadcast Endorsement
structures defined in Section 4.1 of [RFC9575] and MAY not be sent by
the DIME if the registrant is not expected to use Broadcast RID.
Additional items MAY be sent back to the registrant by the DIME.
Their keys SHOULD be registered under IANA as part of Section 5.5 to
support global harmonization.
4.2.5.1. Canonical Registration Certificate
Section 4 of [DKI] provides profiles for X.509 certificates adhering
to the [ICAO-ACCP], developed by the Trust Framework Panel. At least
one of the DRIP profiles MUST be used.
At least one certificate in the chain from an apex node to a leaf
node MUST contain a URI, as part of the Subject Alternative Name
Extension [RFC5280], which points to the relevant Private Information
Registry containing associated PII registered. This certificate MUST
be contained in the HHIT RRType defined in Section 5.1 of [DET-DNS].
The certificate MAY be anywhere on the path and SHOULD be as close to
the apex in the path as possible for efficiency.
At the time of publication, the current best practice is for the HDA
Issue certificate to contain the base URI to be used for all Private
Information Registry requests under the HDA. When an HDA supports
multiple Private Information Registry providers, it SHOULD set the
appropriate URI in the end entity certificate. The HDA MAY either
set all different URIs together in its HDA Issue certificate at cost
of the querent being then required to perform queries at each
provided URI until it receives a response or use different Issuer
DETs for each different Private Information Registry provider.
Wiethuechter Expires 29 January 2026 [Page 20]
Internet-Draft det-tada July 2025
When registering a DET to be used as a Session ID, the CSR MUST
contain the UAS Serial Number as the Subject, and the certificate
placed in the private registry also MUST contain the UAS Serial
Number as the Subject, but the certificate placed in the public
registry and used as the basis of the Broadcast Endorsement (or
otherwise exposed publicly) MUST NOT contain the UAS Serial Number.
Author Note: include Section 4 of [DKI] here if merged?
4.3. Query
A DIME has two query interfaces it MUST support. One interface is
used for public information and the other (discoverable from public
information) is for private information.
4.3.1. Public Information Registries
The information found in these registries has been designated
(explicitly or implicitly) as public by cognizant authority and/or
the information owner. Such information includes asymmetric
cryptographic public keys needed for authentication in [RFC9575],
static Broadcast RID data and trustworthy pointers to additional
information.
These registries are Authoritative Name Servers in the DNS. See
[DET-DNS] for operational requirements, query mechanism and response
models.
4.3.2. Private Information Registries
The information found in these registries is considered Personally
Identifiable Information (PII) and/or is stored for potential future
audit of registration. Access to Private Information Registries MUST
be performed using RDAP [STD95]. This section defines RDAP behavior
for DRIP.
4.3.2.1. URI Path Segment
The URIs to Private Information resources MUST use the specification
defined in Section 3.1.3 of [RFC9082]. Use of Section 3.1.1 of
[RFC9082] is OPTIONAL.
Review(SWC): This makes sense if they are starting in DNS, but if
they take a DET, and without going to DNS, go straight to the RDAP
bootstrap servers, 3.1.1 is more direct and straightforward.
Thoughts?
Wiethuechter Expires 29 January 2026 [Page 21]
Internet-Draft det-tada July 2025
Author Note: use of 3.1.1 could shorten the URIs as their content
would be https://hda.example.com/rdap/ip/<ip6-here> instead of
https://hda.example.com/rdap/domain/<reverse-ip6-here>
4.3.2.2. Conformance Literal
The string literal drip_version_0 MUST be used in the rdapConformance
section of the RDAP response to signal conformance with this
specification.
4.3.2.3. Extension Model
Queries of DETs in RDAP SHOULD respond with the appropriate Object
Class as defined in RFC9083 and MUST include the additional data
element specified in Figure 8.
dime = {
csr: x509,
canonical_cert: x509,
hhit: [
entity_type: uint,
ipv6: ip6
],
be_chain: [+ be: endorsement]
registrant: tstr,
? raa_approval: x509,
metadata
}
Figure 8: RDAP Response CDDL
Additional keys SHOULD be registered to IANA under Section 5.5 for
global harmonization. Specification of their usage and syntax in a
NAS is provided by CAAs using a MOC that references this
specification.
4.3.2.4. Differential Access
Per REG-2 and REG-4 of Section 4.4.1 of [RFC9153], RDAP queries to
DRIP Private Information Registries MUST be protected using fine-
grained AAA policies in a both human- & machine-readable form for
automated enforcement. RDAP supports only HTTP based mechanisms for
authentication as defined in Section 3.2 of [RFC7481]. A federated
authentication mechanism, such as the examples in Section 3.2.1 of
[RFC7481], is RECOMMENDED.
For international and/or global harmonization, DRIP standardizes the
following RDAP behavior for authentication of clients and servers:
Wiethuechter Expires 29 January 2026 [Page 22]
Internet-Draft det-tada July 2025
* MUST support HTTP Digest Authentication Scheme ([RFC7616]) *AND*
* SHOULD NOT support HTTP Basic Authentication Scheme ([RFC7617])
but MAY accept Basic if peer offers that and nothing stronger
*AND*
* SHOULD support OpenID Connect for RDAP ([RFC9560]), or Mutual TLS
(Section 7.4.6 of [RFC5246]) or eXtensible Access Control Markup
Language (XACML) with Security Assertion Markup Language (SAML)
for all queries *OR*
* MUST support OpenID Connect for RDAP [RFC9560], or Mutual TLS
Section 7.4.6 of [RFC5246] or XACML with SAML for global and/or
international queries and MAY do any other RDAP compatible AAA for
domestic queries
Author Note: MUST support (one of the options) for international
and/or global queries and for domestic queries SHOULD use the same
but MAY use any other RDAP compatible AAA mechanism instead.
When Mutual TLS is used, it MUST use a certificate as defined from
[DKI]. It SHOULD use the certificate found in the HHIT RRType but
MAY use another certificate found in an associated TLSA RRType.
Author Note: the list of OpenID Connect, Mutual TLS and XACML/SAML
MUST be narrowed to a single choice. Soliciting input on the best
approach to support international and/or global interoperability.
5. IANA Considerations
5.1. RAA Delegation for CAAs
As part of [DET-DNS] IANA already has the pre-allocated mapping of
RAA values for CAAs. Nations are to follow the guidance in
Section 6.2.1.4 of [DET-DNS] to request delegation of their DNS zone
under 3.0.0.1.0.0.2.ip6.arpa..
5.2. Well-Known URIs
IANA is requested to add the following entries in the "Well-Known
URIs" registry [WELL-KNOWN].
Wiethuechter Expires 29 January 2026 [Page 23]
Internet-Draft det-tada July 2025
+===============+============+===========+===========+=============+
| URI Suffix | Change | Reference | Status | Related |
| | Controller | | | Information |
+===============+============+===========+===========+=============+
| register-hhit | IETF | This RFC | permanent | N/A |
+---------------+------------+-----------+-----------+-------------+
Table 1: Additions to Well-Known URIs Registry
5.3. RDAP Extensions Registry
IANA is request to register the following value in the "RDAP
Extensions" registry [RDAP-EXT].
Extension Identifier:
drip_version_0
Registry Operator:
Any
Specification:
This specification
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension is used to convey private information
under an HHIT registration.
5.4. Media Types
IANA is requested to add the following entries in the "Media Types"
registry [MEDIA-TYPES].
+==========+======================+===============+
| Name | Template | Reference |
+==========+======================+===============+
| DRIP CWT | application/drip+cwt | Section 5.4.1 |
+----------+----------------------+---------------+
| DRIP JWT | application/drip+jwt | Section 5.4.2 |
+----------+----------------------+---------------+
Table 2: Additions to Media Types Registry
5.4.1. application/drip+cwt Registration
Type name: application
Subtype name: drip+cwt
Required parameters: N/A
Wiethuechter Expires 29 January 2026 [Page 24]
Internet-Draft det-tada July 2025
Optional parameters: N/A
Encoding considerations: binary
Security considerations: TODO
Interoperability considerations: N/A
Published specification: This RFC
Applications that use this media type: Applications that access
DIMEs requesting HHIT registration, as well as DIMEs responding to
registration requests.
Fragment identifier considerations: N/A
Person & email address to contact for further information: DRIP WG
mailing list (drip@ietf.org)
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IETF
Provisional registration: no
5.4.2. application/drip+jwt Registration
Type name: application
Subtype name: drip+jwt
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary, JWT values are encoded as a series
of base64url-encoded values (with trailing '=' characters
removed), some of which may be the empty string, separated by
period ('.') characters.
Security considerations: TODO
Interoperability considerations: N/A
Published specification: This RFC
Wiethuechter Expires 29 January 2026 [Page 25]
Internet-Draft det-tada July 2025
Applications that use this media type: Applications that access
DIMEs requesting HHIT registration, as well as DIMEs responding to
registration requests.
Fragment identifier considerations: N/A
Person & email address to contact for further information: DRIP WG
mailing list (drip@ietf.org)
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IETF
Provisional registration: no
5.5. DRIP CBOR/JSON Keys
This specification establishes a new sub-registry called "DRIP CBOR/
JSON Keys" within the "Drone Remote ID Protocol" registry. This
registry is to maintain a globally harmonized list of JSON keys (i.e.
"Names") and CBOR map integer keys (i.e. "Labels") for use in DRIP.
The following ranges are defined based on the CBOR Label values:
+========+=======================+==========+=====================+
| Range | Registration Policy | Range | Comments |
| | | Use | |
+========+=======================+==========+=====================+
| from | Private Use | HID | Private use for |
| -2^64 | (Section 4.1 of | Private | RAAs and HDAs |
| to -25 | [RFC8126]) | Keys | |
+--------+-----------------------+----------+---------------------+
| from | TODO: TBD | ASTM UAS | Keys found in ASTM |
| -24 to | | Keys | UAS Standards such |
| 23 | | | as [F3411] |
+--------+-----------------------+----------+---------------------+
| from | Specification | Reserved | Reserved for future |
| 24 to | Required (Section 4.6 | | registrations to |
| 2^64-1 | of [RFC8126]) | | maintain global |
| | | | harmonization |
+--------+-----------------------+----------+---------------------+
Table 3: DRIP CBOR/JSON Key Registry Policies
Keys in the Private Use and Experimental ranges are RECOMMENDED to
prepend a _ to the Name to avoid namespace collisions with registered
Names.
Wiethuechter Expires 29 January 2026 [Page 26]
Internet-Draft det-tada July 2025
The HID Private Keys range in this registry provide code-points (used
in Section 4.2.4 and Section 4.3.2.3 as part of metadata) for each
RAA and HDA to define their own subset of elements in both
registration and RDAP responses. The spec value of this registry
SHOULD be used to enable the DIME or client to provide a "hint" for
the data elements included. Specification of the spec string
semantics are left to individual RAAs and HDAs to define as they see
fit. RAA and HDA Operators SHOULD provide specification for any
Private Use or Experimental Use values, but this may not be public
due to policy.
5.5.1. Review Criteria
For registrations, review should note if the Name field matches an
existing entry, the request should be denied. A request should also
be denied if the specification duplicates an existing entry both in
syntax and semantics. For example, if an existing key called whee
already exists with the specification of [+ uint] and a new request
comes along to register whee_but_mine with specification [+ uint],
then the latter should be rejected on the grounds of being able to
use whee instead. This denial can be overruled if shown that the new
registration has clear justification, as part of the specification
citing technical reasoning, to exist.
5.5.2. CBOR/JSON Key Fields
Name (JSON Key Value): A string value, to be used as a key in the
key: value pair of a JSON object. No specific rules apply for
syntax beyond being a valid JSON string for a object key, but it
is recommended to use all lower-case and snake-case with
underscores. Care should be given to the length of a Name to
reduce wire size of JSON encodings for constrained environments.
Label (CBOR Integer Key Value): A integer value, ranging from -2^64
to 2^64 - 1, to be used as a key in a CBOR map. Different ranges
of values use different registration policies, see Table 3.
Description: A short description of the entry providing an overview
of its semantic meaning and its expected use-cases.
Reference: A link to a permanent and readily available specification
defining the value syntax and semantics to be used for this key.
5.5.3. Registration Form
Wiethuechter Expires 29 January 2026 [Page 27]
Internet-Draft det-tada July 2025
Name (JSON Key Value):
Label (CBOR Integer Key Value):
Description:
Specification:
Figure 9
5.5.4. Initial Values
+===================+=============+=================+===========+
| Name (JSON Key | Label (CBOR | Description | Reference |
| Value) | Integer Key | | |
| | Value) | | |
+===================+=============+=================+===========+
| uas_type | 0 | Enumeration of | This RFC, |
| | | UAS Type | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| uas_ids | 1 | UAS IDs | This RFC, |
| | | | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| auth | 2 | Authentication | This RFC, |
| | | Data | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| self_id | 3 | Self ID | This RFC, |
| | | | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| classification | 4 | UA Category & | This RFC, |
| | | Class | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| area | 5 | Area Count, | This RFC, |
| | | Radius, etc. | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| operator_id | 6 | Operator ID | This RFC, |
| | | | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| ua_status | 7 | Enumeration of | This RFC, |
| | | Status | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| ua_position | 8 | UA Position | This RFC, |
| | | | Section |
Wiethuechter Expires 29 January 2026 [Page 28]
Internet-Draft det-tada July 2025
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| ua_bearing | 9 | Bearing / Track | This RFC, |
| | | Direction | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| ua_speed | 10 | Vertical & | This RFC, |
| | | Horizontal | Section |
| | | Speeds | 4.1 |
+-------------------+-------------+-----------------+-----------+
| ua_height | 11 | Height Above | This RFC, |
| | | Ground or Take- | Section |
| | | off | 4.1 |
+-------------------+-------------+-----------------+-----------+
| accuracy | 12 | Enumerations of | This RFC, |
| | | Accuracies | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| operator_position | 13 | Operator | This RFC, |
| | | Position | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| timestamp | 14 | UTC Timestamp | This RFC, |
| | | | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| compliance | 15 | Compliance | This RFC, |
| | | Enumeration | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| raa | 23 | RAA | This RFC |
+-------------------+-------------+-----------------+-----------+
| hda | 24 | HDA | This RFC |
+-------------------+-------------+-----------------+-----------+
| csr | 25 | DER Encoded | This RFC |
| | | X.509 CSR | |
+-------------------+-------------+-----------------+-----------+
| uas | 26 | UAS Datum Map | This RFC, |
| | | | Section |
| | | | 4.1 |
+-------------------+-------------+-----------------+-----------+
| utm | 27 | UTM Operational | This RFC |
| | | Intent & Source | |
+-------------------+-------------+-----------------+-----------+
| spec | 28 | CAA | This RFC |
| | | Specification | |
| | | Code | |
+-------------------+-------------+-----------------+-----------+
Wiethuechter Expires 29 January 2026 [Page 29]
Internet-Draft det-tada July 2025
| canonical_cert | 39 | DER Encoded | This RFC |
| | | X.509 | |
| | | Certificate | |
+-------------------+-------------+-----------------+-----------+
| be_chain | 30 | List of | This RFC |
| | | Broadcast | |
| | | Endorsements | |
+-------------------+-------------+-----------------+-----------+
| registrant | 31 | Registrant | This RFC |
| | | Information | |
+-------------------+-------------+-----------------+-----------+
| hhit | 32 | Hierarchial | This RFC |
| | | Host Identity | |
| | | Tag | |
+-------------------+-------------+-----------------+-----------+
| oracle_x509 | 33 | Oracle X.509 | This RFC |
| | | Certificate | |
+-------------------+-------------+-----------------+-----------+
| uas_serial_number | 34 | ANSI/CTA 2063-A | This RFC |
| | | UAS Serial | |
| | | Number | |
+-------------------+-------------+-----------------+-----------+
| caa_assigned_id | 35 | CAA Assigned ID | This RFC |
+-------------------+-------------+-----------------+-----------+
| pilot_license_id | 36 | Pilot License | This RFC |
| | | Number | |
+-------------------+-------------+-----------------+-----------+
Table 4: Pre-Allocated DRIP CBOR/JSON Keys
6. Security Considerations
The considerations discussed in [RFC9153], [RFC9374], [RFC9434],
[RFC9575] and [DET-DNS] apply.
DIMEs use and provide various methods to protect data through:
Attestation, Authentication, Authorization, Access Control,
Attribution, Accounting, and Audit (AAA). All data, handled under
DRIP, MUST be protected by AAA, as per applicable regulation and
policy (which, in some cases, for public data, may impose minimal
requirements). All private data MUST also be protected by strong
encryption where permitted by applicable law etc. These requirements
apply to data at rest and in transit in all phases of the process,
i.e. registration and query.
Wiethuechter Expires 29 January 2026 [Page 30]
Internet-Draft det-tada July 2025
Attestation may be mandated by CAAs for devices (such as UA). Remote
ATtestation ProcedureS (RATS) [RFC9334] is recommended for DRIP. The
specific attestation mechanisms in a given jurisdiction are out of
scope for this document.
Author Note: RGM, what else should go here?
6.1. Cryptographic Materials
Best practices dictate that cryptographic materials that should only
be available to selected parties SHOULD be generated by one or more
of those parties and stored accessibly only on those parties devices.
E.g. the asymmetric key-pair from which a DET will be derived SHOULD
be generated by the entity identified by that DET and the
corresponding private key should be stored only on that entity's
device. There may be scenarios where other parts of the UAS MAY
generate the cryptographic materials and provision them as needed
during an operation. Any such system MUST ensure security of the
cryptographic material is guaranteed.
7. Privacy & Transparency Considerations
The considerations discussed in [RFC9153] and Section 10 of [RFC9434]
apply.
Author Note: do we copy/paste Section 10 of [RFC9434] and update
here or is below sufficient?
7.1. DETs as Session ID and Authentication Key ID
The properties of a DET allow it to be used as a Session ID and/or an
Authentication Key ID. There may be scenarios in which Session IDs
are desired for privacy but Authentication is not; although this may
reduce transparency and security, a DET MAY be used exclusively as a
Session ID in such. There are scenarios in which Authentication is
desired but Session IDs are not (e.g. where a CAA does not allow
Session IDs); a DET MAY be used exclusively as an Authentication Key
ID in such. In the scenario expected to be most common, both Session
IDs and Authentication are desired; the same DET SHOULD be used as
both the Session ID and Authentication Key ID in such. Consequences
and operational impact of using different DETs for the Session ID and
Authentication Key ID of the same entity are unknown and not covered
in this document.
7.2. Selective Encryption
Author Note: renamed section and/or add more explicit disclaimer?
Wiethuechter Expires 29 January 2026 [Page 31]
Internet-Draft det-tada July 2025
Selective encryption may be allowed in some circumstances. An HHIT
may be used in a private lookup to access decryption key material or
obtain decryption as a service.
Selective encryption of UAS RID using DRIP is only allowed when the
DET to be used as the Session ID is issued by an HDA associated with
a USS and that DET is associated with the corresponding Operational
Intent in UTM. This enables the encryption of selected data elements
in Broadcast RID to provide a layer of privacy for operators (e.g.
their position) without compromising transparency to entities (e.g.
public safety / law enforcement personnel) that need to know.
Selective encryption typically requires network connectivity of the
Observer to perform the private query to obtain the decryption
service or key material. CAAs should consider the expected Observer
environment and prohibit encryption wherever and whenever Observers
cannot reasonably be expected to have connectivity. For example
selective encryption, per CAA regulations, MAY be allowed in dense
wireless IP connectivity areas (e.g. urban) but prohibited in poor
wirelessly covered areas (e.g. rural).
The issue of Observer network connectivity MAY be mitigated with the
use of a shared decryption key used by multiple Session IDs under a
given USS/HDA over a period of time, that is preloaded onto the
Observer device before connectivity is lost. For example Observers
MAY query USS/HDAs for flight volumes in which they are interested to
preload their decryption key(s) for the Operational Intents/Session
IDs that day.
8. References
8.1. Normative References
[DET-DNS] Wiethuechter, A. and J. Reid, "DRIP Entity Tags in the
Domain Name System", Work in Progress, Internet-Draft,
draft-ietf-drip-registries-31, 27 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
registries-31>.
[DKI] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-drip-dki-08, 22 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
dki-08>.
Wiethuechter Expires 29 January 2026 [Page 32]
Internet-Draft det-tada July 2025
[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc9434>.
[RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag (DET) Authentication Formats and Protocols for
Broadcast Remote Identification (RID)", RFC 9575,
DOI 10.17487/RFC9575, June 2024,
<https://www.rfc-editor.org/rfc/rfc9575>.
[STD95] Internet Standard 95,
<https://www.rfc-editor.org/info/std95>.
At the time of writing, this STD comprises the following:
Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
Wiethuechter Expires 29 January 2026 [Page 33]
Internet-Draft det-tada July 2025
Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
8.2. Informative References
[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>.
[F3548] ASTM International, "Standard Specification for UAS
Traffic Management (UTM) UAS Service Supplier (USS)
Interoperability", ASTM F3548-21, DOI 10.1520/F3548-21,
July 2025, <https://www.astm.org/f3548-21.html>.
[F3586] ASTM International, "Standard Practice for Remote ID Means
of Compliance to Federal Aviation Administration
Regulation 14 CFR Part 89", ASTM F3586-22,
DOI 10.1520/F3586-22, July 2022,
<https://www.astm.org/f3411-22a.html>.
[ICAO-ACCP]
International Civil Aviation Organization, "ICAO Aviation
Common Certificate Policy", July 2025.
[ICAO-NUMBERS]
International Civil Aviation Organization, "ICAO Remote ID
Number Registry", July 2025,
<https://www.icao.int/airnavigation/IATF/Pages/ASTM-
Remote-ID.aspx>.
[MEDIA-TYPES]
IANA, "Media Types", July 2025,
<https://www.iana.org/assignments/media-types/>.
[RDAP-EXT] IANA, "RDAP Extensions", July 2025,
<https://www.iana.org/assignments/rdap-extensions/>.
Wiethuechter Expires 29 January 2026 [Page 34]
Internet-Draft det-tada July 2025
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<https://www.rfc-editor.org/rfc/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/rfc/rfc7617>.
[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/rfc/rfc8126>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
Wiethuechter Expires 29 January 2026 [Page 35]
Internet-Draft det-tada July 2025
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
<https://www.rfc-editor.org/rfc/rfc9063>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9560] Hollenbeck, S., "Federated Authentication for the
Registration Data Access Protocol (RDAP) Using OpenID
Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
<https://www.rfc-editor.org/rfc/rfc9560>.
[STD90] Internet Standard 90,
<https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[WELL-KNOWN]
IANA, "Well-Known URIs", July 2025,
<https://www.iana.org/assignments/well-known-uris/>.
Appendix A. HID Abbreviation
The DET MAY be abbreviated. This is useful for display applications
with limited screen real-estate as the display of the entire 128-bit
(32 characters in hexadecimal, even without recommended punctuation
or spacing) IPv6 address can be costly. Abbreviations SHOULD follow
the following format rules.
Wiethuechter Expires 29 January 2026 [Page 36]
Internet-Draft det-tada July 2025
Hierarchy Level: Each hierarchy level (RAA/HDA) is represented by a
maximum of six alphanumeric characters. This abbreviation SHOULD
NOT be a single character in length, for obvious reasons of not
being very useful. The decimal representation does fit into the 4
character restriction but is NOT RECOMMENDED. The RECOMMENDED
abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
code for nations. This abbreviation MAY be found in DNS under a
HHIT RRType of the entity or its parents. If there is no
abbreviation hint display devices SHOULD use a fixed size four
character hexadecimal representation of the value. It is
RECOMMENDED that display applications specify a default RAA value,
and only display the RAA abbreviation explicitly when it does not
match the default.
Entity Hash: The entity is represented by a fixed size four
character hexadecimal string using the last four characters of the
DET. If a collision (within the same HID space) on display
occurs, the four characters SHOULD shift to the left by one
hexadecimal character until the collision is resolved. This
window MUST stay within the last sixteen hexadecimal characters of
the DET. The : character found in an IPv6 address string is
ignored.
Review(SWC): Do we need to insert a flag character such as "*" to
indicate when a hash has been shifted? If the abbreviation is
used only to avoid conflicts, no; but if anyone actually knows
some DETs in their operation, if they get shifted, they probably
won't recognize them.
Delimiter: Each section is delimited by a single character. This
can be any whitespace character (except newline and tab) or any
non-alphanumeric character (period, comma, semicolon, etc.). It
is RECOMMENDED that the delimiter is consistent between
components. The RECOMMENDED delimiter is the colon (:) character.
For example a DET with the values of RAA 16383 and HDA 1 without any
abbreviation hint from DNS is represented by the string 3FFF 0001
xxxx with xxxx representing a entity hash. If an abbreviation for
the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
the DET can be represented with the string of DRIP01 TEST xxxx.
For an example of the entity hash, let's assume there are two DETs
with the following hashes in the same HID: 0000:1111:2222:3333 and
0000:2222:1111:3333. At first both DETs are represented with the
same abbreviation: RAA HDA 3333. One of these DETs is selected by
the display application to shift the display hash one character to
avoid the collision resulting in the following two abbreviations: RAA
HDA 3333 and RAA HDA 1333.
Wiethuechter Expires 29 January 2026 [Page 37]
Internet-Draft det-tada July 2025
Appendix B. Compliance Submission Forms
Author Note: talk with AS on this section
Appendix C. CSR Examples
-----BEGIN CERTIFICATE REQUEST-----
MIGaME4CAQAwGzEZMBcGA1UEBRMQMTY0OEJHRU4zVE1SMDAwMDAqMAUGAytlcAMh
AEV/gIxyi4tbRobDCu0zleb9gmQD4teLQt5FfkCey/XxoAAwBQYDK2VwA0EA3vxm
sCGt+qK39V9cfit4UptfqTd+wct7dxOgdmlYL+dTmC4HU1UaM21l0YnDP9CzoH93
4c2wzRrlB/J5BW35DQ==
-----END CERTIFICATE REQUEST-----
Certificate Request:
Data:
Version: 1 (0x0)
Subject: serialNumber = 1648BGEN3TMR0000
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
45:7f:80:8c:72:8b:8b:5b:46:86:c3:0a:ed:33:95:
e6:fd:82:64:03:e2:d7:8b:42:de:45:7e:40:9e:cb:
f5:f1
Attributes:
a0:00
Signature Algorithm: ED25519
de:fc:66:b0:21:ad:fa:a2:b7:f5:5f:5c:7e:2b:78:52:9b:5f:
a9:37:7e:c1:cb:7b:77:13:a0:76:69:58:2f:e7:53:98:2e:07:
53:55:1a:33:6d:65:d1:89:c3:3f:d0:b3:a0:7f:77:e1:cd:b0:
cd:1a:e5:07:f2:79:05:6d:f9:0d
Figure 10: Broadcast RID Session CSR without subjectAltName
Wiethuechter Expires 29 January 2026 [Page 38]
Internet-Draft det-tada July 2025
-----BEGIN CERTIFICATE REQUEST-----
MIHLMH8CAQAwGzEZMBcGA1UEBRMQMTY0OEJHRU4zVE1SMDAwMDAqMAUGAytlcAMh
AEV/gIxyi4tbRobDCu0zleb9gmQD4teLQt5FfkCey/XxoDEwLwYJKoZIhvcNAQkO
MSIwIDAeBgNVHREBAf8EFDAShxAgAQA//gABBS9EvMRvcVpCMAUGAytlcANBAD1O
ZBD16dCvhryQ1qIh5oh60ellac0gymi0dXt9QNZFrAEh3GoJrbpQKNcHc3SArCzJ
AgtxkmVaUz7wJ78LXgc=
-----END CERTIFICATE REQUEST-----
Certificate Request:
Data:
Version: 1 (0x0)
Subject: serialNumber = 1648BGEN3TMR0000
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
45:7f:80:8c:72:8b:8b:5b:46:86:c3:0a:ed:33:95:
e6:fd:82:64:03:e2:d7:8b:42:de:45:7e:40:9e:cb:
f5:f1
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:105:2F44:BCC4:6F71:5A42
Signature Algorithm: ED25519
3d:4e:64:10:f5:e9:d0:af:86:bc:90:d6:a2:21:e6:88:7a:d1:
e9:65:69:cd:20:ca:68:b4:75:7b:7d:40:d6:45:ac:01:21:dc:
6a:09:ad:ba:50:28:d7:07:73:74:80:ac:2c:c9:02:0b:71:92:
65:5a:53:3e:f0:27:bf:0b:5e:07
Figure 11: Broadcast RID Session CSR with subjectAltName
Appendix D. Compliance Testing
It is the responsibility of each parent node in the tree that a child
node pass functional interoperability testing prior to issuing a
certificate for the child node.
Author: This section is a work in progress.
All interfaces MUST be tested on valid and invalid data (such as
being malformed). When policy is required on an interface all
essential permutations of the policy MUST be tested and all possible
permutations SHOULD be tested. The policy engine MUST be invoked to
validate proper decisions (including PERMIT and DENY or their
equivalents) and actions are being made. All data returned from an
interface MUST be tested to check that it conforms with
specifications.
Wiethuechter Expires 29 January 2026 [Page 39]
Internet-Draft det-tada July 2025
There is a range in the RAA space allocated for experimentation and
testing purposes. Sub-ranges can be delegated to parties, for a
limited period of time, at the behest of the RAA Designated Expert,
to test DIME interoperability (e.g. HDA to RAA, and RAA to RAA
interactions) in any of the below subsections. The IANA
Considerations section of [DET-DNS] contains more information on how
these delegations are to be handled.
Appendix B provides a set of forms to be filled out and submitted as
part of a CAA compliance process for using DRIP.
+-----+ +-----+
| | | |
| o----(1)--->o |
| X | | Y |
| o<---(2)----o |
| | | |
+-----+ +-----+
Figure 12: System Interface Test Diagram
D.1. Registration Interface
X, Y pairs: (registrant, HDA), (HDA, RAA)
1: Ensure that endpoints on Y can be accessed according to Y's policy
by X. Ensure that the endpoints conform to the normative
requirements of Test that Y interface properly handles valid and
malformed data. Test that Y securely generates proper artifacts and
stores them.
2: Ensure that the interactions for (1) properly returns data to X
from Y. This data MUST include the Broadcast Endorsements, X.509s
and any other data elements required.
D.2. Public Query Interface
X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
(RAA, HDA), (HDA, HDA'), (RAA, RAA')
1: Ensure that Y has a properly configured and publicly accessible
Authoritative Name Server for its delegated ip6.arpa domain.
2: Ensure that Y returns the valid RRTypes defined in [DET-DNS] to X
based on an ip6.arpa query via standard DNS methods (i.e. using UDP
on port 53). Ensure that the HHIT RRType contains the correct
Certificate with an URI.
Wiethuechter Expires 29 January 2026 [Page 40]
Internet-Draft det-tada July 2025
D.3. Private Query Interface
X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
(RAA, HDA), (HDA, HDA'), (RAA, RAA')
1: Ensure that the provide URI from the public query interface points
to a valid URI. Ensure that the endpoint on Y has proper AAA
mechanisms as defined in this document and enforces the proper policy
options.
2: Ensure that the Y endpoint securely returns the data expected
according to policy (matrix of authorized, valid request,
unauthorized and invalid request) to X.
Author's Address
Adam Wiethuechter
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Wiethuechter Expires 29 January 2026 [Page 41]