AX Enterprize, LLC

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

Internet drip Working Group Internet-Draft This document specifies a registration interaction model and interfaces for DRIP Entity Tags to a DRIP Identity Management Entity using the Constrained Application Protocol and CBOR Web Tokens.

Introduction To properly use a DRIP Entity Tag (DET) it SHOULD be registered to a DRIP Identity Management Entity (DIME). Due to the various components of Unmanned Aircraft System (UAS), typically an Unmanned Aircraft (UA) and Ground Control Station (GCS), sharing similar properties to Internet of Thing (IoT) devices the Constrained Application Protocol (CoAP) is a good choice for registration interactions between the UAS and DIME. This document specifies registration interactions using CoAP as the transport and CBOR Web Tokens (CWTs) as the optional secure container. This document only specifies the minimum data models for registration of a DET. Other elements that MAY be required by policy are out of scope for this document.

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.

Interaction Model A general interaction model () is used for all DET based registrations.

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

(3) VALID_INPUT?:

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

(4) DUPE_HI?:

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

(5) DUPE_DET?:

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

(6) GEN_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 . An associated X.509 is also generated which signifies the DIME accepts the DET/HI pairing from the registrant

(7) UPDATE_DATABASE:

The DIME MUST update the Private Information Registry with any PII that was part of the registration. It MAY include additional metadata or public information. How the Private Information Registry is updated is out of scope for this document.

(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, transmits to the registrant the list of Broadcast Endorsements that make up the trust chain for use in .

X.509 Certification Signing Request CSRs MUST be used to convey the various cryptographic and identity properties of a DET during a registration. The subjectName of the CSR is used to determine the type of registration the DET is to be used for. When the subjectName of the CSR is set to SERIAL_NUMBER then the CSR is related to the UA for use as a Session ID and/or an Authentication Key ID. Any other subjectName indicates some other entity using a DET as their identifier and are not in scope for this document. is an example CSR.

Broadcast RID Session CSR without subjectAltName

A CSR without a subjectAltName is indicating to the DIME that they do not know or care which HID and OGA ID they are registered with. In this scenario the DIME MUST generate the DET for the registrant and return it. If the registrant does known which HID and/or OGA ID they want the CSR SHOULD contain the subjectAltName containing the DET they wish to register with. is an example CSR with the subjectAltName.

Broadcast RID Session CSR with subjectAltName

Models

Registration Model

Registration Model CDDL any } csr-data = [ csr: bstr ? vnb: time, ? vna_offset: uint, ] uas-id-map = { &uas-id-types: [+ uas-id] } uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4) uas-id: tstr .size(1..20) / bstr .size(1..20) area-grp = ( area_count: 1..255, area_radius: float, area_floor: float, area_ceiling: float ) classification-grp = ( ua_class: 0..8, eu_class: nibble-field, eu_category: nibble-field ) self-grp = ( desc_type: nibble-field, description: tstr .size(23) ) operator-grp = ( operator_id_type: nibble-field, operator_id: bstr .size(20) ) nibble-field = 0..15 ]]>

The csr-data model allows flexibility of the registrant to specify the time bounds for a given key. Exclusion of either the vnb and/or vna_offset indicates to the DIME to use the defaults of the jurisdiction for the missing datum. Other keys MAY be provided and specified to carry specific data required for the registration to the DIME. Such data can include operator/organizational information. The details of such extension are out of scope for this document.

Response Model

Response Model CDDL

registration_cert MUST be the Canonical Public Registration Certificate defined in in a DER (X.509) or CBOR (C.509) encoding. The be_chain contains the Broadcast Endorsement structures required for and MUST be sent in responses for a Broadcast RID Session.

Model Use Below are overviews of variants of the above data models for supported registrations in this document. Other registration types that are defined by RAA and/or HDA policy are out of scope for this document.

Broadcast RID Session:

Registrations from UA for either Session IDs, Authentication Key IDs or both. It MAY use the f3411 key to provide static F3411 Broadcast RID information. MUST use the be_chain key to return Broadcast Endorsements for .

Operator:

MUST NOT use the f3411 key. MUST NOT use the be_chain key.

DIME:

MUST NOT use the f3411 key. MUST use the be_chain key to return Broadcast Endorsements for .

CoAP CoAP SHOULD be used using DTLS when possible and MUST send the data model encoded as CBOR. When DTLS is not possible, and CoAP is instead used with UDP, the payload MUST be in a CWT as defined in .

Endpoints The base URL of a given URI is out of scope for this document, however the path of such SHOULD be /operator, /aircraft or /broadcast_session per the class of registration. These URIs SHOULD be publicly accessible and discoverable via some mechanism (such as /.well-known/).

CWT When a CWT is to be used it SHOULD be encrypted. The CWT is signed by the registrant. For a Broadcast Session 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.

IANA Considerations TBD

Security Considerations Cryptographic materials (key-pairs, CSRs, etc.) SHOULD be generated on the device they are intended to be used. 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 SHOULD ensure security of the cryptographic material is guaranteed.

References Normative References AX Enterprize, LLC RTFM llp This document describes the discovery and management of DRIP Entity Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific DNS structures and standard DNS methods, are the Public Information Registries for DETs and their related metadata. 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. 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. 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 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 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.