]> AX Enterprize, LLC

adam.wiethuechter@axenterprize.com

Internet Drone Remote ID Protocol Internet-Draft 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.

Introduction

Purpose An ecosystem using Overlay Routable Cryptographic Hash IDentifiers (ORCHIDs, ) as its primary identifier can be a strong option for modern systems. The Hierarchical Host Identity Tags (HHITs, ) are used in the fast growing sector of Unmanned Aircraft Systems (UAS) to provide identity and authentication services using the Domain Name System (DNS). 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.

Background HHITs are an evolution of the Host Identity Tags (HITs) in the Host Identity Protocol (HIP, ). All of these tags are categorized as an ORCHID which were standardized in and updated by . 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. 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 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).

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 . This document defines all data models in the Concise Data Definition Language (CDDL, ) with the full specification in .

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 .

Targeted DRIP Requirements The following requirements of are satisfied when following this document: GEN-3, ID-4, REG-2, REG-4 and PRIV-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 when, and only when, they appear in all capitals, as shown here.

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 profiles in compliance of Public Key Infrastructure X.509 (PKIX, ) 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; ) Object Signing & Encryption (COSE; ) or JavaScript Object Notation (JSON; ) Object Signing & Encryption (JOSE; , ) structure. See .

HRI Token:

A HOME Token containing an HRI claim per .

HRR Token:

A HOME Token containing an HRR claim per .

HOME Component Architecture & Functions To properly provide the necessary services identified in both and 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 .

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 compliant certificates that support HHITs, see . 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 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 .

Registry:

This document covers the client facing interface of the 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 .

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 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, ) 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 and the RDAP interaction by Querants (such as Observers) and a Registry as described in . 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 . 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.

Registration This sections details the process of registration following . This Z-diagram is the upper link of labeled with "HOME Token/HTTPS" between Registrant and Registrar.

Registration Z-Diagram | | | VALID_HRI? |<-------FAIL-------| | | DUPE_HI? |<-------FAIL-------| | | DUPE_HHIT? |<-------FAIL-------| | | GEN_CERTS | | UPDATE_DATABASE | | UPDATE_NS |<------ HRR--------| ONBOARD | | | | ]]>

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.

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.

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, ) 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 , and placed in a unprotected header.

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 () containing relevant processing errors when the original request token () 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.

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 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 , if known. Additional claims are out of scope for this document. The layer ( or ) 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.

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.

CDDL: HOME Registration Inquiry 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 ] ]]>

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

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 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 () as part of a Content-Type parameter. An initial key set is registered in .

Each nesting in 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.

HOME Registration Response (HRR) This claim is structured to use the provided entity-ids and key-ids from an HRI. It also can contain a list of failures, organized by those same identifiers.

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 ) 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 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 for more details.

Similar to the metadata in the HRI, 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.

Considerations

Keys & Certificate Signing Request Registrants 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 . The process of discovering a specific HID is out of scope for this document.

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.

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 . 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 ). 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 , 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 [<eid>, null, <cat>, <msg>] instead of one for each key-id. 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.

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.

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 response code MUST be sent with only a signature layer () 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.

Differential Access Query This section details the process of query for additional private information following the Z-diagram of . It is the lower right link of labeled with "RDAP" between Querant and Registry.

Query Z-Diagram | RDAP_URI | | |------RDAP_Q------>| | | ACCEPT_X509? |<------DENY--------| | | POLICY_CHECK? |<------DENY--------| | | REDACTION |<-----RDAP_R-------| ACT | | | | ]]>

For HOME's the differential access mechanism known as Registration Data Access Protocol (RDAP, ) 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 . Authentication of the HOME and Querant is done through Mutual TLS using X.509 certificates. As part of RDAP, the HOME MAY follow 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.

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

Query Endpoint The /.well-known/home/query/<IP address> endpoint SHOULD be redirected to a full qualified path conforming with (i.e. ip/<IP address>) by the HOME. All other RDAP endpoints SHOULD NOT be implemented as specified in . 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.

Differential Access Control Per REG-2 and REG-4 of , 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 . A federated authentication mechanism, such as the examples in , 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 AND
• MUST support Mutual TLS per 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 (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.

RDAP Extension & Response A HOME MUST respond to a successful query using . The HOME RDAP Extension shown in 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 .

CDDL: HOME RDAP Extension

hhit:

Array structure contain the HHIT Entity Type and the HHIT encoded per .

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.

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 .

ORCHID Key Infrastructure (OKI) Hierarchy

In 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 with a solid line but open connection point between its ancestor and descendant. Also note that 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 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 ().

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. Hierarchy Responsibilities

Responsibility	Apex	Root	Inode	Leaf
provide using public methods any requirements, policy and/or guidance to prospective descendants	MUST	MUST	MUST	MUST
provide OKIX-compatible certificate(s) as endorsement for registration of descendant(s)	MAY see 1+ Authorization HHIT	MUST	MUST	MUST
maintain registrations with relevant Personally Identifiable Information (PII) as required by their jurisdiction	MUST	MUST	MUST	MUST
fulfill any jurisdiction requirements that are out of scope for this document	MUST	MUST	MUST	MUST
support MAY support services using such as	-	MAY	MAY	MAY
1+ Authorization HHIT see	MAY	MUST	MUST	MUST
1+ Issuing HHIT MUST have same Hierarchy ID as an Authorization HHIT MUST be locally registered using an Authorization HHIT	MAY	MAY	SHOULD	MUST
cross-endorse with siblings MUST use an Authorization HHIT	-	MAY	MAY	MAY
maintain reverse IPv6 zone(s)	SHOULD or delegate back to the IPv6 Prefix	MUST	MUST	MUST
assign/allocate values in the X level of hierarchy in the Hierarchy ID see	MUST X=Root	MUST X=Inode	MUST X=Inode or Leaf	-
implement and	MAY or 501 Not Implemented	SHOULD or 501 Not Implemented	SHOULD or 501 Not Implemented	MUST

Additional Responsibilities for 1+ Authorization HHIT

1+ Authorization HHIT	Apex	Root	Inode	Leaf
set Hierarchy ID to all zeros	MUST	MUST NOT	MUST NOT	MUST NOT
set Hierarchy ID to assignment/allocation from ancestor	MUST NOT	MUST	MUST	MUST
self register	MUST	if Apex MUST then MUST NOT	MUST NOT	MUST NOT
registered to direct ancestor	MUST NOT	if Apex MUST NOT then MUST	MUST	MUST

Additional Responsibilities for Assign/allocate values in Hierarchy ID

Assign/allocate values in Hierarchy ID	Apex	Root	Inode	Leaf
verify prospective descendant(s) for hierarchy membership	SHOULD	SHOULD	SHOULD	-
register descendant(s) hierarchy members using an Authorization HHIT	MAY	MUST	MUST	-
delegate corresponding reverse IPv6 zone(s) to descendant(s)	SHOULD see maintain reverse IPv6 zone(s)	MUST	MUST	-

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.

Signing Request The Certificate Signing Request is mandatory for all HHIT registrations. Depending on the entity being registered, there is specific content rules.

Certificate Signing Request Profile Subject Public Key Info: Attributes: Requested Extensions: X509v3 Subject Alternative Name: critical IP Address: Signature Algorithm: ]]>

Subject:

As defined in . 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 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.

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 MUST field usage. The profile can be found in and a field matrix found in .

OKIX-Lite Profile 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: ]]>

OKIX-Lite Field Matrix

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

Certificate: Full Profile The X.509 certificates are minimalistic (less than 400 bytes for DER). The profile can be found in and a field matrix found in . This profile MUST be used as the Canonical Registration Certificate in the DNS.

OKIX-Full Profile 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: ]]>

OKIX-Full Field Matrix

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

Certificate Fields The following sections contain clarifications on the usage of fields in the OKIX when they deviate from "standard" X.509 practice.

Serial Number

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

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

Subject The Subject field is only used in Authorization and Issuing certificates. For Operational certificates, the Subject MUST be empty and the HHIT will be in Subject Alternative Name (). 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.

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.

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

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.

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 .

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

IANA Considerations

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

URI Suffix	Change Controller	Reference	Status	Related Information
home/register	IETF	This RFC	permanent	N/A
home/query	IETF	This RFC	permanent	N/A
home/oaas	IETF	This RFC	permanent	N/A

• Author Note: should we also add Well-Known URIs for update and delete methods? This would then cover all parts of CRUD.

CWT & JWT Claims HOME Tokens contain a Claim Set compatible with those of CWT and JWT, so the CWT and JWT Claims registries, and , 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 and the "CBOR Web Token (CWT) Claims" registry established by . 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 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.

HOME Registration Inquiry Claim: Registration Form

HOME Registration Response Claim: Registration Form

RDAP Extensions Registry IANA is requested to register the following value in the "RDAP Extensions" registry .

RDAP Extensions: Registration Form Intended Usage: This extension is used to convey private information stored under a HOME registration. ]]>

HHIT Entity Types IANA is requested to make the following changes to the "HHIT Entity Types" registry under to align with . Updated HHIT Entity Type Registry

Value	HHIT Entity Type	Abbreviation	Operational (Y/N)	Reference
0	Undefined	UKN	N
1	Hierarchical ORCHID Management Entity	HOME	N	This RFC
2	Hierarchical ORCHID Management Entity: Authorization	HOME-A	N	This RFC
3	Hierarchical ORCHID Management Entity: Issuing	HOME-I	N	This RFC
4	HOME Apex	APEX	N
5	HOME Apex: Authorization	APEX-A	N	This RFC
6	HOME Apex: Issuing	APEX-I	N	This RFC
7	DRIP Identity Management Entity	DIME	N
8	DRIP Identity Management Entity: Authorization	DIME-A	N	This RFC
9	DRIP Identity Management Entity: Issuing	DIME-I	N	This RFC
10	Registered Assigning Authority	RAA	N
11	Registered Assigning Authority: Authorization	RAA-A	N	This RFC
12	Registered Assigning Authority: Issuing	RAA-I	N	This RFC
13	HHIT Domain Authority	HDA	N
14	HHIT Domain Authority: Authorization	HDA-A	N	This RFC
15	HHIT Domain Authority: Issuing	HDA-I	N	This RFC
16	Unmanned Aircraft	UA	Y
17	Ground Control Station	GCS	Y
18	Unmanned Aircraft System	UAS	Y
19	Remote Identification Module	RID	Y
20	UAS Pilot	PILOT	Y
21	UAS Operator	OP	Y
22	Discovery & Synchronization Service	DSS	Y
23	UAS Service Supplier	USS	Y
24	Network RID Service Provider	DP	Y
25	Network RID Display Provider	SP	Y
26	Supplemental Data Service Provider	SDSP	Y
27	Crowd Sourced RID Finder	FINDER	Y

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.

HOME Parameters This document requests IANA create a new registry under called "HOME Parameters" with registry policies described in . HOME Parameters: Registry Policies

Range	Registration Policy
Integers less than 0	delegated to HOME Common Parameters registry
Integers greater than -1	Reserved

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 () for negative values, and setup new allocation schemes for the positive integers in their scope. See 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.

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.

Registration Form

HOME Parameters: Registration Form

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 . Their typing in JSON is assumed to follow the translation from CBOR to JSON following .

HOME Common Parameters This document requests IANA create a new registry under called "HOME Common Parameters" with registry policies described in . Initial entries for this registry are in and uses the registration form of . HOME Common Parameters: Registry Policies

Range	Registration Policy
Integers less than -65536	Private Use ()
Integers in the range -257 to -65536	Specification Required ()
Integers in the range -1 to -256	Standard Action ()

Initial HOME Common Parameters

HOME Aviation Parameters This document requests IANA create a new registry under called "HOME Aviation Parameters" with registry policies described in . Initial entries for this registry are in and uses the registration form of . When using this registry the "ctx" parameter of is set to "aviation". HOME Aviation Parameters: Registry Policies

Range	Registration Policy
Integers less than 0	delegated to HOME Common Parameters registry
Integers in the range 0 to 65535	Specification Required ()
Integers greater than 65535	First Come First Served ()

Initial HOME Aviation Parameters

Media Types IANA is requested to add the entries of to the "Media Types" registry . New Media Types

Name	Template	Reference
home+cbor	application/home+cbor	This RFC,
home+json	application/home+json	This RFC,

application/home+cbor

home+cbor Media Type Registration

application/home+json

home+json Media Type Registration

CoAP Content-Format IANA is requested to add the entries of to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group . New CoAP Content-Formats

Content Type	Content Coding	ID	Reference
application/home+cbor; ctx=aviation	-	TBD	This RFC
application/home+json; ctx=aviation	-	TBD	This RFC

Security Considerations The considerations discussed in , , and apply.

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, ) is recommended for such mandates. The specific attestation mechanisms are out of scope for this document.

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.

Privacy & Transparency Considerations The use of COSE or JOSE encryption provides privacy for Registrant data when communicating with an HOME. The considerations of apply.

References Normative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement. This document updates RFCs 7401 and 7343. This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote Identification Protocol (DRIP) Requirements document (RFC 9153). This document defines the Domain Name System (DNS) functionality of a Drone Remote Identification Protocol (DRIP) Identity Management Entity (DIME). It is built around DRIP Entity Tags (DETs) to standardize a hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DETs, enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote Identification and other services. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203. This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK] This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. IANA IANA IANA IANA IANA IANA IANA IANA

Oracle As A Service This appendix is normative. 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.

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.

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

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.

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.

CDDL & Encoding Rules This appendix is normative.

Prelude The HOME CDDL Prelude of is built upon the prelude defined in to allow interoperability with JSON encodings. The conversion of fields to/from CBOR and JSON MUST use the advice in .

CDDL: HOME Prelude any } ]]>

HRI & HRR Claims The full claim set for HRI and HRR, including prelude, are shown in .

CDDL: HRI & HRR Claims 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 } ]]>

IPv6 Handling IPv6 addresses MUST be tagged using when encoded in CBOR. For JSON, IPv6 addresses MUST be an address string as defined in .

HOME Common Parameters

CDDL: HOME Common Parameters

VNB & VNA Handling The inclusion of the valid not before (VNB) and valid not after (VNA) parameters to the metadata map of 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.

HOME Aviation Parameters These parameters are carried over from . The content in carries the same semantics from but is more well-defined in syntax of CDDL.

CDDL: HOME Aviation Parameters

Contributors HTT Consulting

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.