Overlay Routable Crytographic Hash IDentifiers Version 3

Internet-Draft	orchid-v3	October 2026
Wiethuechter & Moskowitz	Expires 15 April 2027	[Page]

Abstract

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

1. Introduction

1.1. Purpose

This document provides clarifications and corrections around the use of Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) for the Host Identity Protocol (HIP, [RFC9063]) and the Drone Remote Identification Protocol (DRIP, [RFC9434]). 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.¶

1.2. Background

An ORCHID is the result of a process, originally defined in [RFC7343], 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, [RFC9374]) use a public key of an asymmetric key-pair.¶

Figure 1: 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.¶

1.3. Scope

This document obsoletes [RFC7343], such that the construction of ORCHIDs for [RFC7401], [RFC9374], and other classes (Figure 1) are clearly defined in a single document. It also updates [RFC7401] 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.¶

3. Architecture

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

3.1. Fields & Construction

The general construction of an ORCHID is adapted from [RFC7343] and [RFC9374] and is shown below in Figure 2.¶

Prefix      := IPv6 Prefix
Context ID  := CGA Extension Type Tag bitstring
Info        := Additional information bitstring
OGA ID      := Orchid Generation Algorithm (OGA) ID
Input       := any bitstring
Hash        := Hash Function( Input )
ORCHID      := Prefix | Info | OGA ID | Hash

Figure 2: 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 [IANA.CGA.Tags] 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 Section 3.1.1.¶
Input:: Input bitstring for Hash Function. Contents determined by Prefix and OGA ID. See Section 7.1 for security considerations.¶
Hash Function:: Selection and usage (parameters, truncation, etc.) determined by Prefix and OGA ID. See Section 3.1.2.¶
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 Section 7.2) 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.¶

3.1.1. 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 Section 3.4).¶

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

3.1.2. Hash Function Guidelines

3.1.2.1. Context ID Inclusion

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

3.1.2.2. 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 Figure 3 MUST be used to select a middle portion of the output for use.¶

DEF extract (input, input_size, output, output_size)
    TBD

Figure 3: TBD

3.2. Class Definitions

Figure 4: TBD

Class A: Simple:: Class where Info MUST NOT be present. The exemplar of this class is the HIT for use in [RFC7401].¶

Figure 5: 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 [RFC9374].¶
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, [BCP122]) is used for Info. The exact specification is out of scope for this document.¶

3.3. Guidelines for Internet Frameworks & Infrastructure

This section only applies for ORCHID use cases that included a cryptographic key as part of Input.¶

3.3.1. COSE & JOSE

CBOR Object Signing & Encryption (COSE; [STD96]) and JSON Object Signing & Encryption (JOSE; [RFC7515], [RFC7516] & [RFC7517]) 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 Section 3.2 of [RFC9164]. A JOSE Key ID MUST follow Section 2.2 of [RFC4291].¶

It is RECOMMENDED that ORCHID applications use JSON Web Key (JWK, [RFC7517]) or COSE Key (Section 7 of [RFC9052]) to store and exchange public and/or private keys. The Key ID parameter MUST be set as the ORCHID for these structures.¶

3.3.2. Public Key Infrastructure

Support of ORCHIDs in X.509 Public Key Infrastructure ([RFC5280], PKIX) MUST follow [RFC8002]. 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.¶

3.3.3. 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 Section 3.3.2.¶
HIP:: A domain name associated using one or more HIP RRType of [RFC8005] to an ORCHID, Public Key and any Rendezvous Servers used as part of [RFC8004].¶
HHIT:: A domain name associated using one or more HHIT RRType of Section 5.1 of [RFC9886].¶

Use of DNSSEC is RECOMMENDED for any of the above methods to strengthen an authoritative server claim.¶

[RFC9886] 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?¶

3.4. Considerations

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

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

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

4. Host Identity Protocol

Author TBD: small blurb on HIP here?¶

4.1. Host Identity Tag

HITs are a Class A ORCHID defined as as shown in Figure 6.¶

Prefix      := 2001:20::/28 (28-bits)
Context ID  := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA
Info        := None (0-bits)
OGA ID      := Basic OGA ID (4-bits)
Input       := Host Identity

Figure 6: Construction of HIT

Note: The Context ID for HITs is defined as part of [RFC7401] and is constant for all OGA ID's.¶

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

4.2. Payload Format

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

4.2.1. HIP Controls

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

4.3. HIP Parameters

4.3.1. HOST_ID

4.3.1.1. Algorithm

The HI Algorithm registry provides an enumeration of "profiles" that are used as part of the HOST_ID parameter (Section 5.2.9 of [RFC7401]). This document modifies this registry to add a new column (see Table 1) to indicate the encoding of a given public key to be used in Section 4.3.1.2.¶

Table 1: New HI Algorithm Registry
Value	HI Algorithm	Public Key Encoding
3	DSA	Section 2 of [RFC2536]
6	RSA	Section 2 of [RFC3110]
7	ECDSA	Section 6 of [RFC6090]
9	ECDSA_LOW	Section 6 of [RFC6090]

Note: this document deprecates the use of Section 4.2 of [RFC6090] 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.¶

4.3.1.2. Host Identity

The "Host Identity" is a field as part of the HOST_ID parameter (Section 5.2.9 of [RFC7401]). 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 [RFC7401] 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 Appendix B.¶

4.3.2. HIT_SUITE_LIST

When using the HIT_SUITE_LIST parameter (Section 5.2.10 of [RFC7401]), the ID's, sourced from Section 4.3.2.1 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.¶

4.3.2.1. HIP Suite ID

The updated HIT Suite ID registry shown in Table 2 (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?¶

Table 2: 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.¶

4.3.3. HIP_PREFIX_LIST

A new parameter titled HIP_PREFIX_LIST (Figure 7) that contains enumerated prefixes from Table 3 that a HIP client supports.¶

Figure 7: 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.¶

4.3.3.1. HIP Prefix ID

Table 3: 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)	Section 4.1
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.¶

4.3.4. NOTIFICATION

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

4.4. HIP Packets

4.4.1. HIP Initiator (I1)

Author TBD: Add optional HIP_PREFIX_LIST to I1 packet¶

4.4.2. HIP Responder (R1)

Author TBD: Add optional HIP_PREFIX_LIST to R1 packet¶

5. Drone Remote ID Protocol

Author TBD: small blurb on DRIP here?¶

5.1. DRIP Entity Tag

DETs are a Class B ORCHID defined as as shown in Figure 8.¶

Prefix      := 2001:30::/28 (28-bits)
Context ID  := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40
RAA         := Registered Assigning Authority (14-bits)
HDA         := Hierarchical HIT (HHIT) Domain Authority (14-bits)
Info        := RAA | HDA (28-bits)
OGA ID      := Extended OGA ID (8-bits)
Input       := Prefix | Info | OGA ID | Host Identity

Figure 8: Construction of DET

Note: The Context ID for DETs is defined in [RFC9374] and is constant for all OGA ID's.¶

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

5.2. Addition to HI Algorithms

The following HI Algorithm was originally added by [RFC9374] and is updated to reflect the changes of Section 4.3.1.1.¶

Table 4: Addition to HI Algorithm Registry
Value	HI Algorithm	Public Key Encoding
13	EdDSA	[RFC8032]

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

5.3. Addition to HIP Prefix ID

Table 5: 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)	Section 5.1

5.4. 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 ([RFC7401]) or ability to access Internet resources (such as [RFC9886] to get access to an X.509 certificate which would convey such information). This issue was concealed by [RFC9575] 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 [RFC9374] is deprecated.¶

Table 6: 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

9. References

9.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7343]: Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, <https://www.rfc-editor.org/rfc/rfc7343>.
[RFC7401]: Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/rfc/rfc7401>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9374]: Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023, <https://www.rfc-editor.org/rfc/rfc9374>.

9.2. Informative References

[BCP122]: Best Current Practice 122, <https://www.rfc-editor.org/info/bcp122>.
At the time of writing, this BCP comprises the following:

Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[IANA.CGA.Tags]: IANA, "CGA Extension Type Tags", September 2026, <https://www.iana.org/assignments/cga-message-types>.
[RFC2536]: Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, <https://www.rfc-editor.org/rfc/rfc2536>.
[RFC3110]: Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <https://www.rfc-editor.org/rfc/rfc3110>.
[RFC4291]: Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6090]: McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/rfc/rfc6090>.
[RFC7515]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7516]: Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.
[RFC7517]: Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.
[RFC8002]: Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, <https://www.rfc-editor.org/rfc/rfc8002>.
[RFC8004]: Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, <https://www.rfc-editor.org/rfc/rfc8004>.
[RFC8005]: Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, <https://www.rfc-editor.org/rfc/rfc8005>.
[RFC8032]: Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8610]: Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9063]: Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, <https://www.rfc-editor.org/rfc/rfc9063>.
[RFC9164]: Richardson, M. and C. Bormann, "Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021, <https://www.rfc-editor.org/rfc/rfc9164>.
[RFC9434]: Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July 2023, <https://www.rfc-editor.org/rfc/rfc9434>.
[RFC9575]: Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)", RFC 9575, DOI 10.17487/RFC9575, June 2024, <https://www.rfc-editor.org/rfc/rfc9575>.
[RFC9886]: Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tags (DETs) in the Domain Name System", RFC 9886, DOI 10.17487/RFC9886, December 2025, <https://www.rfc-editor.org/rfc/rfc9886>.
[STD96]: Internet Standard 96, <https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/info/rfc9052>.

Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/info/rfc9338>.

Appendix A. OGA ID Encodings & Enumerations

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

A.1. Basic OGA ID

The Basic OGA ID is a simple 4-bit encoding and enumeration as shown in Table 7.¶

Table 7: 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

A.2. Extended OGA ID

A RECOMMENDED mapping of Basic OGA ID values into to Extended OGA ID registry using the upper nibble as shown in Table 8. 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.¶

Table 8: 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

A.3. 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 Figure 9) 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).¶

Figure 9: 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 Table 9.¶

Table 9: 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

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

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

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