< draft-ietf-drip-rid-23.txt		draft-ietf-drip-rid-24.txt >
	DRIP R. Moskowitz		DRIP R. Moskowitz
	Internet-Draft HTT Consulting		Internet-Draft HTT Consulting
	Updates: 7401, 7343 (if approved) S. Card		Updates: 7401, 7343 (if approved) S. Card
	Intended status: Standards Track A. Wiethuechter		Intended status: Standards Track A. Wiethuechter
	Expires: 23 October 2022 AX Enterprize, LLC		Expires: 26 October 2022 AX Enterprize, LLC
	A. Gurtov		A. Gurtov
	Linköping University		Linköping University
	21 April 2022		24 April 2022
	DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)		DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
	draft-ietf-drip-rid-23		draft-ietf-drip-rid-24
	Abstract		Abstract
	This document describes the use of Hierarchical Host Identity Tags		This document describes the use of Hierarchical Host Identity Tags
	(HHITs) as self-asserting IPv6 addresses and thereby a trustable		(HHITs) as self-asserting IPv6 addresses and thereby a trustable
	identifier for use as the Unmanned Aircraft System Remote		identifier for use as the Unmanned Aircraft System Remote
	Identification and tracking (UAS RID).		Identification and tracking (UAS RID).
	This document updates RFC7401 and RFC7343.		This document updates RFC7401 and RFC7343.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 23 October 2022.		This Internet-Draft will expire on 26 October 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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. HHIT Statistical Uniqueness different from UUID or X.509		1.1. HHIT Statistical Uniqueness different from UUID or X.509
	Subject . . . . . . . . . . . . . . . . . . . . . . . . . 4		Subject . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4		2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
	2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4		2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
	2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	3. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 5		3. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 6
	3.1. HHIT Prefix for RID Purposes . . . . . . . . . . . . . . 7		3.1. HHIT Prefix for RID Purposes . . . . . . . . . . . . . . 7
	3.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 7		3.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. HDA custom HIT Suite IDs . . . . . . . . . . . . . . 7		3.2.1. HDA custom HIT Suite IDs . . . . . . . . . . . . . . 8
	3.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 8		3.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 8
	3.3.1. The Registered Assigning Authority (RAA) . . . . . . 8		3.3.1. The Registered Assigning Authority (RAA) . . . . . . 8
	3.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 9		3.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 9
	3.4. Edward-Curve Digital Signature Algorithm for HHITs . . . 9		3.4. Edward-Curve Digital Signature Algorithm for HHITs . . . 9
	3.4.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 9		3.4.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 11		3.4.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 11
	3.5. ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . . 11		3.5. ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . . 11
	3.5.1. Adding Additional Information to the ORCHID . . . . . 12		3.5.1. Adding Additional Information to the ORCHID . . . . . 12
	3.5.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . 13		3.5.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . 13
	3.5.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . 15		3.5.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . 15
	3.5.4. Decoding ORCHIDs for HIPv2 . . . . . . . . . . . . . 15		3.5.4. Decoding ORCHIDs for HIPv2 . . . . . . . . . . . . . 15
	4. Hierarchical HITs as DRIP Entity Tags . . . . . . . . . . . . 15		4. Hierarchical HITs as DRIP Entity Tags . . . . . . . . . . . . 15
	4.1. Nontransferablity of DETs . . . . . . . . . . . . . . . . 15		4.1. Nontransferablity of DETs . . . . . . . . . . . . . . . . 15
	4.2. Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . . 16		4.2. Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . . 16
	4.3. Remote ID DET as one Class of Hierarchical HITs . . . . . 17		4.3. Remote ID DET as one Class of Hierarchical HITs . . . . . 17
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	4.5. DRIP Entity Tag (DET) Registry . . . . . . . . . . . . . 17		4.5. DRIP Entity Tag (DET) Registry . . . . . . . . . . . . . 17
	4.6. Remote ID Authentication using DETs . . . . . . . . . . . 18		4.6. Remote ID Authentication using DETs . . . . . . . . . . . 18
	5. DRIP Entity Tags (DETs) in DNS . . . . . . . . . . . . . . . 18		5. DRIP Entity Tags (DETs) in DNS . . . . . . . . . . . . . . . 18
	6. Other UTM Uses of HHITs Beyond DET . . . . . . . . . . . . . 19		6. Other UTM Uses of HHITs Beyond DET . . . . . . . . . . . . . 19
	7. Summary of Addressed DRIP Requirements . . . . . . . . . . . 20		7. Summary of Addressed DRIP Requirements . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8.1. New Well-Known IPv6 prefix for DETs . . . . . . . . . . . 20		8.1. New Well-Known IPv6 prefix for DETs . . . . . . . . . . . 20
	8.2. New IANA DRIP Registry . . . . . . . . . . . . . . . . . 21		8.2. New IANA DRIP Registry . . . . . . . . . . . . . . . . . 21
	8.3. IANA CGA Registry Update . . . . . . . . . . . . . . . . 21		8.3. IANA CGA Registry Update . . . . . . . . . . . . . . . . 21
	8.4. IANA HIP Registry Updates . . . . . . . . . . . . . . . . 22		8.4. IANA HIP Registry Updates . . . . . . . . . . . . . . . . 22
	8.5. IANA IPSECKEY Registry Update . . . . . . . . . . . . . . 22		8.5. IANA IPSECKEY Registry Update . . . . . . . . . . . . . . 23
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 23		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	9.1. DET Trust in ASTM messaging . . . . . . . . . . . . . . . 24		9.1. DET Trust in ASTM messaging . . . . . . . . . . . . . . . 25
	9.2. Privacy Considerations . . . . . . . . . . . . . . . . . 25		9.2. DET Revocation . . . . . . . . . . . . . . . . . . . . . 25
	9.3. Collision Risks with DETs . . . . . . . . . . . . . . . . 26		9.3. Privacy Considerations . . . . . . . . . . . . . . . . . 25
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		9.4. Collision Risks with DETs . . . . . . . . . . . . . . . . 26
	10.1. Normative References . . . . . . . . . . . . . . . . . . 26		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . 27		10.1. Normative References . . . . . . . . . . . . . . . . . . 27
	Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 30		10.2. Informative References . . . . . . . . . . . . . . . . . 28
			Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 31
	Appendix B. The 14/14 HID split . . . . . . . . . . . . . . . . 31		Appendix B. The 14/14 HID split . . . . . . . . . . . . . . . . 31
	Appendix C. Calculating Collision Probabilities . . . . . . . . 32		Appendix C. Calculating Collision Probabilities . . . . . . . . 33
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	DRIP Requirements [RFC9153] describe an Unmanned Aircraft System		DRIP Requirements [RFC9153] describe an Unmanned Aircraft System
	Remote ID (UAS ID) as unique (ID-4), non-spoofable (ID-5), and		Remote ID (UAS ID) as unique (ID-4), non-spoofable (ID-5), and
	identify a registry where the ID is listed (ID-2); all within a		identify a registry where the ID is listed (ID-2); all within a
	20-character identifier (ID-1).		20-character identifier (ID-1).
	This document describes (per Section 3 of [drip-architecture]) the		This document describes (per Section 3 of [drip-architecture]) the
	use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-		use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-
	skipping to change at page 19, line 41 ¶		skipping to change at page 19, line 41 ¶
	a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int.		a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int.
	A 'standard' ip6.arpa RR has the advantage of only one Registry		A 'standard' ip6.arpa RR has the advantage of only one Registry
	service supported.		service supported.
	$ORIGIN 5.0.4.1.0.8.2.0.0.3.0.0.1.0.0.2.ip6.arpa.		$ORIGIN 5.0.4.1.0.8.2.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		e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR
	a3ad1952ad0a69e.20.10.det.rid.icao.int.		a3ad1952ad0a69e.20.10.det.rid.icao.int.
			This DNS entry for the DET can also provide a revocation service.
			For example, instead of returning the HI RR it may return some record
			showing that the HI (and thus DET) has been revoked. Guidance on
			revocation service will be provided in [drip-registries].
	6. Other UTM Uses of HHITs Beyond DET		6. Other UTM Uses of HHITs Beyond DET
	HHITs will be used within the UTM architecture beyond DET (and USS in		HHITs will be used within the UTM architecture beyond DET (and USS in
	UA ID registration and authentication), for example, as a Ground		UA ID registration and authentication), for example, as a Ground
	Control Station (GCS) HHIT ID. Some GCS will use its HHIT for		Control Station (GCS) HHIT ID. Some GCS will use its HHIT for
	securing its Network Remote ID (to USS HHIT) and Command and Control		securing its Network Remote ID (to USS HHIT) and Command and Control
	(C2, Section 2.2.2 of [RFC9153]) transports.		(C2, Section 2.2.2 of [RFC9153]) transports.
	Observers may have their own HHITs to facilitate UAS information		Observers may have their own HHITs to facilitate UAS information
	retrieval (e.g., for authorization to private UAS data). They could		retrieval (e.g., for authorization to private UAS data). They could
	skipping to change at page 21, line 37 ¶		skipping to change at page 21, line 37 ¶
	Parameters" registry in [IANA-HIP]. Future additions to this		Parameters" registry in [IANA-HIP]. Future additions to this
	subregistry are to be made through IETF Review (Section 4.8 of		subregistry are to be made through IETF Review (Section 4.8 of
	[RFC8126]). The following HHIT Suite IDs are defined:		[RFC8126]). The following HHIT Suite IDs are defined:
	HHIT Suite Value		HHIT Suite Value
	RESERVED 0		RESERVED 0
	RSA,DSA/SHA-256 1 [RFC7401]		RSA,DSA/SHA-256 1 [RFC7401]
	ECDSA/SHA-384 2 [RFC7401]		ECDSA/SHA-384 2 [RFC7401]
	ECDSA_LOW/SHA-1 3 [RFC7401]		ECDSA_LOW/SHA-1 3 [RFC7401]
	EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED)		EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED)
	RESERVED 16
	HDA Private Use 1 TBD4 (suggested value 254)		HDA Private Use 1 TBD4 (suggested value 254)
	HDA Private Use 2 TBD5 (suggested value 255)		HDA Private Use 2 TBD5 (suggested value 255)
			The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
			replicated as HIT Suite IDs (Section 8.4) as is TBD3 here. Higher
			values (32 - 255) are for those Suite IDs that need not or cannot
			be accommodated as a HIT Suite ID.
	8.3. IANA CGA Registry Update		8.3. IANA CGA Registry Update
	This document requests that this document be added to the reference		This document requests that this document be added to the reference
	field for the "CGA Extension Type Tags" registry [IANA-CGA], where		field for the "CGA Extension Type Tags" registry [IANA-CGA], where
	IANA registers the following Context ID:		IANA registers the following Context ID:
	Context ID:		Context ID:
	The Context ID (Section 3) shares the namespace introduced for CGA		The Context ID (Section 3) shares the namespace introduced for CGA
	Type Tags. Defining new Context IDs follow the rules in Section 8		Type Tags. Defining new Context IDs follow the rules in Section 8
	of [RFC3972]:		of [RFC3972]:
	skipping to change at page 22, line 45 ¶		skipping to change at page 23, line 5 ¶
	HIT Suite ID:		HIT Suite ID:
	This document defines the new HIT Suite of EdDSA/cSHAKE with value		This document defines the new HIT Suite of EdDSA/cSHAKE with value
	TBD3 (suggested: 5) (Section 3.4.2) in the "HIT Suite ID"		TBD3 (suggested: 5) (Section 3.4.2) in the "HIT Suite ID"
	subregistry of the "Host Identity Protocol (HIP) Parameters"		subregistry of the "Host Identity Protocol (HIP) Parameters"
	registry.		registry.
	HIT Suite Value		HIT Suite Value
	EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED)		EdDSA/cSHAKE128 TBD3 (suggested value 5) (RECOMMENDED)
			The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
			MUST be replicated as HHIT Suite IDs (Section 8.2) as is TBD3
			here.
	8.5. IANA IPSECKEY Registry Update		8.5. IANA IPSECKEY Registry Update
	This document requests IANA to make the following change to the		This document requests IANA to make the following change to the
	"IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:		"IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:
	IPSECKEY:		IPSECKEY:
	This document defines the new IPSECKEY value TBD2 (suggested: 4)		This document defines the new IPSECKEY value TBD2 (suggested: 4)
	(Section 3.4.1.2) in the "Algorithm Type Field" subregistry of the		(Section 3.4.1.2) in the "Algorithm Type Field" subregistry of the
	"IPSECKEY Resource Record Parameters" registry.		"IPSECKEY Resource Record Parameters" registry.
	Value Description		Value Description
	TBD2 (suggested value 4)		TBD2 (suggested value 4)
	An EdDSA key is present, in the format defined in [RFC8080]		An EdDSA key is present, in the format defined in [RFC8080]
	9. Security Considerations		9. Security Considerations
	The 64-bit hash in HHITs presents a real risk of second pre-image		The 64-bit hash in HHITs presents a real risk of second pre-image
	cryptographic hash attack Section 9.3. There are no known (to the		cryptographic hash attack Section 9.4. There are no known (to the
	authors) studies of hash size to cryptographic hash attacks. A		authors) studies of hash size to cryptographic hash attacks. A
	Python script is available to randomly generate 1M HHITs that did not		Python script is available to randomly generate 1M HHITs that did not
	produce a hash collision which is a simpler attack than a first or		produce a hash collision which is a simpler attack than a first or
	second pre-image attack.		second pre-image attack.
	However, with today's computing power, producing 2^64 EdDSA keypairs		However, with today's computing power, producing 2^64 EdDSA keypairs
	and then generating the corresponding HHIT is economically feasible.		and then generating the corresponding HHIT is economically feasible.
	Consider that a *single* bitcoin mining ASIC can do on the order of		Consider that a *single* bitcoin mining ASIC can do on the order of
	2^46 sha256 hashes a second or about 2^62 hashes in a single day.		2^46 sha256 hashes a second or about 2^62 hashes in a single day.
	The point being, 2^64 is not prohibitive, especially as this can be		The point being, 2^64 is not prohibitive, especially as this can be
	skipping to change at page 23, line 41 ¶		skipping to change at page 24, line 7 ¶
	Now it should be noted that the 2^64 attempts is for stealing a		Now it should be noted that the 2^64 attempts is for stealing a
	specific HHIT. Consider a scenario of a street photography company		specific HHIT. Consider a scenario of a street photography company
	with 1,024 UAs (each with its own HHIT); you'd be happy stealing any		with 1,024 UAs (each with its own HHIT); you'd be happy stealing any
	one of them. Then rather than needing to satisfy a 64-bit condition		one of them. Then rather than needing to satisfy a 64-bit condition
	on the cSHAKE128 output, you need only satisfy what is equivalent to		on the cSHAKE128 output, you need only satisfy what is equivalent to
	a 54-bit condition (since there are 2^10 more opportunities for		a 54-bit condition (since there are 2^10 more opportunities for
	success).		success).
	Thus, although the probability of a collision or pre-image attack is		Thus, although the probability of a collision or pre-image attack is
	low in a collection of 1,024 HHITs out of a total population of 2^64,		low in a collection of 1,024 HHITs out of a total population of 2^64,
	per Section 9.3, it is computationally and economically feasible.		per Section 9.4, it is computationally and economically feasible.
	Therefore, the HHIT registration and HHIT/HI registration validation		Therefore, the HHIT registration and HHIT/HI registration validation
	is strongly recommended.		is strongly recommended.
	The DET Registry services effectively block attempts to "take over"		The DET Registry services effectively block attempts to "take over"
	or "hijack" a DET. It does not stop a rogue attempting to		or "hijack" a DET. It does not stop a rogue attempting to
	impersonate a known DET. This attack can be mitigated by the		impersonate a known DET. This attack can be mitigated by the
	receiver of messages containing DETs using DNS to find the HI for the		receiver of messages containing DETs using DNS to find the HI for the
	DET. As such, use of DNSSEC by the DET registries is recommended to		DET. As such, use of DNSSEC by the DET registries is recommended to
	provide trust in HI retrieval.		provide trust in HI retrieval.
	skipping to change at page 25, line 22 ¶		skipping to change at page 25, line 33 ¶
	Proof of UA transmission comes when the Authentication Message		Proof of UA transmission comes when the Authentication Message
	includes proofs for the ASTM Location/Vector Message (Msg Type 0x1)		includes proofs for the ASTM Location/Vector Message (Msg Type 0x1)
	and the observer can see the UA or that information is validated by		and the observer can see the UA or that information is validated by
	ground multilateration. Only then does an observer gain full trust		ground multilateration. Only then does an observer gain full trust
	in the DET of the UA.		in the DET of the UA.
	DETs obtained via the Network RID path provides a different approach		DETs obtained via the Network RID path provides a different approach
	to trust. Here the UAS SHOULD be securely communicating to the USS,		to trust. Here the UAS SHOULD be securely communicating to the USS,
	thus asserting DET trust.		thus asserting DET trust.
	9.2. Privacy Considerations		9.2. DET Revocation
			The DNS entry for the DET can also provide a revocation service. For
			example, instead of returning the HI RR it may return some record
			showing that the HI (and thus DET) has been revoked. Guidance on
			revocation service will be provided in [drip-registries].
			9.3. Privacy Considerations
	There is no expectation of privacy for DETs; it is not part of the		There is no expectation of privacy for DETs; it is not part of the
	privacy normative requirements listed in, Section 4.3.1, of		privacy normative requirements listed in, Section 4.3.1, of
	[RFC9153]. DETs are broadcast in the clear over the open air via		[RFC9153]. DETs are broadcast in the clear over the open air via
	Bluetooth and Wi-Fi. They will be collected and collated with other		Bluetooth and Wi-Fi. They will be collected and collated with other
	public information about the UAS. This will include DET registration		public information about the UAS. This will include DET registration
	information and location and times of operations for a DET. A DET		information and location and times of operations for a DET. A DET
	can be for the life of a UA if there is no concern about DET/UA		can be for the life of a UA if there is no concern about DET/UA
	activity harvesting.		activity harvesting.
	skipping to change at page 26, line 20 ¶		skipping to change at page 26, line 38 ¶
	MAC may mean a changing IP address to further impact the UAS		MAC may mean a changing IP address to further impact the UAS
	bindings. Finally, an encryption wrapper's identifier (such as ESP		bindings. Finally, an encryption wrapper's identifier (such as ESP
	[RFC4303] SPI) would need to change per operation to insure operation		[RFC4303] SPI) would need to change per operation to insure operation
	tracking separation.		tracking separation.
	Creating and maintaining UAS operational privacy is a multifaceted		Creating and maintaining UAS operational privacy is a multifaceted
	problem. Many communication pieces need to be considered to truly		problem. Many communication pieces need to be considered to truly
	create a separation between UA operations. Simply changing the DET		create a separation between UA operations. Simply changing the DET
	only starts the changes that need to be implemented.		only starts the changes that need to be implemented.
	9.3. Collision Risks with DETs		These privacy realities may present challenges for the EU U-space
			(Appendix A) program.
			9.4. Collision Risks with DETs
	The 64-bit hash size does have an increased risk of collisions over		The 64-bit hash size does have an increased risk of collisions over
	the 96-bit hash size used for the other HIT Suites. There is a 0.01%		the 96-bit hash size used for the other HIT Suites. There is a 0.01%
	probability of a collision in a population of 66 million. The		probability of a collision in a population of 66 million. The
	probability goes up to 1% for a population of 663 million. See		probability goes up to 1% for a population of 663 million. See
	Appendix C for the collision probability formula.		Appendix C for the collision probability formula.
	However, this risk of collision is within a single "Additional		However, this risk of collision is within a single "Additional
	Information" value, i.e., a RAA/HDA domain. The UAS/USS registration		Information" value, i.e., a RAA/HDA domain. The UAS/USS registration
	process should include registering the DET and MUST reject a		process should include registering the DET and MUST reject a
	skipping to change at page 30, line 46 ¶		skipping to change at page 31, line 26 ¶
	Due to the high privacy requirements, a casual observer can only		Due to the high privacy requirements, a casual observer can only
	query U-space if it is aware of a UA seen in a certain area. A		query U-space if it is aware of a UA seen in a certain area. A
	general observer can use a public U-space portal to query UA details		general observer can use a public U-space portal to query UA details
	based on the UA transmitted "Remote identification" signal. Direct		based on the UA transmitted "Remote identification" signal. Direct
	remote identification (DRID) is based on a signal transmitted by the		remote identification (DRID) is based on a signal transmitted by the
	UA directly. Network remote identification (NRID) is only possible		UA directly. Network remote identification (NRID) is only possible
	for UAs being tracked by U-Space and is based on the matching the		for UAs being tracked by U-Space and is based on the matching the
	current UA position to one of the tracks.		current UA position to one of the tracks.
			This is potentially a contrary expectation as that presented in
			Section 9.3. U-space will have to deal with this reality within the
			GDPR regulations. Still, DETs as defined here present a large step
			in the right direction for agnostic IDs.
	The project lists "E-Identification" and "E-Registrations" services		The project lists "E-Identification" and "E-Registrations" services
	as to be developed. These services can follow the privacy mechanism		as to be developed. These services can use DETs and follow the
	proposed in this document. If an "agnostic ID" above refers to a		privacy considerations outlined in this document for DETs.
	completely random identifier, it creates a problem with identity
	resolution and detection of misuse. On the other hand, a classical		If an "agnostic ID" above refers to a completely random identifier,
	HIT has a flat structure which makes its resolution difficult. The		it creates a problem with identity resolution and detection of
	Hierarchical HITs provide a balanced solution by associating a		misuse. On the other hand, a classical HIT has a flat structure
	registry with the UA identifier. This is not likely to cause a major		which makes its resolution difficult. The DET (Hierarchical HIT)
	conflict with U-space privacy requirements, as the registries are		provides a balanced solution by associating a registry with the UA
	typically few at a country level (e.g., civil personal, military, law		identifier. This is not likely to cause a major conflict with
	enforcement, or commercial).		U-space privacy requirements, as the registries are typically few at
			a country level (e.g., civil personal, military, law enforcement, or
			commercial).
	Appendix B. The 14/14 HID split		Appendix B. The 14/14 HID split
	The following explains the logic behind selecting to divide the 28		The following explains the logic behind selecting to divide the 28
	bits of the HID into 2 14-bit components.		bits of the HID into 2 14-bit components.
	At this writing ICAO has 273 member "States", each may want to		At this writing ICAO has 273 member "States", each may want to
	control RID assignment within its National Air Space (NAS). Some		control RID assignment within its National Air Space (NAS). Some
	members may want separate RAAs to use for Civil, general Government,		members may want separate RAAs to use for Civil, general Government,
	and Military use. They may also want allowances for competing Civil		and Military use. They may also want allowances for competing Civil
End of changes. 20 change blocks.
	33 lines changed or deleted		64 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/