Drone Remote ID Protocol A. Wiethuechter Internet-Draft AX Enterprize, LLC Intended status: Standards Track 16 March 2026 Expires: 17 September 2026 Hierarchical ORCHID Management Entity (HOME) Interfaces for Registration & Differential Access Query draft-atw-home-interfaces-00 Abstract This document standardizes the interfaces of an ORCHID Management Entity (OME) to allow clients to register and query with differential access an Overlay Routable Cryptographic Hash Identifier (ORCHID) such as a Hierarchial Host Identity Tag (HHIT). Existing technologies such as CBOR/JSON Object Signing & Encryption (COSE/ JOSE) and Registration Data Access Protocol (RDAP) are selected to enable widespread interoperability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wiethuechter Expires 17 September 2026 [Page 1] Internet-Draft home-interfaces March 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. Targeted DRIP Requirements . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Additional Definitions & Abbreviations . . . . . . . . . 5 3. HOME Component Architecture & Functions . . . . . . . . . . . 6 4. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. HOME Token . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Signature Layer . . . . . . . . . . . . . . . . . . . 10 4.1.2. Encryption Layer . . . . . . . . . . . . . . . . . . 10 4.2. Claims Set . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. HOME Registration Inquiry (HRI) . . . . . . . . . . . 11 4.2.2. HOME Registration Response (HRR) . . . . . . . . . . 12 4.3. Considerations . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Keys & Certificate Signing Request . . . . . . . . . 14 4.3.2. Registration Endpoint . . . . . . . . . . . . . . . . 14 4.3.3. HRI Validation & Processing . . . . . . . . . . . . . 15 4.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.1. Response Codes . . . . . . . . . . . . . . . . . . . 16 5. Differential Access Query . . . . . . . . . . . . . . . . . . 17 5.1. RDAP Query . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Query Endpoint . . . . . . . . . . . . . . . . . . . 19 5.2. Differential Access Control . . . . . . . . . . . . . . . 19 5.3. RDAP Extension & Response . . . . . . . . . . . . . . . . 20 6. ORCHID Key Infrastructure (OKI) . . . . . . . . . . . . . . . 20 6.1. Hierarchy Responsibilities . . . . . . . . . . . . . . . 23 6.2. ORCHID Key Infrastructure X.509 (OKIX) . . . . . . . . . 26 6.2.1. Signing Request . . . . . . . . . . . . . . . . . . . 26 6.2.2. Certificate: Lite Profile . . . . . . . . . . . . . . 27 6.2.3. Certificate: Full Profile . . . . . . . . . . . . . . 28 6.2.4. Certificate Fields . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7.1. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . 33 7.2. CWT & JWT Claims . . . . . . . . . . . . . . . . . . . . 33 Wiethuechter Expires 17 September 2026 [Page 2] Internet-Draft home-interfaces March 2026 7.3. RDAP Extensions Registry . . . . . . . . . . . . . . . . 34 7.4. HHIT Entity Types . . . . . . . . . . . . . . . . . . . . 34 7.5. HOME Parameters . . . . . . . . . . . . . . . . . . . . . 37 7.5.1. Registry Fields . . . . . . . . . . . . . . . . . . . 38 7.5.2. Registration Form . . . . . . . . . . . . . . . . . . 38 7.6. HOME Common Parameters . . . . . . . . . . . . . . . . . 39 7.7. HOME Aviation Parameters . . . . . . . . . . . . . . . . 41 7.8. Media Types . . . . . . . . . . . . . . . . . . . . . . . 42 7.8.1. application/home+cbor . . . . . . . . . . . . . . . . 43 7.8.2. application/home+json . . . . . . . . . . . . . . . . 43 7.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 8.1. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.2. Cryptographic Materials . . . . . . . . . . . . . . . . . 45 9. Privacy & Transparency Considerations . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. Oracle As A Service . . . . . . . . . . . . . . . . 50 A.1. Use Case Example . . . . . . . . . . . . . . . . . . . . 51 A.2. Expected HOME Behavior . . . . . . . . . . . . . . . . . 51 A.3. Expected Oracle Behavior . . . . . . . . . . . . . . . . 52 Appendix B. CDDL & Encoding Rules . . . . . . . . . . . . . . . 52 B.1. Prelude . . . . . . . . . . . . . . . . . . . . . . . . . 52 B.2. HRI & HRR Claims . . . . . . . . . . . . . . . . . . . . 52 B.3. IPv6 Handling . . . . . . . . . . . . . . . . . . . . . . 53 B.4. HOME Common Parameters . . . . . . . . . . . . . . . . . 54 B.4.1. VNB & VNA Handling . . . . . . . . . . . . . . . . . 54 B.5. HOME Aviation Parameters . . . . . . . . . . . . . . . . 55 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction 1.1. Purpose An ecosystem using Overlay Routable Cryptographic Hash IDentifiers (ORCHIDs, [RFC7343]) as its primary identifier can be a strong option for modern systems. The Hierarchical Host Identity Tags (HHITs, [RFC9374]) are used in the fast growing sector of Unmanned Aircraft Systems (UAS) to provide identity and authentication services using the Domain Name System (DNS). Wiethuechter Expires 17 September 2026 [Page 3] Internet-Draft home-interfaces March 2026 With standardization, identity ecosystems can be created around the use of ORCHIDs to serve various use-cases. This provides widespread interoperability of the functions of registration, public query and private query using a selection of existing standards and methods. Being backed by cryptographic keys allow existing key infrastructure, certificates and policy to be leveraged with minimal overhead, modification or redeployment. 1.2. Background HHITs are an evolution of the Host Identity Tags (HITs) in the Host Identity Protocol (HIP, [RFC9063]). All of these tags are categorized as an ORCHID which were standardized in [RFC7343] and updated by [RFC9374]. HHITs solve the problem of HITs being a flat namespace, which is hard to manage at a global scale, by adding hierarchy into the identifier. When the hierarchy is laid onto the DNS, interoperability of lookups becomes trivial. [RFC9434] introduces the concept of the DRIP Identity Management Entity (DIME) that provides the critical function of registering and querying information around DETs. It further specifies logical entities of the Public Information Registry and Private Information Registry of which the former has been specified in [RFC9886] using the DNS. The concept of the DIME can be backported to ORCHIDs in general with the addition of the term ORCHID Management Entity (HOME). In relation to key infrastructure policies and certificates the terms ORCHID Key Infrastructure (OKI) and ORCHID Key Infrastructure X.509 (OKIX) are introduced here to mirror but be distinct from the existing Public Key Infrastructure (PKI) and Public Key Infrastructure X.509 (PKIX). 1.3. Scope This document provides specification of the interfaces and models for registration and differential access query of ORCHIDs to support identity services under an HOME. This is to provide specification for the final missing pieces of a DIME and is the exemplar use-case of using HHITs, such as the DET, as the core of an identity ecosystem. The term HHIT is used when discussing the general technology while DET is used with discussion around UAS/aviation specific elements when possible. Additional terms reinforcing this delineation are found in Section 2. This document defines all data models in the Concise Data Definition Language (CDDL, [RFC8610]) with the full specification in Appendix B. Wiethuechter Expires 17 September 2026 [Page 4] Internet-Draft home-interfaces March 2026 1.3.1. Disclaimer The specifications in this document do NOT provide protection against incorrect (e.g. fraudulent) data entered during registration or asserted subsequently. The selected technologies do 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 HOME, or the party on whose behalf the HOME is being operated, to validate the registration data. An HOME at a root in the hierarchy aligned with the scope of the data SHOULD provide services to obtain this goal, see Appendix A. 1.3.2. Targeted DRIP Requirements The following requirements of [RFC9153] are satisfied when following this document: GEN-3, ID-4, REG-2, REG-4 and PRIV-2. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Additional Definitions & Abbreviations *Hierarchical ORCHID Management Entity (HOME)*: A term to describe an entity providing various identity management functions (such as registration, query, etc.) to clients at a specific point in the hierarchy. HOME's have four major functional components that can be co-located or distributed as a system of systems: Registrar, Registry, Authoritative Name Server and Certificate Authority. The DRIP Identity Management Entity (DIME) is a specialization of HOME in support of the UAS/aviation ecosystem. *ORCHID Key Infrastructure (OKI)*: A key infrastructure consisting of policies around entities using HHITs in a domain space. An example of an OKI is the DRIP Key Infrastructure (DKI) for UAS/ aviation. *ORCHID Key Infrastructure X.509 (OKIX)*: A set of X.509 certificate Wiethuechter Expires 17 September 2026 [Page 5] Internet-Draft home-interfaces March 2026 profiles in compliance of Public Key Infrastructure X.509 (PKIX, [RFC5280]) that support an OKI. An example of an OKIX is the DRIP Key Infrastructure X.509 (DKIX) for UAS/aviation. *HOME Token*: In the context of this specification; a HOME Token can be any of the Concise Binary Object Representation (CBOR; [STD94]) Object Signing & Encryption (COSE; [STD96]) or JavaScript Object Notation (JSON; [STD90]) Object Signing & Encryption (JOSE; [RFC7515], [RFC7516]) structure. See Section 4.1. *HRI Token*: A HOME Token containing an HRI claim per Section 4.2.1. *HRR Token*: A HOME Token containing an HRR claim per Section 4.2.2. 3. HOME Component Architecture & Functions To properly provide the necessary services identified in both [RFC9153] and [RFC9434] a DIME, or more generally an HOME, requires four critical functions: _Registrar_, _Registry_, _Authoritative Name Server_ and _Certificate Authority_ as detailed below for this document and in Figure 1. _Registrar_: This document covers the client facing interface of the Registrar function used by Registrants. Interactions done by the Registrar with other HOME functions are out of scope for this document. _Certificate Authority_: This document does not cover specific details of this function of an HOME. However, it is expected to provide at least ORCHID Key Infrastructure X.509 (OKIX) certificates used in other parts of the HOME. These are [RFC5280] compliant certificates that support HHITs, see Section 6. Explicit policy for Certificate Authorities are left for more specific implementation and documents, such as a Concept of Operations. _Authoritative Name Server_: The specific details of records hosted by the Authoritative Name Server as part of DNS is specified in [RFC9886] and are out of scope for this document. Interactions done by other HOME functions to manage an Authoritative Name Server are out of scope for this document. It should be noted that some artifacts generated during the registration process specified in this document end up in RRTypes hosted in DNS. This function serves as the Public Information Registry as defined by Section 4.1 of [RFC9434]. _Registry_: This document covers the client facing interface of the Wiethuechter Expires 17 September 2026 [Page 6] Internet-Draft home-interfaces March 2026 Registry function used by Observers to query for additional details about the HHIT. Interactions done by the Registry with other HOME functions are out of scope for this document. It should be noted that artifacts generated during the registration process specified in this document MUST end up in the Registry for audit purposes. For this document the term Registry is short-hand for Private Information Registry as defined in Section 4.2 of [RFC9434]. Wiethuechter Expires 17 September 2026 [Page 7] Internet-Draft home-interfaces March 2026 +------------+ | Registrant | +----*-------+ | | HOME Token/HTTPS +------+ | +---+ HOME +-------------|------------------------+ | +------+ | | | .----*-----. | | | | | | ..........o Registrar o.......... | | : | | : | | : '-----o----' : | | : : : | | : : : | | : : : | | : .-----o------. : | | : | | : | | : | Certificate | : | | : .....o Authority o..... : | | : : | | : : | | : : '------------' : : | | : : : : | | : : : : | | : : : : | | .--o---o-------. .-o---o---. | | | | | | | | | Authoritative | | Registry | | | | Name Server | | | | | | | '----*----' | | '------*-------' | | | | | | +-----------|--------------------------|----------+ | | DNS | | RDAP '----------. .-----------' | | +--*---*--+ | Querant | +---------+ Figure 1: Simplified Diagram of HOME Registration/Query Components & Interactions The specific interaction models and transports between the _Registrar_, _Certificate Authority_, _Registry_ and _Authoritative Name Server_ when not co-located (i.e. as a distributed system of systems) is out of scope for this document. Note that of the Wiethuechter Expires 17 September 2026 [Page 8] Internet-Draft home-interfaces March 2026 duplicate links feeding _Authoritative Name Server_ and _Registry_ one set is chosen in an implementation for each. A number of these functions/interactions are lifted from the DNS and the existing relationships and protocols between such entities in that domain also can apply here. For example, between _Registrar_ and _Registry_ is the Extensible Provisioning Protocol (EPP, [STD69]) or equivalents such as RESTful Provisioning Protocol (RPP). This document details the interactions between a registering client (known as _Registrant_) and the _Registrar_ through an HTTPS interface as described in Section 4 and the RDAP interaction by _Querants_ (such as _Observers_) and a _Registry_ as described in Section 5. These interfaces can be either used by machines as an API or provided with a UI for humans to interact with such as on a web browser. The elements of any maps found in CDDL for this specification MUST be declared by an ecosystem. An initial key set for elements in aviation use cases are registered in Section 7.5. Context MAY be provided in-band in HTTP using a registered Media Type as part of the Content-Type header for what key set to use to avoid processing ambiguity. 4. Registration This sections details the process of registration following Figure 2. This Z-diagram is the upper link of Figure 1 labeled with "HOME Token/HTTPS" between _Registrant_ and _Registrar_. Registrant HOME | | GEN_HHIT/HI | | GEN_CSR | | |--------HRI------->| | | VALID_HRI? |<-------FAIL-------| | | DUPE_HI? |<-------FAIL-------| | | DUPE_HHIT? |<-------FAIL-------| | | GEN_CERTS | | UPDATE_DATABASE | | UPDATE_NS |<------ HRR--------| ONBOARD | | | | Figure 2: Registration Z-Diagram Wiethuechter Expires 17 September 2026 [Page 9] Internet-Draft home-interfaces March 2026 The mechanism for registration is the use of COSE or JOSE over HTTPS. COSE MUST be supported and JOSE is RECOMMENDED for flexibility for non-constrained _Registrants_. The rest of this section specifies exact behavior for this interface of an HOME. 4.1. HOME Token A HOME Token MUST be encoded in either COSE or JOSE. A token MAY contain multiple layers and SHOULD have the Content-Type parameter, as part of an unprotected header, set accordingly for each. 4.1.1. Signature Layer Respective header parameters MUST be used to indicate the verification key. When the key is part of the payload (usually an HRI claim set, Section 4.2.1) a protected header parameter MUST be used (jwk for JOSE and kccs for COSE) to carry the verification key to avoid needing to parse the payload segment of the structure. For all other cases a KID parameter is used containing an HHIT, encoded per Appendix B.3, and placed in a unprotected header. 4.1.2. Encryption Layer HOME Tokens SHOULD be encrypted when the payload may contain Personally Identifiable Information (PII). For example, a HOME would not encrypt their response token (Section 4.2.2) containing relevant processing errors when the original request token (Section 4.2.1) failed to decrypt. Asymmetric algorithms MUST be supported and symmetric MAY be supported. The precise list of encryption algorithm selected and policies are left for the HOME to decide and MUST be provided to clients. Encryption is done with Elliptic Curve Diffie-Hellman (ECDH) using Ephemeral-Static (ES) keying. The static key is provided by the HOME while a unique ephemeral key is provided by the client for each HOME Token and/or recipient. The transfer of this ephemeral key is covered by the relevant COSE/JOSE specifications for using ECDH with encryption objects. The HOME MUST provide its static keys through public methods such as the DNS or an HTTPS GET endpoint. Wiethuechter Expires 17 September 2026 [Page 10] Internet-Draft home-interfaces March 2026 4.2. Claims Set A HOME Token is at its core a set of claims using a CWT or JWT claim set. The claims defined in this section are registered in the respective registries in Section 7.2 and either or both MUST be included in the claim set for HOME Tokens. A HOME Token carrying either of these claims is considered as an HRI Token or HRR Token respectively. The claim set SHOULD also contain the claims of nbf, exp, and iat. The set MAY contain the aud or iss claim with a targeted HHIT, encoded per Appendix B.3, if known. Additional claims are out of scope for this document. The layer (Section 4.1.1 or Section 4.1.2) carrying a claim set is RECOMMENDED to set the Content-Type parameter, as part of the unprotected header, to application/home+cbor or application/ home+json. This SHOULD include the ctx parameter to indicate the set of keys/parameters being used for any maps in the payload structure as they are application specific. 4.2.1. HOME Registration Inquiry (HRI) The structure of an HRI claim is around registration of a set of entities, each uniquely identified by the _Registrant_ that contains keys (also each uniquely identified) and metadata for each. inquiry = [ entities: { &(entity-id) => entity }, metadata: map / null ] entity = [ hhit_entity_type: uint, keys: { &(key-id): key }, metadata: map / null ] key = [ csr: bytes / text .b64u bytes, metadata: map / null ] Figure 3: CDDL: HOME Registration Inquiry _entities_: A map containing elements using key (_entity-id_), value (_entity_) pairs for each _entity_ being registered in the inquiry. _entity-id_: A string or integer key, as part of the _entities_ map, Wiethuechter Expires 17 September 2026 [Page 11] Internet-Draft home-interfaces March 2026 set by the _Registrant_. _entity_: An array containing the elements of _hhit_entity_type_, _keys_ and _metadata_. _hhit_entity_type_: An HHIT Entity Type as defined in the registry found at [IANA.DRIP]. _keys_: A map containing the key (_key-id_), value (_key_) pairs for the keys being registered entity in the inquiry for a given _entity_. _key-id_: A string or integer key, as part of the _keys_ map for each _entity_, set by the _Registrant_. Constrained in uniqueness to an individual HRI and the keys as part of an _entity_. _key_: An array containing the elements of _csr_ and _metadata_. _csr_: OKI(X)-compliant Certificate Signing Request (CSR) that is DER encoded. See Section 4.3.1 for considerations on the CSR. _metadata_: A map containing elements (key, value pairs) and their associated values related to keys/entities in the inquiry. The contents are subject to policy of an HOME and MUST be provided to their clients. The specific key set to be used SHOULD be indicated using the optional parameter of the registered Media Type (Section 7.8) as part of a Content-Type parameter. An initial key set is registered in Section 7.5. Each nesting in Figure 3 contains its own _metadata_. This allows a _Registrant_ to set elements at a higher nesting in the model to be shared among nested sections. When combining from each nesting level, elements found closer to the entities[entity-id].keys[key- id].metadata map are given priority. 4.2.2. HOME Registration Response (HRR) This claim is structured to use the provided _entity-id_s and _key- id_s from an HRI. It also can contain a list of failures, organized by those same identifiers. Wiethuechter Expires 17 September 2026 [Page 12] Internet-Draft home-interfaces March 2026 response = [ success: [ entities: { &(entity-id): success-data }, shared: map ] / null, failure: [ + error-data ] / null ] success-data = [ keys: { &(key-id): map }, shared: map ] error-data = [ eid: &(entity-id) / null, kid: &(key-id) / null, cat: any, msg: any ] Figure 4: CDDL: HOME Registration Response _success_: An array containing two elements: _entities_ and _shared_. MUST be null when no successful registrations issued by the HOME. _entities_: A map of elements with key (_entity-id_), value (_success-data_) pairs. _entity-id_: A string or integer key, as part of the _entities_ map, provided in an HRI from a _Registrant_. _success-data_: An array containing two elements: _keys_ and _shared_. _keys_: A map of elements with key (_key-id_), value pairs. The value of each element is a map (keys from Section 7.5) containing artifacts of the registration associated with the specific key and MUST have an element containing the Canonical Registration Certificate. _key-id_: A string or integer key, as part of the _keys_ map, provided in an HRI from a _Registrant_. _shared_: Same as the _metadata_ field of HRI except contains artifact elements provided to the _Registrant_ for successful registration that is shared amongst either a set of _keys_ or set of _entities_. _failure_: An array with at least one element of _error-data_ to Wiethuechter Expires 17 September 2026 [Page 13] Internet-Draft home-interfaces March 2026 indicate failures, null otherwise. _error-data_: An array of four elements encoding a validation or processing error of an HRI. When _eid_ or _kid_ are null it implies that all of that type are denoting the same failure explained via _cat_ and/or _msg_. When both _eid_ and _kid_ are null it indicates the processing of the HRI token itself or all keys across the HRI entities shared the same failure indicated by _cat_ and/or _msg_. See Section 4.4.1 for more details. Similar to the _metadata_ in the HRI, Figure 4 has an _shared_ map at each level for data that is the identical across different keys/ entities. When combining from each nesting level, elements found closer to those in the success.entities[entity-id].keys[key-id] map are given priority. 4.3. Considerations 4.3.1. Keys & Certificate Signing Request _Registrant_s obtains one or more Certificate Signing Requests (CSRs) that are OKI(X)-compliant by either generating their own key-pair(s), RECOMMENDED asymmetric, or obtaining them from a related party they are acting as a proxy for. Cryptographic materials SHOULD be on the device intending to use said material in operation. If the _Registrant_ is acting as a proxy the methods of the generation and/or transfer of cryptographic materials to and from the device being proxied to is out of scope for this document. If the _Registrant_ knows the HID of the _Registar_ and/or _Certificate Authority_ it wishes to be endorsed by, it SHOULD construct its HHIT accordingly and include it in the CSR per Section 6.2.1. The process of discovering a specific HID is out of scope for this document. 4.3.2. Registration Endpoint The /.well-known/home/registry endpoint SHOULD be redirected to a fully qualified path by the HOME and MUST use 308 Permanent Redirect. Wiethuechter Expires 17 September 2026 [Page 14] Internet-Draft home-interfaces March 2026 4.3.3. HRI Validation & Processing HRI validation and processing is done across two functional components, which can be co-located or distributed, the _Registrar_ and _Certificate Authority_. The following text is based on the processing of an HRI Token. The HOME in question uses a single HHIT for both its _Registrar_ and _Certificate Authority_ roles. The initial steps of decryption and signature validation are skipped as they are straightforward. Failure of either of these steps results in sending a response following Section 4.4.1. Assuming success the claim set is extracted from the HRI Token to be processed. The nbf, ext, iat, iss and aud claims are validated, and then hri claim is processed recursively starting from the outside of the structure. Each entity merges their _metadata_ with the inquiry _metadata_ with entity elements taking precedence. Next each key merges its _metadata_ with the entity _metadata_ with key elements taking precedence. The HOME performs validation of the final combined _metadata_ map for each key using local validation and/or consultation of an "oracle" (see Appendix A). Next each key CSR has its signature validated then the public key confirmed to be unique to the HOME's scope. The HOME then constructs, using its Hierarchy HID and the CSR public key, a prospective HHIT for the key. If the CSR contains an HHIT as part of the Subject Alternative Name the two HHITs are checked for equivalence. The HOME finally checks that the HHIT is unique in its scope. If everything above validates, the HOME endorses the new HHIT by generating and signing an OKI(x)-compliant Canonical Registration Certificate along with any other artifacts required for the entity registration. Any data for the _Registrant_ is then placed within the HRR success.entities[entity-id].keys[key-id] map using the same _entity-id_ and _key-id_ from the HRI. All artifacts of this endorsement are placed in the _Registry_ and artifacts that are considered public, such as those needed for [RFC9886], are placed into the _Authoritative Name Server_. When a failure occurs at any point in the validation and/or processing of a entity/key the HRR _failure_ array is appended using the _entity-id_, _key-id_ and other elements to provide context for the issue. The HOME MAY compress the _failure_ array after processing. For example if all the keys for an _entity-id_ share the same failure the individual structures can be compressed to a single [, null, , ] instead of one for each _key-id_. Wiethuechter Expires 17 September 2026 [Page 15] Internet-Draft home-interfaces March 2026 The HOME upon handling all entities and keys a HOME constructs an HRR Token and responds to the _Registrant_ with it. The token SHOULD replicate the same layering as the original HRI Token. It MAY contain both the original HRI claim and the associated HRR claim. 4.4. Transport This document defines the use of HTTPS as the transport for the HOME Tokens. The use of other transports are out of scope for this document. For COSE, the resulting CBOR content MUST use a proper CBOR Tag to indicate what object is encoded. For JOSE content, the General or Flattened JWE JSON Serialization syntax MUST be used. The "Content-Type" header of HTTPS SHOULD be used to indicate the content typing. For JOSE this is application/jose+json and for COSE is one of the following: application/cose; cose-type="cose-sign, application/cose; cose-type="cose-sign1, application/cose; cose- type="cose-encrypt, application/cose; cose-type="cose-encrypt0. 4.4.1. Response Codes For HOME Tokens with a single entity/key object the HTTP Response Codes can be easily mapped. For example a key that fails processing due to a duplicate public key or HHIT can have the HOME Token returned using 409 Conflict. It is also simple for the first stages of an HOME Token carrying an HRI since it needs to successfully be decrypted and signature(s) before processing resulting in earlier failure conditions to respond to. HOME Tokens with multiple entities/keys can be trivially mapped as well only when all entities/keys either pass or fail. Difficulty arises when a HOME Token has multiple entities/keys and not all of them fail or they all fail in different ways that can be attributed to either a 4xx or 5xx code. For the above reasoning and to maintain interoperability HOMEs MUST follow the below guidelines for management of HTTP Response Codes and using the HRR claim's _failure_ array and _error-data_ structure. Unless otherwise noted a responding HOME Token MUST use both encryption and signature layers. *422 Unprocessable Content*: When a HOME Token fails to decrypt this Wiethuechter Expires 17 September 2026 [Page 16] Internet-Draft home-interfaces March 2026 response code MUST be sent with only a signature layer (Section 4.1.1) signaling in the HRR claim the decryption issue(s) experienced. The _eid_, _kid_ and _cat_ fields MUST be set to null. The _msg_ SHOULD contains specific details about the failed decryption. More than one _error-data_ MAY be present for different decryption issues. *401 Unauthorized*: Failed signature(s) of a HOME Token MUST use this response code with the HRR claim indicating the signature validation issue(s) experienced. The _eid_, _kid_ and _cat_ fields MUST be set to null. The _msg_ SHOULD contains specific details about what signature failed to verify. More than one _error-data_ MAY be present to separate signature(s) processed. *200 OK*: This response code MUST be used to indicate the overall inquiry has been processed but that some entities and/or keys failed to be registered. The _cat_ field SHOULD be used to carry the respective 4xx or 5xx HTTP Response Code exhibited for the entities/keys to fail validation or processing. If _cat_ is not used, then clients MUST check contents of both the _success_ and _failure_ fields of the HRR. *201 Created*: A response with this code MUST be used when all entities and keys in the original HRI were registered successfully and the _failure_ in HRR MUST be set to null. *4xx or 5xx*: If all entities/keys fail with the same _cat_, used as in _200 OK_, then the HOME Token is sent using that HTTP Response Code. The _failure_ array in the HRR MUST be filled with _error- data_'s setting _eid_ and _kid_ as needed, _cat_ to null and _msg_ to any specific details for the given _eid_/_kid_ pair. 5. Differential Access Query This section details the process of query for additional private information following the Z-diagram of Figure 5. It is the lower right link of Figure 1 labeled with "RDAP" between _Querant_ and _Registry_. Wiethuechter Expires 17 September 2026 [Page 17] Internet-Draft home-interfaces March 2026 Querant HOME | | RX_HHIT | | |<-------DNS------->| RDAP_URI | | |------RDAP_Q------>| | | ACCEPT_X509? |<------DENY--------| | | POLICY_CHECK? |<------DENY--------| | | REDACTION |<-----RDAP_R-------| ACT | | | | Figure 5: Query Z-Diagram For HOME's the differential access mechanism known as Registration Data Access Protocol (RDAP, [STD95]) is selected as the interface for the _Registry_ and specified in the following sections. Public information is hosted by the _Authoritative Name Server_ and accessed using DNS methods as defined in [RFC9886]. Authentication of the HOME and _Querant_ is done through Mutual TLS using X.509 certificates. As part of RDAP, the HOME MAY follow RFC9224 to be part of the RDAP bootstrap mechanism for discovery. This is not hard requirement as the same information can be obtained through the HHIT RRType from the _Authoritative Name Server_. It is RECOMMENDED that eXtensible Access Control Markup Language (XACML) with Security Assertion Markup Language (SAML) is used to exchange policy information. 5.1. RDAP Query A _Querent_ with an HHIT looking for private information is RECOMMENDED to perform a series of DNS queries to build a URI that is then used for an HTTPS GET query. The same URI MAY be obtained using the RDAP bootstrap process if the HOME followed RFC9224, but _Querants_ MUST NOT expect this. The base URI needed is part of Subject Alternative Name extension of a Canonical Registration Certificate found in HHIT RRType defined in Section 5.1 of [RFC9886] and accessed by one or more reverse IPv6 DNS lookups. The exact certificate with the base URI for an HOME and its clients is determined by policy and where the URI is minimally duplicated across many certificates. Wiethuechter Expires 17 September 2026 [Page 18] Internet-Draft home-interfaces March 2026 Once the base URI is found the _Querant_ concatenates the /.well- known/home/query/ string then the nibble-reversed HHIT to form the full query string. The HTTPS GET method MUST be authenticated using one of the methods defined in Section 5.2. 5.1.1. Query Endpoint The /.well-known/home/query/ endpoint SHOULD be redirected to a full qualified path conforming with Section 3.1.1 of [RFC9082] (i.e. ip/) by the HOME. All other RDAP endpoints SHOULD NOT be implemented as specified in RFC9082. Other methods MAY be provided to enable differential access controlled queries of information pertaining to an HHIT but are out of scope for this document. 5.2. Differential Access Control Per REG-2 and REG-4 of Section 4.4.1 of [RFC9153], RDAP queries to an HOME 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 Section 3.2 of [RFC7481]. A federated authentication mechanism, such as the examples in Section 3.2.1 of [RFC7481], is RECOMMENDED. For international and/or global harmonization, this document standardizes the following RDAP behavior for authentication of clients and servers: * MUST support HTTP Basic or Digest Authentication Scheme per Section 3.2 of [RFC7481] *AND* * MUST support Mutual TLS per Section 7.4.6 of [RFC5246] for global and/or international queries *AND* * SHOULD use Mutual TLS but MAY do any RDAP compatible AAA for domestic queries An HOME, when supporting Mutual TLS, SHOULD accept valid OKIX- compliant certificates and MAY accept other [RFC5280] (PKIX) compliant certificates. Standard TLS rejection methods MUST be followed to signal to the _Querant_ the rejection of the certificate and authentication. The use of other RDAP compatible authentication mechanisms are out of scope for this document. Wiethuechter Expires 17 September 2026 [Page 19] Internet-Draft home-interfaces March 2026 5.3. RDAP Extension & Response A HOME MUST respond to a successful query using RFC9083. The HOME RDAP Extension shown in Figure 6 is placed under the key home as part of the main JSON map. The rdapConformance array MUST include the string literal of "home_v0" to signal conformance with this specification. Other RDAP specifications MAY be part of the response such as Section 5.4 of [RFC9083]. [ hhit: [ ip6: text, hhit_entity_type: uint ], canon_x: text .b64u bytes, metadata: map / null ] Figure 6: CDDL: HOME RDAP Extension _hhit_: Array structure contain the HHIT Entity Type and the HHIT encoded per Appendix B.3. _canon_x_: Canonical Registration Certificate encoded in base64url. _metadata_: Map that contains private information elements associated with the registration. Elements included are based on access policy and registration requirements of the HOME. Elements are redacted or removed using policy methods of the HOME and is out of scope for this document. 6. ORCHID Key Infrastructure (OKI) The ORCHID Key Infrastructure (OKI) is focused on the delegation and management of the Hierarchy ID field of an HHIT and its levels. There are two types of nodes in the hierarchy, Root and Inode, and relationships between nodes use tree terminology such as ancestor, descendant and degree. Additional, more administrative members, include the IPv6 Prefix and Apex. The relationship between these entities (and their Authorization and Issuing HHITs) are shown in Figure 7. +-----------------------------+ | Apex | | Authorization(s) o........ +-o----o----------------o-----+ : : : : : : .-o---------. .-o---------. : : | Apex | | Apex | : : | Issuing #1 | | Issuing #N | : Wiethuechter Expires 17 September 2026 [Page 20] Internet-Draft home-interfaces March 2026 : '--o------o-' '-----------' : : : : : : : .-o------------. : : : | Operational #1 | : : : '--------------' : : .-o------------. : : | Operational #N | : : '--------------' : : : +-o---------------------------+ +-o---------------------------+ | HID Root A | | HID Root B | | Authorization(s) o.....o Authorization(s) | +-*----o----------------o-----+ +-*------o--------------------+ | : : | : | .-o---------. .-o---------. | .-o---------. | | HID Root A | | HID Root A | | | HID Root B | | | Issuing #1 | | Issuing #N | | | Issuing #1 | | '--o------o-' '-----------' | '--o------o-' | : : | : : | : .-o------------. | : .-o------------. | : | Operational #1 | | : | Operational #1 | | : '--------------' | : '--------------' | .-o------------. | .-o------------. | | Operational #N | | | Operational #N | | '--------------' | '--------------' | | +-o---------------------------+ +-o---------------------------+ | HID Inode A | | HID Inode B | | Authorization(s) o.....o Authorization(s) | +-o----o----------------o-----+ +-o------o--------------------+ | : : | : | .-o----------. .-o----------. | .-o----------. | | HID Inode A | | HID Inode A | | | HID Inode B | | | Issuing #1 | | Issuing #N | | | Issuing #1 | | '--o------o--' '------------' | '--o------o--' | : : | : : | : .-o------------. | : .-o------------. | : | Operational #1 | | : | Operational #1 | | : '--------------' | : '--------------' | .-o------------. | .-o------------. | | Operational #N | | | Operational #N | | '--------------' | '--------------' | | +-*---------------------------+ +-*---------------------------+ | HID Leaf A | | HID Leaf B | | Authorization(s) o.....o Authorization(s) | +-------*----------------o----+ +--------*--------------------+ : : : Wiethuechter Expires 17 September 2026 [Page 21] Internet-Draft home-interfaces March 2026 .-*----------. .-o----------. .-*---------. | HID Leaf A | | HID Leaf A | | HID Leaf B | | Issuing #1 | | Issuing #N | | Issuing #1 | '--*------*--' '------------' '--*------*-' | : | : | .-*------------. | .-*------------. | | Operational #1 | | | Operational #1 | | '--------------' | '--------------' .-*------------. .-*------------. | Operational #N | | Operational #N | '--------------' '--------------' Figure 7: ORCHID Key Infrastructure (OKI) Hierarchy In Figure 7 the solid connections are REQUIRED and dotted connections are OPTIONAL. A two-level hierarchy will consist of only a Root and Leaf level with no Inodes, shown in Figure 7 with a solid line but open connection point between its ancestor and descendant. Also note that Figure 7 shows two distinct paths in the hierarchy, to illustrate OPTIONAL cross-endorsement, for simplicity. IPv6 Prefix: This level is not directly part of the OKI but performs the primary function of delegating reverse IPv6 zone(s) associated with Root Hierarchy ID values to respective Apexes or performing DNS delegations on an Apex's behalf. Apex: An administrative owner of a set of Root Hierarchy ID values. The Apex performs assignment and/or allocation of these values and either delegates management of the reverse IPv6 zone(s) back to the IPv6 Prefix or manages it themselves. The Apex MAY have an Authorization HHIT, with a self-signed endorsement, as part of the function to endorse membership into a hierarchy. Root: The first level of a Hierarchy ID, with descendant levels set to 0. It MUST have at least one Authorization HHIT to be used to obtain membership into the hierarchy and is either self-signed or endorsed by an Apex. A Root is the administrative entity that assigns/allocates the next level in the hierarchy to a descendant and manages the applicable reverse IPv6 zone(s). The endorsement of a descendant membership into the hierarchy MUST be performed using an Authorization HHIT endorsed by the direct ancestor. To support the endorsement of operational entities under the Root Hierarchy ID, the Root SHOULD use one or more Issuing HHITs that are endorsed by Root Authorization HHITs. Inode: A middle level node that has both an ancestor and descendant Wiethuechter Expires 17 September 2026 [Page 22] Internet-Draft home-interfaces March 2026 in the Hierarchy ID. It MUST have at least one Authorization HHIT to be used to obtain membership into the hierarchy and MUST be endorsed by a direct ancestor. An Inode is the administrative entity that assigns/allocates the next level in the hierarchy to a descendant and manages the applicable reverse IPv6 zone(s). To support the endorsement of operational entities under the Inode Hierarchy ID, the Inode SHOULD use one or more Issuing HHITs that are endorsed by Inode Authorization HHITs. Leaf: The last level of a Hierarchy ID. It MUST have at least one Authorization HHIT to be used to obtain membership into the hierarchy and MUST be endorsed by a direct ancestor. A Leaf node is the administrative entity that registers operational entities and manages the applicable reverse IPv6 zone(s). To support the endorsement of operational entities under the Leaf Hierarchy ID, the Leaf MUST use one or more Issuing HHITs that are endorsed by Leaf Authorization HHITs. This document allocates two new HHIT Entity Types in each level of hierarchy, one for Authorization and one for Issuing (Section 7.4). 6.1. Hierarchy Responsibilities An HOME has a number of responsibilities depending on its place in the hierarchy. This section covers the technical responsibilities of each level of an HHIT's hierarchy. Specific non-technical policies for hierarchy levels are out of scope for this document and are expected to be developed into OKI policy guidance or added to existing PKI policy guidance for each use-case. +==================+===============+============+==============+====+ | Responsibility | Apex |Root | Inode |Leaf| +==================+===============+============+==============+====+ | provide using | MUST |MUST | MUST |MUST| | public methods | | | | | | any | | | | | | requirements, | | | | | | policy and/or | | | | | | guidance to | | | | | | prospective | | | | | | descendants | | | | | +------------------+---------------+------------+--------------+----+ | provide OKIX- | MAY |MUST | MUST |MUST| | compatible | _see *1+ | | | | | certificate(s) | Authorization | | | | | as endorsement | HHIT*_ | | | | | for | | | | | | registration of | | | | | Wiethuechter Expires 17 September 2026 [Page 23] Internet-Draft home-interfaces March 2026 | descendant(s) | | | | | +------------------+---------------+------------+--------------+----+ | maintain | MUST |MUST | MUST |MUST| | registrations | | | | | | with relevant | | | | | | Personally | | | | | | Identifiable | | | | | | Information | | | | | | (PII) as | | | | | | required by | | | | | | their | | | | | | jurisdiction | | | | | +------------------+---------------+------------+--------------+----+ | fulfill any | MUST |MUST | MUST |MUST| | jurisdiction | | | | | | requirements | | | | | | that are out of | | | | | | scope for this | | | | | | document | | | | | +------------------+---------------+------------+--------------+----+ | support | - |MAY | MAY |MAY | | [RFC7401] | | | | | | _MAY support | | | | | | services using | | | | | | [RFC8003] such | | | | | | as [RFC8004]_ | | | | | +------------------+---------------+------------+--------------+----+ | 1+ | MAY |MUST | MUST |MUST| | Authorization | | | | | | HHIT | | | | | | _see Table 2_ | | | | | +------------------+---------------+------------+--------------+----+ | 1+ Issuing HHIT | MAY |MAY | SHOULD |MUST| | _MUST have same | | | | | | Hierarchy ID as | | | | | | an | | | | | | Authorization | | | | | | HHIT_ | | | | | | _MUST be | | | | | | locally | | | | | | registered | | | | | | using an | | | | | | Authorization | | | | | | HHIT_ | | | | | +------------------+---------------+------------+--------------+----+ | cross-endorse | - |MAY | MAY |MAY | | with siblings | | | | | | _MUST use an | | | | | Wiethuechter Expires 17 September 2026 [Page 24] Internet-Draft home-interfaces March 2026 | Authorization | | | | | | HHIT_ | | | | | +------------------+---------------+------------+--------------+----+ | maintain | SHOULD |MUST | MUST |MUST| | reverse IPv6 | _or delegate | | | | | zone(s) | back to the | | | | | | IPv6 Prefix_ | | | | +------------------+---------------+------------+--------------+----+ | assign/allocate | MUST |MUST | MUST |- | | values in the X | _X=Root_ |_X=Inode_ | _X=Inode or | | | level of | | | Leaf_ | | | hierarchy in | | | | | | the Hierarchy | | | | | | ID | | | | | | _see Table 3_ | | | | | +------------------+---------------+------------+--------------+----+ | implement | MAY |SHOULD | SHOULD |MUST| | Section 4 and | _or 501 Not |_or 501 Not | _or 501 Not | | | Section 5 | Implemented_ |Implemented_| Implemented_ | | +------------------+---------------+------------+--------------+----+ Table 1: Hierarchy Responsibilities +=================================+======+===========+=======+======+ | 1+ Authorization HHIT | Apex | Root | Inode | Leaf | +=================================+======+===========+=======+======+ | set Hierarchy ID to | MUST | MUST NOT | MUST | MUST | | all zeros | | | NOT | NOT | +---------------------------------+------+-----------+-------+------+ | set Hierarchy ID to | MUST | MUST | MUST | MUST | | assignment/allocation | NOT | | | | | from ancestor | | | | | +---------------------------------+------+-----------+-------+------+ | self register | MUST | if *Apex* | MUST | MUST | | | | MUST then | NOT | NOT | | | | MUST NOT | | | +---------------------------------+------+-----------+-------+------+ | registered to direct | MUST | if *Apex* | MUST | MUST | | ancestor | NOT | MUST NOT | | | | | | then MUST | | | +---------------------------------+------+-----------+-------+------+ Table 2: Additional Responsibilities for 1+ Authorization HHIT Wiethuechter Expires 17 September 2026 [Page 25] Internet-Draft home-interfaces March 2026 +=========================+================+========+========+======+ | Assign/allocate values | Apex | Root | Inode | Leaf | | in Hierarchy ID | | | | | +=========================+================+========+========+======+ | verify prospective | SHOULD | SHOULD | SHOULD | - | | descendant(s) for | | | | | | hierarchy membership | | | | | +-------------------------+----------------+--------+--------+------+ | register descendant(s) | MAY | MUST | MUST | - | | hierarchy members | | | | | | using an Authorization | | | | | | HHIT | | | | | +-------------------------+----------------+--------+--------+------+ | delegate corresponding | SHOULD | MUST | MUST | - | | reverse IPv6 zone(s) | _see *maintain | | | | | to descendant(s) | reverse IPv6 | | | | | | zone(s)*_ | | | | +-------------------------+----------------+--------+--------+------+ Table 3: Additional Responsibilities for Assign/allocate values in Hierarchy ID 6.2. ORCHID Key Infrastructure X.509 (OKIX) Existing Public Key Infrastructure X.509 (PKIX) certificate profiles can be augmented to support HHITs creating ORCHID Key Infrastructure X.509 (OKIX) profiles. Other X.509 fields and OIDs MAY be required in a given jurisdiction. This is up to the original PKI(X) policy if applicable and is out of scope for this document. 6.2.1. Signing Request The Certificate Signing Request is mandatory for all HHIT registrations. Depending on the entity being registered, there is specific content rules. Certificate Request: Data: Version: 1 (0x0) Subject: Subject Public Key Info: Attributes: Requested Extensions: X509v3 Subject Alternative Name: critical IP Address: Signature Algorithm: Wiethuechter Expires 17 September 2026 [Page 26] Internet-Draft home-interfaces March 2026 Figure 8: Certificate Signing Request Profile _Subject_: As defined in Section 4.1.2.6 of [RFC5280]. This field is filled in based on the HHIT Entity Type being registered and subject to policy of the Certificate Authority. _Subject Alternative Name IP6_: When the registrant knows which HID and/or Suite ID they want the CSR SHOULD contain the Subject Alternate Name extension as defined in Section 4.2.1.6 of [RFC5280] using ipAddress containing the fully formed HHIT and MUST mark the extension as critical. The HOME MUST check to ensure that the HHIT 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 HOME will use its HID for HHIT generation using the public key provided by this CSR. The use of other Extension fields are out of scope for this document. 6.2.2. Certificate: Lite Profile OKIX-Lite is designed to fully encapsulate an OKI in the smallest reasonable X.509 certificates (e.g. 240 bytes for DER), but still adhere to [RFC5280] MUST field usage. The profile can be found in Figure 9 and a field matrix found in Table 4. Certificate: Data: Version: 3 (0x2) Serial Number: <1 byte in size> Signature Algorithm: Issuer: CN = Validity Not Before: Not After : Subject: Subject Public Key Info: X509v3 extensions: X509v3 Subject Alternative Name: critical IP Address: Signature Algorithm: Figure 9: OKIX-Lite Profile Wiethuechter Expires 17 September 2026 [Page 27] Internet-Draft home-interfaces March 2026 +==============+===============+=========+=============+============+ | Field | Authorization | Issuing | Operational | Comments | +==============+===============+=========+=============+============+ | Serial | MUST | MUST | MUST | Section | | Number | | | | 6.2.4.1.1 | +--------------+---------------+---------+-------------+------------+ | Subject | MUST | MUST | MUST NOT | Section | | | | | | 6.2.4.2 | +--------------+---------------+---------+-------------+------------+ | Issuer | MUST | MUST | MUST | Section | | | | | | 6.2.4.3 | +--------------+---------------+---------+-------------+------------+ | Subject | MUST | MUST | MUST | Section | | Alternative | | | | 6.2.4.4 | | Name IP6 | | | | | +--------------+---------------+---------+-------------+------------+ | Subject | MAY | MAY | MAY | Section | | Alternative | | | | 6.2.4.5 | | Name URI | | | | | +--------------+---------------+---------+-------------+------------+ | Basic | MUST | MUST | MUST NOT | CA=True, | | Constraints | | | | flagged | | | | | | as | | | | | | Critical | +--------------+---------------+---------+-------------+------------+ | Subject Key | MUST NOT | MUST | MUST NOT | - | | Identifier | | NOT | | | +--------------+---------------+---------+-------------+------------+ | Authority | MUST NOT | MUST | MUST NOT | - | | Key | | NOT | | | | Identifier | | | | | +--------------+---------------+---------+-------------+------------+ | Key Usage | MAY | MAY | MAY | - | +--------------+---------------+---------+-------------+------------+ | _Certificate | MAY | MAY | MAY | - | | Authority_ | | | | | | Policy OIDs | | | | | +--------------+---------------+---------+-------------+------------+ Table 4: OKIX-Lite Field Matrix 6.2.3. Certificate: Full Profile The X.509 certificates are minimalistic (less than 400 bytes for DER). The profile can be found in Figure 10 and a field matrix found in Table 5. This profile MUST be used as the Canonical Registration Certificate in the DNS. Wiethuechter Expires 17 September 2026 [Page 28] Internet-Draft home-interfaces March 2026 Certificate: Data: Version: 3 (0x2) Serial Number: <20 bytes in size> Signature Algorithm: Issuer: CN = Validity Not Before: Not After : Subject: Subject Public Key Info: X509v3 extensions: X509v3 Subject Alternative Name: critical IP Address: URI: X509v3 Subject Key Identifier: X509v3 Authority Key Identifier: X509v3 Basic Constraints: critical X509v3 Key Usage: critical Signature Algorithm: Figure 10: OKIX-Full Profile Wiethuechter Expires 17 September 2026 [Page 29] Internet-Draft home-interfaces March 2026 +==============+===============+===========+=============+==========+ | Field | Authorization |Issuing | Operational |Comments | +==============+===============+===========+=============+==========+ | Serial | MUST |MUST | MUST |Section | | Number | | | |6.2.4.1.2 | +--------------+---------------+-----------+-------------+----------+ | Subject | MUST |MUST | MUST NOT |Section | | | | | |6.2.4.2 | +--------------+---------------+-----------+-------------+----------+ | Issuer | MUST |MUST | MUST |Section | | | | | |6.2.4.3 | +--------------+---------------+-----------+-------------+----------+ | Subject | MUST |MUST | MUST |Section | | Alternative | | | |6.2.4.4 | | Name IP6 | | | | | +--------------+---------------+-----------+-------------+----------+ | Subject | MAY |MAY | MAY |Section | | Alternative | | | |6.2.4.5 | | Name URI | | | | | +--------------+---------------+-----------+-------------+----------+ | Basic | MUST |MUST | MUST NOT |CA=True, | | Constraints | | | |flagged | | | | | |as | | | | | |Critical | +--------------+---------------+-----------+-------------+----------+ | Subject Key | MUST |MUST | MUST NOT |Section | | Identifier | | | |6.2.4.6 | +--------------+---------------+-----------+-------------+----------+ | Authority | MUST |MUST | MUST |Section | | Key | | | |6.2.4.7 | | Identifier | | | | | +--------------+---------------+-----------+-------------+----------+ | Key Usage | SHOULD |SHOULD | SHOULD |- | +--------------+---------------+-----------+-------------+----------+ | _Certificate | RECOMMENDED |RECOMMENDED| RECOMMENDED |- | | Authority_ | | | | | | Policy OIDs | | | | | +--------------+---------------+-----------+-------------+----------+ Table 5: OKIX-Full Field Matrix 6.2.4. Certificate Fields The following sections contain clarifications on the usage of fields in the OKIX when they deviate from "standard" X.509 [RFC5280] practice. Wiethuechter Expires 17 September 2026 [Page 30] Internet-Draft home-interfaces March 2026 6.2.4.1. Serial Number 6.2.4.1.1. Lite The Serial Number is a MUST field, but it has no usage in the Lite profile. It is 1-byte in size and thus duplicates are guaranteed. To drop this field could make many X.509 parsing libraries fail. However, _Certificate Authority_ 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 _Certificate Authority_s. If Serial Numbers are incrementally assigned, 31 bits are sufficient for an Issuing _Certificate Authority_ with 2 billion HHITs active. A _Certificate Authority_ should determine its best-used Serial Number field size to limit the impact of this field on the certificate size. 6.2.4.1.2. Full The certificates MUST contain a 20-byte randomly generated Serial Number, compliant with CABForum recommendations. Serial Numbers are included for CRL functionality. 6.2.4.2. Subject The Subject field is only used in Authorization and Issuing certificates. For Operational certificates, the Subject MUST be empty and the HHIT will be in Subject Alternative Name (Section 6.2.4.4). In the Subject Alternative Name, the HHIT can be properly encoded as an IPv6 address. The contents of the Subject when used are determined by policy and is out of scope for this document. 6.2.4.3. Issuer The Issuer MUST be the higher level's HHIT. The Issuer for the Apex Authorization certificate MUST be its HHIT (indicating self-signed). If the RAA Authorization certificate is self-signed (i.e., no Apex), its Issuer is its HHIT. The Issuer content of its HHIT assists in finding this specific Issuer in the ip6.arpa. DNS tree and any additional information. The exact information that is provide is out of scope for this document. Wiethuechter Expires 17 September 2026 [Page 31] Internet-Draft home-interfaces March 2026 6.2.4.4. Subject Alternative Name IP6 Subject Alternative Name is only used in Operational certificates. It is used to provide the HHIT as an IP address with an Empty Subject (Subject Alternative Name MUST be flagged as Critical). 6.2.4.5. Subject Alternative Name URI This field contains a pointer in the form of a URI where additional information on the _Certificate Authority_ and certificates under its control can be found. The contents MUST be a base URL containing at least the fields scheme, host and port to query for additional information of a HHIT. Authorization certificates MAY have a Subject Alternative Name URI and MUST when it is self-signed. Issuing certificates SHOULD have a Subject Alternative Name URI. Operational certificates MAY have a Subject Alternative Name URI. The RECOMMENDED configuration with respect to Issuing and Operational certificates for a _Certificate Authority_ is to place the Subject Alternative Name URI in the Issuing certificate and exclude them in Operational certificates. When multiple providers are used by the _Certificate Authority_ to handle additional information there SHOULD be a unique Issuing certificate with Subject Alternative Name URI for each provider, and Operational certificates MUST NOT contain a Subject Alternative Name URI. Otherwise a _Certificate Authority_ with multiple providers MUST NOT have a Subject Alternative Name URI in the Issuing certificate and MUST set the Subject Alternative Name URI to the specific provider for each Operational certificate. 6.2.4.6. Subject Key Identifier The Subject Key Identifier MUST be the HHIT. 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 Section 6.2.4.4. Wiethuechter Expires 17 September 2026 [Page 32] Internet-Draft home-interfaces March 2026 6.2.4.7. Authority Key Identifier The Authority Key Identifier MUST be the higher level's Subject Key Identifier (i.e. HHIT). 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). 7. IANA Considerations 7.1. Well-Known URIs IANA is requested to add the following entries in the "Well-Known URIs" registry [IANA.WellKnownURIs]. +============+============+===========+===========+=============+ | URI Suffix | Change | Reference | Status | Related | | | Controller | | | Information | +============+============+===========+===========+=============+ | home/ | IETF | This RFC | permanent | N/A | | register | | | | | +------------+------------+-----------+-----------+-------------+ | home/query | IETF | This RFC | permanent | N/A | +------------+------------+-----------+-----------+-------------+ | home/oaas | IETF | This RFC | permanent | N/A | +------------+------------+-----------+-----------+-------------+ Table 6: Additions to Well-Known URIs Registry Author Note: should we also add Well-Known URIs for update and delete methods? This would then cover all parts of CRUD. 7.2. CWT & JWT Claims HOME Tokens contain a Claim Set compatible with those of CWT and JWT, so the CWT and JWT Claims registries, [IANA.CWT.Claims] and [IANA.JWT.Claims], are reused. No new IANA registry is created. Per this specification, the following values are requested to be added to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token (CWT) Claims" registry established by [RFC8392]. Each entry is requested to be added to both registries. The "Claim Description", "Change Controller", and "Reference" fields are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Type" fields are for Wiethuechter Expires 17 September 2026 [Page 33] Internet-Draft home-interfaces March 2026 the CWT registry only. The "Claim Name" field is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" field is equivalent to the "Claim Name" field in the JWT registry. Claim Name: HOME Registration Inquiry Claim Description: HOME Registration Inquiry JWT Claim Name: hri Claim Key: TBD1 Claim Value Type: array Change Controller: IETF Reference: This RFC Figure 11: HOME Registration Inquiry Claim: Registration Form Claim Name: HOME Registration Response Claim Description: HOME Registration Response JWT Claim Name: hrr Claim Key: TBD2 Claim Value Type: array Change Controller: IETF Reference: This RFC Figure 12: HOME Registration Response Claim: Registration Form 7.3. RDAP Extensions Registry IANA is requested to register the following value in the "RDAP Extensions" registry [IANA.RDAP.Extensions]. Extension Identifier: home_v0 Registry Operator: Any Specification: This specification Contact: IETF Intended Usage: This extension is used to convey private information stored under a HOME registration. Figure 13: RDAP Extensions: Registration Form 7.4. HHIT Entity Types IANA is requested to make the following changes to the "HHIT Entity Types" registry under [IANA.DRIP] to align with Table 7. Wiethuechter Expires 17 September 2026 [Page 34] Internet-Draft home-interfaces March 2026 +=======+=================+==============+=============+===========+ | Value | HHIT Entity | Abbreviation | Operational | Reference | | | Type | | (Y/N) | | +=======+=================+==============+=============+===========+ | 0 | Undefined | UKN | N | [RFC9886] | +-------+-----------------+--------------+-------------+-----------+ | 1 | Hierarchical | HOME | N | This RFC | | | ORCHID | | | | | | Management | | | | | | Entity | | | | +-------+-----------------+--------------+-------------+-----------+ | 2 | Hierarchical | HOME-A | N | This RFC | | | ORCHID | | | | | | Management | | | | | | Entity: | | | | | | Authorization | | | | +-------+-----------------+--------------+-------------+-----------+ | 3 | Hierarchical | HOME-I | N | This RFC | | | ORCHID | | | | | | Management | | | | | | Entity: Issuing | | | | +-------+-----------------+--------------+-------------+-----------+ | 4 | HOME Apex | APEX | N | [RFC9886] | +-------+-----------------+--------------+-------------+-----------+ | 5 | HOME Apex: | APEX-A | N | This RFC | | | Authorization | | | | +-------+-----------------+--------------+-------------+-----------+ | 6 | HOME Apex: | APEX-I | N | This RFC | | | Issuing | | | | +-------+-----------------+--------------+-------------+-----------+ | 7 | DRIP Identity | DIME | N | [RFC9886] | | | Management | | | | | | Entity | | | | +-------+-----------------+--------------+-------------+-----------+ | 8 | DRIP Identity | DIME-A | N | This RFC | | | Management | | | | | | Entity: | | | | | | Authorization | | | | +-------+-----------------+--------------+-------------+-----------+ | 9 | DRIP Identity | DIME-I | N | This RFC | | | Management | | | | | | Entity: Issuing | | | | +-------+-----------------+--------------+-------------+-----------+ | 10 | Registered | RAA | N | [RFC9886] | | | Assigning | | | | | | Authority | | | | +-------+-----------------+--------------+-------------+-----------+ | 11 | Registered | RAA-A | N | This RFC | Wiethuechter Expires 17 September 2026 [Page 35] Internet-Draft home-interfaces March 2026 | | Assigning | | | | | | Authority: | | | | | | Authorization | | | | +-------+-----------------+--------------+-------------+-----------+ | 12 | Registered | RAA-I | N | This RFC | | | Assigning | | | | | | Authority: | | | | | | Issuing | | | | +-------+-----------------+--------------+-------------+-----------+ | 13 | HHIT Domain | HDA | N | [RFC9886] | | | Authority | | | | +-------+-----------------+--------------+-------------+-----------+ | 14 | HHIT Domain | HDA-A | N | This RFC | | | Authority: | | | | | | Authorization | | | | +-------+-----------------+--------------+-------------+-----------+ | 15 | HHIT Domain | HDA-I | N | This RFC | | | Authority: | | | | | | Issuing | | | | +-------+-----------------+--------------+-------------+-----------+ | 16 | Unmanned | UA | Y | [RFC9886] | | | Aircraft | | | | +-------+-----------------+--------------+-------------+-----------+ | 17 | Ground Control | GCS | Y | [RFC9886] | | | Station | | | | +-------+-----------------+--------------+-------------+-----------+ | 18 | Unmanned | UAS | Y | [RFC9886] | | | Aircraft System | | | | +-------+-----------------+--------------+-------------+-----------+ | 19 | Remote | RID | Y | [RFC9886] | | | Identification | | | | | | Module | | | | +-------+-----------------+--------------+-------------+-----------+ | 20 | UAS Pilot | PILOT | Y | [RFC9886] | +-------+-----------------+--------------+-------------+-----------+ | 21 | UAS Operator | OP | Y | [RFC9886] | +-------+-----------------+--------------+-------------+-----------+ | 22 | Discovery & | DSS | Y | [RFC9886] | | | Synchronization | | | | | | Service | | | | +-------+-----------------+--------------+-------------+-----------+ | 23 | UAS Service | USS | Y | [RFC9886] | | | Supplier | | | | +-------+-----------------+--------------+-------------+-----------+ | 24 | Network RID | DP | Y | [RFC9886] | | | Service | | | | | | Provider | | | | +-------+-----------------+--------------+-------------+-----------+ Wiethuechter Expires 17 September 2026 [Page 36] Internet-Draft home-interfaces March 2026 | 25 | Network RID | SP | Y | [RFC9886] | | | Display | | | | | | Provider | | | | +-------+-----------------+--------------+-------------+-----------+ | 26 | Supplemental | SDSP | Y | [RFC9886] | | | Data Service | | | | | | Provider | | | | +-------+-----------------+--------------+-------------+-----------+ | 27 | Crowd Sourced | FINDER | Y | [RFC9886] | | | RID Finder | | | | +-------+-----------------+--------------+-------------+-----------+ Table 7: Updated HHIT Entity Type Registry The above changes include two new fields for "Abbreviation" and "Operational (Y/N)", re-arrangement of the first 15 values and addition of entries for Authorization and Issuing for applicable entity types. 7.5. HOME Parameters This document requests IANA create a new registry under [IANA.DRIP] called "HOME Parameters" with registry policies described in Table 8. +======================+==========================+ | Range | Registration Policy | +======================+==========================+ | Integers less than 0 | delegated to HOME Common | | | Parameters registry | +----------------------+--------------------------+ | Integers greater | Reserved | | than -1 | | +----------------------+--------------------------+ Table 8: HOME Parameters: Registry Policies The positive integer values (including zero) MUST NOT be directly allocated. Instead new registries for specific use-case parameters/ keys are created, inherit the HOME Common Parameter registry (Section 7.6) for negative values, and setup new allocation schemes for the positive integers in their scope. See Section 7.7 for an example. Such a new registry SHOULD have an associated Media Type to allow participants a mechanism to explicitly provide context for the parameter set in use. Wiethuechter Expires 17 September 2026 [Page 37] Internet-Draft home-interfaces March 2026 7.5.1. Registry Fields _Key_: Title of the key. _Description_: A short description of the entry providing an overview of its semantic meaning and its expected use-cases. _Name_: 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_: A integer value to be used as a key in a CBOR map. _Value Type_: CBOR/JSON typing for value under the Key. _Change Controller_: TDB _Reference_: A link to a permanent and readily available specification defining the value syntax and semantics to be used for this key. 7.5.2. Registration Form Key: Description: Name: Label: Value Type: Change Controller: Reference: Figure 14: HOME Parameters: Registration Form 7.5.2.1. Review Criteria For a Key the specified value of a new registration should not duplicate the syntax and/or semantics of an existing registration. For the Name parameter of the Key, a new registration MUST NOT duplicate an existing registration Name. Value Type MUST be a valid CBOR type or from [IANA.CBOR.Tags]. Their typing in JSON is assumed to follow the translation from CBOR to JSON following Section 6 of [RFC8949]. Wiethuechter Expires 17 September 2026 [Page 38] Internet-Draft home-interfaces March 2026 7.6. HOME Common Parameters This document requests IANA create a new registry under [IANA.DRIP] called "HOME Common Parameters" with registry policies described in Table 9. Initial entries for this registry are in Figure 15 and uses the registration form of Section 7.5.2. +===========================+============================+ | Range | Registration Policy | +===========================+============================+ | Integers less than -65536 | Private Use (Section 4.2 | | | of [RFC8126]) | +---------------------------+----------------------------+ | Integers in the range | Specification Required | | -257 to -65536 | (Section 4.7 of [RFC8126]) | +---------------------------+----------------------------+ | Integers in the range -1 | Standard Action | | to -256 | (Section 4.9 of [RFC8126]) | +---------------------------+----------------------------+ Table 9: HOME Common Parameters: Registry Policies Key: HHIT Description: Hierarchial Host Identity Tag & Entity Type Name: hhit Label: -1 Value Type: array Change Controller: IETF Reference: This RFC Key: VNB Description: Valid Not Before Name: vnb Label: -2 Value Type: tdate / time Change Controller: IETF Reference: This RFC Key: VNA Description: Valid Not After Name: vna Label: -3 Value Type: tdate / time / number Change Controller: IETF Reference: This RFC Key: Publish Description: Boolean to publish to DNS Wiethuechter Expires 17 September 2026 [Page 39] Internet-Draft home-interfaces March 2026 Name: publish Label: -4 Value Type: bool Change Controller: IETF Reference: This RFC Key: Certificate Signing Request (CSR) Description: DER Encoded X.509 CSR Name: csr Label: -5 Value Type: bytes Change Controller: IETF Reference: This RFC Key: Oracle Certificate Description: DER Encoded Oracle X.509 Certificate Name: oracle_x Label: -6 Value Type: bytes Change Controller: IETF Reference: This RFC Key: Canonical Certificate Description: DER Encoded X.509 Certificate Name: canon_x Label: -7 Value Type: bytes Change Controller: IETF Reference: This RFC Key: Canonical Certificate Chain Description: List of DER Encoded X.509 Certificates Name: canon_chain Label: -8 Value Type: array Change Controller: IETF Reference: This RFC Key: Contact Description: Base64 Encoded jCard Contact Information Name: contact Label: -9 Value Type: text Change Controller: IETF Reference: This RFC Figure 15: Initial HOME Common Parameters Wiethuechter Expires 17 September 2026 [Page 40] Internet-Draft home-interfaces March 2026 7.7. HOME Aviation Parameters This document requests IANA create a new registry under [IANA.DRIP] called "HOME Aviation Parameters" with registry policies described in Table 10. Initial entries for this registry are in Figure 16 and uses the registration form of Section 7.5.2. When using this registry the "ctx" parameter of Section 7.8 is set to "aviation". +======================+============================+ | Range | Registration Policy | +======================+============================+ | Integers less than 0 | delegated to HOME Common | | | Parameters registry | +----------------------+----------------------------+ | Integers in the | Specification Required | | range 0 to 65535 | (Section 4.7 of [RFC8126]) | +----------------------+----------------------------+ | Integers greater | First Come First Served | | than 65535 | (Section 4.3 of [RFC8126]) | +----------------------+----------------------------+ Table 10: HOME Aviation Parameters: Registry Policies Key: UAS Type Description: ASTM F3411 UAS Type Enumeration Name: uas_type Label: 0 Value Type: uint Change Controller: IETF Reference: Section 5.2 of RFC9886 Key: UAS Identifiers Description: UAS ID Type & Value Pairs Name: uas_ids Label: 1 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Key: Authentication Data Description: Authentication Type & Data Pairs Name: auths Label: 2 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Wiethuechter Expires 17 September 2026 [Page 41] Internet-Draft home-interfaces March 2026 Key: Self ID Description: Self Description Type & Value Name: self_id Label: 3 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Key: UAS Classification Description: UAS Category & Class Name: classification Label: 4 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Key: Area Description: Count, Radius, Floor & Ceiling Name: area Label: 5 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Key: Operator ID Description: UAS Pilot Operator ID Name: operator_id Label: 6 Value Type: array Change Controller: IETF Reference: Section 5.2 of RFC9886 Figure 16: Initial HOME Aviation Parameters 7.8. Media Types IANA is requested to add the entries of Table 11 to the "Media Types" registry [IANA.MediaTypes]. +===========+=======================+=========================+ | Name | Template | Reference | +===========+=======================+=========================+ | home+cbor | application/home+cbor | This RFC, Section 7.8.1 | +-----------+-----------------------+-------------------------+ | home+json | application/home+json | This RFC, Section 7.8.2 | +-----------+-----------------------+-------------------------+ Table 11: New Media Types Wiethuechter Expires 17 September 2026 [Page 42] Internet-Draft home-interfaces March 2026 7.8.1. application/home+cbor Type name: application Subtype name: home+cbor Required parameters: N/A Optional parameters: "ctx" (Context as a string for map keys. Case insensitive.) Encoding considerations: binary Security considerations: N/A Interoperability considerations: N/A Published specification: This RFC Applications that use this media type: Entities that exchange CBOR/COSE data as part of HOME interactions. Fragment identifier considerations: N/A Person & email address to contact for further information: DRIP WG mailing list (tmrid@ietf.org) Intended usage: Common Restrictions on usage: None Author/Change controller: IETF Provisional registration: No Figure 17: home+cbor Media Type Registration 7.8.2. application/home+json Wiethuechter Expires 17 September 2026 [Page 43] Internet-Draft home-interfaces March 2026 Type name: application Subtype name: home+json Required parameters: N/A Optional parameters: "ctx" (Context as a string for map keys. Case insensitive.) Encoding considerations: same as STD90 Security considerations: N/A Interoperability considerations: N/A Published specification: This RFC Applications that use this media type: Entities that exchange JOSE/JSON data as part of HOME interactions. Fragment identifier considerations: N/A Person & email address to contact for further information: DRIP WG mailing list (tmrid@ietf.org) Intended usage: Common Restrictions on usage: None Author/Change controller: IETF Provisional registration: No Figure 18: home+json Media Type Registration 7.9. CoAP Content-Format IANA is requested to add the entries of Table 12 to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.CORE]. Wiethuechter Expires 17 September 2026 [Page 44] Internet-Draft home-interfaces March 2026 +========================+================+=====+===========+ | Content Type | Content Coding | ID | Reference | +========================+================+=====+===========+ | application/home+cbor; | - | TBD | This RFC | | ctx=aviation | | | | +------------------------+----------------+-----+-----------+ | application/home+json; | - | TBD | This RFC | | ctx=aviation | | | | +------------------------+----------------+-----+-----------+ Table 12: New CoAP Content-Formats 8. Security Considerations The considerations discussed in [RFC9153], [RFC9374], [RFC9434] and [RFC9886] apply. 8.1. AAA OMEs 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 a jurisdiction for devices. Remote ATtestation ProcedureS (RATS, [RFC9334]) is recommended for such mandates. The specific attestation mechanisms are out of scope for this document. 8.2. 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 an HHIT will be derived SHOULD be generated by the entity identified by that HHIT and the corresponding private key should be stored only on that entity's device. There may be scenarios where other parts of a system, such as a UAS, generates the cryptographic materials and provision them as needed during an operation. Any such system MUST ensure security of the cryptographic material is guaranteed. Wiethuechter Expires 17 September 2026 [Page 45] Internet-Draft home-interfaces March 2026 9. Privacy & Transparency Considerations The use of COSE or JOSE encryption provides privacy for _Registrant_ data when communicating with an HOME. The considerations of [RFC9153] apply. 10. References 10.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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, . [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, . [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, . Wiethuechter Expires 17 September 2026 [Page 46] Internet-Draft home-interfaces March 2026 [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, . [RFC9886] Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tags (DETs) in the Domain Name System", RFC 9886, DOI 10.17487/RFC9886, December 2025, . [STD95] Internet Standard 95, . At the time of writing, this STD comprises the following: Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, . Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, . Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, . Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, . [STD96] Internet Standard 96, . 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, . Wiethuechter Expires 17 September 2026 [Page 47] Internet-Draft home-interfaces March 2026 Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, . 10.2. Informative References [IANA.CBOR.Tags] IANA, "CBOR Tags", November 2025, . [IANA.CORE] IANA, "CoAP Content-Formats", July 2025, . [IANA.CWT.Claims] IANA, "CBOR Web Token (CWT) Claims", November 2025, . [IANA.DRIP] IANA, "Drone Remote ID Protocol", October 2025, . [IANA.JWT.Claims] IANA, "JSON Web Token (JWT) Claims", November 2025, . [IANA.MediaTypes] IANA, "Media Types", July 2025, . [IANA.RDAP.Extensions] IANA, "RDAP Extensions", July 2025, . [IANA.WellKnownURIs] IANA, "Well-Known URIs", July 2025, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [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, . Wiethuechter Expires 17 September 2026 [Page 48] Internet-Draft home-interfaces March 2026 [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, . [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, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [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, . [RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [STD69] Internet Standard 69, . Wiethuechter Expires 17 September 2026 [Page 49] Internet-Draft home-interfaces March 2026 At the time of writing, this STD comprises the following: Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, . [STD90] Internet Standard 90, . At the time of writing, this STD comprises the following: Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [STD94] Internet Standard 94, . At the time of writing, this STD comprises the following: Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . Appendix A. Oracle As A Service This appendix is normative. Wiethuechter Expires 17 September 2026 [Page 50] Internet-Draft home-interfaces March 2026 In certain circumstances field contents may only be properly validated by other entities outside of DRIP. A so called "oracle" can be provided by an RAA or designated 3rd party as a service (i.e. "oracle-as-a-service") or mandated by an RAA to be implemented directly by their HDAs. 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 could result in bogus data being returned. The rest of this section (and subsections) only applies for an "oracle-as-a-service" model. A.1. Use Case Example An an 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. When an "oracle" is not consulted there is a risk that the a recorded binding between UAS and Operator is non-existent, resulting in faulty CAA enforcement capabilities. A.2. Expected HOME Behavior HOME's when presented with additional information that requires an "oracle", MUST forward without modification the Registrants HOME Token for processing to their RAAs "oracle-as-a-service" endpoint. HOME's acting as an RAA under this specification MUST always provide the "oracle-as-a-service" endpoint (/.well-known/home/oaas) and respond as follows: * return an applicable HTTP Response error when the "oracle" does not exist within a given jurisdiction - OMEs receiving such a response SHOULD proceed as if the "oracle" successfully validated the request * perform a redirect to appropriate system when "oracle" is being provided as a 3rd party service that the HDAs are expected to independently consult * process and respond following Appendix A.3 Wiethuechter Expires 17 September 2026 [Page 51] Internet-Draft home-interfaces March 2026 OMEs process non-error HTTP codes by including the returned "oracle" certificate in artifacts in the Private Information Registry and continuing the registration process. An error HTTP code received by a HOME MUST be mimicked back to the _Registrant_. A.3. Expected Oracle Behavior The "oracle" MUST validate the HOME Token signature before processing any of the claim data it has authority over. Additional authentication and/or authorization on the endpoint MAY be required by a jurisdiction and its selection, implementation and policy are out of scope for this document. If an "oracle" accepts the data presented it MUST respond with a valid X.509 certificate, RECOMMENDED to be OKIX compliant, with the Subject set to the same contents as the _Registrant_ CSR. When a "oracle" denies any data presented it MUST respond with an appropriate HTTP Response code and MUST NOT include a reason. This is to avoid clients data mining information to forge malicious requests. Once the "oracle" has completed its validations on fields it has authority over and responded accordingly the HOME Token MUST be deleted from the "oracle". The policy and other inner mechanics of the "oracle" are out of scope for this document. Appendix B. CDDL & Encoding Rules This appendix is normative. B.1. Prelude The HOME CDDL Prelude of Figure 19 is built upon the prelude defined in Appendix E of [RFC8610] to allow interoperability with JSON encodings. The conversion of fields to/from CBOR and JSON MUST use the advice in Section 6 of [RFC8949]. entity-id = int / text key-id = int / text map = { &(int, text) => any } Figure 19: CDDL: HOME Prelude B.2. HRI & HRR Claims The full claim set for HRI and HRR, including prelude, are shown in Figure 20. Wiethuechter Expires 17 September 2026 [Page 52] Internet-Draft home-interfaces March 2026 rdap = [ hhit: [ ip6: text, hhit_entity_type: uint ], canon_x: text .b64u bytes, metadata: map / null ] response = [ success: { &(entity-id): success-data } / null failure: [ + error-data ] / null shared: map / null ] success-data = [ keys: { &(key-id): map }, shared: map / null ] error-data = [ eid: &(entity-id) / null, kid: &(key-id) / null, cat: any, msg: any ] inquiry = [ entities: { &(entity-id) => entity }, metadata: map / null ] entity = [ hhit_entity_type: uint, keys: { &(key-id): key }, metadata: map / null ] key = [ csr: bytes / text .b64u bytes, metadata: map / null ] entity-id = int / text key-id = int / text map = { &(int, text) => any } Figure 20: CDDL: HRI & HRR Claims B.3. IPv6 Handling IPv6 addresses MUST be tagged using [RFC9164] when encoded in CBOR. For JSON, IPv6 addresses MUST be an address string as defined in [RFC4291], Section 2.2. Wiethuechter Expires 17 September 2026 [Page 53] Internet-Draft home-interfaces March 2026 B.4. HOME Common Parameters hhit = [ ip6: #6.54(bytes .size(16)) / text, ; ip6 addr tstr hhit_entity_type: uint ] vnb = tdate / time vna = tdate / time / number publish = bool csr = bytes / text .b64u bytes ; DER encoded oracle_x = bytes / text .b64u bytes ; DER encoded canon_x = bytes / text .b64u bytes ; DER encoded canon_chain = [ bytes / text .b64u bytes ] ; DER encoded contact = text ; b64 encoded jCard object Figure 21: CDDL: HOME Common Parameters B.4.1. VNB & VNA Handling The inclusion of the valid not before (VNB) and valid not after (VNA) parameters to the metadata map of Section 4.2.1 allows a _Registrant_ to set very specific validity times for their registration. VNB when present is always an absolute time reference per its typing. VNA is either an absolute time reference (like VNB) or a positive offset in seconds (to be added to the VNB absolute time). Negative values of VNA MUST be considered an encoding error. 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. When VNB is not present in the metadata map the HOME MUST use the current absolute date/time as VNB. The absence of VNA is a signal for the HOME to use a default offset, determined by policy and out of scope for this document, to add to VNB. As an example of the use of VNB and VNA, a _Registrant_ may set VNB to null and VNA to 3600. The HOME 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. Wiethuechter Expires 17 September 2026 [Page 54] Internet-Draft home-interfaces March 2026 B.5. HOME Aviation Parameters These parameters are carried over from Section 5.2 of [RFC9886]. The content in Figure 22 carries the same semantics from [RFC9886] but is more well-defined in syntax of CDDL. uas_type = (uint .le 15) .default 0 uas_ids = [ + [ id_type: uint .le 15, uas_id: bytes .size(20) ] ] auth = [ + [ type: uint .le 15, data: bytes .size(1..362) ] ] self_id = [ type: uint .size(1), description: text .size(23) ] area = [ count: (uint .size(1)) .default 1, radius: number, floor: number, ceiling: number ] classification = [ type: (uint .le 8) .default 0, class: (uint .le 15) .default 0, category: (uint .le 15) .default 0 ] operator_id = [ type: uint .size(1), id: bytes .size(20) ] Figure 22: CDDL: HOME Aviation Parameters Contributors Robert Moskowitz HTT Consulting Email: rgm@htt-consulting.com Robert Moskowitz provided the concept and general structure for the OKI and the specific inclusions for X.509 profiles to support HHITs. Wiethuechter Expires 17 September 2026 [Page 55] Internet-Draft home-interfaces March 2026 Author's Address Adam Wiethuechter AX Enterprize, LLC Email: adam.wiethuechter@axenterprize.com Wiethuechter Expires 17 September 2026 [Page 56]