]> AX Enterprize, LLC

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

HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

Internet drip Working Group Internet-Draft This document standardizes usage of Drone Remote Identification Protocol (DRIP) Entity Tags (DETs) as identifiers to enable trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems (UAS) in Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). DETs can serve as Session IDs for privacy, Authentication Key IDs for accountability, and encryption key IDs for confidentiality.

Introduction

Purpose This document provides to stakeholders in a National Airspace System (NAS), such as a Civil Aviation Authority (CAA) and its constituents, a point of entry into a set of relevant standards. These standards provide guidance to enable trustworthy Air Domain Awareness (ADA) primarily via cooperative technologies. Such technologies can include, but are not limited to, Unmanned Aircraft (UA) Systems (UAS) Remote Identification (RID), UAS Traffic Management (UTM) and Advanced Air Mobility (AAM). This document specifies an interoperable manner of achieving the stated objectives in an international context to be used by CAAs in a relevant Means of Compliance (MOC). One such MOC is ASTM for UAS RID to comply with the United States (US) CAA regulations. A CAA MAY override any technical specification in this document but MUST, if claiming compliance with this document, provide the reason and an alternative specification satisfying the same objective.

Background provides comprehensive background on the UAS RID use-case and the UTM/AAM context. Trustworthiness revolves around identification and authentication. defines the Drone Remote Identification Protocol (DRIP) Entity Tag (DET), a trustable identifier backed by asymmetric cryptography. standardizes authentication of DETs and associated information using strong cryptography suited for constrained mobile wireless links (typical of Broadcast RID). Broadcast and Network RID are defined by ASTM which designates the International Civil Aviation Organization (ICAO) to maintain code-points for Specific Session ID Types and Specific Authentication Methods (SAMs) . ICAO includes DETs as a Specific Session ID Type and lists the four DRIP SAMs. DETs generated by registrants (typically a UAS Operator or UAS) are merely proposed until they are registered within the hierarchy consisting of at least two levels above the leaf DET: Registered Assigning Authority (RAA) and Hierarchial Host Identity Tag (HHIT) Domain Authority (HDA). The registry system, made up of DRIP Identity Management Entities (DIMEs) acting as either RAAs or HDAs, ensures uniqueness within the hierarchy, endorses inclusion through X.509 certificates, and provides access to public and private information associated with a DET registration. Public information is served using the Domain Name System (DNS) and is specified in . Private information, such as Personally Identifiable Information (PII), is served using the Registration Data Access Protocol (RDAP, ) and protected through policy based differentiated access. This document specifies fundamental registration processes and interactions surrounding the Private Information Registry function defined in the DRIP Architecture ().

Scope Participating entities are assumed in this document to be in compliance with relevant existing UAS standards such as ASTM , and . This document governs use of a DET in the following cases:

1. An entity that uses a Session ID (some participating entities, e.g. HDAs, may not need Session IDs), MUST use a DET for that Session ID.
2. An entity that participates in DRIP interactions (even if not needing a Session ID), MUST use a DET for the DRIP public authentication key ID in those interactions.
3. An entity that requires a strongly cryptographically verifiable IP compatible identifier, MAY use a DET for any other legal purpose.
4. An entity SHOULD NOT use a DET as a locator in physical or logical space (e.g. as a globally routable IPv6 address outside of an overlay network), as deconflation is intended, see .

The archetypal case is a UAS for which the DET serves as both the UAS ID (first case above) and the Authentication Key ID (second case).

• Author Note: narrow context for at least first bullet above.

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 terms (PII, USS, etc.) defined in , and . For convenience of the reader, some of the major definitions are restated here.

DRIP Identity Management Entity (DIME):

Originally defined in and expanded technically in . An entity providing registrar and registry services specifically for DETs. They can act as either an Registered Assigning Authority (RAA) or Hierarchial Host Identity Tag (HHIT) Domain Authority (HDA).

Web Token:

In the context of this specification; a Web Token can be either a Concise Binary Object Representation (CBOR, ) Web Token (CWT, ) or JavaScript Object Notation (JSON, ) Web Token (JWT, ).

Interactions & Responsibilities This section outlines the various entity roles in the ecosystem. For each, it summarizes motivations for participating in that DRIP role, as well as the interactions and responsibilities they have in doing so. All entity roles, except as otherwise noted, MUST register a DET with a parent entity in the corresponding parental role (e.g. an HDA must register with an RAA), as per , and MUST use it subsequently in all DRIP interactions requiring an entity ID.

UAS Observers An Observer is typically an individual who has a device capable of wirelessly receiving Broadcast RID whether it be an opportunistic passerby with a local-only (i.e. non-Internet connected) smartphone application or a widely deployed sensing system with various IP-based back-hauls. Each has their own motivations for detecting a UAS in their area and querying for additional information. Typically in DRIP, Observers are expected to use DNS (when able) to obtain at least the public keys of unknown DETs and use it to validate signatures found in ASTM Authentication Messages. Some Observers may be granted, by cognizant authorities, authorization to perform more detailed queries of further information, that is considered private (as not explicitly classified as public, placed in DNS, and/or transmitted in cleartext in Broadcast RID).

• Author Note: Broadcast RID here can be dropped or substituted for some phrase comparing Observers to a sensor head, but distinct from a Display-only Observer. If that makes sense and if it is a good distinction to have? One could say Display Applications are in a way Observers (albeit very far removed from the field in most cases where the term is used). Unless we make them their own class of users that could use DETs (and for what?)

All Observers supporting DRIP:

• MUST adhere to relevant details of with regards to receive processing of DRIP SAMs.
  • Processing of SAMs MAY be deferred or outsourced to a dedicated system.
• RECOMMEND display all DETs following or as described in .

• Author Note: as justification for "processing MAY be deferred": Intention here was to allow for Observers not needing to fully process data if desired and push said processing to SDSPs. An example is a slim Finder concept that does no parsing of RID data, just extraction out of transport framing.

Observers authorized by cognizant authorities to access any private (in addition to all public) information recorded as part of the registration process also:

• MUST support RDAP authentication/authorization mechanisms allowed by the cognizant authority.
  • Those RECOMMENDED for global harmonization are identified in .
• MUST register to authentication systems as required by the cognizant authority.
  • A DIME MAY be used as part of an authentication system.

UAS Operators UAS Operators is used herein as a catch-all term for several more specific UAS related roles: Remote Pilot, Pilot In Command (PIC), party (typically an organization) to whom or which the UAS is registered with the cognizant CAA, etc. DRIP does not attempt to clarify the definition of Operator to match any specific CAA, instead using the ambiguity to group these roles based on their similar DRIP interactions. A UAS Operator's desire to use DETs can be any number of the following operational factors:

• Confidentiality of flights through Session IDs.
• Privacy of Remote Pilots by encrypting their Ground Control Station (GCS) position.
  • This option may be constrained by their jurisdiction's RID regulations.
• Reputation of their UAS based on observation and reports of behavior supported by Authentication.

To participate a UAS Operator SHOULD use a DET, registered either with an RAA or HDA, as part of any interactions in DRIP, such as registering a UAS Session ID for their UA. A UAS Operator MAY use another cryptographic scheme for interactions but it MUST be asymmetric with their public key accessible to all domain participants via a standardized method for the cryptographic purpose of signature verification.

UAS Manufacturers While UAS Manufactures do not have a direct requirement for DRIP, they typically wish to maintain good reputation of their brands and are often driven by market forces. Such forces include requirements and preferences of both UAS Observers and Operators. This document assumes a UAS Manufacturer is already in compliance with ASTM . Thus those that wish to support DRIP also:

• MUST provide a mechanism, typically through a GCS, to generate and register a DET for use as either a Session ID, Authentication Key ID or both.
  • MUST bind DET to both UAS Serial Number and Operator. Binding MAY be indirect if system can verify Serial Number already registered to Operator.
  • SHOULD be issued in a manner that keeps private key ONLY ever on UA, does not expose it to GCS etc., but MAY be done in manner that exposes it to GCS or Operator if necessary.
  • SHOULD allow user selection of a parent DIME (typically HDA) using a URI, Hierarchy ID (HID) value, or both
  • MAY support registering multiple DETs in a batch transaction
• SHOULD provide a mechanism to enable, during registration, subsequent encryption of selected fields (e.g. pilot/GCS location), only if the CAA allows it.
• MUST follow as it relates to transmission of SAMs, when using DET as an Authentication Key ID
• MUST, in the Basic ID Message, set the UAS ID Type to Specific Session ID, Specific Session ID Type to DRIP Entity ID, and encode the DET in network byte order, when using DET as a UAS Session ID
• MAY use a DET, following , as a UAS Serial Number
  • It is expected that the UAS Manufacturer runs their own HDA, under which these DETs are registered

HDA Operators In the UTM context, it is expected that the HDA function will be provided by a UAS Service Supplier (USS) to its clients (e.g. UAS Operators). This can be in-house or out-sourced to a service bureau more specialized in cryptographically verifiable identifiers usable to access data and systems on networks. Outside the UTM context, an HDA can be a stand-alone provider to any registrant desiring a DET, or more generally HHIT. Being associated with a USS has some operational benefits:

• Ease for UAS Operators to use both Session IDs and UTM together
• Binding between the DET and Operational Intent
  • Enables safer use of encryption
  • Ability to keep DET private until just before an operation goes active

An HDA Operator:

• MUST register, with its parent RAA, one or more DETs, and use it or them in DRIP interactions
• MUST implement interfaces and functions described in
• MUST maintain DET registrations with relevant PII as required by their jurisdiction
• MUST fulfill the requirements of their jurisdiction
• SHOULD NOT provide to clients the ability to enable encryption of data elements considered PII, especially in Broadcast RID

As part of a USS an HDA Operator also:

• MAY provide encryption ID services, if allowed by jurisdiction
• MAY have its registration interfaces () be integrated into relevant USS interfaces and functions
• SHOULD defer the publishing of a client DET in DNS when it is bound with an Operational Intent until it is "active"
  • Methods to sync an Operational Intent in a USS state and DET state in HDA are out of scope for this document

RAA Operators In the context of this document, RAA Operators are typically CAAs or other cognizant authorities of a Nation State. Each Nation State is allocated four RAA values that are used at their discretion. To obtain these allocations, a Nation State contacts the Apex operator for the UAS or other applicable hierarchy, currently IANA on behalf of ICAO, requesting their provisioning providing any details required by the Apex Operator to configure domain delegations. Each RAA has the responsibility to delegate HDAs under them. Allocation methods of HDA values are at the discretion of the RAA Operator and their policies. Any requirements to operate under an RAA, beyond those as defined in this document to operate as an HDA, are out of scope for this document. An RAA Operator:

• MUST obtain an RAA value(s) from the Apex Operator and provide content for NS RRType(s), see
• MUST register, with its parent (if any), one or more DETs, and use it or them in DRIP interactions
• MUST implement interfaces and functions described in
• MUST maintain DET registrations with relevant PII as required by their jurisdiction
• MUST provide requirements for prospective HDA Operators, and SHOULD do so publicly via an easily located web site
• MUST ensure HDA Operator compliance with this specification

• Author Note: subsection or appendix on a potential RAA scheme for CAA? i.e. 1x MIL, 1x GOV, 1x COMMERCIAL, 1x SPARE with some example guidance on HDA allocation?

Apex Operators The Apex role is the administration root and the domain apex for a specific IPv6 prefix which are typically associated with an industry sector (i.e. DETs being for aviation). This translates to the technical tasking of delegating RAA values and maintaining the reverse DNS zone associated with the allocated IPv6 prefix which contain the DNS delegations to RAAs. An Apex in its capacity as the administration root MAY endorse the required RAA delegation in the hierarchy. Currently IANA performs the functions of RAA delegation (with no endorsement) and DNS zone maintenance for the DET prefix. This is largely a custodial task as critical portions of the RAA range, with regards to aviation, are already reserved or allocated with the rest of the range unassigned. In the context of aviation pre-allocated RAAs to CAAs are currently expected to mutually cross-certify as specified in .

Requirements for DIME Operation The requirements below apply to both RAA and HDA Operators with a focus on how HDA Operators provide registration and related services for their clients (i.e. UAS Operators and their UAS). All data models are represented in this document using the Concise Data Definition Language (CDDL, ) using the prelude defined in as well as an additional DRIP-specific prelude defined in .

Common UAS RID Data Model A common data model is specified by DRIP for various UAS RID elements typically transmitted over ASTM . The field names and their general typing of are borrowed from the ASTM data dictionary (Table 1 and Table 2). See that document for additional context and background information on aviation application-specific interpretation of the field semantics. The contents of this model are considered opaque to DRIP. The model is an expansion upon the BRID RRType model, which only contained static data, defined in .

Common UAS RID CDDL utc, ? uas_type => 0..15, ? uas_ids => [ + [ id_type: 0..15, uas_id: uas-id ] ], ? ua_status => 0..15, ? ua_position => [ lla: position, barometric_altitude: number / null ], ? ua_bearing => uint, ? ua_speed => [ vertical: number / null, horizontal: number / null ], ? ua_height => [ agl: bool, height: number ], ? accuracy => [ vertical: 0..15, horizontal: 0..15, altitude: 0..15, barometric: 0..15, timestamp: 0..15 ], ? auth => [ + [ auth_type: 0..15, data: auth-data ] ], ? self_id => [ desc_type: 0..255, desc: tstr .size 23 ], ? operator_position => position, ? classification => [ region: 0..8, category: 0..15, class: 0..15 ], ? area => [ count: 1..255, radius: number, floor: number, ceiling: number ], ? operator_id => [ operator_type: 0..255, operator_id: tstr .size 20 ], ? compliance => [+ uint] } ]]>

The mapping between JSON keys (as strings) and CBOR keys (as unsigned integers) for are defined in .

• Author Note: do we specify the enumeration for compliance in this document? Is it an IANA registry?

Registration This section defines the interaction model, data models and methods for registration of a DET into a DIME for global interoperability. Standardization of additional methods and data models to register to a DIME (DETs or otherwise) is out of scope for this document.

Disclaimer DRIP does NOT provide protection against incorrect (e.g. fraudulent) data entered during registration or asserted subsequently. DRIP does protect against alteration (intentional or unintentional) of data subsequent to its assertion by the cryptographic signer. The signer might be the proximate sender (e.g. UA transmitting Broadcast RID) or might be an attestor far away and long ago (e.g. root Certificate Authority). It is the duty of the operator of each DIME, or the party on whose behalf the DIME is being operated, to validate the registration data. The RAA (e.g. CAA) SHOULD provide services to obtain this goal, see .

Interaction Model Registration of DETs uses the interaction model shown in .

Simplified DET Registration Z-Diagram | | | (3) VALID_INPUT? |<-------FAIL-------| | | (4) DUPE_HI? |<-------FAIL-------| | | (5) DUPE_DET? |<-------FAIL-------| | | (6) GEN_CERTS | | (7) UPDATE_DATABASE | | (8) UPDATE_NS |<----(9) OUTPUT----| ]]>

(0) GEN_DET/HI:

The registrant that plans to use the identity and its cryptographic properties SHOULD generate the asymmetric key-pair of their choosing and MUST protect the private key with Best Current Practices. The registrant MAY derive the corresponding DET. How the registrant obtains the desired HID for DET generation is out of scope for this document.

(1) GEN_CSR:

The registrant MUST generate a Certificate Signing Request (CSR) for their HI/DET. See for more details.

(2) INPUT:

The registrant MUST format and send the required information for a given service registration as specified by the DIME using .

(3) VALID_INPUT?:

The DIME, upon receipt of service registration inputs, MUST validate the input data. This may be simply performing syntax checks to ensure the data is properly formatted all the way to full semantic validation (see ). Signed data MUST have their signatures verified before further processing. Failure of input validation SHOULD returns errors to the registrant.

(4) DUPE_HI?:

The DIME MUST check that the proposed HI is not a already in use within the specified HID scope. The registrant SHOULD be notified with an error if duplication is detected.

(5) DUPE_DET?:

The DIME MUST check that the proposed DET, derived from the HI, is not a already in use within the specified HID scope. If the registrant proposed a DET with HID outside that of the DIME, it MUST be rejected. If the registrant only provided the HI, the DIME MUST generate the DET using the HID for which that DIME is authoritative. The registrant SHOULD be notified with an error if duplication is detected.

(6) GEN_CERTS:

The DIME, after all the above validation, MUST generate a Broadcast Endorsement using the provided HI and DET from the registrant as the evidence. This Endorsement is used in . The DIME MUST also generate a corresponding X.509 certificate as per , confirming that the DIME has accepted the registrant's DET/HI pair for registration. Other Certificates MAY be generated during registration but are out of scope for this document.

(7) UPDATE_DATABASE:

The DIME MUST update the Private Information Registry with all registration data required by the jurisdiction or the DIME's own policy, typically including PII, all of which must be protected by AAA as per applicable regulation and policy. It MAY include additional metadata or public information. How the Private Information Registry is updated is out of scope for this document.

(8) UPDATE_NS:

The DIME MUST update the Authoritative Name Server with any public information that was part of the registration. This information MUST be stored as described in .

(9) OUTPUT:

The DIME, upon successful updates of the Private Information Registry and Authoritative Name Server, responds according to .

Interface & Encoding Registration request and response data MUST be encapsulated in a Web Token (either CWT or JWT ). For Session IDs and Authentication Key IDs the registrant usually is the Operator (or a proxy for the Operator such as the GCS) but MAY be the UA directly if the UA has a long term cryptographic identity. The method for a registrant to find a DIME is out of scope for this document. DIMEs MUST use to provide DRIP-related interfaces and perform redirects to the relevant URIs. DIME registration endpoints MUST use POST expecting a Web Token from registrants. During a request a registrant MUST encrypt the Web Token in accordance with PRIV-2 of as during a request it typically includes PII. An example is shown in .

• Author Note: /.well-known/ could be a single URI like register-hhit or more specific ones like uas-operator and uas-session. Do we have a preference?

Example REST Registration API (request) [ CWT from registrant ] ]]>

The DIME responds, upon successful registration, with their own Web Token contain the data model defined in . The Web Token SHOULD be encrypted, if containing any PII. An example is shown in .

Example REST Registration API (response)

This document allocates application/drip+cwt, application/drip+jwt and application/drip to the Media Types registry. It also allocates register-hhit to the /.well-known/ registry.

Using CoAP for Registration Support of the Constrained Application Protocol (CoAP, ) is OPTIONAL. When using CoAP, DTLS SHOULD be used when possible and MUST send the data models ( and ) encoded as CBOR. When DTLS is not possible, and CoAP is instead used with UDP, model data MUST be encapsulated, signed and encrypted in a CWT as above.

Guidance on Registration Errors The following registration failure conditions and response are informative:

• Upon invalid input from the registrant, the DIME SHOULD respond with either 400 (Bad Request) or 403 (Forbidden) as appropriate.
• Upon a duplicate HI or DET, the DIME SHOULD respond with 409 (Conflict).
• Any other processing failure of registration by a DIME SHOULD be responded with an appropriate Server Error status code.

Care should be given when responding with 403 (Forbidden) to not expose any information that could be used to socially engineer a fake request. For example, when following , it would be unwise for the HDA to detail an exact reason for the rejection. A malicious registrant could spam the endpoint, farming information on what UAS Serial Numbers, Operator IDs and their potential bindings exist to exploit. It should be noted that the above would be avoided with properly configured systems since signature validation and denial of service mitigations would be before the HDA even attempts to ascertain validation from the RAA.

Registration Model The data sent to the DIME for a given registration is policy driven. For example a Session ID registration SHOULD include a CAA specific identifier of the Operator to enable the private binding of the Session ID to both the Serial Number (found in the CSR, ) but also the Operator themselves.

Registration Model CDDL

The data model defined in is what is minimally required for a DIME to be functional. Additional fields SHOULD be registered to IANA under for global harmonization. RAAs and HDAs MAY use their respective keys and their associated maps to define additional keys to be included in a registration. A dedicated Private Use space is provided for RAAs and HDAs to define keys and their uses. The uas map item uses the data model found in to carry any static information expected to also be found over Broadcast RID. It MUST NOT include in the uas_ids key the UAS Serial Number when a Session ID is being registered. It also MUST NOT contain the operator_location key, as this information is usually considered PII and typically is dynamic or unknown at time of registration. The DIME MUST fill in the auth key with any SAMs related to a registration and place the data model into DNS with when the registrant entity is required to use Broadcast RID and expecting to use . The registrant can select from a number of options to encode the values of valid not before (vnb) and valid not after (vna) for time of applicability of an individual CSR (csr-data). The use of the time or tdate types allow for absolute time references. The use of the uint type for vna specifies a positive offset in seconds from an absolute time. When null is used the registrant is informing the DIME that for vnb the DIME MUST use the current time as vnb during registration and for vna the DIME MUST set vna to a time such that the default DIME policy for maximum delta between vnb and vna is not exceeded.

• Implementation Note: due to not differentiating between integers and floats in its number type, implementations using JSON as the encoded format MUST check the value of vna to determine if its being used as an offset or absolute time.

As an example of the use of vnb and vna, a registrant may set vnb=null and vna=3600. The DIME in this instance would use the current absolute time at receipt of the registration request for vnb and then apply the offset specified by vna to obtain an absolute time for vna that is 3600 seconds after vnb. These absolute times of vnb and vna are then used in the certificate being created by the DIME to endorse the registration .

Validating Fields In certain circumstances field contents may only be properly validated by other entities outside of DRIP. For example the binding between UAS Serial Number and Operator ID should already be known by the CAA, as typically this information is required out of band of DRIP directly to the CAA in some form. The CAA should provide or itself have access to an "oracle" that can validate these claimed bindings for registration to proceed. If such an "oracle" is not consulted there is a risk that information being registered is fraudulent and DRIP has no method or authority to confirm the claims. If such information is accepted, future information queries by authorities can result in bogus data being returned, with no binding to an actual UAS or Operator. The CAA SHOULD, as part of its capacity as an RAA onboarding an HDA, provide data models, communication framework and any authentication mechanisms to query the oracle directly if the CAA allows HDAs to perform the queries themselves. Otherwise the RAA MUST provide an HTTPS POST interface that consumes a Web Token generated by the HDA containing the registrant Web Token. If the RAA is not configured or does not wish to handle such requests it MUST respond with 501 (Not Implemented), HDAs should proceed without validation as if validation was successful. If the RAA is configured to validate registration requests, it sends the data to the "oracle", via a mechanism out of scope for this document. When the "oracle" marks data as invalid the RAA MUST signal to the HDA that the registration is to be denied. Otherwise the RAA returns a Web Token to the HDA containing an X.509 Certificate with the Subject set to the same contents as the registrant CSR.

Response Model

Response Model CDDL any } ] ] ]]>

The canonical_cert key MUST be the certificate defined in . The be_chain contains the Broadcast Endorsement structures defined in and MAY not be sent by the DIME if the registrant is not expected to use Broadcast RID. Additional items MAY be sent back to the registrant by the DIME. Their keys SHOULD be registered under IANA as part of to support global harmonization.

Canonical Registration Certificate provides profiles for X.509 certificates adhering to the , developed by the Trust Framework Panel. At least one of the DRIP profiles MUST be used. At least one certificate in the chain from an apex node to a leaf node MUST contain a URI, as part of the Subject Alternative Name Extension , which points to the relevant Private Information Registry containing associated PII registered. This certificate MUST be contained in the HHIT RRType defined in . The certificate MAY be anywhere on the path and SHOULD be as close to the apex in the path as possible for efficiency. At the time of publication, the current best practice is for the HDA Issue certificate to contain the base URI to be used for all Private Information Registry requests under the HDA. When an HDA supports multiple Private Information Registry providers, it SHOULD set the appropriate URI in the Operational certificate. The HDA MAY either set all different URIs together in its HDA Issue certificate at cost of the querent being then required to perform queries at each provided URI until it receives a response or use different Issuer DETs for each different Private Information Registry provider. When registering a DET to be used as a Session ID, the CSR MUST contain the UAS Serial Number as the Subject, and the certificate placed in the private registry also MUST contain the UAS Serial Number as the Subject, but the certificate placed in the public registry and used as the basis of the Broadcast Endorsement (or otherwise exposed publicly) MUST NOT contain the UAS Serial Number.

Query A DIME has two query interfaces it MUST support. One interface is used for public information and the other (discoverable from public information) is for private information.

Public Information Registries The information found in these registries has been designated (explicitly or implicitly) as public by cognizant authority and/or the information owner. Such information includes asymmetric cryptographic public keys needed for authentication in , static Broadcast RID data and trustworthy pointers to additional information. These registries are Authoritative Name Servers in the DNS. See for operational requirements, query mechanism and response models.

Private Information Registries The information found in these registries is considered Personally Identifiable Information (PII) and/or is stored for potential future audit of registration. Access to Private Information Registries MUST be performed using RDAP . This section defines RDAP behavior for DRIP.

URI Path Segment The URIs to Private Information resources MUST use the specification defined in . Use of is OPTIONAL.

Conformance Literal The string literal drip_version_0 MUST be used in the rdapConformance section of the RDAP response to signal conformance with this specification.

Extension Model Queries of DETs in RDAP SHOULD respond with the appropriate Object Class as defined in and MUST include the additional data element specified in .

RDAP Response CDDL

Additional keys SHOULD be registered to IANA under for global harmonization. Specification of their usage and syntax in a NAS is provided by CAAs using a MOC that references this specification.

Differential Access Per REG-2 and REG-4 of , RDAP queries to DRIP Private Information Registries MUST be protected using fine-grained AAA policies in a both human- & machine-readable form for automated enforcement. RDAP supports only HTTP based mechanisms for authentication as defined in . A federated authentication mechanism, such as the examples in , is RECOMMENDED. For international and/or global harmonization, DRIP standardizes the following RDAP behavior for authentication of clients and servers:

• MUST support HTTP Digest Authentication Scheme () AND
• SHOULD NOT support HTTP Basic Authentication Scheme () but MAY accept Basic if peer offers that and nothing stronger AND
• MUST support Mutual TLS for global and/or international queries AND
• SHOULD use Mutual TLS but MAY do any other RDAP compatible AAA for domestic queries

A DIME when supporting Mutual TLS MUST accept valid DKIX certificates () and MAY accept other certificates.

• Author Note: the selection of Mutual TLS is an initial down selection from OpenID Connect for RDAP (), or Mutual TLS () or eXtensible Access Control Markup Language (XACML) with Security Assertion Markup Language (SAML). This is still a discussion point.

IANA Considerations

RAA Delegation for CAAs As part of IANA already has the pre-allocated mapping of RAA values for CAAs. Nations are to follow the guidance in to request delegation of their DNS zone under 3.0.0.1.0.0.2.ip6.arpa..

Well-Known URIs IANA is requested to add the following entries in the "Well-Known URIs" registry . Additions to Well-Known URIs Registry

URI Suffix	Change Controller	Reference	Status	Related Information
register-hhit	IETF	This RFC	permanent	N/A

RDAP Extensions Registry IANA is request to register the following value in the "RDAP Extensions" registry . Intended Usage: This extension is used to convey private information under an HHIT registration. ]]>

Media Types IANA is requested to add the following entries in the "Media Types" registry . Additions to Media Types Registry

Name	Template	Reference
DRIP CWT	application/drip+cwt
DRIP JWT	application/drip+jwt

application/drip+cwt Registration

Type name:

application

Subtype name:

drip+cwt

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

TODO

Interoperability considerations:

N/A

Published specification:

This RFC

Applications that use this media type:

Applications that access DIMEs requesting HHIT registration, as well as DIMEs responding to registration requests.

Fragment identifier considerations:

N/A

Person & email address to contact for further information:

DRIP WG mailing list (drip@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/drip+jwt Registration

Type name:

application

Subtype name:

drip+jwt

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary, JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters.

Security considerations:

TODO

Interoperability considerations:

N/A

Published specification:

This RFC

Applications that use this media type:

Applications that access DIMEs requesting HHIT registration, as well as DIMEs responding to registration requests.

Fragment identifier considerations:

N/A

Person & email address to contact for further information:

DRIP WG mailing list (drip@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

DRIP CBOR/JSON Keys This specification establishes a new sub-registry called "DRIP CBOR/JSON Keys" within the "Drone Remote ID Protocol" registry. This registry is to maintain a globally harmonized list of JSON keys (i.e. "Names") and CBOR map integer keys (i.e. "Labels") for use in DRIP. The following ranges are defined based on the CBOR Label values: DRIP CBOR/JSON Key Registry Policies

Range	Registration Policy	Range Use	Comments
from -2^64 to -25	Private Use ()	HID Private Keys	Private use for RAAs and HDAs
from -24 to 23	TODO: TBD	ASTM UAS Keys	Keys found in ASTM UAS Standards such as
from 24 to 2^64-1	Specification Required ()	Global Harmonization	Reserved for future registrations to maintain global harmonization

Keys in the Private Use and Experimental ranges are RECOMMENDED to prepend a _ to the Name to avoid namespace collisions with registered Names. The HID Private Keys range in this registry provide code-points (used in and as part of metadata) for each RAA and HDA to define their own subset of elements in both registration and RDAP responses. The spec value of this registry SHOULD be used to enable the DIME or client to provide a "hint" for the data elements included. Specification of the spec string semantics are left to individual RAAs and HDAs to define as they see fit. RAA and HDA Operators SHOULD provide specification for any Private Use or Experimental Use values, but this may not be public due to policy.

Review Criteria For registrations, review should note if the Name field matches an existing entry, the request should be denied. A request should also be denied if the specification duplicates an existing entry both in syntax and semantics. For example, if an existing key called whee already exists with the specification of [+ uint] and a new request comes along to register whee_but_mine with specification [+ uint], then the latter should be rejected on the grounds of being able to use whee instead. This denial can be overruled if shown that the new registration has clear justification, as part of the specification citing technical reasoning, to exist.

CBOR/JSON Key Fields

Name (JSON Key Value):

A string value, to be used as a key in the key: value pair of a JSON object. No specific rules apply for syntax beyond being a valid JSON string for a object key, but it is recommended to use all lower-case and snake-case with underscores. Care should be given to the length of a Name to reduce wire size of JSON encodings for constrained environments.

Label (CBOR Integer Key Value):

A integer value, ranging from -2^64 to 2^64 - 1, to be used as a key in a CBOR map. Different ranges of values use different registration policies, see .

Description:

A short description of the entry providing an overview of its semantic meaning and its expected use-cases.

Reference:

A link to a permanent and readily available specification defining the value syntax and semantics to be used for this key.

Registration Form

Initial Values Pre-Allocated DRIP CBOR/JSON Keys

Name (JSON Key Value)	Label (CBOR Integer Key Value)	Description	Reference
uas_type	0	Enumeration of UAS Type	This RFC,
uas_ids	1	UAS IDs	This RFC,
auth	2	Authentication Data	This RFC,
self_id	3	Self ID	This RFC,
classification	4	UA Category & Class	This RFC,
area	5	Area Count, Radius, etc.	This RFC,
operator_id	6	Operator ID	This RFC,
ua_status	7	Enumeration of Status	This RFC,
ua_position	8	UA Position	This RFC,
ua_bearing	9	Bearing / Track Direction	This RFC,
ua_speed	10	Vertical & Horizontal Speeds	This RFC,
ua_height	11	Height Above Ground or Take-off	This RFC,
accuracy	12	Enumerations of Accuracies	This RFC,
operator_position	13	Operator Position	This RFC,
timestamp	14	UTC Timestamp	This RFC,
compliance	15	Compliance Enumeration	This RFC,
raa	23	RAA	This RFC
hda	24	HDA	This RFC
csr	25	DER Encoded X.509 CSR	This RFC
uas	26	UAS Datum Map	This RFC,
utm	27	UTM Operational Intent & Source	This RFC
spec	28	CAA Specification Code	This RFC
canonical_cert	39	DER Encoded X.509 Certificate	This RFC
be_chain	30	List of Broadcast Endorsements	This RFC
registrant	31	Registrant Information	This RFC
hhit	32	Hierarchial Host Identity Tag	This RFC
oracle_x509	33	Oracle X.509 Certificate	This RFC
uas_serial_number	34	ANSI/CTA 2063-A UAS Serial Number	This RFC
caa_assigned_id	35	CAA Assigned ID	This RFC
pilot_license_id	36	Pilot License Number	This RFC

Security Considerations The considerations discussed in , , , and apply. DIMEs use and provide various methods to protect data through: Attestation, Authentication, Authorization, Access Control, Attribution, Accounting, and Audit (AAA). All data, handled under DRIP, MUST be protected by AAA, as per applicable regulation and policy (which, in some cases, for public data, may impose minimal requirements). All private data MUST also be protected by strong encryption where permitted by applicable law etc. These requirements apply to data at rest and in transit in all phases of the process, i.e. registration and query. Attestation may be mandated by CAAs for devices (such as UA). Remote ATtestation ProcedureS (RATS) is recommended for DRIP. The specific attestation mechanisms in a given jurisdiction are out of scope for this document.

• Author Note: RGM, what else should go here?

Cryptographic Materials Best practices dictate that cryptographic materials that should only be available to selected parties SHOULD be generated by one or more of those parties and stored accessibly only on those parties devices. E.g. the asymmetric key-pair from which a DET will be derived SHOULD be generated by the entity identified by that DET and the corresponding private key should be stored only on that entity's device. There may be scenarios where other parts of the UAS MAY generate the cryptographic materials and provision them as needed during an operation. Any such system MUST ensure security of the cryptographic material is guaranteed.

Privacy & Transparency Considerations The considerations discussed in and apply.

• Author Note: do we copy/paste Section 10 of and update here or is below sufficient?

DETs as Session ID and Authentication Key ID The properties of a DET allow it to be used as a Session ID and/or an Authentication Key ID. There may be scenarios in which Session IDs are desired for privacy but Authentication is not; although this may reduce transparency and security, a DET MAY be used exclusively as a Session ID in such. There are scenarios in which Authentication is desired but Session IDs are not (e.g. where a CAA does not allow Session IDs); a DET MAY be used exclusively as an Authentication Key ID in such. In the scenario expected to be most common, both Session IDs and Authentication are desired; the same DET SHOULD be used as both the Session ID and Authentication Key ID in such. Consequences and operational impact of using different DETs for the Session ID and Authentication Key ID of the same entity are unknown and not covered in this document.

Selective Encryption

• Author Note: renamed section and/or add more explicit disclaimer?

Selective encryption may be allowed in some circumstances. An HHIT may be used in a private lookup to access decryption key material or obtain decryption as a service. Selective encryption of UAS RID using DRIP is only allowed when the DET to be used as the Session ID is issued by an HDA associated with a USS and that DET is associated with the corresponding Operational Intent in UTM. This enables the encryption of selected data elements in Broadcast RID to provide a layer of privacy for operators (e.g. their position) without compromising transparency to entities (e.g. public safety / law enforcement personnel) that need to know. Selective encryption typically requires network connectivity of the Observer to perform the private query to obtain the decryption service or key material. CAAs should consider the expected Observer environment and prohibit encryption wherever and whenever Observers cannot reasonably be expected to have connectivity. For example selective encryption, per CAA regulations, MAY be allowed in dense wireless IP connectivity areas (e.g. urban) but prohibited in poor wirelessly covered areas (e.g. rural). The issue of Observer network connectivity MAY be mitigated with the use of a shared decryption key used by multiple Session IDs under a given USS/HDA over a period of time, that is preloaded onto the Observer device before connectivity is lost. For example Observers MAY query USS/HDAs for flight volumes in which they are interested to preload their decryption key(s) for the Operational Intents/Session IDs that day.

References Normative References AX Enterprize, LLC RTFM llp This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services. 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). 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 recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. 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. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. 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. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. 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 This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [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] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. 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. The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. 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 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 memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Registration Data Access Protocol (RDAP) provides Representational State Transfer (RESTful) web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such, it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. ASTM International ASTM International ASTM International International Civil Aviation Organization International Civil Aviation Organization IEEE IANA IANA IANA

DRIP CDDL Prelude This appendix is normative.

HID Abbreviation The DET MAY be abbreviated. This is useful for display applications with limited screen real-estate as the display of the entire 128-bit (32 characters in hexadecimal, even without recommended punctuation or spacing) IPv6 address can be costly. Abbreviations SHOULD follow the following format rules.

Hierarchy Level:

Each hierarchy level (RAA/HDA) is represented by a maximum of six alphanumeric characters. This abbreviation SHOULD NOT be a single character in length, for obvious reasons of not being very useful. The decimal representation does fit into the 4 character restriction but is NOT RECOMMENDED. The RECOMMENDED abbreviation for the RAA level is to use the ISO3166-1 Alpha 2 code for nations. This abbreviation MAY be found in DNS under a HHIT RRType of the entity or its parents. If there is no abbreviation hint display devices SHOULD use a fixed size four character hexadecimal representation of the value. It is RECOMMENDED that display applications specify a default RAA value, and only display the RAA abbreviation explicitly when it does not match the default.

Entity Hash:

The entity is represented by a fixed size four character hexadecimal string using the last four characters of the DET. If a collision (within the same HID space) on display occurs, the four characters SHOULD shift to the left by one hexadecimal character until the collision is resolved. This window MUST stay within the last sixteen hexadecimal characters of the DET. The : character found in an IPv6 address string is ignored.

• Review(SWC): Do we need to insert a flag character such as "*" to indicate when a hash has been shifted? If the abbreviation is used only to avoid conflicts, no; but if anyone actually knows some DETs in their operation, if they get shifted, they probably won't recognize them.

Delimiter:

Each section is delimited by a single character. This can be any whitespace character (except newline and tab) or any non-alphanumeric character (period, comma, semicolon, etc.). It is RECOMMENDED that the delimiter is consistent between components. The RECOMMENDED delimiter is the colon (:) character.

For example a DET with the values of RAA 16383 and HDA 1 without any abbreviation hint from DNS is represented by the string 3FFF 0001 xxxx with xxxx representing a entity hash. If an abbreviation for the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then the DET can be represented with the string of DRIP01 TEST xxxx. For an example of the entity hash, let's assume there are two DETs with the following hashes in the same HID: 0000:1111:2222:3333 and 0000:2222:1111:3333. At first both DETs are represented with the same abbreviation: RAA HDA 3333. One of these DETs is selected by the display application to shift the display hash one character to avoid the collision resulting in the following two abbreviations: RAA HDA 3333 and RAA HDA 1333.

Compliance Testing It is the responsibility of each parent node in the tree that a child node pass functional interoperability testing prior to issuing a certificate for the child node.

• Author: This section is a work in progress.

All interfaces MUST be tested on valid and invalid data (such as being malformed). When policy is required on an interface all essential permutations of the policy MUST be tested and all possible permutations SHOULD be tested. The policy engine MUST be invoked to validate proper decisions (including PERMIT and DENY or their equivalents) and actions are being made. All data returned from an interface MUST be tested to check that it conforms with specifications. There is a range in the RAA space allocated for experimentation and testing purposes. Sub-ranges can be delegated to parties, for a limited period of time, at the behest of the RAA Designated Expert, to test DIME interoperability (e.g. HDA to RAA, and RAA to RAA interactions) in any of the below subsections. The IANA Considerations section of contains more information on how these delegations are to be handled. provides a set of forms to be filled out and submitted as part of a CAA compliance process for using DRIP.

System Interface Test Diagram o | | X | | Y | | o<---(2)----o | | | | | +-----+ +-----+ ]]>

Registration Interface X, Y pairs: (registrant, HDA), (HDA, RAA) 1: Ensure that endpoints on Y can be accessed according to Y's policy by X. Ensure that the endpoints conform to the normative requirements of Test that Y interface properly handles valid and malformed data. Test that Y securely generates proper artifacts and stores them. 2: Ensure that the interactions for (1) properly returns data to X from Y. This data MUST include the Broadcast Endorsements, X.509s and any other data elements required.

Public Query Interface X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that Y has a properly configured and publicly accessible Authoritative Name Server for its delegated ip6.arpa domain. 2: Ensure that Y returns the valid RRTypes defined in to X based on an ip6.arpa query via standard DNS methods (i.e. using UDP on port 53). Ensure that the HHIT RRType contains the correct Certificate with an URI.

Private Query Interface X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA), (RAA, HDA), (HDA, HDA'), (RAA, RAA') 1: Ensure that the provide URI from the public query interface points to a valid URI. Ensure that the endpoint on Y has proper AAA mechanisms as defined in this document and enforces the proper policy options. 2: Ensure that the Y endpoint securely returns the data expected according to policy (matrix of authorized, valid request, unauthorized and invalid request) to X.

Compliance Submission Forms Author Note: talk with AS on this section

DRIP Key Infrastructure X.509 (DKIX) This appendix is normative. The following sections define profiles and any specific field content for X.509 certificates that serve as a "shadow" of Endorsements that make up the DRIP Key Infrastructure (DKI). It is recommended that DKIX-Full () be deployed, as its CA certificates contain ICAO policy OIDs the reflect on the whole DKIX deployment. A DKIX compliant Certificate Authority (CA) MUST implement generation of the DKI Endorsements. It SHOULD also generate both DKIX profiles ( and ). In this section Endorsing Server and CA are interchangeable.

• Author Note: At this point in defining the shadow PKIs, alternatives to a strict hierarchy is still an open work item.

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

Subject:

As defined in . This field is filled in based on the type of entity being registered. When the attribute type is set to SERIAL_NUMBER, it MUST contain the ANSI/CTA 2063-A UAS Serial Number encoded as a string. The value of this field for other entity types are subject to policy and are out of scope for this document.

Subject Alternative Name:

When the registrant knows which HID and/or Suite ID they want the CSR SHOULD contain the Subject Alternate Name extension as defined in using ipAddress containing the fully formed DET and MUST mark the extension as critical. This DIME MUST check to ensure that the DET located in the extension is properly generated with the included public key of this CSR. If the registrant does not know or care the value of their HID and/or Suite ID, the Extensions field MUST NOT appear and the DIME will use its HID for DET generation using the public key provided by this CSR.

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

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

DKIX-Lite Profile

DKIX-Lite Field Matrix

Field	Authorization	Issuing	Operational	Comments
Serial Number	MUST	MUST	MUST
Subject	MUST	MUST	MUST NOT
Issuer	MUST	MUST	MUST
Subject Alternative Name (SAN) IP6	MUST	MUST	MUST
Subject Alternative Name (SAN) URI	MAY	MAY	MAY
Basic Constraints	MUST	MUST	MUST NOT	CA=True, flagged as Critical
Subject Key Identifier (SKI)	MUST NOT	MUST NOT	MUST NOT	-
Authority Key Identifier (AKI)	MUST NOT	MUST NOT	MUST NOT	-
Key Usage	MAY	MAY	MAY	-
CA Policy OIDs	MAY	MAY	MAY

Full Profile The X.509 certificates are minimalistic (less than 400 bytes for DER). Any DRIP specific OIDs should come from the ICAO arc (see ). The profile can be found in and a field matrix found in .

DKIX-Full Profile

DKIX-Full Field Matrix

Field	Authorization	Issuing	Operational	Comments
Serial Number	MUST	MUST	MUST
Subject	MUST	MUST	MUST NOT
Issuer	MUST	MUST	MUST
Subject Alternative Name (SAN) IP6	MUST	MUST	MUST
Subject Alternative Name (SAN) URI	MAY	MAY	MAY
Basic Constraints	MUST	MUST	MUST NOT	CA=True, flagged as Critical
Subject Key Identifier (SKI)	MUST	MUST	MUST NOT
Authority Key Identifier (AKI)	MUST	MUST	MUST
Key Usage	SHOULD	SHOULD	SHOULD	-
CA Policy OIDs	RECOMMENDED	RECOMMENDED	RECOMMENDED

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

Serial Number

Lite The Serial Number is a MUST field, but it has no usage in this DRIP-Lite. It is 1-byte in size and thus duplicates are guaranteed. To drop this field could make many X.509 parsing libraries fail. However, CA certificate's Serial Number MAY be the common 20 bytes. This is to avoid possible issues with general software expecting this size Serial Numbers for CAs. If Serial Numbers are incrementally assigned, 31 bits are sufficient for an Issuing CA with 2B DETs active. A CA should determine its best-used Serial Number field size to limit the impact of this field on the certificate size.

Full The certificates will contain a 20-byte randomly generated Serial Number, compliant with CABForum recommendations. Serial Numbers are included for CRL functionality.

Subject The Subject field is only used in Authorization and Issuing Certificates. For Operational Certificates, the Subject is Empty and the DET will be in Subject Alternative Name (SAN, ). In the SAN, the DET can be properly encoded as an IPv6 address. The format defined in MUST be used. The CA Subject Name serves a dual purpose: foremost, to place the CA within the DKI tree, but secondly for outside of DRIP usage to tag that this CA's function is to serve DRIP Entities.

CA Subject Format

As examples; an Authorization DET for RAA 16376 would be: DRIP-RAA-A-16376 and an Issuing DET for HDA 16376 under the same RAA would be: DRIP-HDA-I-16376-16376.

Issuer The Issuer MUST be the higher level's DET. The Issuer for the Apex Authorization certificate MUST be its DET (indicating self-signed). If the RAA Authorization certificate is self-signed (i.e., no Apex), its Issuer is its DET. The Issuer content of its DET assists in finding this specific Issuer in the DRIP ip6.arpa. DNS tree and any additional information.

Subject Alternative Name IP6 Subject Alternative Name is only used in Operational certificates. It is used to provide the DET as an IP address with an Empty Subject (SAN MUST be flagged as Critical). The Subject Alternative Name is also used in Manufacturer DET certificates. These may contain the hardwareModuleName as described in that references . Per and , Manufacturer DET certificates with hardwareModuleName MUST have the notAfter date as 99991231235959Z.

Subject Alternative Name URI This field contains a pointer in the form of a URI where additional information on the CA and certificates under its control can be found. For example, an authorized authority may access end-entity PII like an Operator phone number through this URI link using the method specified in . Authorization certificates MAY have a SAN URI and MUST when it is self-signed. Issuing certificates SHOULD have a SAN URI. Operational certificates MAY have a SAN URI. The RECOMMENDED configuration with respect to Issuing and Operational certificates for a CA is to place the SAN URI in the Issuing certificate and exclude them in Operational certificates. When multiple providers are used by the CA to handle additional information there SHOULD be a unique Issuing certificate with SAN URI for each provider, and Operational certificates MUST NOT contain a SAN URI. Otherwise a CA with multiple providers MUST NOT have a SAN URI in the Issuing certificate and MUST set the SAN URI to the specific provider for each Operational certificate. The contents of the SAN URI are the base URI of the host to query for additional information of a DET.

• Author Note: do we want to create a ./well-known/hhit-query? Then base URIs in the certificates can become something like: https://hda.example.com, then the clients append /.well-known/hhit-query/<ip6> (<ip6> here is a specific DET). Path preservation can then be used by the server to replace /.well-known/hhit-query/ with whatever is required on the path for the specific server such as /my/bloated/path/to/rdap/ip/.

Subject Key Identifier The Subject Key Identifier MUST be the DET. This is a major deviation from "standard" X.509 certificates that hash (normally with SHA2) the Public Key to fill the Subject Key Identifier. The Subject Key Identifier is NOT included in Operational certificates. If needed by some application, it is identical with SAN.

Authority Key Identifier The Authority Key Identifier MUST be the higher level's Subject Key Identifier (i.e. DET). This partially follows standard practice to chain up the Authority Key Identifier from the Subject Key Identifier, except for how the Subject Key Identifiers are populated. The Authority Key Identifier for the Apex Authorization (or self-signed RAA Authorization) certificate MUST be the Subject Key Identifier (indicating self-signed).

CA Policy OIDs It is recommended that a CA have policy OIDs defining rules for EEs within its domain. The OIDs used here will tend to be within ICAO's arc of 1.3.27.16. If the CA certificate has policy OIDs, it MUST include an ICAO LOA OID (arc of 1.3.27.16.1.1.0) defining "the confidence in the security measures that protect the private key and manage the certificate lifecycle". ICAO LOA OID Assignments under 1.3.27.16.1.1.0

OID	Description	Applicability
1	Low	This level is relevant to environments where Risks and consequences of data Compromise are low. Subscriber Private Keys shall be stored in software at this Identity Assurance Level (IAL).
2	LowDevice	This policy is identical to that defined for the Low Assurance policy (above) with the exception of identity proofing, re-key, and Activation Data.
3	Low-TSP Mediated Signature	This policy is identical to that defined for the Low Assurance policy (above) with the exception that the Private key is not in the possession of the user, but rather by a Trust Service Provider.
4	Medium	This level is relevant to environments where Risks and consequences of data Compromise are moderate. This may include transactions having substantial monetary value or Risk of fraud or involving access to private information where the likelihood of malicious access is substantial. Subscriber Private Keys shall be stored in software at this IAL.
5	MediumDevice	This policy is identical to that defined for the Medium Assurance policy (above) with the exception of identity proofing, re-key, and Activation Data.
6	Medium-TSP Mediated Signature	This policy is identical to that defined for the Medium Assurance policy (above) with the exception that the Private key is not in the possession of the user, but rather by a Trust Service Provider.
7	MediumHardware	This policy is identical to that defined for the Medium Assurance policy (above) with the exception of Subscriber Cryptographic Module requirements described in .
8	MediumDeviceHardware	This policy is identical to that defined for the Medium Hardware Assurance policy (above) with the exception of identity proofing, re-key, and Activation Data.
9	High	This level is relevant to environments where Risks and consequences of data Compromise are high. Certificates issued at the High-CardAuth IAL shall only be issued for Card Authentication, as defined by NIST SP 800-73 or equivalent standard. Further, this policy is identical to that defined for the identical to the MediumHardware IAL except where specifically noted in .
10	High-CardAuth	This level is relevant to environments where Risks and consequences of data Compromise are high. Certificates issued at the High-cardAuth IAL shall only be issued for Card Authentication, as defined by NIST SP 800-73 or equivalent standard.
11	High-ContentSigning	This level is relevant to environments where Risks and consequences of data Compromise are High. This may include transactions having substantial monetary value or Risk of fraud or involving access to private information where the likelihood of malicious access is substantial. Certificates issued at the High IAL shall only be issued to human Subscribers.Certificates issued at the High-contentSigning IAL shall only be issued to the CMS for signing the HIGH card security objects (e.g. Certificates, CRLs, OCSP responses). Further, this policy is identical to that defined for the identical to the MediumHardware IAL except where specifically noted in .

In this document, the term “Device” is defined as a Non-Person Entity, i.e., an entity with a digital identity that acts in cyberspace but is not a human actor. This can include Organizations, hardware devices (e.g. a UA), software applications, and information artifacts. Operational Certificates issued to Devices shall assert policies mapped to LowDevice, MediumDevice, MediumDeviceHardware, or High Content Signing policies. All other policies defined here should be reserved for human Subscribers when used in Operational Certificates. Thus it is recommended that Issuing CAs/HDAs should be segregated by device and human subscribers so policy can be stated at the CA level rather in individual certificates.