< draft-ietf-drip-auth-05.txt		draft-ietf-drip-auth-06.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: 16 October 2022 R. Moskowitz
	HTT Consulting		HTT Consulting
	7 March 2022		14 April 2022
	DRIP Authentication Formats & Protocols for Broadcast Remote ID		DRIP Authentication Formats & Protocols for Broadcast Remote ID
	draft-ietf-drip-auth-05		draft-ietf-drip-auth-06
	Abstract		Abstract
	This document describes how to include trust into the ASTM Remote ID		This document describes how to include trust into the ASTM Remote ID
	specification defined in ASTM F3411 under Broadcast Remote ID (RID).		specification defined in ASTM F3411 under Broadcast Remote ID (RID).
	It defines a few message schemes (sent within the Authentication		It defines a few message schemes (sent within the Authentication
	Message) that can be used to authenticate past messages sent by a		Message) that can be used to authenticate past messages sent by a
	unmanned aircraft (UA) and provide proof of UA trustworthiness even		unmanned aircraft (UA) and provide proof of UA trustworthiness even
	in the absence of Internet connectivity at the receiving node.		in the absence of Internet connectivity at the receiving node.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 16 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 31 ¶		skipping to change at page 2, line 31 ¶
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Problem Space and Focus . . . . . . . . . . . . . . . . . 4		3.1. Problem Space and Focus . . . . . . . . . . . . . . . . . 4
	3.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 5		3.2. Reasoning for IETF DRIP Authentication . . . . . . . . . 5
	3.3. ASTM Authentication Message . . . . . . . . . . . . . . . 5		3.3. ASTM Authentication Message . . . . . . . . . . . . . . . 5
	3.3.1. Authentication Page . . . . . . . . . . . . . . . . . 5		3.3.1. Authentication Page . . . . . . . . . . . . . . . . . 5
	3.3.2. DRIP Constraints . . . . . . . . . . . . . . . . . . 8		3.3.2. DRIP Constraints . . . . . . . . . . . . . . . . . . 8
	4. Forward Error Correction . . . . . . . . . . . . . . . . . . 8		4. Forward Error Correction . . . . . . . . . . . . . . . . . . 8
	4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 8		4.1.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 8
	4.1.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 9		4.1.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 9
	4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 12		4.2.1. Single Page FEC . . . . . . . . . . . . . . . . . . . 12
	4.2.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 12		4.2.2. Multiple Page FEC . . . . . . . . . . . . . . . . . . 12
	4.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 13		4.3. FEC Limitations . . . . . . . . . . . . . . . . . . . . . 13
	5. Broadcast Attestation Structure . . . . . . . . . . . . . . . 13		5. Broadcast Attestation Structure . . . . . . . . . . . . . . . 13
	6. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 15		6. DRIP Authentication Formats . . . . . . . . . . . . . . . . . 15
	6.1. Operator ID Signature . . . . . . . . . . . . . . . . . . 15		6.1. Operator ID Signature . . . . . . . . . . . . . . . . . . 15
	6.2. Message Set Signature . . . . . . . . . . . . . . . . . . 16		6.2. Message Set Signature . . . . . . . . . . . . . . . . . . 16
	6.3. Specific Authentication Method . . . . . . . . . . . . . 18		6.3. Specific Authentication Method . . . . . . . . . . . . . 18
	6.3.1. SAM Data Format . . . . . . . . . . . . . . . . . . . 18		6.3.1. SAM Data Format . . . . . . . . . . . . . . . . . . . 18
	6.3.2. DRIP Link . . . . . . . . . . . . . . . . . . . . . . 19		6.3.2. DRIP Link . . . . . . . . . . . . . . . . . . . . . . 19
	6.3.3. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 20		6.3.3. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 20
	6.3.4. DRIP Manifest . . . . . . . . . . . . . . . . . . . . 22		6.3.4. DRIP Manifest . . . . . . . . . . . . . . . . . . . . 22
	6.3.5. DRIP Frame . . . . . . . . . . . . . . . . . . . . . 25		6.3.5. DRIP Frame . . . . . . . . . . . . . . . . . . . . . 25
	7. Requirements & Recommendations . . . . . . . . . . . . . . . 27		7. Requirements & Recommendations . . . . . . . . . . . . . . . 27
	7.1. Legacy Transports . . . . . . . . . . . . . . . . . . . . 27		7.1. Legacy Transports . . . . . . . . . . . . . . . . . . . . 27
	7.2. Extended Transports . . . . . . . . . . . . . . . . . . . 27		7.2. Extended Transports . . . . . . . . . . . . . . . . . . . 28
	7.3. Authentication . . . . . . . . . . . . . . . . . . . . . 28		7.3. Authentication . . . . . . . . . . . . . . . . . . . . . 28
	7.4. Operational . . . . . . . . . . . . . . . . . . . . . . . 28		7.4. Operational . . . . . . . . . . . . . . . . . . . . . . . 29
	7.4.1. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 29		7.4.1. DRIP Wrapper . . . . . . . . . . . . . . . . . . . . 29
	8. ICAO Considerations . . . . . . . . . . . . . . . . . . . . . 29		8. ICAO Considerations . . . . . . . . . . . . . . . . . . . . . 30
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 30		10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	10.1. Manifest Hash Length . . . . . . . . . . . . . . . . . . 30		10.1. Manifest Hash Length . . . . . . . . . . . . . . . . . . 30
	10.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 30		10.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 31
	10.3. Trust Timestamp Offsets . . . . . . . . . . . . . . . . 31		10.3. Trust Timestamp Offsets . . . . . . . . . . . . . . . . 31
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	12.1. Normative References . . . . . . . . . . . . . . . . . . 31		12.1. Normative References . . . . . . . . . . . . . . . . . . 32
	12.2. Informative References . . . . . . . . . . . . . . . . . 32		12.2. Informative References . . . . . . . . . . . . . . . . . 32
	Appendix A. Authentication State Diagrams & Color Scheme . . . . 32		Appendix A. Authentication State Diagrams & Color Scheme . . . . 33
	A.1. State Diagrams . . . . . . . . . . . . . . . . . . . . . 33		A.1. State Table . . . . . . . . . . . . . . . . . . . . . . . 33
	A.1.1. Notations . . . . . . . . . . . . . . . . . . . . . . 33		A.2. State Diagrams . . . . . . . . . . . . . . . . . . . . . 34
	A.1.2. General . . . . . . . . . . . . . . . . . . . . . . . 34		A.2.1. Notations . . . . . . . . . . . . . . . . . . . . . . 34
	A.1.3. DRIP SAM . . . . . . . . . . . . . . . . . . . . . . 35		A.2.2. General . . . . . . . . . . . . . . . . . . . . . . . 35
	A.1.4. DRIP Link . . . . . . . . . . . . . . . . . . . . . . 36		A.2.3. DRIP SAM . . . . . . . . . . . . . . . . . . . . . . 36
	A.1.5. DRIP Wrapper/Manifest/Frame . . . . . . . . . . . . . 37		A.2.4. DRIP Link . . . . . . . . . . . . . . . . . . . . . . 37
	Appendix B. HDA-UA Broadcast Attestation . . . . . . . . . . . . 39		A.2.5. DRIP Wrapper/Manifest/Frame . . . . . . . . . . . . . 38
	Appendix C. Example Authentication Messages . . . . . . . . . . 41		Appendix B. HDA-UA Broadcast Attestation . . . . . . . . . . . . 40
	C.1. Authentication Data Only . . . . . . . . . . . . . . . . 41		Appendix C. Example Authentication Messages . . . . . . . . . . 42
	C.2. Authentication Data & Additional Data . . . . . . . . . . 42		C.1. Authentication Data Only . . . . . . . . . . . . . . . . 42
	C.3. DRIP Link Example . . . . . . . . . . . . . . . . . . . . 44		C.2. Authentication Data & Additional Data . . . . . . . . . . 43
	Appendix D. Example TX/RX Flow . . . . . . . . . . . . . . . . . 46		C.3. DRIP Link Example . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47		Appendix D. Example TX/RX Flow . . . . . . . . . . . . . . . . . 47
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	1. Introduction		1. Introduction
	Unmanned Aircraft Systems (UAS) are usually in a volatile environment		Unmanned Aircraft Systems (UAS) are usually in a volatile environment
	when it comes to communication. UA are generally small with little		when it comes to communication. UA are generally small with little
	computational (or flying) horsepower to carry standard communication		computational (or flying) horsepower to carry standard communication
	equipment. This limits the mediums of communication to few viable		equipment. This limits the mediums of communication to few viable
	options.		options.
	Observer systems (e.g. smartphones and tablets) place further		Observer systems (e.g. smartphones and tablets) place further
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 30 ¶
	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.
	2.2. Definitions		2.2. Definitions
	See [drip-requirements] for common DRIP terms.		See [drip-requirements] for common DRIP terms.
	Aircraft: In this document whenever the word Aircraft is used it is
	referring to an Unmanned Aircraft (UA) not a Manned Aircraft.
	Legacy Transports: uses broadcast frames (Bluetooth 4.x).		Legacy Transports: uses broadcast frames (Bluetooth 4.x).
	Extended Transports: uses the extended advertisements (Bluetooth		Extended Transports: uses the extended advertisements (Bluetooth
	5.X), service info (Wi-Fi NaN) or vendor specific element		5.X), service info (Wi-Fi NaN) or vendor specific element
	information (Wi-Fi BEACON). Must use ASTM [F3411] Message Pack		information (Wi-Fi BEACON). Must use ASTM [F3411] Message Pack
	(Message Type 0xF).		(Message Type 0xF).
	3. Background		3. Background
	3.1. Problem Space and Focus		3.1. Problem Space and Focus
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 46 ¶
	Page Header: (1 byte)		Page Header: (1 byte)
	Authentication Type (4 bits)		Authentication Type (4 bits)
	Page Number (4 bits)		Page Number (4 bits)
	Authentication Payload: (23 bytes per page)		Authentication Payload: (23 bytes per page)
	Authentication Payload, including headers. Null padded.		Authentication Payload, including headers. Null padded.
	Figure 1: Standard ASTM Authentication Message Page		Figure 1: Standard ASTM Authentication Message Page
			A single Authentication Page is akin to a TCP or UDP packet. For
			Authentication Pages the structure is further wrapped by outer ASTM
			framing and the specific link framing (Bluetooth or Wi-Fi).
	3.3.1.1. Authentication Type		3.3.1.1. Authentication Type
	[F3411] has the following subset of Authentication Type's defined and		[F3411] has the following subset of Authentication Type's defined and
	that can be used in the Page Header:		that can be used in the Page Header:
	+=====================+================================+		+=====================+================================+
	| Authentication Type | Description |		| Authentication Type | Description |
	+=====================+================================+		+=====================+================================+
	| 0x2 | Operator ID Signature |		| 0x2 | Operator ID Signature |
	+---------------------+--------------------------------+		+---------------------+--------------------------------+
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 14 ¶
	3.3.2. DRIP Constraints		3.3.2. DRIP Constraints
	To keep consistent formatting across the different transports (Legacy		To keep consistent formatting across the different transports (Legacy
	and Extended) and their independent restrictions the authentication		and Extended) and their independent restrictions the authentication
	data being sent is REQUIRED to fit within the page limit of the most		data being sent is REQUIRED to fit within the page limit of the most
	constrained existing transport can support. Under Broadcast RID the		constrained existing transport can support. Under Broadcast RID the
	transport that can hold the least amount of authentication data is		transport that can hold the least amount of authentication data is
	Bluetooth 5 and Wi-Fi BEACON at 9-pages.		Bluetooth 5 and Wi-Fi BEACON at 9-pages.
	As such DRIP transmitters are REQUIRED to adhere to the following:		As such DRIP transmitters are REQUIRED to adhere to the following
			when using the Authentication Message:
	1. Authentication Data / Signature data MUST fit in a 9-page		1. Authentication Data / Signature data MUST fit in a 9-pages (Page
	Authentication Message (Page Numbers 0 through 8).		Numbers 0 through 8).
	2. The Length field in the Authentication Headers (which denotes the		2. The Length field in the Authentication Headers (which denotes the
	length in bytes of Authentication Data / Signature only) MUST NOT		length in bytes of Authentication Data / Signature only) MUST NOT
	exceed the value of 201.		exceed the value of 201.
	4. Forward Error Correction		4. Forward Error Correction
	For Broadcast RID, Forward Error Correction (FEC) is provided by the		For Broadcast RID, Forward Error Correction (FEC) is provided by the
	lower layers in Extended Transports (Bluetooth 5.X, Wi-Fi NaN, and		lower layers in Extended Transports (Bluetooth 5.X, Wi-Fi NaN, and
	Wi-Fi BEACON). Legacy Transports do not have supporting FEC so with		Wi-Fi BEACON). Legacy Transports do not have supporting FEC so with
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	is actually protected.		is actually protected.
	(Editor Note: to improve interop should we explicitly select a		(Editor Note: to improve interop should we explicitly select a
	polynomial for Reed Solomon that DRIP must use?)		polynomial for Reed Solomon that DRIP must use?)
	4.1.2.1. Page Recovery		4.1.2.1. Page Recovery
	Take the following example of an Authentication Message that 3-pages		Take the following example of an Authentication Message that 3-pages
	of parity are to be generated for:		of parity are to be generated for:
	1250098960bf8c05042001001000a00145aac6b00abba268b7		12 50 098960bf8c05 042001001000a00145aac6b00abba268b7
	12512001001000a0014579d8a404d48f2ef9bb9a4470ada5b4		12 51 2001001000a0014579d8a404d48f2ef9bb9a4470ada5b4
	1252ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73		12 52 ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73
	1253dca7d04e776150825863c512c6eb075a206a95c59b297e		12 53 dca7d04e776150825863c512c6eb075a206a95c59b297e
	1254f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454		12 54 f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454
	12557101415def153a770d3e6c0b17ae560809bc634a822c1f		12 55 7101415def153a770d3e6c0b17ae560809bc634a822c1f
	12563b1064b80a000000000000000000000000000000000000		12 56 3b1064b80a000000000000000000000000000000000000
	For Page Recovery the first two columns are ignored (being the Page		For Page Recovery the first two columns are ignored (being the Page
	Header and any data before it), the last 23 columns are extracted and		Header and any data before it), the last 23 columns are extracted and
	have Reed Solomon performed on it to produce parity bytes. For the		have Reed Solomon performed on it to produce parity bytes. For the
	example the following 3-bytes of parity are generated:		example the following 3-bytes of parity are generated:
	dc6c2b = ReedSolomon.encoder(0920ffdcf2713b)		dc6c2b = ReedSolomon.encoder(0920ffdcf2713b)
	Each set of parity is the placed into a pseudo-frame as follows (each		Each set of parity is the placed into a pseudo-frame as follows (each
	byte in its own message in the same column):		byte in its own message in the same column):
	0000dc00000000000000000000000000000000000000000000		00 00 dc00000000000000000000000000000000000000000000
	00006c00000000000000000000000000000000000000000000		00 00 6c00000000000000000000000000000000000000000000
	00002b00000000000000000000000000000000000000000000		00 00 2b00000000000000000000000000000000000000000000
	The above data set produces the following full set of parity:		The above data set produces the following full set of parity:
	0000dc6657acd30b2ec4aa582049f52adf9f922e62c469563a		00 00 dc6657acd30b2ec4aa582049f52adf9f922e62c469563a
	00006c636a59145a55417a3895fd543f19e94200be4abc5e94		00 00 6c636a59145a55417a3895fd543f19e94200be4abc5e94
	000002bba5e28f5896d754caf50016a983993b149b5c9e6eeb		00 00 02bba5e28f5896d754caf50016a983993b149b5c9e6eeb
	The last 23-bytes are then added into the Additional Data field.		The last 23-bytes are then added into the Additional Data fields of
			their respective pages:
			12 57 dc6657acd30b2ec4aa582049f52adf9f922e62c469563a
			12 58 6c636a59145a55417a3895fd543f19e94200be4abc5e94
			12 59 02bba5e28f5896d754caf50016a983993b149b5c9e6eeb
	4.1.2.2. Frame Recovery		4.1.2.2. Frame Recovery
	Frame Recovery uses the full ASTM Message and performs Reed Solomon		Frame Recovery uses the full ASTM Message and performs Reed Solomon
	over each byte. Below is an example of a number of messages.		over each byte. Below is an example of a number of messages.
	1042012001001000a0014579d8a404d48f2ef9000000000000		10 42012001001000a0014579d8a404d48f2ef9000000000000
	11249600006efeb019ee111ed37a097a0948081c10ffff0000		11 249600006efeb019ee111ed37a097a0948081c10ffff0000
	1250098960bf8c05042001001000a00145aac6b00abba268b7		12 50 098960bf8c05 042001001000a00145aac6b00abba268b7
	12512001001000a0014579d8a404d48f2ef9bb9a4470ada5b4		12 51 2001001000a0014579d8a404d48f2ef9bb9a4470ada5b4
	1252ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73		12 52 ff1352c7402af9d9ebd20034e8d7a12920f4d7e91c1a73
	1253dca7d04e776150825863c512c6eb075a206a95c59b297e		12 53 dca7d04e776150825863c512c6eb075a206a95c59b297e
	1254f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454		12 54 f2935fd416f27b1b42fd5d9dfaa0dec79f32287f41b454
	12557101415def153a770d3e6c0b17ae560809bc634a822c1f		12 55 7101415def153a770d3e6c0b17ae560809bc634a822c1f
	12563b1064b80a000000000000000000000000000000000000		12 56 3b1064b80a000000000000000000000000000000000000
	130052656372656174696f6e616c2054657374000000000000		13 0052656372656174696f6e616c2054657374000000000000
	1402c2ffb019322d1ed3010000c008e40700fc080000000000		14 02c2ffb019322d1ed3010000c008e40700fc080000000000
	15004e2e4f5031323334353600000000000000000000000000		15 004e2e4f5031323334353600000000000000000000000000
	Each column is extracted and has Reed Solomon performed on it to		Each column is extracted and has Reed Solomon performed on it to
	produce parity bytes. In the below example 5-bytes of parity are		produce parity bytes. In the below example 5-bytes of parity are
	generated with Frame Recovery:		generated with Frame Recovery:
	6c3f42b8a8 = ReedSolomon.encoder(101112121212121212131415)		6c3f42b8a8 = ReedSolomon.encoder(101112121212121212131415)
	Each set of parity is the placed into a pseudo-frame as follows (each		Each set of parity is the placed into a pseudo-frame as follows (each
	byte in its own message in the same column):		byte in its own message in the same column):
	6c000000000000000000000000000000000000000000000000		6c000000000000000000000000000000000000000000000000
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 44 ¶
	6c86337bf7ab746f5d62bb7f8de954104b121585d3975f6e92		6c86337bf7ab746f5d62bb7f8de954104b121585d3975f6e92
	3f06c1bce165b0e25930d57a63c24f751145e1dd8dc115029b		3f06c1bce165b0e25930d57a63c24f751145e1dd8dc115029b
	42e9979580327a6a14d421c12a33aa2e1a2e517daaee581016		42e9979580327a6a14d421c12a33aa2e1a2e517daaee581016
	b8012a7b3964f7b2720d387bfa77e945556f1831cd477ef3a3		b8012a7b3964f7b2720d387bfa77e945556f1831cd477ef3a3
	a85bb403aada89926fb8fc2a14a9caacb4ec2f3a6ed2d8e9f9		a85bb403aada89926fb8fc2a14a9caacb4ec2f3a6ed2d8e9f9
	For Frame Recovery the above data would be placed into Authentication		For Frame Recovery the above data would be placed into Authentication
	Pages like below:		Pages like below:
	Page 7 = 12576c86337bf7ab746f5d62bb7f8de954104b121585d3975f		12 57 6c86337bf7ab746f5d62bb7f8de954104b121585d3975f
	Page 8 = 12586e923f06c1bce165b0e25930d57a63c24f751145e1dd8d		12 58 6e923f06c1bce165b0e25930d57a63c24f751145e1dd8d
	Page 9 = 1259c115029b42e9979580327a6a14d421c12a33aa2e1a2e51		12 59 c115029b42e9979580327a6a14d421c12a33aa2e1a2e51
	Page 10 = 125a7daaee581016b8012a7b3964f7b2720d387bfa77e94555		12 5a 7daaee581016b8012a7b3964f7b2720d387bfa77e94555
	Page 11 = 125b6f1831cd477ef3a3a85bb403aada89926fb8fc2a14a9ca		12 5b 6f1831cd477ef3a3a85bb403aada89926fb8fc2a14a9ca
	Page 12 = 125cacb4ec2f3a6ed2d8e9f900000000000000000000000000		12 5c acb4ec2f3a6ed2d8e9f900000000000000000000000000
	Up to 240 (255 minus 15 pages max of FEC data) messages can be		Up to 240 (255 minus 15 pages max of FEC data) messages can be
	protected using Frame Recovery.		protected using Frame Recovery.
	4.2. Decoding		4.2. Decoding
	Due to the nature of Bluetooth 4 and the existing ASTM paging		Due to the nature of Bluetooth 4 and the existing ASTM paging
	structure an optimization can be used. If a Bluetooth frame fails		structure an optimization can be used. If a Bluetooth frame fails
	its CRC check, then the frame is dropped without notification to the		its CRC check, then the frame is dropped without notification to the
	upper protocol layers. From the Remote ID perspective this means the		upper protocol layers. From the Remote ID perspective this means the
	skipping to change at page 14, line 40 ¶		skipping to change at page 14, line 47 ¶
	UA Signature (64 bytes):		UA Signature (64 bytes):
	Signature over preceding fields using the keypair of		Signature over preceding fields using the keypair of
	the UA.		the UA.
	Figure 4: Broadcast Attestation Structure		Figure 4: Broadcast Attestation Structure
	Attestation Data is a field with a maximum of 112-bytes, containing		Attestation Data is a field with a maximum of 112-bytes, containing
	data that the UA is attesting during its flight.		data that the UA is attesting during its flight.
	The Not After Timestamp and Not Before Timestamp MUST follow the		The Not After Timestamp and Not Before Timestamp MUST follow the
	format defined in [F3411]. That is a UNIX timestamp offset by		format defined in [F3411]. That is a Unix-style timestamp but with
	01/01/2019 00:00:00. Not Before Timestamp MUST be set to the time		an epoch of 01/01/2019 00:00:00. Not Before Timestamp MUST be set to
	the structure is signed over. An additional offset is then added to		the time the structure is signed over. An additional offset is then
	push the Not After Timestamp a short time into the future to avoid		added to push the Not After Timestamp a short time into the future to
	replay attacks. The offset used against the UNIX timestamp is not		avoid replay attacks.
	defined in this document. Best practice identifying an acceptable
	offset should be used taking into consideration the UA environment,		The offset used against the Unix-style timestamp is not defined in
	and propagation characteristics of the messages being sent and clock		this document. Best practice identifying an acceptable offset should
	differences between the UA and Observers. A reasonable time would be		be used taking into consideration the UA environment, and propagation
	to set Not After Timestamp 2 minutes ahead of Not Before Timestamp.		characteristics of the messages being sent and clock differences
			between the UA and Observers. A reasonable time would be to set Not
			After Timestamp 2 minutes ahead of Not Before Timestamp.
	6. DRIP Authentication Formats		6. DRIP Authentication Formats
	All formats defined in this section fill the Authentication Data /		All formats defined in this section fill the Authentication Data /
	Signature field in Figure 2.		Signature field in Figure 2.
	When sending data over a medium that does not have underlying Forward		When sending data over a medium that does not have underlying Forward
	Error Correction (FEC), for example Bluetooth 4, then Section 4 MUST		Error Correction (FEC), for example Bluetooth 4, then Section 4 MUST
	be used.		be used.
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	Byte defined by F3411 to multiplex SAMs		Byte defined by F3411 to multiplex SAMs
	SAM Authentication Data (0 to 200 bytes):		SAM Authentication Data (0 to 200 bytes):
	Opaque SAM authentication data.		Opaque SAM authentication data.
	Figure 7: SAM Data Format		Figure 7: SAM Data Format
	6.3.1.1. SAM Type		6.3.1.1. SAM Type
	The SAM Type field is maintained by the International Civil Aviation		The SAM Type field is maintained by the International Civil Aviation
	Organization (ICAO) and for DRIP four are allocated:		Organization (ICAO) and for DRIP four are planned to be allocated:
	+==========+===============================+		+==========+===============================+
	| SAM Type | Description |		| SAM Type | Description |
	+==========+===============================+		+==========+===============================+
	| 0x01 | DRIP Link (Section 6.3.2) |		| 0x01 | DRIP Link (Section 6.3.2) |
	+----------+-------------------------------+		+----------+-------------------------------+
	| 0x02 | DRIP Wrapper (Section 6.3.3) |		| 0x02 | DRIP Wrapper (Section 6.3.3) |
	+----------+-------------------------------+		+----------+-------------------------------+
	| 0x03 | DRIP Manifest (Section 6.3.4) |		| 0x03 | DRIP Manifest (Section 6.3.4) |
	+----------+-------------------------------+		+----------+-------------------------------+
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 42 ¶
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| |		| |
	. .		. .
	. Broadcast Attestation .		. Broadcast Attestation .
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Broadcast Attestation: (135-bytes)		Broadcast Attestation: (136-bytes)
	...		HDA over UA. Generated by a DRIP Registry during Session ID
			registration.
	Figure 8: DRIP Link		Figure 8: DRIP Link
	This DRIP format MUST be used in conjunction with the DRIP Manifest		This DRIP format MUST be used in conjunction with the DRIP Manifest
	with the hash of the DRIP Link message and other dynamic data (such		with the hash of the DRIP Link message and other dynamic data (such
	as the Location Message (Message Type 0x2)).		as the Location Message (Message Type 0x2)).
	6.3.2.1. Link Limitations		6.3.2.1. Link Limitations
	See Section 10.2 for details on why this structure is not dynamically		See Section 10.2 for details on why this structure is not dynamically
	skipping to change at page 24, line 32 ¶		skipping to change at page 24, line 32 ¶
	Not After Timestamp by UA (4 bytes):		Not After Timestamp by UA (4 bytes):
	Timestamp denoting recommended time to stop trusting data.		Timestamp denoting recommended time to stop trusting data.
	UA Signature (64 bytes):		UA Signature (64 bytes):
	Signature over preceding fields using the keypair of		Signature over preceding fields using the keypair of
	the UA.		the UA.
	Figure 10: Example DRIP Manifest		Figure 10: Example DRIP Manifest
	6.3.4.1. Hash Algorithms and Operation		6.3.4.1. Message Hash Algorithms and Operation
	The hash algorithm used for the Manifest Message is the same hash		The hash algorithm used for the Manifest Message is the same hash
	algorithm used in creation of the HHIT that is signing the Manifest.		algorithm used in creation of the DET [drip-rid] that is signing the
			Manifest.
	An HHIT using cSHAKE128 [NIST.SP.800-185] computes the hash as		An DET using cSHAKE128 [NIST.SP.800-185] computes the hash as
	follows:		follows:
	cSHAKE128(ASTM Message, 96, "", "Remote ID Auth Hash")		cSHAKE128(ASTM Message, 96, "", "Remote ID Auth Hash")
	Note: [drip-rid] specifies cSHAKE128 but is open for the		Note: [drip-rid] specifies cSHAKE128 but is open for the
	expansion of other OGAs.		expansion of other OGAs.
	6.3.4.1.1. Legacy Transport Hashing		6.3.4.1.1. Legacy Transport Hashing
	Under this transport DRIP hashes the full ASTM Message being sent		Under this transport DRIP hashes the full ASTM Message being sent
	skipping to change at page 26, line 36 ¶		skipping to change at page 26, line 45 ¶
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	UA DRIP Entity Tag (16 bytes):		UA DRIP Entity Tag (16 bytes):
	The UA DET in byte form (network byte order).		The UA DET in byte form (network byte order).
	Frame Type (1 byte):		Frame Type (1 byte):
	Multiplexing frame type.		Sub-type for future different DRIP Frame formats.
	Attestation Data (0 to 111 bytes):		Attestation Data (0 to 111 bytes):
	Opaque attestation data.		Opaque attestation data.
	Not Before Timestamp by UA (4-bytes):		Not Before Timestamp by UA (4-bytes):
	Timestamp denoting recommended time to start trusting data.		Timestamp denoting recommended time to start trusting data.
	Not After Timestamp by UA (4 bytes):		Not After Timestamp by UA (4 bytes):
	Timestamp denoting recommended time to stop trusting data.		Timestamp denoting recommended time to stop trusting data.
	UA Signature (64 bytes):		UA Signature (64 bytes):
	Signature over preceding fields using the keypair of		Signature over preceding fields using the keypair of
	the UA.		the UA.
	Figure 11: Example DRIP Frame		Figure 11: Example DRIP Frame
	6.3.5.1. Frame Type		6.3.5.1. Frame Type
	Multiplexing byte for future different DRIP Frame formats.		Byte to sub-type for future different DRIP Frame formats.
	+============+==============+==================+		+============+==============+==================+
	| Frame Type | Name | Description |		| Frame Type | Name | Description |
	+============+==============+==================+		+============+==============+==================+
	| 0x00 | Reserved | Reserved |		| 0x00 | Reserved | Reserved |
	+------------+--------------+------------------+		+------------+--------------+------------------+
	| 0xC0-0xFF | Experimental | Experimental Use |		| 0xC0-0xFF | Experimental | Experimental Use |
	+------------+--------------+------------------+		+------------+--------------+------------------+
	Table 3		Table 3
	skipping to change at page 28, line 7 ¶		skipping to change at page 28, line 20 ¶
	are sent together (in Message Type order) in a single Bluetooth 5		are sent together (in Message Type order) in a single Bluetooth 5
	extended frame (up to 9 single frame equivalent messages under		extended frame (up to 9 single frame equivalent messages under
	Bluetooth 4.X). Message Packs are required by ASTM to be sent at a		Bluetooth 4.X). Message Packs are required by ASTM to be sent at a
	rate of 1 per second (like dynamic messages).		rate of 1 per second (like dynamic messages).
	Without any fragmentation or loss of pages with transmission Forward		Without any fragmentation or loss of pages with transmission Forward
	Error Correction (Section 4) MUST NOT be used as it is impractical.		Error Correction (Section 4) MUST NOT be used as it is impractical.
	7.3. Authentication		7.3. Authentication
	It is REQUIRED that an aircraft send the following Authentication		It is REQUIRED that a UA send the following Authentication Formats to
	Formats to fulfill the [drip-requirements]:		fulfill the [drip-requirements]:
	1. DRIP Link using the Broadcast Attestation of HDA and the UA		1. DRIP Link using the Broadcast Attestation of HDA and the UA
	(satisfying GEN-1 and GEN-3)		(satisfying GEN-1 and GEN-3)
	2. Any other DRIP Authentication Format (RECOMMENDED: DRIP Manifest		2. Any other DRIP Authentication Format (RECOMMENDED: DRIP Manifest
	or DRIP Wrapper) where the UA is dynamically signing data		or DRIP Wrapper) where the UA is dynamically signing data
	(satisfying GEN-1 and GEN-2)		(satisfying GEN-1 and GEN-2)
	It is RECOMMENDED the following set of Authentication Formats are		It is RECOMMENDED the following set of Authentication Formats are
	sent for support of offline Observers:		sent for support of offline Observers:
	skipping to change at page 31, line 4 ¶		skipping to change at page 31, line 21 ¶
	are two things to mitigate this in DRIP:		are two things to mitigate this in DRIP:
	1. If an attacker (who is smart and spoofs more than just the UAS		1. If an attacker (who is smart and spoofs more than just the UAS
	ID/data payloads) willing replays an Attestation Link message		ID/data payloads) willing replays an Attestation Link message
	they have in principle actually helped by ensuring the message is		they have in principle actually helped by ensuring the message is
	sent more frequently and be received by potential Observers.		sent more frequently and be received by potential Observers.
	2. It is RECOMMENDED to send more than just DRIP Link messages,		2. It is RECOMMENDED to send more than just DRIP Link messages,
	specifically those that sign over changing data using the current		specifically those that sign over changing data using the current
	session keypair, and those messages are sent more frequently. An		session keypair, and those messages are sent more frequently. An
	aircraft beaconing these messages then actually signing other		UA beaconing these messages then actually signing other messages
	messages using the keypair validates the data receiver by an		using the keypair validates the data receiver by an Observer. An
	Observer. An UA who does not either run DRIP themselves or does		UA who does not either run DRIP themselves or does not have
	not have possession of the same private key, would be clearly		possession of the same private key, would be clearly exposed upon
	exposed upon signature verification.		signature verification.
	10.3. Trust Timestamp Offsets		10.3. Trust Timestamp Offsets
	Note the discussion of Trust Timestamp Offsets here is in context of		Note the discussion of Trust Timestamp Offsets here is in context of
	the DRIP Wrapper (Section 6.3.3) and DRIP Manifest (Section 6.3.4)		the DRIP Wrapper (Section 6.3.3) and DRIP Manifest (Section 6.3.4)
	messages. For DRIP Link (Section 6.3.2) messages these offsets are		messages. For DRIP Link (Section 6.3.2) messages these offsets are
	set by the Attestor (typically a registry) and have their own set of		set by the Attestor (typically a registry) and have their own set of
	considerations as seen in [drip-registries].		considerations as seen in [drip-registries].
	The offset of the Trust Timestamp (defined as a very short Expiration		The offset of the Trust Timestamp (defined as a very short Expiration
	skipping to change at page 32, line 24 ¶		skipping to change at page 32, line 46 ¶
	12.2. Informative References		12.2. Informative References
	[drip-registries]		[drip-registries]
	Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP		Wiethuechter, A., Card, S., and R. Moskowitz, "DRIP
	Registries", Work in Progress, Internet-Draft, draft-		Registries", Work in Progress, Internet-Draft, draft-
	wiethuechter-drip-registries-01, 22 October 2021,		wiethuechter-drip-registries-01, 22 October 2021,
	<https://www.ietf.org/archive/id/draft-wiethuechter-drip-		<https://www.ietf.org/archive/id/draft-wiethuechter-drip-
	registries-01.txt>.		registries-01.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>.
	Appendix A. Authentication State Diagrams & Color Scheme		Appendix A. Authentication State Diagrams & Color Scheme
	For DRIP there are various Authentication states. The table below		ASTM Authentication has really only 3 states: None, Invalid or Valid.
	lays out the RECOMMENDED colors to associate with state.		This is because under ASTM the idea is that Authentication is done by
			an external service hosted somewhere on the Internet so it is assumed
			you will always get some sort of answer back. With DRIP this
			classification becomes more complex with the support of "offline"
			scenarios where the receiver does not have Internet connectivity.
			With the use of asymmetric keys this means the public key (PK) must
			somehow be obtained - [drip-registries] gets more into detail how
			these keys are stored on DNS and one reason for DRIP Authentication
			is to send PK's over Broadcast RID.
			There are two keys of interest: the PK of the UA and the PK of the
			HDA (or Registry). This document gives a clear way to send the PK of
			the UA over the Broadcast RID messages - however the PK of the
			Registry is not. It can be using the same mechanism but is not
			required to do so due to potential operational constraints and
			implementation of a given UA transmitter. As such there are
			scenarios where you may have part of the key-chain but not all of it.
			The intent of this appendix is to give some kind of recommended way
			to classify these various states and convey it to the user through
			colors and state names/text.
			A.1. State Table
			The table below lays out the RECOMMENDED colors to associate with
			state.
	+==============+========+===================================+		+==============+========+===================================+
	| State | Color | Details |		| State | Color | Details |
	+==============+========+===================================+		+==============+========+===================================+
	| None | Black | No Authentication being received |		| None | Black | No Authentication being received |
	+--------------+--------+-----------------------------------+		+--------------+--------+-----------------------------------+
	| Partial | Gray | Authentication being received but |		| Partial | Gray | Authentication being received but |
	| | | missing pages |		| | | missing pages |
	+--------------+--------+-----------------------------------+		+--------------+--------+-----------------------------------+
	| Unsupported | Brown | Authentication Type/SAM Type of |		| Unsupported | Brown | Authentication Type/SAM Type of |
	skipping to change at page 33, line 34 ¶		skipping to change at page 34, line 34 ¶
	| Questionable | Orange | Inconsistent verification results |		| Questionable | Orange | Inconsistent verification results |
	+--------------+--------+-----------------------------------+		+--------------+--------+-----------------------------------+
	| Unverified | Red | Invalid verification results |		| Unverified | Red | Invalid verification results |
	+--------------+--------+-----------------------------------+		+--------------+--------+-----------------------------------+
	| Conflicting | Purple | Inconsistent verification results |		| Conflicting | Purple | Inconsistent verification results |
	| | | and HDA is marked as trusted |		| | | and HDA is marked as trusted |
	+--------------+--------+-----------------------------------+		+--------------+--------+-----------------------------------+
	Table 4		Table 4
	A.1. State Diagrams		A.2. State Diagrams
	This section gives some RECOMMENDED state flows that DRIP should		This section gives some RECOMMENDED state flows that DRIP should
	follow.		follow.
	A.1.1. Notations		A.2.1. Notations
	o--------------o		o--------------o
	| PROCESS |		| PROCESS |
	o--------------o		o--------------o
	+--------------+		+--------------+
	| STATE |		| STATE |
	+--------------+		+--------------+
	ooooo		ooooo
	o N o Transition N		o N o Transition N
	ooooo		ooooo
	+-----> Transition Option False/No		+-----> Transition Option False/No
	-----> Transition Option True/Yes		-----> Transition Option True/Yes
	Figure 12: Diagram Notations		Figure 12: Diagram Notations
	A.1.2. General		A.2.2. General
	o---------------------o ooooo +------+		o---------------------o ooooo +------+
	| Start |---->o 1 o+----->| None |		| Start |---->o 1 o+----->| None |
	o---------------------o ooooo +------+		o---------------------o ooooo +------+
	|		|
	v		v
	ooooo +-------------+		ooooo +-------------+
	o 2 o+----->| Unsupported |		o 2 o+----->| Unsupported |
	ooooo +-------------+		ooooo +-------------+
	| ^		| ^
	skipping to change at page 35, line 27 ¶		skipping to change at page 36, line 27 ¶
	+------------+-----------------------------+----------------------+		+------------+-----------------------------+----------------------+
	| 4 | Is Authentication Type | 5, AuthType Decoder |		| 4 | Is Authentication Type | 5, AuthType Decoder |
	| | received 5? | |		| | received 5? | |
	+------------+-----------------------------+----------------------+		+------------+-----------------------------+----------------------+
	| 5 | Is SAM Type Supported? | SAM Decoder, |		| 5 | Is SAM Type Supported? | SAM Decoder, |
	| | | Unsupported |		| | | Unsupported |
	+------------+-----------------------------+----------------------+		+------------+-----------------------------+----------------------+
	Table 5		Table 5
	A.1.3. DRIP SAM		A.2.3. DRIP SAM
	o-------------o ooooo o-----------------------------o		o-------------o ooooo o-----------------------------o
	| SAM Decoder |---->o 6 o------>| DRIP Wrapper/Manifest/Frame |		| SAM Decoder |---->o 6 o------>| DRIP Wrapper/Manifest/Frame |
	o-------------o ooooo o-----------------------------o		o-------------o ooooo o-----------------------------o
	+ | ^		+ | ^
	| | |		| | |
	v v |		v v |
	o-----------o o--------------------o |		o-----------o o--------------------o |
	| DRIP Link |--->| Update State Cache | |		| DRIP Link |--->| Update State Cache | |
	o-----------o o--------------------o |		o-----------o o--------------------o |
	skipping to change at page 36, line 19 ¶		skipping to change at page 37, line 19 ¶
	| 6 | Is SAM Type DRIP | DRIP Link, DRIP |		| 6 | Is SAM Type DRIP | DRIP Link, DRIP |
	| | Link? | Wrapper/Manifest/Frame |		| | Link? | Wrapper/Manifest/Frame |
	+------------+---------------------+------------------------+		+------------+---------------------+------------------------+
	| 7 | Messages in | Extract Message from |		| 7 | Messages in | Extract Message from |
	| | Verification Queue? | Verification Queue, |		| | Verification Queue? | Verification Queue, |
	| | | NOP / Return |		| | | NOP / Return |
	+------------+---------------------+------------------------+		+------------+---------------------+------------------------+
	Table 6		Table 6
	A.1.4. DRIP Link		A.2.4. DRIP Link
	o-----------o ooooo ooooo +--------------+		o-----------o ooooo ooooo +--------------+
	| DRIP Link |----->o 8 o+----->o 9 o+----->| Unverifiable |		| DRIP Link |----->o 8 o+----->o 9 o+----->| Unverifiable |
	o-----------o ooooo ooooo +--------------+		o-----------o ooooo ooooo +--------------+
	| |		| |
	|-------------'		|-------------'
	v		v
	ooooo +------------+		ooooo +------------+
	o 10 o+----->| Unverified |		o 10 o+----->| Unverified |
	ooooo +------------+		ooooo +------------+
	|		|
	v		v
	o---------------------o		o---------------------o
	| Add Aircraft DET/PK |		| Add UA DET/PK |
	| to Key Cache |		| to Key Cache |
	o---------------------o		o---------------------o
	|		|
	v		v
	ooooo +----------+		ooooo +----------+
	o 11 o+------>| Verified |		o 11 o+------>| Verified |
	ooooo +----------+		ooooo +----------+
	| ^		| ^
	v |		v |
	o-------------------------o		o-------------------------o
	| Mark Aircraft DET/PK |		| Mark UA DET/PK |
	| as Trusted in Key Cache |		| as Trusted in Key Cache |
	o-------------------------o		o-------------------------o
	Figure 15: DRIP Link State Decoder		Figure 15: DRIP Link State Decoder
	+============+==========================+========================+		+============+==========================+===========================+
	| Transition | Transition Query | Next State/Process/ |		| Transition | Transition Query | Next State/Process/ |
	| | | Transition (Yes, No) |		| | | Transition (Yes, No) |
	+============+==========================+========================+		+============+==========================+===========================+
	| 8 | Registry DET/PK in Key | 10, 9 |		| 8 | Registry DET/PK in Key | 10, 9 |
	| | Cache? | |		| | Cache? | |
	+------------+--------------------------+------------------------+		+------------+--------------------------+---------------------------+
	| 9 | Registry PK found | 10, Unverifiable |		| 9 | Registry PK found | 10, Unverifiable |
	| | Online? | |		| | Online? | |
	+------------+--------------------------+------------------------+		+------------+--------------------------+---------------------------+
	| 10 | Registry Signature | Add Aircraft DET/PK to |		| 10 | Registry Signature | Add UA DET/PK to Key |
	| | Verified? | Key Cache, Unverified |		| | Verified? | Cache, Unverified |
	+------------+--------------------------+------------------------+		+------------+--------------------------+---------------------------+
	| 11 | Registry DET/PK marked | Mark Aircraft DET/PK |		| 11 | Registry DET/PK marked | Mark UA DET/PK as |
	| | as Trusted in Key Cache? | as Trusted in Key |		| | as Trusted in Key Cache? | Trusted in Key |
	| | | Cache, Verified |		| | | Cache, Verified |
	+------------+--------------------------+------------------------+		+------------+--------------------------+---------------------------+
	Table 7		Table 7
	A.1.5. DRIP Wrapper/Manifest/Frame		A.2.5. DRIP Wrapper/Manifest/Frame
	o-----------------------------o +--------------+		o-----------------------------o +--------------+
	| DRIP Wrapper/Manifest/Frame | | Unverifiable |		| DRIP Wrapper/Manifest/Frame | | Unverifiable |
	o-----------------------------o +--------------+		o-----------------------------o +--------------+
	| ^		| ^
	v |		v |
	ooooo ooooo o--------------------o		ooooo ooooo o--------------------o
	o 12 o+----->o 13 o+----->| Add Message to |		o 12 o+----->o 13 o+----->| Add Message to |
	ooooo ooooo | Verification Queue |		ooooo ooooo | Verification Queue |
	| | o--------------------o		| | o--------------------o
	| |		| |
	skipping to change at page 39, line 9 ¶		skipping to change at page 40, line 9 ¶
	+---------+		+---------+
	| Trusted |		| Trusted |
	+---------+		+---------+
	Figure 16: DRIP Wrapper/Manifest/Frame State Decoder		Figure 16: DRIP Wrapper/Manifest/Frame State Decoder
	+============+==============================+======================+		+============+==============================+======================+
	| Transition | Transition Query | Next State/Process/ |		| Transition | Transition Query | Next State/Process/ |
	| | | Transition (Yes, No) |		| | | Transition (Yes, No) |
	+============+==============================+======================+		+============+==============================+======================+
	| 12 | Aircraft DET/PK in Key | 14, 13 |		| 12 | UA DET/PK in Key Cache? | 14, 13 |
	| | Cache? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 13 | Aircraft PK found Online? | 14, Add Message to |		| 13 | UA PK found Online? | 14, Add Message to |
	| | | Verification Queue |		| | | Verification Queue |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 14 | Aircraft Signature Verified? | 17, 15 |		| 14 | UA Signature Verified? | 17, 15 |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 15 | Has past Messages of this | Conflicting, 16 |		| 15 | Has past Messages of this | Conflicting, 16 |
	| | type been marked as Trusted? | |		| | type been marked as Trusted? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 16 | Has past Messages of this | Questionable, |		| 16 | Has past Messages of this | Questionable, |
	| | type been marked as | Unverified |		| | type been marked as | Unverified |
	| | Questionable or Verified? | |		| | Questionable or Verified? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 17 | Has past Messages of this | Conflicting, 18 |		| 17 | Has past Messages of this | Conflicting, 18 |
	| | type been marked as | |		| | type been marked as | |
	| | Conflicting? | |		| | Conflicting? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 18 | Has past Messages of this | Questionable, 19 |		| 18 | Has past Messages of this | Questionable, 19 |
	| | type been marked as | |		| | type been marked as | |
	| | Questionable or Unverified? | |		| | Questionable or Unverified? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	| 19 | Is Aircraft DET/PK marked as | Trusted, Verified |		| 19 | Is UA DET/PK marked as | Trusted, Verified |
	| | Trusted in Key Cache? | |		| | Trusted in Key Cache? | |
	+------------+------------------------------+----------------------+		+------------+------------------------------+----------------------+
	Table 8		Table 8
	Appendix B. HDA-UA Broadcast Attestation		Appendix B. HDA-UA Broadcast Attestation
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	skipping to change at page 46, line 49 ¶		skipping to change at page 47, line 49 ¶
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Hex: 57bcbe21684809ed5284aa40b4b7bc45efeb3a47d24b6645		Hex: 57bcbe21684809ed5284aa40b4b7bc45efeb3a47d24b6645
	Appendix D. Example TX/RX Flow		Appendix D. Example TX/RX Flow
	In this example the UA is sending all DRIP Authentication Message		In this example the UA is sending all DRIP Authentication Message
	formats (DRIP Link, DRIP Wrapper and DRIP Manifest) during flight,		formats (DRIP Link, DRIP Wrapper and DRIP Manifest) during flight,
	along with standard ASTM Messages. The objective is to show the		along with standard ASTM Messages. The objective is to show the
	combinations of messages that must be received to properly validate a		combinations of messages that must be received to properly validate a
	DRIP equipped aircraft and examples of their various states		DRIP equipped UA and examples of their various states (Appendix A).
	(Appendix A).
	+-------------------+		+-------------------+
	.-----| Unmanned Aircraft |-----.		.-----| Unmanned Aircraft |-----.
	| +-------------------+ |		| +-------------------+ |
	| 1 | 2 | 3 | 4		| 1 | 2 | 3 | 4
	| | | |		| | | |
	O O O O		O O O O
	--|-- --|-- --|-- --|--		--|-- --|-- --|-- --|--
	/ \ / \ / \ / \		/ \ / \ / \ / \
End of changes. 50 change blocks.
	130 lines changed or deleted		165 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/