DRIP Entity Tag (DET) Identity Management Architecture
Internet-Draft draft-ietf-drip-registries-17
Adam Wiethuechter, Ed.
AX Enterprize, LLC
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
UK
jim@rfc1035.com
28 June 2024
Internet
drip Working Group
Internet-Draft
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and related metadata is performed via DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is provided in this document with future supporting documents to provide technical specifications.
Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote Identification (RID). Only very limited operational information can be sent via Broadcast RID, but extended information is sometimes needed. The most essential element of information is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]).
Such extended information is retrieved from the UAS ID via the use of a DRIP Entity Tag (DET) [RFC9374] which is managed by the DRIP Identity Management Entity (DIME). In this document we assume the DIME is a function of UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be independent or handled by another entity as well.
Registration is necessary to guarantee the uniqueness of the DET and thus to ensure the extended information is bound to the UAS ID and that the required public/private information has been submitted, approved and recorded.
While most data to be sent via Broadcast RID (Section 1.2.1 of [RFC9434]) or Network RID (Section 1.2.2 of [RFC9434]) is public, much of the extended information will be private. As discussed in Section 7 of [RFC9434], Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, and Audit (typically known as AAA) is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose. As specific AAA requirements will vary by jurisdictional regulation, provider choices, customer demand, etc., they are left to specification in policies which are out of scope for this document.
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Clients in the architecture that can use a DET include Unmanned Aircraft (UA), Ground Control Station (GCS), Hierarchical HIT Domain Authority (HDA), Registered Assigning Authority (RAA) and USS.
This document uses the Concise Data Definition Language (CDDL) [RFC8610] for describing the registration data and other structures.
General Concept
DETs MUST be registered within the hierarchy to perform lookups and also obtain the trust inherited from being a member of the hierarchy. DIME's are the points in the hierarchy that enforce requirements on registration and information access. This document standardizes the basic interactions and methods for registration and lookup to support interoperability of DETs. Other identifiers and their methods are out of scope for this document.
Authoritative Name Servers of the Domain Name System (DNS) provide the Public Information resource for both storing and retrieving public information, such as the public key of DETs and pointers to Private Information resources. Personally Identifiable Information (PII) is stored in Private Information Registries and is protected through AAA mechanisms not described in this document.
Use of Existing DNS Models
Registration of DETs SHOULD follow the registrant-registrar-registry model commonly used for registration of domain names. In DRIP, the registrant would be the end user who owns/controls the Unmanned Aircraft. They are ultimately responsible for the DET and any other information that gets published in the DNS. Registrants use agents known as registrars to manage their interactions with the registry. Registrars typically provide optional additional services such as DNS hosting, web/mail hosting, X.509 certificates and so on. The registry maintains a database of the registered domain names and their related metadata such as the contact details for domain name holder and the relevant registrar. The registry provides DNS service for the zone apex - 3.0.0.1.0.0.2.ip6.arpa for DRIP - which contains delegation information for the domain names of the registered DETs Registries generally provide services such as WHOIS or RDAP to publish metadata about the registered domain names and their registrants and registrars.
Registrants have contracts with registrars who in turn have contracts with registries. Payments follow this model too: the registrant buys services from a registrar who pays for services provided by the registry.
By definition, there can only be one registry for a domain name. Since that registry is a de facto monopoly, the scope of its activities are usually kept to a minimum to reduce the potential for market distortions or anti-competitive practices. A registry can have an arbitrary number of registrars who compete with each other on price, service and customer support.
It is not necessary, and in some case may not be desirable, for DRIP registrations to strictly follow this registrant-registrar-registry model. Prevailing circumstances and/or local policy may mean some combination of these roles could be combined. A DRIP registry might be operated by the CAA. Or it could be outsourced to a DNS registry provider. Registration policies - pricing, renewals, registrar and registrant agreements, etc. - will need to be developed. These considerations SHOULD be determined by the CAA, perhaps in consultation with local stakeholders. They are are out of scope for this document.
Figure 1 is intended to show this mapping of DRIP Information Registry functions and existing DNS concepts. This figure is not meant to be exhaustive or explain how the DNS functions. It only show where DRIP overlays with the DNS.
DNS & DRIP Terminology/Role Mapping

+--------------------------+
| DNS: Registrant          |
+--------------------------+
| DRIP: UAS Operators & UA |
+-------o------------------+
        |
        | Domain/DET
        | Registration Request
        |
+-------o-----------------------------+
| DNS: Registrar                      |
+-------------------------------------+
| DRIP: DIME Provisioning Agent (DPA) |
+-------o-----------------------------+
        |
        | Updates to
        | Registry Database (e.g. EPP)
        |
+-------o----------------------------+
| DNS: Registry Operator             |
+------------------------------------+
| DRIP: DIME Information Agent (DIA) |
+-------o-------------------------o--+
        |                         |
        | Zone File               | Domain
        | Update(s)               | Metadata
        |                         |
+-------o---------------+    +----o------------------+
| DNS: Authoritative    |    | DNS/DRIP: Private     |
|      Name Server (NS) |    |           Information |
+-----------------------+    |           Registry    |
| DRIP: Public          |    +--o--------------------+
|       Information     |       |
|       Registry        |       | Registrant
+--------------------o--+       | Information Service
                     |          | (e.g. WHOIS, RDAP, etc.)
                     | DNS      |
                     |          |
                  +--o----------o--+
                  | DNS: Resolver  |
                  +----------------+
                  | DRIP: Observer |
                  +----------------+

UAS DIME Services
For UAS, a DIME can provide the following registration and lookup services:
1. personal information (e.g. for pilots and operators)
2. UAS Serial Number and aircraft physical characteristics
3. a Key ID for UAS RID Authentication (for example [RFC9575])
4. a pseudo-anonymous UAS Specific Session ID (for example [RFC9374])
5. binding of UAS ID to UTM Operational Intent
A DIME's services are determined by their intended role (Section 4) and policies (both internally and from appropriate authorities). For example, services 1 and 2 can be restricted to non-public access controlled lookups with mandatory registration and 5 to publicly available but access controlled lookups.
For this document only services 3 and 4, when their identifier is selected as the DET, are detailed. Services 1 and 5 will be talked about conceptually while service 2 is out of scope.
Requirements on the elements of information in registration and lookup (beyond the scope of basic interoperability) is out of scope for this document. It is left to appropriate authorities to determine these details along with policy for access. For the UAS use-case this would be the national Civil Aviation Authorities (CAAs).
Terminology
Required 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.
Additional Definitions
This document makes use of the terms (PII, USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374].
Text Conventions
When talking about a DIME in documents it should be referred to as the role it is serving. For example a CAA level DIME running services both as an RAA (its primary role in the hierarchy) and as an HDA (optionally) would be be referred to "RAA" when performing its RAA duties and "HDA" when performing its HDA duties. The rest of the document will follow this convention unless verbosity or clarity is needed.
- Review(MGLT): do we need this section above?
DIME Roles
[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and further specifies an instance of them used for UAS RID called DETs. The HHIT is a 128-bit value that is as an IPv6 address intended primarily as an identifier rather than locator.
As a review, HHITs are comprised of four major components: a Prefix, a Hierarchy ID (HID), a HHIT Suite ID (fixed 8-bits) and an ORCHID Hash. DETs use a 28-bit prefix (2001:30::/28 assigned by [RFC9374]) and 64-bit hash leaving 28-bits for the HID. For UAS RID this HID is further divided into two fields: RAA and HDA, each 14-bits in length. Figure 2 shows this breakdown.
DRIP Entity Tag Breakdown

+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28-bits)   | (28-bits)    | (8-bits)      | (64-bits)   |
+-------------+--------------+---------------+-------------+
             /                \
            /                  \
           /                    \-----------------------------\
          /                                                    \
         /                                                      \
        +--------------------------------+-----------------------+
        | Registered Assigning Authority | HHIT Domain Authority |
        | (14-bits)                      | (14-bits)             |
        +--------------------------------+-----------------------+

[RFC9434] defines the DRIP Identity Management Entity (DIME) as an entity that vets Claims and/or Evidence from a registrant and delivers, to successful registrations, Endorsements and/or Certificates in response. The DIME encompasses various logical components (Section 5) and can be classified to serve a number of different roles, mapped to levels in the hierarchy, which are detailed in the following subsections.
Apex
The Apex is the IPv6 prefix portion of the DET associated with it which is assigned by IANA from the special IPv6 address space for ORCHIDs. It serves as the branch point from the larger DNS system in which DETs are defined. The Apex manages all delegations and allocations of RAAs to various parties. The Apex MUST reserve an allocation for itself that it MAY use.
DRIP Apex for UAS RID
For UAS RID the Apex uses IPv6 prefix of 2001:30::/28 per [RFC9374]. This corresponds to the domain name 3.0.0.1.0.0.2.ip6.arpa in the DNS and is the Apex for DRIP delegations. Allocations of RAAs in this prefix SHOULD be done in contiguous groups of 4. This is to support the nibble reversing of the DET to be placed in DNS (Section 8.1). See Section 11.1 for the RAA allocations.
RAA values 0 (0x0000) through 3 (0x0003) MUST be reserved for the UAS RID Apex and SHOULD be used to endorse RAA delegations in Endorsements (Section 9). While the individual Apexes can be designated for different purposes they share the same pool of RAAs to be allocated. Such operation would require policy by the administrator of the Apex to avoid simultaneous conflicting allocation and is out of scope for this document.
Registered Assigning Authority (RAA)
An RAA is a government agency, business or other organization that runs a DIME to register HDAs (Section 4.3).For UAS RID and related aviation uses most are expected to be CAAs (using Section 4.2.1), such as the Federal Aviation Authority (FAA), that then delegate HDAs for use in their National Air Space (NAS).
An RAA:
- MUST provide a set of services to allocate HDAs to organizations
- MUST have a public policy on what is necessary to obtain an HDA
- SHOULD provide service level guarantees for DNS operation and registry service
- SHOULD maintain a DNS zone minimally for discovering HIP Rendezvous (RVS) servers
- Review(MGTL): The normative language should not be about what function the RAA MUST accomplish. Instead we should mention what architecture mechanisms/protocols must be implemented so the RAA can perform the action it requires. The only item that fits this requirement is the HIP RVS.
Each RAA MUST use the single reserved HDA value 0 (0x0000) for itself to support various functions or services. Other HDA values SHOULD be allocated or reserved per RAA policy.
ISO 3166-1 Numeric Nations (INN)
The RAA range of 4 (0x0004) to 3999 (0x0F9F) are reserved for CAAs using the ISO 3166-1 Numeric Nation Code. The RAA can be derived from the ISO 3166-1 numeric code by multiplying the value by 4 (i.e. raa_code = iso_code * 4). Four contiguous values (raa_code + 0, raa_code + 1, raa_code + 2 and raa_code + 3) are used in a single allocation. The inverse (RAA to ISO) works out as: iso_code = floor(raa_code / 4).
As an example the United States has an ISO 3166-1 Numeric Code of 840. This derives the following RAAs: 3360, 3361, 3362 and 3363.
It should be noted that the range of codes from 900 to 999 are defined (by ISO 3166-1) as "user assigned code elements" and do not have specific claimants predefined in the RAA space. Withdrawn and other special codes also do not have predetermined claimants. These values MUST NOT be used for an RAA. RAAs MUST NOT use transitionally reserved, indeterminately reserved or formerly assigned ISO 3166-1 code elements.
How a CAA handles their allocated values is out of scope of this document. Control of these values are expected to be claimed by their respective owner. How they are vetted and validated is out of scope of this document. Protection against fraudulent claims of one of these values is out of scope for this document.
Control of a country's RAAs is a National Matter and is expected to be overseen by the CAA. Management issues include delegation of these RAAs in the 3.0.0.1.0.0.2.ip6.arpa Apex, Secure DNS policy, validation and delegation of DET registrations. These are out of scope for this document.
IANA is prepared to operate an interim registry for 3.0.0.1.0.0.2.ip6.arpa until ICAO is ready to assume administrative control of this Apex. Requests for delegations of RAAs MUST be validated, either by ICAO or the appropriate CAA. This SHOULD follow a process analogous to the procedures used in ENUM [RFC3761] for the delegation of country codes for E.164 telephone numbers. Delegation of RAAs is a National Matter and MUST NOT be made without the consent of the relevant CAA.
- Author: above text is duplicate text in IANA considerations, should it stay here or be removed?
Hierarchial HIT Domain Authority (HDA)
An HDA may be an USS, ISP, or any third party that takes on the business to register client entities that need DETs. Client entities include, but is not limited to UA, GCS, UAS Operators and UAS/UTM infrastructure (such as Supplemental Data Service Providers). An HDA SHOULD also provide needed UAS services including those required for HIP-enabled devices (e.g. RVS).
For UAS RID, HDAs can provide any of the following services:
- registration and public lookup of DETs as a Key ID for Authentication as defined in [RFC9575]
- registration and access controlled lookup of DETs as a pseudonymous UAS Session ID
- registration of UAS ID and UTM Operational Intent to bind them together (if allowed by cognizant authority)
An HDA SHOULD maintain a set of RVS servers for UAS clients that may use HIP. This service MUST be discoverable through the DNS zone maintained by the HDA's RAA.
An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such policy is out of scope for this document.
DIME Architecture
The DIME, in any of its roles (Section 4), is comprised of a number of logical components that are depicted in Figure 3. Any of these components could be merged or delegated to other entities as a service.
Interfaces with a specific transport requirement (such as HTTPS) are labeled accordingly. Interfaces not labeled can be implementation specific or proprietary due to co-location of components. For example the interface between the DPA and a Registrar, when delegated, might be Extensible Provisioning Protocol (EPP) [RFC5730] while implementations combining these components might use an internal and possibly proprietary code library. These non-labeled interfaces are out of scope for this document.
- Author: ensure the diagram below aligns with General Concept diagram and text below. Review(MGLT): subsections do not provide any useful information, I tend to think these should be used to illustrate the figure.
DIME Logical Components

+--------------------+
| Registering Client |
+---------o----------+
          |
          | HTTPS
          |
**********|*********************************************************
*         |                                                        *
*         |      DRIP Identity Management Entity (DIME)            *
*         |                                                        *
*   ######|#####################################################   *
*   #     |                                                    #   *
*   #  +--o-----------------+                                  #   *
*   #  | DIME               |                                  #   *
*   #  | Provisioning Agent |         Registrar Functions      #   *
*   #  | (DPA)              |                                  #   *
*   #  +--------------------+                                  #   *
*   #                                                          #   *
*   ##############################o#############################   *
*                                 |                                *
*                                 | EPP                            *
*                                 |                                *
*   ##############################o#############################   *
*   #                                                          #   *
*   #  +--------------------+                                  #   *
*   #  | DIME               |                                  #   *
*   #  | Information Agent  |         Registry Functions       #   *
*   #  | (DIA)              |                                  #   *
*   #  +--------------------+                                  #   *
*   #                                                          #   *
*   ######o#########################################o###########   *
*         |                                         |              *
*         |                                         |              *
**********|*****************************************|***************
          |                                         |
          | Registrant Information Service          | DNS
          | (e.g. WHOIS, RDAP, etc.)                |
          |                                         |
          |              +---------------+          |
          '--------------o Lookup Client o----------'
                         +---------------+

DIME Provisioning Agent (DPA)
The DPA performs the task of vetting information coming from clients wishing to register. It then delegates (internally or externally) various items to other components in the DIME. This is the primary component that handles all DRIP related cryptographic operations for incoming registrations to the DIME. The role of the DPA is similar to that of a registrar in the conventional model of domain name management in the DNS.
The DPA:
- SHOULD have a publicly accessible and discoverable interface for clients to register
- SHOULD provide DNS service for the DET's registered domain name
Specific details of the above interfaces (such as advertisement) are out of scope for this document.
Registrar & Registry
The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. The following RFC provide suitable guidance: [RFC7720], [RFC4033], [RFC4034], [RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007].
If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. [RFC6841] documents a Framework for DNSSEC Policies and DNSSEC Practice Statements.
The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected registry-registrar activity will use the Extensible Provisioning Protocol (EPP) [RFC5730]. The registry SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP [RFC9082] to provide public information about registered domain names.
Decisions about DNS or registry best practices and other operational matters SHOULD be made by the CAA, ideally in consultation with local stakeholders.
DIME Information Agent (DIA)
The DIA is the main component handling information egress (via lookup) of the DIME. Public information SHOULD be in Authoritative Name Servers and MAY be mirrored into the Private Information Registry. Related PII MUST be stored in a Private Information Registry and MAY be available via RDAP or equivalent.
The DIA:
- MUST have an access controlled interface for add/delete/update of information; this interface MAY be publicly available
  - this interface definition, for example an EPP schema, is out of scope for this document
- SHOULD have an access controlled interface to query for private information; this interface MAY be publicly available
  - if this interface is publicly available it MAY use RDAP or equivalent protocols
  - if this interface is not publicly available its specification is out of scope for this document
Certain information may be considered PII. This is a National Matter, subject to prevailing national laws and regulations. Such data MUST be protected from access using AAA (for example using XACML). These decisions should be determined by the CAA. See Section 7 for more information.
A DIA can be considered an additional function to an existing DNS Registry Operator for DRIP. It MAY be a separate service or entity that interfaces with a DNS provider.
Service Registration Process
This document details the registration process for the following services exclusively using DETs:
- UAS RID Authentication
- UAS Specific Session ID
Specification beyond these services is out of scope for this document.
The Constrained Application Protocol (CoAP) [RFC7252] is the RECOMMENDED interface method for machine to machine communication. This is due to the inherent support of HTTPS and UDP variants, thus giving great flexibility for UAS products that share properties of IoT devices. The specifics of a CoAP implementation for DIME services is out of scope for this document.
This section fulfills REG-3 of [RFC9153].
Generic DET Registration
Generically a DET can be used as an identifier for any node in UTM and SHOULD be registered to a DIME. For example a CAA may choose to use DETs as an identifier for its Operators. A data model would be required to define all the information for registration for a given type of client. Such data models are out of scope for this document.
The general process for a registering DET is shown in Figure 4 and the accompanying text.
DET Registration Timeline

            registrant             dime
                |                   |
(1) GEN_DET/HI  |                   |
                |----(2) INPUT----->|
                |                   | (3) VALID_INPUT?
                |<-------FAIL-------|
                |                   | (4) DUPE_HI?
                |<-------FAIL-------|
                |                   | (5) DUPE_DET?
                |<-------FAIL-------|
                |                   | (6) GEN_BE
                |                   | (7) UPDATE_DATABASE
                |                   | (8) UPDATE_NS
                |<----(9) OUTPUT----|

(1) GEN_DET/HI:
The registrant that plans to use the identity and its cryptographic properties MUST generate the asymmetric key-pair of their choosing and protect the private key with best common practices. The registrant SHOULD derive the corresponding DET. How the registrant obtains the desired HID for DET generation is out of scope for this document.
(2) INPUT:
The registrant MUST format and send the required information for a given service registration as specified by the DIME. Specific service data models and methods, other than those proposed by this document (see Section 6.2), are out of scope.
(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. Signed data, such as Endorsements, MUST have their signatures verified before further processing. Failure of input validation SHOULD return errors to the registrant.
(4) DUPE_HI?:
The DIME MUST check that the proposed HI is not a duplicate already in use. 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 duplicate already in use. 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 its HID. The registrant SHOULD be notified with an error if duplication is detected.
(6) GEN_BE:
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 signifies the DIME accepts the DET/HI pairing from the registrant.
(7) UPDATE_DATABASE:
The DIME MUST update the Private Information Registry with any PII that was part of the registration. It MAY include additional metadata or public information. How the Private Information Registry is updated is out of scope for this document. example a CAA may choose to use DETs as an identifier for its Operators. A data model would be required to define all the information (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 Section 8.
(9) OUTPUT:
The DIME, upon successful updates of the Private Information Registry and Name Server, transmits to the registrant the list of Broadcast Endorsements that make up the trust chain for use in [RFC9575].
Session ID & Authentication Services
Both UAS RID Authentication and UAS Specific Session ID services when using DETs share a common data model for registration. Endorsements (Section 9) are the RECOMMENDED way to securely transfer information for registration.
Appendix D contains the general data model as well as the specific variants for Session ID & Authentication services.
Differentiated Access Process
Per [RFC9434] all information classified as private is stored in a datastore protected using some form of differentiated access (i.e. AAA) to satisfy REG-2 from [RFC9153]. Differentiated access is a requirement for DIMEs as defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4, REG-2 and REG-4. [RFC9434] further elaborates on the concept by citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential means of fulfilling this requirement.
- Author: is this section pertaining to the lookup mechanisms enough for this document?
DRIP in the Domain Name System
Per [RFC9434] all information classified as public is stored in the DNS to satisfy REG-1 from [RFC9153]. This is primarily done use Resource Records (RRs). This document defines two new DNS RRs, one for HHIT metadata (Appendix A) and another for UAS RID information (Appendix B).
DIMEs MUST be responsible for the operation of the DNS-related infrastructure for domain names under DRIP. It MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two.
DIMEs SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times, incident handling, complaints, law enforcement interaction and so on. National policy and regulations will define how long DNS data are stored or archived. These are all National Matters where national law/regulation prevail ensuring DRIP complies with national law and regulation since these are matters of national sovereignty.
DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies.
UAS specific information that is publicly available MAY also be stored in DNS but is out of scope for this document. This specification information is drafted in [uas-sn-dns]. An optional record to store static information for UAS RID is defined in Appendix B.
For DRIP, IANA has agreed to act as the Apex at least initially (see Section 11.1 for more details). The assignment of RAAs to civil aviation authorities is already done per Section 4.2.1 using their ISO 3166-1 Numeric Codes. The Apex SHOULD be the trust anchor in a Endorsement or certificate chain that provides validation of any of these specific RAAs to minimize the risk of fraudulent RRAs.
DRIP Entity Tags
The REQUIRED mechanism is to place any information into ip6.arpa when using a DET. Since the DET is an IPv6 address it can be nibble-reversed and used in the zone, per standard conventions.
The prefix 2001:30::/28 is registered with IANA [RFC9374] and 3.0.0.1.0.0.2.ip6.arpa - the corresponding reverse domain - SHOULD be under the administrative control of the Apex. In addition to the DNS infrastructure for 3.0.0.1.0.0.2.ip6.arpa, the Apex SHOULD be responsible for the allocation of IPv6 addresses in this prefix. The RAA, might need to develop an addressing plan for delegating HDA values.
Distribution of HHIT (IPv6 address) blocks SHOULD be done using the 14-bit RAA space as a framework. The Apex SHOULD allocate blocks to each entity who can then assign them to HDAs in accordance with local law and policy. All HDAs MUST have an IPv6 address in 2001:30::/28. A discrete zone SHOULD be delegated for each HDA. These MUST contain an HHIT resource record (Appendix A) for itself.
Reverse lookups of these IPv6 addresses MUST return HIP and HHIT RRTypes. Depending on local circumstances these lookups MAY return other RRTypes.
Endorsements
DRIP Endorsements are defined in a CDDL [RFC8610] structure (Figure 5) that can be encoded to CBOR, JSON or as a binary blob by concatenating values. CBOR is the preferred encoding format.
The CDDL was derived from the more specific structure developed for [RFC9575]. As such the structures found in [RFC9575], such as the UA Signed Evidence and the contents of DRIP Link (known as a Broadcast Endorsement), are a subset of the below definition in a strict binary form.
- Note: this section uses the term HHIT instead of DET as the Endorsements are designed to be generic and re-useable for other HHIT use-cases.
Endorsement CDDL

endorsement = #6.TBD([
    e-type,
    scope,
    ? $$evidence,
    $$endorser,
    $$signature
])

e-type = uint .size(2)
scope = {
    vnb: time,
    vna: time,
    * tstr => any
}

$$endorser //= (hhit,)
$$endorser //= (hhit, eddsa25519-hi,)
$$endorser //= (eddsa25519-hi,)
$$signature //= (eddsa25519-sig,)

hhit = #6.54(bstr .size(16))
eddsa25519-hi = bstr .size(32)
eddsa25519-sig = bstr .size(64)

An Endorsement is made from a CBOR array with 4-5 elements in a specific order as defined below.
Endorsement Type:
a 16-bit value used to hint at the content of the various groups. Four special values (1 through 4) map to the SAM Type of the Authentication framing in [RFC9575], allowing the 16-bit value to be excluded from the Endorsement structure. See Section 11.2.2 for more details.
Scope:
This section is more formally known as "the scope of validity of the endorsement". The scope can come in various forms but MUST always contain a "valid not before" (vnb) and "valid not after" (vna) timestamps. Other forms of the scope could for example be a 4-dimensional volume definition. This could be in raw latitude, longitude, altitude tuples or may be a URI pointing to scope information. Additional scope fields are out of scope for this document and should be defined for specific Endorsement structures if they are desired and assigned an e-type.
Evidence:
socket group containing a set claims, usually CBOR encoded. The content and order of claims is specified explicitly for each e-type.
Endorser:
socket group where the main identity information of the signer of the Endorsement is found. The identity can take many forms such as a handle to the identity (e.g. an HHIT), or can include more explicit data such as the public key (e.g. an HI). The content and ordering is specified explicitly for each e-type. This document defines three different options for this group, using combinations of a DET and its HI.
Signature:
socket group containing the signature data for the Endorsement. The content and ordering is specified explicitly for each e-type. Signatures MUST be generated using the preceding sections (except for e-type) in their binary forms (i.e. as a concatenated octet-string of values) rather than their CBOR encoding. This document defines a single group option sized to an EdDSA25519 signature.
Appendix F specifies Endorsement structures for the UAS RID use-case.
X.509 Certificates
Certificate Policy and Certificate Stores
X.509 certificates are optional for the DRIP entities covered in this document. DRIP endpoint entities (EE) (i.e., UA, GCS, and Operators) may benefit from having X.509 certificates. Most of these certificates will be for their DET and some will be for other UAS identities. To provide for these certificates, some of the other entities (e.g. USS) covered in this document will also have certificates to create and manage the necessary PKI structure.
Three certificate profiles are defined, with examples, and explained in [drip-dki]. Each has a specific role to play and an EE may have its DET enrolled in all of them. There is a 'Lite' profile that would work well enough on constrained communication links for those instances where various issues push the use of X.509. There is a 'Basic; profile that is more in line with [RFC5280] recommendations, but is still small enough for many constrained environments. Finally there is a profile to directly add DET support into the civil/general aviation certificates as discussed below.
A Certificate Authority (CA) supporting DRIP entities MAY adhere to the ICAO's Aviation Common Certificate Policy (ACCP). The CA(s) supporting this CP MUST either be a part of the ACCP cross-certification or part of the ACCP CA Trust List. It is possible that future versions of the ACCP will directly support the DRIP Basic profile.
- Authors Note: ACCP is ICAO Doc 10169 Aviation Common Certificate Policy (ACCP). I can't get a url for that, but so far these is no changes from v 0.93 of the old IATF CP; changes are in the works then will be posted, so continue to reference IATF CP
EEs may use their X.509 certificates, rather than their rawPublicKey (i.e. HI) in authentication protocols (as not all may support rawPublicKey identities). Short lived DETs like those used for a single operation or even for a day's operations may not benefit from X.509. Creating then almost immediately revoking these certificates is a considerable burden on all parts of the system. Even using a short notAfter date will not completely mitigate the burden of managing these certificates. That said, many EEs will benefit to offset the effort. It may also be a regulator requirement to have these certificates. Finally, certificates can provide the context of use for a DET (via policy constraint OIDs).
Typically an HDA either does or does not issue a certificate for all its DETs. An RAA may specifically have some HDAs for DETs that do not want/need certificates and other HDAs for DETs that do need them. These types of HDAs could be managed by a single entity thus providing both environments for its customers.
It is recommended that DRIP X.509 certificates be stored as DNS TLSA Resource Records, using the DET as the lookup key. This not only generally improves certificate lookups, but also enables use of DANE [RFC6698] for the various servers in the UTM and particularly DIME environment and DANCE [dane-clients] for EEs (e.g. [drip-secure-nrid-c2]). All DRIP certificates MAY alternatively be available via RDAP. LDAP/OCSP access for other UTM and ICAO uses SHOULD also be provided.
Certificate Management
PKIX standard X.509 issuance practices should be used. The certificate request SHOULD be included in the DET registration request. A successful DET registration then MUST include certificate creation, store, and return to the DET registrant. It is possible that the DET registration is actually an X.509 registration. For example, PKIX CSR may be directly used and the DET registration and Endorsement creation are a addition to this process. Further ACME may be directly extendable to provide the DET registration.
Note that CSRs do not include the certificate validityDate; adding that is done by the CA. If in the registration process, the EE is the source of notBefore and notAfter dates, they need to be sent along with the CSR.
Certificate revocation will parallel DET revocation. TLSA RR MUST be deleted from DNS and RDAP, LDAP, and OCSP return revoked responses. CRLs SHOULD be maintained per the CP.
Examples
For full examples of X.509 Certificates and the process to use them see [drip-dki].
Alternative Certificate Encoding
The CBOR Encoded X.509 Certificates (C509 Certificates) [cbor-cert] provides a standards-based approach to reduce the size of X.509 certificates both on-the-wire and in storage. The PKI-Lite RAA certificate example in Appendix B.2 is 331 bytes. The matching C509 certificate is 183 bytes. This sort of difference may have significant impact both on UAS storage requirements and over-the-air transmission impact.
- Author: where is the B.2 example from?
C509 provides two approaches for encoding X.509:
1. An invertible CBOR re-encoding of DER encoded X.509 certificates [RFC5280], which can be reversed to obtain the original DER encoded X.509 certificate.
2. Natively signed C509 certificates, where the signature is calculated over the CBOR encoding instead of over the DER encoding as in 1. This removes the need for ASN.1 and DER parsing and the associated complexity but they are not backwards compatible with implementations requiring DER encoded X.509.
The invertible CBOR encoding may be sufficient for most needs. The CBOR objects clearly indicate which approach was used, so that the receiver can properly process the C509 object. For interoperability in DRIP, it is recommended that invertible CBOR encoding be used.
Using the invertible CBOR encoding is achieved through in-line libraries that convert in the desired direction. Since it is not expected that DNS protocols to implement this conversion, the HHIT RR SHOULD contain the normal X.509 DER encoding. The CBOR encoding MAY be used, but operational experience will be needed to see if there are measurable gains in doing so.
IANA Considerations
Management of DRIP Apex
IANA is asked to maintain the DNS registry for 3.0.0.1.0.0.2.ip6.arpa and oversee the delegation of RAA allocations until administrative control can be transitioned to ICAO. Requests for delegation of RAAs MUST be approved by the appropriate CAA. Control of a country's RAAs is a National Matter and is expected to be overseen by the CAA. Management issues include delegation of these RAAs in the 3.0.0.1.0.0.2.ip6.arpa Apex, Secure DNS policy, validation and delegation of DET registrations. These are out of scope for this document.
Requests for delegations of RAAs MUST be validated, either by ICAO or the appropriate CAA. This SHOULD follow a process analogous to the procedures used in ENUM [RFC3761] for the delegation of country codes for E.164 telephone numbers. Delegation of RAAs is a National Matter and MUST NOT be made without the consent of the relevant CAA.
IANA DRIP Registry
DRIP RAA Allocations
This document requests a new registry for RAA Allocations under the DRIP registry group to be managed by IANA.
RAA Allocations:
a 14-bit value that is allocated in groups of 4. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values/ranges are defined:
RAA Value(s) | Status | Allocation | Reference
0 - 3 | Allocated | UAS RID (DRIP) Apex | This RFC (Section 4.1.1)
4 - 3999 | Allocated | ISO 3166-1 Countries | This RFC (Section 4.2.1)
4000 - 16375 | Reserved | N/A | N/A
16375 - 16383 | Allocated | DRIP WG (Experimental Use) | This RFC
- Author: do we set an RAA/HDA for "unregistered" users? A UA could generate a DET/HI and create a "self-signed" BE for Broadcast RID.
The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found as a CSV file on GitHub.
Endorsement Types
This document requests a new registry for Endorsement Type under the DRIP registry group.
Endorsement Type:
A 16-bit value to provide hinting of the contents of other sections of an Endorsement. Future additions to this registry are to be made through Specification Required (Section 4.3 of [RFC8126]) for values 0x0000 to 0xEFFF and First Come First Served (Section 4.4 of [RFC8126]) for the values 0xF000 to 0xFFFF. The following values are defined:
Value | Endorsement Type | Reference
0 | Self-Endorsement | This RFC (Appendix F.1)
1 | Broadcast Endorsement | This RFC (Appendix F.2)
2 | Wrapper | This RFC (Appendix F.3)
3 | Manifest | This RFC (Appendix F.4)
4 | Frame | This RFC (Appendix F.5)
To register an e-type the following MUST be provided in CDDL for review:
- Additions to scope map (optional)
- Specific group contents of $$evidence
- Specific group contents of $$endorser
- Specific group contents of $$signature
HHIT Type
This document requests a new registry for HHIT Type under the DRIP registry group.
HHIT Type:
numeric, 16-bit, field of the HHIT RR to encode the HHIT Type. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values are defined:
Value | Type | Reference
0 | Not Defined | This RFC
1 | DRIP Identity Management Entity (DIME) | This RFC
2 | Apex | This RFC
3 | Registered Assigning Authority (RAA) | This RFC
4 | HHIT Domain Authority (HDA) | This RFC
5 | DIME Provisioning Agent (DPA) | This RFC
6 | DIME Information Agent (DIA) | This RFC
7 | ISO 3166-1 Numeric Nation (INN) | This RFC
8 - 15 | Reserved |
16 | Endpoint Entity (EE) | [drip-dki]
17 | Issuer CA | [drip-dki]
18 | Authentication CA | [drip-dki]
19 | Uncrewed Aircraft (UA) | This RFC
20 | Ground Control Station (GCS) | This RFC
21 | Uncrewed Aerial System (UAS) | This RFC
22 | Remote Identification (RID) Module | This RFC
23 | Pilot | This RFC
24 | Operator | This RFC
25 | Discovery & Synchronization Service (DSS) | This RFC
26 | UAS Service Supplier (USS) | This RFC
27 | Network RID Service Provider (SP) | This RFC
28 | Network RID Display Provider (DP) | This RFC
29 | Supplemental Data Service Provider (SDSP) | This RFC
30 - 65535 | Reserved |
- Author: text on DRIP Expert Review process
HHIT Status
This document requests a new registry for HHIT Status under the DRIP registry group.
HHIT Status:
numeric, 8 bit, field of the HHIT RR to encode the HHIT Status. Future additions to this registry are to be made through Expert Review (Section 4.5 of [RFC8126]). The following values are defined:
Value | Status | Description | Reference
0 | Inactive | Default when accepted by DIME | This RFC
1 | Active | Set when in use | This RFC
2 | Expired | Set when past VNA | This RFC
3 | Deprecated | Set when no longer in use (but not expired) | This RFC
- Author: text on DRIP Expert Review process
Security Considerations
DNS Operational Considerations
The contents of this section are duplicated in Section 5.2
The Registrar and Registry are commonly used concepts in the DNS. These components interface the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. The following RFC provide suitable guidance: [RFC7720], [RFC4033], [RFC4034], [RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007].
If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be developed and published. It SHOULD explain how DNSSEC has been deployed and what security measures are in place. [RFC6841] documents a Framework for DNSSEC Policies and DNSSEC Practice Statements.
The interfaces and protocol specifications for registry-registrar interactions are intentionally not specified in this document. These will depend on nationally defined policy and prevailing local circumstances. It is expected registry-registrar activity will use the Extensible Provisioning Protocol (EPP) [RFC5730]. The registry SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP [RFC9082] to provide public information about registered domain names.
Decisions about DNS or registry best practices and other operational matters SHOULD be made by the CAA, ideally in consultation with local stakeholders.
Key Rollover & Federation
During DET key rollover the DIME MUST inform all children and parents of the change - using best standard practices of a key rollover.
A DET has a natural ability for a single DIME to hold different cryptographic identities under the same HID values. This is due to the lower 64-bits of the DET being a hash of the public key and the HID of the DET being generated. As such during key rollover, only the lower 64-bits would change and a check for a collision would be required.
This attribute could also allow for a single DIME to be "federated" across multiple DETs sharing the same HID value. This method of deployment has not been thoroughly studied at this time.
DET Generation
- Author: is this section valid anymore? Perhaps we hard specify that devices ONLY generate on their own hardware instead of "out-sourcing" as this section implies.
Under the FAA [FAA-RID-NPRM], it is expecting that Session IDs for UAS are assigned by the UTM and are one-time use. The methods for this however are unspecified leaving two options.
Option 1:
- The entity generates its own DET, discovering and using the RAA and HDA for the target DIME. The method for discovering a DIME's RAA and HDA is out of scope here. This allows for the device to generate an DET to send to the DIME to be accepted (thus generating the required Self-Endorsement) or denied.
Option 2:
- The entity sends to the DIME its HI for it to be hashed and result in the DET. The DIME would then either accept (returning the DET to the device) or deny this pairing.
Keypairs are expected to be generated on the device hardware it will be used on. Due to hardware limitations and connectivity it is acceptable, though not recommended, under DRIP to generate keypairs for the Aircraft on Operator devices and later securely inject them into the Aircraft. The methods to securely inject and store keypair information in a "secure element" of the Aircraft is out of scope of this document.
Public Key Exposure
DETs are built upon asymmetric keypairs. As such the public key must be revealed to enable clients to perform signature verifications.
While unlikely the forging of a corresponding private key is possible if given enough time (and computational power). As such it is RECOMMENDED that the public key for any DET not be exposed in DNS (using the HIP RR) until it is required.
Optimally this requires the UAS somehow signal the DIME that a flight using a Specific Session ID will soon be underway or complete. It may also be facilitated under UTM if the USS (which may or may not be a DIME) signals when a given operation using a Session ID goes active.
Contributors
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundations for the content and processes of this architecture and document. Bob Moskowitz is also instrumental in the PKIX work defined in this document with his parallel work in ICAO.
References
Normative References
[RFC9153]

Drone Remote Identification Protocol (DRIP) Requirements and Terminology
S. Card, Ed.
A. Wiethuechter
R. Moskowitz
A. Gurtov
February 2022
RFC 9153
DOI 10.17487/RFC9153
[RFC9374]

DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
R. Moskowitz
S. Card
A. Wiethuechter
A. Gurtov
March 2023
RFC 9374
DOI 10.17487/RFC9374
[RFC9434]

Drone Remote Identification Protocol (DRIP) Architecture
S. Card
A. Wiethuechter
R. Moskowitz
S. Zhao, Ed.
A. Gurtov
July 2023
RFC 9434
DOI 10.17487/RFC9434
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[drip-secure-nrid-c2]

Secure UAS Network RID and C2 Transport
Robert Moskowitz
HTT Consulting
Stuart W. Card
AX Enterprize
Adam Wiethuechter
AX Enterprize
Andrei Gurtov
Linköping University
16 March 2024
Internet-Draft draft-moskowitz-drip-secure-nrid-c2-14
[dane-clients]

TLS Client Authentication via DANE TLSA records
Shumon Huque
Salesforce
Viktor Dukhovni
Two Sigma
13 January 2024
Internet-Draft draft-ietf-dance-client-auth-05
[drip-dki]

The DRIP DET public Key Infrastructure
Robert Moskowitz
HTT Consulting
Stuart W. Card
AX Enterprize, LLC
23 October 2023
Internet-Draft draft-moskowitz-drip-dki-09
[cbor-cert]

CBOR Encoded X.509 Certificates (C509 Certificates)
John Preuß Mattsson
Ericsson AB
Göran Selander
Ericsson AB
Shahid Raza
RISE AB
Joel Höglund
RISE AB
Martin Furuhed
Nexus Group
4 March 2024
Internet-Draft draft-ietf-cose-cbor-encoded-cert-09
[uas-sn-dns]

UAS Serial Numbers in DNS
Adam Wiethuechter
AX Enterprize, LLC
25 June 2024
Internet-Draft draft-wiethuechter-drip-uas-sn-dns-02
[RFC3761]

The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
P. Faltstrom
M. Mealling
April 2004
RFC 3761
DOI 10.17487/RFC3761
[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk
May 2008
RFC 5280
DOI 10.17487/RFC5280
[RFC5730]

Extensible Provisioning Protocol (EPP)
S. Hollenbeck
August 2009
STD 69
RFC 5730
DOI 10.17487/RFC5730
[RFC6698]

The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
P. Hoffman
J. Schlyter
August 2012
RFC 6698
DOI 10.17487/RFC6698
[RFC6841]

A Framework for DNSSEC Policies and DNSSEC Practice Statements
F. Ljunggren
AM. Eklund Lowinder
T. Okubo
January 2013
RFC 6841
DOI 10.17487/RFC6841
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC7480]

HTTP Usage in the Registration Data Access Protocol (RDAP)
A. Newton
B. Ellacott
N. Kong
March 2015
STD 95
RFC 7480
DOI 10.17487/RFC7480
[RFC7519]

JSON Web Token (JWT)
M. Jones
J. Bradley
N. Sakimura
May 2015
RFC 7519
DOI 10.17487/RFC7519
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8392]

CBOR Web Token (CWT)
M. Jones
E. Wahlstroem
S. Erdtman
H. Tschofenig
May 2018
RFC 8392
DOI 10.17487/RFC8392
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC9082]

Registration Data Access Protocol (RDAP) Query Format
S. Hollenbeck
A. Newton
June 2021
STD 95
RFC 9082
DOI 10.17487/RFC9082
[RFC9083]

JSON Responses for the Registration Data Access Protocol (RDAP)
S. Hollenbeck
A. Newton
June 2021
STD 95
RFC 9083
DOI 10.17487/RFC9083
[RFC9334]

Remote ATtestation procedureS (RATS) Architecture
H. Birkholz
D. Thaler
M. Richardson
N. Smith
W. Pan
January 2023
RFC 9334
DOI 10.17487/RFC9334
[RFC9575]

DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)
A. Wiethuechter, Ed.
S. Card
R. Moskowitz
June 2024
RFC 9575
DOI 10.17487/RFC9575
[RFC4033]

DNS Security Introduction and Requirements
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4033
DOI 10.17487/RFC4033
[RFC5155]

DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
B. Laurie
G. Sisson
R. Arends
D. Blacka
March 2008
RFC 5155
DOI 10.17487/RFC5155
[RFC8945]

Secret Key Transaction Authentication for DNS (TSIG)
F. Dupont
S. Morris
P. Vixie
D. Eastlake 3rd
O. Gudmundsson
B. Wellington
November 2020
STD 93
RFC 8945
DOI 10.17487/RFC8945
[RFC4034]

Resource Records for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4034
DOI 10.17487/RFC4034
[RFC4035]

Protocol Modifications for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4035
DOI 10.17487/RFC4035
[RFC3007]

Secure Domain Name System (DNS) Dynamic Update
B. Wellington
November 2000
RFC 3007
DOI 10.17487/RFC3007
[RFC2182]

Selection and Operation of Secondary DNS Servers
R. Elz
R. Bush
S. Bradner
M. Patton
July 1997
BCP 16
RFC 2182
DOI 10.17487/RFC2182
[RFC7720]

DNS Root Name Service Protocol and Deployment Requirements
M. Blanchet
L-J. Liman
December 2015
BCP 40
RFC 7720
DOI 10.17487/RFC7720
[RFC3912]

WHOIS Protocol Specification
L. Daigle
September 2004
RFC 3912
DOI 10.17487/RFC3912
[RFC4786]

Operation of Anycast Services
J. Abley
K. Lindqvist
December 2006
BCP 126
RFC 4786
DOI 10.17487/RFC4786
[CTA2063A]

ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers
September 2019
[FAA-RID-NPRM]

Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems
December 2019
[F3411]

Standard Specification for Remote ID and Tracking
ASTM International
July 2022
ASTM F3411-22A
DOI 10.1520/F3411-22A
HHIT Resource Record
This appendix is normative.
The HHIT Resource Record is a metadata record for various bits of HHIT specific information that isn't available in the pre-existing HIP RR Type. It is encoded as a CBOR array with a TBD CBOR Tag.
Wire Format
HHIT Wire Format CDDL

hhit-rr = #6.TBD([
    hhit, type, status, abbreviation, endorsements, uris
])
hhit = #6.54(bstr .size(16))
type = uint .size(2)
status = uint .size(1)
abbreviation = tstr .size(15)
endorsements = [1* #6.TBD]  ; MUST be in e-type order
uris = [* #6.32]

Presentation Format
HHIT Presentation Format

<domain> HHIT IN ( HHIT TYPE STATUS ABBREV [Endorsement(s)] [URI(s)])

Field Descriptions
Type:
This field is two octets with values defined in Section 11.2.3. It is envisioned that there may be many types of HHITs in use. In some cases it may be helpful to understand the HHITs role in the ecosystem like described in [drip-dki].
Status:
This field is a single byte with values defined in Section 11.2.4. A HHIT can go through various states during its life-cycle in the ecosystem. For example: TODO(ATW).
Abbreviation:
This field is meant to provide an abbreviation to the HID structure for display devices. The specific contents of this field are not defined here, but a recommendation/example can be found in Appendix C.
Endorsements:
This field is a list of CBOR encoded Endorsements in e-type order. It MUST included at least one Broadcast Endorsement (Appendix F.2). A special case for the Apex is that the Broadcast Endorsement is filled with its own DET and HI as evidence (i.e. a self-signed Broadcast Endorsement).
URIs:
This field is a list of URIs that can be used for the given HHIT to obtain information.
Example
The following example was generated using the CDDL presented in Figure 6 with the tool in Appendix F of [RFC8610].
CBOR Tag 55799 is used in this example.

TODO

UAS Broadcast RID Resource Record
This appendix is informative.
The UAS Broadcast RID Resource Record type (UASRID) is a format to hold public information typically sent of the UAS Broadcast RID that is static. It can act as a data source if information is not recieved over Broascast RID or for cross validation.
Wire Format
UASRID Wire Format CDDL

uasrid-rr = #6.55799({
    uas_type: nibble-field,
    uas_ids: {+ &uas-id-types => uas-id},
    ? auth-grp,
    ? self-grp,
    ? op_type: 0..3,
    ? area-grp,
    ? classification-grp,
    ? operator-grp
})
uas-id = bstr .size(20)
uas-id-types = (none: 0, serial: 1, caa: 2, utm: 3, session: 4)
auth-grp = (
    a_type: nibble-field,
    a_data: bstr .size(1..255),
    ? add_a_data: bstr .size(0..255)
)
area-grp = (
    area_count: 1..255,
    area_radius: float,
    area_floor: float,
    area_ceiling: float
)
classification-grp = (
    ua_class: 0..8,
    eu_class: nibble-field,
    eu_category: nibble-field
)
self-grp = (
    desc_type: nibble-field,
    description: tstr .size(23)
)
operator-grp = (
    operator_id_type: nibble-field,
    operator_id: bstr .size(20)
)
nibble-field = 0..15

Presentation Format
UASRID Presentation Format

<domain> IN UASRID ( TODO )

Field Descriptions
The field names and their general typing are borrowed from the ASTM [F3411] data dictionary. See that document for additional information on fields semantics and units.
Example
The following example was generated using the CDDL presented in Figure 8 with the tool in Appendix F of [RFC8610].
CBOR Tag 55799 is used in this example.
UASRID RR Wire Format Example (CBOR Encoded)

d9d9f7a5687561735f747970650c6775
61735f696473a100548c0ee64a4212ba
be59e8459b25e5e550b0b3ae85687561
5f636c617373076865755f636c617373
006b65755f63617465676f727905

UASRID RR Presentation Format Example (CBOR Decoded)

55799({
  "uas_type": 12,
  "uas_ids": {0: h'8C0EE64A4212BABE59E8459B25E5E550B0B3AE85'},
  "ua_class": 7,
  "eu_class": 0,
  "eu_category": 5
})

HID Abbreviation Recommendation
This appendix is informative.
On receiver devices a DET can be translated to a more human readable form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4 Characters of DET Hash}. An example of this would be US FAA FE23.
To support this DIMEs are recommended to have an abbreviation that could be used for this form. These abbreviations should be a maximum of six characters (for each section) in length. Spaces should not be used and be replaced with either underscores (_) or dashes (-).
The concatenation of {RAA Abbreviation} and {HDA Abbreviation} with a space between them can be what fills in the HID field of the HHIT RR in Appendix A.
For RAAs allocated in the ISO range Section 4.2.1, the RAA abbreviation should be set to the ISO 3166-1 country code (either Alpha-2 or Alpha-3). A common abbreviation for an RAAs four allocated RAA values are out of scope. Other documents such as [drip-dki] may have more specific recommendations or requirements.
If a DIME does not have an abbreviation or it can not be looked up then the receiver must use the uppercase 4-character hexadecimal encoding of the field it is missing when using this form.
DET Services Registration Models
This appendix is normative.
DET Registration Evidence Model

$$evidence //= ({
    serial_number: bstr .size(20),
    uas_id_type: 0..15,
    uas_id: bstr .size(20),
    dki: hi / [det, hi] / #6.TBD,
    ? utm: [utm-id, utm-uri],
    * tstr => any
},)

det = #6.48(bstr .size(16))
hi = bstr .size(32)
utm-id = bstr .size(16),  ; uuidv4
utm_uri = #6.32(tstr)     ; uri

UAS ID Type and UAS ID:
defined per ASTM [F3411]. See Appendix D.1 for handling specific instructions during registration.
UAS Serial Number:
defined per [CTA2063A]. Other UAS Serial Number formats (considered legacy) are out of scope for this document.
UTM Assigned ID:
also known as an Operational Intent, defined per TODO-UTM-REF and ASTM [F3411] as a UUIDv4. Part of the UTM Binding group which also includes the source URI of the Operational Intent.
It is RECOMMENDED that the information above is signed over in some way to ensure integrity of the registration data. The recommended way to do this is with a Endorsement (Section 9). Another way, the specification of which is out of scope, is with a JWT [RFC7519] or CWT [RFC8392].
Other data elements MAY be added to this model. A DIME MUST have a public API detailing additional elements expected for their implementations. These elements and reference is out of scope for this document.
The following table highlights the specific fields to be set for each service, distinguished using e-type.
DET Service Type | e-type | uas_id_type == 4? | det present? | hi present?
Session ID | TBD1 | MUST | MUST NOT | MUST
Authentication | TBD2 | MUST NOT | MAY | MUST
Session ID & Authentication | TBD3 | MAY | MUST | MUST
UAS ID Handling
The uas_id_type field MUST be set to same UAS ID Type in the ASTM [F3411] Basic ID Message to ensure proper decoding of the uas_id field.
The uas_id field MUST be set with the octets found in the ASTM [F3411] Basic ID Message UAS ID field. By using identical contents of the Basic ID Message the Specific Session ID Type octet (the first octet in the UAS ID when using UAS ID Type is 0x4) is preserved. It is RECOMMENDED to preserve the null padding.
Registration Model Examples
The following are example CDDLs for registration models for the Session ID and Authentication & Session ID services.
DET Session ID Registration Evidence Model

$$evidence //= ({
    serial_number: bstr .size(20),
    uas_id_type: 0..15,
    uas_id: bstr .size(20),
    dki: dki-grp
},)
dki-grp = {
    hi: bstr .size(32)
}

DET Authentication & Session ID Registration Evidence Model

$$evidence //= ({
    serial_number: bstr .size(20),
    uas_id_type: 0..15,
    uas_id: bstr .size(20),
    dki: dki-grp
},)
dki-grp = {
    det: #6.48(bstr .size(16)),
    hi: bstr .size(32)
}

Relationship to RATS
Remote ATtestationS (RATS) [RFC9334] can play a functional role in the DRIP registration process. The act of registering in DRIP can be seen as a form of attestation to obtain an identity where a Registrant acts as the Attester and a DIME is both the Relying Party and Verifier.
The specifics of using RATS models (such as Passport, Background-Check or some combintation) is out of scope for this document.
DRIP Endorsements for UAS
This appendix is normative. Each section contains the CDDL definition of the Endorsement along with examples in various formats.
The CDDL representation and thus CBOR examples of Appendix F.2, Appendix F.3, Appendix F.4, and Appendix F.5 are back fitted from the binary form and MUST only be used for transport between entities. Their signature generation follows Section 4.1 of [RFC9575].
Self Endorsement
The Self Endorsement MAY be used during registration process as an input. $$evidence contains the HI of the endorser. $$endorser contains the HHIT of the endorser. $$signature contains the EdDSA25519 signature.
Self Endorsement CDDL

e-type = 0  ; Self Endorsement
$$evidence //= (eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)

Self Endorsement CBOR (Encoded)

TODO

Self Endorsement CBOR (Decoded)

TODO

Broadcast Endorsement
Defined by [RFC9575] in a binary format (see Figure 18) to support Authentication over ASTM [F3411] constrained links and is the main content of the DRIP Link. This Endorsement is a required output of registration to a DIME at any level.
Broadcast Endorsement Binary

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                              VNB                              |
+---------------+---------------+---------------+---------------+
|                              VNA                              |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                             Child                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                             HI of                             |
|                             Child                             |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                            HHIT of                            |
|                            Parent                             |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                           Signature                           |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+

Broadcast Endorsement CDDL

e-type = 1  ; SAM Type=1, Broadcast Endorsement
$$evidence //= (hhit, eddsa25519-hi,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)

$$evidence are the child entities (e.g. a UA) DET/HHIT and its associated HI. $$endorser contains the HHIT of the parent entity (e.g. DIME) as the endorser. $$signature contains the EdDSA25519 signature.
Note that the Endorsement Type (e-type) field is the same value as the SAM Type allocated to DRIP (i.e. the value 1). As such for DRIP Authentication the e-type field is not encoded into the binary form and is instead handled by the SAM Type of the Authentication framing.
Broadcast Endorsement CBOR (Encoded)

TODO

Broadcast Endorsement CBOR (Decoded)

TODO

Wrapper Endorsement
Defined by [RFC9575] in a binary format (see Figure 22) to support Authentication over ASTM [F3411] constrained links and is the main content of the DRIP Wrapper.
Wrapper Endorsement Binary

TODO

Wrapper Endorsement CDDL

e-type = 2 ; SAM Type=2, Wrapper Endorsement
$$evidence //= (*4 astm-message,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
astm-message = bstr .size(25)

Wrapper Endorsement CBOR (Encoded)

TODO

Wrapper Endorsement CBOR (Decoded)

TODO

Manifest Endorsement
Defined by [RFC9575] in a binary format (see Figure 26) to support Authentication over ASTM [F3411] constrained links and is the main content of the DRIP Manifest.
Manifest Endorsement Binary

TODO

Manifest Endorsement CDDL

e-type = 3  ; SAM Type=3, Manifest Endorsement
$$evidence //= (3*11 manifest-hash,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
manifest-hash = bstr .size(8)

Manifest Endorsement CBOR (Encoded)

TODO

Manifest Endorsement CBOR (Decoded)

TODO

Frame Endorsement
Defined by [RFC9575] in a binary format (see Figure 30) to support Authentication over ASTM [F3411] constrained links and is the main content of the DRIP Frame.
Frame Endorsement Binary

TODO

Frame Endorsement CDDL

e-type = 4  ; SAM Type=4, Frame Endorsement
$$evidence //= (frame-type, frame-data,)
$$endorser //= (hhit,)
$$signature = (eddsa25519-sig,)
frame-type = uint .size(1)
frame-data = bstr .size(1..111)

Frame Endorsement CBOR (Encoded)

TODO

Frame Endorsement CBOR (Decoded)

TODO

DNS Examples
This appendix is informative.