AX Enterprize, LLC

4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com

RTFM llp

St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL UK jim@rfc1035.com

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 their artifacts is performed via DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications.

Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote ID (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 ). Such extended information is retrieved from the UAS ID via the use of a DRIP Entity Tag (DET) which is managed by the DRIP Identity Management Entity (DIME). In this document we assume the DIME belongs to the UAS Service Suppliers (USS) (Appendix A.2 of ) but a DIME can be independent or handled by another entity as well. While most data to be sent via Broadcast RID (Section 1.2.1 of ) or Network RID (Section 1.2.2 of ) is public, much of the extended information will be private. As discussed in Section 7 of , 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. The intent of the access control requirements is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Registration is necessary to guarantee the uniqueness of the DET and thus to ensure the extended information is bound to the UAS ID. This document creates the DRIP registration and discovery architecture focusing on the DET for UAS at its surrounding ecosystem. Clients in the architecture that can use a DET include Unmanned Aircraft (UA), Registered Assigning Authority (RAA), Hierarchical HIT Domain Authority (HDA), Ground Control Station (GCS), and USS. This document uses the Concise Data Definition Language (CDDL) for describing the registration data.

General Concept DETs when generated are only "proposed" and MUST be registered within the hierarchy to become legitimate. 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 based around DETs. Other identifiers and their methods are out of scope for this document. This document selects the Domain Name System (DNS) as the Public Information Registry for both storing and retrieving public information, such as the public key of DETs and pointers to Private Information Registries. Personally Identifiable Information (PII) is stored in Private Information Registries and MUST be protected through AAA. For UAS, a DIME can provide the following congruent registration and lookup services:

1. personal information (e.g. for pilots and operators)
2. UAS Serial Number and aircraft physical characteristics
3. DETs as a Key ID for UAS RID Authentication ()
4. DETs as a pseudo-anonymous UAS Specific Session ID (UAS ID Type 4)
5. binding of UAS ID to UTM Operational Intent

A DIME's services are determined by their intended role () and policies (both internally and from cognizant 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, as they directly relate to DETs, 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 basic interoperability) is out of scope for this document. It is left to cognizant authorities to determine these details along with policy for access. For the UAS use-case this is 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 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 . Other terms (DIME, Endorsement, etc.) are from , while others (RAA, HDA, etc.) are from .

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.

DIME Roles defines the Hierarchical Host Identity Tag (HHIT) and further specifies an instance of them used for UAS RID called DETs. 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 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. shows this breakdown.

DRIP Entity Tag Breakdown

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 () 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 owner of 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 manages the IPv6 prefix of 2001:30/28. 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 (). See for the RAA allocations. Values 0 (0x0000) through 3 (0x0003) MUST be reserved for the UAS RID Apex and SHOULD be used to endorse RAA delegations in Endorsements (). 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 allocation and is out of scope for this document.

Registered Assigning Authority (RAA) An RAA is a business or organization that runs a DIME to register HDAs (). Most are contemplated to be CAAs (using ), such as the Federal Aviation Authority (FAA), that then delegate HDAs to manage their National Air Space (NAS). This is does not preclude other entities to operate an RAA if the Apex allows it. 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 maintain a DNS zone minimally for discovering HIP RVS servers

All RAA's MUST have a 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. How a CAA handles their allocated values are out of scope of this document. Control of these values are expected to be claimed by their respective owner. How a claim is 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.

• Informational Note: A single entity may control more than one NAS (for example LU and BE being covered by Skeyes.be) and would manage two allocation spaces. How this is claimed and handled is out of scope for this document.

Experimental The RAA range of 16376 (0x3FF8) to 16383 (0x3FFF), eight (8) RAAs, is allocated to the DRIP working group itself as an experimental range. RAA 16376 is already "in use" with driptesting.org. The rest of the range (16377 to 16383) are reserved to be allocated by the DRIP experts to agencies or organizations that wish to test for a period of time.

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. This includes, but is not limited to UA, GCS, UAS Operators and UAS/UTM infrastructure (such as Supplemental Data Service Providers). It 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
• registration and access controlled lookup of DETs as a pseudo-anonymous 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. How this is done and scales to the potentially millions of customers are outside the scope of this document. 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 (), is comprised of a number of logical components that are depicted in . Any of these components could be delegated to other entities as a service both co-located or remote. 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 Registry/Name Server, when delegated, might be Extensional Provisioning Protocol (EPP) (due to Registry/Name Server requirements) while implementations co-locating these components might use an internal code library. These non-labeled interfaces are out of scope for this document.

DIME Logical Components

DRIP Provisioning Agent (DPA) The DPA performs the important task of vetting information coming from clients wishing to register and 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 DPA:

• MUST have a publicly accessible and discoverable HTTPS interface for clients to register through
• MUST use a provided interface from a DRIP Information Agent ()
• MUST use a provided interface from a Registry/Name Server ()

Specific details of the public HTTPS interface (such as advertisement) is out of scope for this document.

Registry & Name Server (NS) The Registry & Name Server component handles all the required DNS based requirements of the DIME to function. This includes the registration and maintenance of various DNS Resource Records used in public lookups. The Registry:

• MUST provide an interface (for example EPP) for management of DNS functions
• MUST provide a standard DNS query interface

The detailed specification of either interface is out of scope for this document. The Registry is the component that interfaces the DIME into the DNS hierarchy and thus operation SHOULD follow best common practices, specifically in security (such as running DNSSEC) as appropriate. Specific instruction for operating a Registry & Name Server is out of scope for this document. However the following references are presented as pointers to material that might be useful: TODO: add list of useful RFCs?

• Author Note: This may be very important here as we should not preclude a USS from running his own Name Server but they are not DNS experts and will need guidance or at least pointers to it to not mess it up. Such as SOA and NS formats to allow delegation if acting as an RAA.

DRIP Information Agent (DIA) & Registration Data Directory Service (RDDS) The DIA is the main component handling information ingress (via registration) and egress (via lookup) of the RDDS. The DIA:

• MUST have an access controlled interface for add/delete/update of information that MAY be publicly available
  • this interface definition is out of scope for this document
• MUST have an access controlled interface to query for information that MAY be publicly available
  • if this interface is publicly available it MUST use Registration Data Access Protocol (RDAP) (, and )
  • if this interface is not publicly available its specification is out of scope for this document

Certain information stored within the RDDS, due to policy, may be considered PII and MUST be protected from access using AAA (for example using XACML). See for more information. The interface between a DIA and an RDDS is out of scope for this document.

DET Registration Process The general process for a registering DET is as follows:

1. Verify inputs (such as Endorsement(s)) from registering client
2. DPA checks for collision of DET and HI
3. Populate Registry/Name Server with resource record(s)
4. Populate RDDS via DIA with PII and other info
5. Generate and return Endorsement(s)

Generically a DET can be used as an identifier for any client in UTM and SHOULD be registered to a DIME. For example a CAA may choose to use DETs for its Operators. A data model (such as what is specified in ) would be required to define all the information for registration for a given classification of client. Such specification beyond using DETs as a Session ID and/or Key ID (, and ) is out of scope for this document. In the following subsections an abbreviated form of seen below in uses co-located components to describe the flow of information. Each section gives specific example details for the components, interfaces and data elements. Each section has an associated appendix () containing DNS examples.

Example Registration Process o | * * +----o----+ (4) | | * * | | | * * | (3) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** ]]>

DET Registration Data Model The following is the general data model for DET registration data to be sent to the DPA from a client. This model is defined for and used by , and . any } utm_binding = ( utm_id: bstr .size 16, ; Operational Intent (UUIDv4) utm_source: tstr ; URI to USS with Operational Intent ) ]]>

UAS ID Type and UAS ID:

defined per ASTM . See for handling specific instructions during registration.

UAS Serial Number:

defined per . 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 ADD-UTM-REF and ASTM as a UUIDv4.

Self Endorsement:

defined per and . See for handling specific instructions during registration.

It is RECOMMENDED that the information above is signed over in some way to ensure integrity of the registration data. A recommended way to do this is with a JWT or CWT using the clients key. 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.

UAS ID Handling The uas_id_type field MUST be set to same UAS ID Type in the ASTM 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 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. When a DET is used a Session ID, the value of this first octet MUST be 0x01.

Self Endorsement The self_endorsement is included when a DET is used either as a Session ID (in uas_id) or for Authentication (in key_id). The value is verified by the DPA and its contents used to generate a Broadcast Endorsement for use in and put into DNS.

Service Tuple Five critical pieces of information are required to provide the services listed in that make a tuple. These are: UAS ID, UAS ID Type, UAS Serial Number, Key ID and UTM Assigned ID. The UAS ID, UAS ID Type and UAS Serial Number fields are mandatory and MUST NOT be null for entry as defined . This tuple encodes the services that the specific registration is being used. A few examples can be seen in the table below.

Service	UAS ID	UAS ID Type	UAS Serial Number	Key ID	UTM Assigned ID
DET Authentication	TEST3ABC	0x1	TEST3ABC	DET	-
DET Session ID	0x01 + DET	0x4	TEST3ABC	-	-
DET Session ID + Authentication	0x01 + DET	0x4	TEST3ABC	DET	-

As this document focuses on DETs exclusively the use of the Key ID using other cryptographic identifiers and how to distinguish between them (such as how UAS ID and UAS ID Type is used) is out of scope of this document.

DET Authentication For Authentication use of a DET, registration requires the following additional data elements: key_id, self_endorsement. MUST be followed.

DET Session ID For the registration of a DET as a Session ID the client is typically the UAS. The mechanisms of how the UAS generates a DET are out of scope for this document. For Session ID use of a DET, registration requires the following additional data elements: self_endorsement. Both and MUST be followed. Optionally a binding between a DET and a UTM Session ID can be made by providing the information of the UTM side using utm_id and utm_source. The support of this is based on CAA policy and is out of scope for this document.

DET Session ID & Authentication For Session ID & Authentication use of a DET, registration requires the following additional data elements: key_id, self_endorsement. Both and MUST be followed.

Differentiated Access Process Per 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 . Differentiated access, as a process, is a requirement for DIMEs as defined in by the combination of PRIV-1, PRIV-3, PRIV-4, REG-2 and REG-4. further elaborates on the concept by citing RDAP (from , and ) as a potential means of fulfilling this requirement. Typically the cognizant authority is the primary querant of private information from a DIME if a Session ID is reported (the case of the owner of the private information is ignored for the moment). This capability MAY be delegated to other parties at the authorities discretion (be it to a single user or many), thus requiring a flexible system to delegate, determine and revoke querent access rights for information. XACML MAY be a good technology choice for this flexibility. It is noted by the authors that as this system scales the problem becomes a, well known and tricky, key management problem. While recommendations for key management are useful they are not necessarily in scope for this document as best common practices around key management should already be mandated and enforced by the cognizant authorities in their existing systems. This document instead focuses on finding a balance for generic wide-spread interoperability between DIMEs with authorities and their existing systems in a Differentiated Access Process (DAP). A system where cognizant authorities would require individual credentials to each HDA is not scalable, nor practical. Any change in policy would require the authority to interact with every single HDA (active or inactive) to grant or revoke access; this would be tedious and prone to mistakes. A single credential for a given authority is also strongly NOT RECOMMENDED due to the security concerns it would entail if it leaked. A zero-trust model would be the most appropriate for a DAP; being highly flexible and robust. Most authorities however use "oracle" based systems with specific user credentials and the oracle knowing the access rights for a given user. This would require the DAP the have some standard mechanism to locate and query a given oracle for information on the querent to determine if access is granted. DRIP has no intention to develop a new "art" of key management, instead hoping to leverage existing systems and be flexible enough to adapt as new ones become popular.

DRIP in the Domain Name System Per all information classified as public is stored in the DNS to satisfy REG-1 from . 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 . This may be influenced by frequency of updates, size of the zone, and policies. Static UAS specific information that is publicly available MAY also be stored in DNS but is out of scope for this document.

• Author Note: proposal for a UAS RR that is a CBOR map of static UAS data elements (UAS ID, UAS Type, Self Description, etc.)

For DRIP, IANA has agreed to act as the Apex at least initially (see for more details). The delegation of civil aviation authorities to RAAs is already done per using their ISO 3166-1 Numeric Codes. Since these are public, any entity can stand up an RAA with that value. The Apex SHOULD be the root of trust in a Endorsement or certificate chain that provides validation of any of these specific RAAs, in the ISO RAA range, thus protecting against bad actors standing up fraudulent RAAs.

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 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. An addressing plan will need to be developed. 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 () for itself. Reverse lookups of these IPv6 addresses will translate the address into a domain name in the manner defined in . However, these lookups will query for, depending on what is required: HIP, HHIT, TLSA, URI, or PTR RRTypes.

Endorsements DRIP Endorsements are defined in a CDDL structure () 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 . As such the structures found in , 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 Type:

a 16-bit value used to hint at the content of the $$evidence group. Four special values (1 through 4) map to the SAM Type of the Authentication framing in , allowing the 16-bit value to be excluded from the Endorsement structure. See for more details.

Scope & Scope Extensions:

The scope section is more formally "the scope of validity of the endorsement". The scope can come in various forms but MUST always have 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 pairs 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 using the $$scope-ext socket group.

Evidence:

socket group containing a set claims. 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.

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 bytestring of values) rather than their CBOR encoding.

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 . 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 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 for the various servers in the UTM and particularly DIME environment and DANCE for EEs (e.g. ). 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 .

Alternative Certificate Encoding The CBOR Encoded X.509 Certificates (C509 Certificates) 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. C509 provides two approaches for encoding X.509:

1. An invertible CBOR re-encoding of DER encoded X.509 certificates , 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 A discussion between the authors of this document, DRIP AD and IANA was held during IETF 118. Those present were:

• Eric Vyncke (AD of DRIP WG)
• Bob Moskowitz
• Jim Ried (Author of this RFC)
• Adam Wiethuechter (Editor of this RFC)
• Kim Davies (IANA)

IANA agreed that they would be willing to manage the Apex for DRIP until the desired Apex manager, International Civil Aviation Organization (ICAO), is ready. This is expected to be in the next 5 years due to ICAO process. The hand-over to ICAO is TBD at that time but various options are available. Further discussion of the SLA required to RAAs by IANA is and other requirements to IANA are TBD.

IANA DRIP Registry

DRIP RAA Allocations This document requests a new registry for RAA Allocations under the DRIP registry group.

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 ). The following values/ranges are defined:

RAA Value(s)	Status	Allocation	Reference
0 - 3	Allocated	UAS RID (DRIP) Apex	This RFC ()
4 - 3999	Allocated	ISO 3166-1 Countries	This RFC ()
4000 - 16375	Reserved	N/A	N/A
16375 - 16383	Allocated	DRIP WG (Experimental Use)	This RFC ()

The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found as a CSV file here: TODO.

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 ) for values 0x0000 to 0xEFFF and First Come First Served (Section 4.4 of ) for the values 0xF000 to 0xFFFF. The following values are defined:

Value	Endorsement Type	Reference
0	Self-Endorsement	This RFC ()
1	Broadcast Endorsement	This RFC ()
2	Wrapper	This RFC ()
3	Manifest	This RFC ()
4	Frame	This RFC ()

To register an e-type the following MUST be provided in CDDL for review:

• Additions to scope group using $$scope-ext
• 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 ). 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	Name Server (NS)	This RFC
8	Registration Data Directory Service (RDDS)	This RFC
9	ISO 3166-1 Numeric Nation (INN)	This RFC
10 - 15	Reserved
16	Endpoint Entity (EE)
17	Issuer CA
18	Authentication CA
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

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

Security Considerations

Key Rollover & Federation During 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 Note: 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 , it is expecting that IDs for UAS are assigned by the UTM and are generally 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 is 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 This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References AX Enterprize, LLC AX Enterprize, LLC HTT Consulting The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. HTT Consulting AX Enterprize AX Enterprize Linköping University This document defines a transport mechanism between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. Either the Broadcast Remote ID (B-RID) messages, or alternatively, appropriate MAVLink Messages can be sent directly over UDP or via a more functional protocol using CoAP/CBOR for the Net-RID messaging. This is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure messaging Command-and-Control (C2) for is also described. Salesforce Two Sigma The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. HTT Consulting AX Enterprize, LLC The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. This PKI can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. ASTM International

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.

Resource Record Wire CDDL

Resource Record Text CDDL HHIT IN ( HHIT TYPE STATUS ABBREV [Endorsement(s)] ) ]]>

Type:

This field is two octets with values defined in . 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 .

Status:

This field is a single byte with values defined in . A HHIT can go through various states during its life-cycle in the ecosystem. It is helpful for a querant to understand the current status as a further requirement for verification.

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 .

Endorsements:

This field is a list of CBOR encoded Endorsements in e-type order. It MUST included at least one Broadcast Endorsement (). 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).

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 . For RAAs allocated in the ISO range , 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 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.

DETs as Fully Qualified Domain Names This appendix is informative.

• {hash}.{oga_id}.{hda}.{raa}.{prefix}.{apex}.

When building a DET FQDN it MUST must be built using the exploded (all padding present) form of the IPv6 address.

DRIP Endorsements for UAS This appendix is normative.

Self Endorsement

Self Endorsement CDDL

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 Binary

Self Endorsement CBOR

Broadcast Endorsement

Broadcast Endorsement CDDL

Defined by in a binary format to support Authentication over ASTM constrained links. Used in the DRIP Link format. A required output of registration to a DIME at any level. $$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 Binary

Broadcast Endorsement CBOR

Wrapper Endorsement

Wrapper Endorsement CDDL

Wrapper Endorsement CBOR

Wrapper Endorsement Binary

Manifest Endorsement

Manifest Endorsement CDDL

Manifest Endorsement CBOR

Manifest Endorsement Binary

Frame Endorsement

Frame Endorsement CDDL

Frame Endorsement CBOR

Frame Endorsement Binary

DNS Examples This appendix is informative.

Operator

Session ID

Child DIME