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 are through the existing DNS structure and methods by using FQDNs. A general overview of the interfaces required between involved components is described in this document with supporting documents giving technical specifications.

Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote ID (RID). Only very limited operational information can be Broadcast, but extended information is sometimes needed. The most essential element of information sent is the UAS ID itself, the unique key for lookup of extended information in relevant registries (see Figure 4 of ). While it is expected that registry functions will be integrated with UAS Service Supplier (USS) (Appendix A.2 of ), who will provide them is not yet determined in most, and is expected to vary between jurisdictions. However this evolves, the essential registry functions (including the management of identifiers) are expected to remain the same, so are specified herein. 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 in registries will be private. As discussed in Section 7 of , Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, and Audit (AAA) for registries 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, etc. As specific AAA requirements will vary by jurisdictional regulation, provider choices, customer demand, etc., they are left to specification in policies, which should be human readable to facilitate analysis and discussion, and machine readable to enable automated enforcement, using a language amenable to both (e.g., eXtensible Access Control Markup Language (XACML)). The intent of the access control requirements on registries 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. Mitigation of Denial of Service (DoS) attacks and refusal to allow database mass scraping would be based on those behaviors, not on identity or role of the party submitting the query per se, but querant identity information might be gathered (by security systems protecting DRIP implementations) on such misbehavior. Registration under DRIP is vital to manage the inevitable collisions in the hash portion of the DRIP Entity Tags (DETs). Forgery of the DETs is still possible, but including it as a part of a public registration mitigates this risk. This document creates the DRIP DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., 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.

Abstract Process and Reasoning In DRIP each entity (registry, operator, and aircraft) is expected to generate a full DRIP Entity ID on the local device their key is expected to be used. These are registered with a Public Information Registry within the hierarchy along with whatever data is required by the cognizant CAA and the registry. Any Personally Identifiable Information (PII) is stored in a Private Information Registry protected through industry practice AAA or stronger. In response, the entity will obtain an endorsement from the registry proving such registration. Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID type for their aircraft but could also generate a DET then encode it as a Serial Number. This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) could still use DRIP and most of its benefits. Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a registry to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for an aircraft profile to be displayed. Operators are registered with a number of registries or their regional RAA. This acts as a verification check when a user performs other registration operations; such as provisioning an aircraft with a new Session ID. It is an open question if an Operator registers to their CAA (the RAA) or multiple USS's (HDA's). PII of the Operator would vary based on the CAA they are under and the registry. Finally, aircraft that support using a DET would provision per flight to a USS, proposing a DET to the registry to generate a binding between the aircraft (Session ID, Serial Number, and Operational Intent), operator and registry. The aircraft then follows to meet various requirements from during a flight.

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 See for common DRIP terms and Section 2.2 of for additional terms used in this document. HDA:

• Hierarchial HIT Domain Authority. The 14 bit field identifying the HIT Domain Authority under a RAA.

HID:

• Hierarchy ID. The 28 bit field providing the HIT Hierarchy ID.

PII:

• Personally Identifiable Information. Any information a cognizant authority (such as a government agency) or a user requires differentiated access to obtain.

RAA:

• Registered Assigning Authority. The 14 bit field identifying the Hierarchical HIT Assigning Authority.

DIME Roles defines the DRIP Identity Management Entity (DIME) as an entity that vets Claims and/or Evidence from a registrant and delivers back Endorsements and/or Certificates in response. The DIME encompasses various logical components and can be classified to serve a number of different roles, which are detailed in the following subsections. The general hierarchy of these roles are illustrated in .

DIME Roles and Hierarchy

Apex The Apex is a special DIME role that holds the value of RAA=0 and HDA=0. It serves as the branch point from the larger DNS system in which HHITs are defined. The Apex generally has as prefix portions of the HHIT associated with it (such as 2001:0030/28) which are assigned by IANA from the non-routable special IPv6 address space for ORCHIDs (where HHITs are derived from). The Apex manages all delegations and allocations of the HHIT's RAA to various parties with NS records to redirect DNS queries to proper sub-branches.

Registered Assigning Authority (RAA) RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field (16,384 RAAs) of an HHIT). An RAA is a business or organization that manages a registry of HDAs (). Most are contemplated to be Civil Aviation Authorities (CAA), 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. For DRIP and the UAS use case ICAO will handle the registration of RAAs. Once ICAO accepts an RAA, it will assign a number and create a zone delegation under the <prefix>.hhit.arpa. DNS zone for the RAA. As HHITs may be used in many different domains, RAA should be allocated in blocks with consideration on the likely size of a particular usage. Alternatively, different prefixes can be used to separate different domains of use of HHITs. An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. It must maintain a DNS zone minimally for discovering HID RVS servers. All RAA's use an HDA value of 0 and have their RAA value delegated to them by the Root.

ICAO Registry of Manufacturers (IRM) An RAA-level DIME that hands out HDA values to participating Manufacturer's that hold an ICAO Manufacturer Code used in . To manage the large ICAO Manufacturer Code space (34 character set; 4 characters; 1,336,336 possible codes) a range of RAA values are set aside for the DRIP use case. These are the RAA values of 2 (0x0002) up to 96 (0x0060). This allows a single HDA for each Manufacturer Code. All IRM's have two reserved HDA values. 0 (0x0000) for itself in its role as an RAA and 1 (0x0001) if it wishes to offer HDA services.

Hierarchial HIT Domain Authority (HDA) An HDA may be an USS, ISP, or any third party that takes on the business to register the actual UAS entities that need DETs. This includes, but is not limited to UA, GCS, and Operators. It should also provide needed UAS services including those required for HIP-enabled devices (e.g. RVS). The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by an RAA. 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 should 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.

Manufacturers Registry of Aircraft (MRA) An HDA-level DIME run by a manufacturer of UAS systems that participate in Remote ID. Stores UAS Serial Numbers under a specific ICAO Manufacturer Code (assigned to the manufacturer by ICAO). A DET can be encoded into a Serial Number (see ) and this registry would hold a mapping from the Serial Number to the DET and its artifacts.

Remote ID Registries (RIDR) An HDA-level DIME that holds the binding between a UAS Session ID (for DRIP the DET) and the UA Serial Number. The Serial Number MUST have its access protected to allow only authorized parties to obtain. The Serial Number SHOULD be encrypted in a way only the authorized party can decrypt. As part of the UTM system they also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent. They may either be a direct logical part of a UAS Service Supplier (USS) or be a UTM wide service to USS's.

Role Abbreviation in DETs 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 in length. Spaces SHOULD NOT be used and be replaced with either underscores (_) or dashes (-). For RAAs the abbreviation is RECOMMENDED to be set to the ISO 3166 country code (either Alpha-2 or Alpha-3) for the CAA. If a DIME does not have an abbreviation or it can not be looked up then the receiver SHOULD use the 4-character hexadecimal encoding of the field it is missing.

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. For example:

• The Name Server component could be handled by a well-established DNS registrar/registry with the DRIP Provisioning Agent (DPA) () interfacing to them
  • Either the DPA or the Registry/Name Server interfaces to the DRIP Information Agent (DIA)
• The DPA, Registry, and Name Server may all be co-located in one implementation with an interface to a DIA offered by another organization from any one of the co-located components

Registry Hierarchy

DRIP Provisioning Agent (DPA) The DPA performs the important task of vetting information (such as the DRIP Endorsements) coming from clients wishing to register and then delegate (internally or externally) various items to other components in the DIME. A standard interface over HTTPS MUST be provided for clients to access with JSON or CBOR encoding of objects being sent to the DPA. This interface specification is out of scope for this document. There MUST be an interface from the DPA to a Registry () component which handles the DNS specific requirements of the DIME as defined by the Registry. There MAY also be interface from the DPA to a DRIP Information Agent () as defined by the DIA.

Registry The Registry component handles all the required DNS based requirements of the DIME to function for DRIP. This includes the registration and maintenance of various DNS Resource Records which use the DRIP FQDNs (). A standardized interface MUST be implemented for interactions with the DPA (). This interface MAY be over HTTPS using JSON/CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP) . The specifications of either of these interfaces is out of scope for this document. There MAY be interface from the Registry to a DRIP Information Agent () as defined by the DIA.

Name Server (NS) 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 as RAA. The interface of the Name Server to any component (nominally the Registry) in a DIME is out of scope as typically they are implementation specific.

DRIP Information Agent (DIA) The DIA is the main component handling requests for information from entities outside of the DIME. Typically this is when an Observer looks up a Session ID from an UA and gets pointed to the DIA via a SVR RR to obtain information not available via DNS. The information contained in the DIA is generally more oriented around the Operator of a given UAS and is thus classified as Personally Identifiable Information (PII). To protect the privacy of an Operator of the UAS this information is not publicly accessible and is only available behind policy driven differentiated access mechanisms. As an example the Serial Number, under the FAA, is classified as PII and can only be accessed by federal entities (such as the FAA themselves). For DRIP the Registration Data Access Protocol (RDAP) (, and ) is the selected protocol to provide policy driven differentiated access for queries of information. A standard interface over HTTPS MUST be provided for clients to access with JSON/CBOR encoding of objects being sent to the DIA. There MUST also be a standardized interface for the DPA or Registry to add, update or delete information into the DIA. Both of these interfaces are out of scope for this document. An interface defined by the Registration Data Directory Service (RDDS) () is also required as specified by the RDDS.

Registration Data Directory Service (RDDS) This is the primary information database for the DIA. An interface MUST be provided to the DIA but its specification is out of scope for this document.

Registration/Provisioning Process The general process for a registering party is as follows:

1. Verify input Endorsement(s) from registering party
2. Check for collision of DET and HI
3. Populate Registry/Name Server with required/optional resource records using the FQDN
4. Populate RDDS via DIA with PII and other info
5. Generate and return required/optional DRIP Endorsements

In the following subsections an abbreviated form of using co-located components is used to describe the flow of information. The data elements being transmitted between entities is marked accordingly in each figure for the specific examples.

Serial Number Serial Numbers are primarily registered to MRA's () by the Manufacturers. Could be also registered to CAA's (using their HDA functionality) as part of Operator registration or to USS's in their capacity as HDAs. In the later two cases no DNS RRs are made to protect the privacy of the registering parties. When the Serial Number is really an encoded DET the DET FQDN is used to point to HIP and CERT RRs rather than the Serial Number FQDN. Instead a CNAME is made between the Serial Number FQDN and the DET FQDN. The same can still happen if the manufacturer chooses to use their own Serial Number formatting (still within the specification of ) and create the CNAME back to a DET loaded into the unmanned aircraft.

Example DIME:MRA with Serial Number (DET) Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: MRA on UA (c) HIP RR, CERT RRs (d) UA Information ]]>

The unmanned aircraft, intending to use DRIP, generates a keypair, DET and Self-Endorsement: UA using the RAA and HDA values specified by the manufacturers DIME (running as an MRA). The DET is converted into a Serial Number (per ) or the manufacturer creates their own Serial Number. The Serial Number, UA information and the Self-Endorsement: UA are sent to the manufacturers DIME. The DIME validates the Self-Endorsement and checks for DET and HI collisions in the Name Server/DIA. A Broadcast Endorsement: DIME on UA is generated which is provisioned into the aircraft for use when using the Serial Number as its UAS ID. In the Name Server HIP RRs are created using the DET FQDN while a CNAME points the Serial Number FQDN to the DET FQDN.

• Note: is specific for a DET encoded Serial Number. The Endorsements in (a) and (b) as well as RRs in (c) would not be present for non-DET based Serial Numbers.

Additional UA Information has a set of valid item keys defined in . The items present for a given interaction is defined by future documents, local regulations and implementation specific capabilities.

Operator Provided either by USS or CAA run HDAs. Regulation might require interaction between them. An Operator can request that certain information normally generated and provisioned into DNS be omitted due to privacy concerns.

Example DIME:HDA with Operator (DET) Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Operator Information, Operator Self-Endorsement (b) Success Code, Generic Endorsement: HDA on Operator (c) HIP RR, CERT RRs (d) Operator Information ]]>

The Operator generates a keypair and DET as specified in along with a self-signed endorsement (Self-Endorsement: Operator). The RAA and HDA values used in the DET generation for the Operator are found by referencing their selected DIME of choice (in an HDA). The self-signed endorsement along with other relevant information (such as Operator PII) is sent to the DIME over a secure channel. The specification of this secure channel is out of scope for this document. The DIME cross checks any personally identifiable information as required. Self-Endorsement: Operator is verified. The DET and HI is searched in the DIME DIA and Name Server to confirm that no collisions occur. A new endorsement is generated (Generic Endorsement: DIME on Operator) and sent securely back to the Operator. Resource Records for the HI and Endorsements are added to the DIME Registry/Name Server. With the receipt of Generic Endorsement: DIME on Operator the registration of the Operator is complete.

• Note: (c) in MAY be requested by the Operator to be omitted due to PII concerns.

The definition of Operator Information is out of scope of this document and left to local regulations.

Session ID Session IDs are generally handled by HDAs, specifically RIDRs. In the UAS comprises of an unmanned aircraft and a Ground Control Station (GCS). Both parties are involved in the registration process.

Example DIME:RIDR with Session ID (DET) Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Mutual Endorsement: RIDR on GCS, Generic Endorsement: GCS on UA, Session ID Information (b) Success Code, Broadcast Endorsement: RIDR on UA, Generic Endorsement: RIDR on UAS (c) HIP RR, TLSA, RR, CERT RRs (d) Session ID Information ]]>

Through mechanisms not specified in this document the Operator should have methods (via the GCS) to instruct the unmanned aircraft onboard systems to generate a keypair, DET and Self-Endorsement: UA. The Self-Endorsement: UA is extracted by the Operator onto the GCS. The GCS is already pre-provisioned and registered to the DIME with its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement: RIDR on GCS. The GCS creates a new Generic Endorsement: GCS on UA and also creates Mutual Endorsement: RIDR on GCS. These new endorsements along with Session ID Information are sent to the DIME via a secure channel. The DIME validates all the endorsements and checks for DET and HI collisions in the Name Server/DIA using the proposed UA DET. A Broadcast Endorsement: DIME on UA is generated. An Generic Endorsement: RIDR on UAS is generated using the Generic Endorsement: GCS on UA. HIP and CERT RRs are provisioned into the Registry/Name server. Both endorsements are back to the GCS on a secure channel. The GCS then injects the Broadcast Endorsement: RIDR on UA securely into the unmanned aircraft. Endorsement: RIDR on GCS is securely stored by the GCS.

• Note: in the Session ID Information is expected to contain the Serial Number along with other PII specific information (such as UTM data) related to the Session ID.

Session ID Information is defined as the current model: Future standards or implementations MAY add other keys to this list (for local features and/or local regulation).

UA Based There may be some unmanned aircraft that have their own Internet connectivity allowing them to register a Session ID themselves without outside help from other devices such as a GCS. When such a system is in use its imperative that the Operator has some method to create the Generic Endorsement: Operator on UA to send to the DIME. The process and methods to perform this are out of scope for this document but MUST be done in a secure fashion.

UAS Based Most unmanned aircraft will not have their own Internet connectivity but will have a connection to a GCS. Typically a GCS is an application on a user device (such as smartphone) that allow the user to fly their aircraft. For the Session ID registration the DIME MUST be provided with an Generic Endorsement: GCS on UA which implies there is some mechanism extracting and inserting information from the unmanned aircraft to the GCS. These methods MUST be secure but are out of scope for this document. With this system it is also possible to have the GCS generate the DET based Session ID and insert it securely into the unmanned aircraft after registration is done. This is NOT RECOMMENDED as this invalidates the objective of the asymmetric cryptography in the underlying DET as the private key MAY get in the possession of another entity other than the unmanned aircraft. See for more details.

Child DIME Handled by the Apex and RAA's. This is an endpoint that handles dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to Apex and HDAs to RAAs) in the hierarchy.

Example DIME:RAA with DIME:HDA Registration o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Self-Endorsement: HDA, HDA Information or Generic Endorsement: old HDA, new HDA (b) Success Code, Broadcast Endorsement: RAA on HDA (c) HIP RR, CERT RRs (d) HDA Information ]]>

It should be noted that this endpoint DOES NOT hand out dynamically RAA/HDA values to systems that hit the endpoint. This is done out-of-band through processes specified by local regulations and performed by cognizant authorities. The endpoint MUST NOT accept queries it is not previously informed of being expected via mechanisms not defined in this document. It is OPTIONAL to implement this endpoint. This MAY be used to handle lower-level DIME key roll-over.

Differentiated Access Process 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 BCPs 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 and 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 The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone. The HDA SHOULD provide DNS service for its zone and provide the DET detail response. DNSSEC is strongly recommended (especially for RAA-level and higher zones). Frequency of updates, size of the zone, and registry policy may impact its use. Per all public information is stored in the DNS to satisfy REG-1 from . CERT RRs () contain public Endorsements or X.509 Certificate relevant to a given Session ID. SVR RRs () point an Observer to a service to obtain further information if they have and can prove duly constituted authority. The REQUIRED mechanism is to place any information into ip6.arpa sub-zones. This zone typically contains PTR RRs, however there is no mandate that this is the only RR allowed in the zone. For DRIP this means that the HIP, CERT and SVR RRs MUST be added and use the nibble-reversed DET. The TLSA RR is RECOMMENDED for other uses cases where DTLS is used (such as in Network RID). For DRIP, the prefix 2001:0030/28 is slated for DETs being used in UAS as defined in . Other prefixes may be allocated by IANA in future for different use cases that do not fit cleanly into an existing prefix.

DRIP Fully Qualified Domain Names

DRIP Entity Tag The DET can be translated to the following FQDN form:

• {hash}.{oga_id}.{hda}.{raa}.{prefix}.hhit.arpa.

When building a DET FQDN the following two things must be done:

1. The RAA, HDA and OGA ID values MUST be converted from hexadecimal to decimal form.
2. The FQDN must be built using the exploded (all padding present) form of the IPv6 address.

Below is an example:

• Note: any of the fields in the FQDN could be CNAME'd to more human readable interpretations. For example the DET FQDN 204.2001003.hhit.arpa. may have a CNAME to uas.faa.gov; if RAA 204 was delegated to the FAA.

Serial Number Serial Number pose a unique problem. If we explicitly only allow HHITs be under the hhit.arpa. domain structure how do we standardize the lookup of Serial Numbers? Perhaps to look up Serial Numbers one must go to a different tree like mfr.icao.int.? We can have CNAMEs in MRAs for this but they probably need the same TLD (hhit.arpa.) to be found properly and these are clearly not HHITs. Serial Numbers MAY be a direct encoding of a DET (as defined in Section 4.2 of ). A Serial Number MAY also be a simple linking to a DET using a CNAME. DNAMEs (or PTRs) could be used to redirect a Serial Number that is not part of an public MRA but is instead registered by the operator to their HDA. The operator in this scenario MAY generate a DET for the Serial Number themselves - also stored in the HDA. The mapping of the Serial Number to this 'private' DET MUST NOT be made public.

Supported DNS Records

HIP All DIMEs MUST use HIP RR as the primary public source of DET HIs. DIMEs have their own DET associated with them and their respective name server will hold a HIP RR that is pointed to by their DET FQDN. MRA () and RIDR () DIMEs will also have HIP RRs for their registered parties (aircraft and operators respectfully).

TLSA This RR, , is mainly used to support DTLS deployments where the DET is used (e.g. Network RID and the wider UTM system). The HI is encoded using the SubjectPublicKeyInfo selector. DANE is for servers, DANCE is for clients. The TLSA RR MAY be used in place of the HIP RR, where to primary need of the DET HI is for DTLS authentication. This DNS server side optimization is for where the overhead of both RR is onerous. Thus all clients that work with the HIP RR SHOULD be able to able to extract the HI from the TLSA RR.

CERT Endorsements MAY be placed into DNS in the CERT RRs . Endorsements will be stored in Certificate Type OID Private (value 254) with a base OID of 1.3.6.1.4.1.6715.2 and further classified by the Endorsement/Certificate Type and then Entities involved.

Endorsement Type	OID Value
Self-Endorsement	1
Generic Endorsement	2
Concise Endorsement	3
Mutual Endorsement	4
Link Endorsement	5
Broadcast Endorsement	6

Entity Type	OID Value
Unmanned Aircraft (UA)	1
Ground Control Station (GCS)	2
Operator (OP)	3
HDA	4
RAA	5
Root	6

As an example the following OID: 1.3.6.1.4.1.6715.2.6.4.1 would decompose into: the base OID (1.3.6.1.4.1.6715.2), the Endorsement Type (6: Broadcast Endorsement) and then the parties involved (4: HDA, 1: UA) Certificate Type X.509 as per PKIX (value 1) MAY be used to store X.509 certificates as discussed in (Appendix B).

• Editor Note: This OID is an initial allocation under the IANA Enterprise Number OID. It is expect that a general OID will be allocated at some point.

SVR The SVR RR for DRIP always is populated at the "local" registry level. That is an HDA's DNS would hold the SVR RR that points to that HDAs private registry for all data it manages. This data includes data being stored on its children. The best example of this is RIDR () would have a SVR RR that points to a database that contains any extra information of a Session ID it has registered. Another example is the MRA () has a SVR RR pointing to where the metadata of a UA registered in the MRA can be located. In all cases the server being pointed to MUST be protected using AAA, such as using RDAP.

Endorsements Under DRIP Endorsements are defined in a CDDL structure that can be encoded to CBOR, JSON or have their keys removed and be sent as a binary blob. When the latter is used very specific forms are defined with naming conventions to know the data fields and their lengths for parsing. The first subsection defines the structure of an Endorsement while the remain subsections define specific forms that are commonly used. The binary forms of the subsections can be found in .

• 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. Specific use-case SHOULD add new keys for each section (if required) and define the valid keys and encoding forms for their use-case.

Endorsement Structure

Endorsement CDDL

Identity The identity section is 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 (an HHIT), and can include more explicit data such as the public key (an HI). Other keys can be provided and MUST be defined in their specific Endorsement. The length of the hi can be determined when using hhit or hi by decoding the provided IPv6 address. The prefix will inform of the ORCHID construction being used, which informs the locations of the OGA ID in the address. The OGA ID will then inform the user of the key algorithm selected which has the key length defined.

Evidence The evidence section contain a byte string of evidence. Specific content of evidence (such as subfields, length and ordering) is defined in specific Endorsement structures.

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

Signature The signature section contain the signature data for the endorsement. The signature itself MUST be provided under the sig key. Other forms or data elements could also be present in the signature section if specified in a specific endorsement. Signatures MUST be generated using the preceding sections in their binary forms (i.e. no keys).

Self-Endorsement (SE-x)

Self-Endorsement CDDL Structure

In a Self-Endorsement the identity is a HHIT/DET and the evidence is the associate HI. The HI could be removed, resulting in an "empty" Endorsement, when obtaining the HI via other means (such as DNS) is guaranteed. This behavior is NOT RECOMMENDED as the data being signed would be very short.

Generic Endorsement (GE-x.y)

Endorsement CDDL Structure

An endorsement used to sign over evidence that is being endorsed. Typically the evidence is filled with a byte string of a Self-Endorsement () of another party.

Concise Endorsement (CE-x.y)

Concise Endorsement CDDL Structure

An endorsement signing over only the HHIT/DET of Y (as evidence) and the HHIT/DET of X (as identity). In constrained environments and when there is the guarantee of being able to lookup the HHITs/DETs to obtain HIs this endorsement can be used.

Mutual Endorsement (ME-x.y)

Mutual Endorsement CDDL Structure

An endorsement that perform a sign over an existing Generic Endorsement (as a byte string of evidence) where the signer is the second party of the embedded endorsement. The HHIT/DET of party Y is used as the identity.

Link Endorsement (LE-x.y)

Link Endorsement CDDL Structure

An endorsement that performs a sign over an existing Concise Endorsement (in byte string form for evidence) where the signer is the second party of the embedded endorsement. The HHIT/DET of party Y is used as the identity.

Broadcast Endorsement (BE-x.y)

Broadcast Endorsement CDDL Structure

This endorsement is required by DRIP Authentication Formats & Protocols for Broadcast RID () to satisfy GEN-1 and GEN-3 and is sent in its binary form (). The evidence is a concatenated byte string of the HHIT/DET of Y and the HI of Y in HHIT/HI order. The identity is the HHIT/DET of X.

Abbreviations & File Naming Conventions The names of endorsements can become quite long and tedious to write out. As such this section provides a guide to a somewhat standardized way they are written in text.

In Text Abbreviation In a long form the name of a particular endorsement can be written as follows:

• Self-Endorsement: Unmanned Aircraft
• Generic Endorsement: Operator on Aircraft or Generic Endorsement: Operator, Aircraft

When multiple entities are listed they can be separated by either on or by ,. These long forms can be shortened:

• SE(Unmanned Aircraft) or SE-ua
• GE(Operator, Unmanned Aircraft) or GE-op.ua

Typical abbreviations for the entity can be used such as Unmanned Aircraft being shorthanded to ua.

File Naming For file naming of various endorsements a similar format to the short form is used:

• se-{hash of entity}
• ge-{hash of entity x}_{hash of entity y}

Some examples of file names:

• se-79d8a404d48f2ef9.cert
• ge-120b8f25b198c1e1_79d8a404d48f2ef9.cert

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 covered in this document will also have certificates to create and manage the necessary PKI structure. Any Certificate Authority (CA) supporting DRIP entities SHOULD adhere to the ICAO's International Aviation Trust Framework (IATF) Certificate Policy [ICAO-IATF-CP-draft]. The CA(s) supporting this CP MUST either be a part of the IATF Bridge PKI or part of the IATF CA Trust List. EEs may use their X.509 certificates, rather than their rawPublicKey (i.e. HI) in authentication protocols (as not all may support rawPublicKey identities). Some EE HI may not be 'worth' supporting the overhead of X.509. 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 not AfterDate will 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. 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. This not only generally improves certificate lookups, but also enables use of DANE for the various servers in the UTM and particularly DRIP registry environment and DANCE for EEs (e.g. ). All DRIP certificates MUST be available via RDAP. LDAP/OCSP access for other UTM and ICAO uses SHOULD also be provided.

Certificate Management (mostly TBD still) 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. 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. Details of this are left out, as there are a number of approaches and further research and experience will be needed.

Examples TBD

Alternative Certificate Encoding (CBOR encoded certs here. TBD)

IANA Considerations

IANA DRIP Registry

DRIP Endorsement Subregistries This document requests a new subregistries for Endorsement Type and Entity Type under the DRIP registry.

DRIP Endorsement Type:

This 8-bit valued subregistry is for Endorsement Types to be used in OID's for CERT Resource Records. Future additions to this subregistry are to be made through Expert Review (Section 4.5 of ). The following values are defined:

Endorsement Type	Value
Self-Endorsement	1
Generic Endorsement	2
Concise Endorsement	3
Mutual Endorsement	4
Link Endorsement	5
Broadcast Endorsement	6

DRIP Entity Type:

This 8-bit valued subregistry is for Entity Types to be used in OID's for CERT Resource Records. Future additions to this subregistry are to be made through Expert Review (Section 4.5 of ). The following values are defined:

Entity Type	Value
Unmanned Aircraft (UA)	1
Ground Control Station (GCS)	2
Operator (OP)	3
HDA	4
RAA	5
Root	6

Aircraft Information Subregistry This document requests a new subregistry for aircraft information fields under the DRIP registry.

Aircraft Information Fields:

list of acceptable keys to be used in UA Information during a UA registration to a DIME. Future additions to this subregistry are to be made through Expert Review (Section 4.5 of ). The following values are defined:

Key Name	Type	Description
length	float	length, in millimeters
width	float	width, in millimeters
height	float	height, in millimeters
constructionMaterial	tstr	materials, comma separated if multiple
color	tstr	colors, comma separated if multiple
serial	tstr	ANSI CTA 2063-A Serial Number
manufacturer	tstr	manufacturer name
make	tstr	aircraft make
model	tstr	aircraft model
dryWeight	float	weight of aircraft with no payloads
numRotors	int	Number of rotators
propLength	float	Length of props, in centimeters
numBatteries	int
batteryCapacity	float	in milliampere hours
batteryWeight	float	in kilograms
batteryVoltage	float	in volts
batteryChemistry	tstr
maxTakeOffWeight	float	in kilograms
maxPayloadWeight	float	in kilograms
maxFlightTime	float	in minutes
minOperatingTemp	float	in Celsius
maxOperatingTemp	float	in Celsius
ipRating	tstr	standard IP rating
engineType	tstr
fuelType	tstr
fuelCapacity	float	in liters
previousSerial	tstr	legacy serial number(s)

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. At time of writing this is signing over the new key with the previous key in a secure fashion and it being validated by others before changing any links (in DRIPs case the NS RRs in the parent registry). 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 of the DET to have different identities could also allow for a single registry to be "federated" across them if they share the same HID value. This method of deployment has not been thoroughly studied at this time. An endpoint such as in is a possible place to have these functions.

DET Generation 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 registry. The method for discovering a registry's RAA and HDA is out of scope here. This allows for the device to generate an DET to send to the registry to be accepted (thus generating the required Self-Endorsement) or denied.

Option 2:

• The entity sends to the registry its HI for it to be hashed and result in the DET. The registry 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.

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 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. AX Enterprize AX Enterprize HTT Consulting Intel Linköping University This document describes an architecture for protocols and services to support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus UAS RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document (RFC9153). HTT Consulting AX Enterprize AX Enterprize Linköping University This document describes the use of Hierarchical Host Identity Tags (HHITs) as a self-asserting and thereby trustable Identifier for use as the UAS Remote ID. HHITs include explicit hierarchy to provide Registrar discovery for 3rd-party ID attestation. 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. 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 Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [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 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. This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205. 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. 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. AX Enterprize, LLC AX Enterprize, LLC HTT Consulting This document describes how to add trust into the Broadcast Remote ID (RID) specification discussed in the DRIP Architecture; first trust in the RID ownership and second in the source of the RID messages. It defines message types and associated formats (sent within the Authentication Message) that can be used to authenticate past messages sent by an unmanned aircraft (UA) and provide proof of UA trustworthiness even in the absence of Internet connectivity at the receiving node. HTT Consulting AX Enterprize AX Enterprize Linköping University This document defines a transport mechanism for Unmanned Aircraft System (UAS) Network Remote ID (Net-RID). The Broadcast Remote ID (B-RID) 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 Valimail 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.

Binary Endorsements

Self-Endorsement (SE-x)

Binary Self-Endorsement (Length: 120-bytes)

Generic Endorsement (GE-x.y)

Binary Generic Endorsement (Length: 240-bytes)

Concise Endorsement (CE-x.y)

Binary Concise Endorsement (Length: 104-bytes)

Mutual Endorsement (ME-x.y)

Binary Mutual Endorsement (Length: 328-bytes

Link Endorsement (LE-x.y)

DRIP Link Endorsement (Length: 192-bytes)

Broadcast Endorsement (BE-x.y)

DRIP Broadcast Endorsement (Length: 136-bytes)