Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness

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 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:¶

1. 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.¶

2. An entity that participates in DRIP interactions (even if not needing a Session ID), MUST use a DET for the DRIP public authentication key ID in those interactions.¶

3. An entity that requires a strongly cryptographically verifiable IP compatible identifier, MAY use a DET for any other legal purpose.¶

4. 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].¶

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.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.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 B.¶

• 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.¶

  • 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.¶

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 Specific Session ID, Specific Session ID Type to DRIP Entity ID, and encode the 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:¶

• 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.¶

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

The Apex role is the administration root and the domain apex for a specific IPv6 prefix which are typically associated with an industry sector (i.e. DETs being for aviation). This translates to the technical tasking of delegating RAA values and maintaining the reverse DNS zone associated with the allocated IPv6 prefix which contain the DNS delegations to RAAs. An Apex in its capacity as the administration root MAY endorse the required RAA delegation in the hierarchy.¶

Currently IANA performs the functions of RAA delegation (with no endorsement) and DNS zone maintenance for the DET prefix. This is largely a custodial task as critical portions of the RAA range, with regards to aviation, are already reserved or allocated with the rest of the range unassigned.¶

In the context of aviation pre-allocated RAAs to CAAs are currently expected to mutually cross-certify as specified in [ICAO-ACCP].¶

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, which only contained static data, 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,
    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]
}

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.¶

            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----|

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 ]

HTTP/1.1 200 OK
Accept: application/drip+cwt, application/drip+jwt
Content-Type: application/drip+cwt

[ CWT from DIME ]

registration-content = {
  csr_list: [
    + csr: [
      idx: hash,
      entity_type: uint,
      csr: x509,
      vnb: utc / null,
      vna: utc / 1..15638400 / null,
      meta: { metadata }
    ]
  ],
  metadata
}

response-content = [
  + [
    idx: hash,
    entity_type: uint,
    certs: {
      canonical_cert: x509,
      ? be_chain: [+ be: endorsement],
      * &(tstr , int) => any
    }
  ]
]

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.¶

dime = {
  csr: x509,
  canonical_cert: x509,
  hhit: [
    entity_type: uint,
    ipv6: ip6
  ],
  be_chain: [+ be: endorsement]
  registrant: tstr,
  ? raa_approval: x509,
  metadata
}

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].¶

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].¶

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:¶

Keys in the Private Use and Experimental ranges are RECOMMENDED to prepend a _ to the Name to avoid namespace collisions with registered Names.¶

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.¶

Requested Range:
Name (JSON Key Value):
Description:
Specification:

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.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?¶

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.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-33, 19 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-drip-registries-33>.

[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>.

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/>.

[RFC4108]

Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, <https://www.rfc-editor.org/rfc/rfc4108>.

[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>.

[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/>.

[_802.1AR]

IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", DOI 10.1109/ieeestd.2018.8423794, July 2025, <https://doi.org/10.1109/ieeestd.2018.8423794>.

C.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.¶

C.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.¶

C.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.¶

C.4. Compliance Submission Forms

Author Note: talk with AS on this section¶

D.1. Signing Request

The Certificate Signing Request (CSR) is a mandatory for all DET registrations. Depending on the entity being registered, there is specific content rules.¶

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:
    Signature Algorithm: ED25519

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. The value of this field for other entity types are subject to policy and are out of scope for this document.¶

Subject Alternative Name:

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.¶

The use of other Extension fields are out of scope for this document.¶

D.2. Lite Profile

DKIX-Lite is designed to fully mirror the DKI in the smallest reasonable X.509 certificates (e.g. 240 bytes for DER), but still adhere to [RFC5280] MUST field usage. The profile can be found in Figure 10 and a field matrix found in Table 5.¶

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: ED25519
        Issuer: CN =
        Validity
            Not Before:
            Not After :
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:
    Signature Algorithm: ED25519
    Signature Value:

D.3. Full Profile

The X.509 certificates are minimalistic (less than 400 bytes for DER). Any DRIP specific OIDs should come from the ICAO arc (see Appendix D.4.8). The profile can be found in Figure 11 and a field matrix found in Table 6.¶

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: ED25519
        Issuer: CN =
        Validity
            Not Before:
            Not After :
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                IP Address:
                URI:
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:
            X509v3 Basic Constraints: critical
            X509v3 Key Usage: critical
    Signature Algorithm: ED25519
    Signature Value:

D.4. Certificate Fields

The following sections contain clarifications on the usage of fields in the DKIX when they deviate from "standard" X.509 [RFC5280] practice or have specific functions in the context of DRIP.¶

DRIP-{APEX|RAA|HDA}-{A|I}[-RAA#][-HDA#]