Skip to main content

DRIP Entity Tag (DET) Identity Management Architecture
draft-ietf-drip-registries-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Adam Wiethuechter , Jim Reid
Last updated 2023-03-28
Replaces draft-wiethuechter-drip-registries
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
OPSDIR Early review by Joel Jaeggli Partially completed Has issues
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestones
Sep 2020
Solution space documents adopted by the WG
Mar 2024
Submit DRIP Registries to the IESG
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-drip-registries-09
drip Working Group                                       A. Wiethuechter
Internet-Draft                                        AX Enterprize, LLC
Intended status: Informational                                   J. Reid
Expires: 29 September 2023                                      RTFM llp
                                                           28 March 2023

         DRIP Entity Tag (DET) Identity Management Architecture
                     draft-ietf-drip-registries-09

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 the existing DNS
   structure and 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 29 September 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wiethuechter & Reid     Expires 29 September 2023               [Page 1]
Internet-Draft             DETIM Architecture                 March 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  . . . . . . . . . . . . . . .   4
     2.1.  Supported Scenarios . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Required Terminology  . . . . . . . . . . . . . . . . . .   6
     3.2.  Additional Definitions  . . . . . . . . . . . . . . . . .   6
   4.  DIME Roles  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Apex  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Registered Assigning Authority (RAA)  . . . . . . . . . .   7
       4.2.1.  ICAO Authority of Manufacturers (IAM) . . . . . . . .   8
     4.3.  Hierarchial HIT Domain Authority (HDA)  . . . . . . . . .   8
       4.3.1.  Manufacturers Authority of Aircraft (MAA) . . . . . .   8
       4.3.2.  Session ID Authority (SIDA) . . . . . . . . . . . . .   9
     4.4.  Role Abbreviation in DETs . . . . . . . . . . . . . . . .   9
     4.5.  Text Conventions  . . . . . . . . . . . . . . . . . . . .   9
   5.  DIME Architecture . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  DRIP Provisioning Agent (DPA) . . . . . . . . . . . . . .  11
     5.2.  Registry  . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Name Server (NS)  . . . . . . . . . . . . . . . . . . . .  11
     5.4.  DRIP Information Agent (DIA)  . . . . . . . . . . . . . .  12
     5.5.  Registration Data Directory Service (RDDS)  . . . . . . .  12
   6.  Registration/Provisioning Process . . . . . . . . . . . . . .  12
     6.1.  Serial Number . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Operator  . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.3.  Session ID  . . . . . . . . . . . . . . . . . . . . . . .  17
       6.3.1.  UA Based  . . . . . . . . . . . . . . . . . . . . . .  19
       6.3.2.  UAS Based . . . . . . . . . . . . . . . . . . . . . .  19
     6.4.  Child DIME  . . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Differentiated Access Process . . . . . . . . . . . . . . . .  21
   8.  DRIP in the Domain Name System  . . . . . . . . . . . . . . .  22
     8.1.  DRIP Entity Tags  . . . . . . . . . . . . . . . . . . . .  23
     8.2.  Serial Numbers & Other UAS ID Types . . . . . . . . . . .  24
   9.  Endorsements  . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Endorsement Structure . . . . . . . . . . . . . . . . . .  24
       9.1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  25
       9.1.2.  Evidence  . . . . . . . . . . . . . . . . . . . . . .  25
       9.1.3.  Identity  . . . . . . . . . . . . . . . . . . . . . .  25

Wiethuechter & Reid     Expires 29 September 2023               [Page 2]
Internet-Draft             DETIM Architecture                 March 2023

       9.1.4.  Signature . . . . . . . . . . . . . . . . . . . . . .  26
   10. X.509 Certificates  . . . . . . . . . . . . . . . . . . . . .  26
     10.1.  Certificate Policy and Certificate Stores  . . . . . . .  26
     10.2.  Certificate Management . . . . . . . . . . . . . . . . .  27
     10.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  27
     10.4.  Alternative Certificate Encoding . . . . . . . . . . . .  27
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     11.1.  IANA DRIP Registry . . . . . . . . . . . . . . . . . . .  27
       11.1.1.  Aircraft Information Registry  . . . . . . . . . . .  27
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  29
     12.1.  Key Rollover & Federation  . . . . . . . . . . . . . . .  29
     12.2.  DET Generation . . . . . . . . . . . . . . . . . . . . .  30
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  30
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     14.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Appendix A.  DRIP Fully Qualified Domain Names  . . . . . . . . .  33
     A.1.  DRIP Entity Tag . . . . . . . . . . . . . . . . . . . . .  33
     A.2.  UAS Serial Number . . . . . . . . . . . . . . . . . . . .  33
   Appendix B.  DRIP Endorsements for UAS  . . . . . . . . . . . . .  33
     B.1.  Self Endorsement  . . . . . . . . . . . . . . . . . . . .  33
     B.2.  Generic Endorsement . . . . . . . . . . . . . . . . . . .  35
     B.3.  Broadcast Endorsement . . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

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 sent is the UAS ID itself, the
   unique key for lookup of extended information in relevant registries
   (see Figure 4 of [drip-arch]).

   While it is expected that DIME functions will be integrated with UAS
   Service Supplier (USS) (Appendix A.2 of [drip-arch]), who will
   provide them is not yet determined in most, and is expected to vary
   between jurisdictions.  However this evolves, the essential DIME
   functions (including the management of identifiers) are expected to
   remain the same, so are specified herein.

   While most data to be sent via Broadcast RID (Section 1.2.1 of
   [drip-arch]) or Network RID (Section 1.2.2 of [drip-arch]) is public,
   much of the extended information in registries will be private.  As
   discussed in Section 7 of [drip-arch], 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

Wiethuechter & Reid     Expires 29 September 2023               [Page 3]
Internet-Draft             DETIM Architecture                 March 2023

   also to support subsequent attribution of any leaks, audit of who
   accessed information when and for what purpose, etc.  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 DRIP Entity Tags (DETs).  Forgery of the
   DETs is still possible, but including it as a part of a public
   registration mitigates this risk.  This document creates the DRIP 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.

2.  Abstract Process and Reasoning

   In DRIP each entity (DIME, Operator, UA, etc.) is expected to
   generate a full DRIP Entity Tag [RFC9374] on the local device their
   key is expected to be used.  These are registered with a Public
   Information Registry 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.  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

Wiethuechter & Reid     Expires 29 September 2023               [Page 4]
Internet-Draft             DETIM Architecture                 March 2023

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

   1.  UA using manufacturer generated Serial Number for UAS ID.  No
       additional information provided.

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

Wiethuechter & Reid     Expires 29 September 2023               [Page 5]
Internet-Draft             DETIM Architecture                 March 2023

   5.  UA using manufacturer generated Serial Number for UAS ID.  UA
       using user generated DET for Authentication.  User uses DIME with
       capability to publically 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
   [drip-arch], while others (RAA, HDA, etc.) are from [RFC9374].

4.  DIME Roles

   [drip-arch] defines the DRIP Identity Management Entity (DIME) as an
   entity that vets Claims and/or Evidence from a registrant and
   delivers back 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 roles are illustrated in
   Figure 1.

Wiethuechter & Reid     Expires 29 September 2023               [Page 6]
Internet-Draft             DETIM Architecture                 March 2023

                          +----------+
                          |   Apex   |
                          +-o------o-+
                            |      |
          ******************|******|*****************************
                            |      |
                      +-----o-+  +-o-----+
          RAAs        |  IAM  |  |  RAA  o------.
                      +---o---+  +---o---+      '
                          |          |          |
          ****************|**********|**********|****************
                          |          |          |
                      +---o---+  +---o---+  +---o---+
          HDAs        |  MAA  |  | SIDA  |  |  HDA  |
                      +-------+  +-------+  +-------+

                     Figure 1: DIME Roles and Hierarchy

4.1.  Apex

   The Apex is a special DIME role that holds the value of RAA=0 and
   HDA=0.  It serves as the branch point from the larger DNS system in
   which DETs are defined.  The Apex generally has as the prefix portion
   of the HHIT associated with it (such as 2001:30/28) which is assigned
   by IANA from the non-routable special IPv6 address space for ORCHIDs.

   The Apex manages all delegations and allocations of the DET's RAA to
   various parties.  For DRIP and the UAS use case it is hoped that ICAO
   will handle the role of registering RAAs as an Apex.

4.2.  Registered Assigning Authority (RAA)

   RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field
   (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 two reserved HDA values. 0 (0x0000)
   for itself in its role as an RAA and 1 (0x0001) if it wishes to offer
   HDA services.  Other HDA values can be allocated or reserved per RAA
   policy.

Wiethuechter & Reid     Expires 29 September 2023               [Page 7]
Internet-Draft             DETIM Architecture                 March 2023

      Note: A single RAA may control more than one NAS (for example LU
      and BE being covered by Skeyes.be).  In such a scenario the CAA
      could either request two different RAA values for each larger
      region with HDAs delegating smaller spaces; or run under a single
      RAA with HDAs delegated to cover specific regions.  A similar
      scenario could also occur in the US with the FAA requesting RAAs
      for each region, for example: North East, South Eat, Midwest,
      North West, South West.  This is up to regulators and their
      policies.

4.2.1.  ICAO Authority of Manufacturers (IAM)

   An RAA-level DIME that hands out HDA values to participating
   Manufacturer's that hold an ICAO Manufacturer Code used in
   [CTA2063A].

   To manage the large ICAO Manufacturer Code space (34 character set; 4
   characters; 1,336,336 possible codes) a range of RAA values are set
   aside for the DRIP use case.  These are the RAA values of 2 (0x0002)
   up to 96 (0x0060).  This allows a single HDA for each Manufacturer
   Code.

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 UAS entities that need DETs.  This
   includes, but is not limited to UA, GCS, and Operators.  It should
   also provide needed UAS services including those required for HIP-
   enabled devices (e.g.  RVS).

   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.

   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.  Manufacturers Authority of Aircraft (MAA)

   An HDA-level DIME run by a manufacturer of UAS systems that
   participate in Remote ID.  Stores UAS Serial Numbers under a specific
   ICAO Manufacturer Code (assigned to the manufacturer by ICAO).

Wiethuechter & Reid     Expires 29 September 2023               [Page 8]
Internet-Draft             DETIM Architecture                 March 2023

   A DET can be encoded into a Serial Number (see [RFC9374],
   Section 4.2) and this DIME would hold a mapping from the Serial
   Number to the DET and its artifacts.

4.3.2.  Session ID Authority (SIDA)

   An HDA-level DIME that holds 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.
   The Serial Number SHOULD be encrypted in a way only the authorized
   party can decrypt.

   As part of the UTM system they 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.

4.4.  Role Abbreviation in DETs

   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 in length.  Spaces SHOULD NOT be used and be replaced
   with either underscores (_) or dashes (-).  For RAAs the abbreviation
   is RECOMMENDED to be set to the ISO 3166 country code (either Alpha-2
   or Alpha-3) when allocated to a CAA.

   If a DIME does not have an abbreviation or it can not be looked up
   then the receiver SHOULD use the uppercase 4-character hexadecimal
   encoding of the field it is missing.

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

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:

Wiethuechter & Reid     Expires 29 September 2023               [Page 9]
Internet-Draft             DETIM Architecture                 March 2023

   *  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

     +--------------------+
     | Registering Client |
     +---------o----------+
               |
     **********|******************************************************
     *         |        DRIP Identity Management Entity              *
     *         |                                                     *
     *  +------o-------+      +-------------+      +--------------+  *
     *  | DRIP         |      |             |      |              |  *
     *  | Provisioning o------o             |      |              |  *
     *  | Agent        |      |             |      |              |  *
     *  +-------o------+      |             |      |              |  *
     *          |             |             |      |              |  *
     *          |             | DRIP        |      | Registration |  *
     *  +-------o--+          | Information o------o Data         |  *
     *  | Registry o----------o Agent       |      | Directory    |  *
     *  +-------o--+          |             |      | Service      |  *
     *          |             |             |      |              |  *
     *          |             |             |      |              |  *
     *  +-------o-----+       |             |      |              |  *
     *  | Name Server |       |             |      |              |  *
     *  +------o------+       +-----o-------+      +------o-------+  *
     *         |                    |                     |          *
     *         |                    |                     |          *
     **********|********************|*********************|***********
               |                    |                     |
               |            +-------o-------+             |
               '------------o Lookup Client o-------------'
                            +---------------+

                     Figure 2: DIME Logical Components

Wiethuechter & Reid     Expires 29 September 2023              [Page 10]
Internet-Draft             DETIM Architecture                 March 2023

5.1.  DRIP Provisioning Agent (DPA)

   The DPA performs the important task of vetting information (such as
   the DRIP Endorsements) coming from clients wishing to register and
   then delegate (internally or externally) various items to other
   components in the DIME.

   A standard interface over HTTPS MUST be provided for clients to
   access with JSON or CBOR encoding of objects being sent to the DPA.
   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.

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.

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
      as RAA.

Wiethuechter & Reid     Expires 29 September 2023              [Page 11]
Internet-Draft             DETIM Architecture                 March 2023

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.  As an example the Serial Number, under the FAA, is
   classified as PII and can only be accessed by federal entities (such
   as the FAA themselves).

   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.

   A standard interface over HTTPS MUST be provided for clients to
   access with JSON/CBOR encoding of objects being sent to the DIA.
   There MUST also 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.

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.

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 records

   4.  Populate RDDS via DIA with PII and other info

   5.  Generate and return DRIP Endorsement(s)

Wiethuechter & Reid     Expires 29 September 2023              [Page 12]
Internet-Draft             DETIM Architecture                 March 2023

   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.

6.1.  Serial Number

   There are four ways a Serial Number is supported (by DRIP):

   1.  As itself as a clear-text string with additional information

   2.  As itself as a clear-text string mapped to a DET "post"
       generation by the manufacturer (for use in authentication) and
       additional information

   3.  As itself as a clear-text string mapped to a DET "post"
       generation by the user (for use in authentication) and additional
       information

   4.  As an encoding of an HI and associated DET by the manufacturer
       (for use in authentication) with additional information

      Note: additional information here refers to any subset of keys
      defined in Section 11.1.1.

   (1) is where a UA is provisioned with a Serial Number by the
   manufacturer.  The manufacturer is runs an MAA and uses the
   mechanisms of this document to provide additional information.

   (2) 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.  This
   document RECOMMENDS the manufacturer use an MAA for this task.

   (3) is where a UAS has a Serial Number (from the manufacturer) and
   the user 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.

   (4) 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 RECOMMENDED that the manufacturer "locks" the device
   from changing its authentication method so identifiers in both the
   Basic ID and Authentication Message do not de-sync.  The manufacturer

Wiethuechter & Reid     Expires 29 September 2023              [Page 13]
Internet-Draft             DETIM Architecture                 March 2023

   MUST use an MAA for this task, with the mapping between their
   Manufacturer Code and the upper portion of the DET publicly
   available.

                     +-------------------+
                     | 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) HIP RR,
                     CERT RRs
                 (d) UA Information

      Figure 3: Example DIME:MAA with Serial Number (DET) Registration

   The unmanned aircraft, intending to use DRIP, generates a keypair,
   DET and Self-Endorsement: UA using the RAA and HDA values specified
   by the manufacturers DIME (running as an MAA).  The DET is converted
   into a Serial Number (per [RFC9374]) or the manufacturer creates
   their own Serial Number.

   The Serial Number, UA information and the Self-Endorsement: UA are
   sent to the manufacturers DIME.  The DIME validates the Self-
   Endorsement and checks for DET and HI collisions in the Name Server/
   DIA.  A Broadcast Endorsement: DIME on UA is generated which is

Wiethuechter & Reid     Expires 29 September 2023              [Page 14]
Internet-Draft             DETIM Architecture                 March 2023

   provisioned into the aircraft for use when using the Serial Number as
   its UAS ID.  In the Name Server HIP RRs are created using the DET
   FQDN while a CNAME points the Serial Number FQDN to the DET FQDN.

      Note: Figure 3 is specific for a DET-encoded or DET-linked Serial
      Number.  The Endorsements in (a) and (b) as well as RRs in (c)
      would not be present for non-DET based Serial Numbers.

   Additional UA Information has a set of valid item keys defined in
   Section 11.1.1.  The items present for a given interaction is defined
   by future documents, local regulations and implementation specific
   capabilities.

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 29 September 2023              [Page 15]
Internet-Draft             DETIM Architecture                 March 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,
                     CERT RRs
                 (d) Operator Information

        Figure 4: Example DIME:HDA with Operator (DET) Registration

   The Operator generates a keypair and DET as specified in [RFC9374]
   along with a self-signed endorsement (Self-Endorsement: Operator).
   The RAA and HDA values used in the DET generation for the Operator
   are found by referencing their selected DIME of choice (in Figure 4
   an HDA).

   The self-signed endorsement along with other relevant information
   (such as Operator PII) is sent to the DIME over a secure channel.
   The specification of this secure channel is out of scope for this
   document.

   The DIME cross checks any personally identifiable information as
   required.  Self-Endorsement: Operator is verified.  The DET and HI is
   searched in the DIME DIA and Name Server to confirm that no
   collisions occur.  A new endorsement is generated (Generic

Wiethuechter & Reid     Expires 29 September 2023              [Page 16]
Internet-Draft             DETIM Architecture                 March 2023

   Endorsement: DIME on Operator) and sent securely back to the
   Operator.  Resource Records for the HI and Endorsements are added to
   the DIME Registry/Name Server.

   With the receipt of Generic Endorsement: DIME on Operator the
   registration of the Operator is complete.

      Note: (c) in Figure 4 MAY be requested by the Operator to be
      omitted due to PII concerns.

   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, specifically SIDAs.  In
   Figure 5 the UAS comprises of an unmanned aircraft and a Ground
   Control Station (GCS).  Both parties are involved in the registration
   process.

Wiethuechter & Reid     Expires 29 September 2023              [Page 17]
Internet-Draft             DETIM Architecture                 March 2023

                     +---------+
                     |   UAS   |
                     +--o---o--+
                        |   ^
                    (a) |   | (b)
                        |   |
                 *******|***|*****************************
                 *      |   |    DIME: SIDA              *
                 *      |   |                            *
                 *      v   |             +----------+   *
                 *   +--o---o--+          |          |   *
                 *   |   DPA   o--------->o          |   *
                 *   +----o----+   (d)    |          |   *
                 *        |               |          |   *
                 *        | (c)           | DIA/RDDS |   *
                 *        v               |          |   *
                 *   +----o--------+      |          |   *
                 *   | Registry/NS |      |          |   *
                 *   +-------------+      |          |   *
                 *                        +----------+   *
                 *                                       *
                 *****************************************

                 (a) Mutual Endorsement: SIDA on GCS,
                     Generic Endorsement: GCS on UA,
                     Session ID Information
                 (b) Success Code,
                     Broadcast Endorsement: SIDA on UA,
                     Generic Endorsement: SIDA on UAS
                 (c) HIP RR,
                     TLSA, RR,
                     CERT RRs
                 (d) Session ID Information

       Figure 5: Example DIME:SIDA 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:
   SIDA on GCS.  The GCS creates a new Generic Endorsement: GCS on UA
   and also creates Mutual Endorsement: SIDA on GCS.  These new
   endorsements along with Session ID Information are sent to the DIME
   via a secure channel.

Wiethuechter & Reid     Expires 29 September 2023              [Page 18]
Internet-Draft             DETIM Architecture                 March 2023

   The DIME validates all the endorsements and checks for DET and HI
   collisions in the Name Server/DIA using the proposed UA DET.  A
   Broadcast Endorsement: DIME on UA is generated.  An Generic
   Endorsement: SIDA on UAS is generated using the Generic Endorsement:
   GCS on UA.  HIP and CERT RRs are provisioned into the Registry/Name
   server.  Both endorsements are back to the GCS on a secure channel.

   The GCS then injects the Broadcast Endorsement: SIDA on UA securely
   into the unmanned aircraft.  Endorsement: SIDA on GCS is securely
   stored by the GCS.

      Note: in Figure 5 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,
       * 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

   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

   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

Wiethuechter & Reid     Expires 29 September 2023              [Page 19]
Internet-Draft             DETIM Architecture                 March 2023

   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
   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,
                     CERT RRs
                 (d) HDA Information

Wiethuechter & Reid     Expires 29 September 2023              [Page 20]
Internet-Draft             DETIM Architecture                 March 2023

           Figure 6: Example DIME:RAA with DIME:HDA Registration

   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 [drip-arch] 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. [drip-arch] 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).

Wiethuechter & Reid     Expires 29 September 2023              [Page 21]
Internet-Draft             DETIM Architecture                 March 2023

   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.

   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 [drip-arch] 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.

   ICAO SHOULD delegate domains beneath these apexes to national civil
   aviation authorities.  This ensures DRIP complies with national law
   and regulation since these are matters of national sovereignty.  The
   HHIT has a designated field, the RAA, for this exact purpose and
   SHOULD be used instead of a ISO-3166 entries: ie a two- or three-
   letter or a three digit country code.

   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

Wiethuechter & Reid     Expires 29 September 2023              [Page 22]
Internet-Draft             DETIM Architecture                 March 2023

   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 reguations 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 (both DIME-level and national-level).

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 ICAO.  In addition to the DNS
   infrastructure for 3.0.0.1.0.0.2.ip6.arpa, ICAO 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 on a
   country by country basis, using the 14-bit RAA space as a framework.
   ICAO SHOULD allocate blocks to each National Aviation Authority 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 HHIT
   resource record 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 an HHIT RRtype and not a PTR RRtype.

      Info: HHIT RRType is a new DNS RRType that would be proposed by
      the DRIP WG to fulfill desired attributes of DRIP.

Wiethuechter & Reid     Expires 29 September 2023              [Page 23]
Internet-Draft             DETIM Architecture                 March 2023

8.2.  Serial Numbers & Other UAS ID Types

   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 7) 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 29 September 2023              [Page 24]
Internet-Draft             DETIM Architecture                 March 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 7: 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 29 September 2023              [Page 25]
Internet-Draft             DETIM Architecture                 March 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 covered in this document will also have certificates to
   create and manage the necessary PKI structure.

   Any Certificate Authority (CA) supporting DRIP entities SHOULD adhere
   to the ICAO's International Aviation Trust Framework (IATF)
   Certificate Policy [ICAO-IATF-CP-draft].  The CA(s) supporting this
   CP MUST either be a part of the IATF Bridge PKI or part of the IATF
   CA Trust List.

   EEs may use their X.509 certificates, rather than their rawPublicKey
   (i.e.  HI) in authentication protocols (as not all may support
   rawPublicKey identities).  Some EE HI may not be 'worth' supporting
   the overhead of X.509.  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
   not AfterDate will 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.

Wiethuechter & Reid     Expires 29 September 2023              [Page 26]
Internet-Draft             DETIM Architecture                 March 2023

   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.  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 MUST be available via RDAP.  LDAP/OCSP access for other
   UTM and ICAO uses SHOULD also be provided.

10.2.  Certificate Management

   (mostly TBD still)

   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.

   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.

   Details of this are left out, as there are a number of approaches and
   further research and experience will be needed.

10.3.  Examples

   TBD

10.4.  Alternative Certificate Encoding

   (CBOR encoded certs here.  TBD)

11.  IANA Considerations

11.1.  IANA DRIP Registry

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

Wiethuechter & Reid     Expires 29 September 2023              [Page 27]
Internet-Draft             DETIM Architecture                 March 2023

   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     |
         +----------------------+-------+------------------------+
         | propLength           | float | Length of props, in    |
         |                      |       | centimeters            |
         +----------------------+-------+------------------------+
         | numBatteries         | int   |                        |
         +----------------------+-------+------------------------+
         | batteryCapacity      | float | in milliampere hours   |
         +----------------------+-------+------------------------+
         | batteryWeight        | float | in kilograms           |
         +----------------------+-------+------------------------+
         | batteryVoltage       | float | in volts               |
         +----------------------+-------+------------------------+
         | batteryChemistry     | tstr  |                        |
         +----------------------+-------+------------------------+

Wiethuechter & Reid     Expires 29 September 2023              [Page 28]
Internet-Draft             DETIM Architecture                 March 2023

         | 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 1

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.  At
   time of writing this is signing over the new key with the previous
   key in a secure fashion and it being validated by others before
   changing any links in DNS.

   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 of the DET to have different identities could also
   allow for a single DIME to be "federated" across them if they share
   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.

Wiethuechter & Reid     Expires 29 September 2023              [Page 29]
Internet-Draft             DETIM Architecture                 March 2023

12.2.  DET Generation

   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.

   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

   [drip-arch]
              Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
              and A. Gurtov, "Drone Remote Identification Protocol
              (DRIP) Architecture", Work in Progress, Internet-Draft,
              draft-ietf-drip-arch-31, 6 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
              arch-31>.

Wiethuechter & Reid     Expires 29 September 2023              [Page 30]
Internet-Draft             DETIM Architecture                 March 2023

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [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,
              <https://www.rfc-editor.org/info/rfc9153>.

   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

14.2.  Informative References

   [CTA2063A] "ANSI/CTA 2063-A Small Unmanned Aerial Systems Numbers",
              September 2019, <https://shop.cta.tech/products/small-
              unmanned-aerial-systems-serial-numbers>.

   [dane-clients]
              Huque, S., Dukhovni, V., and A. Wilson, "TLS Client
              Authentication via DANE TLSA records", Work in Progress,
              Internet-Draft, draft-ietf-dance-client-auth-01, 8
              November 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dance-client-auth-01>.

   [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-30, 27 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
              auth-30>.

Wiethuechter & Reid     Expires 29 September 2023              [Page 31]
Internet-Draft             DETIM Architecture                 March 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,
              <https://datatracker.ietf.org/doc/html/draft-moskowitz-
              drip-secure-nrid-c2-12>.

   [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,
              <https://www.rfc-editor.org/info/rfc1886>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

   [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, <https://www.rfc-editor.org/info/rfc6698>.

   [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,
              <https://www.rfc-editor.org/info/rfc6841>.

   [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,
              <https://www.rfc-editor.org/info/rfc7480>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [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,
              <https://www.rfc-editor.org/info/rfc9083>.

Wiethuechter & Reid     Expires 29 September 2023              [Page 32]
Internet-Draft             DETIM Architecture                 March 2023

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: .det.uas.icao.arpa.
   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.det.uas.icao.arpa.

A.2.  UAS Serial Number

      {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.  Self Endorsement

Wiethuechter & Reid     Expires 29 September 2023              [Page 33]
Internet-Draft             DETIM Architecture                 March 2023

                      self_endorsement = {
                          scope: {
                              vnb: number,
                              vna: number
                          },
                          evidence: bstr,
                          endorser: {
                              identity: {
                                  hhit: bstr .size 16
                              },
                              signature: {
                                  sig: bstr
                              }
                          }
                      }

                      Figure 8: Self Endorsement CDDL

   Used during registration process as an input. evidence is filled with
   the corresponding HI of the hhit.

Wiethuechter & Reid     Expires 29 September 2023              [Page 34]
Internet-Draft             DETIM Architecture                 March 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 9: Self Endorsement Binary

                                   TODO

                      Figure 10: Self Endorsement CBOR

B.2.  Generic Endorsement

Wiethuechter & Reid     Expires 29 September 2023              [Page 35]
Internet-Draft             DETIM Architecture                 March 2023

                      generic_endorsement = {
                          scope: {
                              vnb: number,
                              vna: number
                          },
                          evidence: bstr,
                          endorser: {
                              identity: {
                                  hhit: bstr .size 16
                              },
                              signature: {
                                  sig: bstr
                              }
                          }
                      }

                    Figure 11: Generic Endorsement CDDL

   Defined by [drip-auth] in a binary format to support Authentication
   over F3411 constrained links.  Used in DRIP Wrapper, Manifest and
   Frame formats. evidence is a binary string with specified contents
   (in format and ordering) by specific use-cases.

B.3.  Broadcast Endorsement

                      broadcast_endorsement = {
                          scope: {
                              vnb: number,
                              vna: number
                          },
                          evidence: bstr,
                          endorser: {
                              identity: {
                                  hhit: bstr .size 16
                              },
                              signature: {
                                  sig: bstr
                              }
                          }
                      }

                   Figure 12: Broadcast Endorsement CDDL

   Defined by [drip-auth] in a binary format to support Authentication
   over F3411 constrained links.  Used in 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 29 September 2023              [Page 36]
Internet-Draft             DETIM Architecture                 March 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 13: Broadcast Endorsement Binary

                                   TODO

Wiethuechter & Reid     Expires 29 September 2023              [Page 37]
Internet-Draft             DETIM Architecture                 March 2023

                      Figure 14: Self Endorsement CBOR

Authors' Addresses

   Adam Wiethuechter
   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 29 September 2023              [Page 38]