draft-ietf-drip-registries-00.txt   draft-ietf-drip-registries-01.txt 
drip Working Group A. Wiethuechter drip Working Group A. Wiethuechter
Internet-Draft S. Card Internet-Draft S. Card
Intended status: Standards Track AX Enterprize, LLC Intended status: Standards Track AX Enterprize, LLC
Expires: 31 July 2022 R. Moskowitz Expires: 8 September 2022 R. Moskowitz
HTT Consulting HTT Consulting
J. Reid J. Reid
RTFM llp RTFM llp
27 January 2022 7 March 2022
DRIP Registries DRIP Registries
draft-ietf-drip-registries-00 draft-ietf-drip-registries-01
Abstract Abstract
This document creates the DRIP DET registration and discovery This document creates the DRIP DET registration and discovery
ecosystem. This includes all components in the ecosystem (e.g., RAA, ecosystem. This includes all components in the ecosystem (e.g., RAA,
HDA, UA, GCS, USS). The registration process will use the Extensible HDA, UA, GCS, USS). The registration process will use the Extensible
Provisioning Protocol (EPP) and other protocols. The discovery Provisioning Protocol (EPP) and other protocols. The discovery
process will leverage DNS and DNSSEC and related technology. The process will leverage DNS and DNSSEC and related technology. The
DETs can be registered with as their "raw public keys" or in X.509 DETs can be registered with as their "raw public keys" or in X.509
certificates. certificates.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 July 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abstract Process & Reasoning . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Required Terminology . . . . . . . . . . . . . . . . . . 5 2.1. Required Terminology . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. DRIP Attestations & Certificates . . . . . . . . . . . . . . 5 3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Attestation Structure . . . . . . . . . . . . . . . . . . 5 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Attestor Identity Information . . . . . . . . . . . . 6 3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 7 3.1.2. Registered Assigning Authorities . . . . . . . . . . 6
3.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 7 3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7
3.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 7 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 7
3.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 7 4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 8
3.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Self-Attestation (SA-xx) . . . . . . . . . . . . . . 7 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Attestation (A-xy) . . . . . . . . . . . . . . . . . 8 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Concise Attestation (CA-xy) . . . . . . . . . . . . . 9 5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Mutual Attestation (MA-xy) . . . . . . . . . . . . . 10 5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Link Attestation (LA-xy) . . . . . . . . . . . . . . 11 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.6. Broadcast Attestation (BA-xy) . . . . . . . . . . . . 12 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Attestation Certificate (AC-zxy) . . . . . . . . . . 14 5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Concise Certificate (CC-zxy) . . . . . . . . . . . . 15 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. Link Certificate (LC-zxy) . . . . . . . . . . . . . . 15 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 10
3.3.4. Mutual Certificate (MC-zxy) . . . . . . . . . . . . . 16 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 10
4. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 11
4.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 12
4.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 13
4.1.2. Registered Assigning Authorities . . . . . . . . . . 18 6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 14
4.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 18 6.2. Registering a Serial Number . . . . . . . . . . . . . . . 15
4.2. Federation . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Registering an Operator . . . . . . . . . . . . . . . . . 17
5. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 19 6.4. Registering a Session ID . . . . . . . . . . . . . . . . 18
5.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 19 6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 20
5.2. Reverse SN . . . . . . . . . . . . . . . . . . . . . . . 19 6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 22
5.3. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 23
5.4. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 20 7. EPP Command Mappings . . . . . . . . . . . . . . . . . . . . 23
6. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 20 7.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 23
6.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EPP Query Commands . . . . . . . . . . . . . . . . . . . 24
6.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2.1. EPP <check> Command . . . . . . . . . . . . . . . . . 24
6.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2.2. EPP <info> Command . . . . . . . . . . . . . . . . . 24
6.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.3. EPP <transfer> Command . . . . . . . . . . . . . . . 24
6.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. EPP Transform Commands . . . . . . . . . . . . . . . . . 24
7. Registry Operations . . . . . . . . . . . . . . . . . . . . . 21 7.3.1. EPP <create> Command . . . . . . . . . . . . . . . . 24
7.1. Registering an RAA . . . . . . . . . . . . . . . . . . . 21 7.3.2. EPP <delete> Command . . . . . . . . . . . . . . . . 28
7.1.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 21 7.3.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 30
7.1.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 22 7.3.4. EPP <transfer> Command . . . . . . . . . . . . . . . 30
7.1.3. Database Entries . . . . . . . . . . . . . . . . . . 22 7.3.5. EPP <update> Command . . . . . . . . . . . . . . . . 30
7.1.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 22 8. RDAP Definitions . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Registering an IRM . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.2.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 22 10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 30
7.2.3. Database Entries . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. Registering an HDA . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 31
7.3.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 33
7.3.3. Database Entries . . . . . . . . . . . . . . . . . . 23 A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 33
7.3.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 23 A.1.1. Attestor Identity Information . . . . . . . . . . . . 34
7.4. Registering an MRA . . . . . . . . . . . . . . . . . . . 23 A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 34
7.4.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 24 A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 34
7.4.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 24 A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 35
7.4.3. Database Entries . . . . . . . . . . . . . . . . . . 24 A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 35
7.4.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 24 A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 35
7.5. Registering a Serial Number . . . . . . . . . . . . . . . 24 A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 35
7.5.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 24 A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 36
7.5.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 25 A.2.3. Concise Attestation (CA-x.y) . . . . . . . . . . . . 37
7.5.3. Database Entries . . . . . . . . . . . . . . . . . . 25 A.2.4. Mutual Attestation (MA-x.y) . . . . . . . . . . . . . 38
7.5.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 25 A.2.5. Link Attestation (LA-x.y) . . . . . . . . . . . . . . 39
7.6. Registering an Operator . . . . . . . . . . . . . . . . . 25 A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 40
7.6.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 25 A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 42
7.6.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 25 A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 42
7.6.3. Database Entries . . . . . . . . . . . . . . . . . . 26 A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 43
7.6.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 26 A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 43
7.7. Registering a Session ID . . . . . . . . . . . . . . . . 26 A.3.4. Mutual Certificate (MC-z.x.y) . . . . . . . . . . . . 44
7.7.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 26 A.4. Abbreviations & File Naming Conventions . . . . . . . . . 45
7.7.2. DNS Entries . . . . . . . . . . . . . . . . . . . . . 26 A.4.1. In Text Abbreviation . . . . . . . . . . . . . . . . 46
7.7.3. Database Entries . . . . . . . . . . . . . . . . . . 27 A.4.2. File Naming . . . . . . . . . . . . . . . . . . . . . 46
7.7.4. Outputs . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 46
8. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Overview 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 1. Introduction
Registries are fundamental to RID. Only very limited information can Registries are fundamental to RID. Only very limited information can
be Broadcast, but extended information is sometimes needed. The most be Broadcast, but extended information is sometimes needed. The most
essential element of information sent is the UAS ID itself, the essential element of information sent is the UAS ID itself, the
unique key for lookup of extended information in registries. unique key for lookup of extended information in registries.
While it is expected that registry functions will be integrated with While it is expected that registry functions will be integrated with
USS, who will provide them is not yet determined in most, and is USS, who will provide them is not yet determined in most, and is
skipping to change at page 5, line 10 skipping to change at page 4, line 45
hash portion of the DET. Forgery of the DET is still possible, but hash portion of the DET. Forgery of the DET is still possible, but
including it as a part of a public registration mitigates a lot of including it as a part of a public registration mitigates a lot of
the risk. This document creates the DRIP DET registration and the risk. This document creates the DRIP DET registration and
discovery ecosystem. This includes all components in the ecosystem discovery ecosystem. This includes all components in the ecosystem
(e.g., RAA, HDA, UA, GCS, USS). The registration process will use (e.g., RAA, HDA, UA, GCS, USS). The registration process will use
the Extensible Provisioning Protocol (EPP) and other protocols. The the Extensible Provisioning Protocol (EPP) and other protocols. The
discovery process will leverage DNS and DNSSEC and related discovery process will leverage DNS and DNSSEC and related
technology. The DETs can be registered with as their "raw public technology. The DETs can be registered with as their "raw public
keys" or in X.509 certificates. keys" or in X.509 certificates.
1.1. Abstract Process & Reasoning
In DRIP each entity (registries, operators and aircraft) is expected
to generate a full DRIP Entity ID [drip-rid] on the local device
their key is expected to be used. These are registered with a Public
Information Registry within the hierarchy along with whatever data is
required by the cognizant CAA and the registry. Any PII is stored in
a Private Information Registry protected through industry practice
AAA or better. In response, the entity will obtain an attestation or
certificate from the registry proving such registration.
Manufacturers that wish to 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 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 an aircraft
profile to be displayed.
Operators are registered with a number of registries or their
regional RAA. This acts as a verification check when a user performs
other registration operations; such as provisioning an aircraft with
a new Session ID. It is an open question if an Operator registers to
their CAA (the RAA) or multiple USS's (HDA's). PII of the Operator
would vary based on the CAA they are under and the registry.
Finally aircraft that support using a DET would provision per flight
to a USS, proposing a DET to the registry to generate a binding
between the aircraft (Session ID, Serial Number and Operational
Intent), operator and registry. Aircraft then follow [drip-auth] to
meet various [drip-requirements] during flight.
2. Terminology 2. Terminology
2.1. Required Terminology 2.1. Required Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 5, line 32 skipping to change at page 6, line 6
See [drip-requirements] for common DRIP terms. See [drip-requirements] for common DRIP terms.
HDA: Hierarchial HIT Domain Authority. The 16 bit field identifying HDA: Hierarchial HIT Domain Authority. The 16 bit field identifying
the HIT Domain Authority under a RAA. the HIT Domain Authority under a RAA.
HID: Hierarchy ID. The 32 bit field providing the HIT Hierarchy ID. HID: Hierarchy ID. The 32 bit field providing the HIT Hierarchy ID.
RAA: Registered Assigning Authority. The 16 bit field identifying RAA: Registered Assigning Authority. The 16 bit field identifying
the Hierarchical HIT Assigning Authority. the Hierarchical HIT Assigning Authority.
3. DRIP Attestations & Certificates 3. Registries
3.1. Attestation Structure 3.1. Classes
All Attestations and Certificates under DRIP share the following Under DRIP there 3 classes of registries, with specific variants in
format: 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 registries that wish to
act as an RAA.
3.1.2. Registered Assigning Authorities
RAA's are the upper hierarchy in DRIP. Most are contemplated to be
Civil Aviation Authorities (CAAs) that then delegate HDAs to 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 0 and have their RAA value delegated to
them by the Root.
3.1.2.1. ICAO Registry of 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 RAA value of 1 and HDA value of 0.
3.1.3. Hierarchial HIT Domain Authorities
3.1.3.1. Manufacturer's Registry of Aircraft (MRA)
A registry (HDA) run by a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific
ICAO Manufacturer Code (assigned to the manufacturer by ICAO).
A DET can be encoded into a Serial Number (see [drip-rid]) and this
registry would hold a mapping from the Serial Number to the DET and
its artifacts.
Hold RAA value of 1 and HDA values of 1+.
3.1.3.2. Remote ID Registries (RIDR)
Registry that holds the binding between a UAS Session ID (for DRIP
the DET) and the UA Serial Number. The Serial Number MUST have its
access protected to allow only authorized parties to obtain. The
Serial Number SHOULD be encrypted in a way only the authorized party
can decrypt.
As part of the UTM system they also hold a binding between a UAS ID
(Serial Number or Session ID) and an Operational Intent.
Hold RAA values of 2+ and HDA values of 1+.
3.2. Key Rollover & Federation
During key rollover the entity MUST inform all children and parents
of the change - using best standard practices of a key rollover. At
time of writing this is signing over the new key with the previous
key in a secure fashion and it being validated by others before
changing any links (in DRIPs case the NS RRs in the 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 hash of the public key and the
HID of the DET being generated. As such during key rollover, only
the lower 64-bits would change and a check for a collision would be
required.
This attribute of the DET to have different identities could also
allow for a single registry to be "federated" across them if they
share the 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 a
signed, DNS zone. The HDA SHOULD provide DNS service for its zone
and provide the HHIT detail response. A 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
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 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 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 this is
the Attestation Certificate made during Session ID registration.
This is as this particular certificate acts similar to a car
registration and should be held safe by the operator.
5.3. NS RR
Along with their associated "glue" record (A/AAAA) supports the
traversal 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 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 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 this 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 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 DET is
used in Network RID and the wider UTM system.
6. Registry Operations
As a general rule the following processing performed for any
registration operation:
1. Verify input Attestations from registering party
2. Check for collision of DET and HI
3. Populate DNS with required/optional records
4. Populate Database with PII and other info
5. Generate and return required/optional Attestations/Certificates
6.1. Registering a Registry
DRIP defines two levels of hierarchy maintained by the Registration
Assigning Authority (RAA) and 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 trust for
registries is required to ensure trustworthiness is not compromised.
More information on the registries can be found in [hhit-registries].
Both the parent and child generate their own keypairs and self-signed
attestations if not generated previously. The child sends to the
parent its self-signed attestation to be added into the parent DNS.
The parent confirms the attestation received is valid and that no DET
collisions occur before adding a NS RR (and CERT RRs) to its DNS for
the new child. An attestation, parent on child, is sent as a
confirmation that provisioning was successful.
The child is now a valid member of the registry tree and uses its
keypair and Self-Attestation with all provisioning requests towards
it. The HIP RR for the child is populated into the 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 |
| | |(Optional) |
+==================+===================================+============+
|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 |
| |<hip_rr_data> |Attestation:|
| | |Root, RAA) |
+------------------+-----------------------------------+------------+
| |RAA: <raa_det_fqdn> CERT | |
| |<raa_self_attestation> | |
+------------------+-----------------------------------+------------+
| |(Root: <raa_det_fqdn> CERT | |
| |<attestation_root_raa>) | |
+------------------+-----------------------------------+------------+
| |(Root: <raa_det_fqdn> CERT | |
| |<concise_attestation_root_raa>) | |
+------------------+-----------------------------------+------------+
| |(Root: <raa_det_fqdn> CERT | |
| |<broadcast_attestation_root_raa>) | |
+------------------+-----------------------------------+------------+
| |(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>) | |
+------------------+-----------------------------------+------------+
Table 1
6.1.2. Registering an IRM
Specifically handled by the Root (Section 3.1.1).
+==================+===================================+============+
|Inputs (Optional) |DNS Entries (Optional) |Outputs |
| | |(Optional) |
+==================+===================================+============+
|IP Address of IRM |Root: mfr.remoteid.aero NS |Attestation:|
| |<irm_det_fqdn> |Root, IRM |
+------------------+-----------------------------------+------------+
|IRM Self- |Root: 1.det.remoteid.aero NS |(Concise |
|Attestation |<irm_det_fqdn> |Attestation:|
| | |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 | |
| |<attestation_root_irm>) | |
+------------------+-----------------------------------+------------+
| |(Root: <irm_det_fqdn> CERT | |
| |<concise_attestation_root_irm>) | |
+------------------+-----------------------------------+------------+
| |(Root: <irm_det_fqdn> CERT | |
| |<broadcast_attestation_root_irm>) | |
+------------------+-----------------------------------+------------+
| |(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>) | |
+------------------+-----------------------------------+------------+
Table 2
6.1.3. Registering an HDA
Specifically handled by an RAA (Section 3.1.2).
+===========+==========================================+============+
|Inputs |DNS Entries (Optional) |Outputs |
|(Optional) | |(Optional) |
+===========+==========================================+============+
|IP Address |RAA: |Attestation:|
|of HDA |<hda_value>.<raa_value>.det.remoteid.aero |RAA, HDA |
| |NS <hda_det_fqdn> | |
+-----------+------------------------------------------+------------+
|HDA Self- |RAA: <hda_det_fqdn> AAAA <hda_ip> |(Concise |
|Attestation| |Attestation:|
| | |RAA, HDA) |
+-----------+------------------------------------------+------------+
| |RAA: <hda_det_fqdn> HIP <hip_rr_data> |(Broadcast |
| | |Attestation:|
| | |RAA, HDA) |
+-----------+------------------------------------------+------------+
| |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>) | |
+-----------+------------------------------------------+------------+
| |(RAA: <hda_det_fqdn> CERT | |
| |<broadcast_attestation_raa_hda>) | |
+-----------+------------------------------------------+------------+
| |(HDA: <hda_det_fqdn> CERT | |
| |<attestation_raa_hda>) | |
+-----------+------------------------------------------+------------+
| |(HDA: <hda_det_fqdn> CERT | |
| |<concise_attestation_raa_hda>) | |
+-----------+------------------------------------------+------------+
| |(HDA: <hda_det_fqdn> CERT | |
| |<broadcast_attestation_raa_hda>) | |
+-----------+------------------------------------------+------------+
Table 3
6.1.4. Registering an MRA
Specifically handled by 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) |
+------------------+-----------------------------------+------------+
| |MRA: <mra_det_fqdn> HIP | |
| |<hip_rr_data> | |
+------------------+-----------------------------------+------------+
| |MRA: <mra_det_fqdn> CERT | |
| |<mra_self_attestation> | |
+------------------+-----------------------------------+------------+
| |(IRM: <mra_det_fqdn> CERT | |
| |<attestation_irm_mra>) | |
+------------------+-----------------------------------+------------+
| |(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 Serial Number
Specifically handled by an MRA (Section 3.1.3.1).
+===================+=================================+=============+
| Inputs (Optional) |DNS Entries (Optional) |Outputs |
| | |(Optional) |
+===================+=================================+=============+
| Serial Number |(<sn_det_fqdn> HIP <hip_rr_data>)|(Attestation:|
| | |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 | |
| |<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 |
+----------+
Figure 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 UAS. Under DRIP a DET
can be encoded as such to be able to convert back and 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 on Aircraft 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 0 [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 |
| | |(Optional) |
+==================+==================================+=============+
|Operator Self- | <op_det_fqdn> HIP <hip_rr_data> |Attestation: |
|Attestation | |RIDR, |
| | |Operator |
+------------------+----------------------------------+-------------+
|Operator PII | (<op_det_fqdn> CERT |Broadcast |
| | <op_self_attestation>) |Attestation: |
| | |RIDR, |
| | |Operator |
+------------------+----------------------------------+-------------+
| | (<op_det_fqdn> CERT |(Concise |
| | <attestation_ridr_op>) |Attestation: |
| | |RIDR, |
| | |Operator) |
+------------------+----------------------------------+-------------+
| | (<op_det_fqdn> CERT | |
| | <concise_attestation_ridr_op>) | |
+------------------+----------------------------------+-------------+
| | (<op_det_fqdn> CERT | |
| | <broadcast_attestation_ridr_op>) | |
+------------------+----------------------------------+-------------+
Table 6
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ [HIP RR] +---------+
^ |
| |
| |
Coo | | Aro
| |
| v
+----------+
| Operator |
+----------+
Figure 3: Operator Provision
The Operator generates a keypair and DET as specified in DRIP UAS
RID. A self-signed attestation (Self-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 DET 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 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 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 | <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: |
|Operator, UA)| |RIDR, |
| | |Operator) |
+-------------+--------------------------------------+--------------+
|(Mutual | (<session_det_fqdn> CERT |(Mutual |
|Attestation: | <concise_attestation_ridr_session>) |Certificate: |
|Operator, UA)| |RIDR, |
| | |Operator, UA) |
+-------------+--------------------------------------+--------------+
|(Link | |(Concise |
|Attestation: | |Certificate: |
|Operator, UA)| |RIDR, |
| | |Operator, UA) |
+-------------+--------------------------------------+--------------+
|(Operational | |(Link |
|Intent) | |Certificate: |
| | |RIDR, |
| | |Operator, UA) |
+-------------+--------------------------------------+--------------+
| | |(Broadcast |
| | |Attestation: |
| | |RAA, RIDR) |
+-------------+--------------------------------------+--------------+
| | |(Broadcast |
| | |Attestation: |
| | |Root, RAA) |
+-------------+--------------------------------------+--------------+
Table 7
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.
+----------+
| Registry |
+----------+
^
|
|
| A-ro, A-oaN
|
|
+----------+ +----------+
| Operator | <--------------------- | Aircraft |
+----------+ 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 the Operator.
With A-a0aN the sub-attestation (Self-Attestation: 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 |
+----------+
|
|
|
| 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 |
+---------+
^
|
| HIP RR
|
|
|
+----------+ <----------------------------+
| Registry | |
+----------+ ------------------------+ |
| | |
| | | Token,
| AC-roaN BA-raN | | A-ma0, A-a0aN
| | |
| | |
v v |
+----------+ +----------+
| Operator | | 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 |
+----------+ 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 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 |
+----------+ BA-raN +----------+
Figure 9: 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 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 common attributes between the various EPP
commands under DRIP that has specific encoding rules.
* The hi attribute is a Base64 encoding of the Host Identity.
* The det attribute is a string from of 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 6 characters, and is used by RID
receivers to 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 unknown then the receiver SHOULD use the hexadecimal
encoding of the respective RAA/HDA field of the HID as the value in
the form. For example if the HDA is unknown and the HDA value is 20
then the decoded display would be: DE 14 FE23. Typically for RAAs
the abbreviation is RECOMMENDED to be set to the ISO 3166 country
code (either Alpha-2 or Alpha-3) for the CAA. Dashes or underscores
should be used in place of 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 for ANSI CTA2063-A Serial Numbers. It has a max of
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 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
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 there is no mapping
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
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 own DET, discovering and using the RAA
and HDA for the target registry. The method for discovering a
registry's RAA and HDA is out of scope here. This allows for the
device to 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 be hashed and
result in the DET. The registry would then either accept
(returning the DET to the device) or deny this pairing.
Keypairs are expected to be generated on the device hardware it will
be used on. Due to hardware limitations (see Section 10) and
connectivity it is acceptable under DRIP to generate keypairs for the
Aircraft on Operator devices and later securely inject them into the
Aircraft (as defined in Section 6.4.2). The methods to securely
inject and store keypair information in a "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 DET and HI.
Upon accepting a HI/DET 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 attestations/certificates for the given operation.
If the registry denied the HI/DET pair, because there was a DET
collision or any other reason, the registry MUST signal back to the
device being provisioned that a new HI needs to be generated.
11. Contributors
* Scott Hollenbeck for his guidance with EPP/RDAP
* Andrei Gurtov for his insights as 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 to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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 R. Moskowitz, "DRIP
Authentication Formats & Protocols for 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 A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", 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 of Proposed Rule Making on Remote Identification
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>.
Appendix A. DRIP Attestations & Certificates
See [drip-arch] for definitions of 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 following format structure:
0 1 2 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 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 . . Attestor Identity Information .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 6, line 45 skipping to change at page 34, line 19
Expiration Timestamp by Attestor (4 bytes): Expiration Timestamp by Attestor (4 bytes):
Timestamp denoting recommended time to trust data to. Timestamp denoting recommended time to trust data to.
Signing Timestamp by Attestor (4 bytes): Signing Timestamp by Attestor (4 bytes):
Current time at signing. Current time at signing.
Attestor Signature (64 bytes): Attestor Signature (64 bytes):
Signature over preceding fields using the keypair of Signature over preceding fields using the keypair of
the Attestor. the Attestor.
Figure 1: Attestation Structure Figure 10: Attestation Structure
3.1.1. Attestor Identity Information
This can be any one of the following: A.1.1. Attestor Identity Information
1. None This can be either of the following:
2. Attestor HHIT: 16-bytes
3. Attestor SelfAttestation: 120-bytes 1. Attestor DET: 16-bytes
A specific definition of an Attestation or Certificate defines which 2. Attestor Self-Attestation: 120-bytes
of these are used.
Two Attestation's remove this field: MutualAttestation Section 3.2.4 A specific definition of an Attestation (Appendix A.2) or Certificate
and LinkAttestation Section 3.2.5 as their definition clearly states (Appendix A.3) defines which of these are used.
that the signer is the second party with their HHIT or
SelfAttestation already embedded in the Attestation Data.
3.1.2. Attestation Data A.1.2. Attestation Data
The data being attested to. It can be one of the following forms: The data being attested to. It can be one of the following forms:
1. Claims 1. Claims
2. Assertions 2. Assertions
3. Attestations 3. Attestations
This field is variable length with no limit and specific definitions This field is variable length with no limit and specific definitions
of an Attestation or Certificate indicate the fields, size and of an Attestation (Appendix A.2) or Certificate (Appendix A.3)
ordering of any subfields. indicate the fields, size and ordering of any subfields.
3.1.3. Expiration Timestamp A.1.3. Expiration Timestamp
A UTC timestamp set some time into the future to indicate a point the A UTC timestamp set some time into the future to indicate a point the
Attestation Structure should not be trusted. Attestation Structure should not be trusted.
3.1.4. Signing Timestamp The time delta into the future is of important concern as replay
attacks on during flight could compromise the goals of DRIP.
Attestations and certificates intended for public use and lower in
the tree (importantly any generated for a 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 replays.
A.1.4. Signing Timestamp
A UTC timestamp set to the time when the Attestation Structure was A UTC timestamp set to the time when the Attestation Structure was
signed. signed.
3.1.5. Signature A.1.5. Signature
An EdDSA25519 signature using the signing parties private key over An EdDSA25519 signature using the signing parties private key over
the preceding fields in the Attestation Structure. the preceding fields in the Attestation Structure.
3.2. Attestations Note: the preceding fields of the Attestation Structure
actually form an Assertion, with all fields acting as Claims
3.2.1. Self-Attestation (SA-xx) A.2. Attestations
A.2.1. Self-Attestation (SA-x)
The only attestation to use a claim (the Host Identity) in the The only attestation to use a claim (the Host Identity) in the
Attestation Data with the HHIT acting as the Attestor Identity Attestation Data with the DET acting as the Attestor Identity
Information. Information.
0 1 2 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag | | Entity Tag |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| | | |
| | | |
| Host Identity | | Host Identity |
| | | |
| | | |
| | | |
| | | |
skipping to change at page 8, line 46 skipping to change at page 36, line 46
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 120-bytes Length = 120-bytes
Figure 2: DRIP Self-Attestation Figure 11: DRIP Self-Attestation
3.2.2. Attestation (A-xy) A.2.2. Attestation (A-x.y)
The standard first level DRIP Attestation form using a Self-
Attestations of the signer and of the data being signed.
(Editors Note: blurb here?)
0 1 2 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 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-xx .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
skipping to change at page 9, line 43 skipping to change at page 37, line 44
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 312-bytes Length = 312-bytes
Figure 3: DRIP Attestation Figure 12: DRIP Attestation
3.2.3. Concise Attestation (CA-xy) A.2.3. Concise Attestation (CA-x.y)
In constrained environments and when there is the guarantee of being In constrained environments and when there is the guarantee of being
able to lookup the HHITs to obtain HIs this attestation can be used. able to lookup the DETs to obtain HIs this attestation can be used.
0 1 2 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of X | | Entity Tag of X |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of Y | | Entity Tag of Y |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Trust Timestamp by X | | Trust Timestamp by X |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Signing Timestamp by X | | Signing Timestamp by X |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| | | |
| | | |
| | | |
skipping to change at page 10, line 42 skipping to change at page 38, line 42
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 104-bytes Length = 104-bytes
Figure 4: DRIP Concise Attestation Figure 13: DRIP Concise Attestation
3.2.4. Mutual Attestation (MA-xy) A.2.4. Mutual Attestation (MA-x.y)
An attestation that perform a sign over an existing Attestation where An attestation that perform a sign over an existing Attestation where
the signer is the second party of the embedded attestation. the signer is the second party of the embedded attestation. The DET
of party Y is used as the Attestor Identity Information
This Attestation is one of two that does not fill in the Attestor (Appendix A.1.1).
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
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 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 . . A-xy .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Trust Timestamp by Y | | Trust Timestamp by Y |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Signing Timestamp by Y | | Signing Timestamp by Y |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
skipping to change at page 11, line 39 skipping to change at page 39, line 41
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 384-bytes Length = 400-bytes
Figure 5: DRIP Mutual Attestation
3.2.5. Link Attestation (LA-xy)
An attestations that perform a sign over an existing Figure 14: DRIP Mutual Attestation
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 A.2.5. Link Attestation (LA-x.y)
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 HHIT.
The unique size of this attestation (176-bytes) allows for easy An attestations that perform a sign over an existing Concise
detection and subsequent decoding without issue. Attestation where the signer is the second party of the embedded
attestation. The DET of party Y is used as the Attestor Identity
Information (Appendix A.1.1).
0 1 2 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 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 |
| |
+---------------+---------------+---------------+---------------+
| |
. . . .
. CA-xy . . CA-xy .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Trust Timestamp by Y | | Trust Timestamp by Y |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Signing Timestamp by Y | | Signing Timestamp by Y |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
skipping to change at page 12, line 39 skipping to change at page 40, line 41
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 176-bytes Length = 192-bytes
Figure 6: DRIP Link Attestation Figure 15: DRIP Link Attestation
3.2.6. Broadcast Attestation (BA-xy) A.2.6. Broadcast Attestation (BA-x.y)
Required by DRIP Authentication Formats for Broadcast RID (Editor Required by DRIP Authentication Formats for Broadcast RID
Note: add link to draft here) to satisfy [drip-requirements] GEN-1 ([drip-auth]) to satisfy [drip-requirements] GEN-1 and GEN-3.
and GEN-3.
0 1 2 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of X | | Entity Tag of X |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of Y | | Entity Tag of Y |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| | | |
| | | |
| Host Identity of Y | | Host Identity of Y |
| | | |
| | | |
| | | |
| | | |
skipping to change at page 13, line 51 skipping to change at page 41, line 51
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 136-bytes Length = 136-bytes
Figure 7: DRIP Broadcast Attestation Figure 16: DRIP Broadcast Attestation
3.3. Certificates A.3. Certificates
In DRIP certificates are signed by a third party that has no stake in In DRIP certificates are signed by a third party that has no stake in
the claims/assertions/attestations being attested to. the claims/assertions/attestations being attested to.
It is analogous to a third party in legal system that signs a It is analogous to a third party in legal system that signs a
document as a "witness" and bears no responsibility in the document. document as a "witness" and bears no responsibility in the document.
3.3.1. Attestation Certificate (AC-zxy) A.3.1. Attestation Certificate (AC-z.x.y)
0 1 2 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 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 . . SA-zz .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 15, line 4 skipping to change at page 43, line 4
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 504-bytes Length = 504-bytes
Figure 8: DRIP Attestation Certificate Figure 17: DRIP Attestation Certificate
3.3.2. Concise Certificate (CC-zxy) A.3.2. Concise Certificate (CC-z.x.y)
0 1 2 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of Z | | Entity Tag of Z |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
. . . .
. CA-xy . . CA-xy .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Trust Timestamp by Z | | Trust Timestamp by Z |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 15, line 46 skipping to change at page 43, line 46
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 192-bytes Length = 192-bytes
Figure 9: DRIP Concise Certificate Figure 18: DRIP Concise Certificate
3.3.3. Link Certificate (LC-zxy) A.3.3. Link Certificate (LC-z.x.y)
0 1 2 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 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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Hierarchical | | DRIP |
| Host Identity Tag of Z | | Entity Tag of Z |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
. . . .
. LA-xy . . LA-xy .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Trust Timestamp by Z | | Trust Timestamp by Z |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 16, line 42 skipping to change at page 44, line 42
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 300-bytes Length = 300-bytes
Figure 10: DRIP Link Certificate Figure 19: DRIP Link Certificate
3.3.4. Mutual Certificate (MC-zxy) A.3.4. Mutual Certificate (MC-z.x.y)
0 1 2 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 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 . . SA-zz .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
skipping to change at page 17, line 43 skipping to change at page 45, line 43
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Length = 576-bytes Length = 576-bytes
Figure 11: DRIP Mutual Certificate Figure 20: DRIP Mutual Certificate
4. Registries
4.1. Classes
Under DRIP there 3 classes of registries, with specific variants in
each.
4.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 registries that wish to
act as an RAA.
(Editors Note: we contemplate this is ICAO running this server or
federation of them)
4.1.2. Registered Assigning Authorities
RAA's are the upper hierarchy 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 if
the Root server allows it.
All RAA's use an HDA value of 0 and have their RAA value delegated to
them by the Root.
4.1.2.1. ICAO Registry of 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 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 a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific
ICAO Manufacturer Code (assigned to the manufacturer by ICAO).
A DET can be encoded into a Serial Number (Editor Note: link to -uas-
rid) and when done so this registry would hold a mapping from the
Serial Number to the DET and its artifacts.
Hold RAA value of 1 and HDA values of 1+.
4.1.3.2. Remote ID Registries (RIDR)
Registry that holds the binding between a UAS Session ID (for DRIP
the DET) and the UA Serial Number. The Serial Number MUST have its
access protected to allow only authorized parties to obtain. The
Serial Number SHOULD be encrypted in a way only the authorized party
can decrypt.
As part of the UTM system they also hold a binding between a UAS ID
(Serial Number or Session ID) and an Operational Intent.
(Editors Note: these are contemplated to be part of a USS as a
function or a standalone SDSP in the UTM system)
Hold RAA values of 2+ and HDA values of 1+.
4.2. Federation
(Editors Note: Due to nature of HHIT we could have multiple
registries with same RAA/HDA pairings running and being federated
together. How do we handle this?)
5. DRIP Fully Qualified Domain Names
Under DRIP there are a number of FQDN forms used to allow lookups to
take place.
(Editor Note: copy 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 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 a DET FQDN the 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.
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 a number of resource records, some specific to certain
registries to function.
6.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 their
DET FQDN.
MRA and RIDR servers will also have HIP RRs for their registered
parties (aircraft 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 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 of
matching RAA
4. <hda_value>.<raa_value>.det.remoteid.aero 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 of registering party
2. Populate DNS with required/optional records
3. Populate Database with PII and other info
4. Generate and return required/optional 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 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 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 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 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 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 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 of Aircraft with DET FQDN (Section 5.3) (<sn_det_fqdn> HIP
...)
CERT RRs 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:
1. SelfAttestation: Operator on Operator
2. Operator PII
Optional: TODO
7.6.2. DNS Entries
Optional on RIDR:
HIP RR of Operator
CERT RRs SelfAttestation of Operator, A-ro
7.6.3. Database Entries
TODO
7.6.4. Outputs
Required:
1. 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 of Aircraft with DET FQDN (Section 5.3) (<session_det_fqdn>
HIP ...)
CERT RRs for SelfAttestation 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:
1. MutualCertificate (MC-roa) - using MA-oa
2. ConciseCertificate (CC-roa) - using CA-oa
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 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) and
connectivity it is acceptable under DRIP RID to generate keypairs for
the Aircraft on Operator devices and later securely inject them into
the Aircraft (as defined in Section 8.6.2). The methods to securely
inject and store keypair information in a "secure element" of the
Aircraft is out of scope of this document.
8.1. Overview of Transactions
In DRIP, each Operator MUST generate a Host Identity of the Operator
(HIo) and derived Hierarchical HIT of the Operator (HHITo). These
are registered with a Private Information Registry along with
whatever Operator data (inc. PII) is required by the cognizant CAA
and the registry. In response, the Operator will obtain an
attestation from the Registry, Attestation: Registry on Operator
(A-ro), signed with the Host Identity of the Registry private key
(HIr(priv)) proving such registration.
An Operator may now claim one or more UA.
* An Operator MUST generate a Host Identity of the Aircraft (HIa)
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 by the cognizant CAA and Registry
* Obtain an attestation from the Registry on the Operator and
Aircraft ("AC-roa") signed with the HIr(priv) proving such
registration
* And obtain a broadcast 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 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 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 a
Registry's RAA and HDA is out of scope here. This allows for the
device to generate an HHIT to send to the Registry to be accepted
(thus generating the required Host Identity Claim) or denied.
2 The entity sends to the Registry its HI for it to be hashed and
result in the HHIT. 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 is checking the current Registry
for a collision on the HHIT.
Upon accepting 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 Attestation for the given operation.
If the Registry denied the HI/HHIT pair, because there was a HHIT
collision or any other reason, the Registry MUST signal back to the
device being provisioned that a new HI needs to be generated.
8.3. Registry
(Editor Note: this should break down the individual registrations
between Root/RAA, RAA/HDA and their special variants).
TODO
DRIP UAS RID defines two levels of hierarchy maintained by the
Registration Assigning Authority (RAA) and 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 trust 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 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 and
SelfAttestation: HDA on HDA (SA-hh) with all provisioning requests
from downstream.
8.4. Manufacturer
+--------------+ SA-a0a0 +-----------------+
| Manufacturer | <--------> | Manufacturer CA |
+--------------+ A-ma0 +-----------------+
^ |
| |
| |
SA-a0a0 | | A-ma0
| |
| v
+----------+
| Aircraft |
+----------+
Figure 12: 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. Under DRIP a HHIT can be encoded as
such to be able to convert back and forth between them. This is out
of scope for this document. TODO: link from UAS RID document.
Under DRIP 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 0 on Aircraft 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 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
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ [HIP RR] +---------+
^ |
| |
| |
Coo | | Aro
| |
| 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 +----------+
Figure 14: Standard Provision: Step 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 0 on Aircraft 0
[SA-a0a0]). This new attestation (Attestation: Aircraft 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 |
+----------+
|
|
|
| Token
|
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).
+---------+
| HDA DNS |
+---------+
^
|
| HIP RR
|
|
|
+----------+ <----------------------------+
| Registry | |
+----------+ ------------------------+ |
| | |
| | | Token,
| AC-roaN BA-raN | | A-ma0, A-a0aN
| | |
| | |
v v |
+----------+ +----------+
| Operator | | Aircraft |
+----------+ +----------+
Figure 16: 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 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 |
+----------+
+----------+ +----------+
| Operator | ---------------------> | 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 of the keypair.
+----------+
| Registry |
+----------+
^
|
|
| A-ro, A-ma0, A-a0aN, A-oaN
|
|
+----------+ +----------+
| Operator | <--------------------- | Aircraft |
+----------+ A-ma0, A-a0aN +----------+
Figure 18: Operator Assisted Provision: Step 2
Attestation: Manufacturer on Aircraft 0 (A-ma0) and Attestation:
Aircraft 0 on Aircraft N (A-a0aN) is extracted 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).
+----------+ +---------+
| Registry | ---------> | HDA DNS |
+----------+ HIP RR +---------+
|
|
|
| AC-roaN, BA-raN
|
v
+----------+ +----------+
| Operator | ---------------------> | Aircraft |
+----------+ BA-raN +----------+
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 a
HHIT collision, adding to the HDA if clear and generates
AttestationCertificate: Registry on Operator on Aircraft N (AC-roaN)
and BroadcastAttestation: 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.4. Abbreviations & File Naming Conventions
A special form of provisioning is used when the Aircraft is first The names of attestation and certificates can become quite long and
sold to an Operator. Instead of generating a new keypair, the built tedious to write out. As such this section provides a guide to a
in keypair and certificate done by the Manufacturer is used to somewhat standardized way they are written in text.
provision and register the aircraft to the owner.
For this either Standard or Operator Assisted methods can be used. A.4.1. In Text Abbreviation
9. IANA Considerations In a long form the name of a particular attestation/certification can
be written as follows:
(Editor Note: EPP/RDAP adds to existing registries, CERT RR update, * Self-Attestation: Unmanned Aircraft
HIP RR update)
10. Security Considerations * Attestation: Operator on Aircraft or Attestation: Operator,
Aircraft
TODO * Attestation Certificate: Registry on Operator on Aircraft or
Attestation Certificate: Registry, Operator, Aircraft
11. Contributors 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 for his insights as a pilot * A(Operator, Unmanned Aircraft) or A-op.ua
12. References * AC(Registry, Operator, Aircraft) or AC-reg.op.ua
12.1. Normative References Typical abbreviations for the entity can be used such as Unmanned
Aircraft being shorthanded to ua.
[F3411-19] "Standard Specification for Remote ID and Tracking", A.4.2. File Naming
February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate For file naming of various certificates a similar format to the short
Requirement Levels", BCP 14, RFC 2119, form is used:
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC * sa-{hash of entity}
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References * a-{hash of entity x}_{hash of entity y}
[drip-requirements] * ac-{hash of entity z}_{hash of entity x}_{hash of entity y}
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. Some examples of file names:
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] * sa-79d8a404d48f2ef9.cert
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 Proposed Rule Making on Remote Identification * a-120b8f25b198c1e1_79d8a404d48f2ef9.cert
of Unmanned Aircraft Systems", December 2019.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token * ac-aac6b00abba268b7_120b8f25b198c1e1_79d8a404d48f2ef9.cert
(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, Appendix B. X.509 Certificates
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Authors' Addresses Authors' Addresses
Adam Wiethuechter Adam Wiethuechter
AX Enterprize, LLC AX Enterprize, LLC
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: adam.wiethuechter@axenterprize.com Email: adam.wiethuechter@axenterprize.com
Stuart Card Stuart Card
AX Enterprize, LLC AX Enterprize, LLC
4947 Commercial Drive 4947 Commercial Drive
Yorkville, NY 13495 Yorkville, NY 13495
United States of America United States of America
Email: stu.card@axenterprize.com Email: stu.card@axenterprize.com
Robert Moskowitz Robert Moskowitz
HTT Consulting HTT Consulting
Oak Park, MI 48237 Oak Park, MI 48237
United States of America United States of America
Email: rgm@labs.htt-consult.com Email: rgm@labs.htt-consult.com
Jim Reid Jim Reid
RTFM llp RTFM llp
St Andrews House St Andrews House
382 Hillington Road 382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com Email: jim@rfc1035.com
 End of changes. 87 change blocks. 
1051 lines changed or deleted 1420 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/