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 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/ instead of https://hda.example.com/rdap/domain/ 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 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, . [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, . 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . [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, . [STD95] Internet Standard 95, . 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, . Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, . 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, . Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, . 8.2. Informative References [F3411] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July 2022, . [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, . [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, . [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, . [MEDIA-TYPES] IANA, "Media Types", July 2025, . [RDAP-EXT] IANA, "RDAP Extensions", July 2025, . 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, . [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, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [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, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [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, . 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, . [RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, . [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, . [RFC9560] Hollenbeck, S., "Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024, . [STD90] Internet Standard 90, . 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, . [STD94] Internet Standard 94, . 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, . [WELL-KNOWN] IANA, "Well-Known URIs", July 2025, . 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]