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