drip Working Group                                  A. Wiethuechter, Ed.
Internet-Draft                                        AX Enterprize, LLC
Intended status: Standards Track                                 J. Reid
Expires: 15 June 2025                                           RTFM llp
                                                        12 December 2024


         DRIP Entity Tags (DET) in the Domain Name System (DNS)
                     draft-ietf-drip-registries-21

Abstract

   This document describes the discovery and management of DRIP Entity
   Tags (DETs) in DNS.  Authoritative Name Servers, with DRIP specific
   DNS structures and standard DNS methods, are the Public Information
   Registries for DETs and their related metadata.

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 15 June 2025.

Copyright Notice

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

   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.




Wiethuechter & Reid       Expires 15 June 2025                  [Page 1]

Internet-Draft                 DET in DNS                  December 2024


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  General Concept . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Use of Existing DNS Models  . . . . . . . . . . . . . . .   3
     1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Required Terminology  . . . . . . . . . . . . . . . . . .   4
     2.2.  Additional Definitions  . . . . . . . . . . . . . . . . .   4
   3.  DET Hierarchy in DNS  . . . . . . . . . . . . . . . . . . . .   5
   4.  Public Information Registry . . . . . . . . . . . . . . . . .   6
   5.  Resource Records  . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  HHIT Resource Record  . . . . . . . . . . . . . . . . . .   7
       5.1.1.  Text Representation . . . . . . . . . . . . . . . . .   7
       5.1.2.  Field Descriptions  . . . . . . . . . . . . . . . . .   7
     5.2.  UAS Broadcast RID Resource Record . . . . . . . . . . . .   8
       5.2.1.  Text Representation . . . . . . . . . . . . . . . . .   9
       5.2.2.  Field Descriptions  . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  DRIP Prefix Delegation  . . . . . . . . . . . . . . . . .  11
     6.2.  IANA DRIP Registry  . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  DRIP RAA Allocations  . . . . . . . . . . . . . . . .  11
       6.2.2.  HHIT Entity Type  . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.1.  DNS Operational Considerations  . . . . . . . . . . . . .  13
     7.2.  Public Key Exposure . . . . . . . . . . . . . . . . . . .  14
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Registries are fundamental to Unmanned Aircraft System (UAS) Remote
   Identification (RID).  Only very limited operational information can
   be sent via Broadcast RID, but extended information is sometimes
   needed.  The most essential element of information from RID is the
   UAS ID, the unique key for lookup of extended information in relevant
   registries (see Figure 4 of [RFC9434]).

   When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID,
   extended information can be retrieved from a DRIP Identity Management
   Entity (DIME) which manages registration of and associated lookups
   from DETs.  In this document we assume the DIME is a function of UAS
   Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be
   independent or handled by another entity as well.




Wiethuechter & Reid       Expires 15 June 2025                  [Page 2]

Internet-Draft                 DET in DNS                  December 2024


1.1.  General Concept

   DRIP Entity Tags (DETs) embedded a hierarchy scheme which is mapped
   onto the Domain Name System (DNS).  DIME's enforce registration and
   information access of data associated with a DET while also providing
   the trust inherited from being a member of the hierarchy.  Other
   identifiers and their methods are out of scope for this document.

   Authoritative Name Servers of the Domain Name System (DNS) provide
   the Public Information such as the cryptographic keys, endorsements
   and certificates of DETs and pointers to Private Information
   resources.  Cryptographic (public) keys are used to authenticate
   anything signed by a DET, such as in the Authentication defined
   [RFC9575] for Broadcast RID.  Endorsements and certificates are used
   to endorse the claim of being part of the hierarchy.

   Aspects of Private Information Registries to store and protect,
   through AAA mechanisms, Personally Identifiable Information (PII) are
   not described in this document.

1.2.  Use of Existing DNS Models

   DRIP relies on the DNS and as such roughly follows the registrant-
   registrar-registry model.  In DRIP, the registrant would be the end
   user who owns/controls the Unmanned Aircraft.  They are ultimately
   responsible for the DET and any other information that gets published
   in the DNS.  Registrants use agents known as registrars to manage
   their interactions with the registry.  Registrars typically provide
   optional additional services such as DNS hosting.

   The registry maintains a database of the registered domain names and
   their related metadata such as the contact details for domain name
   holder and the relevant registrar.  The registry provides DNS service
   for the zone apex which contains delegation information for domain
   names.  Registries generally provide services such as WHOIS or RDAP
   to publish metadata about the registered domain names and their
   registrants and registrars.

   Registrants have contracts with registrars who in turn have contracts
   with registries.  Payments follow this model too: the registrant buys
   services from a registrar who pays for services provided by the
   registry.









Wiethuechter & Reid       Expires 15 June 2025                  [Page 3]

Internet-Draft                 DET in DNS                  December 2024


   By definition, there can only be one registry for a domain name.
   Since that registry is a de facto monopoly, the scope of its
   activities are usually kept to a minimum to reduce the potential for
   market distortions or anti-competitive practices.  A registry can
   have an arbitrary number of registrars who compete with each other on
   price, service and customer support.

   It is not necessary, and in some case may not be desirable, for DRIP
   registrations to strictly follow this registrant-registrar-registry
   model.  Prevailing circumstances and/or local policy may mean some
   combination of these roles could be combined.  A DRIP registry might
   be operated by the CAA.  Or it could be outsourced to a DNS registry
   provider.  Registration policies - pricing, renewals, registrar and
   registrant agreements, etc. - will need to be developed.  These
   considerations should be determined by the CAA, perhaps in
   consultation with local stakeholders.  They are are out of scope for
   this document.

   The specifics for the UAS RID use case are detailed in the rest of
   document.

1.3.  Scope

   The scope of this document is limited to the 2001:30::/28 IPv6 prefix
   and its associated reverse domain in DNS.  The use case of DETs for
   UAS RID was the primary driver for the technology (and this
   document), as such requirements of other sectors or use cases are
   unknown at the time of publication.

   Other sectors may adopt this technology.  It is recommended that a
   global Apex (i.e.  IPv6 prefix) and international Apex manager be
   designated for each sector.

2.  Terminology

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

2.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 15 June 2025                  [Page 4]

Internet-Draft                 DET in DNS                  December 2024


3.  DET Hierarchy in DNS

   [RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and
   further specifies an instance of them used for UAS RID called DETs.
   The HHIT is a 128-bit value that is as an IPv6 address intended
   primarily as an identifier rather than locator.  It's format is in
   Figure 1, shown here for reference, and further information is in
   [RFC9374].

    +-------------+--------------+---------------+-------------+
    | IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
    | (28-bits)   | (28-bits)    | (8-bits)      | (64-bits)   |
    +-------------+--------------+---------------+-------------+
                 /                \
                /                  \
               /                    \-----------------------------\
              /                                                    \
             /                                                      \
            +--------------------------------+-----------------------+
            | Registered Assigning Authority | HHIT Domain Authority |
            | (14-bits)                      | (14-bits)             |
            +--------------------------------+-----------------------+

                    Figure 1: DRIP Entity Tag Breakdown

   The IPv6 Prefix, assigned by IANA for DETs is 2001:30::/28.  The
   corresponding domain (nibble reversed as 3.0.0.1.0.0.2.ip6.arpa) is
   owned by the IAB.

   Due to the nature of the hierarchy split and its relationship to
   nibble reversing of the IPv6 address, the upper level of hierarchy
   (i.e.  RAAs) "borrows" the upper two bits of their respective HDA
   space for DNS delegation.  As such the IPv6 prefix of RAAs are
   2001:3x:xxx::/44 and HDAs are 2001:3x:xxxy:yy::/56 with respective
   nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa and
   y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.

   A subset of RAAs have preallocations based on the ISO 3166-1 Numeric
   Nation Code [ISO3166-1].  This is to support the initial use case of
   DETs in UAS RID on an international level.  See Section 6.2.1 for the
   RAA allocations.

   The HDA values of 0, 4096, 8192 and 12288 are reserved for
   operational use of an RAA (a by-product of the above mentioned
   borrowing of bits), specifically when to register with the Apex and
   endorse delegations of HDAs in their namespace.





Wiethuechter & Reid       Expires 15 June 2025                  [Page 5]

Internet-Draft                 DET in DNS                  December 2024


   The administration, management and policy for operation a DIME at any
   level in the hierarchy (Apex, RAA or HDA), be it external or from a
   parent level, is out of scope for this document.  In some cases, such
   as the RAAs and HDAs of a nation, these are National Matters which
   are to be dealt with by those parties accordingly.

4.  Public Information Registry

   Per [RFC9434] all information classified, by all parties involved, as
   public is stored in the DNS, specifically Authoritative Name Servers,
   to satisfy REG-1 from [RFC9153].

   Authoritative Name Servers use domain names as handles and data is
   stored in Resource Records (RR) with associated RRTypes.  This
   document defines two new RRTypes, one for HHIT metadata (HHIT,
   Section 5.1) and another for UAS Broadcast RID information (BRID,
   Section 5.2).  The former RRType is particularly important as it
   contains a URI (as part of the certificate) that point to Private
   Information resources.

   DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed
   per convention) with at minimum an HHIT RRType.  Depending on local
   circumstances or additional use cases other RRTypes MAY be present.
   For UAS RID the BRID RRType MUST be present to provide the Broadcast
   Endorsements defined in [RFC9575].

   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.

   UAS specific information, such as physical characteristics, MAY also
   be stored in DNS but is out of scope for this document.  This
   specification information is currently drafted in [uas-sn-dns].

   Lookups of the above RRTypes are performed with the standard DNS
   methodology using the nibble reversed DET as the query name affixed
   to the ip6.arpa domain apex and asking for the specific RRType.  The
   HHIT RRType provides the public key for signature verification and
   URIs via the certificate.  The BRID RRType provides static Broadcast
   RID information such as the Broadcast Endorsements sent following
   [RFC9575].

5.  Resource Records






Wiethuechter & Reid       Expires 15 June 2025                  [Page 6]

Internet-Draft                 DET in DNS                  December 2024


5.1.  HHIT Resource Record

   The HHIT Resource Record is a metadata record for various bits of
   HHIT specific information that isn't available in the pre-existing
   HIP RRType.  It does not replace the HIP RRType.  The primary
   advantage of this RRType over the existing RRType is the inclusion a
   certificate containing an entity's public key signed by the
   registrar, or other trust anchor, to confirm registration.

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        HHIT Data Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                   HHIT Data (CBOR Encoded)                    .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2: HHIT Wire Format

   The HHIT Data Length is 32-bit integer representing the number of
   bytes contained in the HHIT Data field.  The HHIT Data field MUST be
   encoded in CBOR bytes.  The CDDL of the HHIT Data is provided in
   Figure 3.

5.1.1.  Text Representation

   The HHIT Data is represented in base64 and may be divided into any
   number of white-space-separated substrings, down to single base64
   digits, which are concatenated to obtain the full object.  These
   substrings can span lines using the standard parenthesis.  Note that
   the HHIT Data portion has internal subfields, but these do not appear
   in the master file representation only a single logical base64 string
   will appear.  The HHIT Data Length is not represented as it is
   implicitly known by the HHIT Data.

5.1.1.1.  Presentation Representation

   The HHIT Data portion MAY, for display purposes only, be represented
   using the Extended Diagnostic Notation as defined in Appendix G of
   [RFC8610].

5.1.2.  Field Descriptions





Wiethuechter & Reid       Expires 15 June 2025                  [Page 7]

Internet-Draft                 DET in DNS                  December 2024


   hhit-rr = [
       type: uint .size(2),
       abbreviation: tstr .size(15),
       registration-cert: bstr / #6.TBD
   ]

                      Figure 3: HHIT Wire Format CDDL

   HHIT Entity Type:  This field is two octets with values defined in
      Section 6.2.2.  It is envisioned that there may be many types of
      HHITs in use.  In some cases it may be helpful to understand the
      HHITs role in the ecosystem like described in [drip-dki].  This
      field provides such context.

   HID Abbreviation:  This field is meant to provide an abbreviation to
      the HID structure for display devices.  The specific contents of
      this field are not defined here.

   Canonical Registration Certificate:  This field is reserved for any
      certificate to endorse registration that contains the DET.  It
      MUST be encoded as X.509 DER or C.509 [cbor-x509].  This
      certificate MAY be self-signed when the entity is acting as a root
      of trust (i.e. an apex).  Such self-signed behavior is defined by
      policy, such as in [drip-dki], and is out of scope for this
      document.

5.2.  UAS Broadcast RID Resource Record

   The UAS Broadcast RID Resource Record type (BRID) is a format to hold
   public information typically sent of the UAS Broadcast RID that is
   static.  It can act as a data source if information is not received
   over Broadcast RID or for cross validation.  The primary function for
   DRIP is the inclusion of one or more Broadcast Endorsements as
   defined in [RFC9575] in the auth field.  These Endorsements are
   generated by the registrar upon successful registration and broadcast
   by the entity.

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        BRID Data Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                   BRID Data (CBOR Encoded)                    .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Wiethuechter & Reid       Expires 15 June 2025                  [Page 8]

Internet-Draft                 DET in DNS                  December 2024


                         Figure 4: BRID Wire Format

   The BRID Data Length is 32-bit integer representing the number of
   bytes contained in the BRID Data field.  The BRID Data field MUST be
   encoded in CBOR bytes.  The CDDL of the BRID Data is provided in
   Figure 5.

5.2.1.  Text Representation

   The BRID Data is represented in base64 and may be divided into any
   number of white-space-separated substrings, down to single base64
   digits, which are concatenated to obtain the full object.  These
   substrings can span lines using the standard parenthesis.  Note that
   the BRID Data portion has internal subfields, but these do not appear
   in the master file representation only a single logical base64 string
   will appear.  The BRID Data Length is not represented as it is
   implicitly known by the BRID Data.

5.2.1.1.  Presentation Representation

   The BRID Data portion MAY, for display purposes only, be represented
   using the Extended Diagnostic Notation as defined in Appendix G of
   [RFC8610].  All byte strings longer than a length of 20 SHOULD be
   displayed as base64 when possible.

5.2.2.  Field Descriptions

























Wiethuechter & Reid       Expires 15 June 2025                  [Page 9]

Internet-Draft                 DET in DNS                  December 2024


bcast-rr = {
    uas_type: nibble-field,
    uas_ids: [+ uas-id-grp],
    ? auth: [+ auth-grp],
    ? self-grp,
    ? op_type: 0..3,
    ? area-grp,
    ? classification-grp,
    ? operator-grp
}
uas-id-grp = (
    id_type: &uas-id-types,
    uas_id: bstr .size(20)
)
uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4)
auth-grp = (
    a_type: nibble-field,
    a_data: bstr .size(1..362)
)
area-grp = (
    area_count: 1..255,
    area_radius: float,
    area_floor: float,
    area_ceiling: float
)
classification-grp = (
    ua_class: 0..8,
    eu_class: nibble-field,
    eu_category: nibble-field
)
self-grp = (
    desc_type: nibble-field,
    description: tstr .size(23)
)
operator-grp = (
    operator_id_type: nibble-field,
    operator_id: bstr .size(20)
)
nibble-field = 0..15

                   Figure 5: BRID Wire Format CDDL

   The field names and their general typing are borrowed from the ASTM
   [F3411] data dictionary.  See that document for additional
   information on fields semantics and units.

6.  IANA Considerations




Wiethuechter & Reid       Expires 15 June 2025                 [Page 10]

Internet-Draft                 DET in DNS                  December 2024


6.1.  DRIP Prefix Delegation

   This document requests that the IANA delegate the
   3.0.0.1.0.0.2.ip6.arpa domain.  IANA will be responsible for
   processing requests under the guidance of the Designated Expert.

6.2.  IANA DRIP Registry

6.2.1.  DRIP RAA Allocations

   This document requests a new registry for RAA Allocations under the
   DRIP registry group (https://www.iana.org/assignments/drip/
   drip.xhtml) to be managed by IANA.

   RAA Allocations:  a 14-bit value used to represent RAAs.  Future
      additions to this registry are to be made through Expert Review
      (Section 4.5 of [RFC8126]).  The following values/ranges are
      defined:

     +===============+===========+======================+===========+
     | RAA Value(s)  | Status    | Allocation           | Reference |
     +===============+===========+======================+===========+
     | 0 - 3         | Reserved  | N/A                  | N/A       |
     +---------------+-----------+----------------------+-----------+
     | 4 - 3999      | Allocated | ISO 3166-1 Countries | This RFC  |
     +---------------+-----------+----------------------+-----------+
     | 4000 - 16375  | Reserved  | N/A                  | N/A       |
     +---------------+-----------+----------------------+-----------+
     | 16376 - 16383 | Allocated | DRIP WG              | This RFC  |
     |               |           | (Experimental Use)   |           |
     +---------------+-----------+----------------------+-----------+

                                 Table 1

   To support DNS delegation in ip6.arpa a single RAA is given 4
   delegations by borrowing the upper two bits of HDA space.  This
   enables a clean nibble boundary in DNS to delegate from (i.e. the
   prefix 2001:3x:xxx0::/44).  These HDAs (0, 4096, 8192 and 12288) are
   reserved for the RAA.

   The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found
   as a CSV file on GitHub (https://github.com/ietf-wg-drip/draft-ietf-
   drip-registries/blob/main/iso3166-raa.csv).  Each Nation is assigned
   four RAAs that are left to the national authority for their purpose.
   For RAAs under this range a shorter prefix of 2001:3x:xx00::/40 MAY
   be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs)
   assigned to them.




Wiethuechter & Reid       Expires 15 June 2025                 [Page 11]

Internet-Draft                 DET in DNS                  December 2024


   Requests in the DRIP WG allocation block MUST be forwarded to the
   contact point in the DRIP WG to evaluate the request and MUST contain
   a desired/proposed length of time for the allocation.  Allocations in
   the block are not permanent and have a limited time the delegation is
   to be supported.  The length of the time proposed is evaluated on a
   case-by-case basis by the DRIP WG.

6.2.2.  HHIT Entity Type

   This document requests a new registry for HHIT Entity Type under the
   DRIP registry group (https://www.iana.org/assignments/drip/
   drip.xhtml).

   HHIT Entity Type:  numeric, 16-bit, field of the HHIT RRType to
      encode the HHIT Entity Type.  Future additions to this registry
      are to be made through Expert Review (Section 4.5 of [RFC8126]).
      The following values are defined:

    +=======+===========================================+============+
    | Value | Type                                      | Reference  |
    +=======+===========================================+============+
    | 0     | Not Defined                               | This RFC   |
    +-------+-------------------------------------------+------------+
    | 1     | DRIP Identity Management Entity (DIME)    | This RFC   |
    +-------+-------------------------------------------+------------+
    | 2     | DIME: Authentication CA                   | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 3     | DIME: Issuing CA                          | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 4     | Reserved                                  | This RFC   |
    +-------+-------------------------------------------+------------+
    | 5     | Apex                                      | This RFC   |
    +-------+-------------------------------------------+------------+
    | 6     | Apex: Authentication CA                   | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 7     | Apex: Issuing CA                          | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 8     | Reserved                                  | This RFC   |
    +-------+-------------------------------------------+------------+
    | 9     | Registered Assigning Authority (RAA)      | This RFC   |
    +-------+-------------------------------------------+------------+
    | 10    | RAA: Authentication CA                    | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 11    | RAA: Issuing CA                           | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 12    | Reserved                                  | This RFC   |
    +-------+-------------------------------------------+------------+
    | 13    | HHIT Domain Authority (HDA)               | This RFC   |



Wiethuechter & Reid       Expires 15 June 2025                 [Page 12]

Internet-Draft                 DET in DNS                  December 2024


    +-------+-------------------------------------------+------------+
    | 14    | HDA: Authentication CA                    | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 15    | HDA: Issuing CA                           | [drip-dki] |
    +-------+-------------------------------------------+------------+
    | 16    | Uncrewed Aircraft (UA)                    | This RFC   |
    +-------+-------------------------------------------+------------+
    | 17    | Ground Control Station (GCS)              | This RFC   |
    +-------+-------------------------------------------+------------+
    | 18    | Uncrewed Aircraft System (UAS)            | This RFC   |
    +-------+-------------------------------------------+------------+
    | 19    | Remote Identification (RID) Module        | This RFC   |
    +-------+-------------------------------------------+------------+
    | 20    | Pilot                                     | This RFC   |
    +-------+-------------------------------------------+------------+
    | 21    | Operator                                  | This RFC   |
    +-------+-------------------------------------------+------------+
    | 22    | Discovery & Synchronization Service (DSS) | This RFC   |
    +-------+-------------------------------------------+------------+
    | 23    | UAS Service Supplier (USS)                | This RFC   |
    +-------+-------------------------------------------+------------+
    | 24    | Network RID Service Provider (SP)         | This RFC   |
    +-------+-------------------------------------------+------------+
    | 25    | Network RID Display Provider (DP)         | This RFC   |
    +-------+-------------------------------------------+------------+
    | 26    | Supplemental Data Service Provider (SDSP) | This RFC   |
    +-------+-------------------------------------------+------------+
    | 27 -  | Reserved                                  | N/A        |
    | 65535 |                                           |            |
    +-------+-------------------------------------------+------------+

                                 Table 2

   Future additions to this registry MUST NOT be allowed if they can be
   covered under an existing registration.

7.  Security Considerations

7.1.  DNS Operational Considerations

   The Registrar and Registry are commonly used concepts in the DNS.
   These components interface the DIME into the DNS hierarchy and thus
   operation SHOULD follow best common practices, specifically in
   security (such as running DNSSEC) as appropriate.  The following RFC
   provide suitable guidance: [RFC7720], [RFC4033], [RFC4034],
   [RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007].





Wiethuechter & Reid       Expires 15 June 2025                 [Page 13]

Internet-Draft                 DET in DNS                  December 2024


   If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be
   developed and published.  It SHOULD explain how DNSSEC has been
   deployed and what security measures are in place.  [RFC6841]
   documents a Framework for DNSSEC Policies and DNSSEC Practice
   Statements.

   The interfaces and protocol specifications for registry-registrar
   interactions are intentionally not specified in this document.  These
   will depend on nationally defined policy and prevailing local
   circumstances.  It is expected registry-registrar activity will use
   the Extensible Provisioning Protocol (EPP) [RFC5730].  The registry
   SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP
   [RFC9082] to provide public information about registered domain
   names.

   Decisions about DNS or registry best practices and other operational
   matters SHOULD be made by the CAA, ideally in consultation with local
   stakeholders.  This document RECOMMENDS that DNSSEC SHOULD be used by
   both Apex (to control RAA levels) and RAA (to control HDA level)
   zones.

7.2.  Public Key Exposure

   DETs are built upon asymmetric keys.  As such the public key must be
   revealed to enable clients to perform signature verifications.
   [RFC9374] security considerations cover various attacks on such keys.

   While unlikely the forging of a corresponding private key is possible
   if given enough time (and computational power).  As such it is
   RECOMMENDED that the public key for any DET not be exposed in DNS
   (under any RRType) until it is required.

   Optimally this requires the UAS somehow signal the DIME that a flight
   using a Specific Session ID will soon be underway or complete.  It
   may also be facilitated under UTM if the USS (which may or may not be
   a DIME) signals when a given operation using a Session ID goes
   active.

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

9.  References

9.1.  Normative References



Wiethuechter & Reid       Expires 15 June 2025                 [Page 14]

Internet-Draft                 DET in DNS                  December 2024


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

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

   [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/rfc/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/rfc/rfc9374>.

   [RFC9434]  Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
              and A. Gurtov, "Drone Remote Identification Protocol
              (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
              2023, <https://www.rfc-editor.org/rfc/rfc9434>.

9.2.  Informative References

   [cbor-x509]
              Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
              Certificates)", Work in Progress, Internet-Draft, draft-
              ietf-cose-cbor-encoded-cert-11, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              cbor-encoded-cert-11>.

   [drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
              Infrastructure", Work in Progress, Internet-Draft, draft-
              moskowitz-drip-dki-09, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-moskowitz-
              drip-dki-09>.

   [F3411]    ASTM International, "Standard Specification for Remote ID
              and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
              2022, <https://www.astm.org/f3411-22a.html>.







Wiethuechter & Reid       Expires 15 June 2025                 [Page 15]

Internet-Draft                 DET in DNS                  December 2024


   [ISO3166-1]
              International Standards Organization (ISO), "Codes for the
              representation of names of countries and their
              subdivisions", ISO 3166-1:2020, August 2020,
              <https://www.iso.org/iso-3166-country-codes.html>.

   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              DOI 10.17487/RFC2182, July 1997,
              <https://www.rfc-editor.org/rfc/rfc2182>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <https://www.rfc-editor.org/rfc/rfc3007>.

   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              DOI 10.17487/RFC3912, September 2004,
              <https://www.rfc-editor.org/rfc/rfc3912>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4035>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <https://www.rfc-editor.org/rfc/rfc4786>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/rfc/rfc5155>.

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





Wiethuechter & Reid       Expires 15 June 2025                 [Page 16]

Internet-Draft                 DET in DNS                  December 2024


   [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/rfc/rfc6841>.

   [RFC7720]  Blanchet, M. and L. Liman, "DNS Root Name Service Protocol
              and Deployment Requirements", BCP 40, RFC 7720,
              DOI 10.17487/RFC7720, December 2015,
              <https://www.rfc-editor.org/rfc/rfc7720>.

   [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/rfc/rfc8126>.

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

   [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
              Gudmundsson, O., and B. Wellington, "Secret Key
              Transaction Authentication for DNS (TSIG)", STD 93,
              RFC 8945, DOI 10.17487/RFC8945, November 2020,
              <https://www.rfc-editor.org/rfc/rfc8945>.

   [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/rfc/rfc9082>.

   [RFC9575]  Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
              Entity Tag (DET) Authentication Formats and Protocols for
              Broadcast Remote Identification (RID)", RFC 9575,
              DOI 10.17487/RFC9575, June 2024,
              <https://www.rfc-editor.org/rfc/rfc9575>.

   [uas-sn-dns]
              Wiethuechter, A., "UAS Serial Numbers in DNS", Work in
              Progress, Internet-Draft, draft-wiethuechter-drip-uas-sn-
              dns-02, 25 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-wiethuechter-
              drip-uas-sn-dns-02>.

Authors' Addresses





Wiethuechter & Reid       Expires 15 June 2025                 [Page 17]

Internet-Draft                 DET in DNS                  December 2024


   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 15 June 2025                 [Page 18]