drip Working Group                                       A. Wiethuechter
Internet-Draft                                                   S. Card
Intended status: Standards Track                      AX Enterprize, LLC
Expires: 31 July 8 September 2022                                   R. Moskowitz
                                                          HTT Consulting
                                                                 J. Reid
                                                                RTFM llp
                                                         27 January
                                                            7 March 2022

                            DRIP Registries
                     draft-ietf-drip-registries-00
                     draft-ietf-drip-registries-01

Abstract

   This document creates the DRIP DET registration and discovery
   ecosystem.  This includes all components in the ecosystem (e.g., RAA,
   HDA, UA, GCS, USS).  The registration process will use the Extensible
   Provisioning Protocol (EPP) and other protocols.  The discovery
   process will leverage DNS and DNSSEC and related technology.  The
   DETs can be registered with as their "raw public keys" or in X.509
   certificates.

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 31 July 8 September 2022.

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Abstract Process & Reasoning  . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Required Terminology  . . . . . . . . . . . . . . . . . .   5
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  DRIP Attestations & Certificates  Registries  . . . . . . . . . . . . . .   5
     3.1.  Attestation Structure . . . . . . . . . . .   6
     3.1.  Classes . . . . . . . .   5
       3.1.1.  Attestor Identity Information . . . . . . . . . . . .   6
       3.1.2.  Attestation Data . . . . .   6
       3.1.1.  Root  . . . . . . . . . . . . .   7
       3.1.3.  Expiration Timestamp . . . . . . . . . . .   6
       3.1.2.  Registered Assigning Authorities  . . . . .   7
       3.1.4.  Signing Timestamp . . . . .   6
       3.1.3.  Hierarchial HIT Domain Authorities  . . . . . . . . .   7
     3.2.  Key Rollover & Federation . . . .   7
       3.1.5.  Signature . . . . . . . . . . . .   7
   4.  DRIP Fully Qualified Domain Names . . . . . . . . . .   7
     3.2.  Attestations . . . .   8
     4.1.  Serial Number . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Self-Attestation (SA-xx) . . . .   8
     4.2.  DET . . . . . . . . . .   7
       3.2.2.  Attestation (A-xy) . . . . . . . . . . . . . . . . .   8
       3.2.3.  Concise Attestation (CA-xy)
     4.3.  Reverse DET . . . . . . . . . . . . .   9
       3.2.4.  Mutual Attestation (MA-xy) . . . . . . . . . .   8
   5.  Supported DNS Records . . .  10
       3.2.5.  Link Attestation (LA-xy) . . . . . . . . . . . . . .  11
       3.2.6.  Broadcast Attestation (BA-xy) . . .   9
     5.1.  HIP RR  . . . . . . . . .  12
     3.3.  Certificates . . . . . . . . . . . . . . . .   9
     5.2.  CERT RR . . . . . .  14
       3.3.1.  Attestation Certificate (AC-zxy) . . . . . . . . . .  14
       3.3.2.  Concise Certificate (CC-zxy) . . . . . . . . .   9
     5.3.  NS RR . . .  15
       3.3.3.  Link Certificate (LC-zxy) . . . . . . . . . . . . . .  15
       3.3.4.  Mutual Certificate (MC-zxy) . . . . . . . . .   9
     5.4.  AAAA RR . . . .  16
   4.  Registries . . . . . . . . . . . . . . . . . . . . .   9
     5.5.  SVR RR  . . . .  17
     4.1.  Classes . . . . . . . . . . . . . . . . . . . . .  10
     5.6.  TLSA RR . . . .  17
       4.1.1.  Root . . . . . . . . . . . . . . . . . . . . .  10
   6.  Registry Operations . . .  18
       4.1.2.  Registered Assigning Authorities . . . . . . . . . .  18
       4.1.3.  Hierarchial HIT Domain Authorities . . . . . . . .  10
     6.1.  Registering a Registry  .  18
     4.2.  Federation . . . . . . . . . . . . . . . .  10
       6.1.1.  Registering an RAA  . . . . . . .  19
   5.  DRIP Fully Qualified Domain Names . . . . . . . . . .  11
       6.1.2.  Registering an IRM  . . . .  19
     5.1.  Serial Number . . . . . . . . . . . . .  12
       6.1.3.  Registering an HDA  . . . . . . . . .  19
     5.2.  Reverse SN . . . . . . . .  13
       6.1.4.  Registering an MRA  . . . . . . . . . . . . . . .  19
     5.3.  DET . .  14
     6.2.  Registering a Serial Number . . . . . . . . . . . . . . .  15
     6.3.  Registering an Operator . . . . . . . . . .  19
     5.4.  Reverse DET . . . . . . .  17
     6.4.  Registering a Session ID  . . . . . . . . . . . . . . . .  20
   6.  Supported DNS Records  18
       6.4.1.  Standard Provisioning . . . . . . . . . . . . . . . .  20
       6.4.2.  Operator Assisted Provisioning  . . . .  20
     6.1.  HIP RR . . . . . . .  22
       6.4.3.  Initial Provisioning  . . . . . . . . . . . . . . . .  23
   7.  EPP Command Mappings  . .  20
     6.2.  CERT RR . . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.3.  NS RR . . . . . .  23
     7.1.  Common Attributes . . . . . . . . . . . . . . . . . . . .  20
     6.4.  AAAA RR . . . . . . . . . . .  23
     7.2.  EPP Query Commands  . . . . . . . . . . . . . .  21
     6.5.  SVR RR . . . . .  24
       7.2.1.  EPP <check> Command . . . . . . . . . . . . . . . . .  24
       7.2.2.  EPP <info> Command  . . .  21
     6.6.  TLSA RR . . . . . . . . . . . . . .  24
       7.2.3.  EPP <transfer> Command  . . . . . . . . . . .  21
   7.  Registry Operations . . . .  24

     7.3.  EPP Transform Commands  . . . . . . . . . . . . . . . . .  21
     7.1.  Registering an RAA  24
       7.3.1.  EPP <create> Command  . . . . . . . . . . . . . . . .  24
       7.3.2.  EPP <delete> Command  . . .  21
       7.1.1.  Inputs . . . . . . . . . . . . .  28
       7.3.3.  EPP <renew> Command . . . . . . . . . .  21
       7.1.2.  DNS Entries . . . . . . .  30
       7.3.4.  EPP <transfer> Command  . . . . . . . . . . . . . .  22
       7.1.3.  Database Entries .  30
       7.3.5.  EPP <update> Command  . . . . . . . . . . . . . . . .  30
   8.  RDAP Definitions  .  22
       7.1.4.  Outputs . . . . . . . . . . . . . . . . . . . . .  30
   9.  IANA Considerations . .  22
     7.2.  Registering an IRM . . . . . . . . . . . . . . . . . . .  22
       7.2.1.  Inputs  30
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  30
     10.1.  DET Generation . . . .  22
       7.2.2.  DNS Entries . . . . . . . . . . . . . . . . .  30
   11. Contributors  . . . .  22
       7.2.3.  Database Entries . . . . . . . . . . . . . . . . . .  23
       7.2.4.  Outputs . .  31
   12. References  . . . . . . . . . . . . . . . . . . . . .  23
     7.3.  Registering an HDA . . . .  31
     12.1.  Normative References . . . . . . . . . . . . . . .  23
       7.3.1.  Inputs . . .  31
     12.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Appendix A.  DRIP Attestations & Certificates . . .  23
       7.3.2.  DNS Entries . . . . . . .  33
     A.1.  Attestation Structure . . . . . . . . . . . . . .  23
       7.3.3.  Database Entries . . . .  33
       A.1.1.  Attestor Identity Information . . . . . . . . . . . .  34
       A.1.2.  Attestation Data  . .  23
       7.3.4.  Outputs . . . . . . . . . . . . . . . .  34
       A.1.3.  Expiration Timestamp  . . . . . . .  23
     7.4.  Registering an MRA . . . . . . . . .  34
       A.1.4.  Signing Timestamp . . . . . . . . . .  23
       7.4.1.  Inputs . . . . . . . .  35
       A.1.5.  Signature . . . . . . . . . . . . . . .  24
       7.4.2.  DNS Entries . . . . . . .  35
     A.2.  Attestations  . . . . . . . . . . . . . .  24
       7.4.3.  Database Entries . . . . . . . .  35
       A.2.1.  Self-Attestation (SA-x) . . . . . . . . . .  24
       7.4.4.  Outputs . . . . .  35
       A.2.2.  Attestation (A-x.y) . . . . . . . . . . . . . . . . .  36
       A.2.3.  Concise Attestation (CA-x.y)  .  24
     7.5.  Registering a Serial Number . . . . . . . . . . .  37
       A.2.4.  Mutual Attestation (MA-x.y) . . . .  24
       7.5.1.  Inputs . . . . . . . . .  38
       A.2.5.  Link Attestation (LA-x.y) . . . . . . . . . . . . . .  24
       7.5.2.  DNS Entries  39
       A.2.6.  Broadcast Attestation (BA-x.y)  . . . . . . . . . . .  40
     A.3.  Certificates  . . . . . . . . . .  25
       7.5.3.  Database Entries . . . . . . . . . . . .  42
       A.3.1.  Attestation Certificate (AC-z.x.y)  . . . . . .  25
       7.5.4.  Outputs . . .  42
       A.3.2.  Concise Certificate (CC-z.x.y)  . . . . . . . . . . .  43
       A.3.3.  Link Certificate (LC-z.x.y) . . . . . . . . .  25
     7.6.  Registering an Operator . . . .  43
       A.3.4.  Mutual Certificate (MC-z.x.y) . . . . . . . . . . . .  44
     A.4.  Abbreviations & File Naming Conventions .  25
       7.6.1.  Inputs . . . . . . . .  45
       A.4.1.  In Text Abbreviation  . . . . . . . . . . . . . . .  25
       7.6.2.  DNS Entries .  46
       A.4.2.  File Naming . . . . . . . . . . . . . . . . . . . .  25
       7.6.3.  Database Entries .  46
   Appendix B.  X.509 Certificates . . . . . . . . . . . . . . . . .  26
       7.6.4.  Outputs  46
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
     7.7.  Registering a Session  46

1.  Introduction

   Registries are fundamental to RID.  Only very limited information can
   be Broadcast, but extended information is sometimes needed.  The most
   essential element of information sent is the UAS ID  . . . . . . . . . . . . . . . .  26
       7.7.1.  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  26
       7.7.2.  DNS Entries . . . . . . . . . . . . . . . . . . . . .  26
       7.7.3.  Database Entries  . . . . . . . . . . . . . . . . . .  27
       7.7.4.  Outputs . . . . . . . . . . . . . . . . . . . . . . .  27
   8.  Provisioning  . . . . . . . . . . . . . . . . . . . . . . . .  27
     8.1.  Overview itself, the
   unique key for lookup of Transactions  . . . . . . . . . . . . . . . .  27
     8.2.  HHIT Delegation . . . . . . . . . . . . . . . . . . . . .  28
     8.3.  Registry  . . . . . . . . . . . . . . . . . . . . . . . .  29
     8.4.  Manufacturer  . . . . . . . . . . . . . . . . . . . . . .  30
     8.5.  Operator  . . . . . . . . . . . . . . . . . . . . . . . .  30
     8.6.  Aircraft  . . . . . . . . . . . . . . . . . . . . . . . .  31
       8.6.1.  Standard Provisioning . . . . . . . . . . . . . . . .  31
       8.6.2.  Operator Assisted Provisioning  . . . . . . . . . . .  34
       8.6.3.  Initial Provisioning  . . . . . . . . . . . . . . . .  35
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  36
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  36
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  36
     12.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

   Registries extended information in registries.

   While it is expected that registry functions will be integrated with
   USS, who will provide them is not yet determined in most, and is
   expected to vary between, jurisdictions.  However this evolves, the
   essential registry functions, starting with management of
   identifiers, are expected to remain the same, so are specified
   herein.

   While most data to be sent via Broadcast or Network RID is public,
   much of the extended information in registries will be private.  Thus
   AAA for registries is essential, not just to ensure that access is
   granted only to strongly authenticated, duly authorized parties, but
   also to support subsequent attribution of any leaks, audit of who
   accessed information when and for what purpose, etc.  As specific AAA
   requirements will vary by jurisdictional regulation, provider
   philosophy, customer demand, etc., they are fundamental left to RID.  Only very limited information can specification in
   policies, which should be Broadcast, but extended information is sometimes needed. human readable to facilitate analysis and
   discussion, and machine readable to enable automated enforcement,
   using a language amenable to both, e.g., XACML.

   The most
   essential element intent of information sent is the UAS ID itself, negative and positive access control requirements
   on registries is to ensure that no member of the
   unique key for lookup public would be
   hindered from accessing public information, while only duly
   authorized parties would be enabled to access private information.
   Mitigation of extended Denial of Service attacks and refusal to allow database
   mass scraping would be based on those behaviors, 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 as the worry of collisions in registries.

   While it the
   hash portion of the DET.  Forgery of the DET is expected that registry functions still possible, but
   including it as a part of a public registration mitigates a lot of
   the risk.  This document creates the DRIP DET registration and
   discovery ecosystem.  This includes all components in the ecosystem
   (e.g., RAA, HDA, UA, GCS, USS).  The registration process will use
   the Extensible Provisioning Protocol (EPP) and other protocols.  The
   discovery process will leverage DNS and DNSSEC and related
   technology.  The DETs can be integrated registered with
   USS, who will provide them is not yet determined as their "raw public
   keys" or in most, X.509 certificates.

1.1.  Abstract Process & Reasoning

   In DRIP each entity (registries, operators and aircraft) is expected
   to vary between, jurisdictions.  However this evolves, generate a full DRIP Entity ID [drip-rid] on the
   essential registry functions, starting with management of
   identifiers, are local device
   their key is expected to remain the same, so be used.  These are specified
   herein.

   While most registered with a Public
   Information Registry within the hierarchy along with whatever data to be sent via Broadcast or Network RID is public,
   much of
   required by the extended information cognizant CAA and the registry.  Any PII is stored in registries will be private.  Thus
   a Private Information Registry protected through industry practice
   AAA for registries is essential, not just to ensure or better.  In response, the entity will obtain an attestation or
   certificate from the registry proving such registration.

   Manufacturers that access is
   granted only wish to strongly authenticated, duly authorized parties, participate in DRIP should not only
   support DRIP as a Session ID type for their aircraft but also
   generate a DET then encode it as a Serial Number.  This would allow
   aircraft under CAA mandates to support subsequent attribution of any leaks, audit of who
   accessed information fly only ID Type 1 (Serial Number)
   could still use DRIP and all its benefits.  Even if DRIP is not
   supported for Serial Numbers by a Manufacturer it is hoped that they
   would still run a registry 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 what purpose, etc.  As specific AAA
   requirements will 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 by jurisdictional regulation, provider
   philosophy, customer demand, etc., based on the CAA they are left under and the registry.

   Finally aircraft that support using a DET would provision per flight
   to specification in
   policies, which should be human readable a USS, proposing a DET to facilitate analysis the registry to generate a binding
   between the aircraft (Session ID, Serial Number and
   discussion, Operational
   Intent), operator and machine readable registry.  Aircraft then follow [drip-auth] to enable automated enforcement,
   using a language amenable
   meet various [drip-requirements] during flight.

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 both, e.g., XACML. be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   See [drip-requirements] for common DRIP terms.

   HDA:  Hierarchial HIT Domain Authority.  The intent of 16 bit field identifying
      the negative and positive access control requirements
   on registries HIT Domain Authority under a RAA.

   HID:  Hierarchy ID.  The 32 bit field providing the HIT Hierarchy ID.

   RAA:  Registered Assigning Authority.  The 16 bit field identifying
      the Hierarchical HIT Assigning Authority.

3.  Registries

3.1.  Classes

   Under DRIP there 3 classes of registries, with specific variants in
   each.

                          +----------+
                          |   Root   |
                          +-o------o-+
                            |      |
          ******************|******|*****************************
                            |      |
                      +-----o-+  +-o-----+
          RAAs        |  IRM  |  |  RAA  o------.
                      +---o---+  +---o---+      '
                          |          |          |
          ****************|**********|**********|****************
                          |          |          |
                      +---o---+  +---o---+  +---o---+
          HDAs        |  MRA  |  | RIDR  |  |  HDA  |
                      +-------+  +-------+  +-------+

                        Figure 1: Registry Hierarchy

3.1.1.  Root

   This is a special registry holding the RAA value of 0 and HDA value
   of 0.  It delegates out RAA values only to ensure registries that no member of wish to
   act as an RAA.

3.1.2.  Registered Assigning Authorities

   RAA's are the public would be
   hindered from accessing public information, while only duly
   authorized parties would upper hierarchy in DRIP.  Most are contemplated to be enabled
   Civil Aviation Authorities (CAAs) that then delegate HDAs to access private information.
   Mitigation of Denial manage
   their NAS.  This is does not preclude other entities to operate an
   RAA if the Root server allows it.

   All RAA's use an HDA value of Service attacks 0 and refusal have their RAA value delegated to allow database
   mass scraping would be based on those behaviors, 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 as
   them by the worry Root.

3.1.2.1.  ICAO Registry of collisions Manufacturer's (IRM)

   A special RAA that hands out HDA values to participating
   Manufacturer's that hold an ICAO Manufacturer Code used in ANSI
   CTA2063-A Serial Numbers.

   It is holds the
   hash portion RAA value of the DET.  Forgery 1 and HDA value of the DET is still possible, but
   including it as 0.

3.1.3.  Hierarchial HIT Domain Authorities

3.1.3.1.  Manufacturer's Registry of Aircraft (MRA)

   A registry (HDA) run by a part manufacturer of UAS systems that
   participate in Remote ID.  Stores UAS Serial Numbers under a public registration mitigates specific
   ICAO Manufacturer Code (assigned to the manufacturer by ICAO).

   A DET can be encoded into a Serial Number (see [drip-rid]) and this
   registry would hold a lot of mapping from the risk.  This document creates Serial Number to the DRIP DET registration and
   discovery ecosystem.  This includes all components in
   its artifacts.

   Hold RAA value of 1 and HDA values of 1+.

3.1.3.2.  Remote ID Registries (RIDR)

   Registry that holds the ecosystem
   (e.g., RAA, HDA, UA, GCS, USS).  The registration process will use binding between a UAS Session ID (for DRIP
   the Extensible Provisioning Protocol (EPP) DET) and other protocols. the UA Serial Number.  The
   discovery process will leverage DNS and DNSSEC and related
   technology. Serial Number MUST have its
   access protected to allow only authorized parties to obtain.  The DETs can
   Serial Number SHOULD be registered with as their "raw public
   keys" or encrypted in X.509 certificates.

2.  Terminology

2.1.  Required Terminology

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

   Hold RAA values of 2+ and HDA values of 1+.

3.2.  Key Rollover & Federation

   During key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", rollover the entity MUST inform all children and
   "OPTIONAL" in parents
   of the change - using best standard practices of a key rollover.  At
   time of writing this document are to be interpreted as described is signing over the new key with the previous
   key in BCP
   14 [RFC2119] [RFC8174] when, a secure fashion and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   See [drip-requirements] for common DRIP terms.

   HDA:  Hierarchial HIT Domain Authority.  The 16 bit field identifying it being validated by others before
   changing any links (in DRIPs case the NS RRs in the HIT Domain Authority parent registry).

   A DET has a natural ability for a single entity to hold different
   cryptographic identities under the same HID values.  This is due to
   the lower 64-bits of the DET being a RAA.

   HID:  Hierarchy ID.  The 32 bit field providing hash of the HIT Hierarchy ID.

   RAA:  Registered Assigning Authority.  The 16 bit field identifying public key and the Hierarchical HIT Assigning Authority.

3.  DRIP Attestations & Certificates

3.1.  Attestation Structure

   All Attestations
   HID of the DET being generated.  As such during key rollover, only
   the lower 64-bits would change and Certificates under DRIP a check for a collision would be
   required.

   This attribute of the DET to have different identities could also
   allow for a single registry to be "federated" across them if they
   share the following
   format:

    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
   +---------------+---------------+---------------+---------------+
   |                                                               |
   .                                                               .
   .                 Attestor Identity Information                 .
   .                                                               .
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   .                                                               .
   .                       Attestation Data                        .
   .                                                               .

   |                                                               |
   +---------------+---------------+---------------+---------------+
   |               Expiration Timestamp by Attestor                |
   +---------------+---------------+---------------+---------------+
   |                 Signing Timestamp by Attestor                 |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                     Signature by Attestor                     |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +---------------+---------------+---------------+---------------+

   Attestor Identity Information: (0, 16-bytes or 120-bytes)
       Field containing Attestor Identity Information same HID value.  This method of deployment has not been
   thoroughly studied at this time.

4.  DRIP Fully Qualified Domain Names

   Under DRIP there are a number of FQDN forms used to allow lookups to
   take place.

   The individual DETs may be potentially too numerous (e.g., 60 - 600M)
   and dynamic (e.g., new DETs every minute for some HDAs) to store in various forms.

   Attestation Data: a
   signed, DNS zone.  The HDA SHOULD provide DNS service for its zone
   and provide the HHIT detail response.  A field secure connection (e.g., DNS
   over TLS) to the authoritative zone may be a viable alternative to
   DNSSEC.

4.1.  Serial Number

   Serial Number: 8653FZ2T7B8RA85D19LX
   ICAO Mfr Code: 8653
   Length Code: F
   ID: FZ2T7B8RA85D19LX
   FQDN: Z2T7B8RA85D19LX.F.8653.mfr.uas.icao.int

4.2.  DET

   The DET reverse lookup can be a standard IPv6 reverse look up, or it
   can leverage off the HHIT structure.  If we assume a prefix of variable length containing
   2001:30::/28:

   DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e
   ID: a3ad:1952:0ad0:a69e
   OGA: 5
   HDA: 0014 = 20
   RAA: 000a = 10
   Prefix: 20010030
   FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int

   When building a DET FQDN the attestation data.

   Expiration Timestamp following two things must be done:

   1.  The RAA and HDA values MUST be converted from hexadecimal to
       decimal form

   2.  The FQDN must be built using the expanded form of the IPv6
       address

   The prefix is included in the FQDN form to support other potential
   prefixes being used.

4.3.  Reverse DET
   $ORIGIN  5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
   e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a    IN   PTR

5.  Supported DNS Records

   DRIP requires a number of resource records, some specific to certain
   registries to function.

5.1.  HIP RR

   All registries will have their own DET associated with them and their
   respective DNS server will hold a HIP RR that is pointed to by Attestor (4 bytes):
       Timestamp denoting recommended time their
   DET FQDN.

   MRA and RIDR servers will also have HIP RRs for their registered
   parties (aircraft and operators).

5.2.  CERT RR

   Most attestations can be placed into DNS.  An exception to trust data to.

   Signing Timestamp by Attestor (4 bytes):
       Current time at signing.

   Attestor Signature (64 bytes):
       Signature over preceding fields using the keypair of this is
   the Attestor.

                      Figure 1: Attestation Structure

3.1.1.  Attestor Identity Information Certificate made during Session ID registration.
   This can is as this particular certificate acts similar to a car
   registration and should be any one of held safe by the following: operator.

5.3.  NS RR

   Along with their associated "glue" record (A/AAAA) supports the
   traversal in DNS across the tree.

   1.  None  <mfr.remoteid.aero> on Root points to specific DET FQDN of IRM

   2.  Attestor HHIT: 16-bytes

   3.  Attestor SelfAttestation: 120-bytes

   A  <icao_mfr_code>.mfr.remoteid.aero on IRM points to specific definition DET
       FQDN of MRA

   3.  <raa_value>.det.remoteid.aero on Root pointing to DET FQDN of
       matching RAA

   4.  <hda_value>.<raa_value>.det.remoteid.aero on RAA pointing to DET
       FQDN of matching HDA

5.4.  AAAA RR

   DRIP requires the use of IPv6.

5.5.  SVR RR

   The SVR RR for DRIP always is populated at the "local" registry
   level.  That is an Attestation or Certificate defines which HDA's DNS would hold the SVR RR that points to
   that HDAs private registry for all data it manages.  This data
   includes data being stored on its children.

   The best example of these are used.

   Two Attestation's remove this field: MutualAttestation Section 3.2.4
   and LinkAttestation Section 3.2.5 as their definition clearly states is RIDR would have a SVR RR that points to a
   database that contains any extra information of a Session ID it has
   registered.  Another example is the signer MRA has a SVR RR pointing to
   where the metadata of a UA registered in the MRA can be located.

   In all cases the server being pointed to MUST be protected using AAA,
   specifically using RDAP.

5.6.  TLSA RR

   This RR is mainly used to support DTLS deployments where the second party with their HHIT or
   SelfAttestation already embedded DET is
   used in Network RID and the Attestation Data.

3.1.2.  Attestation Data

   The data being attested to.  It can be one of wider UTM system.

6.  Registry Operations

   As a general rule the following forms: processing performed for any
   registration operation:

   1.  Claims  Verify input Attestations from registering party

   2.  Assertions  Check for collision of DET and HI

   3.  Attestations

   This field is variable length  Populate DNS with no limit required/optional records

   4.  Populate Database with PII and specific definitions other info

   5.  Generate and return required/optional Attestations/Certificates

6.1.  Registering a Registry

   DRIP defines two levels of an Attestation or Certificate indicate hierarchy maintained by the fields, size Registration
   Assigning Authority (RAA) and
   ordering HHIT Domain Authority (HDA).  The
   authors anticipate that an RAA is owned and operated by a regional
   CAA (or a delegated party by an CAA in a specific airspace region)
   with HDAs being contracted out.  As such a chain of any subfields.

3.1.3.  Expiration Timestamp

   A UTC timestamp set some time into the future trust for
   registries is required to indicate a point the
   Attestation Structure should ensure trustworthiness is not compromised.
   More information on the registries can be trusted.

3.1.4.  Signing Timestamp

   A UTC timestamp set to found in [hhit-registries].

   Both the time when parent and child generate their own keypairs and self-signed
   attestations if not generated previously.  The child sends to the Attestation Structure was
   signed.

3.1.5.  Signature

   An EdDSA25519 signature using
   parent its self-signed attestation to be added into the signing parties private key over parent DNS.

   The parent confirms the preceding fields in attestation received is valid and that no DET
   collisions occur before adding a NS RR (and CERT RRs) to its DNS for
   the Attestation Structure.

3.2.  Attestations

3.2.1.  Self-Attestation (SA-xx) new child.  An attestation, parent on child, is sent as a
   confirmation that provisioning was successful.

   The only attestation to use child is now a claim (the Host Identity) in valid member of the
   Attestation Data registry tree and uses its
   keypair and Self-Attestation with all provisioning requests towards
   it.  The HIP RR for the HHIT acting as child is populated into the Attestor Identity
   Information.

      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
     +---------------+---------------+---------------+---------------+
     | local DNS along
   with any CERT RRs.

6.1.1.  Registering an RAA

   Specifically handled by the Root (Section 3.1.1).

   +==================+===================================+============+
   |Inputs (Optional) |DNS Entries (Optional)             |Outputs     |
   |                          Hierarchical                  |                                   |(Optional)  |                       Host Identity Tag
   +==================+===================================+============+
   |IP Address of RAA |Root: <raa_value>.det.remoteid.aero|Attestation:|
   |                  |NS <raa_det_fqdn>                  |Root, RAA   |
   +------------------+-----------------------------------+------------+
   |RAA Self-         |Root: <raa_det_fqdn> AAAA <raa_ip> |(Concise    |
     +---------------+---------------+---------------+---------------+
   |Attestation       |                                   |Attestation:|
   |                  |                                   |Root, RAA)  |
   +------------------+-----------------------------------+------------+
   |                  |RAA: <raa_det_fqdn> HIP            |(Broadcast  |
   |                          Host Identity                  |<hip_rr_data>                      |Attestation:|
   |                  |                                   |Root, RAA)  |
   +------------------+-----------------------------------+------------+
   |                  |RAA: <raa_det_fqdn> CERT           |            |
   |                  |<raa_self_attestation>             |            |
     +---------------+---------------+---------------+---------------+
   +------------------+-----------------------------------+------------+
   |                         Trust Timestamp                  |(Root: <raa_det_fqdn> CERT         |
     +---------------+---------------+---------------+---------------+            |                        Signing Timestamp
   |
     +---------------+---------------+---------------+---------------+                  |<attestation_root_raa>)            |            |
   +------------------+-----------------------------------+------------+
   |                  |(Root: <raa_det_fqdn> CERT         |            |
   |                  |<concise_attestation_root_raa>)    |            |
   +------------------+-----------------------------------+------------+
   |                  |(Root: <raa_det_fqdn> CERT         |            |
   |                  |<broadcast_attestation_root_raa>)  |            |
   +------------------+-----------------------------------+------------+
   |                            Signature                  |(RAA: <raa_det_fqdn> CERT          |            |
   |                  |<attestation_root_raa>)            |            |
   +------------------+-----------------------------------+------------+
   |                  |(RAA: <raa_det_fqdn> CERT          |            |
   |                  |<concise_attestation_root_raa>)    |            |
   +------------------+-----------------------------------+------------+
   |                  |(RAA: <raa_det_fqdn> CERT          |            |
   |                  |<broadcast_attestation_root_raa>)  |            |
     +---------------+---------------+---------------+---------------+

     Length = 120-bytes

                      Figure 2: DRIP Self-Attestation

3.2.2.  Attestation (A-xy)

   (Editors Note: blurb here?)
      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
   +------------------+-----------------------------------+------------+

                                  Table 1
     +---------------+---------------+---------------+---------------+

6.1.2.  Registering an IRM

   Specifically handled by the Root (Section 3.1.1).

   +==================+===================================+============+
   |Inputs (Optional) |DNS Entries (Optional)             |Outputs     |
   |
     .                                                               .
     .                             SA-xx                             .
     .                                                               .                  |                                   |(Optional)  |
     +---------------+---------------+---------------+---------------+
   +==================+===================================+============+
   |IP Address of IRM |Root: mfr.remoteid.aero NS         |Attestation:|
   |                  |<irm_det_fqdn>                     |Root, IRM   |
     .                                                               .
     .                             SA-yy                             .
     .                                                               .
   +------------------+-----------------------------------+------------+
   |IRM Self-         |Root: 1.det.remoteid.aero NS       |(Concise    |
   |Attestation       |<irm_det_fqdn>                     |Attestation:|
   |
     +---------------+---------------+---------------+---------------+                  |                      Trust Timestamp by X                                   |Root, IRM)  |
   +------------------+-----------------------------------+------------+
   |                  |Root: <irm_det_fqdn> AAAA <irm_ip> |(Broadcast  |
   |                  |                                   |Attestation:|
   |                  |                                   |Root, IRM)  |
   +------------------+-----------------------------------+------------+
   |                  |IRM: <irm_det_fqdn> HIP            |            |
   |                  |<hip_rr_data>                      |            |
   +------------------+-----------------------------------+------------+
   |                  |IRM: <irm_det_fqdn> CERT           |            |
   |                  |<irm_self_attestation>             |            |
   +------------------+-----------------------------------+------------+
   |                  |(Root: <irm_det_fqdn> CERT         |
     +---------------+---------------+---------------+---------------+            |                     Signing Timestamp by X
   |
     +---------------+---------------+---------------+---------------+                  |<attestation_root_irm>)            |            |
   +------------------+-----------------------------------+------------+
   |                  |(Root: <irm_det_fqdn> CERT         |            |
   |                  |<concise_attestation_root_irm>)    |            |
   +------------------+-----------------------------------+------------+
   |                  |(Root: <irm_det_fqdn> CERT         |            |
   |                  |<broadcast_attestation_root_irm>)  |            |
   +------------------+-----------------------------------+------------+
   |                         Signature by X                  |(IRM: <irm_det_fqdn> CERT          |            |
   |                  |<attestation_root_irm>)            |            |
   +------------------+-----------------------------------+------------+
   |                  |(IRM: <irm_det_fqdn> CERT          |            |
   |                  |<concise_attestation_root_irm>)    |            |
   +------------------+-----------------------------------+------------+
   |                  |(IRM: <irm_det_fqdn> CERT          |            |
   |                  |<broadcast_attestation_root_irm>)  |            |
     +---------------+---------------+---------------+---------------+

     Length = 312-bytes

                         Figure 3: DRIP Attestation

3.2.3.  Concise Attestation (CA-xy)

   In constrained environments and when there is the guarantee of being
   able to lookup the HHITs to obtain HIs this attestation can be used.

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

                                  Table 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+

6.1.3.  Registering an HDA

   Specifically handled by an RAA (Section 3.1.2).

   +===========+==========================================+============+
   |Inputs     |DNS Entries (Optional)                    |Outputs     |
   |(Optional) |                                          |(Optional)  |                          Hierarchical
   +===========+==========================================+============+
   |IP Address |RAA:                                      |Attestation:|
   |of HDA     |<hda_value>.<raa_value>.det.remoteid.aero |RAA, HDA    |
   |                    Host Identity Tag of X           |NS <hda_det_fqdn>                         |            |
   +-----------+------------------------------------------+------------+
   |HDA Self-  |RAA: <hda_det_fqdn> AAAA <hda_ip>         |(Concise    |
     +---------------+---------------+---------------+---------------+
   |Attestation|                                          |Attestation:|
   |           |                                          |RAA, HDA)   |                          Hierarchical
   +-----------+------------------------------------------+------------+
   |           |RAA: <hda_det_fqdn> HIP <hip_rr_data>     |(Broadcast  |                    Host Identity Tag of Y
   |           |                                          |Attestation:|
   |
     +---------------+---------------+---------------+---------------+           |                      Trust Timestamp by X                                          |RAA, HDA)   |
     +---------------+---------------+---------------+---------------+
   +-----------+------------------------------------------+------------+
   |                     Signing Timestamp by X           |HDA: <hda_det_fqdn> CERT                  |
     +---------------+---------------+---------------+---------------+            |
   |           |<hda_self_attestation>                    |            |
   +-----------+------------------------------------------+------------+
   |           |(RAA: <hda_det_fqdn> CERT                 |            |
   |           |<attestation_raa_hda>)                    |            |
   +-----------+------------------------------------------+------------+
   |           |(RAA: <hda_det_fqdn> CERT                 |            |
   |           |<concise_attestation_raa_hda>)            |                         Signature by X            |
   +-----------+------------------------------------------+------------+
   |           |(RAA: <hda_det_fqdn> CERT                 |            |
   |           |<broadcast_attestation_raa_hda>)          |            |
   +-----------+------------------------------------------+------------+
   |           |(HDA: <hda_det_fqdn> CERT                 |            |
   |           |<attestation_raa_hda>)                    |            |
   +-----------+------------------------------------------+------------+
   |           |(HDA: <hda_det_fqdn> CERT                 |            |
   |
     +---------------+---------------+---------------+---------------+

     Length = 104-bytes

                     Figure 4: DRIP Concise Attestation

3.2.4.  Mutual Attestation (MA-xy)

   An attestation that perform a sign over an existing Attestation where
   the signer is the second party of the embedded attestation.

   This Attestation is one of two that does not fill in the Attestor
   Identity Information (Section 3.1.1) as the data is already present
   in the Attestation Data (Section 3.1.2) in the form of Y's
   SelfAttestation.

   The unique size of this attestation (384-bytes) allows for easy
   detection and subsequent decoding without issue.

      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
     +---------------+---------------+---------------+---------------+           |<concise_attestation_raa_hda>)            |            |
     .                                                               .
     .                              A-xy                             .
     .                                                               .
   +-----------+------------------------------------------+------------+
   |           |(HDA: <hda_det_fqdn> CERT                 |
     +---------------+---------------+---------------+---------------+            |                      Trust Timestamp by Y
   |
     +---------------+---------------+---------------+---------------+           |<broadcast_attestation_raa_hda>)          |                     Signing Timestamp            |
   +-----------+------------------------------------------+------------+

                                  Table 3

6.1.4.  Registering an MRA

   Specifically handled by Y the IRM (Section 3.1.2.1).

   +==================+===================================+============+
   |Inputs (Optional) |DNS Entries (Optional)             |Outputs     |
   |
     +---------------+---------------+---------------+---------------+                  |                                   |(Optional)  |
   +==================+===================================+============+
   |IP Address of MRA |IRM:                               |Attestation:|
   |                  |<icao_mfr_code>.mfr.remoteid.aero  |IRM, MRA    |
   |                  |NS <mra_det_fqdn>                  |            |
   +------------------+-----------------------------------+------------+
   |MRA Self-         |IRM:                               |(Concise    |
   |Attestation       |<hda_value>.1.det.remoteid.aero NS |Attestation:|
   |                  |<mra_det_fqdn>                     |IRM, MRA)   |
   +------------------+-----------------------------------+------------+
   |ICAO Manufacturer |IRM: <mra_det_fqdn> AAAA <mra_ip>  |(Broadcast  |
   |Code              |                                   |Attestation:|
   |                  |                                   |IRM, MRA)   |                         Signature by Y
   +------------------+-----------------------------------+------------+
   |                  |MRA: <mra_det_fqdn> HIP            |            |
   |                  |<hip_rr_data>                      |            |
   +------------------+-----------------------------------+------------+
   |                  |MRA: <mra_det_fqdn> CERT           |            |
   |                  |<mra_self_attestation>             |            |
   +------------------+-----------------------------------+------------+
   |                  |(IRM: <mra_det_fqdn> CERT          |            |
   |                  |<attestation_irm_mra>)             |
     +---------------+---------------+---------------+---------------+

     Length = 384-bytes

                     Figure 5: DRIP Mutual Attestation

3.2.5.  Link Attestation (LA-xy)

   An attestations that perform            |
   +------------------+-----------------------------------+------------+
   |                  |(IRM: <mra_det_fqdn> CERT          |            |
   |                  |<concise_attestation_irm_mra>)     |            |
   +------------------+-----------------------------------+------------+
   |                  |(IRM: <mra_det_fqdn> CERT          |            |
   |                  |<broadcast_attestation_irm_mra>)   |            |
   +------------------+-----------------------------------+------------+
   |                  |(MRA: <mra_det_fqdn> CERT          |            |
   |                  |<attestation_irm_mra>)             |            |
   +------------------+-----------------------------------+------------+
   |                  |(MRA: <mra_det_fqdn> CERT          |            |
   |                  |<concise_attestation_irm_mra>)     |            |
   +------------------+-----------------------------------+------------+
   |                  |(MRA: <mra_det_fqdn> CERT          |            |
   |                  |<broadcast_attestation_irm_mra>)   |            |
   +------------------+-----------------------------------+------------+

                                  Table 4

6.2.  Registering a sign over Serial Number

   Specifically handled by an existing
   ConciseAttestation where the signer is the second party of the
   embedded attestation.

   This Attestation is one of two that does not fill in the Attestor
   Identity Information (Section 3.1.1) as the data is already present
   in the Attestation Data MRA (Section 3.1.2) in the form of Y's HHIT.

   The unique size of this attestation (176-bytes) allows for easy
   detection and subsequent decoding without issue.

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

   +===================+=================================+=============+
   | Inputs (Optional) |DNS Entries (Optional)           |Outputs      |
     .                                                               .
     .                             CA-xy                             .
     .                                                               .
   |                   |
     +---------------+---------------+---------------+---------------+                                 |(Optional)   |                      Trust Timestamp by Y
   +===================+=================================+=============+
   |
     +---------------+---------------+---------------+---------------+ Serial Number     |(<sn_det_fqdn> HIP <hip_rr_data>)|(Attestation:|
   |                     Signing Timestamp by Y                   |
     +---------------+---------------+---------------+---------------+                                 |MRA, UA)     |
   +-------------------+---------------------------------+-------------+
   | (UA Self-         |(<sn_det_fqdn> CERT              |(Broadcast   |
   | Attestation)      |<sn_self_attestation>)           |Attestation: |
   |                   |                                 |MRA, UA      |
   +-------------------+---------------------------------+-------------+
   | UA Metadata       |(<sn_det_fqdn> CERT              |(Concise     |
   |                   |<attestation_mra_sn>)            |Attestation: |
   |                   |                                 |MRA, UA)     |
   +-------------------+---------------------------------+-------------+
   |                   |(<sn_det_fqdn> CERT              |             |                         Signature by Y
   |                   |<concise_attestation_mra_sn>)    |             |
   +-------------------+---------------------------------+-------------+
   |                   |(<sn_det_fqdn> CERT              |             |
   |                   |<broadcast_attestation_mra_sn>)  |             |
   +-------------------+---------------------------------+-------------+

                                  Table 5

                +--------------+    SA-a0a0 +-----------------+
                | Manufacturer | <--------> | Manufacturer CA |
                +--------------+ A-ma0      +-----------------+
                    ^    |
                    |    |
                    |    |
            SA-a0a0 |    |   A-ma0
                    |    |
                    |    v
                +----------+
                | Aircraft |
     +---------------+---------------+---------------+---------------+

     Length = 176-bytes
                +----------+

                      Figure 6: DRIP Link Attestation

3.2.6.  Broadcast Attestation (BA-xy)

   Required by DRIP Authentication Formats 2: Manufacturer Provision

   During the initial configuration and production at the factory the
   Aircraft MUST be configured to have a serial number.  ASTM defines
   this to be an ANSI/CTA-2063A Serial Number for Broadcast RID (Editor
   Note: add link UAS.  Under DRIP a DET
   can be encoded as such to draft here) be able to satisfy [drip-requirements] GEN-1 convert back and GEN-3.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 forth between
   them.  This is covered in [drip-rid].

   Under DRIP the Manufacturer SHOULD be using DETs and have their own
   keypair and Self-Attestation: Manufacturer (SA-m).  (Ed.  Note: some
   words on aircraft keypair and certs here?).

   Self-Attestation: Aircraft 0 1 2 3 4 5 6 7 8 9 on Aircraft 0 1 2 3 4 5 6 7 8 9 (SA-a0a0) is extracted by
   the manufacturer and sent to their Certificate Authority (CA) to be
   verified and added.  A resulting attestation (Attestation:
   Manufacturer on Aircraft 0 1
     +---------------+---------------+---------------+---------------+
     | [A-ma0]) SHOULD be a DRIP Attestation -
   however this could be a X.509 certificate binding the serial number
   to the manufacturer.

6.3.  Registering an Operator

   Specifically handled by a RIDR (Section 3.1.3.2).

   +==================+==================================+=============+
   |Inputs (Optional) | DNS Entries (Optional)           |Outputs      |                          Hierarchical
   |                  |                    Host Identity Tag of X                                  |(Optional)   |
   +==================+==================================+=============+
   |Operator Self-    | <op_det_fqdn> HIP <hip_rr_data>  |Attestation: |
     +---------------+---------------+---------------+---------------+
   |Attestation       |                                  |RIDR,        |
   |                          Hierarchical                  |                                  |Operator     |                    Host Identity Tag of Y
   +------------------+----------------------------------+-------------+
   |Operator PII      | (<op_det_fqdn> CERT              |Broadcast    |
   |
     +---------------+---------------+---------------+---------------+                  | <op_self_attestation>)           |Attestation: |
   |                  |                                  |RIDR,        |
   |                  |                       Host Identity of Y                                  |Operator     |
   +------------------+----------------------------------+-------------+
   |                  | (<op_det_fqdn> CERT              |(Concise     |
   |                  | <attestation_ridr_op>)           |Attestation: |
   |                  |
     +---------------+---------------+---------------+---------------+                                  |RIDR,        |                      Trust Timestamp by X
   |
     +---------------+---------------+---------------+---------------+                  |                     Signing Timestamp by X                                  |Operator)    |
     +---------------+---------------+---------------+---------------+
   +------------------+----------------------------------+-------------+
   |                  | (<op_det_fqdn> CERT              |             |
   |                  | <concise_attestation_ridr_op>)   |             |
   +------------------+----------------------------------+-------------+
   |                  | (<op_det_fqdn> CERT              |             |
   |                  | <broadcast_attestation_ridr_op>) |                         Signature by X             |
   +------------------+----------------------------------+-------------+

                                  Table 6

                    +----------+            +---------+
                    | Registry | ---------> | HDA DNS |
                    +----------+  [HIP RR]  +---------+
                        ^   |
                        |   |
                        |   |
                    Coo |   | Aro
                        |   |
                        |   v
                    +----------+
                    | Operator |
     +---------------+---------------+---------------+---------------+

     Length = 136-bytes
                    +----------+

                        Figure 7: DRIP Broadcast Attestation

3.3.  Certificates

   In DRIP certificates are signed by 3: Operator Provision

   The Operator generates a third party that has no stake keypair and DET as specified in
   the claims/assertions/attestations being attested to.

   It DRIP UAS
   RID.  A self-signed attestation (Self-Attestation: Operator on
   Operator [SA-oo]) is analogous generated and sent to the desired registry
   (HDA).  Other relevant information and possibly personally
   identifiable information needed may also be required to be sent to
   the registry (all over a third party in legal system that signs a
   document secure channel - the method of which is out
   of scope for this document).

   The registry cross checks any personally identifiable information as a "witness"
   required.  Certificate: Operator on Operator is verified (both using
   the expiration timestamp and bears no responsibility signature).  The DET is searched in the document.

3.3.1.  Attestation Certificate (AC-zxy)

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             SA-zz                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              A-xy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Z                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp
   Registries database to confirm that no collision occurs.  A new
   attestation is generated (Attestation: Registry on Operator) and sent
   securely back to the Operator.  Optionally the DET/HI pairing can be
   added to the Registries DNS in to form of a HIP Resource Record (RR).
   Other RRs, such as CERT and TXT, may also be used to hold public
   information.

   With the receipt of Attestation: Registry on Operator (A-ro) the
   provisioning of an Operator is complete.

6.4.  Registering a Session ID

   Specifically handled by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               | a RIDR (Section 3.1.3.2).

   +=============+======================================+==============+
   |Inputs       | DNS Entries (Optional)               |Outputs       |
   |(Optional)   |                                      |(Optional)    |
   +=============+======================================+==============+
   |Attestation: | <session_det_fqdn> HIP <hip_rr_data> |Attestation:  |
   |RIDR,        |                                      |RIDR, Operator|
   |Operator     |                                      |              |
   +-------------+--------------------------------------+--------------+
   |Attestation: | <session_det_fqdn> CERT              |Broadcast     |
   |Operator, UA |                         Signature by Z <session_self_attestation>           |Attestation:  |
   |             |                                      |RIDR, Operator|
   +-------------+--------------------------------------+--------------+
   |Serial Number| <session_det_fqdn> CERT              |Attestation   |
   |             | <broadcast_attestation_ridr_session> |Certificate:  |
   |             |                                      |RIDR,         |
   |             |                                      |Operator, UA  |
   +-------------+--------------------------------------+--------------+
   |(Concise     | (<session_det_fqdn> CERT             |(Concise      |
   |Attestation: | <attestation_ridr_session>)          |Attestation:  |
     +---------------+---------------+---------------+---------------+

     Length = 504-bytes
                   Figure 8: DRIP Attestation Certificate

3.3.2.  Concise Certificate (CC-zxy)

      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
     +---------------+---------------+---------------+---------------+
   |Operator, UA)|                                      |RIDR,         |
   |             |                          Hierarchical                                      |Operator)     |
   +-------------+--------------------------------------+--------------+
   |(Mutual      |                    Host Identity Tag of Z (<session_det_fqdn> CERT             |(Mutual       |
   |Attestation: | <concise_attestation_ridr_session>)  |Certificate:  |
     +---------------+---------------+---------------+---------------+
   |Operator, UA)|                                      |RIDR,         |
   |
     .                                                               .
     .                             CA-xy                             .
     .                                                               .             |                                      |Operator, UA) |
     +---------------+---------------+---------------+---------------+
   +-------------+--------------------------------------+--------------+
   |(Link        |                      Trust Timestamp by Z                                      |(Concise      |
     +---------------+---------------+---------------+---------------+
   |Attestation: |                     Signing Timestamp by Z                                      |Certificate:  |
     +---------------+---------------+---------------+---------------+
   |Operator, UA)|                                      |RIDR,         |
   |             |                                      |Operator, UA) |
   +-------------+--------------------------------------+--------------+
   |(Operational |                                      |(Link         |
   |Intent)      |                                      |Certificate:  |
   |             |                                      |RIDR,         |
   |             |                                      |Operator, UA) |
   +-------------+--------------------------------------+--------------+
   |                         Signature by Z             |                                      |(Broadcast    |
   |             |                                      |Attestation:  |
   |             |                                      |RAA, RIDR)    |
   +-------------+--------------------------------------+--------------+
   |             |                                      |(Broadcast    |
   |             |                                      |Attestation:  |
   |             |                                      |Root, RAA)    |
     +---------------+---------------+---------------+---------------+

     Length = 192-bytes

                     Figure 9: DRIP Concise Certificate

3.3.3.  Link Certificate (LC-zxy)
      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
   +-------------+--------------------------------------+--------------+

                                  Table 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |                                                               |

6.4.1.  Standard Provisioning

   Under standard provisioning the Aircraft has its own connectivity to
   the registry, the method which is out of scope for this document.

             +----------+
             |                          Hierarchical Registry |
             +----------+
                 ^
                 |                    Host Identity Tag of Z
                 |
                 |  A-ro, A-oaN
                 |
     +---------------+---------------+---------------+---------------+
                 |
             +----------+                        +----------+
             |
     .                                                               .
     .                             LA-xy                             .
     .                                                               . Operator | <--------------------- |
     +---------------+---------------+---------------+---------------+ Aircraft |                      Trust Timestamp
             +----------+        A-a0aN          +----------+

                    Figure 4: Standard Provision: Step 1

   Through mechanisms not specified in this document the Operator should
   have methods to instruct the Aircraft onboard systems to generate a
   keypair and certificate.  This certificate is chained to the factory
   provisioned certificate (Self-Attestation: Aircraft 0 on Aircraft 0
   [SA-a0a0]).  This new attestation (Attestation: Aircraft 0 on
   Aircraft N [A-a0aN]) is securely extracted by Z                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp the Operator.

   With A-a0aN the sub-attestation (Self-Attestation: Aircraft N on
   Aircraft N [SA-aNaN]) is used by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               | the Operator to generate
   Attestation: Operator on Aircraft N (A-oaN).  This along with
   Attestation: Registry on Operator (A-ro) is sent to the registry.

             +----------+
             | Registry |
             +----------+
                 |
                 |
                 |
                 |  Token
                 |
                 v
             +----------+                        +----------+
             | Operator | ---------------------> | Aircraft |
             +----------+        Token           +----------+

                    Figure 5: Standard Provision: Step 2

   On the registry, A-ro is verified and used as confirmation that the
   Operator is already registered.  A-oaN also undergoes a validation
   check and used to generate a token to return to the Operator to
   continue provisioning.

   Upon receipt of this token, the Operator injects it into the Aircraft
   and its used to form a secure connection to the registry.  The
   Aircraft then sends Attestation: Manufacturer on Aircraft 0 (A-ma0)
   and Attestation: Aircraft 0 to Aircraft N (A-a0aN).

        +---------+
        | HDA DNS |                         Signature by Z
        +---------+
            ^
            |
            | HIP RR
            |
            |
            |
        +----------+ <----------------------------+
        | Registry |                              |
        +----------+ ------------------------+    |
            |                                |    |
            |                                |    |  Token,
            |  AC-roaN               BA-raN  |
     +---------------+---------------+---------------+---------------+

     Length = 300-bytes

                      Figure 10: DRIP Link Certificate

3.3.4.  Mutual Certificate (MC-zxy)
      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
     +---------------+---------------+---------------+---------------+    |  A-ma0, A-a0aN
            |
     .                                                               .
     .                             SA-zz                             .
     .                                                               .                                |    |
     +---------------+---------------+---------------+---------------+
            |                                |
     .                                                               .
     .                             MA-xy                             .
     .                                                               .    |
            v                                v    |
     +---------------+---------------+---------------+---------------+
        +----------+                      +----------+
        |                      Trust Timestamp by Z Operator |
     +---------------+---------------+---------------+---------------+                      |                     Signing Timestamp by Z Aircraft |
     +---------------+---------------+---------------+---------------+
        +----------+                      +----------+

                    Figure 6: Standard Provision: Step 3

   The registry uses Attestation: Manufacturer on Aircraft 0 (with an
   external database if supported) to confirm the validity of the
   Aircraft.  Attestation: Aircraft 0 on Aircraft N is correlated with
   Attestation: Operator on Aircraft N and Attestation: Manufacturer on
   Aircraft 0 to see the chain of ownership.  The new DET tied to
   Aircraft N is then checked for collisions in the HDA.  With the
   information the registry generates two items: Attestation
   Certificate: Registry on Operator on Aircraft N (AC-roaN) and
   Broadcast Attestation: Registry on Aircraft N (BA-raN).  A HIP RR
   (and other RR types as needed) are generated and inserted into the
   HDA.

   AC-roaN is sent via a secure channel back to the Operator to be
   stored.  BA-raN is sent to the Aircraft to be used in Broadcast RID
   as specified in [drip-auth].

6.4.2.  Operator Assisted Provisioning

   This provisioning scheme is for when the Aircraft is unable to
   connect to the registry itself or does not have the hardware required
   to generate keypairs and attestations.

             +----------+
             | Registry |
             +----------+

             +----------+                        +----------+
             | Operator | ---------------------> | Aircraft |
             +----------+     aN, SA-aNaN        +----------+

               Figure 7: Operator Assisted Provision: Step 1

   To start the Operator generates on behalf of the Aircraft a new
   keypair and Attestation: Aircraft N on Aircraft N (SA-aNaN).  This
   keypair and certificate are injected into the Aircraft for it to
   generate Attestation: Aircraft 0 on Aircraft N (A-a0aN).  After
   injecting the keypair and certificate, the Operator MUST destroy all
   copies of the keypair.

             +----------+
             | Registry |
             +----------+
                 ^
                 |
                 |
                 |  A-ro, A-ma0, A-a0aN, A-oaN
                 |
                 |
             +----------+                        +----------+
             | Operator | <--------------------- | Aircraft |                         Signature
             +----------+      A-ma0, A-a0aN     +----------+

               Figure 8: Operator Assisted Provision: Step 2

   Attestation: Manufacturer on Aircraft 0 (A-ma0) and Attestation:
   Aircraft 0 on Aircraft N (A-a0aN) is extracted by Z                        |
     |                                                               |
     | the Operator and
   the following data items are sent to the Registry; Attestation:
   Registry on Operator (A-ro), Attestation: Manufacturer on Aircraft 0
   (A-ma0), Attestation: Aircraft 0 on Aircraft N (A-a0aN), Attestation:
   Operator on Aircraft N (A-oaN).

             +----------+            +---------+
             | Registry | ---------> | HDA DNS |
             +----------+   HIP RR   +---------+
                 |
                 |
                 |
                 |  AC-roaN, BA-raN
                 |
                 v
             +----------+                        +----------+
             | Operator | ---------------------> | Aircraft |
     +---------------+---------------+---------------+---------------+

     Length = 576-bytes
             +----------+        BA-raN          +----------+

               Figure 11: DRIP Mutual Certificate

4.  Registries

4.1.  Classes

   Under DRIP there 9: Operator Assisted Provision: Step 3 classes

   On the registry validation checks are done on all attestations as per
   the previous sections.  Once complete then the registry checks for a
   DET collision, adding to the HDA if clear and generates Attestation
   Certificate: Registry on Operator on Aircraft N (AC-roaN) and
   Broadcast Attestation: Registry on Aircraft N (BA-raN).  Both are
   sent back to the Operator.

   The Operator securely inject BA-raN and securely stores AC-roaN of
   Aircraft N.

6.4.3.  Initial Provisioning

   A special form of provisioning is used when the Aircraft is first
   sold to an Operator.  Instead of generating a new keypair, the built
   in keypair and certificate done by the Manufacturer is used to
   provision and register the aircraft to the owner.

   For this either Standard or Operator Assisted methods can be used.

7.  EPP Command Mappings

7.1.  Common Attributes

   There are a number of registries, with common attributes between the various EPP
   commands under DRIP that has specific variants in
   each.

4.1.1.  Root

   This encoding rules.

   *  The hi attribute is a special registry holding Base64 encoding of the RAA value Host Identity.

   *  The det attribute is a string from of 0 and HDA value the DET.

7.2.  EPP Query Commands

7.2.1.  EPP <check> Command

7.2.1.1.  Registry

7.2.1.2.  Operator

7.2.1.3.  Aircraft Serial Number

7.2.1.4.  Aircraft Session ID

7.2.2.  EPP <info> Command

7.2.2.1.  Registry

7.2.2.2.  Operator

7.2.2.3.  Aircraft Serial Number

7.2.2.4.  Aircraft Session ID

7.2.3.  EPP <transfer> Command

   Transfer semantics do not apply in DRIP, so there is no mapping
   defined for the EPP <transfer> command.

7.3.  EPP Transform Commands

7.3.1.  EPP <create> Command

7.3.1.1.  Registry

   The abbreviation field has a max of 0.  It delegates out RAA values only to registries that wish 6 characters, and is used by RID
   receivers to
   act as an RAA.

   (Editors Note: we contemplate display a short decoded form for display of a received
   DET in the form of {RAA Abbreviation} {HDA Abbreviation} {Last 4 of
   DET Hash}. An example of this would be US FAA FE23.  If the
   abbreviation is ICAO running this server or
   federation unknown then the receiver SHOULD use the hexadecimal
   encoding of them)

4.1.2.  Registered Assigning Authorities

   RAA's are the upper hierarchy respective RAA/HDA field of the HID as the value in DRIP.  Most are contemplated to be
   Civil Aviation Authorities (CAAs) then delegate HDAs to manage their
   NAS.  This is does not preclude other entities to operate an RAA
   the form.  For example if the Root server allows it.

   All RAA's use an HDA value of 0 is unknown and have their RAA the HDA value delegated is 20
   then the decoded display would be: DE 14 FE23.  Typically for RAAs
   the abbreviation is RECOMMENDED to be set to
   them by the Root.

4.1.2.1.  ICAO Registry ISO 3166 country
   code (either Alpha-2 or Alpha-3) for the CAA.  Dashes or underscores
   should be used in place of Manufacturer's (IRM)

   A special RAA that hands out HDA values to participating
   Manufacturer's that hold spaces.

   The mfrCode field is only used by an MRA (Section 3.1.3.1) when
   registering with an IRM (Section 3.1.2.1) and holds the ICAO assigned
   Manufacturer Code used in for ANSI CTA2063-A Serial Numbers.  It is holds the RAA value of 1 and HDA value of 0.

   (Editors Note: we contemplate this is ICAO running this server or
   federation of them)

4.1.3.  Hierarchial HIT Domain Authorities

4.1.3.1.  Manufacturer's Registry of Aircraft (MRA)

   A registry (HDA) run by has a manufacturer max of UAS systems that
   participate in Remote ID.  Stores UAS
   4 characters.

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <dripRegistry:create xmlns:dripRegistry="urn:ietf:params:xml:ns:dripRegistry-1.0">
        <dripRegistry:det>2001:0030:00a0:0145:a3ad:1952:0ad0:a69e</dripRegistry:det>
        <dripRegistry:hi></dripRegistry:hi>
        <dripRegistry:raa>10</dripRegistry:raa>
        <dripRegistry:hda>20</dripRegistry:hda>
        <dripRegistry:abbreviation>FAA</dripRegistry:abbreviation>
        <dripRegistry:mfrCode>MFR0</dripRegistry:mfrCode>
        <dripRegistry:postalInfo type="int">
          <dripRegistry:name>Federal Aviation Administration</dripRegistry:name>
          <dripRegistry:phys_addr>
            <dripRegistry:street1>Orville Wright Federal Building</dripRegistry:street1>
            <dripRegistry:street2>800 Independence Avenue SW</dripRegistry:street2>
            <dripRegistry:city>Washington</dripRegistry:city>
            <dripRegistry:sp>DC</dripRegistry:sp>
            <dripRegistry:pc>20591</dripRegistry:pc>
            <dripRegistry:cc>US</dripRegistry:cc>
          </dripRegistry:phys_addr>
        </dripRegistry:postalInfo>
        <dripRegistry:voice x="1234">1 (866) 835-5322</dripRegistry:voice>
        <dripRegistry:email>stephen.dickson@faa.gov</dripRegistry:email>
      </dripRegistry:create>
    </create>
    <clTRID>ADD-REGIS</clTRID>
  </command>
</epp>

7.3.1.2.  Operator

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <dripOperator:create xmlns:dripOperator="urn:ietf:params:xml:ns:dripOperator-1.0">
        <dripOperator:postalInfo type="int">
          <dripOperator:name>John Doe</dripOperator:name>
          <dripOperator:phys_addr>
            <dripOperator:street1>123 Example Dr.</dripOperator:street1>
            <dripOperator:street2>Suite 100</dripOperator:street2>
            <dripOperator:city>Dulles</dripOperator:city>
            <dripOperator:sp>VA</dripOperator:sp>
            <dripOperator:pc>20166-6503</dripOperator:pc>
            <dripOperator:cc>US</dripOperator:cc>
          </dripOperator:phys_addr>
          <dripOperator:ma_addr>
            <dripOperator:street1>123 Example Dr.</dripOperator:street1>
            <dripOperator:street2>Suite 100</dripOperator:street2>
            <dripOperator:city>Dulles</dripOperator:city>
            <dripOperator:sp>VA</dripOperator:sp>
            <dripOperator:pc>20166-6503</dripOperator:pc>
            <dripOperator:cc>US</dripOperator:cc>
          </dripOperator:ma_addr>
        </dripOperator:postalInfo>
        <dripOperator:voice x="1234">+1.7035555555</dripOperator:voice>
        <dripOperator:email>jdoe@example.com</dripOperator:email>
        <dripOperator:part107_acct_name>some_faa_account</dripOperator:part107_acct_name>
        <dripOperator:rec_flyer_id>123456</dripOperator:rec_flyer_id>
        <dripOperator:caaId></dripOperator:caaId>
        <dripOperator:det></dripOperator:det>
        <dripOperator:hi></dripOperator:hi>
      </dripOperator:create>
    </create>
    <clTRID>ADD-OPER</clTRID>
  </command>
</epp>

7.3.1.3.  Aircraft Serial Numbers under a specific
   ICAO Manufacturer Code (assigned to the manufacturer by ICAO).

   A DET can be encoded into a Number

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <dripSerial:create xmlns:dripSerial="urn:ietf:params:xml:ns:dripSerial-1.0">
        <dripSerial:serial>0000F000000000000000</dripSerial:serial>
        <dripSerial:det></dripSerial:det>
        <dripSerial:hi></dripSerial:hi>
        <dripSerial:manufacturer>Drones R Us</dripSerial:manufacturer>
        <dripSerial:make>Fast Drone</dripSerial:make>
        <dripSerial:model>9000</dripSerial:model>
        <dripSerial:color>White</dripSerial:color>
        <dripSerial:material>Plastic</dripSerial:material>
        <dripSerial:weight>12.0</dripSerial:weight>
        <dripSerial:length>5.0</dripSerial:length>
        <dripSerial:width>4.0</dripSerial:width>
        <dripSerial:height>3.0</dripSerial:height>
        <dripSerial:numRotors>4</dripSerial:numRotors>
        <dripSerial:propLength>2.0</dripSerial:propLength>
        <dripSerial:batteryCapacity>5000</dripSerial:batterCapacity>
        <dripSerial:batteryVoltage>12</dripSerial:batteryVoltage>
        <dripSerial:batteryWeight>5.2</dripSerial:batteryWeight>
        <dripSerial:batteryChemistry>Lithium-Ion</dripSerial:batteryChemistry>
        <dripSerial:takeOffWeight>15</dripSerial:takeOffWeight>
        <dripSerial:maxTakeOffWeight>25</dripSerial:maxTakeOffWeight>
        <dripSerial:maxPayloadWeight>10</dripSerial:maxPayloadWeight>
        <dripSerial:maxFlightTime>15</dripSerial:maxFlightTime>
        <dripSerial:minOperatingTemp>35</dripSerial:minOperatingTemp>
        <dripSerial:maxOperatingTemp>90</dripSerial:maxOperatingTemp>
        <dripSerial:ipRating>55</dripSerial:ipRating>
      </dripSerial:create>
    </create>
    <clTRID>ADD-AIRCRFT</clTRID>
  </command>
</epp>

7.3.1.4.  Aircraft Session ID

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <dripSession:create xmlns:dripSession="urn:ietf:params:xml:ns:dripSession-1.0">
        <dripSession:serial>0000F000000000000000</dripSession:serial>
        <dripSession:uasId></dripSession:uasId>
        <dripSession:sessionHi></dripSession:sessionHi>
        <dripSession:operationalIntent></dripSession:operationalIntent>
        <dripSession:operationalIntentSrc>uss.example.com</dripSession:operationalIntentSrc>
        <dripSession:operatorId>NOP123456</dripSession:operatorId>
        <dripSession:operatorDet></dripSession:operatorDet>
        <dripSession:fa3>N1232456</dripSession:fa3>
      </dripSession:create>
    </create>
    <clTRID>ADD-SID</clTRID>
  </command>
</epp>

7.3.2.  EPP <delete> Command

7.3.2.1.  Registry

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <dripRegistry:delete xmlns:dripRegistry="urn:ietf:params:xml:ns:dripRegistry-1.0">
        <dripRegistry:det>2001:0030:00a0:0145:a3ad:1952:0ad0:a69e</dripRegistry:det>
      </dripRegistry:delete>
    </delete>
    <clTRID>DEL-REGIS</clTRID>
  </command>
</epp>

7.3.2.2.  Operator

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <dripOperator:delete xmlns:dripOperator="urn:ietf:params:xml:ns:dripOperator-1.0">
        <dripOperator:caaId></dripOperator:caaId>
        <dripOperator:det></dripOperator:det>
      </dripOperator:delete>
    </delete>
    <clTRID>DEL-OPER</clTRID>
  </command>
</epp>

7.3.2.3.  Aircraft Serial Number (Editor Note: link to -uas-
   rid) and when done

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <dripSerial:delete xmlns:dripSerial="urn:ietf:params:xml:ns:dripSerial-1.0">
        <dripSerial:serial>0000F000000000000000</dripSerial:serial>
      </dripSerial:delete>
    </delete>
    <clTRID>DEL-AIRCRFT</clTRID>
  </command>
</epp>

7.3.2.4.  Aircraft Session ID

   Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <dripSession:delete xmlns:dripSession="urn:ietf:params:xml:ns:dripSession-1.0">
        <dripSession:uasId></dripSession:uasId>
      </dripSession:delete>
    </delete>
    <clTRID>DEL-SID</clTRID>
  </command>
</epp>
7.3.3.  EPP <renew> Command

   Renewal semantics do not apply in DRIP, so this registry would hold a there is no mapping from
   defined for the EPP <renew> command.

7.3.4.  EPP <transfer> Command

   Transfer semantics do not apply in DRIP, so there is no mapping
   defined for the EPP <transfer> command.

7.3.5.  EPP <update> Command

7.3.5.1.  Registry

7.3.5.2.  Operator

7.3.5.3.  Aircraft Serial Number to the

7.3.5.4.  Aircraft Session ID

8.  RDAP Definitions

9.  IANA Considerations

10.  Security Considerations

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

   1  The entity generates its artifacts.

   Hold own DET, discovering and using the RAA value of 1
      and HDA values of 1+.

4.1.3.2.  Remote ID Registries (RIDR)

   Registry that holds for the binding between target registry.  The method for discovering a UAS Session ID (for DRIP
   the DET)
      registry's RAA and HDA is out of scope here.  This allows for the UA Serial Number.  The Serial Number MUST have its
   access protected
      device to allow only authorized parties generate an DET to send to the registry to be accepted
      (thus generating the required Self-Attestation) or denied.

   2  The entity sends to the registry its HI for it to obtain.  The
   Serial Number SHOULD be encrypted hashed and
      result in a way only the authorized party
   can decrypt.

   As part of DET.  The registry would then either accept
      (returning the UTM system they also hold a binding between a UAS ID
   (Serial Number DET to the device) or Session ID) and an Operational Intent.

   (Editors Note: these deny this pairing.

   Keypairs are contemplated expected to be part of a USS as a
   function or a standalone SDSP in generated on the UTM system)

   Hold RAA values of 2+ and HDA values of 1+.

4.2.  Federation

   (Editors Note: device hardware it will
   be used on.  Due to nature of HHIT we could have multiple
   registries with same RAA/HDA pairings running hardware limitations (see Section 10) and being federated
   together.  How do we handle this?)

5.  DRIP Fully Qualified Domain Names

   Under
   connectivity it is acceptable under DRIP there are a number of FQDN forms used to allow lookups to
   take place.

   (Editor Note: copy generate keypairs for the
   Aircraft on Operator devices and later securely inject them into the
   Aircraft (as defined in DET Section 5 here)

5.1.  Serial Number

   Serial Number: 8653FZ2T7B8RA85D19LX
   ICAO Mfr Code: 8653
   Length Code: F
   ID: FZ2T7B8RA85D19LX
   FQDN: Z2T7B8RA85D19LX.F.8653.mfr.uas.icao.int

5.2.  Reverse SN

   (Editors Note: convert SN 6.4.2).  The methods to DET format then perform reverse DET?)

5.3.  DET
   DET: 2001:0030:00a0:0145:a3ad:1952:0ad0:a69e
   ID: a3ad:1952:0ad0:a69e
   OGA: 5
   HDA: 0014 = 20
   RAA: 000a = 10
   Prefix: 20010030
   FQDN: a3ad19520ad0a69e.5.20.10.20010030.det.uas.icao.int

   When building securely
   inject and store keypair information in a DET FQDN "secure element" of the
   Aircraft is out of scope of this document.

   In either case the registry must decide on if the HI/DET pairing is
   valid.  This in its simplest form is checking the current registry
   for a collision on the following two things must be done:

   1.  The RAA DET and HDA values HI.

   Upon accepting a HI/DET pair the registry MUST be converted from hexadecimal to
       decimal form

   2.  The FQDN must be built using populate the expanded form of required
   the IPv6
       address DNS serving the HDA with the HIP RR and other relevant RR types
   (such as TXT and CERT).  The prefix is included in registry MUST also generate the FQDN form to support
   appropriate attestations/certificates for the given operation.

   If the registry denied the HI/DET pair, because there was a DET
   collision or any other potential
   prefixes reason, the registry MUST signal back to the
   device being used.

5.4.  Reverse DET

   $ORIGIN  5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
   e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a    IN   PTR

6.  Supported DNS Records

   DRIP requires provisioned that a number of resource records, some specific to certain
   registries new HI needs to function.

6.1.  HIP RR

   All registries will have their own DET associated be generated.

11.  Contributors

   *  Scott Hollenbeck for his guidance with them and their
   respective DNS server will hold EPP/RDAP

   *  Andrei Gurtov for his insights as a HIP RR that is pointed pilot

12.  References

12.1.  Normative References

   [F3411-19] "Standard Specification for Remote ID and Tracking",
              February 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to by their
   DET FQDN.

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

12.2.  Informative 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-20, 28 January 2022,
              <https://www.ietf.org/archive/id/draft-ietf-drip-arch-
              20.txt>.

   [drip-auth]
              Wiethuechter, A., Card, S., and RIDR servers will also have HIP RRs R. Moskowitz, "DRIP
              Authentication Formats & Protocols for their registered
   parties (aircraft Broadcast Remote
              ID", Work in Progress, Internet-Draft, draft-ietf-drip-
              auth-04, 20 December 2021,
              <https://www.ietf.org/archive/id/draft-ietf-drip-auth-
              04.txt>.

   [drip-requirements]
              Card, S. W., Wiethuechter, A., Moskowitz, R., and operators).

6.2.  CERT RR

   Most attestations can be placed into DNS.  An exception to this is
   the AttestationCertificate made during Session ID registration.

6.3.  NS RR

   Along with their associated "glue" record (A/AAAA) supports the
   traversal A.
              Gurtov, "Drone Remote Identification Protocol (DRIP)
              Requirements and Terminology", Work in DNS across the tree.

   1.  <mfr.remoteid.aero> on Root points to specific DET FQDN of IRM

   2.  <icao_mfr_code>.mfr.remoteid.aero on IRM points to specific DET
       FQDN of MRA

   3.  <raa_value>.det.remoteid.aero on Root pointing to DET FQDN Progress, Internet-
              Draft, draft-ietf-drip-reqs-18, 8 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-drip-reqs-
              18.txt>.

   [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
              Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
              draft-ietf-drip-uas-rid-01, 9 September 2020,
              <https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
              01.txt>.

   [hhit-registries]
              Moskowitz, R., Card, S. W., and A. Wiethuechter,
              "Hierarchical HIT Registries", Work in Progress, Internet-
              Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
              2020, <https://www.ietf.org/archive/id/draft-moskowitz-
              hip-hhit-registries-02.txt>.

   [NPRM]     "Notice of
       matching RAA

   4.  <hda_value>.<raa_value>.det.remoteid.aero Proposed Rule Making on RAA Registry
       pointing to DET FQDN of matching HDA

6.4.  AAAA RR

   DRIP requires the use of IPv6.

6.5.  SVR RR

   TODO - points to server for RDAP stuff

6.6.  TLSA RR

   Raw key format here; for DTLS support.  RFC6698

7.  Registry Operations

   (Editors Note: General processing instructions here?)

   As a general rule the following processing performed for any
   registration operation:

   1.  Verify SelfAttestation Remote Identification
              of registering party

   2.  Populate DNS with required/optional records

   3.  Populate Database with PII Unmanned Aircraft Systems", December 2019.

   [RFC7519]  Jones, M., Bradley, J., and other info

   4.  Generate N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and return required/optional H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

Appendix A.  DRIP Attestations

7.1.  Registering an RAA

   Specifically handled by the Root Registry (Section 4.1.1).

7.1.1.  Inputs

   Required:

   1.  SelfAttestation of RAA
   2.  IP Address & Certificates

   See [drip-arch] for definitions of RAA

7.1.2.  DNS Entries

   Required on Root:

   NS RR = <raa_value>.det.remoteid.aero NS <raa_det_fqdn>

   AAAA RR = <raa_det_fqdn> AAAA ...

   CERT RR = ???

   Required on RAA:

   HIP RR = <raa_det_fqdn> HIP ...

   CERT RR = ???

7.1.3.  Database Entries

7.1.4.  Outputs

7.2.  Registering an IRM

   Specifically handled by claim, assertion, attestation and
   certificate as used in this document.

A.1.  Attestation Structure

   All Attestations (Appendix A.2) and Certificates (Appendix A.3) under
   DRIP share the Root Registry (Section 4.1.1).

7.2.1.  Inputs

   Required:

   1.  Self-Attestation of IRM

   2.  IP Address of IRM

7.2.2.  DNS Entries

   Required on Root:

   NS RR = mfr.remoteid.aero NS <irm_det_fqdn>

   NS RR = 1.det.remoteid.aero NS <irm_det_fqdn>

   AAAA RR = <irm_det_fqdn> AAAA ...

   CERT RR = ???

   Required on IRM:

   HIP RR = <irm_det_fqdn> HIP ...

   CERT RR = ???

7.2.3.  Database Entries

7.2.4.  Outputs

   Required:

   1.  Attestation: Root on IRM

7.3.  Registering an HDA

   Specifically handled following format structure:

    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
   +---------------+---------------+---------------+---------------+
   |                                                               |
   .                                                               .
   .                 Attestor Identity Information                 .
   .                                                               .
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   .                                                               .
   .                       Attestation Data                        .
   .                                                               .
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |               Expiration Timestamp by an RAA (Section 4.1.2).

7.3.1.  Inputs

   Required:

   1.  Self-Attestation of HDA

   2.  IP Address of HDA

7.3.2.  DNS Entries

   Required on RAA:

   NS RR = <hda_value>.<raa_value>.det.remoteid.aero NS <hda_det_fqdn>

   AAAA RR = <hda_det_fqdn> AAAA ...

   CERT RR = ???

   Required on HDA:

   HIP RR = <hda_det_fqdn> HIP ...

7.3.3.  Database Entries

7.3.4.  Outputs

7.4.  Registering an MRA

   Specifically handled Attestor                |
   +---------------+---------------+---------------+---------------+
   |                 Signing Timestamp by the IRM Registry (Section 4.1.2.1).

7.4.1.  Inputs

   Required:

   1.  ICAO Manufacturer Code

   2.  Self-Attestation of MRA

   3.  IP Address Attestor                 |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                     Signature by Attestor                     |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +---------------+---------------+---------------+---------------+

   Attestor Identity Information: (0, 16-bytes or 120-bytes)
       Field containing Attestor Identity Information in various forms.

   Attestation Data:
       A field of MRA

7.4.2.  DNS Entries

   Required on IRM:

   NS RR = <icao_mfr_code>.mfr.remoteid.aero NS <mra_det_fqdn>

   NS RR = <hda_value>.1.det.remoteid.aero NS <mra_det_fqdn>

   AAAA RR = <mra_det_fqdn> AAAA ...

   CERT RR = ???

   Required on MRA:

   HIP RR = <mra_det_fqdn> HIP ...

   CERT RR = ???

7.4.3.  Database Entries

   (HDA value, MRA Details)

7.4.4.  Outputs

   Required:

   1.  Attestation: IRM on MRA

7.5.  Registering a Serial Number

   Specifically handled variable length containing the attestation data.

   Expiration Timestamp by a MRA (Section 4.1.3.1).

7.5.1.  Inputs

   Required:

   1.  Serial Number
   2.  Aircraft Metadata

   Optional:

   1.  SelfAttestation: Aircraft on Aircraft (if DET encoded)

7.5.2.  DNS Entries

   Required on MRA:

   A/AAAA with Serial Number FQDN (Section 5.1)

   Optional on MRA:

   HIP RR Attestor (4 bytes):
       Timestamp denoting recommended time to trust data to.

   Signing Timestamp by Attestor (4 bytes):
       Current time at signing.

   Attestor Signature (64 bytes):
       Signature over preceding fields using the keypair of Aircraft with DET FQDN (Section 5.3) (<sn_det_fqdn> HIP
   ...)

   CERT RRs
       the Attestor.

                      Figure 10: Attestation Structure

A.1.1.  Attestor Identity Information

   This can be either of SelfAttestation and BroadcastAttestation

7.5.3.  Database Entries

   (Serial Number, [DET], Metadata, [SelfAttestation])

7.5.4.  Outputs

   Optional:

   1.  BroadcastAttestation: Mfr on Aircraft

7.6.  Registering an Operator

   Specifically handled by a RIDR (Section 4.1.3.2).

7.6.1.  Inputs

   Required: the following:

   1.  SelfAttestation: Operator on Operator  Attestor DET: 16-bytes

   2.  Operator PII

   Optional: TODO

7.6.2.  DNS Entries

   Optional on RIDR:

   HIP RR of Operator
   CERT RRs SelfAttestation  Attestor Self-Attestation: 120-bytes

   A specific definition of Operator, A-ro

7.6.3.  Database Entries

   TODO

7.6.4.  Outputs

   Required:

   1. an Attestation (A-ro) - using SA-rr and SA-oo

   Optional:

   1.  ConciseAttestation (CA-ro) - using SA-oo

   2.  BroadcastAttestation (BA-ro) - using SA-oo

7.7.  Registering a Session ID

   Specifically handled by a RIDR (Section 4.1.3.2).

7.7.1.  Inputs

   Required:

   1.  Attestation: Registry on Operator

   2.  Attestation: Operator on Aircraft

   3.  UAS Serial Number

   Optional:

   1.  ConciseAttestation: Operator on Aircraft

   2.  MutualAttestation: Operator on Aircraft

   3.  LinkAttestation: Operator on Aircraft

   4.  Operational Intent ID (GUFI)

7.7.2.  DNS Entries

   Required on RIDR:

   HIP RR (Appendix A.2) or Certificate
   (Appendix A.3) defines which of Aircraft with DET FQDN (Section 5.3) (<session_det_fqdn>
   HIP ...)
   CERT RRs for SelfAttestation these are used.

A.1.2.  Attestation Data

   The data being attested to.  It can be one of Aircraft, BroadcastAttestation

7.7.3.  Database Entries

   (Session ID, Serial Number, GUFI, A-oa, BA-ra, AC-roa)

7.7.4.  Outputs

   Required:

   1.  BroadcastAttestation (BA-ra) - generated using the embedded SA-aa
       from A-oa

   2.  AttestationCertificate (AC-roa) - using A-oa

   Optional: following forms:

   1.  MutualCertificate (MC-roa) - using MA-oa  Claims

   2.  ConciseCertificate (CC-roa) - using CA-oa  Assertions

   3.  LinkCertificate (LC-roa) - using LA-oa

   4.  BroadcastAttestation's of parent Registries in chain

8.  Provisioning

   Under DRIP UAS RID a special provisioning procedure  Attestations

   This field is required to
   properly generate and distribute the certificates and attestations to
   all parties in the USS/UTM ecosystem using DRIP RID.

   Keypairs are expected to be generated on the device hardware it will
   be used on.  Due to hardware limitations (see Section 10) variable length with no limit and
   connectivity it is acceptable under DRIP RID to generate keypairs for specific definitions
   of an Attestation (Appendix A.2) or Certificate (Appendix A.3)
   indicate the Aircraft on Operator devices and later securely inject them fields, size and ordering of any subfields.

A.1.3.  Expiration Timestamp

   A UTC timestamp set some time into the Aircraft (as defined in Section 8.6.2).  The methods future to securely
   inject and store keypair information in indicate a "secure element" of point the
   Aircraft
   Attestation Structure should not be trusted.

   The time delta into the future is out of scope of this document.

8.1.  Overview of Transactions

   In DRIP, each Operator MUST generate a Host Identity of important concern as replay
   attacks on during flight could compromise the Operator
   (HIo) and derived Hierarchical HIT goals of DRIP.
   Attestations and certificates intended for public use and lower in
   the Operator (HHITo).  These
   are registered with tree (importantly any generated for a Private Information Registry along Session ID (Section 6.4)).

   For this reason deltas SHOULD be kept as short as possible for the
   given use-case to avoid issues with
   whatever Operator data (inc.  PII) is required by replays.

A.1.4.  Signing Timestamp

   A UTC timestamp set to the cognizant CAA
   and time when the registry.  In response, Attestation Structure was
   signed.

A.1.5.  Signature

   An EdDSA25519 signature using the Operator will obtain signing parties private key over
   the preceding fields in the Attestation Structure.

         Note: the preceding fields of the Attestation Structure
         actually form an Assertion, with all fields acting as Claims

A.2.  Attestations

A.2.1.  Self-Attestation (SA-x)

   The only attestation from to use a claim (the Host Identity) in the Registry, Attestation: Registry on Operator
   (A-ro), signed
   Attestation Data with the Host Identity of DET acting as the Registry private key
   (HIr(priv)) proving such registration.

   An Operator may now claim one or more UA.

   *  An Operator MUST generate a Attestor Identity
   Information.

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                              DRIP                             |
     |                           Entity Tag                          |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                          Host Identity                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                         Trust Timestamp                       |
     +---------------+---------------+---------------+---------------+
     |                        Signing Timestamp                      |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                            Signature                          |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 120-bytes

                      Figure 11: DRIP Self-Attestation

A.2.2.  Attestation (A-x.y)

   The standard first level DRIP Attestation form using a Self-
   Attestations of the Aircraft (HIa) signer and derived Hierarchical HIT of the Aircraft (HHITa)

   *  Create an attestation from the Operator on the Aircraft (A-oa)
      signed with the Host Identity of the Operator private key
      (HIo(priv)) to associate the UA with its Operator

   *  Register them with a Private Information Registry along with
      whatever UAS data is required being signed.

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             SA-xx                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             SA-yy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by the cognizant CAA X                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 312-bytes

                        Figure 12: DRIP Attestation

A.2.3.  Concise Attestation (CA-x.y)

   In constrained environments and Registry

   *  Obtain an attestation from the Registry on when there is the Operator and
      Aircraft ("AC-roa") signed with guarantee of being
   able to lookup the HIr(priv) proving such
      registration

   *  And DETs to obtain a broadcast HIs this attestation from the Registry on the
      Aircraft (BA-ra) signed with HIr(priv) proving UA registration in
      that specific registry while preserving Operator privacy.

   The operator then MUST provision the UA with HIa, HIa(priv), HHITa
   and B-Ara.

   *  UA engaging in Broadcast RID MUST use HIa(priv) to sign
      Authentication Messages and MUST periodically broadcast BA-ra.

   *  UAS engaging in Network RID MUST use HIa(priv) to sign
      Authentication Messages.

   *  Observers MUST use HIa from received BA-ra to verify received
      Broadcast RID Authentication messages.

   *  Observers without Internet connectivity MAY use BA-ra to identify
      the trust class can be used.

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP                              |
     |                        Entity Tag of the UAS based on known registry vetting.

   *  Observers with Internet connectivity MAY use HHITa to perform
      lookups in the Public Information Registry and MAY then query the
      Private Information Registry which MUST enforce AAA policy on
      Operator PII and other sensitive information

8.2.  HHIT Delegation

   Under the FAA [NPRM], it is expecting X                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP                              |
     |                        Entity Tag of Y                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by X                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 104-bytes

                    Figure 13: DRIP Concise Attestation

A.2.4.  Mutual Attestation (MA-x.y)

   An attestation 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.

   1  The entity generates its own HHIT, discovering and using thr RAA
      and HDA for the target Registry.  The method for discovering perform a
      Registry's RAA and HDA is out of scope here.  This allows for the
      device to generate sign over an HHIT to send to the Registry to be accepted
      (thus generating existing Attestation where
   the required Host Identity Claim) or denied.

   2  The entity sends to signer is the Registry its HI for it to be hashed and
      result in second party of the HHIT. embedded attestation.  The Registry would then either accept
      (returning the HHIT to the device) or deny this pairing.

   In either case the Registry must decide on if the HI/HHIT pairing is
   valid.  This in its simplest form DET
   of party Y is checking the current Registry
   for a collision on used as the HHIT.

   Upon accepting Attestor Identity Information
   (Appendix A.1.1).

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP                              |
     |                        Entity Tag of Y                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              A-xy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Y                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Y                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Y                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 400-bytes

                     Figure 14: DRIP Mutual Attestation

A.2.5.  Link Attestation (LA-x.y)

   An attestations that perform a HI/HHIT pair the Registry MUST populate the required
   the DNS serving the HDA with the HIP RR and other relevant RR types
   (such as TXT and CERT).  The Registry MUST also generate the
   appropriate sign over an existing Concise
   Attestation for the given operation.

   If the Registry denied where the HI/HHIT pair, because there was a HHIT
   collision or any other reason, signer is the Registry MUST signal back to second party of the
   device being provisioned that a new HI needs to be generated.

8.3.  Registry

   (Editor Note: this should break down embedded
   attestation.  The DET of party Y is used as the individual registrations
   between Root/RAA, RAA/HDA and their special variants).

   TODO Attestor Identity
   Information (Appendix A.1.1).

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP UAS RID defines two levels                              |
     |                        Entity Tag of hierarchy maintained Y                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             CA-xy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by the
   Registration Assigning Authority (RAA) and HHIT Domain Authority
   (HDA).  The authors anticipate that an RAA is owned and operated Y                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by a
   regional CAA (or a delegated party Y                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by an CAA in a specific airspace
   region) with HDAs being contracted out.  As such a chain of trust Y                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 192-bytes

                      Figure 15: DRIP Link Attestation

A.2.6.  Broadcast Attestation (BA-x.y)

   Required by DRIP Authentication Formats for
   registries is required to ensure trustworthiness is not compromised.
   More information on the registries can be found in [hhit-registries].

   Both the RAA and HDA generate their own keypairs and self-signed
   attestations (SelfAttestation: RAA on RAA and SelfAttestation: HDA on
   HDA respectively).  The HDA sends to the RAA its self-signed
   attestation to be added into the RAA DNS.

   The RAA confirms the attestation received is valid and that no HHIT
   collisions occur before added a HIP RR Broadcast RID
   ([drip-auth]) to its DNS for the new HDA.
   An Attestation: RAA on HDA (A-rh) is sent as a confirmation that
   provisioning was successful.

   The HDA is now a valid "Registry" and uses its keypair satisfy [drip-requirements] GEN-1 and
   SelfAttestation: HDA on HDA (SA-hh) with all provisioning requests
   from downstream.

8.4.  Manufacturer

                +--------------+    SA-a0a0 +-----------------+ GEN-3.

      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
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP                              |
     |                        Entity Tag of X                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                             DRIP                              |
     |                        Entity Tag of Y                        |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                       Host Identity of Y                      |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               | Manufacturer
     +---------------+---------------+---------------+---------------+
     | <-------->                      Trust Timestamp by X                     | Manufacturer CA
     +---------------+---------------+---------------+---------------+
     |
                +--------------+ A-ma0      +-----------------+
                    ^                     Signing Timestamp by X                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
            SA-a0a0
     |                                                               |   A-ma0
     |                                                               |
     |    v
                +----------+                                                               | Aircraft
     |
                +----------+                                                               |
     |                                                               |
     |                         Signature by X                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 136-bytes

                   Figure 12: Manufacturer Provision

   During the initial configuration and production at the factory 16: DRIP Broadcast Attestation

A.3.  Certificates

   In DRIP certificates are signed by a third party that has no stake in
   the
   Aircraft MUST be configured claims/assertions/attestations being attested to.

   It is analogous to have a serial number.  ASTM defines
   this to be an ANSI/CTA-2063A.  Under DRIP third party in legal system that signs a HHIT can be encoded
   document as
   such to be able to convert back a "witness" and forth between them.  This is out
   of scope for this document.  TODO: link from UAS RID document.

   Under DRIP bears no responsibility in the Manufacturer SHOULD be using HHITs and have their own
   keypair and SA-mm (SelfAttestation: Manufacturer on Manufacturer).
   (Ed.  Note: some words on aircraft keypair and certs here?).

   SelfAttestation: Aircraft document.

A.3.1.  Attestation Certificate (AC-z.x.y)

      0 on Aircraft                   1                   2                   3
      0 (SA-a0a0) is extracted by
   the manufacturer and sent to their Certificate Authority (CA) to be
   verified and added.  A resulting attestation (Attestation:
   Manufacturer on Aircraft 1 2 3 4 5 6 7 8 9 0 [A-ma0]) SHOULD be a DRIP Attestation -
   however this could be a X.509 certificate binding the serial number
   to the manufacturer.

8.5.  Operator
                    +----------+            +---------+ 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     | Registry                                                               | --------->
     .                                                               .
     .                             SA-zz                             .
     .                                                               .
     | HDA DNS                                                               |
                    +----------+  [HIP RR]  +---------+
                        ^
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                              A-xy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |
                    Coo                      Trust Timestamp by Z                     |
     +---------------+---------------+---------------+---------------+
     | Aro                     Signing Timestamp by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |   v
                    +----------+
     | Operator                                                               |
                    +----------+

                       Figure 13: Operator Provision

   The Operator generates a keypair and HHIT as specified in DRIP UAS
   RID.  A self-signed attestation (Attestation: Operator on Operator
   [SA-oo]) is generated and sent to the desired Registry (HDA).  Other
   relevant information and possibly personally identifiable information
   needed may also be required to be sent to the Registry (all over a
   secure channel - the method of which is out of scope for this
   document).

   The Registry cross checks any personally identifiable information as
   required.  Certificate: Operator on Operator is verified (both using
   the expiration timestamp and signature).  The HHIT is searched in the
   Registries database to confirm that no collision occurs.  A new
   attestation is generated (Attestation: Registry on Operator) and sent
   securely back to the Operator.  Optionally the HHIT/HI pairing can be
   added to the Registries DNS in to form of a HIP Resource Record (RR).
   Other RRs, such as CERT and TXT, may also be used to hold public
   information.

   With the receipt of Attestation: Registry on Operator (A-ro) the
   provisioning of an Operator is complete.

8.6.  Aircraft

8.6.1.  Standard Provisioning

   Under standard provisioning the Aircraft has its own connectivity to
   the Registry, the method which is out of scope for this document.

             +----------+
     | Registry                                                               |
             +----------+
                 ^
     |                                                               |
     |  A-ro, A-oaN                                                               |
     |
             +----------+                        +----------+                                                               | Operator
     | <---------------------                                                               | Aircraft
     |
             +----------+        A-a0aN          +----------+                         Signature by Z                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 504-bytes
                  Figure 14: Standard Provision: Step 17: DRIP Attestation Certificate

A.3.2.  Concise Certificate (CC-z.x.y)

      0                   1

   Through mechanisms not specified in this document the Aircraft should
   have methods to instruct the Aircraft onboard systems to generate a
   keypair and certificate.  This certificate is chained to the factory
   provisioned certificate (SelfAttestation: Aircraft                   2                   3
      0 on Aircraft 1 2 3 4 5 6 7 8 9 0
   [SA-a0a0]).  This new attestation (Attestation: Aircraft 1 2 3 4 5 6 7 8 9 0 on
   Aircraft N [A-a0aN]) is securely extracted by the Operator.

   With A-a0aN the sub-attestation (SelfAttestation: Aircraft N on
   Aircraft N [SA-aNaN]) is used by the Operator to generate
   Attestation: Operator on Aircraft N (A-oaN).  This along with
   Attestation: Registry on Operator (A-ro) is sent to the Registry.

             +----------+
             | Registry 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |
             +----------+                                                               |
     |                             DRIP                              |
     |  Token                        Entity Tag of Z                        |
                 v
             +----------+                        +----------+
     | Operator                                                               | --------------------->
     +---------------+---------------+---------------+---------------+
     | Aircraft                                                               |
             +----------+        Token           +----------+

                   Figure 15: Standard Provision: Step 2

   On the Registry, A-ro is verified and used as confirmation that the
   Operator is already registered.  A-oaN also undergoes a validation
   check and used to generate a token to return to the Operator to
   continue provisioning.

   Upon receipt of this token, the Operator injects it into the Aircraft
   and its used to form a secure connection to the Registry.  The
   Aircraft then sends Attestation: Manufacturer on Aircraft 0 (A-ma0)
   and Attestation: Aircraft 0 to Aircraft N (A-a0aN).

        +---------+
     .                                                               .
     .                             CA-xy                             .
     .                                                               .
     | HDA DNS                                                               |
        +---------+
            ^
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Z                     | HIP RR
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Z                    |
     +---------------+---------------+---------------+---------------+
     |
        +----------+ <----------------------------+                                                               | Registry
     |                                                               |
        +----------+ ------------------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |  Token,                                                               |  AC-roaN               BA-raN
     |                                                               |  A-ma0, A-a0aN
     |                         Signature by Z                        |
     |                                                               |
     |                                                               |
            v                                v
     |
        +----------+                      +----------+                                                               | Operator
     |                                                               | Aircraft
     |
        +----------+                      +----------+                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 192-bytes

                    Figure 16: Standard Provision: Step 18: DRIP Concise Certificate

A.3.3.  Link Certificate (LC-z.x.y)
      0                   1                   2                   3

   The Registry uses Attestation: Manufacturer on Aircraft
      0 (with an
   external database if supported) to confirm the validity of the
   Aircraft.  Attestation: Aircraft 1 2 3 4 5 6 7 8 9 0 on Aircraft N is correlated with
   Attestation: Operator on Aircraft N and Attestation: Manufacturer on
   Aircraft 1 2 3 4 5 6 7 8 9 0 to see the chain of ownership.  The new HHIT tied to
   Aircraft N is then checked for collisions in the HDA.  With the
   information the Registry generates two items: AttestationCertificate:
   Registry on Operator on Aircraft N (AC-roaN) and
   BroadcastAttestation: Registry on Aircraft N (BA-raN).  A HIP RR (and
   other RR types as needed) are generated and inserted into the HDA.

   AC-roaN is sent via a secure channel back to the Operator to be
   stored.  ABA-raN is sent to the Aircraft to be used in Broadcast RID
   as specified in (Editors Note: add link to -auth-formats).

8.6.2.  Operator Assisted Provisioning

   This provisioning scheme is for when the Aircraft is unable to
   connect to the Registry itself or does not have the hardware required
   to generate keypairs and certificates.

             +----------+
             | Registry 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |
             +----------+

             +----------+                        +----------+                                                               | Operator
     | --------------------->                             DRIP                              | Aircraft
     |
             +----------+     aN, SA-aNaN        +----------+

               Figure 17: Operator Assisted Provision: Step 1

   To start the Operator generates on behalf of the Aircraft a new
   keypair and Attestation: Aircraft N on Aircraft N (SA-aNaN).  This
   keypair and certificate are injected into the Aircraft for it to
   generate Attestation: Aircraft 0 on Aircraft N (A-a0aN).  After
   injecting the keypair and certificate, the Operator MUST destroy all
   copies                        Entity Tag of the keypair.

             +----------+ Z                        | Registry
     |
             +----------+
                 ^                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |  A-ro, A-ma0, A-a0aN, A-oaN
     .                                                               .
     .                             LA-xy                             .
     .                                                               .
     |                                                               |
             +----------+                        +----------+
     +---------------+---------------+---------------+---------------+
     | Operator                      Trust Timestamp by Z                     | <---------------------
     +---------------+---------------+---------------+---------------+
     | Aircraft                     Signing Timestamp by Z                    |
             +----------+      A-ma0, A-a0aN     +----------+
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by Z                        |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 300-bytes

                      Figure 18: Operator Assisted Provision: Step 19: DRIP Link Certificate

A.3.4.  Mutual Certificate (MC-z.x.y)
      0                   1                   2

   Attestation: Manufacturer on Aircraft                   3
      0 (A-ma0) and Attestation:
   Aircraft 1 2 3 4 5 6 7 8 9 0 on Aircraft N (A-a0aN) is extracted 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             SA-zz                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     .                                                               .
     .                             MA-xy                             .
     .                                                               .
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                      Trust Timestamp by Z                     |
     +---------------+---------------+---------------+---------------+
     |                     Signing Timestamp by Z                    |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                         Signature by the Operator and
   the following data items are sent to the Registry; Attestation:
   Registry on Operator (A-ro), Attestation: Manufacturer on Aircraft 0
   (A-ma0), Attestation: Aircraft 0 on Aircraft N (A-a0aN), Attestation:
   Operator on Aircraft N (A-oaN).

             +----------+            +---------+ Z                        | Registry
     | --------->                                                               | HDA DNS
     |
             +----------+   HIP RR   +---------+                                                               |
     |                                                               |
     |  AC-roaN, BA-raN                                                               |
                 v
             +----------+                        +----------+
     | Operator                                                               | --------------------->
     | Aircraft                                                               |
             +----------+        BA-raN          +----------+
     |                                                               |
     |                                                               |
     +---------------+---------------+---------------+---------------+

     Length = 576-bytes

                     Figure 19: Operator Assisted Provision: Step 3

   On the Registry validation checks are done on all attestations as per
   the previous sections.  Once complete then the Registry checks for 20: DRIP Mutual Certificate

A.4.  Abbreviations & File Naming Conventions

   The names of attestation and certificates can become quite long and
   tedious to write out.  As such this section provides a
   HHIT collision, adding guide to a
   somewhat standardized way they are written in text.

A.4.1.  In Text Abbreviation

   In a long form the HDA if clear and generates
   AttestationCertificate: Registry on name of a particular attestation/certification can
   be written as follows:

   *  Self-Attestation: Unmanned Aircraft

   *  Attestation: Operator on Aircraft N (AC-roaN)
   and BroadcastAttestation: or Attestation: Operator,
      Aircraft

   *  Attestation Certificate: Registry on Aircraft N (BA-raN).  Both are
   sent back to the Operator.

   The Operator securely inject BA-raN and securely stores AC-roaN of
   Aircraft N.

8.6.3.  Initial Provisioning

   A special form of provisioning is used when the on Aircraft is first
   sold to an Operator.  Instead of generating a new keypair, the built
   in keypair and certificate done by the Manufacturer is used to
   provision and register the aircraft to the owner.

   For this either Standard or Operator Assisted methods can be used.

9.  IANA Considerations

   (Editor Note: EPP/RDAP adds to existing registries, CERT RR update,
   HIP RR update)

10.  Security Considerations

   TODO

11.  Contributors
      Attestation Certificate: Registry, Operator, Aircraft

   When multiple entities are listed they can be separated by either on
   or by ,. These long forms can be shortened:

   *  Scott Hollenbeck for his guidance with EPP/RDAP  SA(Unmanned Aircraft) or SA-ua

   *  Andrei Gurtov  A(Operator, Unmanned Aircraft) or A-op.ua

   *  AC(Registry, Operator, Aircraft) or AC-reg.op.ua

   Typical abbreviations for his insights the entity can be used such as Unmanned
   Aircraft being shorthanded to ua.

A.4.2.  File Naming

   For file naming of various certificates a pilot

12.  References

12.1.  Normative References

   [F3411-19] "Standard Specification for Remote ID and Tracking",
              February 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs similar format 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 the short
   form is used:

   *  sa-{hash 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>.

12.2.  Informative References

   [drip-requirements]
              Card, S. W., Wiethuechter, A., Moskowitz, R., and A.
              Gurtov, "Drone Remote Identification Protocol (DRIP)
              Requirements", Work in Progress, Internet-Draft, draft-
              ietf-drip-reqs-18, 8 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-drip-reqs-
              18.txt>.

   [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
              Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
              draft-ietf-drip-uas-rid-01, 9 September 2020,
              <https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
              01.txt>.

   [hhit-registries]
              Moskowitz, R., Card, S. W., and A. Wiethuechter,
              "Hierarchical HIT Registries", Work in Progress, Internet-
              Draft, draft-moskowitz-hip-hhit-registries-02, 9 March
              2020, <https://www.ietf.org/archive/id/draft-moskowitz-
              hip-hhit-registries-02.txt>.

   [NPRM]     "Notice entity}

   *  a-{hash of Proposed Rule Making on Remote Identification entity x}_{hash of Unmanned Aircraft Systems", December 2019.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>. entity y}

   *  ac-{hash of entity z}_{hash of entity x}_{hash of entity y}

   Some examples of file names:

   *  sa-79d8a404d48f2ef9.cert

   *  a-120b8f25b198c1e1_79d8a404d48f2ef9.cert

   *  ac-aac6b00abba268b7_120b8f25b198c1e1_79d8a404d48f2ef9.cert

Appendix B.  X.509 Certificates

Authors' Addresses
   Adam Wiethuechter
   AX Enterprize, LLC
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America
   Email: adam.wiethuechter@axenterprize.com

   Stuart Card
   AX Enterprize, LLC
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America
   Email: stu.card@axenterprize.com

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI 48237
   United States of America
   Email: rgm@labs.htt-consult.com

   Jim Reid
   RTFM llp
   St Andrews House
   382 Hillington Road Road, Glasgow Scotland
   G51 4BL
   United Kingdom
   Email: jim@rfc1035.com