drip Working Group A. Wiethuechter, Ed. Internet-Draft AX Enterprize, LLC Intended status: Standards Track J. Reid Expires: 21 March 2024 RTFM llp 18 September 2023 DRIP Entity Tag (DET) Identity Management Architecture draft-ietf-drip-registries-13 Abstract This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through DRIP specific DNS structures and standard DNS methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. 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 21 March 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Wiethuechter & Reid Expires 21 March 2024 [Page 1] Internet-Draft DETIM Architecture September 2023 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 2. Abstract Process and Reasoning . . . . . . . . . . . . . . . 5 2.1. Supported Scenarios . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Required Terminology . . . . . . . . . . . . . . . . . . 6 3.2. Additional Definitions . . . . . . . . . . . . . . . . . 6 3.3. Text Conventions . . . . . . . . . . . . . . . . . . . . 7 4. DIME Roles . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Apex . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Registered Assigning Authority (RAA) . . . . . . . . . . 9 4.2.1. ISO 3166-1 Numeric Nations (INN) . . . . . . . . . . 9 4.2.2. Manufacturer Code Authority (MCA) . . . . . . . . . . 9 4.3. Hierarchial HIT Domain Authority (HDA) . . . . . . . . . 10 4.3.1. Manufacturer Unmanned Aircraft Authority (MAA) . . . 11 5. DIME Architecture . . . . . . . . . . . . . . . . . . . . . . 11 5.1. DRIP Provisioning Agent (DPA) . . . . . . . . . . . . . . 12 5.2. Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Name Server (NS) . . . . . . . . . . . . . . . . . . . . 14 5.4. DRIP Information Agent (DIA) . . . . . . . . . . . . . . 15 5.5. Registration Data Directory Service (RDDS) . . . . . . . 16 6. Registration/Provisioning Process . . . . . . . . . . . . . . 17 6.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Serial Method 1 . . . . . . . . . . . . . . . . . . . 18 6.1.2. Serial Method 2 . . . . . . . . . . . . . . . . . . . 18 6.1.3. Serial Method 3 . . . . . . . . . . . . . . . . . . . 19 6.1.4. Serial Method 4 . . . . . . . . . . . . . . . . . . . 20 6.2. Operator . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Session ID . . . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. UA Based Session ID . . . . . . . . . . . . . . . . . 24 6.3.2. UAS Based Session ID . . . . . . . . . . . . . . . . 24 6.4. Child DIME . . . . . . . . . . . . . . . . . . . . . . . 25 7. Differentiated Access Process . . . . . . . . . . . . . . . . 26 8. DRIP in the Domain Name System . . . . . . . . . . . . . . . 27 8.1. DRIP Entity Tags . . . . . . . . . . . . . . . . . . . . 28 8.1.1. DET Resource Record . . . . . . . . . . . . . . . . . 28 8.2. Serial Numbers & Other UAS ID Types . . . . . . . . . . . 29 9. Endorsements . . . . . . . . . . . . . . . . . . . . . . . . 30 Wiethuechter & Reid Expires 21 March 2024 [Page 2] Internet-Draft DETIM Architecture September 2023 9.1. Endorsement Structure . . . . . . . . . . . . . . . . . . 30 9.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1.2. Evidence . . . . . . . . . . . . . . . . . . . . . . 31 9.1.3. Identity . . . . . . . . . . . . . . . . . . . . . . 31 9.1.4. Signature . . . . . . . . . . . . . . . . . . . . . . 32 10. X.509 Certificates . . . . . . . . . . . . . . . . . . . . . 32 10.1. Certificate Policy and Certificate Stores . . . . . . . 32 10.2. Certificate Management . . . . . . . . . . . . . . . . . 33 10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 10.4. Alternative Certificate Encoding . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11.1. Delegation of Nibble Reversed IPv6 Prefix . . . . . . . 34 11.2. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 35 11.2.1. Aircraft Information Registry . . . . . . . . . . . 35 11.2.2. Endorsement Fields . . . . . . . . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12.1. Key Rollover & Federation . . . . . . . . . . . . . . . 37 12.2. DET Generation . . . . . . . . . . . . . . . . . . . . . 37 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 14.1. Normative References . . . . . . . . . . . . . . . . . . 38 14.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. DRIP Fully Qualified Domain Names . . . . . . . . . 41 A.1. DRIP Entity Tag . . . . . . . . . . . . . . . . . . . . . 41 A.2. UAS Serial Number . . . . . . . . . . . . . . . . . . . . 41 Appendix B. DRIP Endorsements for UAS . . . . . . . . . . . . . 41 B.1. Generic Endorsement . . . . . . . . . . . . . . . . . . . 41 B.2. Self Endorsement . . . . . . . . . . . . . . . . . . . . 42 B.3. Broadcast Endorsement . . . . . . . . . . . . . . . . . . 43 Appendix C. DNS Examples . . . . . . . . . . . . . . . . . . . . 46 C.1. Serial Method 1 . . . . . . . . . . . . . . . . . . . . . 46 C.2. Serial Method 2 . . . . . . . . . . . . . . . . . . . . . 46 C.3. Serial Method 3 . . . . . . . . . . . . . . . . . . . . . 46 C.4. Serial Method 4 . . . . . . . . . . . . . . . . . . . . . 46 C.5. Operator . . . . . . . . . . . . . . . . . . . . . . . . 46 C.6. Session ID . . . . . . . . . . . . . . . . . . . . . . . 46 C.7. Child DIME . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction Registries are fundamental to Unmanned Aircraft System (UAS) Remote ID (RID). Only very limited operational information can be Broadcast, but extended information is sometimes needed. The most essential element of information is the UAS ID, the unique key for lookup of extended information in relevant registries (see Figure 4 of [RFC9434]). Wiethuechter & Reid Expires 21 March 2024 [Page 3] Internet-Draft DETIM Architecture September 2023 While it is expected that DRIP Identity Management Entity (DIME) functions will be integrated with UAS Service Suppliers (USS) (Appendix A.2 of [RFC9434]), who will provide DIME-like functions is not yet determined in most, and is expected to vary between, jurisdictions. However this evolves, the essential DIME-like functions (including the management of identifiers (such as the DRIP Entity Tag (DET))) are expected to remain the same, so are specified herein. While most data to be sent via Broadcast RID (Section 1.2.1 of [RFC9434]) or Network RID (Section 1.2.2 of [RFC9434]) is public, much of the extended information in registries will be private. As discussed in Section 7 of [RFC9434], Authentication, Attestation, Authorization, Access Control, Accounting, Attribution, and Audit (AAA) for registries is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose. As specific AAA requirements will vary by jurisdictional regulation, provider choices, customer demand, etc., they are left to specification in policies, which should be human readable to facilitate analysis and discussion, and machine readable to enable automated enforcement, using a language amenable to both (e.g., eXtensible Access Control Markup Language (XACML)). The intent of the access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Mitigation of Denial of Service (DoS) attacks and refusal to allow database mass scraping would be based on those behavior, not on identity or role of the party submitting the query per se, but querant identity information might be gathered (by security systems protecting DRIP implementations) on such misbehavior. Registration under DRIP is vital to manage the inevitable collisions in the hash portion of the DET (Section 9.5 of [RFC9374]). Forgery of a DET is still possible, but including it as a part of a public registration mitigates this risk. This document creates the DET registration and discovery ecosystem. This includes all components in the ecosystem (e.g., Unmanned Aircraft (UA), Registered Assigning Authority (RAA), Hierarchical HIT Domain Authority (HDA), Ground Control Station (GCS), and USS). This document uses the Concise Data Definition Language (CDDL) [RFC8610] for describing the registration data. Wiethuechter & Reid Expires 21 March 2024 [Page 4] Internet-Draft DETIM Architecture September 2023 2. Abstract Process and Reasoning In DRIP each entity (DIME, Operator, UA, etc.) is expected to generate a DET [RFC9374] on the local device their key is expected to be used. These are registered with a Public Information Registry (e.g. DNS) within the hierarchy along with whatever data is required by the cognizant CAA and the DIME. Any Personally Identifiable Information (PII) is stored in a Private Information Registry protected through industry practice AAA or stronger. In response, the entity will obtain an endorsement from the DIME proving such registration. Manufacturers that wish to participate in DRIP should not only support DRIP as a Session ID type for their aircraft but could also generate a DET then encode it as a Serial Number (Section 4.2 of [RFC9374]). This would allow aircraft under CAA mandates to fly only ID Type 1 (Serial Number) could still use DRIP and most of its benefits. Even if DRIP is not supported for Serial Numbers by a Manufacturer it is hoped that they would still run a DIME to store their Serial Numbers and allow look ups for generic model information. This look up could be especially helpful in UTM for Situational Awareness when an aircraft flying with a Serial Number is detected and allow for an aircraft profile to be displayed. Operators are registered with a number of registries or their regional RAA. This acts as a verification check when a user performs other registration operations; such as provisioning an aircraft with a new Session ID. It is an open question if an Operator registers to their CAA (the RAA's direct HDA) or multiple USS's (HDA's). PII of the Operator would vary based on the CAA they are under and the DIME. Finally, aircraft that support using a DET would provision per flight to a USS, proposing a DET to the DIME to generate a binding between the aircraft (Session ID, Serial Number, and Operational Intent), operator and DIME. The aircraft then follows [drip-auth] to meet various requirements from [RFC9153] during a flight. 2.1. Supported Scenarios Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section most likely is removed or merged with another. The only point to merge is #6. 1. UA using manufacturer generated Serial Number for UAS ID. No additional information provided. Wiethuechter & Reid Expires 21 March 2024 [Page 5] Internet-Draft DETIM Architecture September 2023 2. UA using manufacturer generated Serial Number for UAS ID. Manufacturer using a DIME. Manufacturer MUST provided pointer to additional information via DNS (even if null). 3. UA using manufacturer generated Serial Number which is mapped to a DET by manufacturer for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. Manufacturer MUST provide pointer to additional information via DNS (even if null). 4. UA using manufacturer generated DRIP enhanced Serial Number for UAS ID. UA using manufacturer generated DET for Authentication. Manufacturer using a DIME. DIME MUST place public information into DNS (i.e. HI) - either directly or as a mapping to a DET. DIME MUST provide pointer to additional information via DNS (even if null). 5. UA using manufacturer generated Serial Number for UAS ID. UA using user generated DET for Authentication. User uses DIME with capability to publicly map Serial Number to a DET (via a USS). DIME MUST place public DET information into DNS (i.e. HI). DIME MUST provide mapping of Serial Number to DET in DNS. DIME MUST provide pointer to additional information via DNS (even if null). 6. UA provisioned with DET (i.e. Session ID) with a DIME (via a USS) for UAS ID and Authentication. DIME MUST place public DET information into DNS (i.e. HI). DIME MUST NOT (unless required) provide mapping of DET to Serial Number in DNS. USS MUST provide pointer to additional information via DNS (even if null). 3. Terminology 3.1. Required 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. 3.2. Additional Definitions This document makes use of the terms (PII, USS, etc.) defined in [RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434], while others (RAA, HDA, etc.) are from [RFC9374]. Wiethuechter & Reid Expires 21 March 2024 [Page 6] Internet-Draft DETIM Architecture September 2023 3.3. Text Conventions When talking about a DIME in documents it should be referred to as the role it is serving. For example a CAA level DIME running services both as an RAA (its primary role in the hierarchy) and as an HDA (optionally) would be be referred to "RAA" when performing its RAA duties and "HDA" when performing its HDA duties. The rest of the document will follow this convention unless verbosity or clarity is needed. 4. DIME Roles [RFC9434] defines the DRIP Identity Management Entity (DIME) as an entity that vets Claims and/or Evidence from a registrant and delivers, to successful registrations, Endorsements and/or Certificates in response. The DIME encompasses various logical components and can be classified to serve a number of different roles, which are detailed in the following subsections. The general hierarchy of these initial roles (some highly specialized and predetermined for the UAS use case) are illustrated in Figure 1. +----------+ | Apex o--------. +-o------o-+ | | | | ******************|******|**********|****************** | | | +-----o-+ +-o-----+ +-o-----+ RAAs | MCA | | INN | | RAA | +---o---+ +---o---+ +---o---+ | | | ****************|**********|**********|**************** | | | +---o---+ +---o---+ +---o---+ HDAs | MAA | | HDA | | HDA | +-------+ +-------+ +-------+ Figure 1: DIME Roles and Hierarchy 4.1. Apex The Apex is a special DIME role that holds the values of RAA=0-3 and HDA=0. It serves as the branch point from the larger DNS system in which DETs are defined. The Apex is the owner of the IPv6 prefix portion of the DET associated with it (2001:30/28) which is assigned by IANA from the special IPv6 address space for ORCHIDs. Wiethuechter & Reid Expires 21 March 2024 [Page 7] Internet-Draft DETIM Architecture September 2023 The Apex manages all delegations and allocations of the DET's RAA to various parties. Allocations of RAAs SHOULD be done in contiguous groups of 4. +===================+=================+=============================+ | RAA Decimal Range | RAA Hex Range | Status | +===================+=================+=============================+ | 0 - 3 | 0x0000 - | Apex | | | 0x0003 | | +-------------------+-----------------+-----------------------------+ | 4 - 3999 | 0x0004 - | ISO 3166-1 Countries | | | 0x0F9F | (Section 4.2.1) | +-------------------+-----------------+-----------------------------+ | 4000 - 4095 | 0x0FA0 - | Manufacturer Code | | | 0x0FFF | Authorities (Section 4.2.2) | +-------------------+-----------------+-----------------------------+ | 4096 - 16375 | 0x1000 - | Reserved | | | 0x3FFF | | +-------------------+-----------------+-----------------------------+ | 16376 - 16383 | 0x3FF8 - | DRIP WG Experimental Use | | | 0x3FFF | | +-------------------+-----------------+-----------------------------+ Table 1 Note: that the first column of this table is _decimal_ values *not* _hexadecimal_. RAA values of 0 (0x0000) to 3 (0x0003) are reserved to the Apex exclusively. The Experimental range of 16376 (0x3FF8) to 16383 (0x3FFF), eight (8) RAAs, is allocated to the DRIP working group itself. 16376 to 16379 are setup by DRIP experts to act as RAAs for potential HDA users to test against. RAA 16376 is already "in use" with driptesting.org. 16379 is to be setup as an RAA to act as a MCA Section 4.2.2 for UAS manufacturers to test their HDAs against and have their Manufacturer Code properly managed. The rest of the range (16380 to 16383) are reserved to be allocate by the DRIP experts to agencies that wish to test being an RAA. Wiethuechter & Reid Expires 21 March 2024 [Page 8] Internet-Draft DETIM Architecture September 2023 4.2. Registered Assigning Authority (RAA) RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field, i.e. 16,384 RAAs, of an DET). An RAA is a business or organization that manages a DIME of HDAs (Section 4.3). Most are contemplated to be Civil Aviation Authorities (CAA), such as the Federal Aviation Authority (FAA), that then delegate HDAs to manage their National Air Space (NAS). This is does not preclude other entities to operate an RAA if the Apex allows it. An RAA must provide a set of services to allocate HDAs to organizations. It must have a public policy on what is necessary to obtain an HDA. It must maintain a DNS zone minimally for discovering HID RVS servers. All RAA's have a single reserved HDA value: 0 (0x0000) for itself to support various functions or services. Other HDA values can be allocated or reserved per RAA policy. 4.2.1. ISO 3166-1 Numeric Nations (INN) The RAA range of 4 (0x0004) to 3999 (0x0F9F) are reserved for CAAs using the ISO 3166-1 Numeric Nation Code. The RAA can be derived from the ISO 3166-1 numeric code by multiplying the value by 4 (i.e. raa_code = iso_code * 4). Four contiguous values are used in a single allocation. The inverse (RAA to ISO) works out as: iso_code = floor(raa_code / 4). As an example the United States has an ISO 3166-1 Numeric Code of 840. This derives the following RAAs: 3360, 3361, 3362 and 3363. It should be noted that the range of codes from 900 to 999 are defined as "user assigned code elements" without specific claimant predefined in the RAA space. Withdrawn and other special codes also do not have predetermined claimants. How a CAA handles their 4 allocations are out of scope of this document. Control of these values are expected to be claimed by their respective owner. How a claim is vetted and validated is out of scope of this document. Protection against fraudulent claims of one of these values is out of scope for this document. Note: A single entity may control more than one NAS (for example LU and BE being covered by Skeyes.be) and would manage two allocation spaces. How this is claimed and handled is out of scope for this document. 4.2.2. Manufacturer Code Authority (MCA) Wiethuechter & Reid Expires 21 March 2024 [Page 9] Internet-Draft DETIM Architecture September 2023 Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section is either moved to a new document or left here. An RAA-level DIME that hands out HDA values to participating Manufacturer's that hold an Manufacturer Code used in [CTA2063A] that is issued by ICAO. To manage the large Manufacturer Code space (34 character set; 4 characters; 1,336,336 possible codes) a range of RAA values are set aside for the use case. These are the RAA values of 4000 (0x0FA0) up to 4095 (0x0FFF). This allows a single HDA for each Manufacturer Code. See Section 4.3.1 for the HDA allocation of Manufacturer Codes under these RAAs. Note: the upper RAAs in the range (4083 to 4095) are not used but are left reserved in this space for future action if required. 4.3. Hierarchial HIT Domain Authority (HDA) An HDA may be an USS, ISP, or any third party that takes on the business to register the actual entities that need DETs. This includes, but is not limited to UA, GCS, UAS Operators and infrastructure (such as Supplemental Data Service Providers). It should also provide needed UAS services including those required for HIP-enabled devices (e.g. RVS). A primary function of HDAs for DRIP, in the context of UAS RID is the binding between a UAS Session ID (for DRIP the DET) and the UA Serial Number. The Serial Number MUST have its access protected to allow only authorized parties to obtain it. The Serial Number MUST be protected in a way only the authorized party can decrypt. As part of the UTM system HDAs can also hold a binding between a UAS ID (Serial Number or Session ID) and an Operational Intent. They may either be a direct logical part of a UAS Service Supplier (USS) or be a UTM wide service to USS's. The HDA is a 14-bit field (16,384 HDAs per RAA) of a DET assigned by an RAA. An HDA should maintain a set of RVS servers for UAS clients that may use HIP. How this is done and scales to the potentially millions of customers are outside the scope of this document. This service should be discoverable through the DNS zone maintained by the HDA's RAA. Wiethuechter & Reid Expires 21 March 2024 [Page 10] Internet-Draft DETIM Architecture September 2023 An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such policy is out of scope. 4.3.1. Manufacturer Unmanned Aircraft Authority (MAA) Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section can be moved to the new document or left here. An HDA-level DIME run by a manufacturer of UAS systems that participate in Remote ID. Stores UAS Serial Numbers under a specific Manufacturer Code (assigned to the manufacturer by ICAO). The specific RAA (out of MCA space) and HDA use the following derivation: mfr_int = base34_decode(mfr_code) hid = (4000 << 14) + mfr_int mfr_code = base34_encode(hid) A character in a UAS Serial Number "shall include any combination of digits and uppercase letters, except the letters O and I, but may include all digits" [CTA2063A]. For HID determination, the character space [0-9,A-H,J-N,P-Z] is mapped to [0-34] to convert the 4 place Base34 Manufacturer Code to Base10 (Note this is different than the Base32 process in Section 4.2 of [RFC9374]). A DET can be encoded into a Serial Number (see [RFC9374], Section 4.2) and this DIME MUST hold a mapping from the Serial Number to the DET and its artifacts. 5. DIME Architecture The DIME, in any of its roles (Section 4), is comprised of a number of logical components that are depicted in Figure 2. Any of these components could be delegated to other entities as a service both co- located or remote. For example: * The Name Server component could be handled by a well-established DNS registrar/registry with the DRIP Provisioning Agent (DPA) (Section 5.1) interfacing to them - Either the DPA or the Registry/Name Server interfaces to the DRIP Information Agent (DIA) * The DPA, Registry, and Name Server may all be co-located in one implementation with an interface to a DIA offered by another organization from any one of the co-located components Wiethuechter & Reid Expires 21 March 2024 [Page 11] Internet-Draft DETIM Architecture September 2023 +--------------------+ | Registering Client | +---------o----------+ | **********|****************************************************** * | DRIP Identity Management Entity (DIME) * * | * * +------o-------+ +-------------+ +--------------+ * * | DRIP | | | | | * * | Provisioning o------o | | | * * | Agent (DPA) | | | | | * * +-------o------+ | | | | * * | | | | | * * | | DRIP | | Registration | * * +-------o--+ | Information o------o Data | * * | Registry o----------o Agent (DIA) | | Directory | * * +-------o--+ | | | Service | * * | | | | (RDDS) | * * | | | | | * * +-------o----------+ | | | | * * | Name Server (NS) | | | | | * * +------o-----------+ +-----o-------+ +------o-------+ * * | | | * * | | | * **********|********************|*********************|*********** | | | | +-------o-------+ | '------------o Lookup Client o-------------' +---------------+ Figure 2: DIME Logical Components 5.1. DRIP Provisioning Agent (DPA) The DPA performs the important task of vetting information coming from clients wishing to register and then delegate (internally or externally) various items to other components in the DIME. A standard interface MUST be provided for clients to access. An HTTPS based interface is RECOMMENDED. This interface specification is out of scope for this document. There MUST be an interface from the DPA to a Registry (Section 5.2) component which handles the DNS specific requirements of the DIME as defined by the Registry. There MAY also be interface from the DPA to a DRIP Information Agent (Section 5.4) as defined by the DIA. Wiethuechter & Reid Expires 21 March 2024 [Page 12] Internet-Draft DETIM Architecture September 2023 +-------------+ | Registering | | Client | +------o------+ | | HTTPS | | +--o--+ +-----+ | DPA o-----------o DIA | +--o--+ TBD +-----+ | | | HTTPS or EPP | +------o---+ | Registry | +----------+ Figure 3: DPA Interface Mapping 5.2. Registry The Registry component handles all the required DNS based requirements of the DIME to function for DRIP. This includes the registration and maintenance of various DNS Resource Records. A standardized interface MUST be implemented for interactions with the DPA (Section 5.1). This interface MAY be over HTTPS using JSON/ CBOR encoding or MAY use the Extensional Provisioning Protocol (EPP) [RFC5730]. The detailed specification of either of these interfaces is out of scope for this document. There MAY be interface from the Registry to a DRIP Information Agent (Section 5.4) as defined by the DIA. Wiethuechter & Reid Expires 21 March 2024 [Page 13] Internet-Draft DETIM Architecture September 2023 +-----+ | DPA | +--o--+ | | HTTPS or EPP | | +------o---+ +-----+ | Registry o-----------o DIA | +-----o----+ TBD +-----+ | | | TBD | +---o--+ | NS | +------+ Figure 4: Registry Interface Mapping 5.3. Name Server (NS) The interface of the Name Server to any component (nominally the Registry) in a DIME is out of scope as typically they are implementation specific. Author Note: This may be very important here as we should not preclude a USS from running his own Name Server but they are not DNS experts and will need guidance or at least pointers to it to not mess it up. Such as SOA and NS formats to allow delegation if acting as an RAA. Wiethuechter & Reid Expires 21 March 2024 [Page 14] Internet-Draft DETIM Architecture September 2023 +----------+ | Registry | +-----o----+ | | | TBD | +---o--+ | NS | +--o---+ | | | DNS Query/Response | +----o----------+ | Lookup Client | +---------------+ Figure 5: Name Server Interface Mapping 5.4. DRIP Information Agent (DIA) The DIA is the main component handling requests for information from entities outside of the DIME. Typically this is when an Observer looks up a Session ID from an UA and gets pointed to the DIA to obtain information not available publicly (i.e. via DNS). The information contained in the DIA is generally more oriented around the Operator of a given UAS and is thus classified as Personally Identifiable Information (PII). To protect the privacy of an Operator of the UAS this information is not publicly accessible and is only available behind policy driven differentiated access mechanisms (see Section 7). For DRIP, the Registration Data Access Protocol (RDAP) ([RFC7480], [RFC9082] and [RFC9083]) is the selected protocol to provide policy driven differentiated access for queries of information from clients. There MUST be a standardized interface for the DPA or Registry to add, update or delete information into the DIA. Specific details for these interfaces are out of scope for this document. An interface defined by the Registration Data Directory Service (RDDS) (Section 5.5) is also required as specified by the RDDS. Wiethuechter & Reid Expires 21 March 2024 [Page 15] Internet-Draft DETIM Architecture September 2023 +-----+ | DPA | +--o--+ | | | TBD | +----------+ TBD +--o--+ +------+ | Registry o-----------o DIA o-------------o RDDS | +----------+ +--o--+ TBD +------+ | | RDAP | | +-------o-------+ | Lookup Client | +---------------+ Figure 6: DIA Interface Mapping 5.5. Registration Data Directory Service (RDDS) This is the primary information database for the DIA. An interface MUST be provided to the DIA but its specification is out of scope for this document. +-----+ | DIA | +--o--+ | | | TBD | +---o--+ | RDDS | +--o---+ | | | RDAP | +----o----------+ | Lookup Client | +---------------+ Figure 7: RDDS Interface Mapping Wiethuechter & Reid Expires 21 March 2024 [Page 16] Internet-Draft DETIM Architecture September 2023 6. Registration/Provisioning Process The general process for a registering party is as follows: 1. Verify input Endorsement(s) from registering party 2. Check for collision of DET and HI 3. Populate Registry/Name Server with resource record(s) 4. Populate RDDS via DIA with PII and other info 5. Generate and return Endorsement(s) In the following subsections an abbreviated form of Section 5 using co-located components is used to describe the flow of information. The data elements being transmitted between entities is marked accordingly in each figure for the specific examples. Each section has an associated appendix (Appendix C) containing DNS examples. 6.1. Serial Number Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section becomes the basis for a new document and is removed from here. There are four ways a Serial Number is supported by DRIP: 1. As a clear-text string with additional information (Section 6.1.1) 2. As a clear-text string mapped to a DET "post" generation by the *manufacturer* (for use in authentication) and additional information (Section 6.1.2) 3. As a clear-text string mapped to a DET "post" generation by the *user (via an HDA)* (for use in authentication) and additional information (Section 6.1.3) 4. As an encoding of an HI and associated DET by the *manufacturer* (for use in authentication) with additional information (Section 6.1.4) Note: additional information here refers to any subset of keys defined in Section 11.2.1. Wiethuechter & Reid Expires 21 March 2024 [Page 17] Internet-Draft DETIM Architecture September 2023 6.1.1. Serial Method 1 This is where a UA is provisioned with a Serial Number by the manufacturer. The Serial Number is just text string, defined by [CTA2063A]. The manufacturer runs an Name Server delegated under the Serial Number apex and points to information using a DET RR (filling in only the Serial Number and URI fields). +-------------------+ | Unmanned Aircraft | +--o---o------------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: MAA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information (b) Success Code (c) DET RR (d) UA Information Figure 8: Example DIME:MAA with Serial Number Registration 6.1.2. Serial Method 2 This is where a UAS is provisioned with a Serial Number and DET by the manufacturer enabling their devices to use [drip-auth] and provide additional information. A public mapping of the Serial Number to DET and all public artifacts MUST be provided by the manufacturer. The manufacturer MUST use an MAA for this task. Wiethuechter & Reid Expires 21 March 2024 [Page 18] Internet-Draft DETIM Architecture September 2023 The device MAY allow the DET to be regenerated dynamically with the MAA. +-------------------+ | Unmanned Aircraft | +--o---o------------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: MAA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: MAA on UA (c) DET RR, PTR RR (d) UA Information Figure 9: Example DIME:MAA with Serial Number + DET Registration 6.1.3. Serial Method 3 This is where a UAS has a Serial Number (from the manufacturer) and the user (via a DIME) has a mechanism to generate and map a DET to the Serial Number after production. This can provide dynamic signing keys for DRIP Authentication Messages via [drip-auth] for UAS that MUST fly only using Serial Numbers. Registration SHOULD be allowed to any relevant DIME that supports it. A public mapping of the DET to the Serial Number SHOULD be provided. Wiethuechter & Reid Expires 21 March 2024 [Page 19] Internet-Draft DETIM Architecture September 2023 +-------------------+ | Unmanned Aircraft | +--o---o------------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: DIME on UA (c) DET RR (d) UA Information Figure 10: Example DIME with Serial Number + DET Registration 6.1.4. Serial Method 4 This is where a UAS manufacturer chooses to use the Serial Number scheme defined in [RFC9374] to create Serial Numbers, their associated DETs for [drip-auth] and provide additional information. This document RECOMMENDS that the manufacturer "locks" the device from changing its authentication method so identifiers in both the Basic ID Message and Authentication Message do not de-sync. The manufacturer MUST use an MAA for this task, with the mapping between their Manufacturer Code and the upper portion of the DET publicly available. Wiethuechter & Reid Expires 21 March 2024 [Page 20] Internet-Draft DETIM Architecture September 2023 +-------------------+ | Unmanned Aircraft | +--o---o------------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: MAA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Serial Number, UA Information, Self-Endorsement: UA (b) Success Code, Broadcast Endorsement: MAA on UA (c) DET RR (d) UA Information Figure 11: Example DIME:MAA with DRIP Serial Number Registration 6.2. Operator Provided either by USS or CAA run HDAs. Regulation might require interaction between them. An Operator can request that certain information normally generated and provisioned into DNS be omitted due to privacy concerns. Wiethuechter & Reid Expires 21 March 2024 [Page 21] Internet-Draft DETIM Architecture September 2023 +----------+ | Operator | +--o---o---+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME:HDA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Operator Information, Operator Self-Endorsement (b) Success Code, Generic Endorsement: HDA on Operator (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) Operator Information Note: (c) MAY be requested by the Operator to be omitted due to PII concerns. Figure 12: Example DIME:HDA with Operator (DET) Registration The definition of Operator Information is out of scope of this document and left to local regulations (both in its format and contents). 6.3. Session ID Session IDs are generally handled by HDAs. In Figure 13 the UAS comprises of an unmanned aircraft and a Ground Control Station (GCS). Both parties are involved in the registration process. Wiethuechter & Reid Expires 21 March 2024 [Page 22] Internet-Draft DETIM Architecture September 2023 +---------+ | UAS | +--o---o--+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: HDA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Mutual Endorsement: HDA on GCS, Generic Endorsement: GCS on UA, Session ID Information (b) Success Code, Broadcast Endorsement: HDA on UA, Generic Endorsement: HDA on UAS (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) Session ID Information Figure 13: Example DIME:HDA with Session ID (DET) Registration Through mechanisms not specified in this document the Operator should have methods (via the GCS) to instruct the unmanned aircraft onboard systems to generate a keypair, DET and Self-Endorsement: UA. The Self-Endorsement: UA is extracted by the Operator onto the GCS. The GCS is already pre-provisioned and registered to the DIME with its own keypair, DET, Self-Endorsement: GCS and Generic Endorsement: HDA on GCS. The GCS creates a new Generic Endorsement: GCS on UA and also creates Mutual Endorsement: HDA on GCS. These new endorsements along with Session ID Information are sent to the DIME via a secure channel. Wiethuechter & Reid Expires 21 March 2024 [Page 23] Internet-Draft DETIM Architecture September 2023 The GCS injects the Broadcast Endorsement: HDA on UA securely into the unmanned aircraft. Endorsement: HDA on GCS is securely stored by the GCS. Note: in Figure 13 the Session ID Information is expected to contain the Serial Number along with other PII specific information (such as UTM data) related to the Session ID. Session ID Information is defined as the current model: sessionid_info = { serial: tstr .size 20, session_id: tstr, operational_intent: tstr, intent_src: tstr, operator_id: tstr, session_context: tstr, * tstr: any } Future standards or implementations MAY add other keys to this list (for local features and/or local regulation). 6.3.1. UA Based Session ID There may be some unmanned aircraft that have their own Internet connectivity allowing them to register a Session ID themselves without outside help from other devices such as a GCS. When such a system is in use its imperative that the Operator has some method to create the Generic Endorsement: Operator on UA to send to the DIME. The process and methods to perform this are out of scope for this document but MUST be done in a secure fashion. 6.3.2. UAS Based Session ID Most unmanned aircraft will not have their own Internet connectivity but will have a connection to a GCS. Typically a GCS is an application on a user device (such as smartphone) that allow the user to fly their aircraft. For the Session ID registration the DIME MUST be provided with an Generic Endorsement: GCS on UA which implies there is some mechanism extracting and inserting information from the unmanned aircraft to the GCS. These methods MUST be secure but are out of scope for this document. With this system it is also possible to have the GCS generate the DET based Session ID and insert it securely into the unmanned aircraft after registration is done. This is NOT RECOMMENDED as this invalidates the objective of the asymmetric cryptography in the Wiethuechter & Reid Expires 21 March 2024 [Page 24] Internet-Draft DETIM Architecture September 2023 underlying DET as the private key MAY get in the possession of another entity other than the unmanned aircraft. See Section 12.2 for more details. 6.4. Child DIME Handled by the Apex and RAA's. This is an endpoint that handles dynamic registration (or key roll-over) of lower-level DIMEs (RAAs to Apex and HDAs to RAAs) in the hierarchy. +---------------+ | DIME: HDA | +--o---o--------+ | ^ (a) | | (b) | | *******|***|***************************** * | | DIME: RAA * * | | * * v | +----------+ * * +--o---o--+ | | * * | DPA o--------->o | * * +----o----+ (d) | | * * | | | * * | (c) | DIA/RDDS | * * v | | * * +----o--------+ | | * * | Registry/NS | | | * * +-------------+ | | * * +----------+ * * * ***************************************** (a) Self-Endorsement: HDA, HDA Information or Generic Endorsement: old HDA, new HDA (b) Success Code, Broadcast Endorsement: RAA on HDA (c) HIP RR, DET RR, TLSA RR, URI RR, PTR RR (d) HDA Information Figure 14: Example DIME:RAA with DIME:HDA Registration Wiethuechter & Reid Expires 21 March 2024 [Page 25] Internet-Draft DETIM Architecture September 2023 It should be noted that this endpoint DOES NOT hand out dynamically RAA/HDA values to systems that hit the endpoint. This is done out- of-band through processes specified by local regulations and performed by cognizant authorities. The endpoint MUST NOT accept queries it is not previously informed of being expected via mechanisms not defined in this document. It is OPTIONAL to implement this endpoint. This MAY be used to handle lower-level DIME key roll-over. 7. Differentiated Access Process Per [RFC9434] all information classified as public is stored in a datastore protected using some form of differentiated access (i.e. AAA) to satisfy REG-2 from [RFC9153]. Differentiated access, as a process, is a requirement for DIMEs as defined in [RFC9153] by the combination of PRIV-1, PRIV-3, PRIV-4, REG-2 and REG-4. [RFC9434] further elaborates on the concept by citing RDAP (from [RFC7480], [RFC9082] and [RFC9083]) as a potential means of fulfilling this requirement. Typically the cognizant authority is the primary querant of private information from a DIME if a Session ID is reported (the case of the owner of the private information is ignored for the moment). This capability MAY be delegated to other parties at the authorities discretion (be it to a single user or many), thus requiring a flexible system to delegate, determine and revoke querent access rights for information. XACML MAY be a good technology choice for this flexibility. It is noted by the authors that as this system scales the problem becomes a, well known and tricky, key management problem. While recommendations for key management are useful they are not necessarily in scope for this document as best common practices around key management should already be mandated and enforced by the cognizant authorities in their existing systems. This document instead focuses on finding a balance for generic wide-spread interoperability between DIMEs with authorities and their existing systems in a Differentiated Access Process (DAP). A system where cognizant authorities would require individual credentials to each HDA is not scalable, nor practical. Any change in policy would require the authority to interact with every single HDA (active or inactive) to grant or revoke access; this would be tedious and prone to mistakes. A single credential for a given authority is also strongly NOT RECOMMENDED due to the security concerns it would entail if it leaked. Wiethuechter & Reid Expires 21 March 2024 [Page 26] Internet-Draft DETIM Architecture September 2023 A zero-trust model would be the most appropriate for a DAP; being highly flexible and robust. Most authorities however use "oracle" based systems with specific user credentials and the oracle knowing the access rights for a given user. This would require the DAP the have some standard mechanism to locate and query a given oracle for information on the querent to determine if access is granted. DRIP has no intention to develop a new "art" of key management, instead hoping to leverage existing systems and be flexible enough to adapt as new ones become popular. 8. DRIP in the Domain Name System Per [RFC9434] all information classified as public is stored in the DNS to satisfy REG-1 from [RFC9153]. The apex for domain names MUST be under the administrative control of ICAO, the international treaty organization providing the critical coordination platform for civil aviation. ICAO SHOULD be responsible for the operation of the DNS-related infrastructure for these domain name apexes. It MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two. ICAO SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times incident handling, complaints, law enforcement interaction and so on. The delegation of civil aviation authorities to RAAs is already done per Section 4.2.1 using their ISO 3166-1 Numeric Codes. Since these are public, any entity can stand up an RAA with that value. ICAO SHOULD be the root of trust in a Endorsement or certificate chain that provides validation of any of these specific RAAs, in the ISO RAA range, thus protecting against bad actors standing up fraudulent RAAs. This also ensures DRIP complies with national law and regulation since these are matters of national sovereignty. Wiethuechter & Reid Expires 21 March 2024 [Page 27] Internet-Draft DETIM Architecture September 2023 Each national aviation authority SHOULD be responsible for the operation of the DNS-related infrastructure for their delegated subdomains. As with the domain apexes overseen by ICAO, each national aviation authority MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two. National aviation authorities SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times, incident handling, complaints, law enforcement interaction and so on. These are National Matters where national law/regulation prevail. National policy and regulations will define how long DNS data are stored or archived. DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher zones). When a DIME decides to use DNSSEC they SHOULD define a framework for cryptographic algorithms and key management [RFC6841]. This may be influenced by frequency of updates, size of the zone, and policies. 8.1. DRIP Entity Tags The REQUIRED mechanism is to place any information into ip6.arpa when using a DET. Since the DET is an IPv6 address it can be nibble- reversed and used in the zone, per standard conventions. The prefix 2001:30/28 is registered with IANA [RFC9374] and 3.0.0.1.0.0.2.ip6.arpa - the corresponding reverse domain - SHOULD be under the administrative control of the Apex. In addition to the DNS infrastructure for 3.0.0.1.0.0.2.ip6.arpa, the Apex SHOULD be responsible for the allocation of IPv6 addresses in this prefix. An addressing plan will need to be developed. Distribution of HHIT (IPv6 address) blocks SHOULD be done using the 14-bit RAA space as a framework. The Apex SHOULD allocate blocks to each entity who can then assign them to HDAs in accordance with local law and policy. All HDAs MUST have an IPv6 address in 2001:30/28. A discrete zone SHOULD be delegated for each HDA. These MUST contain an DET resource record (Section 8.1.1) for itself. Reverse lookups of these IPv6 addresses will translate the address into a domain name in the manner defined in [RFC1886]. However, these lookups will query for, depending on what is required: HIP, DET, TLSA, URI, or PTR RRTypes. 8.1.1. DET Resource Record Wiethuechter & Reid Expires 21 March 2024 [Page 28] Internet-Draft DETIM Architecture September 2023 Author Note: This section is very much a WIP, comments are welcome. DET IN ( DET TYPE STATUS HID [SN] Endorsement ) DET = Base16 DET TYPE = enumeration of Type of DET STATUS = enumeration of Status of DET HID = HID Abbreviation SN = Serial Number (optional) Endorsement = Broadcast Endorsement in CBOR encoding With the SN parameter this covers the "public mapping to DET" when a user/manufacturer already has a Serial Number that can not change and wishes to do DRIP Authentication. 8.1.1.1. HID Abbreviation On receiver devices a DET can be translated to a more human readable form such as: {RAA Abbreviation} {HDA Abbreviation} {Last 4 Characters of DET Hash}. An example of this would be US FAA FE23. To support this DIMEs are RECOMMENDED to have an abbreviation that could be used for this form. These abbreviations SHOULD be a maximum of six characters (for each section) in length. Spaces MUST NOT be used and be replaced with either underscores (_) or dashes (-). The concatenation of {RAA Abbreviation} and {HDA Abbreviation} with a space between them is what fills in the HID field of the DET RR in Section 8.1.1. For RAAs allocated in the ISO range Section 4.2.1, the RAA abbreviation MUST be set to the ISO 3166-1 country code (either Alpha-2 or Alpha-3). If a DIME does not have an abbreviation or it can not be looked up then the receiver MUST use the uppercase 4-character hexadecimal encoding of the field it is missing. 8.2. Serial Numbers & Other UAS ID Types Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section is removed and becomes part of a new document. Author Note: There MUST be an entry point in DNS for the lookup of UAS Serial Numbers. This section is very much a shot in the dark. Wiethuechter & Reid Expires 21 March 2024 [Page 29] Internet-Draft DETIM Architecture September 2023 This document specifies the creation and delegation to ICAO of the subdomain uas.icao.arpa. To enable lookup of Serial Numbers a subdomains of sn.uas.icao.arpa is maintained. All entries under sn.uas.icao.arpa are to follow the convention found in Appendix A.2. This is to enable a singular lookup point for Serial Numbers for UAS. Note that other subdomains under uas.icao.arpa can be made to support other identifiers in UAS. The creation and use of other such other subdomains are out of scope for this document. The further use and creation of items under icao.arpa is the authority of ICAO (which has been delegated control). DETs MUST not have a subdomain in uas.icao.arpa (such as det.uas.icao.arpa) as they fit within the predefined ip6.arpa as they are IPv6 addresses. 9. Endorsements DRIP Endorsements are defined in a CDDL [RFC8610] structure (Figure 15) that can be encoded to CBOR, JSON or have their CDDL keys removed and be sent as a binary blob. When the latter is used very specific forms are defined with naming conventions to know the data fields and their lengths for parsing and constrained envirornments. CBOR is the preferred encoding format. The CDDL was derived from the more specific structure developed for [drip-auth]. As such the structures found in [drip-auth], such as the UA Signed Evidence and the contents of DRIP Link (known as a Broadcast Endorsement), are a subset of the below definition in a strict binary form. Appendix B specifies specific Endorsement structures for the UAS RID use-case. Note: this section uses the term HHIT instead of DET as the Endorsements are designed to be generic and re-useable for other HHIT use-cases. Specific use-cases SHOULD add new keys for each section (if required) and define the valid keys and encoding forms for their use-case. 9.1. Endorsement Structure Wiethuechter & Reid Expires 21 March 2024 [Page 30] Internet-Draft DETIM Architecture September 2023 endorsement = { ; TODO: add tag for self-describing type or leave up to cbor? scope: { vnb: number, vna: number, * tstr => any }, evidence: bstr, endorser: { identity: { hhit: bstr .size 16, ? hi: bstr // * tstr => any }, signature: { sig: bstr, * tstr => any } } } Figure 15: Endorsement CDDL 9.1.1. Scope The scope section is more formally "the scope of validity of the endorsement". The scope can come in various forms but MUST always have a "valid not before" (vnb) and "valid not after" (vna) timestamps. Other forms of the scope could for example be a 4-dimensional volume definition. This could be in raw latitude, longitude, altitude pairs or may be a URI pointing to scope information. Additional scope fields are out of scope for this document and should be defined for specific Endorsement structures if they are desired. 9.1.2. Evidence The evidence section contain a byte string of evidence. Specific content of evidence (such as subfields, length and ordering) is defined in specific Endorsement structures. 9.1.3. Identity The identity section is where the main identity information of the signer of the Endorsement is found. The identity can take many forms such as a handle to the identity (e.g. an HHIT), or can include more explicit data such as the public key (e.g. an HI). Other keys, for different identifiers, can be provided and MUST be defined in their specific Endorsement. Wiethuechter & Reid Expires 21 March 2024 [Page 31] Internet-Draft DETIM Architecture September 2023 The length of the hi can be determined when using hhit by decoding the provided IPv6 address. The prefix will inform of the ORCHID construction being used, which informs the locations of the OGA ID in the address. The OGA ID will then inform the user of the key algorithm selected which has the key length defined. 9.1.4. Signature The signature section contain the signature data for the Endorsement. The signature itself MUST be provided under the sig key. Other forms or data elements could also be present in the signature section if specified in a specific Endorsement. Signatures MUST be generated using the preceding sections in their binary forms (i.e. as a bytestring with no keys). 10. X.509 Certificates 10.1. Certificate Policy and Certificate Stores X.509 certificates are optional for the DRIP entities covered in this document. DRIP endpoint entities (EE) (i.e., UA, GCS, and Operators) may benefit from having X.509 certificates. Most of these certificates will be for their DET and some will be for other UAS identities. To provide for these certificates, some of the other entities (e.g. USS) covered in this document will also have certificates to create and manage the necessary PKI structure. Three certificate profiles are defined, with examples, and explained in [drip-dki]. Each has a specific role to play and an EE may have its DET enrolled in all of them. There is a 'Lite' profile that would work well enough on constrained communication links for those instances where various issues push the use of X.509. There is a 'Basic; profile that is more in line with [RFC5280] recommendations, but is still small enough for many constrained environments. Finally there is a profile to directly add DET support into the civil/general aviation certificates as discussed below. A Certificate Authority (CA) supporting DRIP entities MAY adhere to the ICAO's Aviation Common Certificate Policy (ACCP) [ICAO-IATF-CP- draft]. The CA(s) supporting this CP MUST either be a part of the ACCP cross-certification or part of the ACCP CA Trust List. It is possible that future versions of the ACCP will directly support the DRIP Basic profile. Note ACCP is: ICAO Doc 10169 Aviation Common Certificate Policy (ACCP). I can't get a url for that, but so far these is no changes from v 0.93 of the old IATF CP; changes are in the works then will be posted, so continue to reference IATF CP Wiethuechter & Reid Expires 21 March 2024 [Page 32] Internet-Draft DETIM Architecture September 2023 EEs may use their X.509 certificates, rather than their rawPublicKey (i.e. HI) in authentication protocols (as not all may support rawPublicKey identities). Short lived DETs like those used for a single operation or even for a day's operations may not benefit from X.509. Creating then almost immediately revoking these certificates is a considerable burden on all parts of the system. Even using a short notAfter date will not completely mitigate the burden of managing these certificates. That said, many EEs will benefit to offset the effort. It may also be a regulator requirement to have these certificates. Finally, certificates can provide the context of use for a DET (via policy constraint OIDs). Typically an HDA either does or does not issue a certificate for all its DETs. An RAA may specifically have some HDAs for DETs that do not want/need certificates and other HDAs for DETs that do need them. These types of HDAs could be managed by a single entity thus providing both environments for its customers. It is recommended that DRIP X.509 certificates be stored as DNS TLSA Resource Records, using the DET as the lookup key. This not only generally improves certificate lookups, but also enables use of DANE [RFC6698] for the various servers in the UTM and particularly DIME environment and DANCE [dane-clients] for EEs (e.g. [drip-secure-nrid-c2]). All DRIP certificates MAY alternatively be available via RDAP. LDAP/OCSP access for other UTM and ICAO uses SHOULD also be provided. 10.2. Certificate Management PKIX standard X.509 issuance practices should be used. The certificate request SHOULD be included in the DET registration request. A successful DET registration then MUST include certificate creation, store, and return to the DET registrant. It is possible that the DET registration is actually an X.509 registration. For example, PKIX CSR may be directly used and the DET registration and Endorsement creation are a addition to this process. Further ACME may be directly extendable to provide the DET registration. Note that CSRs do not include the certificate validityDate; adding that is done by the CA. If in the registration process, the EE is the source of notBefore and notAfter dates, they need to be sent along with the CSR. Certificate revocation will parallel DET revocation. TLSA RR MUST be deleted from DNS and RDAP, LDAP, and OCSP return revoked responses. CRLs SHOULD be maintained per the CP. Wiethuechter & Reid Expires 21 March 2024 [Page 33] Internet-Draft DETIM Architecture September 2023 10.3. Examples For full examples of X.509 Certificates and the process to use them see [drip-dki]. 10.4. Alternative Certificate Encoding (CBOR encoded certs here. TBD) 11. IANA Considerations 11.1. Delegation of Nibble Reversed IPv6 Prefix For DRIP to function in a interoperable way the easiest way to allow look up of DETs is through the already existing ip6.arpa domain structure (as defined in this document). Here IPv6 addresses are nibble reversed and usually have PTR records. With DRIP the prefix 2001:30/28 has been allocated by IANA already for DRIP use. However its representative reverse domain in ip6.arpa has not. There are a number of questions in this area for DRIP: 1. What organization would have administrative control over the nibble-reversed ip6.arpa block for 2001:30/28? * How do they obtain this and from whom? * What is the SLA between IANA/ICANN and the administrative organization for nibble-reversed 2001:30/28? 2. What organization would have technical control (i.e. day to day operations) over the nibble-reversed ip6.arpa block for 2001:30/28? 3. How are delegation/allocation of further nibble-reversed sub- blocks from 2001:30/28 handled by the administrative organization? * This is partly covered in this document already (Apex->RAA->HDA) * What is the SLA between the administrative organization and sub-organizations given delegations/allocations? This might be more general guidelines than an actual SLA? Wiethuechter & Reid Expires 21 March 2024 [Page 34] Internet-Draft DETIM Architecture September 2023 4. What goes into a nibble-reversed ip6.arpa domain for DRIP at each level? This is not an exhaustive list of questions, this is more to get discussion going. 11.2. IANA DRIP Registry 11.2.1. Aircraft Information Registry This document requests a new registry for aircraft information fields under the DRIP registry group (https://www.iana.org/assignments/drip/ drip.xhtml). Aircraft Information Fields: list of acceptable keys to be used in UA Information during a UA registration to a DIME. Future additions to this registry are to be made through First Come First Served (Section 4.4 of [RFC8126]). The following values are defined: +======================+=======+========================+ | Key Name | Type | Description | +======================+=======+========================+ | length | float | length, in millimeters | +----------------------+-------+------------------------+ | width | float | width, in millimeters | +----------------------+-------+------------------------+ | height | float | height, in millimeters | +----------------------+-------+------------------------+ | constructionMaterial | tstr | materials, comma | | | | separated if multiple | +----------------------+-------+------------------------+ | color | tstr | colors, comma | | | | separated if multiple | +----------------------+-------+------------------------+ | serial | tstr | ANSI CTA 2063-A Serial | | | | Number | +----------------------+-------+------------------------+ | manufacturer | tstr | manufacturer name | +----------------------+-------+------------------------+ | make | tstr | aircraft make | +----------------------+-------+------------------------+ | model | tstr | aircraft model | +----------------------+-------+------------------------+ | dryWeight | float | weight of aircraft | | | | with no payloads | +----------------------+-------+------------------------+ | numRotors | int | Number of rotators | Wiethuechter & Reid Expires 21 March 2024 [Page 35] Internet-Draft DETIM Architecture September 2023 +----------------------+-------+------------------------+ | propLength | float | Length of props, in | | | | centimeters | +----------------------+-------+------------------------+ | numBatteries | int | | +----------------------+-------+------------------------+ | batteryCapacity | float | in milliampere hours | +----------------------+-------+------------------------+ | batteryWeight | float | in kilograms | +----------------------+-------+------------------------+ | batteryVoltage | float | in volts | +----------------------+-------+------------------------+ | batteryChemistry | tstr | | +----------------------+-------+------------------------+ | maxTakeOffWeight | float | in kilograms | +----------------------+-------+------------------------+ | maxPayloadWeight | float | in kilograms | +----------------------+-------+------------------------+ | maxFlightTime | float | in minutes | +----------------------+-------+------------------------+ | minOperatingTemp | float | in Celsius | +----------------------+-------+------------------------+ | maxOperatingTemp | float | in Celsius | +----------------------+-------+------------------------+ | ipRating | tstr | standard IP rating | +----------------------+-------+------------------------+ | engineType | tstr | | +----------------------+-------+------------------------+ | fuelType | tstr | | +----------------------+-------+------------------------+ | fuelCapacity | float | in liters | +----------------------+-------+------------------------+ | previousSerial | tstr | legacy serial | | | | number(s) | +----------------------+-------+------------------------+ Table 2 11.2.2. Endorsement Fields This document requests a new registry for Endorsement fields under the DRIP registry group (https://www.iana.org/assignments/drip/ drip.xhtml). Endorsement Fields: list of field keys to be used in an Endorsement and what section(s) they can be used in. Future additions to this registry are to be made through First Come First Served (Section 4.4 of [RFC8126]). The following values are defined: Wiethuechter & Reid Expires 21 March 2024 [Page 36] Internet-Draft DETIM Architecture September 2023 +============+========+===========+==============================+ | Field Name | Type | Useable | Description | | | | Sections | | +============+========+===========+==============================+ | vna | number | scope | Valid Not After, UTC Unix | | | | | Timestamp | +------------+--------+-----------+------------------------------+ | vnb | number | scope | Valid Not Before, UTC Unix | | | | | Timestamp | +------------+--------+-----------+------------------------------+ | hhit | bstr | identity | Hierarchial Host Identity | | | | | Tag (HHIT), fixed size of 16 | +------------+--------+-----------+------------------------------+ | hi | bstr | identity | Host Identity (HI) | +------------+--------+-----------+------------------------------+ | sig | bstr | signature | Signature | +------------+--------+-----------+------------------------------+ Table 3 12. Security Considerations 12.1. Key Rollover & Federation During key rollover the DIME MUST inform all children and parents of the change - using best standard practices of a key rollover. A DET has a natural ability for a single DIME to hold different cryptographic identities under the same HID values. This is due to the lower 64-bits of the DET being a hash of the public key and the HID of the DET being generated. As such during key rollover, only the lower 64-bits would change and a check for a collision would be required. This attribute could also allow for a single DIME to be "federated" across multiple DETs sharing the same HID value. This method of deployment has not been thoroughly studied at this time. An endpoint such as in Section 6.4 is a possible place to have these functions. 12.2. DET Generation Author Note: is this section valid anymore? Perhaps we hard specify that devices ONLY generate on their own hardware instead of "out-sourcing" as this section implies. Under the FAA [NPRM], it is expecting that IDs for UAS are assigned by the UTM and are generally one-time use. The methods for this however are unspecified leaving two options. Wiethuechter & Reid Expires 21 March 2024 [Page 37] Internet-Draft DETIM Architecture September 2023 Option 1: The entity generates its own DET, discovering and using the RAA and HDA for the target DIME. The method for discovering a DIME's RAA and HDA is out of scope here. This allows for the device to generate an DET to send to the DIME to be accepted (thus generating the required Self-Endorsement) or denied. Option 2: The entity sends to the DIME its HI for it to be hashed and result in the DET. The DIME would then either accept (returning the DET to the device) or deny this pairing. Keypairs are expected to be generated on the device hardware it will be used on. Due to hardware limitations and connectivity it is acceptable, though not recommended, under DRIP to generate keypairs for the Aircraft on Operator devices and later securely inject them into the Aircraft. The methods to securely inject and store keypair information in a "secure element" of the Aircraft is out of scope of this document. 13. Contributors Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT Consulting, LLC) for their early work on the DRIP registries concept. Their early contributions laid the foundations for the content and processes of this architecture and document. Bob Moskowitz is also instrumental in the PKIX work defined in this document with his parallel work in ICAO. 14. References 14.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Wiethuechter & Reid Expires 21 March 2024 [Page 38] Internet-Draft DETIM Architecture September 2023 [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, . [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, . [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, . [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, . 14.2. Informative References [CTA2063A] "ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers", September 2019, . [dane-clients] Huque, S. and V. Dukhovni, "TLS Client Authentication via DANE TLSA records", Work in Progress, Internet-Draft, draft-ietf-dance-client-auth-02, 12 May 2023, . [drip-auth] Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID", Work in Progress, Internet-Draft, draft-ietf-drip-auth-32, 18 September 2023, . [drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key Infrastructure", Work in Progress, Internet-Draft, draft- moskowitz-drip-dki-07, 10 July 2023, . Wiethuechter & Reid Expires 21 March 2024 [Page 39] Internet-Draft DETIM Architecture September 2023 [drip-secure-nrid-c2] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. Gurtov, "Secure UAS Network RID and C2 Transport", Work in Progress, Internet-Draft, draft-moskowitz-drip-secure- nrid-c2-12, 26 March 2023, . [NPRM] "Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems", December 2019. [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995, . [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, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, . [RFC7480] 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, . [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, . Wiethuechter & Reid Expires 21 March 2024 [Page 40] Internet-Draft DETIM Architecture September 2023 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . Appendix A. DRIP Fully Qualified Domain Names A.1. DRIP Entity Tag {hash}.{oga_id}.{hda}.{raa}.{prefix}.{apex}. When building a DET FQDN it MUST must be built using the exploded (all padding present) form of the IPv6 address. Apex: .example.com DET: 2001:0030:0280:1405:c465:1542:a33f:dc26 ID: c4651542a33fdc26 OGA: 05 HID: 0028014 HDA: 0014 RAA: 000a Prefix: 2001003 FQDN: c4651542a33fdc26.05.0014.000a.2001003.example.com A.2. UAS Serial Number Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, this section is removed and part of a new document. {id}.{length}.{manufacturer-code}.{apex}. Apex: .sn.uas.icao.arpa. Serial: MFR0ADR1P1SC00L Manufacturer Code: MFR0 Length: A ID: DR1P1SC00L FQDN: dr1p1sc00l.a.mfr0.sn.uas.icao.arpa. Appendix B. DRIP Endorsements for UAS B.1. Generic Endorsement Wiethuechter & Reid Expires 21 March 2024 [Page 41] Internet-Draft DETIM Architecture September 2023 generic_endorsement = { scope: { vnb: number, vna: number }, evidence: bstr, endorser: { identity: { hhit: bstr .size 16 }, signature: { sig: bstr } } } Figure 16: Generic Endorsement CDDL evidence is a binary string with specified contents (in format and ordering) by specific use-cases. As an example this format is used by [drip-auth] to support Authentication over F3411 constrained links. evidence data is defined by [drip-auth] for DRIP Wrapper, Manifest and Frame formats. B.2. Self Endorsement self_endorsement = { scope: { vnb: number, vna: number }, evidence: bstr, endorser: { identity: { hhit: bstr .size 16 }, signature: { sig: bstr } } } Figure 17: Self Endorsement CDDL Used during registration process as an input. evidence is filled with the corresponding HI of the hhit. Wiethuechter & Reid Expires 21 March 2024 [Page 42] Internet-Draft DETIM Architecture September 2023 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | VNB | +---------------+---------------+---------------+---------------+ | VNA | +---------------+---------------+---------------+---------------+ | | | | | | | HI | | | | | | | | | +---------------+---------------+---------------+---------------+ | | | HHIT | | | | | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Figure 18: Self Endorsement Binary TODO Figure 19: Self Endorsement CBOR B.3. Broadcast Endorsement Wiethuechter & Reid Expires 21 March 2024 [Page 43] Internet-Draft DETIM Architecture September 2023 broadcast_endorsement = { scope: { vnb: number, vna: number }, evidence: bstr, endorser: { identity: { hhit: bstr .size 16 }, signature: { sig: bstr } } } Figure 20: Broadcast Endorsement CDDL Defined by [drip-auth] in a binary format to support Authentication over F3411 constrained links. Used in the DRIP Link format. A required output of registration to a DIME at any level. evidence is a binary string of the concatination of a child entities (e.g. a UA) HHIT and its associated HI. hhit is of the parent entity (e.g. a DIME). Wiethuechter & Reid Expires 21 March 2024 [Page 44] Internet-Draft DETIM Architecture September 2023 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | VNB | +---------------+---------------+---------------+---------------+ | VNA | +---------------+---------------+---------------+---------------+ | | | HHIT of | | Child | | | +---------------+---------------+---------------+---------------+ | | | | | | | HI of | | Child | | | | | | | +---------------+---------------+---------------+---------------+ | | | HHIT of | | Parent | | | +---------------+---------------+---------------+---------------+ | | | | | | | | | | | | | | | Signature | | | | | | | | | | | | | | | | | +---------------+---------------+---------------+---------------+ Figure 21: Broadcast Endorsement Binary TODO Wiethuechter & Reid Expires 21 March 2024 [Page 45] Internet-Draft DETIM Architecture September 2023 Figure 22: Broadcast Endorsement CBOR Appendix C. DNS Examples Author Note: with the proposal to remove solving the issue of putting Serial Numbers into DNS from this document, Serial Numbers section is removed and part of a new document. C.1. Serial Method 1 @ORIGIN mfr0.uas-sn.arpa example1.8 IN URI ( https://example.com/sn/EXAMPLE1 ) C.2. Serial Method 2 @ORIGIN mfr0.uas-sn.arpa example2.8 IN DET ( 5 20010033e872f705f3ce91124b677d65 ... "MFR MFR0" MFR08EXAMPLE2 https://example.com/sn/EXAMPLE2 ... active ) @ORIGIN 3.2.f.7.0.f.a.1.3.0.0.1.0.0.2.ip6.arpa 6.5.d.7.7.6.b.4.2.1.1.9.e.c.3.f.5.0 IN PTR example2.8.mfr0.uas-sn.arpa C.3. Serial Method 3 @ORIGIN mfr0.uas-sn.arpa example3.8 IN DET ( 5 20010033e872f70584b1fa2b70421112 ... "MFR MFR0" MFR08EXAMPLE3 https://example.com/sn/EXAMPLE3 ... active ) @ORIGIN 3.2.f.7.0.f.a.1.3.0.0.1.0.0.2.ip6.arpa 2.1.1.1.2.4.0.7.b.2.a.f.1.b.4.8.5.0 IN PTR example3.8.mfr0.uas-sn.arpa C.4. Serial Method 4 @ORIGIN mfr0.uas-sn.arpa example4.8 IN DET ( 5 20010033e872f705ba8af5252a35030e ... "MFR MFR0" MFR08EXAMPLE4 https://example.com/sn/EXAMPLE4 ... active ) @ORIGIN 3.2.f.7.0.f.a.1.3.0.0.1.0.0.2.ip6.arpa e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN PTR example4.8.mfr0.uas-sn.arpa C.5. Operator @ORIGIN 0000.3ffe.2001003.hhit.arpa ba8af5252a35030e.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff800005ba8af5252a35030e ... "TEST DRIP" null https://example.com/operator/* ... active ) @ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa e.0.3.0.5.3.a.2.5.2.5.f.a.8.a.b.5.0 IN PTR ba8af5252a35030e.05.0000.3ffe.2001003.hhit.arpa C.6. Session ID Wiethuechter & Reid Expires 21 March 2024 [Page 46] Internet-Draft DETIM Architecture September 2023 @ORIGIN 0000.3ffe.2001003.hhit.arpa b6ce935b616306d4.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff800005b6ce935b616306d4 ... "TEST DRIP" null https://example.com/session/* ... active ) @ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa 4.d.6.0.3.6.1.6.b.5.3.9.e.c.6.b.5.0 IN PTR b6ce935b616306d4.05.0000.3ffe.2001003.hhit.arpa C.7. Child DIME RAA: @ORIGIN 8.f.f.f.3.0.0.1.0.0.2.ip6.arpa 0.0.0 IN NS 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa HDA: @ORIGIN 0.0.0.8.f.f.f.3.0.0.1.0.0.2.ip6.arpa 9.6.6.b.b.0.6.a.4.9.3.6.8.4.e.4.5.0 IN PTR 4e486394a60bb669.05.0000.3ffe.2001003.hhit.arpa @ORIGIN 0000.3ffe.2001003.hhit.arpa 4e486394a60bb669.05.0000.3ffe.2001003.hhit.arpa IN DET ( 5 2001003fff8000054e486394a60bb669 ... "TEST DRIP" null https://example.com/session/* ... active ) Authors' Addresses Adam Wiethuechter (editor) AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Jim Reid RTFM llp St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL United Kingdom Email: jim@rfc1035.com Wiethuechter & Reid Expires 21 March 2024 [Page 47]