]> Independent

atw.ietf@gmail.com

HTT Consulting

rgm@htt-consulting.com

Internet drip Internet-Draft Over time improvements and implementation considerations have been accumulating around Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) for the Host Identity Protocol (HIP) and the Drone Remote Identification Protocol (DRIP). Such improvements like the addition of hierarchy in RFC9374, or the development of using ORCHIDs in other frameworks are scattered across resources. This document serves to combine lessons learned and minor corrections into a single specification that obsolete RFC7343 and updates RFC7401 and RFC9374 to maintain interoperability of ORCHID-aware implementations. About This Document Status information for this document may be found at . Discussion of this document takes place on the drip Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Purpose This document provides clarifications and corrections around the use of Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) for the Host Identity Protocol (HIP, ) and the Drone Remote Identification Protocol (DRIP, ). Over time the construction and expected uses of an ORCHID have changed, most recently in the series of documents from the DRIP Working Group. This has resulted in a confusing set of requirements and options with minor errors and missing considerations across a number of documents. Simplifying the context and knowledge required to produce a cross-domain implementation using ORCHIDs is paramount for interoperability and is the goal of this document.

Background An ORCHID is the result of a process, originally defined in , that hashes information down to a "tag" in the form of valid IPv6 address out of special-use address space. Anything can be the input for this process for example the Host Identity Tag (HIT) and later the DRIP Entity Tag (DET, ) use a public key of an asymmetric key-pair.

Comparison of ORCHID Classes to Unicast IPv6 Address

The HIT is an identifier that is built around the use of HIP and the Base Exchange (BEX). DRIP improved the HIT by introducing the concept of a Hierarchial HIT (HHIT) and developing the DET as a session identifier for UAS RID. Being under a broadcast centric domain, DRIP users are in most cases is not expected to or cannot perform the HIP BEX. During the development of DETs, it was broadly attempted to keep backwards compatibility with the existing HIP specifications. Recent developments have found this goal has fallen short, with various elements of HIP not being interoperable with DETs. One example is the Suite ID definition of DRIP and the original HIP parameter to share them.

Scope This document obsoletes , such that the construction of ORCHIDs for , , and other classes () are clearly defined in a single document. It also updates to enable the interoperability of ORCHIDs in general rather specifically the HIT. Guidelines for using of ORCHIDs in other applications such as Object Signing & Encryption, Public Key Infrastructure and the Domain Name System (DNS) is also specified or referenced.

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 & Abbreviations This document uses the Concise Data Definition Language (CDDL, ). TBD

Architecture

• Author TBD: small blurb on arch. w/ high-level changes from RFC7343?

Fields & Construction The general construction of an ORCHID is adapted from and and is shown below in .

ORCHID Format & Construction

Prefix:

IANA assigned IPv6 Prefix from the Special Use block. Size P_SIZE in bits.

Context ID

A randomly generated bitstring value defining the expected usage context for the particular ORCHID by Prefix and OGA ID to be used as part of the Input bitstring or Hash Function parameter. These values MUST be enumerated in the namespace.

Info:

OPTIONAL bitstring of additional information. MUST be 0 <= I_SIZE <= 60 where I_SIZE % 4 == 0, determined by Prefix.

OGA ID:

Enumeration for Input and Hash Function. O_SIZE in bits determined by Prefix. See .

Input:

Input bitstring for Hash Function. Contents determined by Prefix and OGA ID. See for security considerations.

Hash Function:

Selection and usage (parameters, truncation, etc.) determined by Prefix and OGA ID. See .

Hash:

Output of Hash Function that MUST be H_SIZE = 128 - P_SIZE - I_SIZE - O_SIZE bits. It is RECOMMENDED to keep H_SIZE >= 64 && H_SIZE % 4 == 0 bits for hash collision security (see ) and to align with the "interface ID" portion of an IPv6 address.

ORCHID:

The resulting IPv6 address known as an ORCHID. The sum size of components MUST be P_SIZE + I_SIZE + O_SIZE + H_SIZE == 128.

Construction is limited to the IPv6 unicast and anycast address format with construction as a multicast IPv6 address is out of scope. The placement of OGA ID to be directly before the Hash portion is analogous to the "subnet ID" portion of an IPv6 address. The combination of Prefix, Info and OGA ID is relative to the "network prefix" terminology of IPv6.

OGA ID & Suite ID The OGA ID is a field that allows enumeration of an Input and Hash Algorithm to be used to form an ORCHID. The exact specification of what consists of an Input and what Hash Algorithm to use is decided by a domain/protocol/application that obtains a Prefix (see ). A "Suite ID" is an application specific enumeration table to be used as the OGA ID in the creation of an ORCHID. Enumerations for a Suite ID are set by the Prefix owner. The Suite ID SHOULD encompasses any parameters that are required for processing the ORCHID by a receiver. For some applications this MAY include details that become unavailable while disconnected from the Internet such as if the recipient is not expected or unable to perform a HIP Base Exchanged (BEX) or DNS lookup.

Hash Function Guidelines

Context ID Inclusion Inclusion of Context ID as part of the hash function is determined by the Prefix owner. Currently for both the and Prefix the Context ID MUST be prepended to the Input for the SHA family of hash algorithms. For cSHAKE , the Context ID MUST be set in the "custom string" parameter.

Fixed Hash Output Some hash function families, such as SHA, that have a fixed length output which exceeds the Hash field length. For security purposes truncation SHOULD NOT be used to shorten the hash to the length needed for an ORCHID. Instead the generalized function of MUST be used to select a middle portion of the output for use.

TBD

Class Definitions

TBD

Class A: Simple:

Class where Info MUST NOT be present. The exemplar of this class is the HIT for use in .

TBD

Class B: Hierarchical (Static):

Class where Info MUST be present and MUST contain hierarchy information, forming a Hierarchy ID (HID), that has fixed sized fields. The exemplar case is the HHIT and the use-case instance of a DET from .

Class C: Opaque:

Class where Info MUST be present and MUST contain non-hierarchical opaque domain/application information. There is currently no example of such an ORCHID, thus is out of scope for this document. A potential case for such is a closed off network of computational agents.

Class D: Hierarchical (Dynamic):

Similar to Class B, but instead of a hierarchy of fixed sized fields Classless Inter-Domain Routing (CIDR, ) is used for Info. The exact specification is out of scope for this document.

Guidelines for Internet Frameworks & Infrastructure This section only applies for ORCHID use cases that included a cryptographic key as part of Input.

COSE & JOSE CBOR Object Signing & Encryption (COSE; ) and JSON Object Signing & Encryption (JOSE; , & ) are common envelope models that are used in modern applications to interchange data signing and/or encrypted. An ORCHID MAY be used as a Key ID as part of COSE or JOSE when applicable. An ORCHID COSE Key ID MUST be set using . A JOSE Key ID MUST follow . It is RECOMMENDED that ORCHID applications use JSON Web Key (JWK, ) or COSE Key () to store and exchange public and/or private keys. The Key ID parameter MUST be set as the ORCHID for these structures.

Public Key Infrastructure Support of ORCHIDs in X.509 Public Key Infrastructure (, PKIX) MUST follow . This uses the extensions "Subject Alternative Name: IP6" and "Issuer Alternative Name: IP6" to carry the ORCHID. Use of other extensions are defined by policy as needed. If required multiple ORCHIDs can be part of the Issuer or Subject Alternative Name to cover interoperability considerations between ORCHID classes.

Domain Name System The inclusion of ORCHIDs in DNS depends on specific use-case goals. There are currently three resource record types (RRType) that ORCHID can be used.

CERT:

A domain name associated using one or more CERT RRType that contains an X.509 certificate following .

HIP:

A domain name associated using one or more HIP RRType of to an ORCHID, Public Key and any Rendezvous Servers used as part of .

HHIT:

A domain name associated using one or more HHIT RRType of .

Use of DNSSEC is RECOMMENDED for any of the above methods to strengthen an authoritative server claim. details, and readily demonstrates its deployment with DETs, using the existing ip6.arpa domain hierarchy to allow clean delegation and standardized lookup of ORCHIDs. It is RECOMMENDED as it is applicable for all ORCHID classes but MAY, at the loss of global interoperability, be augmented or replaced in isolated LANs. When using DNS for ORCHID Class B, C or D the internal structures of Info SHOULD be evenly divisible by four (4) to ensure that fields in Info stay on clean nibble boundaries for delegation.

• Author TBD: do we enable a DNS lookup of Suite IDs for a given prefix+info?

Considerations The declaration of an ORCHID requires the selection of an ORCHID Class () along with the following items:

1. If Class B & C: size in bits and definition of fields encoded into Info
2. Selection of OGA ID encoding size and appropriate Suite ID (see for definitions and Suite ID templates)
3. Size of Hash in bits

• Author TBD: something about hash function selection here and input parameters?

Host Identity Protocol

• Author TBD: small blurb on HIP here?

Host Identity Tag HITs are a Class A ORCHID defined as as shown in .

Construction of HIT

• Note: The Context ID for HITs is defined as part of and is constant for all OGA ID's.

The Host Identity is described in . The Basic OGA ID uses as the source of values.

Payload Format

• Author TBD: update to be Sender's ORCHID and Receiver's ORCHID

HIP Controls

• Author TBD: Add HIP Controls for optional HIP_PREFIX_LIST to I1/R1 and updated HIT_SUITE_LIST behavior?

HIP Parameters

HOST_ID

Algorithm The HI Algorithm registry provides an enumeration of "profiles" that are used as part of the HOST_ID parameter (). This document modifies this registry to add a new column (see ) to indicate the encoding of a given public key to be used in . New HI Algorithm Registry

Value	HI Algorithm	Public Key Encoding
3	DSA
6	RSA
7	ECDSA
9	ECDSA_LOW

• Note: this document deprecates the use of for the encoding of ECDSA and ECDSA_LOW Host Identities.

The support of RSA, DSA and ECDSA_LOW is for legacy applications that use HIP. Newer implementations SHOULD NOT allow the creation of an ORCHID with these HI Algorithms.

Host Identity The "Host Identity" is a field as part of the HOST_ID parameter (). The content is selected using the HI Algorithm ("Algorithm" field) and its "Public Key Encoding". This field MUST be used as part of HIT generation.

• Implementation Note: in it was unclear exactly what was used as Input for HIT generation without careful mapping of multiple references. For clarity all current HI Algorithm's "Host Identity" field contents are specified in .

HIT_SUITE_LIST When using the HIT_SUITE_LIST parameter (), the ID's, sourced from MUST be encoded as a full octet to maintain backwards compatibility. This specification removes the requirement for senders to set the lower nibble to zero (0), along with removing the error state for receipt of a lower nibble of non-zero, enabling support of Suite IDs using an Extended OGA ID.

• Note: the more accurate name of this parameter after the changes is HIP_SUITE_LIST.

HIP Suite ID The updated HIT Suite ID registry shown in (renamed to "HIP Suite ID"). It maintains an 8-bit enumeration but can either be used with a 4-bit or 8-bit encoding.

• Author TBD: should this be more specific? Columns for HI Algorithm, and a new table for Hash Algorithms to use and reference? Columns: Value(dec)/HI Alg/Hash Alg/Label?

Extended OGA ID Registry Template

Value (Decimal)	Basic OGA ID (4-bit, Hex)	Extended OGA ID (8-bit, Hex)	HIP Suite ID
0	0x0	0x00	Reserved
1 - 15	-	0x01 - 0x0F	Unassigned
16	0x1	0x10	RSA,DSA/SHA-256
17 - 31	-	0x11 - 0x1F	Unassigned
32	0x2	0x20	ECDSA/SHA-384
33 - 47	-	0x21 - 0x2F	Unassigned
48	0x3	0x30	ECDSA_LOW/SHA-1
49 - 63	-	0x31 - 0x3F	Unassigned
64	0x4	0x40	Unassigned
65 - 79	-	0x41 - 0x4F	Unassigned
80	0x5	0x50	Unassigned
81 - 95	-	0x51 - 0x5F	Unassigned
96	0x6	0x60	Unassigned
97 - 111	-	0x61 - 0x6F	Unassigned
112	0x7	0x70	Unassigned
113 - 127	-	0x71 - 0x7F	Unassigned
128	0x8	0x80	Unassigned
129 - 143	-	0x81 - 0x8F	Unassigned
144	0x9	0x90	Unassigned
145 - 159	-	0x91 - 0x9F	Unassigned
160	0xA	0xA0	Unassigned
161 - 175	-	0xA1 - 0xAF	Unassigned
176	0xB	0xB0	Unassigned
177 - 191	-	0xB1 - 0xBF	Unassigned
192	0xC	0xC0	Unassigned
193 - 207	-	0xC1 - 0xCF	Unassigned
208	0xD	0xD0	Unassigned
209 - 223	-	0xD1 - 0xDF	Unassigned
224	0xE	0xE0	Unassigned
225 - 239	-	0xE1 - 0xEF	Unassigned
240	0xF	0xF0	Unassigned
241 - 255	-	0xF1 - 0xFF	Unassigned

• Note: HITs MUST only use the values indicated by the "Basic OGA ID (4-bit, Hex)" column.

HIP_PREFIX_LIST A new parameter titled HIP_PREFIX_LIST () that contains enumerated prefixes from that a HIP client supports.

HIP_PREFIX_LIST

Type:

TBD

Length:

length in octets, excluding Type, Length, and Padding

Prefix:

identifies a HIP Prefix ID supported by the host. The list of prefixes is ordered by preference of the host. Each HIP Prefix ID is one octet long.

HIP Prefix ID HIP Prefix ID Registry

Value	Prefix	Info	OGA ID	Hash	Class	HIP Prefix ID	Reference
0	-	-	-	-	-	Reserved	-
1	2001:20::/28	0	Basic	96	A	Host Identity Tag (HIT)
2 - 255	-	-	-	-	-	Unassigned	-

Prefix:

IANA assigned IPv6 prefix in CIDR notation.

Info:

Size of Info in bits.

OGA ID:

Encoding format for OGA ID: Basic, Extended, or Flex.

Hash:

Size of Hash in bits.

Class:

ORCHID Class: A, B, C, or D.

NOTIFICATION

• Author TBD: add UNSUPPORTED_PREFIX to Error enumeration, data contains supported HIP Prefix IDs

HIP Packets

HIP Initiator (I1)

• Author TBD: Add optional HIP_PREFIX_LIST to I1 packet

HIP Responder (R1)

• Author TBD: Add optional HIP_PREFIX_LIST to R1 packet

Drone Remote ID Protocol

• Author TBD: small blurb on DRIP here?

DRIP Entity Tag DETs are a Class B ORCHID defined as as shown in .

Construction of DET

• Note: The Context ID for DETs is defined in and is constant for all OGA ID's.

The Host Identity as part of Input is described in . The Extended OGA ID uses the HIP Suite ID registry () as the source of values.

Addition to HI Algorithms The following HI Algorithm was originally added by and is updated to reflect the changes of . Addition to HI Algorithm Registry

Value	HI Algorithm	Public Key Encoding
13	EdDSA

The EdDSA HI Algorithm uses the same "Host Identity" as ECDSA/ECDSA_LOW (). A separate curve registry (EdDSA Curve Label) is defined by .

Addition to HIP Prefix ID Addition to HIP Prefix ID Registry

Value	Prefix	Info	OGA ID	Hash	Class	HIP Prefix ID	Reference
2	2001:30::/28	28	Extended	64	B	DRIP Entity Tag (DET)

Additions to HIP Suite ID The Suite IDs that were allocated during DRIP did not contain enough information for scenarios where the DET recipient had no intention of performing a HIP BEX () or ability to access Internet resources (such as to get access to an X.509 certificate which would convey such information). This issue was concealed by constraining the selection of the EdDSA curve to Ed25519 due to media size limits. This requires receivers to rely on the specifications narrow scope to avoid interoperability issues. Thus this document defines new HIP Suite ID specific values encoding HI Algorithm parameters such as curve to resolve the issue. The allocation of HIP Suite ID value 5 is to avoid existing implementation changes from the old HHIT Suite ID allocations. The HHIT Suite ID defined in is deprecated. Additions to HIP Suite ID Registry

Value (Decimal)	Basic OGA ID (4-bit, Hex)	Extended OGA ID (8-bit, Hex)	HIP Suite ID
5	-	0x05	EdDSA-25519/cSHAKE128
33	-	0x21	ECDSA-P256/SHA-384
34	-	0x22	ECDSA-P384/SHA-384
80	0x5	0x50	EdDSA/cSHAKE128
81	-	0x51	EdDSA-25519ph/cSHAKE128
82	-	0x52	EdDSA-448/cSHAKE256
83	-	0x53	EdDSA-448ph/cSHAKE256
254	-	0xFE	DET HDA Private Use
255	-	0xFF	DET HDA Private Use

IANA Considerations TBD

Security Considerations

Hash Input TBD

Hash Size vs Collisions TBD

Privacy & Transparency Considerations TBD

References Normative References This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. 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. 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 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK] This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter. This document updates RFC 7401 and obsoletes RFC 6253. This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204. 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. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. 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 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. This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. 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 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 Identification and other services. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. IANA

OGA ID Encodings & Enumerations The OGA ID of an ORCHID has three supported encodings of which a Prefix selects one for use.

Basic OGA ID The Basic OGA ID is a simple 4-bit encoding and enumeration as shown in . Basic OGA ID Registry Template

Value (Decimal)	Basic OGA ID (4-bit, Hex)
0	0x0
1	0x1
2	0x2
3	0x3
4	0x4
5	0x5
6	0x6
7	0x7
8	0x8
9	0x9
10	0xA
11	0xB
12	0xC
13	0xD
14	0xE
15	0xF

Extended OGA ID A RECOMMENDED mapping of Basic OGA ID values into to Extended OGA ID registry using the upper nibble as shown in . A given ORCHID declaration with a newly defined Suite ID MAY choose to ignore this recommendation and use a one-to-one mapping between encoding and enumeration. Extended OGA ID Registry Template

Value (Decimal)	Basic OGA ID (4-bit, Hex)	Extended OGA ID (8-bit, Hex)
0	0x0	0x00
1 - 15	-	0x01 - 0x0F
16	0x1	0x10
17 - 31	-	0x11 - 0x1F
32	0x2	0x20
33 - 47	-	0x21 - 0x2F
48	0x3	0x30
49 - 63	-	0x31 - 0x3F
64	0x4	0x40
65 - 79	-	0x41 - 0x4F
80	0x5	0x50
81 - 95	-	0x51 - 0x5F
96	0x6	0x60
97 - 111	-	0x61 - 0x6F
112	0x7	0x70
113 - 127	-	0x71 - 0x7F
128	0x8	0x80
129 - 143	-	0x81 - 0x8F
144	0x9	0x90
145 - 159	-	0x91 - 0x9F
160	0xA	0xA0
161 - 175	-	0xA1 - 0xAF
176	0xB	0xB0
177 - 191	-	0xB1 - 0xBF
192	0xC	0xC0
193 - 207	-	0xC1 - 0xCF
208	0xD	0xD0
209 - 223	-	0xD1 - 0xDF
224	0xE	0xE0
225 - 239	-	0xE1 - 0xEF
240	0xF	0xF0
241 - 255	-	0xF1 - 0xFF

Flex OGA ID To support a dynamic OGA ID sizing as part of an ORCHID the most significant bit of the OGA ID is a flag (FX in ) indicating a total length of 4-bits or 8-bits. The Basic OGA ID is a 4-bit encoding with a 3-bit enumeration (0b0xxx, values 0 to 7) and Extended OGA ID is an 8-bit encoding with a 7-bit enumeration (0b1xxx xxxx, values 0 to 127).

TBD

• Author TBD: move FX bit from MSb to LSb?

An Extended OGA ID has seven (7) values shared between the encodings due to three shared bits (4, 5 & 6). A registry template is provided as . Flex OGA ID Registry Template

Value (Decimal)	Basic OGA ID (4-bit, Hex)	Extended OGA ID (8-bit Hex)
0	0x0	0x80
1 - 15	-	0x81 - 0x8F
16	0x1	0x90
17 - 31	-	0x91 - 0x9F
32	0x2	0xA0
33 - 47	-	0xA1 - 0xAF
48	0x3	0xB0
49 - 63	-	0xB1 - 0xBF
64	0x4	0xC0
65 - 79	-	0xC1 - 0xCF
80	0x5	0xD0
81 - 95	-	0xD1 - 0xDF
96	0x6	0xE0
97 - 111	-	0xE1 - 0xEF
112	0x7	0xF0
113 - 127	-	0xF1 - 0xFF

Host Identities

RSA is a representation of a RSA Host Identity. See for details.

RSA Host Identity

DSA is a representation of a DSA Host Identity. See for details.

DSA Host Identity

ECDSA & ECDSA_LOW is a representation of a ECDSA or ECDSA_LOW Host Identity originally defined in .

ECDSA & ECDSA_LOW Host Identity

Curve Label:

Enumeration of specific curve in use. See respective curve label registry based on HI Algorithm.

Public Key

Encoded per HI Algorithm "Public Key Encoding".