draft-ietf-drip-registries-01.txt   draft-ietf-drip-registries-02.txt 
drip Working Group A. Wiethuechter drip Working Group A. Wiethuechter (Editor)
Internet-Draft S. Card Internet-Draft S. Card
Intended status: Standards Track AX Enterprize, LLC Intended status: Standards Track AX Enterprize, LLC
Expires: 8 September 2022 R. Moskowitz Expires: 1 November 2022 R. Moskowitz
HTT Consulting HTT Consulting
J. Reid J. Reid
RTFM llp RTFM llp
7 March 2022 30 April 2022
DRIP Registries DRIP Entity Tag Registration & Lookup
draft-ietf-drip-registries-01 draft-ietf-drip-registries-02
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 8 September 2022. This Internet-Draft will expire on 1 November 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.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abstract Process & Reasoning . . . . . . . . . . . . . . 4 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. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Registries . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Classes . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Root . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Registered Assigning Authorities . . . . . . . . . . 6 3.1.2. Registered Assigning Authorities . . . . . . . . . . 6
3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7 3.1.3. Hierarchial HIT Domain Authorities . . . . . . . . . 7
3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 7 3.2. Key Rollover & Federation . . . . . . . . . . . . . . . . 8
4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 8 4. DRIP Fully Qualified Domain Names . . . . . . . . . . . . . . 8
4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Serial Number . . . . . . . . . . . . . . . . . . . . . . 8
4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Reverse DET . . . . . . . . . . . . . . . . . . . . . . . 9
5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 9 5. Supported DNS Records . . . . . . . . . . . . . . . . . . . . 9
5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. HIP RR . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. CERT RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. NS RR . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. AAAA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.5. SVR RR . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. TLSA RR . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 10 6. Registry Operations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registering a Registry . . . . . . . . . . . . . . . . . 10 6.1. Registering a Registry . . . . . . . . . . . . . . . . . 11
6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 11 6.1.1. Registering an RAA . . . . . . . . . . . . . . . . . 11
6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 12 6.1.2. Registering an IRM . . . . . . . . . . . . . . . . . 12
6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 13 6.1.3. Registering an HDA . . . . . . . . . . . . . . . . . 13
6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 14 6.1.4. Registering an MRA . . . . . . . . . . . . . . . . . 14
6.2. Registering a Serial Number . . . . . . . . . . . . . . . 15 6.2. Registering a Serial Number . . . . . . . . . . . . . . . 15
6.3. Registering an Operator . . . . . . . . . . . . . . . . . 17 6.3. Registering an Operator . . . . . . . . . . . . . . . . . 17
6.4. Registering a Session ID . . . . . . . . . . . . . . . . 18 6.4. Registering a Session ID . . . . . . . . . . . . . . . . 18
6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 20 6.4.1. Standard Provisioning . . . . . . . . . . . . . . . . 20
6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 22 6.4.2. Operator Assisted Provisioning . . . . . . . . . . . 22
6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 23 6.4.3. Initial Provisioning . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 15 skipping to change at page 3, line 15
7.3. EPP Transform Commands . . . . . . . . . . . . . . . . . 24 7.3. EPP Transform Commands . . . . . . . . . . . . . . . . . 24
7.3.1. EPP <create> Command . . . . . . . . . . . . . . . . 24 7.3.1. EPP <create> Command . . . . . . . . . . . . . . . . 24
7.3.2. EPP <delete> Command . . . . . . . . . . . . . . . . 28 7.3.2. EPP <delete> Command . . . . . . . . . . . . . . . . 28
7.3.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 30 7.3.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 30
7.3.4. EPP <transfer> Command . . . . . . . . . . . . . . . 30 7.3.4. EPP <transfer> Command . . . . . . . . . . . . . . . 30
7.3.5. EPP <update> Command . . . . . . . . . . . . . . . . 30 7.3.5. EPP <update> Command . . . . . . . . . . . . . . . . 30
8. RDAP Definitions . . . . . . . . . . . . . . . . . . . . . . 30 8. RDAP Definitions . . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 30 10.1. DET Generation . . . . . . . . . . . . . . . . . . . . . 30
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 33 Appendix A. DRIP Attestations & Certificates . . . . . . . . . . 33
A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 33 A.1. Attestation Structure . . . . . . . . . . . . . . . . . . 33
A.1.1. Attestor Identity Information . . . . . . . . . . . . 34 A.1.1. Attestor Identity Information . . . . . . . . . . . . 34
A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 34 A.1.2. Attestation Data . . . . . . . . . . . . . . . . . . 34
A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 34 A.1.3. Expiration Timestamp . . . . . . . . . . . . . . . . 34
A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 35 A.1.4. Signing Timestamp . . . . . . . . . . . . . . . . . . 35
A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 35 A.1.5. Signature . . . . . . . . . . . . . . . . . . . . . . 35
A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 35 A.2. Attestations . . . . . . . . . . . . . . . . . . . . . . 35
A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 35 A.2.1. Self-Attestation (SA-x) . . . . . . . . . . . . . . . 35
A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 36 A.2.2. Attestation (A-x.y) . . . . . . . . . . . . . . . . . 36
skipping to change at page 3, line 42 skipping to change at page 3, line 43
A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 40 A.2.6. Broadcast Attestation (BA-x.y) . . . . . . . . . . . 40
A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 42 A.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 42
A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 42 A.3.1. Attestation Certificate (AC-z.x.y) . . . . . . . . . 42
A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 43 A.3.2. Concise Certificate (CC-z.x.y) . . . . . . . . . . . 43
A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 43 A.3.3. Link Certificate (LC-z.x.y) . . . . . . . . . . . . . 43
A.3.4. Mutual Certificate (MC-z.x.y) . . . . . . . . . . . . 44 A.3.4. Mutual Certificate (MC-z.x.y) . . . . . . . . . . . . 44
A.4. Abbreviations & File Naming Conventions . . . . . . . . . 45 A.4. Abbreviations & File Naming Conventions . . . . . . . . . 45
A.4.1. In Text Abbreviation . . . . . . . . . . . . . . . . 46 A.4.1. In Text Abbreviation . . . . . . . . . . . . . . . . 46
A.4.2. File Naming . . . . . . . . . . . . . . . . . . . . . 46 A.4.2. File Naming . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 46 Appendix B. X.509 Certificates . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Appendix C. Blockchain-based Registries . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 4, line 47 skipping to change at page 4, line 47
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 1.1. Abstract Process & Reasoning
In DRIP each entity (registries, operators and aircraft) is expected In DRIP each entity (registry, operator and aircraft) is expected to
to generate a full DRIP Entity ID [drip-rid] on the local device generate a full DRIP Entity ID [drip-rid] on the local device their
their key is expected to be used. These are registered with a Public key is expected to be used. These are registered with a Public
Information Registry within the hierarchy along with whatever data is Information Registry within the hierarchy along with whatever data is
required by the cognizant CAA and the registry. Any PII is stored in required by the cognizant CAA and the registry. Any PII is stored in
a Private Information Registry protected through industry practice a Private Information Registry protected through industry practice
AAA or better. In response, the entity will obtain an attestation or AAA or better. In response, the entity will obtain an attestation or
certificate from the registry proving such registration. certificate from the registry proving such registration.
Manufacturers that wish to participate in DRIP should not only Manufacturers that wish to participate in DRIP should not only
support DRIP as a Session ID type for their aircraft but also 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 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) 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 could still use DRIP and most of its benefits. Even if DRIP is not
supported for Serial Numbers by a Manufacturer it is hoped that they supported for Serial Numbers by a Manufacturer it is hoped that they
would still run a registry to store their Serial Numbers and allow would still run a registry to store their Serial Numbers and allow
look ups for generic model information. This look up could be look ups for generic model information. This look up could be
especially helpful in UTM for Situational Awareness when an aircraft especially helpful in UTM for Situational Awareness when an aircraft
flying with a Serial Number is detected and allow for an aircraft flying with a Serial Number is detected and allow for an aircraft
profile to be displayed. profile to be displayed.
Operators are registered with a number of registries or their Operators are registered with a number of registries or their
regional RAA. This acts as a verification check when a user performs regional RAA. This acts as a verification check when a user performs
other registration operations; such as provisioning an aircraft with other registration operations; such as provisioning an aircraft with
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Figure 1: Registry Hierarchy Figure 1: Registry Hierarchy
3.1.1. Root 3.1.1. Root
This is a special registry holding the RAA value of 0 and HDA value 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 of 0. It delegates out RAA values only to registries that wish to
act as an RAA. act as an RAA.
3.1.2. Registered Assigning Authorities 3.1.2. Registered Assigning Authorities
RAA's are the upper hierarchy in DRIP. Most are contemplated to be RAA's are the upper hierarchy in DRIP (denoted by a 14-bit field
Civil Aviation Authorities (CAAs) that then delegate HDAs to manage (16,384 RAAs) of a DET). An RAA is a business or organization that
their NAS. This is does not preclude other entities to operate an manages a registry of HDAs (Section 3.1.3). Most are contemplated to
RAA if the Root server allows it. be Civil Aviation Authorities (CAA), such as the Federal Aviation
Authority (FAA), 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 The ICAO registration process will be available from ICAO. Once ICAO
them by the Root. accepts an RAA, it will assign a number and create a zone delegation
under the uas.icao.int. DNS zone for the RAA.
As HHITs may be used in many different domains, RAA should be
allocated in blocks with consideration on the likely size of a
particular usage. Alternatively, different prefixes can be used to
separate different domains of use of HHITs.
An RAA must provide a set of services to allocate HDAs to
organizations. It must have a public policy on what is necessary to
obtain an HDA. It must maintain a DNS zone minimally for discovering
HID RVS servers. All RAA's 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) 3.1.2.1. ICAO Registry of Manufacturer's (IRM)
A special RAA that hands out HDA values to participating A special RAA that hands out HDA values to participating
Manufacturer's that hold an ICAO Manufacturer Code used in ANSI Manufacturer's that hold an ICAO Manufacturer Code used in ANSI
CTA2063-A Serial Numbers. CTA2063-A Serial Numbers.
It is holds the RAA value of 1 and HDA value of 0. It is holds the RAA value of 1 and HDA value of 0.
3.1.3. Hierarchial HIT Domain Authorities 3.1.3. Hierarchial HIT Domain Authorities
An HDA may be an ISP or any third party that takes on the business to
provide RVS and other needed services such as those required for HIP-
enabled devices.
The HDA is an 14-bit field (16,384 HDAs per RAA) of a DET assigned by
an RAA. An HDA should maintain a set of RVS servers for UAS clients
that may use HIP. How this is done and scales to the potentially
millions of customers are outside the scope of this document. This
service should be discoverable through the DNS zone maintained by the
HDA's RAA.
An RAA may assign a block of values to an individual organization.
This is completely up to the individual RAA's published policy for
delegation. Such policy is out of scope.
3.1.3.1. Manufacturer's Registry of Aircraft (MRA) 3.1.3.1. Manufacturer's Registry of Aircraft (MRA)
A registry (HDA) run by a manufacturer of UAS systems that A registry (HDA) run by a manufacturer of UAS systems that
participate in Remote ID. Stores UAS Serial Numbers under a specific participate in Remote ID. Stores UAS Serial Numbers under a specific
ICAO Manufacturer Code (assigned to the manufacturer by ICAO). ICAO Manufacturer Code (assigned to the manufacturer by ICAO).
A DET can be encoded into a Serial Number (see [drip-rid]) and this 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 registry would hold a mapping from the Serial Number to the DET and
its artifacts. its artifacts.
skipping to change at page 31, line 26 skipping to change at page 31, line 26
Upon accepting a HI/DET pair the registry MUST populate the required 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 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 (such as TXT and CERT). The registry MUST also generate the
appropriate attestations/certificates for the given operation. appropriate attestations/certificates for the given operation.
If the registry denied the HI/DET pair, because there was a DET 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 collision or any other reason, the registry MUST signal back to the
device being provisioned that a new HI needs to be generated. device being provisioned that a new HI needs to be generated.
11. Contributors 11. Acknowledgements
* Scott Hollenbeck for his guidance with EPP/RDAP * Scott Hollenbeck for his guidance with EPP/RDAP
12. Contributors
* Andrei Gurtov for his insights as a pilot * Andrei Gurtov for his insights as a pilot
12. References 13. References
12.1. Normative References 13.1. Normative References
[F3411-19] "Standard Specification for Remote ID and Tracking", [F3411-19] "Standard Specification for Remote ID and Tracking",
February 2020. February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 13.2. Informative References
[drip-arch] [drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S., Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft, (DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-20, 28 January 2022, draft-ietf-drip-arch-22, 21 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-arch- <https://www.ietf.org/archive/id/draft-ietf-drip-arch-
20.txt>. 22.txt>.
[drip-auth] [drip-auth]
Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
Authentication Formats & Protocols for Broadcast Remote Authentication Formats & Protocols for Broadcast Remote
ID", Work in Progress, Internet-Draft, draft-ietf-drip- ID", Work in Progress, Internet-Draft, draft-ietf-drip-
auth-04, 20 December 2021, auth-09, 30 April 2022, <https://www.ietf.org/archive/id/
<https://www.ietf.org/archive/id/draft-ietf-drip-auth- draft-ietf-drip-auth-09.txt>.
04.txt>.
[drip-requirements] [drip-requirements]
Card, S. W., Wiethuechter, A., Moskowitz, R., and A. Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP) Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", Work in Progress, Internet- Requirements and Terminology", RFC 9153,
Draft, draft-ietf-drip-reqs-18, 8 September 2021, DOI 10.17487/RFC9153, February 2022,
<https://www.ietf.org/archive/id/draft-ietf-drip-reqs- <https://www.rfc-editor.org/info/rfc9153>.
18.txt>.
[drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A. [drip-rid] Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft, Gurtov, "UAS Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-uas-rid-01, 9 September 2020, draft-ietf-drip-uas-rid-01, 9 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid- <https://www.ietf.org/archive/id/draft-ietf-drip-uas-rid-
01.txt>. 01.txt>.
[hhit-registries] [hhit-registries]
Moskowitz, R., Card, S. W., and A. Wiethuechter, Moskowitz, R., Card, S. W., and A. Wiethuechter,
"Hierarchical HIT Registries", Work in Progress, Internet- "Hierarchical HIT Registries", Work in Progress, Internet-
skipping to change at page 46, line 50 skipping to change at page 47, line 4
Some examples of file names: Some examples of file names:
* sa-79d8a404d48f2ef9.cert * sa-79d8a404d48f2ef9.cert
* a-120b8f25b198c1e1_79d8a404d48f2ef9.cert * a-120b8f25b198c1e1_79d8a404d48f2ef9.cert
* ac-aac6b00abba268b7_120b8f25b198c1e1_79d8a404d48f2ef9.cert * ac-aac6b00abba268b7_120b8f25b198c1e1_79d8a404d48f2ef9.cert
Appendix B. X.509 Certificates Appendix B. X.509 Certificates
Appendix C. Blockchain-based Registries
The implementation of the registries and Network Remote
Identification (Network RID; identify a UA through the network) in
DRIP is yet to be determined. Blockchain, being synonymous with
ledger, is a technology that could naturally fulfil the role of a
registry, while simultaneously offering its benefits such as
auditability, persistency and decentralization. We suggest that
blockchain is an ample candidate to be used as registry within DRIP.
We also show that it can be used to effectively leverage Network RID
in certain scenarios. Thus 1) We propose a novel drone ID
architecture based on Hyperledger Iroha and describe its proof-of-
concept implementation with DRIP. 2) Its performance and scalability
is empirically evaluated. 3) We perform an informal security analysis
of the system against various types of attacks [Secure Drone
Identification with Hyperledger Iroha
(https://doi.org/10.1145/3479243.3487305)].
Figure 1: Architecture using blockchain as registry for DRIP
The proposed architecture is presented in Fig. 1. It consists of the
usual actors in a UAS network, along with the blockchain registry
based on Hyperledger Iroha. Key components: o Authorized users
(administrators) can register new UAs to the network, and store with
them any relevant data such as public keys and certificates.
Drones can either send location updates directly to the blockchain,
given that they are connected to the Internet, or send location
updates to their connected Ground Control Station (GCS) that forwards
it on behalf of the drones. o Observers can receive drone messages
either through bluetooth and WiFi broadcasts from drones, or by
polling the blockchain. They can also fetch the public key
associated with a drone in order to validate its messages. o The
blockchain network and its nodes are an entirely separate entity, no
other actor participates in the consensus of new blocks.
Actors within DRIP (except observers) will be registered as accounts
on the blockchain network. Each of these accounts will have their
DRIP identities, certificates and public keys stored and available so
that they can be validated and used for validation by any account on
the blockchain. Note that DRIP crypto key-pairs are separate from
the blockchain crypto key-pairs. DRIP key-pairs are used to sign,
verify and validate DRIP identities and messages, while the
blockchain key-pairs are used to sign, verify and validate
transactions on the blockchain.
The DRIP requirements for a registry are the following: (1) REG-1:
Public lookup (2) REG-2: Private lookup (3) REG-3: Provisioning (of
static/dynamic data of UAs) (4) REG-4: AAA Policy
REG-1 & REG-2. In Hyperledger Iroha, accounts are created on
domains. The same account name can be used for multiple domains, and
these are seen as separate accounts on Iroha. PII for an account can
therefore be stored on a separate account (with the same account
name) existing on a separate domain, that only allows certain
accounts to view its account details. Accordingly, a registry using
Iroha would need at least two domains associated with it for any
given account, one for public lookup and one for private lookup.
REG-3 & REG-4. The details for an account are set with a key/value
pair. Key/value pairs can not be removed once they are set, values
can only be modified through the corresponding key. Furthermore, the
account that sets a key/value pair is included in the account details
as a key/value pair itself, meaning one account can not modify
details set by another account. See Listing 1 for clarification.
Notice that both accounts have set the same key but contain different
values. This sort of implementation supports both non-repudiation,
but also trust in the sense that a drone (assuming the drone is not
compromised) can always trust its own data, and does not have to
interpret data coming from other accounts. Similarly, other accounts
accessing another account's data can trust that it is set by the
corresponding account (e.g. fetching gps data).
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
 End of changes. 28 change blocks. 
44 lines changed or deleted 149 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/