rfc9575-usestt.txt		rfc9575.txt
	skipping to change at line 352 ¶		skipping to change at line 352 ¶
	+---------------+ |		+---------------+ |
	| |		| |
	| |		| |
	| Authentication Payload |		| Authentication Payload |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 1: Standard ASTM Authentication Message Page		Figure 1: Standard ASTM Authentication Message Page
	Page Header: (1 octet)		_Page Header_: (1 octet)
	Authentication Type (4 bits) and Page Number (4 bits)		Authentication Type (4 bits) and Page Number (4 bits)
	Authentication Payload: (23 octets per page)		_Authentication Payload_: (23 octets per page)
	Authentication Payload, including headers. Null padded. See		Authentication Payload, including headers. Null padded. See
	Section 3.2.2.		Section 3.2.2.
	The Authentication Message is structured as a set of pages per		The Authentication Message is structured as a set of pages per
	Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15)		Figure 1. There is a technical maximum of 16 pages (indexed 0 to 15)
	that can be sent for a single Authentication Message, with each page		that can be sent for a single Authentication Message, with each page
	carrying a maximum 23-octet Authentication Payload. See		carrying a maximum 23-octet _Authentication Payload_. See
	Section 3.2.4 for more details. Over Legacy Transports, these		Section 3.2.4 for more details. Over Legacy Transports, these
	messages are "fragmented", with each page sent in a separate Legacy		messages are "fragmented", with each page sent in a separate Legacy
	Transport frame.		Transport frame.
	Either as a single Authentication Message or a set of fragmented		Either as a single Authentication Message or a set of fragmented
	Authentication Message Pages, the structure is further wrapped by		Authentication Message Pages, the structure is further wrapped by
	outer ASTM framing and the specific link framing.		outer ASTM framing and the specific link framing.
	3.2.2. Authentication Payload Field		3.2.2. Authentication Payload Field
	Figure 2 is the source data view of the data fields found in the		Figure 2 is the source data view of the data fields found in the
	Authentication Message as defined by [F3411]. This data is placed		Authentication Message as defined by [F3411]. This data is placed
	into the Authentication Payload shown in Figure 1, which spans		into the _Authentication Payload_ shown in Figure 1, which spans
	multiple Authentication Pages.		multiple _Authentication Pages_.
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Authentication Headers |		| Authentication Headers |
	| +---------------+---------------+		| +---------------+---------------+
	| | |		| | |
	+---------------+---------------+ |		+---------------+---------------+ |
	. .		. .
	. Authentication Data / Signature .		. Authentication Data / Signature .
	skipping to change at line 402 ¶		skipping to change at line 402 ¶
	| ADL | |		| ADL | |
	+---------------+ |		+---------------+ |
	. .		. .
	. Additional Data .		. Additional Data .
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 2: ASTM Authentication Message Fields		Figure 2: ASTM Authentication Message Fields
	Authentication Headers: (6 octets)		_Authentication Headers_: (6 octets)
	As defined in [F3411].		As defined in [F3411].
	Authentication Data / Signature: (0 to 255 octets)		_Authentication Data / Signature_: (0 to 255 octets)
	Opaque authentication data. The length of this payload is known		Opaque authentication data. The length of this payload is known
	through a field in the Authentication Headers (defined in		through a field in the _Authentication Headers_ (defined in
	[F3411]).		[F3411]).
	Additional Data Length (ADL): (1 octet - unsigned)		_Additional Data Length (ADL)_: (1 octet - unsigned)
	Length in octets of Additional Data. The value of ADL is		Length in octets of _Additional Data_. The value of _ADL_ is
	calculated as the minimum of 361 - Authentication Data / Signature		calculated as the minimum of _361 - Authentication Data /
	Length and 255. Only present with Additional Data.		Signature Length_ and 255. Only present with _Additional Data_.
	Additional Data: (ADL octets)		_Additional Data:_ (_ADL_ octets)
	Data that follows the Authentication Data / Signature but is not		Data that follows the _Authentication Data / Signature_ but is not
	considered part of the Authentication Data, and thus is not		considered part of the _Authentication Data_, and thus is not
	covered by a signature. For DRIP, this field is used to carry		covered by a signature. For DRIP, this field is used to carry
	Forward Error Correction (FEC) generated by transmitters and		Forward Error Correction (FEC) generated by transmitters and
	parsed by receivers as defined in Section 5.		parsed by receivers as defined in Section 5.
	3.2.3. SAM Data Format		3.2.3. SAM Data Format
	Figure 3 is the general format to hold authentication data when using		Figure 3 is the general format to hold authentication data when using
	SAM and is placed inside the Authentication Data / Signature field in		SAM and is placed inside the _Authentication Data / Signature_ field
	Figure 2.		in Figure 2.
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| SAM Type | |		| SAM Type | |
	+---------------+ |		+---------------+ |
	. .		. .
	. SAM Authentication Data .		. SAM Authentication Data .
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 3: SAM Data Format		Figure 3: SAM Data Format
	SAM Type: (1 octet)		_SAM Type_: (1 octet)
	The following SAM Types are allocated to DRIP:		The following SAM Types are allocated to DRIP:
	+==========+=============================+		+==========+=============================+
	| SAM Type | Description |		| SAM Type | Description |
	+==========+=============================+		+==========+=============================+
	| 0x01 | DRIP Link (Section 4.2) |		| 0x01 | DRIP Link (Section 4.2) |
	+----------+-----------------------------+		+----------+-----------------------------+
	| 0x02 | DRIP Wrapper (Section 4.3) |		| 0x02 | DRIP Wrapper (Section 4.3) |
	+----------+-----------------------------+		+----------+-----------------------------+
	skipping to change at line 470 ¶		skipping to change at line 470 ¶
	Table 1: DRIP SAM Types		Table 1: DRIP SAM Types
	| Note: ASTM International is the owner of these code points as		| Note: ASTM International is the owner of these code points as
	| they are defined in [F3411]. In accordance with Annex 5 of		| they are defined in [F3411]. In accordance with Annex 5 of
	| [F3411], the International Civil Aviation Organization (ICAO)		| [F3411], the International Civil Aviation Organization (ICAO)
	| has been selected by ASTM as the registrar to manage		| has been selected by ASTM as the registrar to manage
	| allocations of these code points. The list is available at		| allocations of these code points. The list is available at
	| [ASTM-Remote-ID].		| [ASTM-Remote-ID].
	SAM Authentication Data: (0 to 200 octets)		_SAM Authentication Data_: (0 to 200 octets)
	Contains opaque authentication data formatted as defined by the		Contains opaque authentication data formatted as defined by the
	preceding SAM Type.		preceding SAM Type.
	3.2.4. ASTM Broadcast RID Constraints		3.2.4. ASTM Broadcast RID Constraints
	3.2.4.1. Wireless Frame Constraints		3.2.4.1. Wireless Frame Constraints
	A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi		A UA has the option to broadcast using Bluetooth (4.x and 5.x), Wi-Fi
	NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and		NAN, or IEEE 802.11 Beacon; see Section 6. With Bluetooth, FAA and
	skipping to change at line 522 ¶		skipping to change at line 522 ¶
	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 that the		data being sent is REQUIRED to fit within the page limit that the
	most constrained existing transport can support. Under Broadcast		most constrained existing transport can support. Under Broadcast
	RID, the Extended Transport that can hold the least amount of		RID, the Extended Transport that can hold the least amount of
	authentication data is Bluetooth 5.x at 9 pages.		authentication data is Bluetooth 5.x 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:		when using the Authentication Message:
	1. Authentication Data / Signature data MUST fit in the first 9		1. _Authentication Data / Signature_ data MUST fit in the first 9
	pages (Page Numbers 0 through 8).		pages (Page Numbers 0 through 8).
	2. The Length field in the Authentication Headers (which encodes the		2. The _Length_ field in the _Authentication Headers_ (which encodes
	length in octets of Authentication Data / Signature only) MUST		the length in octets of _Authentication Data / Signature_ only)
	NOT exceed the value of 201. This includes the SAM Type but		MUST NOT exceed the value of 201. This includes the SAM Type but
	excludes Additional Data.		excludes _Additional Data_.
	3.2.4.3. Timestamps		3.2.4.3. Timestamps
	In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch		In ASTM [F3411], timestamps are a Unix-style timestamp with an epoch
	of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for		of 2019-01-01 00:00:00 UTC. For DRIP, this format is adopted for
	Authentication to keep a common time format in Broadcast payloads.		Authentication to keep a common time format in Broadcast payloads.
	Under DRIP, there are two timestamps defined: Valid Not Before (VNB)		Under DRIP, there are two timestamps defined: Valid Not Before (VNB)
	and Valid Not After (VNA).		and Valid Not After (VNA).
	skipping to change at line 563 ¶		skipping to change at line 563 ¶
	take into consideration the UA environment, propagation		take into consideration the UA environment, propagation
	characteristics of the messages being sent, and clock differences		characteristics of the messages being sent, and clock differences
	between the UA and Observers. For UA signatures in scenarios		between the UA and Observers. For UA signatures in scenarios
	typical as of 2024, a reasonable offset would be to set VNA		typical as of 2024, a reasonable offset would be to set VNA
	approximately 2 minutes after VNB; see Appendix B for examples		approximately 2 minutes after VNB; see Appendix B for examples
	that may aid in tuning this value.		that may aid in tuning this value.
	4. DRIP Authentication Formats		4. DRIP Authentication Formats
	All formats defined in this section are contained in the		All formats defined in this section are contained in the
	Authentication Data / Signature field in Figure 2 and use the		_Authentication Data / Signature_ field in Figure 2 and use the
	Specific Authentication Method (SAM, Authentication Type 0x5). The		Specific Authentication Method (SAM, Authentication Type 0x5). The
	first octet of the Authentication Data / Signature of Figure 2 is		first octet of the _Authentication Data / Signature_ of Figure 2 is
	used to multiplex among these various formats.		used to multiplex among these various formats.
	When sending data over a medium that does not have underlying FEC,		When sending data over a medium that does not have underlying FEC,
	for example Legacy Transports, then FEC (per Section 5) MUST be used.		for example Legacy Transports, then FEC (per Section 5) MUST be used.
	Examples of Link, Wrapper, and Manifest are shown as part of an		Examples of Link, Wrapper, and Manifest are shown as part of an
	operational schedule in Appendix B.2.1.		operational schedule in Appendix B.2.1.
	4.1. UA-Signed Evidence Structure		4.1. UA-Signed Evidence Structure
	The UA-Signed Evidence Structure (Figure 4) is used by the UA during		The _UA-Signed Evidence Structure_ (Figure 4) is used by the UA
	flight to sign over information elements using the private key		during flight to sign over information elements using the private key
	associated with the current UA DET. It is encapsulated by the SAM		associated with the current UA DET. It is encapsulated by the _SAM
	Authentication Data field of Figure 3.		Authentication Data_ field of Figure 3.
	This structure is used by the DRIP Wrapper (Section 4.3), Manifest		This structure is used by the DRIP Wrapper (Section 4.3), Manifest
	(Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST		(Section 4.4), and Frame (Section 4.5). DRIP Link (Section 4.2) MUST
	NOT use it, as it will not fit in the ASTM Authentication Message		NOT use it, as it will not fit in the ASTM Authentication Message
	with its intended content (i.e., a Broadcast Endorsement).		with its intended content (i.e., a Broadcast Endorsement).
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| VNB Timestamp by UA |		| VNB Timestamp by UA |
	skipping to change at line 624 ¶		skipping to change at line 624 ¶
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 4: Endorsement Structure for UA-Signed Evidence		Figure 4: Endorsement Structure for UA-Signed Evidence
	Valid Not Before (VNB) Timestamp by UA: (4 octets)		_Valid Not Before (VNB) Timestamp by UA_: (4 octets)
	See Section 3.2.4.3. Set by the UA.		See Section 3.2.4.3. Set by the UA.
	Valid Not After (VNA) Timestamp by UA: (4 octets)		_Valid Not After (VNA) Timestamp by UA_: (4 octets)
	See Section 3.2.4.3. Set by the UA.		See Section 3.2.4.3. Set by the UA.
	Evidence: (0 to 112 octets)		_Evidence_: (0 to 112 octets)
	The Evidence field MUST be filled in with data in the form of an		The _Evidence_ field MUST be filled in with data in the form of an
	opaque object specified in the DRIP Wrapper (Section 4.3),		opaque object specified in the DRIP Wrapper (Section 4.3),
	Manifest (Section 4.4), or Frame (Section 4.5).		Manifest (Section 4.4), or Frame (Section 4.5).
	UA DRIP Entity Tag: (16 octets)		_UA DRIP Entity Tag_: (16 octets)
	This is a DET [RFC9374] currently being used by the UA for		This is a DET [RFC9374] currently being used by the UA for
	authentication; it is assumed to be a Specific Session ID (a type		authentication; it is assumed to be a Specific Session ID (a type
	of UAS ID typically also used by the UA in the Basic ID Message).		of UAS ID typically also used by the UA in the Basic ID Message).
	UA Signature: (64 octets)		_UA Signature_: (64 octets)
	Signature over the concatenation of preceding fields (VNB, VNA,		Signature over the concatenation of preceding fields (_VNB_,
	Evidence, and UA DET) using the keypair of the UA DET. The		_VNA_, _Evidence_, and _UA DET_) using the keypair of the UA DET.
	signature algorithm is specified by the Hierarchical Host Identity		The signature algorithm is specified by the Hierarchical Host
	Tags (HHIT) Suite ID of the DET.		Identity Tags (HHIT) Suite ID of the DET.
	When using this structure, the UA is minimally self-endorsing its		When using this structure, the UA is minimally self-endorsing its
	DET. The HI of the UA DET can be looked up by mechanisms described		DET. The HI of the UA DET can be looked up by mechanisms described
	in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see		in [DRIP-REG] or by extracting it from a Broadcast Endorsement (see
	Sections 4.2 and 6.3).		Sections 4.2 and 6.3).
	4.2. DRIP Link		4.2. DRIP Link
	This SAM Type (Figure 5) is used to transmit Broadcast Endorsements.		This SAM Type (Figure 5) is used to transmit Broadcast Endorsements.
	For example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link		For example, the BE: HDA, UA is sent (see Section 6.3) as a DRIP Link
	skipping to change at line 720 ¶		skipping to change at line 720 ¶
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 5: Broadcast Endorsement / DRIP Link		Figure 5: Broadcast Endorsement / DRIP Link
	VNB Timestamp by Parent: (4 octets)		_VNB Timestamp by Parent_: (4 octets)
	See Section 3.2.4.3. Set by Parent Entity.		See Section 3.2.4.3. Set by Parent Entity.
	VNA Timestamp by Parent: (4 octets)		_VNA Timestamp by Parent_: (4 octets)
	See Section 3.2.4.3. Set by Parent Entity.		See Section 3.2.4.3. Set by Parent Entity.
	DET of Child: (16 octets)		_DET of Child_: (16 octets)
	DRIP Entity Tag of Child Entity.		DRIP Entity Tag of Child Entity.
	HI of Child: (32 octets)		_HI of Child_: (32 octets)
	Host Identity of Child Entity.		Host Identity of Child Entity.
	DET of Parent: (16 octets)		_DET of Parent_: (16 octets)
	DRIP Entity Tag of Parent Entity in DIME Hierarchy.		DRIP Entity Tag of Parent Entity in DIME Hierarchy.
	Signature by Parent: (64 octets)		_Signature by Parent_: (64 octets)
	Signature over concatenation of preceding fields (VNB, VNA, DET of		Signature over concatenation of preceding fields (_VNB_, _VNA_,
	Child, HI of Child, and DET of Parent) using the keypair of the		_DET of Child_, _HI of Child_, and _DET of Parent_) using the
	Parent DET.		keypair of the Parent DET.
	This DRIP Authentication Message is used in conjunction with other		This DRIP Authentication Message is used in conjunction with other
	DRIP SAM Types (such as the Manifest or the Wrapper) that contain		DRIP SAM Types (such as the Manifest or the Wrapper) that contain
	data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that		data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that
	is guaranteed to be unique, unpredictable, and easily cross-checked		is guaranteed to be unique, unpredictable, and easily cross-checked
	by the receiving device.		by the receiving device.
	A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement		A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
	chain MUST be included in each DRIP Manifest (Section 4.4).		chain MUST be included in each DRIP Manifest (Section 4.4).
	skipping to change at line 768 ¶		skipping to change at line 768 ¶
	hierarchy, the parent of the UA is its HHIT Domain Authority (HDA),		hierarchy, the parent of the UA is its HHIT Domain Authority (HDA),
	the parent of an HDA is its Registered Assigning Authority (RAA),		the parent of an HDA is its Registered Assigning Authority (RAA),
	etc. It is also assumed that all DRIP-aware entities use a DET as		etc. It is also assumed that all DRIP-aware entities use a DET as
	their identifier during interactions with other DRIP-aware entities.		their identifier during interactions with other DRIP-aware entities.
	4.3. DRIP Wrapper		4.3. DRIP Wrapper
	This SAM Type is used to wrap and sign over a list of other [F3411]		This SAM Type is used to wrap and sign over a list of other [F3411]
	Broadcast RID messages.		Broadcast RID messages.
	The Evidence field of the UA-Signed Evidence Structure (Section 4.1)		The _Evidence_ field of the _UA-Signed Evidence Structure_
	is populated with up to four ASTM Messages [F3411] in a contiguous		(Section 4.1) is populated with up to four ASTM Messages [F3411] in a
	octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5		contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3,
	are allowed and must be in Message Type order as defined by [F3411].		0x4, and 0x5 are allowed and must be in Message Type order as defined
	These messages MUST include the Message Type and Protocol Version		by [F3411]. These messages MUST include the Message Type and
	octet and MUST NOT include the Message Counter octet (thus are fixed		Protocol Version octet and MUST NOT include the Message Counter octet
	at 25 octets in length).		(thus are fixed at 25 octets in length).
	4.3.1. Wrapped Count and Format Validation		4.3.1. Wrapped Count and Format Validation
	When decoding a DRIP Wrapper on a receiver, a calculation of the		When decoding a DRIP Wrapper on a receiver, a calculation of the
	number of messages wrapped and a validation MUST be performed by		number of messages wrapped and a validation MUST be performed by
	using the number of octets (defined as wrapperLength) between the VNA		using the number of octets (defined as wrapperLength) between the
	Timestamp by UA and the UA DET as shown in Figure 6.		_VNA Timestamp by UA_ and the _UA DET_ as shown in Figure 6.
	<CODE BEGINS>		<CODE BEGINS>
	if (wrapperLength MOD 25) != 0 {		if (wrapperLength MOD 25) != 0 {
	return DECODE_FAILURE;		return DECODE_FAILURE;
	}		}
	wrappedCount = wrapperLength / 25;		wrappedCount = wrapperLength / 25;
	if (wrappedCount == 0) {		if (wrappedCount == 0) {
	// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport		// DECODE_SUCCESS; treat as DRIP Wrapper over extended transport
	}		}
	else if (wrappedCount > 4) {		else if (wrappedCount > 4) {
	skipping to change at line 807 ¶		skipping to change at line 807 ¶
	Figure 6: Pseudocode for Wrapper Validation and Number of		Figure 6: Pseudocode for Wrapper Validation and Number of
	Messages Calculation		Messages Calculation
	4.3.2. Wrapper over Extended Transports		4.3.2. Wrapper over Extended Transports
	When using Extended Transports, an optimization to DRIP Wrapper can		When using Extended Transports, an optimization to DRIP Wrapper can
	be made to sign over co-located data in an ASTM Message Pack (Message		be made to sign over co-located data in an ASTM Message Pack (Message
	Type 0xF).		Type 0xF).
	To perform this optimization, the UA-Signed Evidence Structure is		To perform this optimization, the _UA-Signed Evidence Structure_ is
	filled with the ASTM Messages to be in the ASTM Message Pack, the		filled with the ASTM Messages to be in the ASTM Message Pack, the
	signature is generated, and then the Evidence field is cleared,		signature is generated, and then the _Evidence_ field is cleared,
	leaving the encoded form shown in Figure 7.		leaving the encoded form shown in Figure 7.
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| VNB Timestamp by UA |		| VNB Timestamp by UA |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| VNA Timestamp by UA |		| VNA Timestamp by UA |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| |		| |
	skipping to change at line 847 ¶		skipping to change at line 847 ¶
	| |		| |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 7: DRIP Wrapper over Extended Transports		Figure 7: DRIP Wrapper over Extended Transports
	To verify the signature, the receiver MUST concatenate all the		To verify the signature, the receiver MUST concatenate all the
	messages in the Message Pack (excluding the Authentication Message		messages in the Message Pack (excluding the Authentication Message
	found in the same Message Pack) in ASTM Message Type order and set		found in the same Message Pack) in ASTM Message Type order and set
	the Evidence field of the UA-Signed Evidence Structure before		the _Evidence_ field of the _UA-Signed Evidence Structure_ before
	performing signature verification.		performing signature verification.
	The functionality of a Wrapper in this form is equivalent to Message		The functionality of a Wrapper in this form is equivalent to Message
	Set Signature (Authentication Type 0x3) when running over Extended		Set Signature (Authentication Type 0x3) when running over Extended
	Transports. The Wrapper provides the same format but over both		Transports. The Wrapper provides the same format but over both
	Extended and Legacy Transports, which allows the transports to be		Extended and Legacy Transports, which allows the transports to be
	similar. Message Set Signature also implies using the ASTM validator		similar. Message Set Signature also implies using the ASTM validator
	system architecture, which depends on Internet connectivity for		system architecture, which depends on Internet connectivity for
	verification that the receiver may not have at the time an		verification that the receiver may not have at the time an
	Authentication Message is received. This is something the Wrapper,		Authentication Message is received. This is something the Wrapper,
	skipping to change at line 889 ¶		skipping to change at line 889 ¶
	Wrapper (Section 4.3.3) and greatly reduce overhead.		Wrapper (Section 4.3.3) and greatly reduce overhead.
	Observers MUST hash all received ASTM Messages and cross-check them		Observers MUST hash all received ASTM Messages and cross-check them
	against hashes in received Manifests.		against hashes in received Manifests.
	Judicious use of a Manifest enables an entire Broadcast RID message		Judicious use of a Manifest enables an entire Broadcast RID message
	stream to be strongly authenticated with less than 100% overhead		stream to be strongly authenticated with less than 100% overhead
	relative to a completely unauthenticated message stream (see		relative to a completely unauthenticated message stream (see
	Section 6.3 and Appendix B).		Section 6.3 and Appendix B).
	The Evidence field of the UA-Signed Evidence Structure (Section 4.1)		The _Evidence_ field of the _UA-Signed Evidence Structure_
	is populated with 8-octet hashes of [F3411] Broadcast RID messages		(Section 4.1) is populated with 8-octet hashes of [F3411] Broadcast
	(up to 11) and three special hashes (Section 4.4.2). All of these		RID messages (up to 11) and three special hashes (Section 4.4.2).
	hashes MUST be concatenated to form a contiguous octet sequence in		All of these hashes MUST be concatenated to form a contiguous octet
	the Evidence field. It is RECOMMENDED that the maximum number of		sequence in the _Evidence_ field. It is RECOMMENDED that the maximum
	ASTM Message Hashes used be 10 (see Appendix B.1.1.2).		number of ASTM Message Hashes used be 10 (see Appendix B.1.1.2).
	The Previous Manifest Hash, Current Manifest Hash, and DRIP Link (BE:		The _Previous Manifest Hash_, _Current Manifest Hash_, and _DRIP Link
	HDA, UA) Hash MUST always come before the ASTM Message Hashes as seen		(BE: HDA, UA) Hash_ MUST always come before the _ASTM Message Hashes_
	in Figure 8.		as seen in Figure 8.
	An Observer MUST use the Manifest to verify each ASTM Message hashed		An Observer MUST use the Manifest to verify each ASTM Message hashed
	therein that it has previously received. It can do this without		therein that it has previously received. It can do this without
	having received them all. A Manifest SHOULD typically encompass a		having received them all. A Manifest SHOULD typically encompass a
	single transmission cycle of messages being sent; see Section 6.4 and		single transmission cycle of messages being sent; see Section 6.4 and
	Appendix B.		Appendix B.
	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 line 927 ¶		skipping to change at line 927 ¶
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| |		| |
	. .		. .
	. ASTM Message Hashes .		. ASTM Message Hashes .
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 8: DRIP Manifest Evidence Structure		Figure 8: DRIP Manifest Evidence Structure
	Previous Manifest Hash: (8 octets)		_Previous Manifest Hash_: (8 octets)
	Hash of the previously sent Manifest Message.		Hash of the previously sent Manifest Message.
	Current Manifest Hash: (8 octets)		_Current Manifest Hash_: (8 octets)
	Hash of the current Manifest Message.		Hash of the current Manifest Message.
	DRIP Link (BE: HDA, UA): (8 octets)		_DRIP Link (BE: HDA, UA)_: (8 octets)
	Hash of the DRIP Link Authentication Message carrying BE: HDA, UA		Hash of the DRIP Link Authentication Message carrying BE: HDA, UA
	(see Section 4.2).		(see Section 4.2).
	ASTM Message Hash: (8 octets)		_ASTM Message Hash_: (8 octets)
	Hash of a single full ASTM Message using hash operations described		Hash of a single full ASTM Message using hash operations described
	in Section 4.4.3.		in Section 4.4.3.
	4.4.1. Hash Count and Format Validation		4.4.1. Hash Count and Format Validation
	When decoding a DRIP Manifest on a receiver, a calculation of the		When decoding a DRIP Manifest on a receiver, a calculation of the
	number of hashes and a validation can be performed by using the		number of hashes and a validation can be performed by using the
	number of octets between the UA DET and the VNB Timestamp by UA		number of octets between the _UA DET_ and the _VNB Timestamp by UA_
	(defined as manifestLength) such as shown in Figure 9.		(defined as manifestLength) such as shown in Figure 9.
	<CODE BEGINS>		<CODE BEGINS>
	if (manifestLength MOD 8) != 0 {		if (manifestLength MOD 8) != 0 {
	return DECODE_FAILURE		return DECODE_FAILURE
	}		}
	hashCount = (manifestLength / 8) - 3;		hashCount = (manifestLength / 8) - 3;
	<CODE ENDS>		<CODE ENDS>
	Figure 9: Pseudocode for Manifest Sanity Check and Number of		Figure 9: Pseudocode for Manifest Sanity Check and Number of
	Hashes Calculation		Hashes Calculation
	4.4.2. Manifest Ledger Hashes		4.4.2. Manifest Ledger Hashes
	The following three special hashes are included in all Manifests:		The following three special hashes are included in all Manifests:
	* the Previous Manifest Hash links to the previous Manifest.		* the _Previous Manifest Hash_ links to the previous Manifest.
	* the Current Manifest Hash is of the Manifest in which it appears.		* the _Current Manifest Hash_ is of the Manifest in which it
			appears.
	* the DRIP Link (BE: HDA, UA) Hash ties the endorsed UA key to the		* the _DRIP Link (BE: HDA, UA) Hash_ ties the endorsed UA key to the
	Manifest chain.		Manifest chain.
	The Previous and Current hashes act as a ledger of provenance for the		The Previous and Current hashes act as a ledger of provenance for the
	Manifest chain, which should be traced back if the Observer and UA		Manifest chain, which should be traced back if the Observer and UA
	were within Broadcast RID wireless range of each other for an		were within Broadcast RID wireless range of each other for an
	extended period of time.		extended period of time.
	The DRIP Link (BE: HDA, UA) is included so there is a direct		The _DRIP Link (BE: HDA, UA)_ is included so there is a direct
	signature by the UA over the Broadcast Endorsement (see Section 4.2).		signature by the UA over the Broadcast Endorsement (see Section 4.2).
	Typical operation would expect that the list of ASTM Message Hashes		Typical operation would expect that the list of _ASTM Message Hashes_
	contain nonce-like data. To enforce a binding between the BE: HDA,		contain nonce-like data. To enforce a binding between the BE: HDA,
	UA and avoid trivial replay attack vectors (see Section 9.1), at		UA and avoid trivial replay attack vectors (see Section 9.1), at
	least one ASTM Message Hash MUST be from an [F3411] message that		least one _ASTM Message Hash_ MUST be from an [F3411] message that
	satisfies the fourth requirement in Section 6.3.		satisfies the fourth requirement in Section 6.3.
	4.4.3. Hash Algorithms and Operation		4.4.3. Hash Algorithms and Operation
	The hash algorithm used for the Manifest is the same hash algorithm		The hash algorithm used for the Manifest is the same hash algorithm
	used in creation of the DET [RFC9374] that is signing the Manifest.		used in creation of the DET [RFC9374] that is signing the Manifest.
	This is encoded as part of the DET using the HHIT Suite ID.		This is encoded as part of the DET using the HHIT Suite ID.
	DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as		DETs that use cSHAKE128 [NIST.SP.800-185] compute the hash as
	follows:		follows:
	cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")		cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")
	For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/		For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/
	cSHAKE128) [RFC9374], use the construct appropriate for the		cSHAKE128) [RFC9374], use the construct appropriate for the
	associated hash. For example, the hash for "2" (ECDSA/SHA-384) is		associated hash. For example, the hash for "2" (ECDSA/SHA-384) is
	computed as follows:		computed as follows:
	Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )		Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )
	When building the list of hashes, the Previous Manifest Hash is known		When building the list of hashes, the _Previous Manifest Hash_ is
	from the previous Manifest. For the first built Manifest, this value		known from the previous Manifest. For the first built Manifest, this
	is filled with a random nonce. The Current Manifest Hash is null		value is filled with a random nonce. The _Current Manifest Hash_ is
	filled while ASTM Messages are hashed and fill the ASTM Message		null filled while ASTM Messages are hashed and fill the _ASTM Message
	Hashes field. When all messages are hashed, the Current Manifest		Hashes_ field. When all messages are hashed, the _Current Manifest
	Hash is computed over the Previous Manifest Hash, Current Manifest		Hash_ is computed over the _Previous Manifest Hash_, _Current
	Hash (null filled), and ASTM Message Hashes. This hash value		Manifest Hash_ (null filled), and _ASTM Message Hashes_. This hash
	replaces the null-filled Current Manifest Hash and becomes the		value replaces the null-filled _Current Manifest Hash_ and becomes
	Previous Manifest Hash for the next Manifest.		the _Previous Manifest Hash_ for the next Manifest.
	4.4.3.1. Legacy Transport Hashing		4.4.3.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
	over the Bluetooth Advertising frame. This is the 25-octet object		over the Bluetooth Advertising frame. This is the 25-octet object
	that starts with the Message Type and Protocol Version octet along		that starts with the Message Type and Protocol Version octet along
	with the 24 octets of message data. The hash MUST NOT include the		with the 24 octets of message data. The hash MUST NOT include the
	Message Counter octet.		Message Counter octet.
	For paged ASTM Messages (currently only Authentication Messages), all		For paged ASTM Messages (currently only Authentication Messages), all
	skipping to change at line 1034 ¶		skipping to change at line 1035 ¶
	hashed as one object.		hashed as one object.
	4.4.3.2. Extended Transport Hashing		4.4.3.2. Extended Transport Hashing
	Under this transport, DRIP hashes the full ASTM Message Pack (Message		Under this transport, DRIP hashes the full ASTM Message Pack (Message
	Type 0xF) regardless of its content. The hash MUST NOT include the		Type 0xF) regardless of its content. The hash MUST NOT include the
	Message Counter octet.		Message Counter octet.
	4.5. DRIP Frame		4.5. DRIP Frame
	This SAM Type is defined to enable use of the UA-Signed Evidence		This SAM Type is defined to enable use of the _UA-Signed Evidence
	Structure (Section 4.1) in the future beyond the previously defined		Structure_ (Section 4.1) in the future beyond the previously defined
	formats (Wrapper and Manifest) by the inclusion of a single octet to		formats (Wrapper and Manifest) by the inclusion of a single octet to
	signal the format of Evidence data (up to 111 octets).		signal the format of _Evidence_ data (up to 111 octets).
	The content format of Frame Evidence Data is not defined in this		The content format of _Frame Evidence Data_ is not defined in this
	document. Other specifications MUST define the contents and register		document. Other specifications MUST define the contents and register
	for a Frame Type. At the time of publication (2024), there are no		for a _Frame Type_. At the time of publication (2024), there are no
	defined Frame Types; only an Experimental range has been defined.		defined Frame Types; only an Experimental range has been defined.
	Observers MUST check the signature of the structure (Section 4.1) per		Observers MUST check the signature of the structure (Section 4.1) per
	Section 3.1.2.2 and MAY, if the specification of Frame Type is known,		Section 3.1.2.2 and MAY, if the specification of _Frame Type_ is
	parse the content in Frame Evidence Data.		known, parse the content in _Frame Evidence Data_.
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Frame Type | |		| Frame Type | |
	+---------------+ .		+---------------+ .
	. Frame Evidence Data .		. Frame Evidence Data .
	. .		. .
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 10: DRIP Frame		Figure 10: DRIP Frame
	Frame Type: (1 octet)		_Frame Type_: (1 octet)
	As shown in Figure 10, the Frame Type takes the first octet, which		As shown in Figure 10, the _Frame Type_ takes the first octet,
	leaves 111 octets available for Frame Evidence Data. See		which leaves 111 octets available for _Frame Evidence Data_. See
	Section 8.1 for Frame Type allocations.		Section 8.1 for Frame Type allocations.
	5. Forward Error Correction		5. Forward Error Correction
	For Broadcast RID, FEC is provided by the lower layers in Extended		For Broadcast RID, FEC is provided by the lower layers in Extended
	Transports. The Bluetooth 4.x Legacy Transport does not support FEC,		Transports. The Bluetooth 4.x Legacy Transport does not support FEC,
	so the following application-level scheme is used with DRIP		so the following application-level scheme is used with DRIP
	Authentication to add some FEC. When sending data over a medium that		Authentication to add some FEC. When sending data over a medium that
	does not have underlying FEC, for example Bluetooth 4.x, this section		does not have underlying FEC, for example Bluetooth 4.x, this section
	MUST be used.		MUST be used.
	skipping to change at line 1091 ¶		skipping to change at line 1092 ¶
	all page data of an Authentication Message. This allows the		all page data of an Authentication Message. This allows the
	correction of a single erased page in an Authentication Message. If		correction of a single erased page in an Authentication Message. If
	more than a single page is missing, then handling of an incomplete		more than a single page is missing, then handling of an incomplete
	Authentication Message is determined by higher layers.		Authentication Message is determined by higher layers.
	Other FEC schemes, to protect more than a single page of an		Other FEC schemes, to protect more than a single page of an
	Authentication Message or multiple [F3411] Messages, are left for		Authentication Message or multiple [F3411] Messages, are left for
	future standardization if operational experience proves it necessary		future standardization if operational experience proves it necessary
	and/or practical.		and/or practical.
	The data added during FEC is not included in the Authentication Data		The data added during FEC is not included in the _Authentication Data
	/ Signature, but instead in the Additional Data field of Figure 2.		/ Signature_, but instead in the _Additional Data_ field of Figure 2.
	This may cause the Authentication Message to exceed 9 pages, up to a		This may cause the Authentication Message to exceed 9 pages, up to a
	maximum of 16 pages.		maximum of 16 pages.
	5.1. Encoding		5.1. Encoding
	When encoding, two things are REQUIRED:		When encoding, two things are REQUIRED:
	1. The FEC data MUST start on a new Authentication Page. To do		1. The FEC data MUST start on a new Authentication Page. To do
	this, the results of parity encoding MUST be placed in the		this, the results of parity encoding MUST be placed in the
	Additional Data field of Figure 2 with null padding before it to		_Additional Data_ field of Figure 2 with null padding before it
	line up with the next page. The Additional Data Length field		to line up with the next page. The _Additional Data Length_
	MUST be set to number of padding octets + number of parity		field MUST be set to number of padding octets + number of parity
	octets.		octets.
	2. The Last Page Index field (in Page 0) MUST be incremented from		2. The _Last Page Index_ field (in Page 0) MUST be incremented from
	what it would have been without FEC by the number of pages		what it would have been without FEC by the number of pages
	required for the Additional Data Length field, null padding, and		required for the _Additional Data Length_ field, null padding,
	FEC.		and FEC.
	To generate the parity, a simple XOR operation using the previous		To generate the parity, a simple XOR operation using the previous
	parity page and current page is used. Only the 23-octet		parity page and current page is used. Only the 23-octet
	Authentication Payload field of Figure 1 is used in the XOR		_Authentication Payload_ field of Figure 1 is used in the XOR
	operations. For Page 0, a 23-octet null pad is used for the previous		operations. For Page 0, a 23-octet null pad is used for the previous
	parity page.		parity page.
	Figure 11 shows an example of the last two pages (out of N) of an		Figure 11 shows an example of the last two pages (out of N) of an
	Authentication Message using DRIP Single Page FEC. The Additional		Authentication Message using DRIP Single Page FEC. The _Additional
	Data Length is set to 33, as there are always 23 octets of FEC data		Data Length_ is set to 33, as there are always 23 octets of FEC data
	and there are 10 octets of padding in this example to line it up into		and there are 10 octets of padding in this example to line it up into
	Page N.		Page N.
	Page N-1:		Page N-1:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Page Header | |		| Page Header | |
	+---------------+ |		+---------------+ |
	| Authentication Data / Signature |		| Authentication Data / Signature |
	skipping to change at line 1157 ¶		skipping to change at line 1158 ¶
	| |		| |
	| |		| |
	| |		| |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 11: Example Single Page FEC Encoding		Figure 11: Example Single Page FEC Encoding
	5.2. Decoding		5.2. Decoding
	Frame decoding is independent of the transmit media. However, the		Frame decoding is independent of the transmit media. However, the
	decoding process can determine from the first Authentication page		decoding process can determine from the first Authentication Page
	that there may be a Bluetooth 4.x FEC page at the end. The decoding		that there may be a Bluetooth 4.x FEC page at the end. The decoding
	process MUST test for the presence of FEC and apply it as follows.		process MUST test for the presence of FEC and apply it as follows.
	To determine if FEC has been used, a check of the Last Page Index is		To determine if FEC has been used, a check of the _Last Page Index_
	performed. In general, if the Last Page Index field is one greater		is performed. In general, if the _Last Page Index_ field is one
	than that necessary to hold Length octets of Authentication Data,		greater than that necessary to hold _Length_ octets of Authentication
	then FEC has been used. Note that if Length octets are exhausted		Data, then FEC has been used. Note that if _Length_ octets are
	exactly at the end of an Authentication Page, the Additional Data		exhausted exactly at the end of an Authentication Page, the
	Length field will occupy the first octet of the following page. The		_Additional Data Length_ field will occupy the first octet of the
	remainder of this page will be null padded under DRIP to align the		following page. The remainder of this page will be null padded under
	FEC to its own page. In this case, the Last Page Index will have		DRIP to align the FEC to its own page. In this case, the _Last Page
	been incremented once for initializing the Additional Data Length		Index_ will have been incremented once for initializing the
	field and once for the FEC page, for a total of two additional pages,		_Additional Data Length_ field and once for the FEC page, for a total
	as in the last row of Table 5.		of two additional pages, as in the last row of Table 5.
	To decode FEC in DRIP, a rolling XOR is used on each Authentication		To decode FEC in DRIP, a rolling XOR is used on each _Authentication
	Page received in the current Authentication Message. A Message		Page_ received in the current Authentication Message. A Message
	Counter, outside of the ASTM Message but specified in [F3411], is		Counter, outside of the ASTM Message but specified in [F3411], is
	used to signal a different Authentication Message and to correlate		used to signal a different Authentication Message and to correlate
	pages to messages. This Message Counter is only a single octet in		pages to messages. This Message Counter is only a single octet in
	length, so it will roll over (to 0x00) after reaching its maximum		length, so it will roll over (to 0x00) after reaching its maximum
	value (0xFF). If only a single page is missing in the Authentication		value (0xFF). If only a single page is missing in the Authentication
	Message the resulting parity octets should be the data of the erased		Message the resulting parity octets should be the data of the erased
	page.		page.
	Authentication Page 0 contains various important fields, only located		Authentication Page 0 contains various important fields, only located
	on that page, that help decode the full ASTM Authentication Message.		on that page, that help decode the full ASTM Authentication Message.
	If Page 0 has been reconstructed, the Last Page Index and Length		If Page 0 has been reconstructed, the _Last Page Index_ and _Length_
	fields MUST be validated by DRIP. The pseudocode in Figure 12 can be		fields MUST be validated by DRIP. The pseudocode in Figure 12 can be
	used for both checks.		used for both checks.
	<CODE BEGINS>		<CODE BEGINS>
	function decode_check(auth_pages[], decoded_lpi, decoded_length) {		function decode_check(auth_pages[], decoded_lpi, decoded_length) {
	// check decoded_lpi does not exceed maximum value		// check decoded_lpi does not exceed maximum value
	if (decoded_lpi >= 16) {		if (decoded_lpi >= 16) {
	return DECODE_FAILURE		return DECODE_FAILURE
	}		}
	skipping to change at line 1234 ¶		skipping to change at line 1235 ¶
	return DECODE_FAILURE		return DECODE_FAILURE
	}		}
	return DECODE_SUCCESS		return DECODE_SUCCESS
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 12: Pseudocode for Decode Checks		Figure 12: Pseudocode for Decode Checks
	5.3. FEC Limitations		5.3. FEC Limitations
	The worst-case scenario is when the Authentication Data / Signature		The worst-case scenario is when the _Authentication Data / Signature_
	ends perfectly on a page boundary (Page N-1). This means the		ends perfectly on a page boundary (Page N-1). This means the
	Additional Data Length would start the next page (Page N) and have 22		_Additional Data Length_ would start the next page (Page N) and have
	octets worth of null padding to align the FEC to begin at the start		22 octets worth of null padding to align the FEC to begin at the
	of the next page (Page N+1). In this scenario, an entire page (Page		start of the next page (Page N+1). In this scenario, an entire page
	N) is being wasted just to carry the Additional Data Length.		(Page N) is being wasted just to carry the _Additional Data Length_.
	6. Requirements and Recommendations		6. Requirements and Recommendations
	6.1. Legacy Transports		6.1. Legacy Transports
	Under DRIP, the goal is to bring reliable receipt of the paged		Under DRIP, the goal is to bring reliable receipt of the paged
	Authentication Message using Legacy Transports. FEC (Section 5) MUST		Authentication Message using Legacy Transports. FEC (Section 5) MUST
	be used, per mandated RID rules (for example, the US FAA RID Rules		be used, per mandated RID rules (for example, the US FAA RID Rules
	[FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x).		[FAA-14CFR]), when using Legacy Transports (such as Bluetooth 4.x).
	skipping to change at line 1571 ¶		skipping to change at line 1572 ¶
	frames* (manifest frame count + base frame count).		frames* (manifest frame count + base frame count).
	9.3. VNA Timestamp Offsets for DRIP Authentication Formats		9.3. VNA Timestamp Offsets for DRIP Authentication Formats
	Note the discussion of VNA Timestamp offsets here is in the context		Note the discussion of VNA Timestamp offsets here is in the context
	of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and		of the DRIP Wrapper (Section 4.3), DRIP Manifest (Section 4.4), and
	DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets		DRIP Frame (Section 4.5). For DRIP Link (Section 4.2), these offsets
	are set by the DIME and have their own set of considerations in		are set by the DIME and have their own set of considerations in
	[DRIP-REG].		[DRIP-REG].
	The offset of the VNA Timestamp by UA is one that needs careful		The offset of the _VNA Timestamp by UA_ is one that needs careful
	consideration for any implementation. The offset should be shorter		consideration for any implementation. The offset should be shorter
	than any given flight duration (typically less than an hour) but be		than any given flight duration (typically less than an hour) but be
	long enough to be received and processed by Observers (larger than a		long enough to be received and processed by Observers (larger than a
	few seconds). It is recommended that 3-5 minutes should be		few seconds). It is recommended that 3-5 minutes should be
	sufficient to serve this purpose in any scenario, but it is not		sufficient to serve this purpose in any scenario, but it is not
	limited by design.		limited by design.
	9.4. DNS Security in DRIP		9.4. DNS Security in DRIP
	As stated in Section 3.1 specification of particular DNS security		As stated in Section 3.1 specification of particular DNS security
	skipping to change at line 1730 ¶		skipping to change at line 1731 ¶
	Table 4: Authentication State Names, Colors, and Descriptions		Table 4: Authentication State Names, Colors, and Descriptions
	A.1. None: Black		A.1. None: Black
	The default state where authentication information has not yet been		The default state where authentication information has not yet been
	received and is not currently being received.		received and is not currently being received.
	A.2. Partial: Gray		A.2. Partial: Gray
	A pending state where authentication pages are being received, but a		A pending state where Authentication Pages are being received, but a
	full Authentication Message has yet to be compiled.		full Authentication Message has yet to be compiled.
	A.3. Unsupported: Brown		A.3. Unsupported: Brown
	A state wherein authentication data is being or has been received but		A state wherein authentication data is being or has been received but
	cannot be used, as the Authentication Type or SAM Type is not		cannot be used, as the Authentication Type or SAM Type is not
	supported by the Observer.		supported by the Observer.
	A.4. Unverifiable: Yellow		A.4. Unverifiable: Yellow
	skipping to change at line 1922 ¶		skipping to change at line 1923 ¶
	five slots; thus it can authenticate up to four ASTM Messages co-		five slots; thus it can authenticate up to four ASTM Messages co-
	located in the same Message Pack.		located in the same Message Pack.
	B.1.1.2. Eleven ASTM Messages		B.1.1.2. Eleven ASTM Messages
	Eleven ASTM Messages (see Table 5) is where a Manifest with FEC		Eleven ASTM Messages (see Table 5) is where a Manifest with FEC
	invokes the situation mentioned in Section 5.3.		invokes the situation mentioned in Section 5.3.
	Eleven is the maximum number of ASTM Message Hashes that can be		Eleven is the maximum number of ASTM Message Hashes that can be
	supported resulting in 14 total hashes. This completely fills the		supported resulting in 14 total hashes. This completely fills the
	Evidence field of the UA-Signed Evidence Structure making its total		_Evidence_ field of the _UA-Signed Evidence Structure_ making its
	size 200 octets. This fits on exactly 9 Authentication Pages ((201 -		total size 200 octets. This fits on exactly 9 Authentication Pages
	17) / 23 == 8), so when the ADL is added, it is placed on the next		((201 - 17) / 23 == 8), so when the ADL is added, it is placed on the
	page (Page 10). Per rule 1 in Section 5.1, this means that all of		next page (Page 10). Per rule 1 in Section 5.1, this means that all
	Page 10 is null padded (expect the ADL octet) and FEC data fills Page		of Page 10 is null padded (expect the ADL octet) and FEC data fills
	11, resulting in a plus-two page count when FEC is applied.		Page 11, resulting in a plus-two page count when FEC is applied.
	This drives the recommendation is Section 4.4 to only use up to 10		This drives the recommendation is Section 4.4 to only use up to 10
	ASTM Message Hashes, not 11.		ASTM Message Hashes, not 11.
	B.2. Full Authentication Example		B.2. Full Authentication Example
	This example (Figure 13) is focused on showing that 100% of ASTM		This example (Figure 13) is focused on showing that 100% of ASTM
	Messages can be authenticated over Legacy Transports with up to 125%		Messages can be authenticated over Legacy Transports with up to 125%
	overhead in Authentication Pages. Extended Transports are not shown		overhead in Authentication Pages. Extended Transports are not shown
	in this example, because, for those, Authentication with DRIP is		in this example, because, for those, Authentication with DRIP is
	skipping to change at line 2092 ¶		skipping to change at line 2093 ¶
	LLC for early prototyping to find holes in earlier drafts of this		LLC for early prototyping to find holes in earlier drafts of this
	specification.		specification.
	* Carsten Bormann for the simple approach of using bit-column-wise		* Carsten Bormann for the simple approach of using bit-column-wise
	parity for erasure (dropped frame) FEC.		parity for erasure (dropped frame) FEC.
	* Soren Friis for pointing out that Wi-Fi implementations would not		* Soren Friis for pointing out that Wi-Fi implementations would not
	always give access to the MAC Address, as was originally used in		always give access to the MAC Address, as was originally used in
	calculation of the hashes for DRIP Manifest. Also, for confirming		calculation of the hashes for DRIP Manifest. Also, for confirming
	that Message Packs (0xF) can only carry up to 9 ASTM frames worth		that Message Packs (0xF) can only carry up to 9 ASTM frames worth
	of data (9 Authentication pages).		of data (9 Authentication Pages).
	* Gabriel Cox (chair of the working group that produced [F3411]) for		* Gabriel Cox (chair of the working group that produced [F3411]) for
	reviewing the specification for the SAM Type request as the ASTM		reviewing the specification for the SAM Type request as the ASTM
	Designated Expert.		Designated Expert.
	* Mohamed Boucadair (Document Shepherd) for his many patches and		* Mohamed Boucadair (Document Shepherd) for his many patches and
	comments.		comments.
	* Eric Vyncke (DRIP AD) for his guidance regarding the document's		* Eric Vyncke (DRIP AD) for his guidance regarding the document's
	path to publication.		path to publication.
End of changes. 75 change blocks.
	140 lines changed or deleted		141 lines changed or added
This html diff was produced by rfcdiff 1.48.