rfc9575.original.xml   rfc9575.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.2 --> <!-- draft submitted in xml v3 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc sortrefs="yes"?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc comments="yes"?> <!ENTITY nbhy "&#8209;">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <!ENTITY wj "&#8288;">
-ietf-drip-auth-49" category="std" obsoletes="" updates="" submissionType="IETF" ]>
xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-drip-auth-49"
number="9575"
category="std"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
consensus="true"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
<front> <front>
<title abbrev="DRIP Auth Formats">DRIP Entity Tag Authentication Formats &am <title abbrev="DRIP Auth Formats">DRIP Entity Tag Authentication Formats and
p; Protocols for Broadcast Remote ID</title> Protocols for Broadcast Remote Identification</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-drip-auth-49"/> <seriesInfo name="RFC" value="9575"/>
<author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" ro le="editor"> <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" ro le="editor">
<organization>AX Enterprize, LLC</organization> <organization>AX Enterprize, LLC</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville</city> <city>Yorkville</city>
<region>NY</region> <region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>adam.wiethuechter@axenterprize.com</email> <email>adam.wiethuechter@axenterprize.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Card" fullname="Stuart Card"> <author initials="S." surname="Card" fullname="Stuart Card">
<organization>AX Enterprize, LLC</organization> <organization>AX Enterprize, LLC</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville</city> <city>Yorkville</city>
<region>NY</region> <region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>stu.card@axenterprize.com</email> <email>stu.card@axenterprize.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Moskowitz" fullname="Robert Moskowitz"> <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
<organization>HTT Consulting</organization> <organization>HTT Consulting</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Oak Park</city> <city>Oak Park</city>
<region>MI</region> <region>MI</region>
<code>48237</code> <code>48237</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>rgm@labs.htt-consult.com</email> <email>rgm@labs.htt-consult.com</email>
</address> </address>
</author> </author>
<date year="2024" month="February" day="21"/> <date year="2024" month="April"/>
<area>Internet</area>
<workgroup>DRIP Working Group</workgroup> <area>INT</area>
<keyword>Internet-Draft</keyword> <workgroup>drip</workgroup>
<!--[rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>The Drone Remote Identification Protocol (DRIP), plus trust policies an d periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet acces s. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed.</t> <t>The Drone Remote Identification Protocol (DRIP), plus trust policies an d periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet acces s. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recently detached messag es were signed by the registered owner of the DRIP Entity Tag (DET) claimed.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The initial regulations (e.g., <xref target="FAA-14CFR" format="default <t>The initial regulations (e.g., <xref target="FAA-14CFR" format="default
"/>) and standards (e.g., <xref target="F3411" format="default"/>) for Unmanned "/>) and standards (e.g., <xref target="F3411" format="default"/>) for Unmanned
Aircraft (UA) Systems (UAS) Remote Identification and tracking (RID) do not addr Aircraft Systems (UAS) Remote Identification (RID) and tracking do not address
ess trust. However, this is a requirement that needs to be addressed for various trust. However, this is a requirement that needs to be addressed for various dif
different parties that have a stake in the safe operation of National Airspace ferent parties that have a stake in the safe operation of National Airspace Syst
Systems (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how RID ca ems (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how RID can be
n be made trustworthy and available in both Internet and local-only connected sc made trustworthy and available in both Internet and local-only connected scenar
enarios, especially in emergency situations.</t> ios, especially in emergency situations.</t>
<t>UAS often operate in a volatile environment. Small UA offer little capa <t>UAS often operate in a volatile environment. A small Unmanned Aircraft
city for computation and communication. UAS RID must also be accessible with ubi (UA) offers little capacity for computation and communication. UAS RID must also
quitous and inexpensive devices without modification. This limits options. Most be accessible with ubiquitous and inexpensive devices without modification. Thi
current small UAS are IoT devices even if not typically thought of as such. Thus s limits options. Most current small UAS are Internet of Things (IoT) devices ev
many IoT considerations apply here. Some DRIP work, currently strongly scoped t en if they are not typically thought of as such. Thus many IoT considerations ap
o UAS RID, is likely to be applicable to some other IoT use-cases.</t> ply here. Some DRIP work, currently strongly scoped to UAS RID, is likely to be
<t>Generally, two communication schemes for UAS RID are considered: Broadc applicable to some other IoT use cases.</t>
ast and Network. This document focuses on adding trust to Broadcast RID (Section <!-- [rfced] We have expanded the following terms. Please review and let us
3.2 of <xref target="RFC9153" format="default"/> and Section 1.2.2 of <xref tar know if any updates are needed.
get="RFC9434" format="default"/>). As defined in <xref target="F3411" format="de
fault"/> and outlined in <xref target="RFC9153" format="default"/> and <xref tar RF: Radio Frequency
get="RFC9434" format="default"/>, Broadcast RID is a one-way RF transmission of MAC: Media Access Control
MAC layer messages over Bluetooth or Wi-Fi.</t>
<t>Senders can make any claims the RID message formats allow. Observers ha Original:
ve no standardized means to assess the trustworthiness of message content, nor v As defined in [F3411] and outlined in [RFC9153] and
erify whether the messages were sent by the UA identified therein, nor confirm t [RFC9434], Broadcast RID is a one-way RF transmission of MAC layer
hat the UA identified therein is the one they are visually observing. Indeed, Ob messages over Bluetooth or Wi-Fi.
servers have no way to detect whether the messages were sent by a UA, or spoofed -->
by some other transmitter (e.g., a laptop or smartphone) anywhere in direct wir
eless broadcast range. Authentication is the primary strategy for mitigating thi <t>Generally, two communication schemes for UAS RID are considered: Broadc
s issue.</t> ast and Network. This document focuses on adding trust to Broadcast RID (<xref t
arget="RFC9153" sectionFormat="of" section="3.2"/> and <xref target="RFC9434" se
ctionFormat="of" section="1.2.2"/>). As defined in <xref target="F3411" format="
default"/> and outlined in <xref target="RFC9153" format="default"/> and <xref t
arget="RFC9434" format="default"/>, Broadcast RID is a one-way Radio Frequency (
RF) transmission of Media Access Control (MAC) layer messages over Bluetooth or
Wi-Fi.</t>
<t>Senders can make any claims the RID message formats allow. Observers ha
ve no standardized means to assess the trustworthiness of message content, nor v
erify whether the messages were sent by the UA identified therein, nor confirm t
hat the UA identified therein is the one they are visually observing. Indeed, Ob
servers have no way to detect whether the messages were sent by a UA or spoofed
by some other transmitter (e.g., a laptop or smartphone) anywhere in direct wire
less broadcast range. Authentication is the primary strategy for mitigating this
issue.</t>
<section anchor="drip-entity-tag-det-authentication-goals-for-broadcast-ri d" numbered="true" toc="default"> <section anchor="drip-entity-tag-det-authentication-goals-for-broadcast-ri d" numbered="true" toc="default">
<name>DRIP Entity Tag (DET) Authentication Goals for Broadcast RID</name > <name>DRIP Entity Tag (DET) Authentication Goals for Broadcast RID</name >
<t>ASTM <xref target="F3411" format="default"/> Authentication Messages <t>ASTM <xref target="F3411" format="default"/> Authentication Messages
(Message Type 0x2), when used with DRIP Entity Tag (DET) <xref target="RFC9374" (Message Type 0x2), when used with DET-based formats <xref target="RFC9374" form
format="default"/> based formats, enable a high level of trust that the content at="default"/>, enable a high level of trust that the content of other ASTM Mess
of other ASTM Messages was generated by their claimed registered source. These m ages was generated by their claimed registered source. These messages are design
essages are designed to provide the Observers with trustworthy and immediately a ed to provide the Observers with trustworthy and immediately actionable informat
ctionable information. <xref target="auth-state-diagrams" format="default"/> pro ion. <xref target="auth-state-diagrams" format="default"/> provides a high-level
vides a high-level overview of the various states of trustworthiness that may be overview of the various states of trustworthiness that may be used along with t
used along with these formats.</t> hese formats.</t>
<t>This authentication approach also provides some error correction (<xr ef target="fec-details" format="default"/>) as mandated by the United States (US ) Federal Aviation Administration (FAA) <xref target="FAA-14CFR" format="default "/>, which is missing from <xref target="F3411" format="default"/> over Legacy T ransports (Bluetooth 4.x).</t> <t>This authentication approach also provides some error correction (<xr ef target="fec-details" format="default"/>) as mandated by the United States (US ) Federal Aviation Administration (FAA) <xref target="FAA-14CFR" format="default "/>, which is missing from <xref target="F3411" format="default"/> over Legacy T ransports (Bluetooth 4.x).</t>
<t>These DRIP enhancements to ASTM's <xref target="F3411" format="defaul <t>These DRIP enhancements to ASTM's specification for RID and tracking
t"/> further support the important use case of Observers who may be offline at t <xref target="F3411" format="default"/> further support the important use case o
he time of observation.</t> f Observers who may be offline at the time of observation.</t>
<t>A summary of DRIP requirements <xref target="RFC9153" format="default <t><xref target="req-sum" format="default"/> summarizes the DRIP require
"/> addressed herein is provided in <xref target="req-sum" format="default"/>.</ ments <xref target="RFC9153" format="default"/> addressed herein.</t>
t> <!-- [rfced] Please review whether any of the notes in this document should be
<ul empty="true" spacing="normal"> in the <aside> element. It is defined as "a container for content that is
<li>Note: The Endorsement (used in <xref target="drip-link" format="de semantically less important or tangential to the content that surrounds
fault"/>) that proves that a DET is registered MUST come from its immediate pare it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
nt in the registration hierarchy, e.g., a DRIP Identity Management Entity (DIME) -->
<xref target="drip-registries" format="default"/>. In the definitive hierarchy,
the parent of the UA is its HHIT Domain Authority (HDA), the parent of an HDA i <t>Note: The Endorsement (used in <xref target="drip-link" format="def
s its Registered Assigning Authority (RAA), etc. It is also assumed that all DRI ault"/>) that proves that a DET is registered <bcp14>MUST</bcp14> come from its
P-aware entities use a DET as their identifier during interactions with other DR immediate parent in the registration hierarchy, e.g., a DRIP Identity Management
IP-aware entities.</li> Entity (DIME) <xref target="I-D.ietf-drip-registries" format="default"/>. In th
</ul> e definitive hierarchy, the parent of the UA is its HHIT Domain Authority (HDA),
the parent of an HDA is its Registered Assigning Authority (RAA), etc. It is al
so assumed that all DRIP-aware entities use a DET as their identifier during int
eractions with other DRIP-aware entities.</t>
</section> </section>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<section anchor="required-terminology" numbered="true" toc="default"> <section anchor="required-terminology" numbered="true" toc="default">
<name>Required Terminology</name> <name>Required Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " <t>
SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
n this document are to be interpreted as described in BCP 14 <xref target="RFC21 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
19" format="default"/> <xref target="RFC8174" format="default"/> when, and only ",
when, they appear in all capitals, as shown here.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="definitions" numbered="true" toc="default"> <section anchor="definitions" numbered="true" toc="default">
<name>Definitions</name> <name>Definitions</name>
<t>This document makes use of the terms (CAA, Observer, USS, UTM, etc.) defined in <xref target="RFC9153" format="default"/>. Other terms (such as DIME) are from <xref target="RFC9434" format="default"/>, while others (HI, DET, RAA, HDA, etc.) are from <xref target="RFC9374" format="default"/>.</t> <t>This document makes use of the terms (CAA, Observer, USS, UTM, etc.) defined in <xref target="RFC9153" format="default"/>. Other terms (such as DIME) are from <xref target="RFC9434" format="default"/>, while others (HI, DET, RAA, HDA, etc.) are from <xref target="RFC9374" format="default"/>.</t>
<t>In addition, the following terms are defined for this document:</t> <t>In addition, the following terms are defined for this document:</t>
<t>Extended Transports:</t> <dl>
<ul empty="true" spacing="normal"> <dt>Extended Transports:</dt>
<li>Use of extended advertisements (Bluetooth 5.x), service info (Wi-F <dd>Use of extended advertisements (Bluetooth 5.x), service info
i Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons with vendor speci (Wi-Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons
fic information element as specified in <xref target="F3411" format="default"/>. with the vendor-specific information element as specified in <xref
Must use ASTM Message Pack (Message Type 0xF).</li> target="F3411" format="default"/>. Must use ASTM Message Pack (Message
</ul> Type 0xF).</dd>
<t>Legacy Transports:</t> <dt>Legacy Transports:</dt>
<ul empty="true" spacing="normal"> <dd>Use of broadcast frames (Bluetooth 4.x) as specified in <xref
<li>Use of broadcast frames (Bluetooth 4.x) as specified in <xref targ target="F3411" format="default"/>.</dd>
et="F3411" format="default"/>.</li> <dt>Manifest:</dt>
</ul> <dd>An immutable list of items being transported (in this specific
<t>Manifest:</t> case over wireless communication).</dd>
<ul empty="true" spacing="normal"> </dl>
<li>an immutable list of items being transported (in this specific cas
e over wireless communication).</li>
</ul>
</section> </section>
</section> </section>
<section anchor="uas-rid-authentication-background-procedures" numbered="tru e" toc="default"> <section anchor="uas-rid-authentication-background-procedures" numbered="tru e" toc="default">
<name>UAS RID Authentication Background &amp; Procedures</name> <name>UAS RID Authentication Background and Procedures</name>
<section anchor="protocol-desc" numbered="true" toc="default"> <section anchor="protocol-desc" numbered="true" toc="default">
<name>DRIP Authentication Protocol Description</name> <name>DRIP Authentication Protocol Description</name>
<t><xref target="F3411" format="default"/> defines Authentication Messag <t><xref target="F3411" format="default"/> defines Authentication Messag
e framing only. It does not define authentication formats or methods. It explici e framing only. It does not define authentication formats or methods. It explici
tly anticipates several signature options but does not fully define those. Annex tly anticipates several signature options but does not fully define those. Annex
A1 of <xref target="F3411" format="default"/> defines a Broadcast Authenticatio A1 of <xref target="F3411" format="default"/> defines a Broadcast Authenticatio
n Verifier Service, which has a heavy reliance on Observer real-time connectivit n Verifier Service, which has a heavy reliance on Observer real-time connectivit
y to the Internet. Fortunately, <xref target="F3411" format="default"/> also all y to the Internet. Fortunately, <xref target="F3411" format="default"/> also all
ows third party standard Authentication Types using Type 5 Specific Authenticati ows third-party standard Authentication Types using the Type 5 Specific Authenti
on Method (SAM), several of which DRIP defines herein.</t> cation Method (SAM), several of which DRIP defines herein.</t>
<t>The standardization of specific formats to support the DRIP requireme <!-- [rfced] In most places, the SAM type is referred to as 0x5. Should "Type 5
nts in UAS RID for trustworthy communications over Broadcast RID is an important " be "Type 0x5" for consistency?
part of the chain of trust for a UAS ID. Per Section 5 of <xref target="RFC9434
" format="default"/>, Authentication formats are needed to relay information for Original:
Observers to determine trust. No existing formats (defined in <xref target="F34 Fortunately, [F3411] also allows third party standard
11" format="default"/> or other organizations leveraging this feature) provide t Authentication Types using Type 5 Specific Authentication Method
he functionality to satisfy this goal resulting in the work reflected in this do (SAM), several of which DRIP defines herein.
cument.</t> -->
<t>The standardization of specific formats to support the DRIP requireme
nts in UAS RID for trustworthy communications over Broadcast RID is an important
part of the chain of trust for a UAS ID. Per <xref target="RFC9434" sectionForm
at="of" section="5"/>, Authentication formats are needed to relay information fo
r Observers to determine trust. No existing formats (defined in <xref target="F3
411" format="default"/> or other organizations leveraging this feature) provide
functionality to satisfy this goal, resulting in the work reflected in this doc
ument.</t>
<section anchor="auth-dns" numbered="true" toc="default"> <section anchor="auth-dns" numbered="true" toc="default">
<name>Usage of DNS</name> <name>Usage of DNS</name>
<t>Like most aviation matters, the overall objectives here are securit <t>Like most aviation matters, the overall objectives here are securit
y and ultimately safety oriented. Since DRIP depends on DNS for some of its func y and ultimately safety oriented. Since DRIP depends on DNS for some of its func
tions, DRIP usage of DNS needs to be protected as per best security practices. M tions, DRIP usage of DNS needs to be protected per best security practices. Many
any participating nodes will have limited local processing power and/or poor, lo participating nodes will have limited local processing power and/or poor, low-b
w bandwidth QoS paths. Appropriate and feasible security techniques will be high andwidth QoS paths. Appropriate and feasible security techniques will be highly
ly UAS and Observer situation dependent. Therefore specification of particular D dependent on the UAS and Observer situation. Therefore, specification of particu
NS security options, transports, etc. is outside the scope of this document (see lar DNS security options, transports, etc. is outside the scope of this document
also <xref target="dns-security" format="default"/>).</t> (see also <xref target="dns-security" format="default"/>).</t>
<t>In DRIP Observers MUST validate all signatures received. This requi <t>In DRIP, Observers <bcp14>MUST</bcp14> validate all signatures rece
res the Host Identity (HI) corresponding to a DET <xref target="RFC9374" format= ived. This requires that the Host Identity (HI) correspond to a DET <xref target
"default"/>. HI's MAY be retrieved from a local cache, if present. The local cac ="RFC9374" format="default"/>. HI's <bcp14>MAY</bcp14> be retrieved from a local
he is pre-configured with well knowns HIs (such as those of CAA DIMEs) and furth cache, if present. The local cache is pre-configured with well-known HIs (such
er populated by received Broadcast Endorsements (BEs) (<xref target="dime-attest as those of CAA DIMEs) and is further populated by received Broadcast Endorsemen
ation" format="default"/>) and DNS lookups (when available).</t> ts (BEs) (<xref target="dime-attestation" format="default"/>) and DNS lookups (w
<t>The Observer MUST perform a DNS query, when connectivity allows, to hen available).</t>
obtain an HI not previously known. If a query can not be performed, the message <t>The Observer <bcp14>MUST</bcp14> perform a DNS query, when connecti
SHOULD be cached by the Observer to be validated once the HI is obtained.</t> vity allows, to obtain a previously unknown HI. If a query cannot be performed,
<t>A more comprehensive specification of DRIP's use of DNS is out of s the message <bcp14>SHOULD</bcp14> be cached by the Observer to be validated once
cope for this document and can be found in <xref target="drip-registries" format the HI is obtained.</t>
="default"/>.</t> <t>A more comprehensive specification of DRIP's use of DNS is out of s
cope for this document and can be found in <xref target="I-D.ietf-drip-registrie
s" format="default"/>.</t>
</section> </section>
<section anchor="rid-trust" numbered="true" toc="default"> <section anchor="rid-trust" numbered="true" toc="default">
<name>Providing UAS RID Trust</name> <name>Providing UAS RID Trust</name>
<t>For DRIP, two actions together provide a mechanism for an Observer to trust in UAS RID using Authentication Messages.</t> <t>For DRIP, two actions together provide a mechanism for an Observer to trust in UAS RID using Authentication Messages.</t>
<t>First is the transmission of an entire trust chain via Broadcast En dorsements (<xref target="dime-attestation" format="default"/>). This provides a hierarchy of DIMEs down to and including an individual UA's registration of a c laimed DET and corresponding HI (public key). This alone cannot be trusted as ha ving any relevance to the observed UA because replay attacks are trivial.</t> <t>First is the transmission of an entire trust chain via Broadcast En dorsements (<xref target="dime-attestation" format="default"/>). This provides a hierarchy of DIMEs down to and including an individual UA's registration of a c laimed DET and corresponding HI (public key). This alone cannot be trusted as ha ving any relevance to the observed UA because replay attacks are trivial.</t>
<t>After an Observer has gathered such a complete key trust chain (fro <t>After an Observer has gathered such a complete key trust chain (fro
m pre-configured cache entries, Broadcast Endorsements received over the air and m pre-configured cache entries, Broadcast Endorsements received over the air and
/or DNS lookups) and verified all of its links, that device can trust that claim /or DNS lookups) and verified all of its links, that device can trust that the c
ed DET and corresponding public key are properly registered, but the UA has not laimed DET and corresponding public key are properly registered, but the UA has
yet been proven to possess the corresponding private key.</t> not yet been proven to possess the corresponding private key.</t>
<t>It is necessary for the UA to prove possession by dynamically signi <t>It is necessary for the UA to prove possession by dynamically signi
ng data that is unique and unpredictable but easily verified by the Observer (<x ng data that is unique and unpredictable but easily verified by the Observer (<x
ref target="ua-attestation" format="default"/>). Verification of this signed dat ref target="ua-attestation" format="default"/>). Verification of this signed dat
a MUST be performed by the Observer as part of the received UAS RID information a <bcp14>MUST</bcp14> be performed by the Observer as part of the received UAS R
trust assessment (<xref target="trust-assessment" format="default"/>).</t> ID information trust assessment (<xref target="trust-assessment" format="default
"/>).</t>
<section anchor="dime-attestation" numbered="true" toc="default"> <section anchor="dime-attestation" numbered="true" toc="default">
<name>DIME Endorsements of Subordinate DETs</name> <name>DIME Endorsements of Subordinate DETs</name>
<t>Observers receive DRIP Link Authentication Messages (<xref target <t>Observers receive DRIP Link Authentication Messages (<xref target
="drip-link" format="default"/>) containing Broadcast Endorsements by DIMEs of c ="drip-link" format="default"/>) containing Broadcast Endorsements by DIMEs of c
hild DET registrations. A series of these Endorsements confirms a path through t hild DET registrations. A series of these Endorsements confirms a path through t
he hierarchy, defined in <xref target="drip-registries" format="default"/>, from he hierarchy, defined in <xref target="I-D.ietf-drip-registries" format="default
the DET Prefix Owner all the way to an individual UA DET registration.</t> "/>, from the DET Prefix Owner all the way to an individual UA DET registration.
<ul empty="true" spacing="normal"> </t>
<li>Note: For the remainder of this document <tt>Broadcast Endorse <t>Note: For the remainder of this document, <tt>Broadcast
ment: Parent, Child</tt> will be abbreviated to <tt>BE: Parent, Child</tt>. For Endorsement: Parent, Child</tt> will be abbreviated as <tt>BE:
example <tt>Broadcast Endorsement: RAA, HDA</tt> will be abbreviated to <tt>BE: Parent, Child</tt>. For example, <tt>Broadcast Endorsement: RAA, HDA</
RAA, HDA</tt>.</li> tt> will be abbreviated as <tt>BE: RAA, HDA</tt>.</t>
</ul>
</section> </section>
<section anchor="ua-attestation" numbered="true" toc="default"> <section anchor="ua-attestation" numbered="true" toc="default">
<name>UA Signed Evidence</name> <name>UA Signed Evidence</name>
<t>To prove possession of the private key associated to the DET, the <!-- [rfced] Please clarify; how does "that is signed over" relate to the
UA MUST send data that is unique and unpredictable but easily validated by the earlier part of the sentence?
Observer, that is signed over. The data can be an ASTM Message that fulfills the
requirements to be unpredictable but easily validated. An Observer receives thi Original:
s UA-signed Evidence from DRIP-based Authentication Messages (<xref target="drip To prove possession of the private key associated to the DET, the UA
-wrapper" format="default"/> or <xref target="drip-manifest" format="default"/>) MUST send data that is unique and unpredictable but easily validated
.</t> by the Observer, that is signed over.
<t>Whether the content is true is a separate question which DRIP can -->
not address, but validation performed using observable and/or out of band data (
<xref target="reqs" format="default"/>) are possible and encouraged.</t> <t>To prove possession of the private key associated with the DET, t
he UA <bcp14>MUST</bcp14> send data that is unique and unpredictable but easily
validated by the Observer, that is signed over. The data can be an ASTM Message
that fulfills the requirements to be unpredictable but easily validated. An Obse
rver receives this UA signed Evidence from DRIP-based Authentication Messages (S
ections <xref target="drip-wrapper" format="counter"/> or <xref target="drip-man
ifest" format="counter"/>).</t>
<t>Whether the content is true is a separate question that DRIP cann
ot address, but validation performed using observable and/or out-of-band data (<
xref target="reqs" format="default"/>) is possible and encouraged.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="auth-message" numbered="true" toc="default"> <section anchor="auth-message" numbered="true" toc="default">
<name>ASTM Authentication Message Framing</name> <name>ASTM Authentication Message Framing</name>
<t>The Authentication Message (Message Type 0x2) is unique in the ASTM < <t>The Authentication Message (Message Type 0x2) is unique in the ASTM
xref target="F3411" format="default"/> Broadcast standard as it is the only mess <xref target="F3411" format="default"/> Broadcast standard, as it is the only me
age that can be larger than the Legacy Transport size. To address this limitatio ssage that can be larger than the Legacy Transport size. To address this limitat
n around transport size, it is defined as a set of "pages", each of which fits i ion around transport size, it is defined as a set of "pages", each of which fits
nto a single Legacy Transport frame. For Extended Transports, pages are still us into a single Legacy Transport frame. For Extended Transports, pages are still
ed but all are in a single frame.</t> used but they are all in a single frame.</t>
<ul empty="true" spacing="normal"> <t>Informational Note: Message Pack (Message Type 0xF) is also
<li>Informational Note: Message Pack (Message Type 0xF) is also larger larger than the Legacy Transport size but is limited for use only on
than the Legacy Transport size but is limited for use only on Extended Transpor Extended Transports where is can be supported.</t>
ts where is can be supported.</li> <t>The following subsections are a brief overview of the Authentication
</ul> Message format defined in <xref target="F3411" format="default"/> for better con
<t>The following sub-sections are a brief overview of the Authentication text on how DRIP Authentication fills and uses various fields already defined by
Message format defined in <xref target="F3411" format="default"/> for better co ASTM <xref target="F3411" format="default"/>.</t>
ntext on how DRIP Authentication fills and uses various fields already defined b
y ASTM <xref target="F3411" format="default"/>.</t>
<section anchor="auth-page" numbered="true" toc="default"> <section anchor="auth-page" numbered="true" toc="default">
<name>Authentication Page</name> <name>Authentication Page</name>
<t>This document leverages Authentication Type 0x5, Specific Authentic ation Method (SAM), as the principal authentication container, defining a set of SAM Types in <xref target="drip-authentication-formats" format="default"/>. Aut hentication Type is encoded in every Authentication Page in the <tt>Page Header< /tt>. The SAM Type is defined as a field in the <tt>Authentication Payload</tt> (see <xref target="sam-data" format="default"/>).</t> <t>This document leverages Authentication Type 0x5 (Specific Authentic ation Method (SAM)) as the principal authentication container, defining a set of SAM Types in <xref target="drip-authentication-formats" format="default"/>. Aut hentication Type is encoded in every Authentication Page in the <tt>Page Header< /tt>. The SAM Type is defined as a field in the <tt>Authentication Payload</tt> (see <xref target="sam-data" format="default"/>).</t>
<figure anchor="astm-auth-page"> <figure anchor="astm-auth-page">
<name>Standard ASTM Authentication Message Page</name> <name>Standard ASTM Authentication Message Page</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 Payload | | Authentication Payload |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Page Header: (1 octet)</t> <dl><dt>Page Header:</dt><dd><t>(1 octet)</t>
<ul empty="true" spacing="normal"> <t>Authentication Type (4 bits) and Page Number (4 bits)</t></dd>
<li>Authentication Type (4 bits) and Page Number (4 bits)</li>
</ul> <dt>Authentication Payload:</dt><dd><t>(23 octets per page)</t>
<t>Authentication Payload: (23 octets per page)</t> <t>Authentication Payload, including headers. Null padded. See
<ul empty="true" spacing="normal"> <xref target="auth-payload" format="default"/>.</t></dd>
<li>Authentication Payload, including headers. Null padded. See <xre </dl>
f target="auth-payload" format="default"/>.</li> <t>The Authentication Message is structured as a set of pages per <xre
</ul> f target="astm-auth-page" format="default"/>. There is a technical maximum of 16
<t>The Authentication Message is structured as a set of pages per <xre pages (indexed 0 to 15) that can be sent for a single Authentication Message, w
f target="astm-auth-page" format="default"/>. There is a technical maximum of 16 ith each page carrying a maximum 23-octet <tt>Authentication Payload</tt>. See <
pages (indexed 0 to 15) that can be sent for a single Authentication Message, w xref target="drip-restrictions" format="default"/> for more details. Over Legacy
ith each page carrying a maximum 23 octet <tt>Authentication Payload</tt>. See < Transports, these messages are "fragmented", with each page sent in a separate
xref target="drip-restrictions" format="default"/> for more details. Over Legacy Legacy Transport frame.</t>
Transports, these messages are "fragmented", with each page sent in a separate
Legacy Transport frame.</t>
<t>Either as a single Authentication Message or a set of fragmented Au thentication Message Pages, the structure is further wrapped by outer ASTM frami ng and the specific link framing.</t> <t>Either as a single Authentication Message or a set of fragmented Au thentication Message Pages, the structure is further wrapped by outer ASTM frami ng and the specific link framing.</t>
</section> </section>
<section anchor="auth-payload" numbered="true" toc="default"> <section anchor="auth-payload" numbered="true" toc="default">
<name>Authentication Payload Field</name> <name>Authentication Payload Field</name>
<t><xref target="astm-auth" format="default"/> is the source data view of the data fields found in the Authentication Message as defined by <xref targ et="F3411" format="default"/>. This data is placed into <xref target="astm-auth- page" format="default"/>'s <tt>Authentication Payload</tt>, spanning multiple <t t>Authentication Pages</tt>.</t> <t><xref target="astm-auth" format="default"/> is the source data view of the data fields found in the Authentication Message as defined by <xref targ et="F3411" format="default"/>. This data is placed into the <tt>Authentication P ayload</tt> shown in <xref target="astm-auth-page" format="default"/>, which spa ns multiple <tt>Authentication Pages</tt>.</t>
<figure anchor="astm-auth"> <figure anchor="astm-auth">
<name>ASTM Authentication Message Fields</name> <name>ASTM Authentication Message Fields</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 |
| +---------------+---------------+ | +---------------+---------------+
| | | | | |
+---------------+---------------+ | +---------------+---------------+ |
skipping to change at line 200 skipping to change at line 267
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ADL | | | ADL | |
+---------------+ | +---------------+ |
. . . .
. Additional Data . . Additional Data .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Authentication Headers: (6 octets)</t> <dl><dt>Authentication Headers:</dt><dd><t>(6 octets)</t>
<ul empty="true" spacing="normal"> <t>As defined in <xref target="F3411" format="default"/>.</t></dd>
<li>As defined in <xref target="F3411" format="default"/>.</li> <dt>Authentication Data / Signature:</dt><dd><t>(0 to 255 octets)</t>
</ul> <t>Opaque authentication data. The length of this payload is
<t>Authentication Data / Signature: (0 to 255 octets)</t> known through a field in the <tt>Authentication Headers</tt>
<ul empty="true" spacing="normal"> (defined in <xref target="F3411" format="default"/>).</t></dd>
<li>Opaque authentication data. The length of this payload is known <dt>Additional Data Length (ADL):</dt><dd><t>(1 octet - unsigned)</t>
through a field in the <tt>Authentication Headers</tt> (defined in <xref target= <t>Length in octets of <tt>Additional Data</tt>. The
"F3411" format="default"/>).</li> value of <tt>ADL</tt> is calculated as the minimum of <tt>361 -
</ul> Authentication Data / Signature Length</tt> and <tt>255</tt>. Only
<t>Additional Data Length (ADL): (1 octet - unsigned)</t> present with <tt>Additional Data</tt>.</t></dd>
<ul empty="true" spacing="normal"> <dt>Additional Data:</dt><dd><t>(<tt>ADL</tt> octets)</t>
<li>Length in octets of <tt>Additional Data</tt>. The value of <tt>A <t>Data that follows the <tt>Authentication Data /
DL</tt> is calculated as the minimum of <tt>361 - Authentication Data / Signatur Signature</tt> but is not considered part of the <tt>Authentication
e Length</tt> and <tt>255</tt>. Only present with <tt>Additional Data</tt>.</li> Data</tt>, and thus is not covered by a signature. For DRIP, this fiel
</ul> d
<t>Additional Data: (<tt>ADL</tt> octets)</t> is used to carry Forward Error Correction (FEC) generated by
<ul empty="true" spacing="normal"> transmitters and parsed by receivers as defined in <xref
<li>Data that follows the <tt>Authentication Data / Signature</tt> b target="fec-details" format="default"/>.</t></dd></dl>
ut is not considered part of the <tt>Authentication Data</tt> thus is not covere
d by a signature. For DRIP, this field is used to carry Forward Error Correction
(FEC) generated by transmitters and parsed by receivers as defined in <xref tar
get="fec-details" format="default"/>.</li>
</ul>
</section> </section>
<section anchor="specific-authentication-method-sam" numbered="true" toc ="default"> <section anchor="specific-authentication-method-sam" numbered="true" toc ="default">
<name>Specific Authentication Method (SAM)</name> <name>Specific Authentication Method (SAM)</name>
<section anchor="sam-data" numbered="true" toc="default"> <section anchor="sam-data" numbered="true" toc="default">
<name>SAM Data Format</name> <name>SAM Data Format</name>
<t><xref target="sam-frame" format="default"/> is the general format to hold authentication data when using SAM and is placed inside the <tt>Authent ication Data/Signature</tt> field in <xref target="astm-auth" format="default"/> .</t> <t><xref target="sam-frame" format="default"/> is the general format to hold authentication data when using SAM and is placed inside the <tt>Authent ication Data / Signature</tt> field in <xref target="astm-auth" format="default" />.</t>
<figure anchor="sam-frame"> <figure anchor="sam-frame">
<name>SAM Data Format</name> <name>SAM Data Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>SAM Type: (1 octet)</t>
<ul empty="true" spacing="normal"> <dl><dt>SAM Type:</dt><dd><t>(1 octet)</t>
<li>The following SAM Types are allocated to DRIP:</li> <t>The following SAM Types are allocated to DRIP:</t>
</ul>
<table align="center"> <table align="center">
<name>DRIP SAM Types</name> <name>DRIP SAM Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">SAM Type</th> <th align="left">SAM Type</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 268 skipping to change at line 336
<tr> <tr>
<td align="left">0x03</td> <td align="left">0x03</td>
<td align="left">DRIP Manifest (<xref target="drip-manifest" f ormat="default"/>)</td> <td align="left">DRIP Manifest (<xref target="drip-manifest" f ormat="default"/>)</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x04</td> <td align="left">0x04</td>
<td align="left">DRIP Frame (<xref target="drip-frame" format= "default"/>)</td> <td align="left">DRIP Frame (<xref target="drip-frame" format= "default"/>)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true" spacing="normal"> </dd></dl>
<li>Note: ASTM International is the owner of these code points as <t>Note: ASTM International is the owner of these code points as t
they are defined in <xref target="F3411" format="default"/>. In accordance with hey are defined in <xref target="F3411" format="default"/>. In accordance with A
Annex 5 of the ASTM's <xref target="F3411" format="default"/>, the International nnex 5 of <xref target="F3411" format="default"/>, the International Civil Aviat
Civil Aviation Organization (ICAO) has been selected by ASTM as the registrar t ion Organization (ICAO) has been selected by ASTM as the registrar to manage all
o manage allocations of these code points. The list of which can be found at <xr ocations of these code points. The list is available at <xref target="ASTM-Remot
ef target="ASTM-Remote-ID" format="default"/>.</li> e-ID" format="default"/>.</t>
</ul>
<t>SAM Authentication Data: (0 to 200 octets)</t> <dl><dt>SAM Authentication Data:</dt><dd><t>(0 to 200 octets)</t>
<ul empty="true" spacing="normal"> <t>Contains opaque authentication data formatted as defined by the p
<li>Contains opaque authentication data formatted as defined by th receding SAM Type.</t></dd></dl>
e preceding SAM Type.</li>
</ul>
</section> </section>
</section> </section>
<section anchor="drip-restrictions" numbered="true" toc="default"> <section anchor="drip-restrictions" numbered="true" toc="default">
<name>ASTM Broadcast RID Constraints</name> <name>ASTM Broadcast RID Constraints</name>
<section anchor="wireless-frame-constraints" numbered="true" toc="defa ult"> <section anchor="wireless-frame-constraints" numbered="true" toc="defa ult">
<name>Wireless Frame Constraints</name> <name>Wireless Frame Constraints</name>
<t>A UA has the option of broadcasting using Bluetooth (4.x and 5.x)
, Wi-Fi NAN, or IEEE 802.11 Beacon, see <xref target="reqs" format="default"/>. <t>A UA has the option to broadcast using Bluetooth (4.x and 5.x), W
With Bluetooth, FAA and other Civil Aviation Authorities (CAA) mandate transmitt i-Fi NAN, or IEEE 802.11 Beacon; see <xref target="reqs" format="default"/>. Wit
ing simultaneously over both 4.x and 5.x. The same application layer information h Bluetooth, FAA and other Civil Aviation Authorities (CAA) mandate transmitting
defined in <xref target="F3411" format="default"/> MUST be transmitted over all simultaneously over both 4.x and 5.x. The same application-layer information de
the physical layer interfaces performing the function of RID. This is because O fined in <xref target="F3411" format="default"/> <bcp14>MUST</bcp14> be transmit
bserver transports may be limited. If an Observer can support multiple transport ted over all the physical-layer interfaces performing RID, because Observer tran
s it should be assumed to use the latest data regardless of the transport receiv sports may be limited.
ed over.</t> <!--[rfced] For clarity, may 'transport received over' be rephrased?
<t>Bluetooth 4.x presents a payload size challenge in that it can on Does it refer to the transport over which the data was received?
ly transmit 25 octets of payload per frame while other transports can support la
rger payloads per frame. However, the <xref target="F3411" format="default"/> me Original:
ssaging framing dictated by Bluetooth 4.x constraints is inherited by <xref targ If an Observer can
et="F3411" format="default"/> over other media.</t> support multiple transports it should be assumed to use the latest
<t>It should be noted that Extended Transports by definition have Er data regardless of the transport received over.
ror Correction built in, unlike Legacy Transports. For Authentication Messages t
his means that over Legacy Transport pages could be not received by Observers re Perhaps:
sulting in incomplete messages during operation, although the use of DRIP FEC (< If an Observer can
xref target="fec-details" format="default"/>) reduces the likelihood of this. Au support multiple transports it should be assumed to use the latest
thentication Messages sent using Extended Transports do not suffer this issue as data regardless of the transport over which that data was received.
the full message (all pages) are sent using a single Message Pack. Furthermore -->
the use of one-way RF broadcasts prohibits the use of any congestion control or If an Observer can support multiple transports, it should be assumed to use the
loss recovery schemes that require ACKs or NACKs.</t> latest data regardless of the transport received over.</t>
<!-- [rfced] What does "[F3411] over other media" refer to - RID and tracking?
Please review and clarify, if possible.
Original:
However, the [F3411] messaging
framing dictated by Bluetooth 4.x constraints is inherited by [F3411]
over other media.
-->
<t>Bluetooth 4.x presents a payload-size challenge in that it can on
ly transmit 25 octets of payload per frame, while other transports can support l
arger payloads per frame. However, the <xref target="F3411" format="default"/> m
essage framing dictated by Bluetooth 4.x constraints is inherited by <xref targe
t="F3411" format="default"/> over other media.</t>
<!-- [rfced] We are having trouble parsing this text. Please review. Also, sho
uld Error Correction be Forward Error Correction?
Original:
It should be noted that Extended Transports by definition have Error
Correction built in, unlike Legacy Transports. For Authentication
Messages this means that over Legacy Transport pages could be not
received by Observers resulting in incomplete messages during
operation, although the use of DRIP FEC (Section 5) reduces the
likelihood of this.
Perhaps:
It should be noted that Extended Transports by definition have Error
Correction built in, unlike Legacy Transports. For Authentication
Messages this means that over Legacy Transport, pages may not be
received by Observers. This results in incomplete messages during
operation; however, the use of DRIP FEC (Section 5) reduces its
likelihood.
-->
<t>It should be noted that Extended Transports by definition have Er
ror Correction built in, unlike Legacy Transports. For Authentication Messages,
this means that over Legacy Transport pages may not received by Observers result
ing in incomplete messages during operation, although the use of DRIP FEC (<xref
target="fec-details" format="default"/>) reduces its likelihood. Authentication
Messages sent using Extended Transports do not suffer this issue, as the full m
essage (all pages) is sent using a single Message Pack. Furthermore, the use of
one-way RF broadcasts prohibits the use of any congestion-control or loss-recove
ry schemes that require ACKs or NACKs.</t>
</section> </section>
<section anchor="paged-authentication-message-constraints" numbered="t rue" toc="default"> <section anchor="paged-authentication-message-constraints" numbered="t rue" toc="default">
<name>Paged Authentication Message Constraints</name> <name>Paged Authentication Message Constraints</name>
<t>To keep consistent formatting across the different transports (Le <t>To keep consistent formatting across the different transports (Le
gacy and Extended) and their independent restrictions, the authentication data b gacy and Extended) and their independent restrictions, the authentication data b
eing sent is REQUIRED to fit within the page limit that the most constrained exi eing sent is <bcp14>REQUIRED</bcp14> to fit within the page limit that the most
sting transport can support. Under Broadcast RID, the Extended Transport that ca constrained existing transport can support. Under Broadcast RID, the Extended Tr
n hold the least amount of authentication data is Bluetooth 5.x at 9 pages.</t> ansport that can hold the least amount of authentication data is Bluetooth 5.x a
<t>As such DRIP transmitters are REQUIRED to adhere to the following t 9 pages.</t>
when using the Authentication Message:</t> <t>As such, DRIP transmitters are <bcp14>REQUIRED</bcp14> to adhere
<ol spacing="normal" type="1"><li> to the following when using the Authentication Message:</t>
<tt>Authentication Data / Signature</tt> data MUST fit in the fi <ol spacing="normal" type="1">
rst 9 pages (Page Numbers 0 through 8).</li> <li><tt>Authentication Data / Signature</tt> data
<li>The <tt>Length</tt> field in the <tt>Authentication Headers</t <bcp14>MUST</bcp14> fit in the first 9 pages (Page Numbers 0
t> (which encodes the length in octets of <tt>Authentication Data / Signature</t through 8).</li>
t> only) MUST NOT exceed the value of 201. This includes the SAM Type but exclud <li>The <tt>Length</tt> field in the <tt>Authentication
es <tt>Additional Data</tt>.</li> Headers</tt> (which encodes the length in octets of
<tt>Authentication Data / Signature</tt> only) <bcp14>MUST
NOT</bcp14> exceed the value of 201. This includes the SAM Type
but excludes <tt>Additional Data</tt>.</li>
</ol> </ol>
</section> </section>
<section anchor="astm-timestamps" numbered="true" toc="default"> <section anchor="astm-timestamps" numbered="true" toc="default">
<name>Timestamps</name> <name>Timestamps</name>
<t>In ASTM <xref target="F3411" format="default"/> timestamps are a <t>In ASTM <xref target="F3411" format="default"/>, timestamps are a
Unix-style timestamp with an epoch of <tt>2019-01-01 00:00:00 UTC</tt>. For DRIP Unix-style timestamp with an epoch of <tt>2019-01-01 00:00:00 UTC</tt>. For DRI
this format is adopted for Authentication to keep a common time format in Broad P, this format is adopted for Authentication to keep a common time format in Bro
cast payloads.</t> adcast payloads.</t>
<t>Under DRIP there are two timestamps defined <tt>Valid Not Before <t>Under DRIP, there are two timestamps defined: <tt>Valid Not Befor
(VNB)</tt> and <tt>Valid Not After (VNA)</tt>.</t> e (VNB)</tt> and <tt>Valid Not After (VNA)</tt>.</t>
<t>Valid Not Before (VNB) Timestamp: (4 octets)</t> <dl><dt>Valid Not Before (VNB) Timestamp:</dt><dd><t>(4 octets)</t>
<ul empty="true" spacing="normal"> <t>Timestamp denoting the recommended time at which to start trustin
<li>Timestamp denoting recommended time to start trusting data in. g data. <bcp14>MUST</bcp14> follow the format defined in <xref target="F3411" fo
MUST follow the format defined in <xref target="F3411" format="default"/> as de rmat="default"/> as described above. <bcp14>MUST</bcp14> be set no earlier than
scribed above. MUST be set no earlier than the time the signature (across a give the time the signature (across a given structure) is generated.</t></dd>
n structure) is generated.</li>
</ul> <dt>Valid Not After (VNA) Timestamp:</dt><dd><t>(4 octets)</t>
<t>Valid Not After (VNA) Timestamp: (4 octets)</t> <!-- [rfced] Is this about a reasonable offset? If so, please consider
<ul empty="true" spacing="normal"> whether updating "a reasonable time" to "a reasonable offset" would be
<li>Timestamp denoting recommended time to stop trusting data. MUS more clear.
T follow the format defined in <xref target="F3411" format="default"/> as descri
bed above. Has an additional offset to push a short time into the future (relati Original:
ve to <tt>VNB</tt>) to avoid replay attacks. The exact offset is not defined in A reasonable time would
this document. Best practice identifying an acceptable offset should be used tak be to set VNA 2 minutes after VNB.
ing into consideration the UA environment, and propagation characteristics of th
e messages being sent, and clock differences between the UA and Observers. A rea Perhaps:
sonable time would be to set <tt>VNA</tt> 2 minutes after <tt>VNB</tt>.</li> A reasonable offset would
</ul> be to set VNA to 2 minutes after VNB.
-->
<t>Timestamp denoting the recommended time at which to stop trusting
data. <bcp14>MUST</bcp14> follow the format defined in <xref target="F3411" for
mat="default"/> as described above. Has an additional offset to push a short tim
e into the future (relative to <tt>VNB</tt>) to avoid replay attacks. The exact
offset is not defined in this document. Best practice for identifying an accepta
ble offset should be used and should take into consideration the UA environment,
propagation characteristics of the messages being sent, and clock differences b
etween the UA and Observers. A reasonable time would be to set <tt>VNA</tt> 2 mi
nutes after <tt>VNB</tt>.</t></dd></dl>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="drip-authentication-formats" numbered="true" toc="default"> <section anchor="drip-authentication-formats" numbered="true" toc="default">
<name>DRIP Authentication Formats</name> <name>DRIP Authentication Formats</name>
<t>All formats defined in this section are the content of the <tt>Authenti <t>All formats defined in this section are contained in the <tt>Authentica
cation Data / Signature</tt> field in <xref target="astm-auth" format="default"/ tion Data / Signature</tt> field in <xref target="astm-auth" format="default"/>
> and use the Specific Authentication Method (SAM, Authentication Type 0x5). The and use the Specific Authentication Method (SAM, Authentication Type 0x5). The f
first octet of the <tt>Authentication Data / Signature</tt> of <xref target="as irst octet of the <tt>Authentication Data / Signature</tt> of <xref target="astm
tm-auth" format="default"/> is used to multiplex among these various formats.</t -auth" format="default"/> is used to multiplex among these various formats.</t>
> <!-- [rfced] For readability, may we update the text as follows?
<t>When sending data over a medium that does not have underlying FEC, for
example Legacy Transports, then <xref target="fec-details" format="default"/> MU Original:
ST be used.</t> When sending data over a medium that does not have underlying FEC,
<t>Examples of Link, Wrapper and Manifest are shown as part of an operatio for example Legacy Transports, then Section 5 MUST be used.
nal schedule in <xref target="raw-example" format="default"/>.</t>
Perhaps:
When sending data over a medium that does not have underlying FEC,
for example Legacy Transports, then FEC (Section 5) MUST be used.
-->
<t>When sending data over a medium that does not have underlying FEC, for
example Legacy Transports, then <xref target="fec-details" format="default"/> <b
cp14>MUST</bcp14> be used.</t>
<t>Examples of Link, Wrapper, and Manifest are shown as part of an operati
onal schedule in <xref target="raw-example" format="default"/>.</t>
<section anchor="bas" numbered="true" toc="default"> <section anchor="bas" numbered="true" toc="default">
<name>UA Signed Evidence Structure</name> <name>UA Signed Evidence Structure</name>
<t>The <tt>UA Signed Evidence Structure</tt> (<xref target="drip-data" f ormat="default"/>) is used by the UA during flight to sign over information elem ents using the private key associated with the current UA DET. It is encapsulate d by the <tt>SAM Authentication Data</tt> field of <xref target="sam-frame" form at="default"/>.</t> <t>The <tt>UA Signed Evidence Structure</tt> (<xref target="drip-data" f ormat="default"/>) is used by the UA during flight to sign over information elem ents using the private key associated with the current UA DET. It is encapsulate d by the <tt>SAM Authentication Data</tt> field of <xref target="sam-frame" form at="default"/>.</t>
<t>This structure is used by the DRIP Wrapper (<xref target="drip-wrappe r" format="default"/>), Manifest <xref target="drip-manifest" format="default"/> , and Frame (<xref target="drip-frame" format="default"/>). DRIP Link (<xref tar get="drip-link" format="default"/>) MUST NOT use it as it will not fit in the AS TM Authentication Message with its intended content (i.e., a Broadcast Endorseme nt).</t> <t>This structure is used by the DRIP Wrapper (<xref target="drip-wrappe r" format="default"/>), Manifest <xref target="drip-manifest" format="default"/> ), and Frame (<xref target="drip-frame" format="default"/>). DRIP Link (<xref ta rget="drip-link" format="default"/>) <bcp14>MUST NOT</bcp14> use it, as it will not fit in the ASTM Authentication Message with its intended content (i.e., a Br oadcast Endorsement).</t>
<figure anchor="drip-data"> <figure anchor="drip-data">
<name>Endorsement Structure for UA Signed Evidence</name> <name>Endorsement Structure for UA Signed Evidence</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 359 skipping to change at line 493
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Valid Not Before (VNB) Timestamp by UA: (4 octets)</t> <dl><dt>Valid Not Before (VNB) Timestamp by UA:</dt><dd><t>(4 octets)</t>
<ul empty="true" spacing="normal"> <t>See <xref target="astm-timestamps" format="default"/>. Set by the UA.
<li>See <xref target="astm-timestamps" format="default"/>. Set by the </t></dd>
UA.</li>
</ul> <dt>Valid Not After (VNA) Timestamp by UA:</dt><dd><t>(4 octets)</t>
<t>Valid Not After (VNA) Timestamp by UA: (4 octets)</t> <t>See <xref target="astm-timestamps" format="default"/>. Set by the UA.<
<ul empty="true" spacing="normal"> /t></dd>
<li>See <xref target="astm-timestamps" format="default"/>. Set by the <dt>Evidence:</dt><dd><t>(0 to 112 octets)</t>
UA.</li> <t>The <tt>evidence</tt> section <bcp14>MUST</bcp14> filled in with data
</ul> in the form of an opaque object specified in the DRIP Wrapper (<xref target="dr
<t>Evidence: (0 to 112 octets)</t> ip-wrapper" format="default"/>), Manifest (<xref target="drip-manifest" format="
<ul empty="true" spacing="normal"> default"/>), or Frame (<xref target="drip-frame" format="default"/>).</t></dd>
<li>The <tt>evidence</tt> section MUST be filled in with data in the f
orm of an opaque object specified in the DRIP Wrapper (<xref target="drip-wrappe <dt>UA DRIP Entity Tag:</dt><dd><t>(16 octets)</t>
r" format="default"/>), Manifest (<xref target="drip-manifest" format="default"/ <!-- [rfced] In the following, is the current DET or UA assumed to be a Specific
>), or Frame (<xref target="drip-frame" format="default"/>).</li> Session ID?
</ul>
<t>UA DRIP Entity Tag: (16 octets)</t> Original:
<ul empty="true" spacing="normal"> UA DRIP Entity Tag: (16 octets)
<li>This is the current DET <xref target="RFC9374" format="default"/>
being used by the UA assumed to be a Specific Session ID (a type of UAS ID).</li This is the current DET [RFC9374] being used by the UA assumed to
> be a Specific Session ID (a type of UAS ID).
</ul>
<t>UA Signature: (64 octets)</t> Perhaps A (current DET is assumed to be a Specific Session ID):
<ul empty="true" spacing="normal"> UA DRIP Entity Tag: (16 octets)
<li>Signature over concatenation of preceding fields (<tt>VNB</tt>, <t
t>VNA</tt>, <tt>Evidence</tt>, and <tt>UA DET</tt>) using the keypair of the UA This is the current DET [RFC9374] being used by the UA; it is assumed to
DET. The signature algorithm is specified by the HHIT Suite ID of the DET.</li> be a Specific Session ID (a type of UAS ID).
</ul>
<t>When using this structure, the UA is minimally self-endorsing its DET Perhaps B (UA is assumed to be a Specific Session ID):
. The HI of the UA DET can be looked up by mechanisms described in <xref target= UA DRIP Entity Tag: (16 octets)
"drip-registries" format="default"/> or by extracting it from a Broadcast Endors
ement (see <xref target="drip-link" format="default"/> and <xref target="drip-re This is the current DET [RFC9374] being used by the UA that is assumed to
commendations" format="default"/>).</t> be a Specific Session ID (a type of UAS ID).
-->
<t>This is the current DET <xref target="RFC9374" format="default"/> bei
ng used by the UA assumed to be a Specific Session ID (a type of UAS ID).</t></d
d>
<!-- [rfced] We are unsure what "Signature over concatenation" means. Please re
view and let us know how/if the text may be clarified.
Original:
UA Signature: (64 octets)
Signature over concatenation of preceding fields (VNB, VNA,
Evidence, and UA DET) using the keypair of the UA DET.
Signature by Parent: (64 octets)
Signature over concatenation of preceding fields (VNB, VNA, DET of
Child, HI of Child, and DET of Parent) using the keypair of the
Parent DET.
-->
<dt>UA Signature:</dt><dd><t>(64 octets)</t>
<t>Signature over concatenation of preceding fields (<tt>VNB</tt>, <tt>V
NA</tt>, <tt>Evidence</tt>, and <tt>UA DET</tt>) using the keypair of the UA DET
. The signature algorithm is specified by the Hierarchical Host Identity Tags (H
HIT) Suite ID of the DET.</t></dd></dl>
<t>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 in <xref target=
"I-D.ietf-drip-registries" format="default"/> or by extracting it from a Broadca
st Endorsement (see Sections <xref target="drip-link" format="counter"/> and <xr
ef target="drip-recommendations" format="counter"/>).</t>
</section> </section>
<section anchor="drip-link" numbered="true" toc="default"> <section anchor="drip-link" numbered="true" toc="default">
<name>DRIP Link</name> <name>DRIP Link</name>
<t>This SAM Type is used to transmit Broadcast Endorsements. For example , the <tt>BE: HDA, UA</tt> is sent (see <xref target="drip-recommendations" form at="default"/>) as a DRIP Link message.</t> <t>This SAM Type is used to transmit Broadcast Endorsements. For example , the <tt>BE: HDA, UA</tt> is sent (see <xref target="drip-recommendations" for mat="default"/>) as a DRIP Link message.</t>
<t>DRIP Link is important as its contents are used to provide trust in t he DET/HI pair that the UA is currently broadcasting. This message does not requ ire Internet connectivity to perform signature verification of the contents when the DIME DET/HI is in the Observer's cache. It also provides the UA HI, when it is filled with a <tt>BE: HDA, UA</tt>, so that connectivity is not required whe n performing signature verification of other DRIP Authentication Messages.</t> <t>DRIP Link is important as its contents are used to provide trust in t he DET/HI pair that the UA is currently broadcasting. This message does not requ ire Internet connectivity to perform signature verification of the contents when the DIME DET/HI is in the Observer's cache. It also provides the UA HI, when it is filled with a <tt>BE: HDA, UA</tt>, so that connectivity is not required whe n performing signature verification of other DRIP Authentication Messages.</t>
<!-- [rfced] It is unclear what "operation" refers to here. Please review.
Original:
Various Broadcast Endorsements are sent during operation to ensure
that the full Broadcast Endorsement chain is available offline.
-->
<t>Various Broadcast Endorsements are sent during operation to ensure th at the full Broadcast Endorsement chain is available offline. See <xref target=" drip-recommendations" format="default"/> for further details.</t> <t>Various Broadcast Endorsements are sent during operation to ensure th at the full Broadcast Endorsement chain is available offline. See <xref target=" drip-recommendations" format="default"/> for further details.</t>
<figure anchor="link-fig"> <figure anchor="link-fig">
<name>Broadcast Endorsement / DRIP Link</name> <name>Broadcast Endorsement / DRIP Link</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 Parent | | VNB Timestamp by Parent |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| VNA Timestamp by Parent | | VNA Timestamp by Parent |
skipping to change at line 434 skipping to change at line 604
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>VNB Timestamp by Parent: (4 octets)</t> <dl><dt>VNB Timestamp by Parent:</dt><dd><t>(4 octets)</t>
<ul empty="true" spacing="normal"> <t>See <xref target="astm-timestamps" format="default"/>. Set by Parent
<li>See <xref target="astm-timestamps" format="default"/>. Set by Pare Entity.</t></dd>
nt Entity.</li> <dt>VNA Timestamp by Parent:</dt><dd><t>(4 octets)</t>
</ul> <t>See <xref target="astm-timestamps" format="default"/>. Set by Parent
<t>VNA Timestamp by Parent: (4 octets)</t> Entity.</t></dd>
<ul empty="true" spacing="normal"> <dt>DET of Child:</dt><dd><t>(16 octets)</t>
<li>See <xref target="astm-timestamps" format="default"/>. Set by Pare <t>DRIP Entity Tag of Child Entity.</t></dd>
nt Entity.</li> <dt>HI of Child:</dt><dd><t>(32 octets)</t>
</ul> <t>Host Identity of Child Entity.</t></dd>
<t>DET of Child: (16 octets)</t> <dt>DET of Parent:</dt><dd><t>(16 octets)</t>
<ul empty="true" spacing="normal"> <t>DRIP Entity Tag of Parent Entity in DIME Hierarchy.</t></dd>
<li>DRIP Entity Tag of Child Entity.</li> <dt>Signature by Parent:</dt><dd><t>(64 octets)</t>
</ul> <t>Signature over concatenation of preceding fields (<tt>VNB</tt>, <tt>V
<t>HI of Child: (32 octets)</t> NA</tt>, <tt>DET of Child</tt>, <tt>HI of Child</tt>, and <tt>DET of Parent</tt>
<ul empty="true" spacing="normal"> ) using the keypair of the Parent DET.</t></dd></dl>
<li>Host Identity of Child Entity.</li>
</ul>
<t>DET of Parent: (16 octets)</t>
<ul empty="true" spacing="normal">
<li>DRIP Entity Tag of Parent Entity in DIME Hierarchy.</li>
</ul>
<t>Signature by Parent: (64 octets)</t>
<ul empty="true" spacing="normal">
<li>Signature over concatenation of preceding fields (<tt>VNB</tt>, <t
t>VNA</tt>, <tt>DET of Child</tt>, <tt>HI of Child</tt>, and <tt>DET of Parent</
tt>) using the keypair of the Parent DET.</li>
</ul>
<t>This DRIP Authentication Message is used in conjunction with other DR IP SAM Types (such as the Manifest or the Wrapper) that contain data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that is guaranteed to be unique, unpredictable, and easily cross-checked by the receiving device.</t> <t>This DRIP Authentication Message is used in conjunction with other DR IP SAM Types (such as the Manifest or the Wrapper) that contain data (e.g., the ASTM Location/Vector Message, Message Type 0x2) that is guaranteed to be unique, unpredictable, and easily cross-checked by the receiving device.</t>
<t>A hash of the final link (<tt>BE: HDA on UA</tt>) in the Broadcast En dorsement chain MUST be included in each DRIP Manifest <xref target="drip-manife st" format="default"/>.</t> <t>A hash of the final link (<tt>BE: HDA on UA</tt>) in the Broadcast En dorsement chain <bcp14>MUST</bcp14> be included in each DRIP Manifest (<xref tar get="drip-manifest" format="default"/>).</t>
</section> </section>
<section anchor="drip-wrapper" numbered="true" toc="default"> <section anchor="drip-wrapper" numbered="true" toc="default">
<name>DRIP Wrapper</name> <name>DRIP Wrapper</name>
<t>This SAM Type is used to wrap and sign over a list of other <xref tar get="F3411" format="default"/> Broadcast RID messages.</t> <t>This SAM Type is used to wrap and sign over a list of other <xref tar get="F3411" format="default"/> Broadcast RID messages.</t>
<t>The <tt>evidence</tt> section of the <tt>UA Signed Evidence Structure </tt> (<xref target="bas" format="default"/>) is populated with up to four ASTM <xref target="F3411" format="default"/> Messages in a contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 are allowed and must be in Message Type order as defined by <xref target="F3411" format="default"/>. These messages MUST include the Message Type and Protocol Version octet and MUST NOT i nclude the Message Counter octet (thus are fixed at 25 octets in length).</t> <t>The <tt>evidence</tt> section of the <tt>UA Signed Evidence Structure </tt> (<xref target="bas" format="default"/>) is populated with up to four ASTM Messages <xref target="F3411" format="default"/> in a contiguous octet sequence. Only ASTM Message Types 0x0, 0x1, 0x3, 0x4, and 0x5 are allowed and must be in Message Type order as defined by <xref target="F3411" format="default"/>. These messages <bcp14>MUST</bcp14> include the Message Type and Protocol Version octet and <bcp14>MUST NOT</bcp14> include the Message Counter octet (thus are fixed a t 25 octets in length).</t>
<section anchor="wrapped-count-format-validation" numbered="true" toc="d efault"> <section anchor="wrapped-count-format-validation" numbered="true" toc="d efault">
<name>Wrapped Count &amp; Format Validation</name> <name>Wrapped Count and Format Validation</name>
<t>When decoding a DRIP Wrapper on a receiver, a calculation of the nu <t>When decoding a DRIP Wrapper on a receiver, a calculation of the nu
mber of messages wrapped and a validation MUST be performed by using the number mber of messages wrapped and a validation <bcp14>MUST</bcp14> be performed by us
of octets (defined as <tt>wrapperLength</tt>) between the <tt>VNA Timestamp by U ing the number of octets (defined as <tt>wrapperLength</tt>) between the <tt>VNA
A</tt> and the <tt>UA DET</tt> as shown in <xref target="wrapper-check" format=" Timestamp by UA</tt> and the <tt>UA DET</tt> as shown in <xref target="wrapper-
default"/>.</t> check" format="default"/>.</t>
<figure anchor="wrapper-check"> <figure anchor="wrapper-check">
<name>Pseudo-code for Wrapper validation and number of messages calc <name>Pseudocode for Wrapper Validation and Number of Messages calcu
ulation</name> lation</name>
<sourcecode name="" type="" markers="true"><![CDATA[
<sourcecode name="" type="pseudocode" markers="true"><![CDATA[
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) {
return DECODE_FAILURE; return DECODE_FAILURE;
} else { } else {
skipping to change at line 484 skipping to change at line 642
} }
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) {
return DECODE_FAILURE; return DECODE_FAILURE;
} else { } else {
// DECODE_SUCCESS; treat as standard DRIP Wrapper // DECODE_SUCCESS; treat as standard DRIP Wrapper
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="extended-wrapper" numbered="true" toc="default"> <section anchor="extended-wrapper" numbered="true" toc="default">
<name>Wrapper over Extended Transports</name> <name>Wrapper over Extended Transports</name>
<t>When using Extended Transports an optimization can be made to DRIP <t>When using Extended Transports, an optimization to DRIP Wrapper can
Wrapper to sign over co-located data in an ASTM Message Pack (Message Type 0xF). be made to sign over co-located data in an ASTM Message Pack (Message Type 0xF)
</t> .</t>
<t>To perform this optimization the <tt>UA Signed Evidence Structure</ <t>To perform this optimization, the <tt>UA Signed Evidence Structure<
tt> is filled with the ASTM Messages to be in the ASTM Message Pack, the signatu /tt> is filled with the ASTM Messages to be in the ASTM Message Pack, the signat
re is generated, then the <tt>evidence</tt> field is cleared leaving the encoded ure is generated, and then the <tt>evidence</tt> field is cleared, leaving the e
form shown in <xref target="set-sig" format="default"/>.</t> ncoded form shown in <xref target="set-sig" format="default"/>.</t>
<figure anchor="set-sig"> <figure anchor="set-sig">
<name>DRIP Wrapper over Extended Transports</name> <name>DRIP Wrapper over Extended Transports</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 526 skipping to change at line 683
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>To verify the signature, the receiver MUST concatenate all the mess <t>To verify the signature, the receiver <bcp14>MUST</bcp14> concatena
ages in the Message Pack (excluding Authentication Message found in the same Mes te all the messages in the Message Pack (excluding the Authentication Message fo
sage Pack) in ASTM Message Type order and set the <tt>evidence</tt> section of t und in the same Message Pack) in ASTM Message Type order and set the <tt>evidenc
he <tt>UA Signed Evidence Structure</tt> before performing signature verificatio e</tt> section of the <tt>UA Signed Evidence Structure</tt> before performing si
n.</t> gnature verification.</t>
<t>The functionality of a Wrapper in this form is equivalent to Messag <t>The functionality of a Wrapper in this form is equivalent to Messag
e Set Signature (Authentication Type 0x3) when running over Extended Transports. e Set Signature (Authentication Type 0x3) when running over Extended Transports.
What the Wrapper provides is the same format but over both Extended and Legacy The Wrapper provides the same format but over both Extended and Legacy Transpor
Transports allowing the transports to be similar. Message Set Signature also imp ts, which allows the transports to be similar. Message Set Signature also implie
lies using the ASTM validator system architecture which depends on Internet conn s using the ASTM validator system architecture, which depends on Internet connec
ectivity for verification which the receiver may not have at the time of receipt tivity for verification that the receiver may not have at the time an Authentica
of an Authentication Message. This is something the Wrapper, and all DRIP Authe tion Message is received. This is something the Wrapper, and all DRIP Authentica
ntication Formats, avoid when the UA key is obtained via a DRIP Link Authenticat tion Formats, avoid when the UA key is obtained via a DRIP Link Authentication M
ion Message.</t> essage.</t>
</section> </section>
<section anchor="wrapper-limitations" numbered="true" toc="default"> <section anchor="wrapper-limitations" numbered="true" toc="default">
<name>Wrapper Limitations</name> <name>Wrapper Limitations</name>
<t>The primary limitation of the Wrapper is the bounding of up to 4 AS <!-- [rfced] What does "Observer on the ground" refer to? Will this be understo
TM Messages that can be sent within it. Another limitation is that the format ca od by readers?
nnot be used as a surrogate for messages it is wrapping due to the potential tha
t an Observer on the ground does not support DRIP. Thus, when a Wrapper is being Original:
used, the wrapped data must effectively be sent twice, once as a single framed Another limitation is that the
message (as specified in <xref target="F3411" format="default"/>) and then again format cannot be used as a surrogate for messages it is wrapping due
within the Wrapper.</t> to the potential that an Observer on the ground does not support
DRIP.
-->
<t>The primary limitation of the Wrapper is the bounding of up to four
ASTM Messages that can be sent within it. Another limitation is that the format
cannot be used as a surrogate for messages it is wrapping due to the potential
that an Observer on the ground does not support DRIP. Thus, when a Wrapper is be
ing used, the wrapped data must effectively be sent twice, once as a single-fram
ed message (as specified in <xref target="F3411" format="default"/>) and again w
ithin the Wrapper.</t>
</section> </section>
</section> </section>
<section anchor="drip-manifest" numbered="true" toc="default"> <section anchor="drip-manifest" numbered="true" toc="default">
<name>DRIP Manifest</name> <name>DRIP Manifest</name>
<t>This SAM Type is used to create message manifests that contain hashes of previously sent ASTM Messages.</t> <t>This SAM Type is used to create message manifests that contain hashes of previously sent ASTM Messages.</t>
<t>By hashing previously sent messages and signing them, we gain trust i <t>By hashing previously sent messages and signing them, we gain trust i
n a UA's previous reports without re-transmitting them. This is a way to evade t n a UA's previous reports without retransmitting them. This is a way to evade th
he limitation of a maximum of 4 messages in the Wrapper (<xref target="wrapper-l e limitation of a maximum of four messages in the Wrapper (<xref target="wrapper
imitations" format="default"/>) and greatly reduce overhead.</t> -limitations" format="default"/>) and greatly reduce overhead.</t>
<t>Observers MUST hash all received ASTM Messages and cross-check them a <t>Observers <bcp14>MUST</bcp14> hash all received ASTM Messages and cro
gainst hashes in received Manifests.</t> ss-check them against hashes in received Manifests.</t>
<t>Judicious use of a Manifest enables an entire Broadcast RID message s tream to be strongly authenticated with less than 100% overhead relative to a co mpletely unauthenticated message stream (see <xref target="drip-recommendations" format="default"/> and <xref target="operational-proof" format="default"/>).</t > <t>Judicious use of a Manifest enables an entire Broadcast RID message s tream to be strongly authenticated with less than 100% overhead relative to a co mpletely unauthenticated message stream (see <xref target="drip-recommendations" format="default"/> and <xref target="operational-proof" format="default"/>).</t >
<t>The <tt>evidence</tt> section of the <tt>UA Signed Evidence Structure <t>The <tt>evidence</tt> section of the <tt>UA Signed Evidence Structure
</tt> (<xref target="bas" format="default"/>) is populated with 8-octet hashes o </tt> (<xref target="bas" format="default"/>) is populated with 8-octet hashes o
f <xref target="F3411" format="default"/> Broadcast RID messages (up to 11) and f <xref target="F3411" format="default"/> Broadcast RID messages (up to 11) and
three special hashes (<xref target="block-hashes" format="default"/>). All these three special hashes (<xref target="block-hashes" format="default"/>). All of th
hashes MUST be concatenated to form a contiguous octet sequence in the <tt>evid ese hashes <bcp14>MUST</bcp14> be concatenated to form a contiguous octet sequen
ence</tt> section. It is RECOMMENDED the max number of ASTM Message Hashes be us ce in the <tt>evidence</tt> section. It is <bcp14>RECOMMENDED</bcp14> that the m
ed is 10 (see <xref target="eleven-astm-messages" format="default"/>).</t> aximum number of ASTM Message Hashes used be 10 (see <xref target="eleven-astm-m
<t>The <tt>Previous Manifest Hash</tt>, <tt>Current Manifest Hash</tt>, essages" format="default"/>).</t>
and <tt>DRIP Link (BE: HDA, UA) Hash</tt> MUST always come before the <tt>ASTM M <t>The <tt>Previous Manifest Hash</tt>, <tt>Current Manifest Hash</tt>,
essage Hashes</tt> as seen in <xref target="manifest-fig" format="default"/>.</t and <tt>DRIP Link (BE: HDA, UA) Hash</tt> <bcp14>MUST</bcp14> always come before
> the <tt>ASTM Message Hashes</tt> as seen in <xref target="manifest-fig" format=
<t>An Observer MUST use the Manifest to verify each ASTM Message hashed "default"/>.</t>
therein that it has previously received. It can do this without having received <t>An Observer <bcp14>MUST</bcp14> use the Manifest to verify each ASTM
them all. A Manifest SHOULD typically encompass a single transmission cycle of m Message hashed therein that it has previously received. It can do this without h
essages being sent, see <xref target="operational-recommendations" format="defau aving received them all. A Manifest <bcp14>SHOULD</bcp14> typically encompass a
lt"/> and <xref target="operational-proof" format="default"/>.</t> single transmission cycle of messages being sent; see <xref target="operational-
recommendations" format="default"/> and <xref target="operational-proof" format=
"default"/>.</t>
<figure anchor="manifest-fig"> <figure anchor="manifest-fig">
<name>DRIP Manifest Evidence Structure</name> <name>DRIP Manifest Evidence Structure</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Previous Manifest | | Previous Manifest |
| Hash | | Hash |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Current Manifest | | Current Manifest |
skipping to change at line 566 skipping to change at line 732
| Hash | | Hash |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
. . . .
. ASTM Message Hashes . . ASTM Message Hashes .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Previous Manifest Hash: (8 octets)</t> <dl>
<ul empty="true" spacing="normal"> <dt>Previous Manifest Hash:</dt><dd><t>(8 octets)</t>
<li>Hash of the previously sent Manifest Message.</li> <t>Hash of the previously sent Manifest Message.</t></dd>
</ul> <dt>Current Manifest Hash:</dt><dd><t>(8 octets)</t>
<t>Current Manifest Hash: (8 octets)</t> <t>Hash of the current Manifest Message.</t></dd>
<ul empty="true" spacing="normal"> <dt>DRIP Link (BE: HDA, UA):</dt><dd><t>(8 octets)</t>
<li>Hash of the current Manifest Message.</li> <t>Hash of the DRIP Link Authentication Message carrying <tt>BE: HDA,
</ul> UA</tt> (see <xref target="drip-link" format="default"/>).</t></dd>
<t>DRIP Link (BE: HDA, UA): (8 octets)</t> <dt>ASTM Message Hash:</dt><dd><t>(8 octets)</t>
<ul empty="true" spacing="normal"> <t>Hash of a single full ASTM Message using hash operations described
<li>Hash of the DRIP Link Authentication Message carrying <tt>BE: HDA, in <xref target="hash-op" format="default"/>.</t></dd></dl>
UA</tt> (see <xref target="drip-link" format="default"/>).</li>
</ul>
<t>ASTM Message Hash: (8 octets)</t>
<ul empty="true" spacing="normal">
<li>Hash of a single full ASTM Message using hash operations described
in <xref target="hash-op" format="default"/>.</li>
</ul>
<section anchor="hash-count-format-validation" numbered="true" toc="defa ult"> <section anchor="hash-count-format-validation" numbered="true" toc="defa ult">
<name>Hash Count &amp; Format Validation</name> <name>Hash Count and Format Validation</name>
<t>When decoding a DRIP Manifest on a receiver, a calculation of the n <t>When decoding a DRIP Manifest on a receiver, a calculation of the n
umber of hashes and a validation can be performed by using the number of octets umber of hashes and a validation can be performed by using the number of octets
(defined as <tt>manifestLength</tt>) between the <tt>UA DET</tt> and the <tt>VNB between the <tt>UA DET</tt> and the <tt>VNB Timestamp by UA</tt> (defined as
Timestamp by UA</tt> such as shown in <xref target="manifest-check" format="def <tt>manifestLength</tt>) such as shown in <xref target="manifest-check" format="
ault"/>.</t> default"/>.</t>
<figure anchor="manifest-check"> <figure anchor="manifest-check">
<name>Pseudo-code for Manifest Sanity Check and Number of Hashes Cal <name>Pseudocode for Manifest Sanity Check and Number of Hashes Calc
culation</name> ulation</name>
<sourcecode name="" type="" markers="true"><![CDATA[
<sourcecode name="" type="pseudocode" markers="true"><![CDATA[
if (manifestLength MOD 8) != 0 { if (manifestLength MOD 8) != 0 {
return DECODE_FAILURE return DECODE_FAILURE
} }
hashCount = (manifestLength / 8) - 3; hashCount = (manifestLength / 8) - 3;
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="block-hashes" numbered="true" toc="default"> <section anchor="block-hashes" numbered="true" toc="default">
<name>Manifest Ledger Hashes</name> <name>Manifest Ledger Hashes</name>
<!-- [rfced] The text specifies three special hashes, but then says "these two h
ashes". Does the following specify 2 or 3 hashes?
Original:
Three special hashes are included in all Manifests. The Previous
Manifest Hash, links to the previous Manifest, and the Current
Manifest Hash is of the Manifest in which it appears. These two
hashes act as a ledger of provenance to the Manifest that could be
traced back if the Observer was present for extended periods of time.
In addition, does "is of the Manifest in which it appears" only apply to Current
Manifest Hash, or does it apply to all of the listed hashes? Should "is" be "a
re"? Otherwise, is the second sentence only a list of the hashes, in which case
it's a sentence fragment. Perhaps the first and second sentence should be comb
ined?
Perhaps:
Three special hashes are included in all Manifests: the Previous
Manifest Hash, links to the previous Manifest, and the Current
Manifest Hash that is of the Manifest in which it appears.
-->
<t>Three special hashes are included in all Manifests. The <tt>Previou s Manifest Hash</tt>, links to the previous Manifest, and the <tt>Current Manife st Hash</tt> is of the Manifest in which it appears. These two hashes act as a l edger of provenance to the Manifest that could be traced back if the Observer wa s present for extended periods of time.</t> <t>Three special hashes are included in all Manifests. The <tt>Previou s Manifest Hash</tt>, links to the previous Manifest, and the <tt>Current Manife st Hash</tt> is of the Manifest in which it appears. These two hashes act as a l edger of provenance to the Manifest that could be traced back if the Observer wa s present for extended periods of time.</t>
<t>The <tt>DRIP Link (BE: HDA, UA)</tt> is included so there is a dire ct signature by the UA over the Broadcast Endorsement (see <xref target="drip-li nk" format="default"/>). Typical operation would expect that the list of <tt>AST M Message Hash</tt>'s contain nonce-link data. To enforce a binding between the <tt>BE: HDA, UA</tt> and avoid trivial replay attack vectors (see <xref target=" replay-attacks" format="default"/>) at least 1 <tt>ASTM Message Hash</tt> MUST b e from an <xref target="F3411" format="default"/> message that satisfies the 4th requirement in <xref target="drip-recommendations" format="default"/>.</t> <t>The <tt>DRIP Link (BE: HDA, UA)</tt> is included so there is a dire ct signature by the UA over the Broadcast Endorsement (see <xref target="drip-li nk" format="default"/>). Typical operation would expect that the list of <tt>AST M Message Hashes</tt> contain nonce-like data. To enforce a binding between the <tt>BE: HDA, UA</tt> and avoid trivial replay attack vectors (see <xref target=" replay-attacks" format="default"/>), at least one <tt>ASTM Message Hash</tt> <bc p14>MUST</bcp14> be from an <xref target="F3411" format="default"/> message that satisfies the fourth requirement in <xref target="drip-recommendations" format= "default"/>.</t>
</section> </section>
<section anchor="hash-op" numbered="true" toc="default"> <section anchor="hash-op" numbered="true" toc="default">
<name>Hash Algorithms and Operation</name> <name>Hash Algorithms and Operation</name>
<t>The hash algorithm used for the Manifest is the same hash algorithm used in creation of the DET <xref target="RFC9374" format="default"/> that is s igning the Manifest. This is encoded as part of the DET using the HHIT Suite ID. </t> <t>The hash algorithm used for the Manifest is the same hash algorithm used in creation of the DET <xref target="RFC9374" format="default"/> that is s igning the Manifest. This is encoded as part of the DET using the HHIT Suite ID. </t>
<t>DET's using cSHAKE128 <xref target="NIST.SP.800-185" format="defaul <t>DETs that use cSHAKE128 <xref target="NIST.SP.800-185" format="defa
t"/> compute the hash as follows:</t> ult"/> compute the hash as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")
]]></artwork> ]]></artwork>
<t>For OGAs other than "5" <xref target="RFC9374" format="default"/>, <t>For ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/cSHAK
use the construct appropriate for the associated hash. For example, for "2" whic E128) <xref target="RFC9374" format="default"/>, use the construct appropriate f
h is ECDSA/SHA-384:</t> or the associated hash. For example, the hash for "2" (ECDSA/SHA-384) is compute
<artwork name="" type="" align="left" alt=""><![CDATA[ d as follows:</t>
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 ) <artwork name="" type="" align="left" alt=""><![CDATA[
Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )
]]></artwork> ]]></artwork>
<t>When building the list of hashes, the <tt>Previous Manifest Hash</t t> is known from the previous Manifest. For the first built Manifest this value is filled with a random nonce. The <tt>Current Manifest Hash</tt> is null filled while ASTM Messages are hashed and fill the <tt>ASTM Messages Hashes</tt> secti on. When all messages are hashed, the <tt>Current Manifest Hash</tt> is computed over the <tt>Previous Manifest Hash</tt>, <tt>Current Manifest Hash</tt> (null filled) and <tt>ASTM Messages Hashes</tt>. This hash value replaces the null fil led <tt>Current Manifest Hash</tt> and becomes the <tt>Previous Manifest Hash</t t> for the next Manifest.</t> <t>When building the list of hashes, the <tt>Previous Manifest Hash</t t> is known from the previous Manifest. For the first built Manifest, this value is filled with a random nonce. The <tt>Current Manifest Hash</tt> is null fille d while ASTM Messages are hashed and fill the <tt>ASTM Messaged Hashes</tt> sect ion. When all messages are hashed, the <tt>Current Manifest Hash</tt> is compute d over the <tt>Previous Manifest Hash</tt>, <tt>Current Manifest Hash</tt> (null filled), and <tt>ASTM Message Hashes</tt>. This hash value replaces the null-fi lled <tt>Current Manifest Hash</tt> and becomes the <tt>Previous Manifest Hash</ tt> for the next Manifest.</t>
<section anchor="legacy-transport-hashing" numbered="true" toc="defaul t"> <section anchor="legacy-transport-hashing" numbered="true" toc="defaul t">
<name>Legacy Transport Hashing</name> <name>Legacy Transport Hashing</name>
<t>Under this transport DRIP hashes the full ASTM Message being sent <t>Under this transport, DRIP hashes the full ASTM Message being sen
over the Bluetooth Advertising frame. This is the 25-octet object start with th t over the Bluetooth Advertising frame. This is the 25-octet object that starts
e Message Type and Protocol Version octet along with the 24 octets of message da with the Message Type and Protocol Version octet along with the 24 octets of mes
ta. The hash MUST NOT included the Message Counter octet.</t> sage data. The hash <bcp14>MUST NOT</bcp14> include the Message Counter octet.</
<t>For paged ASTM Messages (currently only Authentication Messages) t>
all the pages are concatenated together in Page Number order and hashed as one o <t>For paged ASTM Messages (currently only Authentication Messages),
bject.</t> all of the pages are concatenated together in Page Number order and hashed as o
ne object.</t>
</section> </section>
<section anchor="extended-transport-hashing" numbered="true" toc="defa ult"> <section anchor="extended-transport-hashing" numbered="true" toc="defa ult">
<name>Extended Transport Hashing</name> <name>Extended Transport Hashing</name>
<t>Under this transport DRIP hashes the full ASTM Message Pack (Mess age Type 0xF) regardless of its content. The hash MUST NOT included the Message Counter octet.</t> <t>Under this transport, DRIP hashes the full ASTM Message Pack (Mes sage Type 0xF) regardless of its content. The hash <bcp14>MUST NOT</bcp14> inclu de the Message Counter octet.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="drip-frame" numbered="true" toc="default"> <section anchor="drip-frame" numbered="true" toc="default">
<name>DRIP Frame</name> <name>DRIP Frame</name>
<!-- [rfced] For ease of the reader, may we update "Section 4.1" to indicate the
subject matter?
Original:
This SAM Type is defined to enable the use of Section 4.1 in the
future beyond the previously defined formats (Wrapper and Manifest)
by the inclusion of a single octet to signal the format of evidence
data (up to 111 octets).
Perhaps (where "UA Signed Evidence Structure" would appear in <tt>):
This SAM Type is defined to enable use of the UA Signed Evidence Structure
(Section 4.1) in the future beyond the previously defined formats (Wrapper an
d
Manifest) by the inclusion of a single octet to signal the format of evidence
data (up to 111 octets).
-->
<t>This SAM Type is defined to enable the use of <xref target="bas" form at="default"/> in the future beyond the previously defined formats (Wrapper and Manifest) by the inclusion of a single octet to signal the format of <tt>evidenc e</tt> data (up to 111 octets).</t> <t>This SAM Type is defined to enable the use of <xref target="bas" form at="default"/> in the future beyond the previously defined formats (Wrapper and Manifest) by the inclusion of a single octet to signal the format of <tt>evidenc e</tt> data (up to 111 octets).</t>
<t>The content format of <tt>Frame Evidence Data</tt> is not defined in <!-- [rfced] For clarity, please consider the following update.
this document. Other specifications MUST define the contents and register for a
<tt>Frame Type</tt>. At the time of publication there are no defined Frame Types Original:
other than an Experimental range.</t> At the time of publication there are no defined
<t>Observers MUST check the signature of the structure (<xref target="ba Frame Types other than an Experimental range.
s" format="default"/>) per <xref target="ua-attestation" format="default"/> and
MAY, if the specification of <tt>Frame Type</tt> is known, parse the content in Perhaps:
<tt>Frame Evidence Data</tt>.</t> At the time of publication, there are no defined
Frame Types; only an Experimental range has been defined.
-->
<t>The content format of <tt>Frame Evidence Data</tt> is not defined in
this document. Other specifications <bcp14>MUST</bcp14> define the contents and
register for a <tt>Frame Type</tt>. At the time of publication, there are no def
ined Frame Types other than an Experimental range.</t>
<t>Observers <bcp14>MUST</bcp14> check the signature of the structure (<
xref target="bas" format="default"/>) per <xref target="ua-attestation" format="
default"/> and <bcp14>MAY</bcp14>, if the specification of <tt>Frame Type</tt> i
s known, parse the content in <tt>Frame Evidence Data</tt>.</t>
<figure anchor="frame-fig"> <figure anchor="frame-fig">
<name>DRIP Frame</name> <name>DRIP Frame</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 .
. . . .
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Frame Type: (1 octet)</t> <dl>
<ul empty="true" spacing="normal"> <dt>Frame Type:</dt><dd><t>(1 octet)</t>
<li>Byte to sub-type for future different DRIP Frame formats. It takes <!-- [rfced] For clarity, may we update the text as follows?
the first octet in <xref target="frame-fig" format="default"/>, leaving 111 oct
ets available for <tt>Frame Evidence Data</tt>. See <xref target="iana-drip-regi Original (preceding text included for context):
stry" format="default"/> for Frame Type allocations.</li> Frame Type: (1 octet)
</ul>
Byte to sub-type for future different DRIP Frame formats. It
takes the first octet in Figure 10, leaving 111 octets available
for Frame Evidence Data.
Perhaps (update to the second sentence):
As shown in Figure 10, the Frame Type takes the first octet, which
leaves 111 octets available for Frame Evidence Data.
-->
<t>Byte to subtype for future different DRIP Frame formats. It takes t
he first octet in <xref target="frame-fig" format="default"/>, leaving 111 octet
s available for <tt>Frame Evidence Data</tt>. See <xref target="iana-drip-regist
ry" format="default"/> for Frame Type allocations.</t></dd></dl>
</section> </section>
</section> </section>
<section anchor="fec-details" numbered="true" toc="default"> <section anchor="fec-details" numbered="true" toc="default">
<name>Forward Error Correction</name> <name>Forward Error Correction</name>
<t>For Broadcast RID, FEC is provided by the lower layers in Extended Tran sports. The Bluetooth 4.x Legacy Transport does not have supporting FEC, so with DRIP Authentication the following application level scheme is used to add some FEC. When sending data over a medium that does not have underlying FEC, for exam ple Bluetooth 4.x, then this section MUST be used.</t> <t>For Broadcast RID, FEC is provided by the lower layers in Extended Tran sports. The Bluetooth 4.x Legacy Transport does not support FEC, so the followin g application-level scheme is used with DRIP Authentication to add some FEC. Whe n sending data over a medium that does not have underlying FEC, for example Blue tooth 4.x, this section <bcp14>MUST</bcp14> be used.</t>
<t>The Bluetooth 4.x lower layers have error detection but not correction. Any frame in which Bluetooth detects an error is dropped and not delivered to h igher layers (in our case, DRIP). Thus it can be treated as an erasure.</t> <t>The Bluetooth 4.x lower layers have error detection but not correction. Any frame in which Bluetooth detects an error is dropped and not delivered to h igher layers (in our case, DRIP). Thus it can be treated as an erasure.</t>
<t>DRIP standardizes a single page FEC scheme using XOR parity across all <t>DRIP standardizes a single page FEC scheme using XOR parity across all
page data of an Authentication Message. This allows the correction of single era page data of an Authentication Message. This allows the correction of a single e
sed page in an Authentication Message. If more than a single page is missing the rased page in an Authentication Message. If more than a single page is missing,
n handling of an incomplete Authentication Message is determined by higher layer then handling of an incomplete Authentication Message is determined by higher la
s.</t> yers.</t>
<t>Other FEC schemes, to protect more than a single page of an Authenticat <t>Other FEC schemes, to protect more than a single page of an Authenticat
ion Message or multiple <xref target="F3411" format="default"/> Messages, is lef ion Message or multiple <xref target="F3411" format="default"/> Messages, are le
t for future standardization if operational experience proves it necessary and/o ft for future standardization if operational experience proves it necessary and/
r practical.</t> or practical.</t>
<t>The data added during FEC is not included in the <tt>Authentication Dat <t>The data added during FEC is not included in the <tt>Authentication Dat
a / Signature</tt>, but instead in the <tt>Additional Data</tt> field of <xref t a / Signature</tt>, but instead in the <tt>Additional Data</tt> field of <xref t
arget="astm-auth" format="default"/>. This may cause the Authentication Message arget="astm-auth" format="default"/>. This may cause the Authentication Message
to exceed 9-pages, up to a maximum of 16-pages.</t> to exceed 9 pages, up to a maximum of 16 pages.</t>
<section anchor="enc-single-page" numbered="true" toc="default"> <section anchor="enc-single-page" numbered="true" toc="default">
<name>Encoding</name> <name>Encoding</name>
<t>When encoding two things are REQUIRED:</t> <t>When encoding, two things are <bcp14>REQUIRED</bcp14>:</t>
<ol spacing="normal" type="1"><li>The FEC data MUST start on a new Authe <ol spacing="normal" type="1">
ntication Page. To do this, the results of parity encoding MUST be placed in the <li>The FEC data <bcp14>MUST</bcp14> start on a new Authentication
<tt>Additional Data</tt> field of <xref target="astm-auth" format="default"/> w Page. To do this, the results of parity encoding <bcp14>MUST</bcp14>
ith null padding before it to line up with the next page. The <tt>Additional Dat be placed in the <tt>Additional Data</tt> field of <xref
a Length</tt> field MUST be set to <tt>number of padding octets + number of pari target="astm-auth" format="default"/> with null padding before it to
ty octets</tt>.</li> line up with the next page. The <tt>Additional Data Length</tt>
<li>The <tt>Last Page Index</tt> field (in Page 0) MUST be incremented field <bcp14>MUST</bcp14> be set to <tt>number of padding octets +
from what it would have been without FEC by the number of pages required for th number of parity octets</tt>.</li>
e <tt>Additional Data Length</tt> field, null padding and FEC.</li> <li>The <tt>Last Page Index</tt> field (in Page 0)
<bcp14>MUST</bcp14> be incremented from what it would have been
without FEC by the number of pages required for the <tt>Additional
Data Length</tt> field, null padding, and FEC.</li>
</ol> </ol>
<t>To generate the parity, a simple XOR operation using the previous par ity page and current page is used. Only the 23-octet <tt>Authentication Payload< /tt> field of <xref target="astm-auth-page" format="default"/> is used in the XO R operations. For Page 0, a 23-octet null pad is used for the previous parity pa ge.</t> <t>To generate the parity, a simple XOR operation using the previous par ity page and current page is used. Only the 23-octet <tt>Authentication Payload< /tt> field of <xref target="astm-auth-page" format="default"/> is used in the XO R operations. For Page 0, a 23-octet null pad is used for the previous parity pa ge.</t>
<t><xref target="fig-single-fec" format="default"/> shows an example of the last two pages (out of N) of an Authentication Message using DRIP Single Pag e FEC. The <tt>Additional Data Length</tt> is set to 33 as there are always 23 o ctets of FEC data and in this example 10 octets of padding to line it up into Pa ge N.</t> <t><xref target="fig-single-fec" format="default"/> shows an example of the last two pages (out of N) of an Authentication Message using DRIP Single Pag e FEC. The <tt>Additional Data Length</tt> 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 Page N.</t>
<figure anchor="fig-single-fec"> <figure anchor="fig-single-fec">
<name>Example Single Page FEC Encoding</name> <name>Example Single Page FEC Encoding</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
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 700 skipping to change at line 926
| Forward Error Correction | | Forward Error Correction |
| | | |
| | | |
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="dec-single-page" numbered="true" toc="default"> <section anchor="dec-single-page" numbered="true" toc="default">
<name>Decoding</name> <name>Decoding</name>
<t>Frame decoding is independent of the transmit media. However the deco <t>Frame decoding is independent of the transmit media. However, the dec
ding process can determine from the first Authentication page that there may be oding process can determine from the first Authentication page that there may be
a Bluetooth 4.x FEC page at the end. The decoding process MUST test for the pres a Bluetooth 4.x FEC page at the end. The decoding process <bcp14>MUST</bcp14> t
ence of FEC and apply it as follows.</t> est for the presence of FEC and apply it as follows.</t>
<t>To determine if FEC has been used, a check of the <tt>Last Page Index <t>To determine if FEC has been used, a check of the <tt>Last Page Index
</tt> is performed. In general if the <tt>Last Page Index</tt> field is one grea </tt> is performed. In general, if the <tt>Last Page Index</tt> field is one gre
ter than that necessary to hold <tt>Length</tt> octets of Authentication Data th ater than that necessary to hold <tt>Length</tt> octets of Authentication Data,
en FEC has been used. Note that if <tt>Length</tt> octets are exhausted exactly then FEC has been used. Note that if <tt>Length</tt> octets are exhausted exactl
at the end of an Authentication Page, the <tt>Additional Data Length</tt> field y at the end of an Authentication Page, the <tt>Additional Data Length</tt> fiel
will occupy the first octet of the following page. The remainder of this page wi d will occupy the first octet of the following page. The remainder of this page
ll be null padded under DRIP to align the FEC to its own page. In this case the will be null padded under DRIP to align the FEC to its own page. In this case, t
<tt>Last Page Index</tt> will have been incremented once for initializing the <t he <tt>Last Page Index</tt> will have been incremented once for initializing the
t>Additional Data Length</tt> field and once for FEC page, for a total of two ad <tt>Additional Data Length</tt> field and once for the FEC page, for a total of
ditional pages, as in the last row of <xref target="tbl-page-counts" format="def two additional pages, as in the last row of <xref target="tbl-page-counts" form
ault"/>.</t> at="default"/>.</t>
<t>To decode FEC in DRIP, a rolling XOR is used on each <tt>Authenticati <t>To decode FEC in DRIP, a rolling XOR is used on each <tt>Authenticati
on Page</tt> received in the current <tt>Authentication Message</tt>. A Message on Page</tt> received in the current <tt>Authentication Message</tt>. A Message
Counter, outside of the ASTM Message but specified in <xref target="F3411" forma Counter, outside of the ASTM Message but specified in <xref target="F3411" forma
t="default"/>, is used to signal a different <tt>Authentication Message</tt> and t="default"/>, is used to signal a different <tt>Authentication Message</tt> and
to correlate pages to messages. This Message Counter is only single octet in le to correlate pages to messages. This Message Counter is only a single octet in
ngth, so it will roll over (to 0x00) after reaching its maximum value (0xFF). If length, so it will roll over (to 0x00) after reaching its maximum value (0xFF).
only a single page is missing in the <tt>Authentication Message</tt> the result If only a single page is missing in the <tt>Authentication Message</tt> the resu
ing parity octets should be the data of the erased page.</t> lting parity octets should be the data of the erased page.</t>
<t>Authentication Page 0 contains various important fields, only located <t>Authentication Page 0 contains various important fields, only located
on that page, that help decode the full ASTM Authentication Message. If Page 0 on that page, that help decode the full ASTM Authentication Message. If Page 0
has been reconstructed, the <tt>Last Page Index</tt> and <tt>Length</tt> fields has been reconstructed, the <tt>Last Page Index</tt> and <tt>Length</tt> fields
MUST be validated by DRIP. The pseudo-code in <xref target="decode-pseudo" forma <bcp14>MUST</bcp14> be validated by DRIP. The pseudocode in <xref target="decode
t="default"/> can be used for both checks.</t> -pseudo" format="default"/> can be used for both checks.</t>
<figure anchor="decode-pseudo"> <figure anchor="decode-pseudo">
<name>Pseudo-code for Decode Checks</name> <name>Pseudocode for Decode Checks</name>
<sourcecode name="" type="" markers="true"><![CDATA[
<!-- [rfced] Does "LPI" expand to "Locator Preference Indicator"? We would like
to introduce the expansion in the following:
Original (part of <sourcecode>):
// use the presumed ADL to calculate a presumed LPI
-->
<sourcecode name="" type="pseudocode" markers="true"><![CDATA[
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
} }
// check that decoded length does not exceed DRIP maximum value // check that decoded length does not exceed DRIP maximum value
if (decoded_length > 201) { if (decoded_length > 201) {
return DECODE_FAILURE return DECODE_FAILURE
} }
skipping to change at line 745 skipping to change at line 977
presumed_adl = auth_data[last_auth_byte + 1] presumed_adl = auth_data[last_auth_byte + 1]
// use the presumed ADL to calculate a presumed LPI // use the presumed ADL to calculate a presumed LPI
presumed_lpi = (presumed_adl + decoded_length - 17) / 23 presumed_lpi = (presumed_adl + decoded_length - 17) / 23
// check that presumed LPI and decoded LPI match // check that presumed LPI and decoded LPI match
if (presumed_lpi not equal decoded_lpi) { if (presumed_lpi not equal decoded_lpi) {
return DECODE_FAILURE return DECODE_FAILURE
} }
return DECODE_SUCCESS return DECODE_SUCCESS
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="fec-limitations" numbered="true" toc="default"> <section anchor="fec-limitations" numbered="true" toc="default">
<name>FEC Limitations</name> <name>FEC Limitations</name>
<t>The worst-case scenario is when the <tt>Authentication Data / Signatu re</tt> ends perfectly on a page boundary (Page N-1). This means the <tt>Additio nal Data Length</tt> would start the next page (Page N) and have 22 octets worth of null padding to align the FEC to begin at the start of the next page (Page N +1). In this scenario, an entire page (Page N) is being wasted just to carry the <tt>Additional Data Length</tt>.</t> <t>The worst-case scenario is when the <tt>Authentication Data / Signatu re</tt> ends perfectly on a page boundary (Page N-1). This means the <tt>Additio nal Data Length</tt> would start the next page (Page N) and have 22 octets worth of null padding to align the FEC to begin at the start of the next page (Page N +1). In this scenario, an entire page (Page N) is being wasted just to carry the <tt>Additional Data Length</tt>.</t>
</section> </section>
</section> </section>
<section anchor="reqs" numbered="true" toc="default"> <section anchor="reqs" numbered="true" toc="default">
<name>Requirements &amp; Recommendations</name> <name>Requirements and Recommendations</name>
<section anchor="legacy-transports" numbered="true" toc="default"> <section anchor="legacy-transports" numbered="true" toc="default">
<name>Legacy Transports</name> <name>Legacy Transports</name>
<t>Under DRIP, the goal is to attempt to bring reliable receipt of the p <t>Under DRIP, the goal is to bring reliable receipt of the paged Authen
aged Authentication Message using Legacy Transports. FEC (<xref target="fec-deta tication Message using Legacy Transports. FEC (<xref target="fec-details" format
ils" format="default"/>) MUST be used, per mandated RID rules (for example the U ="default"/>) <bcp14>MUST</bcp14> be used, per mandated RID rules (for example,
S FAA RID Rule <xref target="FAA-14CFR" format="default"/>), when using Legacy T the US FAA RID Rules <xref target="FAA-14CFR" format="default"/>), when using Le
ransports (such as Bluetooth 4.x).</t> gacy Transports (such as Bluetooth 4.x).</t>
<t>Under <xref target="F3411" format="default"/>, Authentication Message <t>Under <xref target="F3411" format="default"/>, Authentication Message
s are transmitted at the static rate (at least every 3 seconds). Any DRIP Authen s are transmitted at the static rate (at least every 3 seconds). Any DRIP Authen
tication Messages containing dynamic data (such as the DRIP Wrapper) MAY be sent tication Messages containing dynamic data (such as the DRIP Wrapper) <bcp14>MAY<
at the dynamic rate (at least every 1 second).</t> /bcp14> be sent at the dynamic rate (at least every 1 second).</t>
</section> </section>
<section anchor="extended-transports" numbered="true" toc="default"> <section anchor="extended-transports" numbered="true" toc="default">
<name>Extended Transports</name> <name>Extended Transports</name>
<t>Under the ASTM specification, Extended Transports of RID must use the <t>Under the ASTM specification, Extended Transports of RID must use the
Message Pack (Message Type 0xF) format for all transmissions. Under Message Pac Message Pack (Message Type 0xF) format for all transmissions. Under Message Pac
k, ASTM Messages are sent together (in Message Type order) in a single frame (up k, ASTM Messages are sent together (in Message Type order) in a single frame (up
to 9 single frame equivalent messages under Legacy Transports). Message Packs a to 9 single-frame equivalent messages under Legacy Transports). Message Packs a
re required by <xref target="F3411" format="default"/> to be sent at a rate of 1 re required by <xref target="F3411" format="default"/> to be sent at a rate of 1
per second (like dynamic messages).</t> per second (like dynamic messages).</t>
<t>Message Packs are sent only over Extended Transports that provide FEC <t>Message Packs are sent only over Extended Transports that provide FEC
. Thus, the DRIP decoders will never be presented with a Message Pack from which . Thus, the DRIP decoders will never be presented with a Message Pack from which
a constituent Authentication Page has been dropped; DRIP FEC could never provid a constituent Authentication Page has been dropped; DRIP FEC could never provid
e a benefit to a Message Pack, only consume its precious payload space. Therefor e benefit to a Message Pack, only consume its precious payload space. Therefore,
e, DRIP FEC (<xref target="fec-details" format="default"/>) MUST NOT be used in DRIP FEC (<xref target="fec-details" format="default"/>) <bcp14>MUST NOT</bcp14
Message Packs.</t> > be used in Message Packs.</t>
</section> </section>
<section anchor="drip-recommendations" numbered="true" toc="default"> <section anchor="drip-recommendations" numbered="true" toc="default">
<name>Authentication</name> <name>Authentication</name>
<t>To fulfill the requirements in <xref target="RFC9153" format="default "/>, a UA:</t> <t>To fulfill the requirements in <xref target="RFC9153" format="default "/>, a UA:</t>
<ol spacing="normal" type="1"><li>MUST: send DRIP Link (<xref target="dr <ol spacing="normal" type="1">
ip-link" format="default"/>) using the <tt>BE: Apex, RAA</tt> (partially satisfy <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
ing GEN-3); at least once per 5 minutes. Apex in this context is the DET prefix format="default"/>) using the <tt>BE: Apex, RAA</tt> (partially
owner</li> satisfying GEN-3); at least once per 5 minutes. Apex in this context
<li>MUST: send DRIP Link (<xref target="drip-link" format="default"/>) is the DET prefix owner.</li>
using the <tt>BE: RAA, HDA</tt> (partially satisfying GEN-3); at least once per <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
5 minutes</li> format="default"/>) using the <tt>BE: RAA, HDA</tt> (partially
<li>MUST: send DRIP Link (<xref target="drip-link" format="default"/>) satisfying GEN-3); at least once per 5 minutes.</li>
using the <tt>BE: HDA, UA</tt> (satisfying ID-5, GEN-1 and partially satisfying <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
GEN-3); at least once per minute</li> format="default"/>) using the <tt>BE: HDA, UA</tt> (satisfying ID-5,
<li>MUST: send any other DRIP Authentication Format (non-DRIP Link) wh GEN-1 and partially satisfying GEN-3); at least once per minute.</li>
ere the UA is dynamically signing data that is guaranteed to be unique, unpredic <li><bcp14>MUST</bcp14>: send any other DRIP Authentication Format
table and easily cross checked by the receiving device (satisfying ID-5, GEN-1 a (non-DRIP Link) where the UA is dynamically signing data that is
nd GEN-2); at least once per 5 seconds</li> guaranteed to be unique, unpredictable, and easily cross checked by
the receiving device (satisfying ID-5, GEN-1 and GEN-2); at least
once per 5 seconds.</li>
</ol> </ol>
<t>These four transmission requirements collectively satisfy GEN-3.</t> <t>These four transmission requirements collectively satisfy GEN-3.</t>
</section> </section>
<section anchor="operational-recommendations" numbered="true" toc="default "> <section anchor="operational-recommendations" numbered="true" toc="default ">
<name>Operational</name> <name>Operational</name>
<t>UAS operation may impact the frequency of sending DRIP Authentication <t>UAS operation may impact the frequency of sending DRIP Authentication
messages. When a UA dwells at an approximate location, and the channel is heavi messages. When a UA dwells at an approximate location, and the channel is heavi
ly used by other devices, less frequent message authentication may be effective ly used by other devices, less frequent message authentication may be effective
(to minimize RF packet collisions) for an Observer. Contrast this with a UA tran (to minimize RF packet collisions) for an Observer. Contrast this with a UA tran
siting an area, where authenticated messages SHOULD be sufficiently frequent for siting an area, where authenticated messages <bcp14>SHOULD</bcp14> be sufficient
an Observer to have a high probability of receiving an adequate number for vali ly frequent for an Observer to have a high probability of receiving an adequate
dation during the transit.</t> number for validation during the transit.</t>
<t>A RECOMMENDED operational configuration (in alignment with <xref targ <!-- [rfced] For readability, please consider whether the suggested text correct
et="drip-recommendations" format="default"/>) with reasoning can be found in <xr ly conveys the intended meaning.
ef target="operational-proof" format="default"/>. It consists of the following r
ecommendations for every second:</t> Original:
It consists
of the following recommendations for every second:
Perhaps:
It recommends the following once per second:
-->
<t>A <bcp14>RECOMMENDED</bcp14> operational configuration (in alignment
with <xref target="drip-recommendations" format="default"/>) with rationale can
be found in <xref target="operational-proof" format="default"/>. It consists of
the following recommendations for every second:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Under Legacy Transport: <t>Under Legacy Transport:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Two sets of those ASTM Messages required by a CAA in its juris diction (example: Basic ID, Location and System) and one set of other ASTM Messa ges (example: Self ID, Operator ID)</li> <li>Two sets of those ASTM Messages required by a CAA in its juris diction (example: Basic ID, Location and System) and one set of other ASTM Messa ges (example: Self ID, Operator ID)</li>
<li>An FEC protected DRIP Manifest enabling authentication of thos <li>An FEC-protected DRIP Manifest enabling authentication of thos
e ASTM Messages sent</li> e ASTM Messages sent</li>
<li>A single page of an FEC protected DRIP Link</li> <li>A single page of an FEC-protected DRIP Link</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Under Extended Transport: <t>Under Extended Transport:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper ( per <xref target="extended-wrapper" format="default"/>)</li> <li>A Message Pack of ASTM Messages (up to 4) and a DRIP Wrapper ( per <xref target="extended-wrapper" format="default"/>)</li>
<li>A Message Pack of a DRIP Link</li> <li>A Message Pack of a DRIP Link</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<section anchor="wrapper-operations" numbered="true" toc="default"> <section anchor="wrapper-operations" numbered="true" toc="default">
<name>DRIP Wrapper</name> <name>DRIP Wrapper</name>
<t>If DRIP Wrappers are sent, they MUST be sent in addition to any req <t>If DRIP Wrappers are sent, they <bcp14>MUST</bcp14> be sent in addi
uired ASTM Messages in a given jurisdiction. An implementation MUST NOT send DRI tion to any required ASTM Messages in a given jurisdiction. An implementation <b
P Wrappers in place of any required ASTM Messages it may encapsulate. Thus, mess cp14>MUST NOT</bcp14> send DRIP Wrappers in place of any required ASTM Messages
ages within a Wrapper are sent twice: once in the clear and once authenticated w it may encapsulate. Thus, messages within a Wrapper are sent twice: once in the
ithin the Wrapper.</t> clear and once authenticated within the Wrapper.</t>
<t>The DRIP Wrapper has a specific use case for DRIP aware Observers. <t>The DRIP Wrapper has a specific use case for DRIP-aware Observers.
For an Observer plotting Location Messages (Message Type 0x2) on a map, display For an Observer plotting Location Messages (Message Type 0x2) on a map, display
an embedded Location Message in a DRIP Wrapper can be marked differently (e.g., of an embedded Location Message in a DRIP Wrapper can be marked differently (e.g
via color) to signify trust in the Location data.</t> ., via color) to signify trust in the Location data.</t>
</section> </section>
<section anchor="trust-assessment" numbered="true" toc="default"> <section anchor="trust-assessment" numbered="true" toc="default">
<name>UAS RID Trust Assessment</name> <name>UAS RID Trust Assessment</name>
<t>As described in <xref target="rid-trust" format="default"/>, the Ob <t>As described in <xref target="rid-trust" format="default"/>, the Ob
server MUST perform validation of the data being received in Broadcast RID. This server <bcp14>MUST</bcp14> perform validation of the data being received in Broa
is because trust in a key is different from trust that an observed UA possesses dcast RID. This is because trust in a key is different from trust that an observ
that key.</t> ed UA possesses that key.</t>
<!-- [rfced] We are having trouble parsing this sentence - is there a word
missing after "not predictable"? That is, what is rapidly changing and
unpredictable? Also, should "can be validated by Observers, signed by that key"
be "can be validated by Observers and signed by that key" or otherwise?
Original:
A message containing
rapidly changing, not predictable far in advance (relative to typical
operational flight times) that can be validated by Observers, signed
by that key, provides trust that some agent with access to that data
also possesses that key.
-->
<t>A chain of DRIP Links provides trust in a key. A message containing rapidly changing, not predictable far in advance (relative to typical operation al flight times) that can be validated by Observers, signed by that key, provide s trust that some agent with access to that data also possesses that key. If the validation involves correlating physical world observations of the UA with clai ms in that data, then the probability is high that the observed UA is (or is col laborating with or observed in real time by) the agent with the key.</t> <t>A chain of DRIP Links provides trust in a key. A message containing rapidly changing, not predictable far in advance (relative to typical operation al flight times) that can be validated by Observers, signed by that key, provide s trust that some agent with access to that data also possesses that key. If the validation involves correlating physical world observations of the UA with clai ms in that data, then the probability is high that the observed UA is (or is col laborating with or observed in real time by) the agent with the key.</t>
<t>After signature verification of any DRIP Authentication Message con <t>After signature verification of any DRIP Authentication Message con
taining UAS RID information elements (e.g., DRIP Wrapper <xref target="drip-wrap taining UAS RID information elements (e.g., DRIP Wrapper <xref target="drip-wrap
per" format="default"/>) the Observer MUST use other sources of information to c per" format="default"/>) the Observer <bcp14>MUST</bcp14> use other sources of i
orrelate against and perform validation. An example of another source of informa nformation to correlate against and perform validation. An example of another so
tion is a visual confirmation of the UA position.</t> urce of information is a visual confirmation of the UA position.</t>
<t>When correlation of these different data streams does not match in <t>When correlation of these different data streams does not match in
acceptable thresholds, the data MUST be rejected as if the signature failed to v acceptable thresholds, the data <bcp14>MUST</bcp14> be rejected as if the signat
alidate. Acceptable thresholds limits and what happens after such a rejection ar ure failed to validate. Acceptable threshold limits and what happens after such
e out of scope for this document.</t> a rejection are out of scope for this document.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="req-sum" numbered="true" toc="default"> <section anchor="req-sum" numbered="true" toc="default">
<name>Summary of Addressed DRIP Requirements</name> <name>Summary of Addressed DRIP Requirements</name>
<t>The following <xref target="RFC9153" format="default"/> requirements ar <t>The following requirements as defined in <xref target="RFC9153" format=
e addressed in this document:</t> "default"/> are addressed in this document:</t>
<t>ID-5: Non-spoofability</t> <dl>
<ul empty="true" spacing="normal"> <dt>ID-5:</dt><dd><t>Non-spoofability</t>
<li>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format <t>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format=
="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) o "default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>), o
r DRIP Frame (<xref target="drip-frame" format="default"/>).</li> r DRIP Frame (<xref target="drip-frame" format="default"/>).</t></dd>
</ul>
<t>GEN-1: Provable Ownership</t> <dt>GEN-1:</dt><dd><t>Provable Ownership</t>
<ul empty="true" spacing="normal">
<li>Addressed using the DRIP Link (<xref target="drip-link" format="defa <t>Addressed using the DRIP Link (<xref target="drip-link" format="defau
ult"/>) and DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP lt"/>) and DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP M
Manifest (<xref target="drip-manifest" format="default"/>) or DRIP Frame (<xref anifest (<xref target="drip-manifest" format="default"/>), or DRIP Frame (<xref
target="drip-frame" format="default"/>).</li> target="drip-frame" format="default"/>).</t></dd>
</ul>
<t>GEN-2: Provable Binding</t> <dt>GEN-2:</dt><dd><t>Provable Binding</t>
<ul empty="true" spacing="normal"> <t>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format=
<li>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format "default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) or
="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) o DRIP Frame (<xref target="drip-frame" format="default"/>).</t></dd>
r DRIP Frame (<xref target="drip-frame" format="default"/>).</li>
</ul> <dt>GEN-3:</dt><dd><t>Provable Registration</t>
<t>GEN-3: Provable Registration</t> <t>Addressed using the DRIP Link (<xref target="drip-link" format="defau
<ul empty="true" spacing="normal"> lt"/>).</t></dd></dl>
<li>Addressed using the DRIP Link (<xref target="drip-link" format="defa
ult"/>).</li>
</ul>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="iana-drip-registry" numbered="true" toc="default"> <section anchor="iana-drip-registry" numbered="true" toc="default">
<name>IANA DRIP Registry</name> <name>IANA DRIP Registry</name>
<t>This document requests two new registries, for DRIP SAM Type and DRIP <t>IANA has created the "DRIP SAM Types" and "DRIP Frame Types" registri
Frame Type, under the <eref target="https://www.iana.org/assignments/drip/drip. es within the <eref target="https://www.iana.org/assignments/drip">"Drone Remote
xhtml">DRIP registry group</eref>.</t> ID Protocol" registry group</eref>.</t>
<dl newline="false" spacing="normal"> <dl newline="true" spacing="normal">
<dt>DRIP SAM Type:</dt> <dt>DRIP SAM Types:</dt>
<dd> <dd><t>This registry is a mirror for SAM Types containing the subset o
This registry is a mirror for SAM Types containing the subset of allocations u f
sed by DRIP Authentication Messages. Future additions MUST be done through ASTM' allocations used by DRIP Authentication Messages. Future additions
s designated registrar which at the time of publication of this RFC is ICAO <xre <bcp14>MUST</bcp14> be done through ASTM's designated registrar,
f target="ASTM-Remote-ID" format="default"/>. Additions for DRIP will be coordin which is ICAO <xref target="ASTM-Remote-ID" format="default"/> at the
ated by IANA and the ASTM designated registrar before final publication as Stand time of publication of this RFC.
ards Track RFCs. The following values have been allocated to the IETF and are de <!-- [rfced] This text seems to indicate that the registration procedure
fined here:</dd> is Standards Action - should this be called out for clarity? In addition,
</dl> may we update the text as follows, as we believe "additions" refers to
registration requests.
Original:
Additions for DRIP will be coordinated by IANA
and the ASTM designated registrar before final publication as
Standards Track RFCs.
Option A:
The registration procedure is Standards Action [RFC8126]. Requests for
new registrations will be coordinated by IANA and the ASTM-designated
registrar before being documented in Standards Track RFCs.
Option B:
IANA will coordinate with the ASTM-designated registrar before
additions to the "DRIP SAM Types" are documented in Standards Track RFCs.
-->
Additions for DRIP will
be coordinated by IANA and the ASTM designated registrar before
final publication as Standards Track RFCs. The following values have
been allocated to the IETF:</t>
<table align="center"> <table align="center">
<name>DRIP SAM Types</name> <name>DRIP SAM Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">SAM Type</th> <th align="left">SAM Type</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 874 skipping to change at line 1164
<td align="left">0x03</td> <td align="left">0x03</td>
<td align="left">DRIP Manifest</td> <td align="left">DRIP Manifest</td>
<td align="left">Authenticate hashes of ASTM Messages</td> <td align="left">Authenticate hashes of ASTM Messages</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x04</td> <td align="left">0x04</td>
<td align="left">DRIP Frame</td> <td align="left">DRIP Frame</td>
<td align="left">Format for future DRIP authentication</td> <td align="left">Format for future DRIP authentication</td>
</tr> </tr>
</tbody> </tbody>
</table> </table></dd>
<dl newline="false" spacing="normal">
<dt>DRIP Frame Type:</dt> <dt>DRIP Frame Types:</dt>
<dd> <dd><t>This 8-bit value registry is for Frame Types in DRIP Frame
This 8-bit valued registry is for Frame Types in DRIP Frame Authentication Mes Authentication Messages. Future additions to this registry are to be
sages. Future additions to this registry are to be made through Expert Review (S made through Expert Review (<xref target="RFC8126"
ection 4.5 of <xref target="RFC8126" format="default"/>) for the values of 0x01 sectionFormat="of" section="4.5"/>) for values 0x01 to 0x9F
to 0x9F and First Come, First Served (Section 4.4 of <xref target="RFC8126" form and First Come First Served (<xref target="RFC8126"
at="default"/>) for values 0xA0 to 0xEF. The following values are defined:</dd> sectionFormat="of" section="4.4"/>) for values 0xA0 to 0xEF. The
</dl> following values are defined:</t>
<table align="center"> <table align="center">
<name>DRIP Frame Types</name> <name>DRIP Frame Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Frame Type</th> <th align="left">Frame Type</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x00</td> <td align="left">0x00</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x01 - 0x9F</td> <td align="left">0x01 - 0xEF</td>
<td align="left">Reserved</td> <td align="left">Unassigned</td>
<td align="left">Reserved: Expert Review</td> <td align="left"></td>
</tr>
<tr>
<td align="left">0xA0 - 0xEF</td>
<td align="left">Reserved</td>
<td align="left">Reserved: First Come, First Served</td>
</tr>
<tr>
<td align="left">0xF0 - 0xFF</td>
<td align="left">Experimental</td>
<td align="left">Experimental Use</td>
</tr> </tr>
<tr>
<td align="left">0xF0-0xFF</td>
<td align="left">Experimental</td>
<td align="left">Reserved for Experimental Use</td>
</tr>
</tbody> </tbody>
</table> </table>
</dd></dl>
<t>Criteria that should be applied by the designated experts includes de termining whether the proposed registration duplicates existing functionality an d whether the registration description is clear and fits the purpose of this reg istry.</t> <t>Criteria that should be applied by the designated experts includes de termining whether the proposed registration duplicates existing functionality an d whether the registration description is clear and fits the purpose of this reg istry.</t>
<t>Registration requests MUST be sent to <eref target="mailto:drip-reg-r eview@ietf.org">drip-reg-review@ietf.org</eref> and be evaluated within a three- week review period on the advice of one or more designated experts. Within that review period, the designated experts will either approve or deny the registrati on request, and communicate their decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions to successfully re gister the DRIP Frame Type.</t> <t>Registration requests <bcp14>MUST</bcp14> be sent to <eref target="ma ilto:drip-reg-review@ietf.org">drip-reg-review@ietf.org</eref> and be evaluated by one or more designated experts within a three-week review period. Within that review period, the designated experts will either approve or deny the registrat ion request, and communicate their decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions to successfully r egister the DRIP Frame Type.</t>
<t>Registration requests that are undetermined for a period longer than 28 days can be brought to the IESG's attention for resolution.</t> <t>Registration requests that are undetermined for a period longer than 28 days can be brought to the IESG's attention for resolution.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="replay-attacks" numbered="true" toc="default"> <section anchor="replay-attacks" numbered="true" toc="default">
<name>Replay Attacks</name> <name>Replay Attacks</name>
<t><xref target="F3411" format="default"/> (regardless of transport) lac <t><xref target="F3411" format="default"/> (regardless of transport) lac
ks replay protection, as it more fundamentally lacks fully specified authenticat ks replay protection, as it more fundamentally lacks fully specified authenticat
ion. An attacker can spoof the UA sender MAC address and UAS ID, replaying (with ion. An attacker can spoof the UA sender MAC address and UAS ID, replaying (with
or without modification) previous genuine messages, and/or crafting entirely ne or without modification) previous genuine messages, and/or crafting entirely ne
w messages. Using DRIP in <xref target="F3411" format="default"/> Authentication w messages. Using DRIP in <xref target="F3411" format="default"/> Authentication
message framing enables verification that messages were signed with registered message framing enables verification that messages were signed with registered
keys, but when naively used may be vulnerable to replay attacks. Technologies su keys, but when naively used may be vulnerable to replay attacks. Technologies su
ch as Single Emitter Identification can detect such attacks, but are not readily ch as Single Emitter Identification can detect such attacks, but they are not re
available and can be prohibitively expensive, especially for typical Observer d adily available and can be prohibitively expensive, especially for typical Obser
evices such as smartphones.</t> ver devices such as smartphones.</t>
<t>Replay attack detection using DRIP requires Observer devices to combi <!-- [rfced] We are having trouble parsing this sentence. Please review.
ne information from multiple messages and sources other than Broadcast RID. A co
mplete chain of Link messages (<xref target="drip-link" format="default"/>), fro Original:
m an Endorsement root of trust to the claimed sender, must be collected and veri Successful signature verification, using that key, of a Wrapper
fied by the Observer device to provide trust in a key. Successful signature veri (Section 4.3) or Manifest (Section 4.4) message, authenticating
fication, using that key, of a Wrapper (<xref target="drip-wrapper" format="defa content that is nonce-like, provides trust that the sender actually
ult"/>) or Manifest (<xref target="drip-manifest" format="default"/>) message, a possesses that key.
uthenticating content that is nonce-like, provides trust that the sender actuall
y possesses that key.</t> Perhaps:
<t>By "nonce-like" is meant data that is unique, not accurately predicta Using that key, successful signature verification of a Wrapper
ble long in advance, and readily validated by the Observer. This is described in (Section 4.3) or Manifest (Section 4.4) message and authentication of
<xref target="drip-recommendations" format="default"/> (requirement 4) and <xre content that is nonce-like provides trust that the sender actually
f target="ua-attestation" format="default"/>. The <xref target="F3411" format="d possesses that key.
efault"/> Location message reporting precise UA position and velocity at a preci -->
se very recent time, to be checked by the Observer against visual observations o
f the UA within RF and thus typically visual Line Of Sight is the recommended fo <t>Replay attack detection using DRIP requires Observer devices to combi
rm of this data. For specification of the foregoing, see <xref target="rid-trust ne information from multiple messages and sources other than Broadcast RID. A co
" format="default"/> and <xref target="trust-assessment" format="default"/>.</t> mplete chain of Link messages (<xref target="drip-link" format="default"/>) from
<t>Messages that pass signature verification with trusted keys could sti an Endorsement root of trust to the claimed sender must be collected and verifi
ll be replays if they contain only static information (e.g., Broadcast Endorseme ed by the Observer device to provide trust in a key. Successful signature verifi
nts (<xref target="drip-link" format="default"/>), <xref target="F3411" format=" cation, using that key, of a Wrapper (<xref target="drip-wrapper" format="defaul
default"/> Basic ID or <xref target="F3411" format="default"/> Operator ID) or i t"/>) or Manifest (<xref target="drip-manifest" format="default"/>) message, aut
nformation that cannot be readily validated (e.g., <xref target="F3411" format=" henticating content that is nonce-like, provides trust that the sender actually
default"/> Self-ID). Replay of Link messages is harmless (unless sent so frequen possesses that key.</t>
tly as to cause RF data link congestion) and indeed can increase the likelihood <!--[rfced] We see that "nonce-like" is also defined in RFC 9434. Would
of an Observer device collecting an entire trust chain in a short time window. R you like to update the definition here to more closely match RFC 9434?
eplay of other messages (<xref target="F3411" format="default"/> Basic ID, <xref
target="F3411" format="default"/> Operator ID, or <xref target="F3411" format=" Current text:
default"/> Self-ID) remains a vulnerability, unless they are combined with messa The term "nonce-like" means the that data is unique, not accurately
ges containing nonce-like data (<xref target="F3411" format="default"/> Location predictable long in advance, and readily validated by the Observer.
or <xref target="F3411" format="default"/> System) in a Wrapper or Manifest. Fo
r specification of this last requirement, see <xref target="block-hashes" format RFC 9434:
="default"/>.</t> The term "nonce-like" describes data that is readily
available to the prover and the verifier, changes frequently, is not
predictable by the prover, and can be checked quickly at low
computational cost by the verifier; a Location/Vector message is an
obvious choice.
-->
<t>The term "nonce-like" means the that data is unique, not accurately p
redictable long in advance, and readily validated by the Observer. This is descr
ibed in <xref target="drip-recommendations" format="default"/> (requirement 4) a
nd <xref target="ua-attestation" format="default"/>. The Location message <xref
target="F3411" format="default"/> reporting precise UA position and velocity at
a precise and very recent time is to be checked by the Observer against visual o
bservations of the UA within RF. Thus, Visual Line of Sight is typically the rec
ommended form of this data. For specification of the foregoing, see Sections <xr
ef target="rid-trust" format="counter"/> and <xref target="trust-assessment" for
mat="counter"/>.</t>
<t>Messages that pass signature verification with trusted keys could sti
ll be replays if they contain only static information (e.g., Broadcast Endorseme
nts (<xref target="drip-link" format="default"/>), <xref target="F3411" format="
default"/> Basic ID or <xref target="F3411" format="default"/> Operator ID), or
information that cannot be readily validated (e.g., <xref target="F3411" format=
"default"/> Self-ID). Replay of Link messages is harmless (unless sent so freque
ntly as to cause RF data link congestion) and indeed can increase the likelihood
of an Observer device collecting an entire trust chain in a short time window.
Replay of other messages (<xref target="F3411" format="default"/> Basic ID, <xre
f target="F3411" format="default"/> Operator ID, or <xref target="F3411" format=
"default"/> Self-ID) remains a vulnerability, unless they are combined with mess
ages containing nonce-like data (<xref target="F3411" format="default"/> Locatio
n or <xref target="F3411" format="default"/> System) in a Wrapper or Manifest. F
or specification of this last requirement, see <xref target="block-hashes" forma
t="default"/>.</t>
</section> </section>
<section anchor="wrapper-vs-manifest" numbered="true" toc="default"> <section anchor="wrapper-vs-manifest" numbered="true" toc="default">
<name>Wrapper vs Manifest</name> <name>Wrapper vs Manifest</name>
<t>Implementations have a choice on using Wrapper (<xref target="drip-wr <t>Implementations have a choice of using Wrapper (<xref target="drip-wr
apper" format="default"/>), Manifest (<xref target="drip-manifest" format="defau apper" format="default"/>), Manifest (<xref target="drip-manifest" format="defau
lt"/>), or a combination to satisfy the 4th requirement in <xref target="drip-re lt"/>), or a combination to satisfy the fourth requirement in <xref target="drip
commendations" format="default"/>.</t> -recommendations" format="default"/>.</t>
<t>Wrapper is an attached signature of the full content of one or more < <!-- [rfced] For readability, may we update this sentence as follows?
xref target="F3411" format="default"/> messages, providing strong authentication
. However, the size limitation means it can not support such signatures over oth Original:
er Authentication Messages, thus it can not provide a direct binding to any part Wrapper is an attached signature of the full content of one or more
of the trust chain (<xref target="rid-trust" format="default"/> and <xref targe [F3411] messages, providing strong authentication.
t="trust-assessment" format="default"/>).</t>
<t>Manifest explicitly provides the binding of the last link in the trus Perhaps:
t chain (with the inclusion of the hash of the Link containing <tt>BE: HDA, UA</ Wrapper is a signature attached to the full content of one or more
tt>). The use of hashes and their length also allows for a larger (11 vs 4) numb [F3411] messages, which provides strong authentication.
er of any <xref target="F3411" format="default"/> messages to be authenticated, -->
making it more efficient compared to the Wrapper. However, the detached signatur
e requires additional Observer overhead in storing and comparing hashes of recei <t>Wrapper is an attached signature of the full content of one or more <
ved messages (some that may not be received) of those in a Manifest.</t> xref target="F3411" format="default"/> messages, providing strong authentication
<t><xref target="operational-proof" format="default"/> contains a breakd . However, the size limitation means it cannot support such signatures over othe
own of frame counts and an example of a schedule using both Manifest and Wrapper r Authentication Messages; thus, it cannot provide a direct binding to any part
. Typical operation may see (as an example) 2x Basic ID, 2x Location, 2x System, of the trust chain (Sections <xref target="rid-trust" format="counter"/> and <xr
1x Operator ID and 1x Self ID broadcast per second to comply with jurisdiction ef target="trust-assessment" format="counter"/>).</t>
mandates. Each of these messages are a single frame in size. A Link message is 8 <t>Manifest explicitly provides the binding of the last link in the trus
frames long (including FEC). This is a base frame count of <strong>16 frames</s t chain (with the inclusion of the hash of the Link containing <tt>BE: HDA, UA</
trong>.</t> tt>). The use of hashes and their length also allows for a larger number (11 vs
<t>When Wrapper is used, up to 4 of the previous messages (except the Li 4) of <xref target="F3411" format="default"/> messages to be authenticated, maki
nk) can be authenticated. For this comparison, we will sign all the messages we ng it more efficient compared to the Wrapper. However, the detached signature re
can in two Wrappers. This results in <em>20 frames</em> (with FEC). Due to not b quires additional Observer overhead in storing and comparing hashes of received
eing able to fit, the Link message is left unauthenticated. The total frame coun messages (some of which may not be received) with those in a Manifest.</t>
t using Wrappers is <strong>36 frames</strong> (wrapper frame count + base frame <t><xref target="operational-proof" format="default"/> contains a breakd
count).</t> own of frame counts and an example of a schedule using both Manifest and Wrapper
<t>When Manifest is used, up to 10 previous messages can be authenticate . Typical operation may see (as an example) 2x Basic ID, 2x Location, 2x System,
d. For this example all messages (8) are hashed (including the Link) resulting i 1x Operator ID and 1x Self ID broadcast per second to comply with jurisdiction
n a single Manifest that is <em>9 frames</em> (with FEC). The total frame count mandates. Each of these messages is a single frame in size. A Link message is 8
using Manifest is <strong>25 frames</strong> (manifest frame count + base frame frames long (including FEC). This is a base frame count of <strong>16 frames</st
count).</t> rong>.</t>
<t>When Wrapper is used, up to four of the previous messages (except the
Link) can be authenticated. For this comparison, we will sign all the messages
we can in two Wrappers. This results in <em>20 frames</em> (with FEC). Due to si
ze constraints, the Link message is left unauthenticated. The total frame count
using Wrappers is <strong>36 frames</strong> (wrapper frame count + base frame c
ount).</t>
<t>When Manifest is used, up to 10 previous messages can be authenticate
d. For this example, all messages (8) are hashed (including the Link) resulting
in a single Manifest that is <em>9 frames</em> (with FEC). The total frame count
using Manifest is <strong>25 frames</strong> (manifest frame count + base frame
count).</t>
</section> </section>
<section anchor="vna-timestamp-offsets-for-drip-authentication-formats" nu mbered="true" toc="default"> <section anchor="vna-timestamp-offsets-for-drip-authentication-formats" nu mbered="true" toc="default">
<name>VNA Timestamp Offsets for DRIP Authentication Formats</name> <name>VNA Timestamp Offsets for DRIP Authentication Formats</name>
<t>Note the discussion of VNA Timestamp offsets here is in the context o <t>Note the discussion of VNA Timestamp offsets here is in the context o
f the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manife f the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manife
st (<xref target="drip-manifest" format="default"/>), and DRIP Frame (<xref targ st (<xref target="drip-manifest" format="default"/>), and DRIP Frame (<xref targ
et="drip-frame" format="default"/>). For DRIP Link (<xref target="drip-link" for et="drip-frame" format="default"/>). For DRIP Link (<xref target="drip-link" for
mat="default"/>) these offsets are set by the DIME and have their own set of con mat="default"/>), these offsets are set by the DIME and have their own set of co
siderations in <xref target="drip-registries" format="default"/>.</t> nsiderations in <xref target="I-D.ietf-drip-registries" format="default"/>.</t>
<t>The offset of the <tt>VNA Timestamp by UA</tt> is one that needs care <t>The offset of the <tt>VNA Timestamp by UA</tt> is one that needs care
ful consideration for any implementation. The offset should be shorter than any ful consideration for any implementation. The offset should be shorter than any
given flight duration (typically less than an hour) but be long enough to be rec given flight duration (typically less than an hour) but be long enough to be rec
eived and processed by Observers (larger than a few seconds). It is recommended eived and processed by Observers (larger than a few seconds). It is recommended
that 3-5 minutes should be sufficient to serve this purpose in any scenario, but that 3-5 minutes should be sufficient to serve this purpose in any scenario, but
is not limited by design.</t> it is not limited by design.</t>
</section> </section>
<section anchor="dns-security" numbered="true" toc="default"> <section anchor="dns-security" numbered="true" toc="default">
<name>DNS Security in DRIP</name> <name>DNS Security in DRIP</name>
<t>As stated in <xref target="protocol-desc" format="default"/> specific <!-- [rfced] We are having trouble parsing "specify DRIP usage of best common pr
ation of particular DNS security options, transports, etc. is outside the scope actices". Please consider whether the suggested update accurately conveys the i
of this document. <xref target="drip-registries" format="default"/> is the main ntended meaning.
specification for DNS operations in DRIP and as such will specify DRIP usage of
best common practices for security (such as <xref target="RFC9364" format="defau Original:
lt"/>).</t> [drip-registries] is the main specification for DNS operations in
DRIP and as such will specify DRIP usage of best common practices for
security (such as [RFC9364]).
Perhaps:
The main specification for DNS operations in
DRIP [drip-registries] will specify the best common security practices
(e.g., [RFC9364]) for DRIP usage of best common practices for
security.
-->
<t>As stated in <xref target="protocol-desc" format="default"/> specific
ation of particular DNS security options, transports, etc. is outside the scope
of this document. <xref target="I-D.ietf-drip-registries" format="default"/> is
the main specification for DNS operations in DRIP and as such will specify DRIP
usage of best common practices for security (such as <xref target="RFC9364" form
at="default"/>).</t>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="true" toc="default"> <section anchor="acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<!-- [rfced] Please consider adding lead-in text to the Acknowledgements section
. For example, "The authors would like the acknowledge the following individual
s:". If this is acceptable, we would also like to start a new list of individua
ls after "Thanks to the following reviewers." For example:
...
* Eric Vyncke (DRIP AD) for his guidance through the documents path
to publication
The authors also thank the following document reviewers:
- Rick Salz (secdir)
...
-->
<ul spacing="normal"> <ul spacing="normal">
<li>Ryan Quigley, James Mussi and Joseph Stanton of AX Enterprize, LLC f <li><t><contact fullname="Ryan Quigley"/>, <contact fullname="James
or early prototyping to find holes in the draft specifications</li> Mussi"/>, and <contact fullname="Joseph Stanton"/> of AX Enterprize,
<li>Carsten Bormann for the simple approach of using bit-column-wise par LLC for early prototyping to find holes in earlier drafts of this
ity for erasure (dropped frame) FEC</li> specification</t></li>
<li>Soren Friis for pointing out that Wi-Fi implementations would not al <li><t><contact fullname="Carsten Bormann"/> for the simple approach of
ways give access to the MAC Address, originally used in calculation of the hashe using bit-column-wise
s for DRIP Manifest. Also, for confirming that Message Packs (0xF) can only carr parity for erasure (dropped frame) FEC</t></li>
y up to 9 ASTM frames worth of data (9 Authentication pages)</li> <li><t><contact fullname="Soren Friis"/> for pointing out that Wi-Fi imp
<li>Gabriel Cox (chair of the working group that produced <xref target=" lementations would not always give access to the MAC Address, as was originally
F3411" format="default"/>) in reviewing the specification for the SAM Type reque used in calculation of the hashes for DRIP Manifest. Also, for confirming that M
st as the ASTM Designated Expert</li> essage Packs (0xF) can only carry up to 9 ASTM frames worth of data (9 Authentic
<li>Mohamed Boucadair (Document Shepherd) for his many patches and comme ation pages)</t></li>
nts</li> <li><t><contact fullname="Gabriel Cox"/> (chair of the working group tha
<li>Eric Vyncke (DRIP AD) for his guidance through the documents path to t produced <xref target="F3411" format="default"/>) for reviewing the specificat
publication</li> ion for the SAM Type request as the ASTM Designated Expert</t></li>
<li><t><contact fullname="Mohamed Boucadair"/> (Document Shepherd) for h
is many patches and comments</t></li>
<li><t><contact fullname="Eric Vyncke"/> (DRIP AD) for his guidance rega
rding the document's path to publication</t></li>
<li> <li>
<t>Thanks to the following reviewers: <t>Thanks to the following reviewers:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Rick Salz (secdir)</li> <li><t><contact fullname="Rick Salz (secdir)"/></t></li>
<li>Matt Joras (genart)</li> <li><t><contact fullname="Matt Joras (genart)"/></t></li>
<li>Di Ma (dnsdir)</li> <li><t><contact fullname="Di Ma (dnsdir)"/></t></li>
<li>Gorry Fairhurst (tsvart)</li> <li><t><contact fullname="Gorry Fairhurst (tsvart)"/></t></li>
<li>Carlos Bernardos (intdir)</li> <li><t><contact fullname="Carlos Bernardos (intdir)"/></t></li>
<li>Behcet Sarikaya (iotdir)</li> <li><t><contact fullname="Behcet Sarikaya (iotdir)"/></t></li>
<li>Martin Duke (IESG)</li> <li><t><contact fullname="Martin Duke (IESG)"/></t></li>
<li>Roman Danyliw (IESG)</li> <li><t><contact fullname="Roman Danyliw (IESG)"/></t></li>
<li>Murray Kucherawy (IESG)</li> <li><t><contact fullname="Murray Kucherawy (IESG)"/></t></li>
<li>Erik Kline (IESG)</li> <li><t><contact fullname="Erik Kline (IESG)"/></t></li>
<li>Warren Kumari (IESG)</li> <li><t><contact fullname="Warren Kumari (IESG)"/></t></li>
<li>Paul Wouters (IESG)</li> <li><t><contact fullname="Paul Wouters (IESG)"/></t></li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-drip-registries" to="DRIP-REG"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9153" target="https://www.rfc-editor.org/info/rfc9
153"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<front> 53.xml"/>
<title>Drone Remote Identification Protocol (DRIP) Requirements and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
Terminology</title> 74.xml"/>
<author fullname="S. Card" initials="S." role="editor" surname="Card <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
"/> 34.xml"/>
<author fullname="A. Wiethuechter" initials="A." surname="Wiethuecht
er"/>
<author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
<author fullname="A. Gurtov" initials="A." surname="Gurtov"/>
<date month="February" year="2022"/>
<abstract>
<t>This document defines terminology and requirements for solution
s produced by the Drone Remote Identification Protocol (DRIP) Working Group. The
se solutions will support Unmanned Aircraft System Remote Identification and tra
cking (UAS RID) for security, safety, and other purposes (e.g., initiation of id
entity-based network sessions supporting UAS applications). DRIP will facilitate
use of existing Internet resources to support RID and to enable enhanced relate
d services, and it will enable online and offline verification that RID informat
ion is trustworthy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9153"/>
<seriesInfo name="DOI" value="10.17487/RFC9153"/>
</reference>
<reference anchor="RFC9374" target="https://www.rfc-editor.org/info/rfc9
374">
<front>
<title>DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID
(UAS RID)</title>
<author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
<author fullname="S. Card" initials="S." surname="Card"/>
<author fullname="A. Wiethuechter" initials="A." surname="Wiethuecht
er"/>
<author fullname="A. Gurtov" initials="A." surname="Gurtov"/>
<date month="March" year="2023"/>
<abstract>
<t>This document describes the use of Hierarchical Host Identity T
ags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identif
iers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tra
cking.</t>
<t>Within the context of RID, HHITs will be called DRIP Entity Tag
s (DETs). HHITs provide claims to the included explicit hierarchy that provides
registry (via, for example, DNS, RDAP) discovery for third-party identifier endo
rsement.</t>
<t>This document updates RFCs 7401 and 7343.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9374"/>
<seriesInfo name="DOI" value="10.17487/RFC9374"/>
</reference>
<reference anchor="RFC9434" target="https://www.rfc-editor.org/info/rfc9
434">
<front>
<title>Drone Remote Identification Protocol (DRIP) Architecture</tit
le>
<author fullname="S. Card" initials="S." surname="Card"/>
<author fullname="A. Wiethuechter" initials="A." surname="Wiethuecht
er"/>
<author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
<author fullname="S. Zhao" initials="S." role="editor" surname="Zhao
"/>
<author fullname="A. Gurtov" initials="A." surname="Gurtov"/>
<date month="July" year="2023"/>
<abstract>
<t>This document describes an architecture for protocols and servi
ces to support Unmanned Aircraft System Remote Identification and tracking (UAS
RID), plus UAS-RID-related communications. This architecture adheres to the requ
irements listed in the Drone Remote Identification Protocol (DRIP) Requirements
document (RFC 9153).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9434"/>
<seriesInfo name="DOI" value="10.17487/RFC9434"/>
</reference>
<reference anchor="F3411" target="https://www.astm.org/f3411-22a.html"> <reference anchor="F3411" target="https://www.astm.org/f3411-22a.html">
<front> <front>
<title>Standard Specification for Remote ID and Tracking</title> <title>Standard Specification for Remote ID and Tracking</title>
<author> <author>
<organization>ASTM International</organization> <organization>ASTM International</organization>
</author> </author>
<date year="2022" month="July"/> <date year="2022" month="July"/>
</front> </front>
<seriesInfo name="ASTM" value="F3411-22A"/> <seriesInfo name="ASTM" value="F3411-22A"/>
<seriesInfo name="DOI" value="10.1520/F3411-22A"/> <seriesInfo name="DOI" value="10.1520/F3411-22A"/>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
le> 74.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.800-185.pdf"> <reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.800-185.pdf">
<front> <front>
<title>SHA-3 derived functions: cSHAKE, KMAC, TupleHash and Parallel <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and Parallel
Hash</title> Hash</title>
<author fullname="John Kelsey" surname="Kelsey"> <author fullname="John Kelsey" surname="Kelsey"/>
<organization>Information Technology Laboratory</organization> <author fullname="Shu-jen Chang" surname="Chang"/>
</author> <author fullname="Ray Perlner" surname="Perlner"/>
<author fullname="Shu-jen Change" surname="Change"> <date month="December" year="2016"/>
<organization>Information Technology Laboratory</organization>
</author>
<author fullname="Ray Perlner" surname="Perlner">
<organization>Information Technology Laboratory</organization>
</author>
<author>
<organization abbrev="NIST">National Institute of Standards and Te
chnology</organization>
<address>
<postal>
<country>US</country>
<city>Gaithersburg</city>
</postal>
</address>
</author>
<date month="December" year="2016"/>
</front> </front>
<seriesInfo name="NIST Special Publications (General)" value="800-185" /> <seriesInfo name="NIST Special Publication" value="800-185"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="drip-registries" target="https://datatracker.ietf.org
/doc/html/draft-ietf-drip-registries-14">
<front>
<title>DRIP Entity Tag (DET) Identity Management Architecture</title
>
<author fullname="Adam Wiethuechter" initials="A." surname="Wiethuec
hter">
<organization>AX Enterprize, LLC</organization>
</author>
<author fullname="Jim Reid" initials="J." surname="Reid">
<organization>RTFM llp</organization>
</author>
<date day="4" month="December" year="2023"/>
<abstract>
<t> This document describes the high level architecture for the
registration and discovery of DRIP Entity Tags (DETs) using DNS.
Discovery of DETs and their artifacts are through DRIP specific DNS
structures and standard DNS methods. A general overview of the
interfaces required between involved components is described in this
document with future supporting documents giving technical
specifications.
</t> <!-- [rfced] [I-D.ietf-drip-registries] IESG State: I-D Exists -->
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
</front> etf-drip-registries.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-drip-registries-14
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
</reference> 26.xml"/>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
126"> 64.xml"/>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9
364">
<front>
<title>DNS Security Extensions (DNSSEC)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2023"/>
<abstract>
<t>This document describes the DNS Security Extensions (commonly c
alled "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a ha
ndful of others. One purpose is to introduce all of the RFCs in one place so tha
t the reader can understand the many aspects of DNSSEC. This document does not u
pdate any of those RFCs. A second purpose is to state that using DNSSEC for orig
in authentication of DNS data is the best current practice. A third purpose is t
o provide a single reference for other documents that want to refer to DNSSEC.</
t>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
<reference anchor="FAA-14CFR" target="https://www.govinfo.gov/content/pk g/FR-2021-01-15/pdf/2020-28948.pdf"> <reference anchor="FAA-14CFR" target="https://www.govinfo.gov/content/pk g/FR-2021-01-15/pdf/2020-28948.pdf">
<front> <front>
<title>Remote Identification of Unmanned Aircraft</title> <title>Remote Identification of Unmanned Aircraft</title>
<author> <author>
<organization/> <organization>Federal Aviation Administration (FAA)</organization>
</author> </author>
<date year="2021" month="January"/> <date year="2021" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="ASTM-Remote-ID" target="https://www.icao.int/airnavig ation/IATF/Pages/ASTM-Remote-ID.aspx"> <reference anchor="ASTM-Remote-ID" target="https://www.icao.int/airnavig ation/IATF/Pages/ASTM-Remote-ID.aspx">
<front> <front>
<title>ICAO Remote ID Number Registration</title> <title>Remote ID Number Registration</title>
<author> <author>
<organization/> <organization>International Civil Aviation Organization (ICAO)</or
</author> ganization>
</author>
<date year="2023" month="December"/> <date year="2023" month="December"/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="auth-state-diagrams" numbered="true" toc="default"> <section anchor="auth-state-diagrams" numbered="true" toc="default">
<name>Authentication States</name> <name>Authentication States</name>
<t>ASTM Authentication has only three states: None, Invalid, and Valid. Th <t>ASTM Authentication has only three states: None, Invalid, and Valid. Th
is is because, under ASTM, the authentication is done by an external service hos is is because, under ASTM, the authentication is done by an external service hos
ted somewhere on the Internet so it is assumed an authoritative response will al ted somewhere on the Internet so it is assumed an authoritative response will al
ways be returned. This classification becomes more complex in DRIP with the supp ways be returned. This classification becomes more complex in DRIP with the supp
ort of "offline" scenarios where a Observer does not have Internet connectivity. ort of "offline" scenarios where an Observer does not have Internet connectivity
With the use of asymmetric cryptography this means that the public key (PK) mus . With the use of asymmetric cryptography, this means that the public key (PK) m
t somehow be obtained. <xref target="drip-registries" format="default"/> gets mo ust somehow be obtained. <xref target="I-D.ietf-drip-registries" format="default
re into detail how these keys are stored on DNS and one use of DRIP Authenticati "/> provides more detail on how these keys are stored on the DNS and how DRIP Au
on messages is to send PK's over Broadcast RID.</t> thentication messages can be used to send PK's over Broadcast RID.</t>
<t>There are a few keys of interest: the PK of the UA and the PK's of rele <t>There are a few keys of interest: the PK of the UA and the PKs of relev
vant DIMEs. This document describes how to send the PK of the UA over the Broadc ant DIMEs. This document describes how to send the PK of the UA over the Broadca
ast RID messages. The key of DIMEs are sent over Broadcast RID using the same me st RID messages. The keys of DIMEs are sent over Broadcast RID using the same me
chanisms (see <xref target="drip-link" format="default"/> and <xref target="drip chanisms (see Sections <xref target="drip-link" format="counter"/> and <xref tar
-recommendations" format="default"/>) but MAY be sent at a far lower rate due to get="drip-recommendations" format="counter"/>) but <bcp14>MAY</bcp14> be sent at
potential operational constraints (such as saturation of limited bandwidth). As a far lower rate due to potential operational constraints (such as saturation o
such, there are scenarios where part of the key-chain may be unavailable at the f limited bandwidth). As such, there are scenarios where part of the key-chain m
moment a full Authentication Message is received and processed.</t> ay be unavailable at the moment a full Authentication Message is received and pr
<t>The intent of this informative appendix is to give a recommended way to ocessed.</t>
classify these various states and convey it to the user through colors and stat <t>The intent of this informative appendix is to recommend a way to classi
e names/text. These states can apply to either a single authentication message, fy these various states and convey it to the user through colors and state names
a DET (and its associated public key), and/or a sender.</t> /text. These states can apply to either a single authentication message, a DET (
and its associated public key), and/or a sender.</t>
<!-- [rfced] For readability, may we update the text as follows?
Original:
The table below lays out the recommended colors to associate with
state and a brief description of each.
Perhaps:
The table below briefly describes each state and recommends an associated col
or.
-->
<t>The table below lays out the recommended colors to associate with state and a brief description of each.</t> <t>The table below lays out the recommended colors to associate with state and a brief description of each.</t>
<table align="center"> <table align="center">
<name>Authentication State Names, Colors &amp; Descriptions</name> <name>Authentication State Names, Colors, and Descriptions</name>
<thead> <thead>
<tr> <tr>
<th align="left">State</th> <th align="left">State</th>
<th align="left">Color</th> <th align="left">Color</th>
<th align="left">Details</th> <th align="left">Details</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">None</td> <td align="left">None</td>
<td align="left">Black</td> <td align="left">Black</td>
<!--[rfced] In Table 4, may the details for "None" be updated as follows?
The use of 'being' seems odd.
Original: No Authentication being received (as yet)
Perhaps: No Authentication has been received (as yet)
-->
<td align="left">No Authentication being received (as yet)</td> <td align="left">No Authentication being received (as yet)</td>
</tr> </tr>
<tr> <tr>
<td align="left">Partial</td> <td align="left">Partial</td>
<td align="left">Gray</td> <td align="left">Gray</td>
<td align="left">Authentication being received but missing pages</td > <td align="left">Authentication being received but missing pages</td >
</tr> </tr>
<tr> <tr>
<td align="left">Unsupported</td> <td align="left">Unsupported</td>
<td align="left">Brown</td> <td align="left">Brown</td>
<td align="left">Authentication Type/SAM Type of received message no t supported</td> <td align="left">Authentication Type / SAM Type of received message not supported</td>
</tr> </tr>
<tr> <tr>
<td align="left">Unverifiable</td> <td align="left">Unverifiable</td>
<td align="left">Yellow</td> <td align="left">Yellow</td>
<td align="left">Data needed for signature verification is missing</ td> <td align="left">Data needed for signature verification is missing</ td>
</tr> </tr>
<tr> <tr>
<td align="left">Verified</td> <td align="left">Verified</td>
<td align="left">Green</td> <td align="left">Green</td>
<td align="left">Valid signature verification and content validation </td> <td align="left">Valid signature verification and content validation </td>
</tr> </tr>
<tr> <tr>
<td align="left">Trusted</td> <td align="left">Trusted</td>
<td align="left">Blue</td> <td align="left">Blue</td>
<td align="left">evidence of Verified and DIME is marked as only reg istering DETs for trusted entities</td> <td align="left">Evidence of Verified and DIME is marked as only reg istering DETs for trusted entities</td>
</tr> </tr>
<tr> <tr>
<td align="left">Unverified</td> <td align="left">Unverified</td>
<td align="left">Red</td> <td align="left">Red</td>
<td align="left">Invalid signature verification or content validatio n</td> <td align="left">Invalid signature verification or content validatio n</td>
</tr> </tr>
<tr> <tr>
<td align="left">Questionable</td> <td align="left">Questionable</td>
<td align="left">Orange</td> <td align="left">Orange</td>
<td align="left">evidence of both Verified &amp; Unverified for the same claimed sender</td> <td align="left">Evidence of both"Verified and Unverified for the sa me claimed sender</td>
</tr> </tr>
<tr> <tr>
<td align="left">Conflicting</td> <td align="left">Conflicting</td>
<td align="left">Purple</td> <td align="left">Purple</td>
<td align="left">evidence of both Trusted &amp; Unverified for the s ame claimed sender</td> <td align="left">Evidence of both Trusted and Unverified for the sam e claimed sender</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="black" numbered="true" toc="default"> <section anchor="black" numbered="true" toc="default">
<name>None: Black</name> <name>None: Black</name>
<t>The default state where no authentication information has yet to be r <!-- [rfced] Please note that we have updated the description for Black,
eceived.</t> because "no authentication" and "yet to be received" seem redundant.
Please let us know if any updates are needed.
Original:
A.1. None: Black
The default state where no authentication information has yet to be
received.
Current:
A.1. None: Black
The default state where no authentication information has been
received.
-->
<t>The default state where no authentication information has been
received.</t>
</section> </section>
<section anchor="gray" numbered="true" toc="default"> <section anchor="gray" numbered="true" toc="default">
<name>Partial: Gray</name> <name>Partial: Gray</name>
<t>A pending state where authentication pages are being received but a f ull authentication message has yet to be compiled.</t> <t>A pending state where authentication pages are being received, but a full authentication message has yet to be compiled.</t>
</section> </section>
<section anchor="brown" numbered="true" toc="default"> <section anchor="brown" numbered="true" toc="default">
<name>Unsupported: Brown</name> <name>Unsupported: Brown</name>
<t>A state wherein authentication data is being or has been received, bu t cannot be used, as the Authentication Type or SAM Type is not supported by the Observer.</t> <t>A state wherein authentication data is being or has been received but cannot be used, as the Authentication Type or SAM Type is not supported by the Observer.</t>
</section> </section>
<section anchor="yellow" numbered="true" toc="default"> <section anchor="yellow" numbered="true" toc="default">
<name>Unverifiable: Yellow</name> <name>Unverifiable: Yellow</name>
<t>A pending state where a full authentication message has been received but other information, such as public keys to verify signatures, is missing.</t > <t>A pending state where a full authentication message has been received but other information, such as public keys to verify signatures, is missing.</t >
</section> </section>
<section anchor="green" numbered="true" toc="default"> <section anchor="green" numbered="true" toc="default">
<name>Verified: Green</name> <name>Verified: Green</name>
<t>A state where all authentication messages that have been received, up to that point from that claimed sender, pass signature verification and the req uirement of <xref target="trust-assessment" format="default"/> has been met.</t> <t>A state where all authentication messages that have been received fro m that claimed sender up to that point pass signature verification and the requi rement of <xref target="trust-assessment" format="default"/> has been met.</t>
</section> </section>
<section anchor="blue" numbered="true" toc="default"> <section anchor="blue" numbered="true" toc="default">
<name>Trusted: Blue</name> <name>Trusted: Blue</name>
<t>A state where all authentication messages that have been received, up to that point, from that claimed sender, have passed signature verification, th e requirement of <xref target="trust-assessment" format="default"/> has been met , and the public key of the sending UA is marked as trusted.</t> <t>A state where all authentication messages that have been received fro m that claimed sender up to that point have passed signature verification, the r equirement of <xref target="trust-assessment" format="default"/> has been met, a nd the public key of the sending UA has been marked as trusted.</t>
<t>The sending UA key will have been marked as trusted if the relevant D IMEs only register DETs (of subordinate DIMEs, UAS operators, and UA) that have been vetted as per their published registration policies, and those DIMEs have b een marked, by the owner (individual or organizational) of the Observer, as per that owner's policy, as trusted to register DETs only for trusted parties.</t> <t>The sending UA key will have been marked as trusted if the relevant D IMEs only register DETs (of subordinate DIMEs, UAS operators, and UA) that have been vetted as per their published registration policies, and those DIMEs have b een marked, by the owner (individual or organizational) of the Observer, as per that owner's policy, as trusted to register DETs only for trusted parties.</t>
</section> </section>
<section anchor="orange" numbered="true" toc="default"> <section anchor="orange" numbered="true" toc="default">
<name>Questionable: Orange</name> <name>Questionable: Orange</name>
<t>A state where there is a mix of authentication messages received that are Verified (<xref target="green" format="default"/>) and Unverified (<xref ta rget="red" format="default"/>).</t> <t>A state where there is a mix of authentication messages received that are Verified (<xref target="green" format="default"/>) and Unverified (<xref ta rget="red" format="default"/>).</t>
<t>Transition to this state is from Verified if a subsequent message fai ls verification so would have otherwise been marked Unverified, or from Unverifi ed if a subsequent message passes verification or validation so would otherwise have been marked Verified, or from either of those state upon mixed results on t he requirement of <xref target="trust-assessment" format="default"/>.</t> <t>State transitions from Verified to Questionable if a subsequent messa ge fails verification, so it would have otherwise been marked Unverified. State transitions from Unverified to Questionable if a subsequent message passes veri fication or validation, so it would otherwise have been marked Verified. It may transition from either of those states upon mixed results on the requirement of <xref target="trust-assessment" format="default"/>.</t>
</section> </section>
<section anchor="red" numbered="true" toc="default"> <section anchor="red" numbered="true" toc="default">
<name>Unverified: Red</name> <name>Unverified: Red</name>
<t>A state where all authentication messages that have been received, up to that point, from that claimed sender, failed signature verification or the r equirement of <xref target="trust-assessment" format="default"/>.</t> <t>A state where all authentication messages that have been received fro m that claimed sender up to that point failed signature verification or the requ irement of <xref target="trust-assessment" format="default"/>.</t>
</section> </section>
<section anchor="purple" numbered="true" toc="default"> <section anchor="purple" numbered="true" toc="default">
<name>Conflicting: Purple</name> <name>Conflicting: Purple</name>
<t>A state where there is a mix of authentication messages received that are Trusted (<xref target="blue" format="default"/>) and Unverified (<xref targ et="red" format="default"/>) and the public key of the aircraft is marked as tru sted.</t> <t>A state where there is a mix of authentication messages received that are Trusted (<xref target="blue" format="default"/>) and Unverified (<xref targ et="red" format="default"/>) and the public key of the aircraft is marked as tru sted.</t>
<t>Transition to this state is from Trusted if a subsequent message fail s verification so would have otherwise been marked Unverified, or from Unverifie d if a subsequent message passes verification or validation and policy checks so would otherwise have been marked Trusted, or from either of those state upon mi xed results on the requirement of <xref target="trust-assessment" format="defaul t"/>.</t> <t>State transitions from Trusted to Conflicting if a subsequent message fails verification, so it would have otherwise been marked Unverified. State t ransitions from Unverified to Conflicting if a subsequent message passes verific ation or validation and policy checks, so it would otherwise have been marked Tr usted. It may transition from either of those states upon mixed results on the r equirement of <xref target="trust-assessment" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="operational-proof" numbered="true" toc="default"> <section anchor="operational-proof" numbered="true" toc="default">
<name>Operational Recommendation Analysis</name> <name>Operational Recommendation Analysis</name>
<t>The recommendations found in <xref target="operational-recommendations" <t>The recommendations in <xref target="operational-recommendations" forma
format="default"/> may seem heavy handed and specific. This informative appendi t="default"/> may seem heavy-handed and specific. This informative appendix lays
x lays out the math and assumptions made to come to the recommendations listed t out the math and assumptions made that resulted in those recommendations and pr
here as well as an example.</t> ovides an example.</t>
<t>In many jurisdictions, the required ASTM Messages to be transmitted eve <!-- [rfced] Are the values for Basic ID and Location correct? In other places,
ry second are: Basic ID (0x1), Location (0x2), and System (0x4). Typical impleme we see Basic, Location, and System associated as follows:
ntations will most likely send at a higher rate (2x sets per cycle) resulting in
6 frames sent per cycle. Transmitting this set of message more than once a seco - Basic ID: 0x0
nd is not discouraged but awareness is needed to avoid congesting the RF spectru - Location: 0x1
m, causing further issues.</t> - System: 0x4 (seems correct)
<ul empty="true" spacing="normal">
<li>Informational Note: In Europe, the Operator ID Message (0x5) is also Original:
required. In Japan, two Basic ID (0x0), Location (0x1), and Authentication (0x2 In many jurisdictions, the required ASTM Messages to be transmitted
) are required. Self ID (0x3) is optional but can carry Emergency Status informa every second are: Basic ID (0x1), Location (0x2), and System (0x4).
tion.</li>
</ul> For example, the note that appears just after the above shows Basic ID (0x0) and
Location (0x1).
Informational Note: In Europe, the Operator ID Message (0x5) is
also required. In Japan, two Basic ID (0x0), Location (0x1), and
Authentication (0x2) are required.
For the note text above, may we update to indicate that message transmission is
required?
Perhaps:
Informational Note: In Europe, transmission of the Operator ID Message (0x
5) is
also required. In Japan, transmission of two Basic IDs (0x0), a Location
(0x1),
and an Authentication (0x2) are required. Self ID (0x3) transmission is o
ptional but
can carry Emergency Status information.
-->
<t>In many jurisdictions, the required ASTM Messages to be transmitted eve
ry second are: Basic ID (0x1), Location (0x2), and System (0x4). Typical impleme
ntations will most likely send at a higher rate (2x sets per cycle) resulting in
6 frames sent per cycle. Transmitting this set of messages more than once a sec
ond is not discouraged, but awareness is needed to avoid congesting the RF spect
rum, causing further issues.</t>
<t>Informational Note: In Europe, the Operator ID Message (0x5) is also
required. In Japan, two Basic ID (0x0), Location (0x1), and Authentication (0x2)
are required. Self ID (0x3) is optional but can carry Emergency Status informat
ion.</t>
<section anchor="page-counts-vs-frame-counts" numbered="true" toc="default "> <section anchor="page-counts-vs-frame-counts" numbered="true" toc="default ">
<name>Page Counts vs Frame Counts</name> <name>Page Counts vs Frame Counts</name>
<t>There are two formulas to determine the number of Authentication Page <t>There are two formulas to determine the number of Authentication Page
s required, one for Wrapper:</t> s required. The following formula is for Wrapper:</t>
<sourcecode name="" type="" markers="true"><![CDATA[ <sourcecode name="" type="" markers="true"><![CDATA[
wrapper_struct_size = 89 + (25 * num_astm_messages) wrapper_struct_size = 89 + (25 * num_astm_messages)
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1 wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1
]]></sourcecode> ]]></sourcecode>
<t>and one for Manifest:</t>
<sourcecode name="" type="" markers="true"><![CDATA[
<t>The following formula is for Manifest:</t>
<sourcecode name="" type="" markers="true"><![CDATA[
manifest_struct_size = 89 + (8 * (num_astm_hashes + 3)) manifest_struct_size = 89 + (8 * (num_astm_hashes + 3))
manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1 manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1
]]></sourcecode> ]]></sourcecode>
<t>A similar formula can be applied to Link as they are of fixed size:</
t>
<sourcecode name="" type="" markers="true"><![CDATA[
<t>A similar formula can be applied to Links, as they are of fixed size:
</t>
<sourcecode name="" type="" markers="true"><![CDATA[
link_page_count = ceiling((137 - 17) / 23) + 1 = 7 link_page_count = ceiling((137 - 17) / 23) + 1 = 7
]]></sourcecode> ]]></sourcecode>
<t>Comparing Wrapper and Manifest Authentication Message page counts aga
inst total frame counts we have the following:</t> <t>Comparing Wrapper and Manifest Authentication Message page counts aga
inst total frame counts, we have the following:</t>
<table anchor="tbl-page-counts" align="center"> <table anchor="tbl-page-counts" align="center">
<name>Page &amp; Frame Counts</name> <name>Page and Frame Counts</name>
<thead> <thead>
<tr> <tr>
<th align="left">ASTM Messages</th> <th align="left">ASTM Messages</th>
<th align="left">Wrapper (w/FEC)</th> <th align="left">Wrapper (w/FEC)</th>
<th align="left">Manifest (w/FEC)</th> <th align="left">Manifest (w/FEC)</th>
<th align="left">ASTM Messages + Wrapper (w/FEC)</th> <th align="left">ASTM Messages + Wrapper (w/FEC)</th>
<th align="left">ASTM Messages + Manifest (w/FEC)</th> <th align="left">ASTM Messages + Manifest (w/FEC)</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 1404 skipping to change at line 1694
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">20 (22)</td> <td align="left">20 (22)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Link shares the same page counts as Manifest with 5 ASTM Messages.</t > <t>Link shares the same page counts as Manifest with 5 ASTM Messages.</t >
<section anchor="special-cases" numbered="true" toc="default"> <section anchor="special-cases" numbered="true" toc="default">
<name>Special Cases</name> <name>Special Cases</name>
<section anchor="zero-astm-messages" numbered="true" toc="default"> <section anchor="zero-astm-messages" numbered="true" toc="default">
<name>Zero ASTM Messages</name> <name>Zero ASTM Messages</name>
<t>Zero ASTM Messages in <xref target="tbl-page-counts" format="defa ult"/> is where Extended Wrapper (<xref target="extended-wrapper" format="defaul t"/>) without FEC is used in Message Packs. With a max of 9 "message slots" in a Message Pack an Extended Wrapper fills 5 slots, thus can authenticate up to 4 A STM Messages co-located in the same Message Pack.</t> <t>Zero ASTM Messages (see <xref target="tbl-page-counts" format="de fault"/>) is where Extended Wrapper (<xref target="extended-wrapper" format="def ault"/>) without FEC is used in Message Packs. With a maximum of nine "message s lots" in a Message Pack, an Extended Wrapper fills five slots; thus it can authe nticate up to four ASTM Messages co-located in the same Message Pack.</t>
</section> </section>
<section anchor="eleven-astm-messages" numbered="true" toc="default"> <section anchor="eleven-astm-messages" numbered="true" toc="default">
<name>Eleven ASTM Messages</name> <name>Eleven ASTM Messages</name>
<t>Eleven ASTM Messages in <xref target="tbl-page-counts" format="de <t>Eleven ASTM Messages (see <xref target="tbl-page-counts" format="
fault"/> is where a Manifest with FEC invokes the situation mentioned in <xref t default"/>) is where a Manifest with FEC invokes the situation mentioned in <xre
arget="fec-limitations" format="default"/>.</t> f target="fec-limitations" format="default"/>.</t>
<t>Eleven is the max number of ASTM Messages Hashes that can be supp <t>Eleven is the maximum number of ASTM Message Hashes that can be s
orted resulting in 14 total hashes. This completely fills the <tt>evidence</tt> upported resulting in 14 total hashes. This completely fills the <tt>evidence</t
section of the structure making its total size 200 octets. This fits on exactly t> section of the structure making its total size 200 octets. This fits on exact
9 Authentication Pages (<tt>(201 - 17) / 23 == 8</tt>) so when the ADL is added ly 9 Authentication Pages (<tt>(201 - 17) / 23 == 8</tt>), so when the ADL is ad
it is placed on the next page (Page 10). Per rule 1 in <xref target="enc-single- ded, it is placed on the next page (Page 10). Per rule 1 in <xref target="enc-si
page" format="default"/> this means that all of Page 10 is null padded (expect t ngle-page" format="default"/>, this means that all of Page 10 is null padded (ex
he ADL octet) and FEC data fills Page 11, resulting in a plus two page count whe pect the ADL octet) and FEC data fills Page 11, resulting in a plus-two page cou
n FEC is applied.</t> nt when FEC is applied.</t>
<t>This drives the recommendation is <xref target="drip-manifest" fo <t>This drives the recommendation is <xref target="drip-manifest" fo
rmat="default"/> to only use up to 10 ASTM Message Hashes and not 11.</t> rmat="default"/> to only use up to 10 ASTM Message Hashes, not 11.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="full-authentication-example" numbered="true" toc="default "> <section anchor="full-authentication-example" numbered="true" toc="default ">
<name>Full Authentication Example</name> <name>Full Authentication Example</name>
<t>This example is focused on showing that 100% of ASTM Messages can be <!-- [rfced] "Authentication with DRIP in that case" is unclear. May we update
authenticated over Legacy Transports with up to 125% overhead in Authentication the text as follows?
Pages. Extended Transports is not shown as Authentication with DRIP in that case
is covered using Extended Wrapper (<xref target="extended-wrapper" format="defa Original:
ult"/>). Two ASTM Message Packs are sent in a given cycle: one containing up to Extended Transports is not shown as
4 ASTM Messages and an Extended Wrapper (authenticating the pack) and one contai Authentication with DRIP in that case is covered using Extended
ning a Link message with a Broadcast Endorsement and up to two other ASTM Messag Wrapper (Section 4.3.2).
es.</t>
Perhaps:
Extended Transport is not shown as
Authentication with DRIP; in this case, it is covered using Extended
Wrapper (Section 4.3.2).
-->
<t>This example is focused on showing that 100% of ASTM Messages can be
authenticated over Legacy Transports with up to 125% overhead in Authentication
Pages. Extended Transport is not shown as Authentication with DRIP in that case
is covered using Extended Wrapper (<xref target="extended-wrapper" format="defau
lt"/>). Two ASTM Message Packs are sent in a given cycle: one containing up to f
our ASTM Messages and an Extended Wrapper (authenticating the pack), and one con
taining a Link message with a Broadcast Endorsement and up to two other ASTM Mes
sages.</t>
<t>This example transmit scheme covers and meets every known regulatory case enabling manufacturers to use the same firmware worldwide.</t> <t>This example transmit scheme covers and meets every known regulatory case enabling manufacturers to use the same firmware worldwide.</t>
<figure anchor="max-schedule-fig"> <figure anchor="max-schedule-fig">
<name>Full Authenticated Legacy Transport Transmit Schedule Example</n ame> <name>Example of a Fully Authenticated Legacy Transport Transmit Sched ule</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------------------+ +------------------------------------------------------+
| Frame Slots | | Frame Slots |
| 00 - 04 | 05 - 07 | 08 - 16 | 17 | | 00 - 04 | 05 - 07 | 08 - 16 | 17 |
+-------------------+---------------+---------+--------+ +-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] | | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[0] |
+-------------------+---------------+---------+--------+ +-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[1] | | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[1] |
+-------------------+---------------+---------+--------+ +-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[2] | | {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8] | L/W[2] |
skipping to change at line 1461 skipping to change at line 1763
L[y,z] = DRIP Link Authentication Message (0x2) L[y,z] = DRIP Link Authentication Message (0x2)
W[y,z] = DRIP Wrapper Authentication Message (0x2) W[y,z] = DRIP Wrapper Authentication Message (0x2)
M[y,z] = DRIP Manifest Authentication Message (0x2) M[y,z] = DRIP Manifest Authentication Message (0x2)
y = Start Page y = Start Page
z = End Page z = End Page
# = Empty Frame Slot # = Empty Frame Slot
* = Message in DRIP Manifest Authentication Message * = Message in DRIP Manifest Authentication Message
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Every common required message (Basic ID, Location and System) is sent <t>Every common required message (Basic ID, Location, and System) is sen
twice plus Operator ID and Self ID in a single second. The Manifest is over all t twice along with Operator ID and Self ID in a single second. The Manifest is o
messages (8) in slots <tt>00 - 04</tt> and <tt>05 - 07</tt>.</t> ver all messages (8) in slots <tt>00 - 04</tt> and <tt>05 - 07</tt>.</t>
<t>In two seconds either a Link or Wrapper are sent. The content and ord <t>In two seconds, either a Link or Wrapper are sent. The content and or
er of Links and Wrappers runs as follows:</t> der of Links and Wrappers runs as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Link: HDA on UA Link: HDA on UA
Link: RAA on HDA Link: RAA on HDA
Link: HDA on UA Link: HDA on UA
Link: Apex on RAA Link: Apex on RAA
Link: HDA on UA Link: HDA on UA
Link: RAA on HDA Link: RAA on HDA
Link: HDA on UA Link: HDA on UA
Wrapper: Location (0x1), System (0x4) Wrapper: Location (0x1), System (0x4)
Link: HDA on UA Link: HDA on UA
Link: RAA on HDA Link: RAA on HDA
Link: HDA on UA Link: HDA on UA
Link: Apex on RAA Link: Apex on RAA
Link: HDA on UA Link: HDA on UA
Link: RAA on HDA Link: RAA on HDA
Link: HDA on UA Link: HDA on UA
Wrapper: Location (0x1), System (0x4) Wrapper: Location (0x1), System (0x4)
Link: IANA on UAS RID Apex Link: IANA on UAS RID Apex
]]></artwork> ]]></artwork>
<t>With perfect receipt of all messages, in 8 seconds all messages (up t <!-- [rfced] We are unsure what "then all in future" means.
o that point then all in future) are authenticated using the Manifest. Within 13
6 seconds the entire Broadcast Endorsement chain is received and can be validate Original:
d; interspersed with 4 messages directly signed over via Wrapper.</t> With perfect receipt of all messages, in 8 seconds all messages (up
to that point then all in future) are authenticated using the
Manifest.
Perhaps:
With perfect receipt of all messages, the messages up
to that point are authenticated using the
Manifest within 8 seconds.
-->
<t>With perfect receipt of all messages, all messages (up to that point
then all in future) are authenticated within 8 seconds using the Manifest.
<!--[rfced] Please clarify; what is interspersed with 4 messages?
Also, will "signed over via Wrapper" be clear to the reader?
Original:
Within 136 seconds the entire Broadcast Endorsement chain
is received and can be validated; interspersed with 4 messages
directly signed over via Wrapper.
Perhaps:
Within 136 seconds, the entire Broadcast Endorsement chain
is received and can be validated; it is interspersed with
four messages that are signed over using a Wrapper.
Related question: We see 'sign over' used in various forms in this document,
as in sign over information elements, sign over data, sign over a
list of messages. Should it be a defined term? It does not appear in
RFC 9153.
-->
Within 136 seconds, the entire Broadcast Endorsement chain is received and can b
e validated; interspersed with four messages directly signed over via Wrapper.</
t>
<section anchor="raw-example" numbered="true" toc="default"> <section anchor="raw-example" numbered="true" toc="default">
<name>Raw Example</name> <name>Raw Example</name>
<t>Assuming the following DET and HI:</t> <t>Assuming the following DET and HI:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
2001:3f:fe00:105:a29b:3ff4:2226:c04e 2001:3f:fe00:105:a29b:3ff4:2226:c04e
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813 b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813
]]></artwork> ]]></artwork>
<t>The following ASTM Messages to be sent in a single second:</t> <t>The following ASTM Messages are to be sent in a single second:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0240012001003ffe000105a29b3ff42226c04e000000000000 0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000 12000000000000000000000000000000000000000060220000
32004578616d706c652053656c662049440000000000000000 32004578616d706c652053656c662049440000000000000000
420000000000000000000100000000000000000010ea510900 420000000000000000000100000000000000000010ea510900
52004578616d706c65204f70657261746f7220494400000000 52004578616d706c65204f70657261746f7220494400000000
0240012001003ffe000105a29b3ff42226c04e000000000000 0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000 12000000000000000000000000000000000000000060220000
420000000000000000000100000000000000000010ea510900 420000000000000000000100000000000000000010ea510900
]]></artwork> ]]></artwork>
<t>This is Link with FEC that would be spread out over 8 seconds:</t> <t>This is a Link with FEC that would be spread out over 8 seconds:</t >
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
2250078910ea510904314b8564b17e66662001003ffe000105 2250078910ea510904314b8564b17e66662001003ffe000105
2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7 2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7
2252f5ed0ac08a81975034297bea2b000418132001003ffe00 2252f5ed0ac08a81975034297bea2b000418132001003ffe00
22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222 22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222
2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46 2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46
2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94 2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94
2256d9ad97940d280000000000000000000000000000000000 2256d9ad97940d280000000000000000000000000000000000
2257a03b0f7a6feb0d198167045058cfc49f73129917024d22 2257a03b0f7a6feb0d198167045058cfc49f73129917024d22
]]></artwork> ]]></artwork>
skipping to change at line 1539 skipping to change at line 1873
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4 2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
22552226c04efb729846e7d110903797066fd96f49a77c5a48 22552226c04efb729846e7d110903797066fd96f49a77c5a48
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2 2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317 22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83 2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAFJ71mUAA+292XLjVpYo+s6vQGdGl0mbZJIUqamOK5opKZ2qyqlTSrvr
VjisTQAU0SIJNgBKouU8cT7k3p87X3LXtCcAlJSeyq6wosopkcAe1l57zUOn
02mEaZQsLw+DdTHt7DcaRVLM48Pg+P3pu+BkCX9tgnN1GYzXxSyGP0NVJOky
eJFmC1XkwZ+Cd1lapGE6z4NpmgXPs1RFocqL4H28SIs4OD1uqMkki69lSBxH
v92I0nCpFjBblKlp0UliWEKUJauOgqc6w4MGzBZfptnmMMiLqNFIVtlhUGTr
vBj0ege9QUNlsToMTpdFnC3jonFzKbN8k2ZXsKngqyxdrxpXN/aZzjFOhQPL
mHmhltF3ap4uYR2bOG+sksPgH7CldpCnWZHF0xx+2yz4lzBdLAAM+beNBq4x
zQ4bjU4QBFmKQIujpEizBvwdJMv8MBh3g29gU7N1HM5gevqCNzyO1KL6XZrB
Bsb/hXCPs1WWfB+3g1evjui7HJYSw6KHB8O94AiXkYWJmgfHWXId0xMhnNVh
8HfY+nUyn/NnWXwJx3UYvPk7P5JGMHl/Z3gwkr/XywLB++FsTB/EC5XMDwMF
y+veOMv7D3Ubm0V1AQq0a9rkWTc4UlnkbO6sWKussJ/+ZraVF+tuCKu6Zzfv
u8HrNL9Kb5Lie2dL79NJDFvyv6J9vTw/h3Uv8/W8AIzz9vTkibOBt+oqeKey
K2/9r0+d9Q/3Bzt7964/u1z8x1xN8u6sKDohT0rLbyzpRgHIDun5p8H7F0c5
/Qq/HPRHO4f4Id2tLP6fdZLFhMbmiZ29ofNEEpkvhjvOFyoLZw2Z4OQWL5Sa
058vdob9Pk8dBEJBzvBiAbCDs1UcJlNNOZBKGNoQwCPBeabCKw27IND3KpCf
TmB+1ah0dv5aLjSNKYuAmVV2iYAH8Kzyw2fPbm5uukCLFl147dkU19gZDBRA
b6HfiIDAHAZ/Xc83waA3GMineZwlcZ4sp6ldBk56yBuFQcbm8+O3p4B6vW5/
NOg9s1838O3SmZyenL8IiP4w4OU4LhNAGJgPiFTnuGuJoP2mUXOo+/3BLp1M
opaKkCGJ4ozg4RzrLp/e8ZuzsxO+cKXjC87SdRbG/MqL8bjTHx69eG+3LYep
TyxCHmDOMp0GH5YLtVzGUTBOspBIq36zfI50dB+WSQEPA24UcR68iHHJ82B8
nfCA42iRLHHT/GcTFtSyS6k53cv0GgGN/z4DGBSwvGerq8tnL9534Dz7nV6/
0x89W0XTZ/BnrzPYPxjud+FPMygjgDzb0Afd4f12To8rkDg9Gr91EPjNegGU
AT64NMu+HwIe3gZHCRA1u/+32aVaJt/7w9TtG04g7SawWZXAYNfJJb3y7HR8
/uLZO3UZ58/8bcA1WN1WN73T6Q+AgXU6AVAVWH5YNBrnsxiQFNjhlkPXDD9o
IqtttYPVfJ0zVw5W6TwJAWHpXq/gFoFsEQYqBASDR9LAonQboHNJNKiKQsHZ
Ji/iRdD8MD5rbVlF8/3pMcwdL9Vkjpx+noYAThAH5nBQizhQeQ5z4gSIpbS6
G2Dns2SJS4GPsjiM4W5GAQwULOBDhBqtO53A/cdvYHqY4TpeBpNN8JY/zfJg
zuTKiBSyv25wPkvyAGSaNU0bxVOcjAUSmSAoNiuZZSoSFEBlEgPFgTeSpSs/
wbJKQtdrvUp4B1aSTDdBMVMwf1GocAYLxnFxXzS7fGa2dhNnME9yiZCe4Jux
HAd8Dpu+WQIaI6jw+EvCX/P45LwVhHMFkI26jDCLJIqAGzeeIhyyNFqHhLSE
PnCHi4SO43I9Z5IUNOPuZbcd3N0ZIvPxY4tWnAujcJ9BOorfI7eo4gcgRkuQ
JL8XS3D4QtgLowycT7BMAWZRlBFSImZ0g5fpDRx01obtwxnC/1Tg8EkG8zKO
I31e8npM5xhcK8B0uARRMp0CNOGFFQhAeA/oxZm6hjdwn1cIGwJxrqZxkK6E
YiPg32iaANvMVyqM7Q7fwA67pUt5bC7iZzlfxc/yVnCZwgAJrTIntrsJZukN
IVOolrjyhYpi5z5sCEbqGuQLuEm0vEkKIrpFbviaLlcnXQKXBCK7jEOk4Tng
Ge4brnJMc6k5fA/vA8iAYC3DDWAbSIJ0/IA0cEywTaDQsm2aSwXXKWIIzBwv
rxPYIcK7G5wtYDS4gPAGQDSYJwUQX9gCwAWREoEOcs9qXdhzRtF8vZST7+Ll
5auNdEnNcz42uqkJbhSkuFmwniRwyAWeHQ4B9/V2FQMnhfOK4uskxGsDz6Xr
IlgAKZua0emqz5NFAjc4XfEWUTosgnCdEQbksoOzAJSU4DQ9NyMSRUmmhIZA
D2BMBBzOcjkjaqXyIF+HM5wFFgbIv6H3fR4fqNUKXpsBvgG40oXcWjjUq7Ze
BHwP1DZdXuIvIYA9QsQQyLQD2sJVjJMzdGBEWA1CB/EHxwRUAPDj7Os87gBh
ivEov4qXyLfnG7gvN6kPeZhoBhjA6qA+BASBXn4cHTpkDsH+JkZcvCoT0Cn8
AvMFeL4R6qjCZGBtPplsnsVEfIKd7gDhd3cnQu/HjzS+/rrfHbgPgGgLJKYb
jHOh1YgAlvgwL1gXc/uNP6wzSru0IiIgcFs7N2oDghjSoGW+SAD1+K6/Hh8B
G9kAaA15ToH8BM/n67hI8f4B8L5JOi8SgPZZvIyQ7+AFXiAJQYQgYpwTKXEY
mOEqcDjpTddhWkSDlqkhtqD4IG+AZSE8mVvSaDWsUg8uAlYbxsk0A7qZxYQi
+GqJ1eAZCqOBi5wIZUYcRKRNljwODDpNsgVTyq3PEk2DL5ECwr8bwqjrJF/T
3WGODRjSBboVAZlu1+wcjwK2CowR0OER61awkjaeQ75K0ykzTedOyJEWQCY1
31JwpqsiXdFLC+AAqxmsF5nc5ga3gUgUAUvB6eGfOYJ3YvAGxruEq1zi+bJv
0FRhQLrOaBJhCgizk+CHN4PZVr6OAWGePt3CwUtjfwXMomK2OT1uNEjBshdh
mxjSlN+Cc5Bqgt7tAAQy2OgSaUXEBLZ+HXxzQOeEwSdKuCjirQh0yC1nyeUs
mAOtnBsBzuKIYCJ+w6dBKzYLuwEKekk0qjDCTpJpAcYVe3LSfpDyxLmDCIhd
USzCEiDNKgM9IyLUczCLdlhmpckCpgBxHsmqIrojfFXUQeQed3dk4MpRC+rA
w5eZWuQAC5kml+13ZPvXiNzxjZbOtLSRsxJVI94SnBaA70DU6SzQvHUp66Wd
Cry7KK8hsfJPGBgBIEQ4Y75pVkXYH2cZ3dosE6ravLubxmEHBc5knpNQR0wr
coBf0vuaH0Bie5Ty58uLiF4JLAtWTMQU9jTN0oWDqkRFX8WXCqSPc7yhK4AK
TGgJ67B726JtIxgIPePlTC1DNojgYSMugUxlB52uM0KyfL3C4WhDyQJ/VYCD
AOAAGSMehIMbs1SfAIgwyEMCwV1STxBx6VnGCLhyMPqCrjh8Rcty7TQ+7zGy
p6WNckbCp+DVDgz38SMM/JfgTYraHsrlJ8sozXIWaZuEGPQ4WRtgiVd4eIQ7
OJyWXlUAdxbncK7N6w9nKI/ARgj+KAUZvEfZV7QZq2PImc4SOPIsnIHgoEkm
7ZXFdqARr9USLiAtUKhG8/j09UlLr9IqkLA5IPY0BXHvBC0t7gRENnkpcnGQ
s+S02JcvT8+D43ShYJFj0tJpqpfH41b5RWC68LF+8b2FwThH+oA46Izwfowj
xEUIiytIDMAbBOx1vSBmhvAEsRA33VE3SGZo46gqIB4xrFUuBMvwwSyI1hlO
laBYzmRF6A/Tv5oBkREE53EGlyqdp8Ay7p4W9q+PxCbeM45F7nOswl0BjwWK
AgrPEzzsJ23+N3jzln5/f/KfH07fnxzj72cvx69emV/0E2cv3354dWx/s28e
vX39+uTNMb8Mnwalj16P/w7/IC198vbd+enbN+NXTxibXOkQt8pia8Km3BgJ
jEJZLg+zZMLI/fzoXdAfAvb8G9yfQb9/APeH/9jvE/tBfsWTkXrDf7KEsVrF
KiMlBU4MVI+kgMNsk3QOOtWSRW/mtoKAaHpr+EIsCmx8toKEeAZAkI7GYyuk
tIMPZ2fwn/PXjDstXyA1Vx8EOpY9eAxUEnA5fEMQIEINHbkUCOZcRBZ44+Vp
GzGsHbzH6QGv9Xyll4k1w95OWfTGnfG9mKYoWJLEQWtgRslrRUHCO6PDRgPN
jEukS5YYHyJN+sAAifXXKgIwFEku5M6h1yOg1+2A5LuQ2WjQJMkY1AbgkROY
dIx4T4xPNAnS9t+M37RaJMCdnpycBPu9QbffD57HKjR3BxSxiAQ8NlC7TDoA
8YzxLNffl/QD0PdQJsGjdaWP4J0Kryqi0QvkORW+5ILCCoJTkAbiCs+6ZyGN
BpDNZBrnBQ0IFAuIMajGKHfMgVzh8AlZEiYxq1GyABioqS+WAQLzMuSjRkj1
FLwWERat2ZVkw+ew+cssXcN9ItdgGAPhQgO2lklLzxtj4jHdWtKkgVCt5OMO
XmYgVZYXa6tavUxKsMMt4mUmEhyl8DBq2vxiWdLR+hJK06AQpFFOb8W3qAkn
qEArfDhZkdySo40IRBYk/KqAjWndP5isnamma1RKZEIYNEexfrmMb4Nxn9XP
8m6UI4GXdvY16lnIAc74CmgZaKZITIzV9QZ47DxBEQZVZU1TyBbaIWFDbDbJ
NbIooJl4kbV9p4vO2GK9JIG17Wq/xLjwtiM3SrKIbFobo0CW13lOls01CWWE
9CPj+KkeFkIa1Pbxa7raDFQADO+M8ERDhkUcFtgc5dVYzQzaOvZUV06rilKA
8Bp5iWI58ruH51olryj2S0f4Q5hoyh7OUJwwygoOrmiq0+Nu8I5OkCXmUckG
0S4DyGjxgGFodWQlBE5ZbTwahVNYkVOUW2TksbZrvkkBl4EEkKgsozZrrR0w
FIsSqeODyEkDy9Sl0TGnMSF+y1OJpuslazpzwbAc3s7JPA2vkE0SiAB7SLVc
iHQaPp3O2ZpY5u/EWIHM0K1GkfjNGdAFUpuiZQ4k4VVyBQobWtyUViBgd7D9
nDlVSlgFaDX5b8J9wSWCaR6Ha5LXkO/jshasr6FRFj4FWQ7dw1E3OEvwVglC
roBbkDUK14KgZ2vAlARDDQKYnR5fuwt3LcdI2njLcIFXAO8J0G27ohVJd2GM
5kS085AhmegPwm6ZRmSShH2RWYMskLEYaHFoMm/Cg6v0BoaG7T2Dda7SFEQM
uMmgbC+jmyQClvKf6RmMXcxgnjFqe6uMZHfyTMSKTaRmUbDg2TL5n7WeexKT
fgoQI/smvGOojjH5CsDImnuOkAeIxea6mvvL+1vPQdJCSJkphbC2LbPKRa4G
JEnXRa5xj+yafAVduauZxzHTMNAclnlHD4wWP5Jr6JTs5SHh9hoQOCIwzB0i
nxtfkVgohZywZeYloqDRX0DCarFyDGtestEyFbHeFa2Cl6egYoKki7AE0RUw
Dj1OJIIpOc4QHThttBSDcJtrQLpfsuYXd8iGdrnOtNXlJob1Xy1BSAVV59SR
FIkZIbBA/CSxMWcXjNZwV+kKHTastxsPmSWBjgKJAgq+Dup/BEymg3cvZ3O8
duzggc7T9Gq9gofJMGT8DKKCW7wh+MN1QCKF8IJXAd+yjViUPBbGXKmNkE0n
BRJdVNJOifcCOK7ROgK4SQAAdg46HI9FFlR8CK8hT4WmQscEGIiuMokZwMZ+
YdbJl1gjCmoNIeMhzI+YSeshJ9kYqBOZvRewppl4FSr4z44brSDgthm/ibcR
alfEavZ2sDdnSqKW1eI9/ZhJ6Dsi1IiJmu2dE3+6e5olUYf4BJBTkAJoLWzR
1xpmkV6ymVRTewWQAj63TPIFM7ilBxrmfA6HZXlgiwERFvgiyfJCGznLVnIY
HN/KhJsJgwVqvxUja3FRbq1nXBMrAcEcrwEAFzQ6vKoEznC+Joghr4dbDO+t
FTpzPst9ewYu0pgVSXUnR5R7/QEvmqv1BMRJ1Kn1YijeDA9R0JE2yDwBCDtP
TXJdfE2CnUhtjmsa3goVok0Wr1AuICfwFcsMgAAApTki4bSI/VNCufFSkVk9
CpguEI7OQXQgrd+FdZMIUonEMOkBgLMff8tZGOpBUhQuXiWGIzmUgUnFNUu5
EVFeYalokSJmrgrxnRHWO6bg+yFvoU5AQSYXZ/ONY8dqk9wupiEEDJ7GJsYT
AZpDRjBCilVq/SOlOQDSigGHbIVQGQgVIni2katLo4sROdZjIfYAbYk2S1BY
2AOozUlAWBTvDwZbE99lQWUJBxElISt2uHJk1PCiAV6ZWMF9WKvKbWCNwpIg
Vv/Y1k1zEy12aWRlYBRdHMnXnLW+9q6QyuflxGPAquizjv2MufJTJFd4HX1M
gknO1qDnA8AR1HDYORCvykVvNCw3lwUxk38FeLTdh1Eyf6JnATAfz2ELYgMs
mGTAusJZMmf0c8kCylQSQyYQymN/DHF6IS1CIQweydD7S8B0TJieoF6h720W
F0jLgRW8AxEruQ3eUiAHXiOSstnpVaZjlSU7huIXgrQZBh2i57EqXF3UguYQ
4xvJP3iEYLkwsiIHACfEL2ExF89Pyo+SFgqaikI6tHV4bbS6f2TzlMYo2O4Z
Y/cJMgAkp3dPS/cCpJGaCyro7VxyxOM0NBMK7Nv6ltPNAVEt+hGX2IgUpcvW
NsPIHUWCyqIgTSKSAPzXM0PRS9P1fAqgyuVAHS2Y5ZiHV4OWC9emQPcqZ3z4
MO7kJcASRpIxmv16D127mwzNrBnrn/LZQoxZTBS+cRy12u2XUNxOzG72PAZS
hMeD+gnN4pgRhMOKy4TpvewNn7QUjgUV8cmQB5I5lYhiqDgxuJvkXmE/V8bY
ksjzwBPDdA3aMsl/gHl0IFssVS/EUiVKrQigH1ks3vJO1eHqYJfo1SXfrb1K
xnCj0JVhHepw2gsXZwSf5hh1iGBXPG7ZeAnY+D06TlMbSmViYsSLyHbAwnuj
LXNr0qb4CAnIT1aIG09Az0Pfo7EHTcm9tCQ9Ck9pXrMYspkyFakxObeDlXHr
AooA7SDnFyIDEkqVSSySjM6DIUU8tXwM6CbTxwfsvMbp8ygA0ho02MSGTroA
HgvAsGYzgcQS5PqkxNxFSHfu2ejz9QQVX4kXQuNHMAHeMa24lLdZU2nz9dEx
uNJJTOEPdC1vC1wvBpvV2XmZChEBxJAe7cIGqWUeIbyyWEUbMxFQQB+NRZUp
G49xjXJ/VvryuHxKjFdVc7Gc1qj9SBulMlEYS7TFzMtmZJEakFizMxIFeI3W
MIRYRy0f99/viGkODQN1K4U9IWkR/y5ualMLCyEBF/THSwBpnF0wp9BrqFw9
OgHzYmXQzRzIxwVbU+7ucrXoIBFkynx3CBrBIeAV+Vw6QFUvl18+CSmz4snH
xv+Gn0bQC6o//ZrPBjWf7eDrffhqJxgGo2A32Av2g4NP+azxRcf/+eS/Gz8E
gQPOIPihZqH3/fxQXcMnj/Cpc/56I9QjzK+7hk8Z4afjA6E1oX7wFHNLOob8
cIbAl09M4st97B9xCi5Jw8Gtw6DZD9KwiIsW8p46QtAcBhPghqwz06uSf6C/
aARBo/5MYPTBDg/Pdmdcct1E8nzbMYPMaH2g1rxZA7tcAcMn4zjRBNk+vUOE
+h75BWVYENzCguwILutn/ozLghE9qCJNPNccT4kpGi2gC3WbLNYLfLu/KwM0
UWG5hbF7KOD2Ry1PpMk5qjSznL5+nW22opIUQgcbqizbME3Xs2pYbqWZGj6i
tqHSxoxYeCcZByVoqhu8rY1baovu6MWlPQHxhDIn4uhJZaU6j8ARi7fISo3G
SUKCNR/DffAIGGR8Unb2+1BbnDDmtPHwtJGZZX7i8iBd6+A97bmlkP2ZtZSS
GUh/u00OYKrzgniZEQgYJdF5bDAKYC9yLwf+sUjvSkL0gYglxrh6j4ikcldq
cYIDWBLB0dD2OFchMe8irUHwz/KtWNQGOIAKg4BZoKOK1OMa1p+jtvuvw3Fr
fkqbZpKZ11P5h/jEj12DM8dD3z8MhwdH6D7wxEM/3eoIJSAeI3o+I+sIhzM8
PMInr+G3wLNlDePjVzLmT1/DJ4/wC5ym/IwlQguzpvFAP32Ex6/ht3CatRKY
Fr7uNbkQWUepq56YgIi0KxISC0b1iSHdyvvlewQDkQAyGI3c8d6uFJkB/ZeR
R4hnN15eFjNjbhUOhvyDXJnGSvyA1ia7uagP9EDNrYwxr3jiJlyQlpVCg06w
XrKBj5YvT2GMC0uRsNCL0lCibl6r+Trm749fXbCtYh6Ka1mUaQz2FvntYme3
D7M9RJ14ARckIlwAbGGyt2gnEfc4y0LVFVX2C1vkdTlnc2zstWw+yWtBW17S
hbbfoJHRJjh5zpG6MS7gm3VuX7ymtyjpxIQdsDVLfLIUesOHnrPxCtCLxFJ8
6ga1jRMKzD9yAvNfnBy1SnkQNmlFcnRVlnvefvy8hPZedL9IYI8xm4j5HU0P
BDeu+gHymTEjoGyGf5BEamUzXvJcm59gp7MUdl5zb3S6CcpHOA95bx1xy0SJ
1B3CM+cYzYXyhEUtU/00keq3IVEZC1Dwr8X/cF91t/TxI3zKGn5r/M/cHmN8
8G8bMjt98iX7gm8qtkZKshPPMcpInFxIgg4bsHWDQj944brbdvpDoNcc2F+3
/tALvdse36sfHNdt2UXrzgAvDNwXvmF/UtW/1LIv7Lgv6Mhp84bjfdIvDN0X
XhC09dNCuVpmSXeH+iToaQNWPAjtYa3WLzHeGCcLH9OK0gg9TAk67JhrbryI
ez8cHYP1wzDNIooYIWbIUccjY+YvZTa1nVDgR1SkCJpY/KJFkRIUIZHHEr2p
DfZKexrZs0wxQQtK6dEoxYG1NRsUEUjC1dnz4wU5Ieu486taEIXeQgCMDNbr
uXz+iC31mLW9TRgTvmPSSYx2zy4A4JORe2O0TQL37wcLY1kggAId393TqiFI
GOQ3OsyeUct5C4PIJDKFsGOlQzZMsgAuhNmfzRZoDru3xAk5dUKSJcZvtuRC
YAR2HGivJlasgjHMaG0sCsP5MWS8KaGHTn3CUAfMaWnpzD8rapAjKkHrhVrG
HJlHIUETyWzQS2UEyBEEkohOM3CatBtQUuuO0jErVsKRyCMdCbGabXKyG+oB
AemnKmSrIw7OIc42mBnh/B5Dt8+lJIQOuLIBb9YnJ6l+4sbjoEPHb46IrKPS
jR3HeT0pMKdoDSLIJLbZYim5AnFNKDgDUhF2wuUCcW8uudkmbo7G9oKuADG9
FBItJ3PUCesW5IMMZwAkkK3FgYTBBmwzJS+khihoM47grwdAYssMyMk0crfm
bl1covJubl/2CnDEzrGy5ZMTPdk+SNEKQnP87YXOdcMTW8JKkqJkmGOk4FVS
wiKHbVnog0CuM/XqnK+TjUk3RHcnBmFXBO/JOpmjFbYN+hMWWKgadlm231re
BRFOcvNxHbVJrWLxDp112+P36tV4offJ0gT7Gauy5BaaaiRtuDRcjoJOQ8em
Evc7OapJ+AXlZR1KPDRVlEhmKWgBoshWfJpmo6S1Mfmqg7WUasnXVAPEprhr
NoN5NiZ2oanINQHDtiTG34xtzNuu6x6OgO3RZIh39umUbTBklqJHZwm6WNxH
qRBDChcnN17gLJ0jmZ2nOUWhpeSr1SUx6DQlDCcYH/2N8o7e4C86VgltuVsN
6x5nOE+DqzhesdaZF+LaQL5FWw6zVAIWbVEa51Y2BZ2Q9mrQt7TtHTNPlyZ8
P3B5Ft/POqbJqWW5hOfo/FAkYtOEVXMxV5CfgghlYPL5KY/D3F+AgElasbTN
ISTd4AMFpnnslpdWxSPrAiItknA0ptIjCyyzR+dYsx/YhJeEiPLHASMYWhS4
RAtfCl+rhqN1d68icl5JsJgVuB3Ndbt7AcTufvcRVggbtonAFkBPKbb6QLvG
HHdhjv4xMSbtt7qNAfPeC21geaR5iYU0jkyQy19rInpo9chmWoFOL4azD2Ou
/GHtSINeXzNi8krKfEYjodC1W/mmzgREt+s8WWDE32KF8hjp+YX55CNlhZSi
p+zXEj7zYZncdvJiM4/tdyxqY7D6KuW4pQtY7gHWngNtptc7pP8FH86PLqxN
R0w6bOFAz2YE0p0EAJUAVshNpzjtBX6ASX36VbdmmGasWG2JLojMpPOeMLTf
2ZIWpC6+xog4VE5AJKQ0nebXb563xNBmv+Rgcvhu3EKQ1r9lgXyIXmlH9DZf
wMRA1xHzkUJiQVXKcMNdFVShBi8tRgibaOhk2RX0pvsjV2l7cJKXBq4mQIW7
RkJEP+YyDWKVzRM3Povnn8VOdmdTyKgKLhMMBTfuTIryMpY1DxYOkH4GUKQr
HxI/HQwvFaUwKntF0ukUYYIR6uscrcsgDOEJ4CLIY8m8liGCSYhUaQHDbeG8
L1pE5K7TJCplIjBNiW9VWOgpEjcVtybnDxAJsVhS4HT5g41kYmDxrhVHqsp4
Vmpjk6i6khoJqV8sS4fnOiXGOOcfcwLUpcRwzRRODDIjgDs0wrWRkiyD43dD
0GevDHcN6YniBtVimc3Ni6OQ8AzYjpSDIeDe6NXjUWMoASDNRTBAy/ga040V
oRJBmXKu6wLrdCnlxng+NxmeZQBLDCDTAL98zuOs3PXmUR3Px6T4YYtwJc9V
h+G1GFeYYbHv4dFLo1TakoNfG8i1qnWLvJ4ZbW7r59gaON/MyJjBKR1EcFh1
JA1hLbWpTHo3Cf1rpK9zQk2QidtEt3X8en0cR8WUbigSLhfjMfh1wjw0fLWN
NQvhbAxVJNxSAQonC0MtrfiOCeqYu7bmcn6g2aubjqxNDPh1MfFnJlbj7ulE
5RKJfHHfkxfGDiZRgQb4tu6XKBfTeYLV7RDTYTSGb025hdwRibaE3esqRqbS
Hqcz6IIrsEK1ym0WI2HRFhuRRmzCIccRocsieeEr7r4esDW27WlVrIpMPOqt
iN17rJ5GPMILlxQSxU2JEFRzwMp997lACXgST828RtOCZtKNqSBPbfJF6189
vCQAKuuw5QmmNm8zbP+Caxj/09fw6J9fMqSBfgy9+dEjPGoNvwWXzi8eGrsN
kR4zQrmG349dw4M/vwtI/jHCb2MEkUtq49Z+rTX8McLvboSf1/1uZF/t9HUr
LFqBmkshl+VodAk/ZENhIaBsPpDI+5IB6yOGnDsldx82S/zE0fVGtKu13x94
Rg6UvGN55sIooVrrwZQw1lFJKBU7j7FpGK2G3LRcxccvgPZpgniNf58colsk
caxXXuZ8GECx6++QPYOuNlKq9CJmg5JS5Lj40OFnleczyTzGqtaKugVQkw0q
IiWLcqMMd/2Ds2XJrjktD2M4lrbWjvFdS4B7k2wLbTY8wD/6QC9YSblgzeqi
5ShloIytsJCDLalJute5ZzdT80t0Cs8WQeIWrZP9U/HNs3XCVex1ywEYRRRx
PZmrgJkMayr9ukwWXDEhnk87VMOPXkG9xqzm5am/RpPXmqZXmO9LyG+KmZTK
RtZk2yOuwBvxLbXJ4Ol0vZ5alUknzTlanJQNl7HF3qckK6TlVG5GDVB0UDdz
T9s1jEu2vkSBl03PkKPMeKr3+GFM8Zh5eYXV9XBmiNVIxRIGy7SfIf6bYmiK
a6SKRskmc71kUy5MV4iRQ38G50QI5dX/zp0K9m6sg/gAtM/PmGS0T810LSiX
vNOVhSyOXleqYMR25eScoRViNQpZJjkfvNT8z3IuhkK2B79WsuwEC27SYJz1
LDSPHQb+oWC7MXFVuWtPvA1GPJgTsbB9Q7Yw7D31d74WW9iWWhfGkVp2ESNM
42W+zmJ7cOSOrb8KXE0G3Rym0YRURS6lSZVwkDinzhvSyVL/2paIih2CK2X8
UtLMljWM/+lr+ISfB+VCJP8/ZQQsmEaVXn7CGh78+V1A8p8+ArP1+0/jt7+L
X2uE3wFG/cS7CciwnTg9dg0P/vwuIPnHCP/0EawGdi/T/EXX8McIv88Rfl7L
FCqcHfxNDFP1cvkzq96RNape9vxUA5EgPhtOUMmoFyd/6rDIObQsUDHNlJ0W
RmgwrzuSBLy945mu/KK+1XdlarOPB+f21o5qJCmWL3WpP0xjqJKOn9/A44IM
/3ZgoG0+3tbuM/3IlthwQ2r5PbqmsV4kFCb73zrGvtTCxElDcmoWx9aKJ7UJ
xeLXMgozVQHm+mzcWMY4wl9J1smzr0GnhtdNjY9qLTVdZ+9yrTK1LGJjoOMK
a22/XB7DS+rlUZxYJ5zF4VXstNfEcGyKKaHypVQUeKbymQbhNMFgDSpw0dTG
AKyi9WEMgBdbw30KtTalSkwkV4dSOix1ewyCY2kSSN5jbEJrKvfpNIEbyuTp
8NHVlZtz26pKVZgaY7AO83kwygQjUji+xNao5haOK4oxTtdZOXjThJlTPRRE
kuRyjcYOjjDKYzjTJTb/oiRir3gio2DvtteG//TxPzv4nyGfee92ZLLkbmJu
u0ptJukofMRKs4hrrGyrEuLVd6EDldNkxHfHoqI/umHG13HGNSppMxQhpCNE
6gY4wlhnzHygx5uUfkxNXxIsl6Pc7A7YAsfxSk1WwZGIxwj+pBN5vzZ1FMVw
G8VhymWTfbs8Rp6Z/GIMMdHJ4A4GLLmOke02mJs6MdSg1K3aWFuf1tIpO5Rs
qOlUPLsQ54CEOre8oL2LmgCMC1ORRpvDbQcgshTLgHz5bc7w/zp6e3wSPD/5
6vTN2V8ajWQaNL2pg9dvjwHoreDfvgx6wV0Dm8IDtgNnOME3v3sxPn314f3J
nxsfGwIIBv+XgT/MMxjkz87w+jEYtUXDPnumhzz7cHR0cnb256DIYkXmWv+Y
8Gqbjjwm8B4WEM8x5qg8xV+CYevehQf03kNrMHUpPXoE0ghD8OTNMcBPRJvg
qQdtLdy8y+N1lHYomxAthnpHDs7gIdbgmIOJTz662C7gqEtLuXuqgWQ8TZ7n
ou4d8mSBVKMzKb1mvKl/Dl6MXJh2dCqu9pCVK71ubzh0bg3f5E7xlvAIuluy
WBue6jainviVR91FtUvh1G7MtIREFj5bMCUOwnms0NwN/1zre61LILIh317A
PC6wDq29ev+iluE/YtQ++eePuKhfDZJ/jPDbGOGPuKg/RvgRI/zMZUmYJXul
MB6Sq55wEX7pK+5JDm1Hnda9gqzxIzY5/gtH43OVH5aQOD9wez8av94jFSJw
ByCNvKIlagUP9eO4KMszn6bmTjgE7EHvvq7z7XVdo1Y0GsY68YdEJUyK+J91
AsIwJQGnZv1oV7O0olmfnLPT4piDbM1lKLcdXzf4RgcC6FWYYAhdc1PZvEVM
2LRlIMx4CMdq+2Zlmo7OvLIJLH7mINPOVdbdsi+Ky0gWq3kSu9kldJKiIGAv
t01exIsArXEJ9mfDNzm/1Wn8Vh9eghqHF3zB73koi/UhTO5QqRE0PbTSaTz1
uGmrUGDTOcylvnRBzXYJ3Vl4S45YW9L0THALYCPm1jhtq6i5khvzs2U1vqb0
ytT8zxkzdbd6pxmA3ACDoIwRE7xxhFVTMeQMyxpGuX6vZJInBXamYPOTM02S
O/EojGm2yRK3Qqdyt+ssSy+RdFApXkM2yPxHSh1Z7dYmb3uVYmBQouY8vFvb
Q1Qp6XpqQpJ0zQuEJZ7eOpdIIOUCwUYHMo3TNg/S9cimFE+n3L9wvjEwKG6o
ESj1HnPL91L0YuSURNjWMtak+sNyLpWEYArhk9U5NkJtSLzHSBiiNm/bqGlT
oz4/MdCi7ZPz25w2bbQj79CxcMmGHuYWS/6jthiy2CTlLiwAvnAMOI8JMlPc
s0sPgRmq3EIhwfoWGFbV8erU4DD2qindPie+VmJO8zFauUWohxX248SlarOF
fT/Xp3CJoKO2VFhEg4gi1tvuuv2MiOOR5RjvuCnz4V8VSkq1dmjaDB9vXmjQ
w8rM2/pYEd5/BcYYEoh0aQtrPo4pZTV32rHVWnkxWDNWC02UiywFnNy4tRW0
HWHO3UJgvH6v9+9mx4GbW2ybksEY66U/SmnGe8MYJebSyY7sAF9Kpxxw+YuZ
pfc7bGm1KP+QkTxoMgXs9/XtzGIpg63mehycEvOOO/w35QyOWfqBc5OHtH3U
EZEiNpJTb8WtlnBT8aECEJ1c6XRqZ4FL3TpWNU84eslr0WQXXu739ElhW7t4
2SFXn96+cx7v9HU1KIiDob/qSIKsy1+w58rmTjqBlS1+hoGi5nCjqZ91rKUt
zjKurpzNvGgZJsKpKRr6VLkE7LLUvFInQpu1FUaYJZ+MNwedVMSlGZyiS1jp
y6F3tu/oKTPBKGW5TtMv6RVorjRf+fkcs83NOqSnZbFZSaO5mGoAqdzhHF7r
xXATUoBmfe47H6F7nz7hzv3Lm+iCKvJuU7keUNoQDe994Jc0C1Uu2u9xF9sI
wu9rF4/++QUTcuso+6eN8Alr+K0ZM1zS71k0zOWoCgfU2qWWjR0GzX0v1MSJ
ByiLuuZFq3fVcsD7xgzLL9ixttyP+0Z7SDO0rVL8jJNqLgzVIS+j1baprYaD
OQbea6zRc1SF5jeVbB78upOuTPlqGvdT3dk2COWT/NkilFW82KLU/igntkbJ
ei+28VNrx3WN3+gi0PE1jifNYPrDvmx/BeTM3n/Il9342EBgaD92eYxnOEIn
2PnzFtevv7ptvl8r9sAvxSY4oocRFG8MSIWCHVWdv+btV3GEpSrlybunntSN
cmqNcM59BG0oDupqVskK7pdtqduxMTeUn2rbw6yXgcmKM/UF0ESborBcCKif
Kst1xAlWAtOrDgs2Isx5y6SdY+djt/G0FWpZn9eFizIqtD5B+2oy9XKjQHfO
TWV+ro4jNj7A+CSNeLkJdSIiyGyhRheBLfoWcY6UaQYVJRllhbqhc2LYMl2n
H5ubhzWIWEJ2spy4QlN8u8JpjGFJBz9V1YaLz3Jj7FiieYYG1y0eMGUKIBFS
H8aEDV/exfVIJhEMMthJO2+/vhboFhjPluut8JcdKb5FxoVCCh3261Zq83Ap
h9EtG+a1A80BEvk0kZS2IdxTp4+slytZUgJcUjvWCaFMB98aAN891aSZsUBs
HDp9lFRH3UXb4rVjTq57AWMM0ajikONyVq7bUleTXD2+NQDpiINSu2sczFJq
L52VY0M/04bm8Ozl+G8n/cE+TP5vb07Pzrtn77r7vV6nvz+CVaAati5YbeSN
5Lr9xKGQXjNC0z3CdrA7bAdPnsD/uRg2ZtIiRyZwP2nxuw1MA3371TjXVXnR
5PJk9MSFRNvorVx+cx0SrcjSVZZo+yh+6xRgwpWWUkzxqSeDJ5rc5MHJ0fHZ
+BmsvbOzP9R7eQXDL8NmIB83fUb+Q/1eglYbtDa9I2LMWF830uDXl5GpmWS7
bqGytpWK6ZxdobRd0wCby5FxMV+H/iW5lKWs5HOCDh3BsHTxhdxvJ9ZLlGT0
+1Q6uWTNy4yVAK8MPlm1VeTGWGEMNQQhZQvjuiO1H+IggpCRJZ+fbIwJms7O
2JJVv2S5ZoT3DFAiYbqOsAufbVPh4BOkO/LO1nPXWLzENrXmpKUqaKWy8ku2
POsimnTktg4t8SnhnSbt1cNkpxSuZUOmluw4gs+Apuqi1o5vBx8cjMRyqEse
UDlME3/16IDQORa8M68Nhk5FVpM+bToP0SGU40ej7QGkXaYtK65W7J1u02Zu
U/nwLbnHLVuY3SBpyV55yY2/k6XX6dL6W/XtQNecrhChz7SmDPBPPdVt/Z79
euxOAvyPBq32u1Bpihqni9YEKAeby0nOTE1qsUmbUhpct3MSb1IRIB0lUw+k
60Y26woOtrRURWvPjetDNDJGN4lZVHPX84YikjUlc3S+tnH3tZon4p8uQ+e8
ypU5jG7NBfseLCH6lpBGd48UdZDgz+9oXiclCpaRdKvAUvTU51LmRWADjRr7
vtrVemI6ExSmru4yNQuyL3tcV2ErbxR8cZEoyqklqeAlF49x3DgyrQgdthah
dTtwv9S1QqkPlTtcllhfX4//3tYiuQcMB7S0RcMT29wMyoUPgrf2GP6lzLgW
GME/ozXSVpNZDeA/cYRPWMNvzehGnLFicSOQoK5uz6zU1ej5puB6uutJh8rn
cAUJuji2Er7TyUdXgUUXS6GuNPl3StFyEzS9HhSZdVSyJWNOYQucsP7SSIZb
opaq49aX2UihCwcRnW45VPp3a5O3u6duTVlmy6Wy+NizIcl1NI7JTsLclYy7
oZBfuDam59wTXbDLRkVa8uviStiDqYsLCjsJIXVxKcwqdGyP1/Qlvo7n0jbB
DTNQUUQBMDi2iLo/X9leb58mPt0pn1yq11uFjQdSmi+m84LjMa1BCmn5p08Q
w1g20kLFGGzssPwqO99pLGR2oJ3pxBhmhvOEOwhiq7zkcmYX0cRS/GtsQJOD
moaH0OJgFN3ihYw4se7LSLMoLOuizcM6OyP5PnbchdTDAfFKjoi13f96+x55
CFrddOF06ckhp/NwgJOyvRctiPBFmRhXhyYkxc1q7hnudBpIZw+1LC2cakjl
WoHHsJRlNJcoJOW1SNmezIjngjF6fJ88oCNbJ85vAYR6KRUHwsPcuq774IOZ
j6ZzUDXHrY1rmsfTwqV39uwkOGrqFYmOSSAh+kQGP8KJZRzikBm1BnmGMj5X
Y1dzwXg6SeoAr4sCCX1BTHStn6ysPlC+u80NNJcgfynnrVL/BrdMs9ueUapB
qU3AnZkorq8efCgrc1+JA+q6DRBjUVT5jeQ7usMHKhFLcQDcPQUodfiouGe3
WCJi/QR1VkD1wm8Awv07EGwIJNulg5U68iMs45tqP3O6D6l29+vwV2zjI82X
6JKZ2U1CnO57+UlgZAJN+vYK2wKQVZJiIxIS7LFMEwLLKJOkRa/k0lbnCfw2
Im7fBWwaYD0bejZhoV8E7le0Q/7mwulQglyN1MFToOS3eo6mVhJ7LTcplo2U
qOCguedGgizYqEvkmbrY6WAKPCLhje5CUDs15be0IeH+Pbd9aFLBb2BYFN+s
M6BE98VttokOEA9CEmrNz24tdDFsCGCIXlDAl1hGNGEj3sQZraT374g1YVuD
+VqckL70btI2DuYtTqrMMdRxB2YqvXfzugZa3Sa62AMWxCp9u0CagYnRJ8Xc
SHizKEFzPH68a9LTBo8NvnrTup92Mhw5wZzp7TthYA9gMDF/QtudHclFF5VP
IokGO45dxdxxtbSaqd5Bv+c8qTFD3y7ASrhg1LiCbR1aweK/Ov3Dfw1Vi7bD
DYT+OV1oK3M+1HP64RF+8hp+eqQI/T0+fvXlzo79+941PDjHJ+/C+XmDBOCd
oPiPGuFRPz+HyikX7I/r9Qtdr59phK3q76+4hl93hJ/ZmuIxWFOsWlhTiSca
uZeDIoLj2IjBUVwWg9lmYUJlyFdvWwe6DUqxXi133NTNPuk78yroIKh6cJyr
1q6so44tMiVyvTJuaubM0oZVlfRy3BRLTGzNhdUx469MTsIj9Vp1hJacdCRh
8OSWX61AvuImLOKvZeHOrjvhp02rZE7xUGLh1fHlFXE2yW1AEHV0ZnFxrk25
2wTghJ0glEtgm5opV59D2wA2QDRd/qw4UscESTOubKFLLazFfT6tjIWSUXw7
A2WsoCaOoDpiCoCBer2Y9o482g+L1dztJg3D9WpTsdLpkjrGnmQVFFADVEJO
H+lIyshAo01iK6tjWWinbR7ohnOsw1CI+gYfoHcH3cc89qmIeGhc2XI6NIdV
NVydhLJ3EMuomSxM9b0W9h+AAjVj1i9r1G6L96JIC2rpRlKy0+RNdF5lklNI
lM7SGxb9i8mcbnQnRF8UR28QPlNcFWn4SwIL4nAGMNb2Hi3jp1J5qKpnXMYX
NkBdJtdaS/lpEdgvKH7d9461AxD2saWb28zculzXxZZUp7ZrPxQflXJMwduW
wAFXKZuhMLFDdA5sK6bzlNj+UHbj0V3EEE7XQWaK6pBJVHduQkiy0bIJ4/Zu
e6C/cte3DKGpi5prCwW7yZu92xcvWmThonm2Gre2GGHMDq1Vge+Lo3I7rfWK
mTXf0TW2JjgM4aweN8gzoe6yrnut2SLhXJmszUvXpU1SoVYroQTw6yyerzT+
+Q7Zeyx+Mr0hWRiUJFEtJvqhckcpRMG7YjaFRuI12cqnU/kA0k7QIYdA0UI7
/DlG9rBp1ai/lOVKtD/fElRp2o7zUN/Rw03Uxr8jxPvHt235KvpuvkqcP7hW
k66zwwzGedJawMUA5mETvIThnO7zf/ky6O/yeNsCOYPgI/zfnZBt7TyKbgNb
npjI6r2z83t/wXavDy+Ap7/M1MTEEQTUERVOFVMtM9OPlvJ3qVobV++nS4U4
DUMQhAm/vwwcaJfX1An6ey0strTzbVfehMmniTjVeVK4IURWcRxAmAL3hx98
RwPjBxj22t8Lvgiag53gc+dLnLWF4a/+vLJJbFpAeLRMlx3kV7o5pKHk7pQI
UrOtfzRLK/giGLQOv6U7YkZ7LLCds6axOAATaRCtxl+JjnKqrKiyoP63mKGu
5vz8YxdzwzZFdG+gkEYNNeo5Z9AE5bgFb+nnvlPRXJ/3tiXxJNqsbGc4fkVs
QWKHUdg03716d+pOgpcJztub9ItgK2JVYewOTPirLxj+vVBFOBPYelPSjUNw
ulTgMffZ/04qdW2txOWRvG3R2MdMwCkIOxd9AqWJSsr4TZphZDdKUnkYL5Ft
UC62KRL1YCNQuuQoPDNGknGdaAIlmaME3NTWtJbpIwF6yf0iFxuLpSexa/vW
o7UkFglEvIGuIYq7KShxwbMD10mUk/gS/ViFxHg4UaaVmb7AdWuZUwOp7aTl
+ssy2eU3iqTx/15zTiJlaNy7afI4v7dRvnnwJ/jTC+8FXTCL/yfnA60UbHDb
TzPXvUxRhyHpCWNVFitayiTj7MV5Qp5zpxCCJujR/Sbdysxdgmuz1Gm15blu
2xQ3s0DfGMIFc3CzNSY4N11vMK7gw1nwYjymJ96v2e82Hnf6w6MX76l9kNPD
vVq0whQw9XTRlunN7UioW2LkuF+vaS4fOWgCzwbkRWiaKG/UqDfBDnqrU7gK
LXYs39f/Q4tp5D7fLNUCBuUoLbf2qlu8pYVxRaYMgSxHv1q7nr6sR7rb1AQZ
2IA8kem9cKV2bTk9wBBKnUaUNnm3D8TpSWQZqUkYeuhkvALa8Br86nXVgFyu
vqAjE5u1xT5bXHjALcmgw94O/E+dqiwmWJcV0Ao2tbre2ng1xivl1hTV+fdy
QIqPBX2bhPZ8GkFznlzZk9Oz4yFVp+FAVhTXt5ZEFG7FLX7ErbIWvyXhDzOL
LJeGtWT9mWjjikmaV/4hitcOAyIUh6cnxZqqRdQoHUbml+iIP0uQD5ADTlfh
SfUiFTy8jKfs4VSlg6fN4oRrDMooKI8lFM8Vuc0AR5XEeGfkKm3b2bYQH4z+
NMnwS/80+W6UdnX3tDavgvRyUIZMQHjmEmpSRjC4vz/aoV7D2N+NnNC4iEOK
lrmnybB1OFIuyngV37aD92NM4MMEiIS7blFGCMXQfHXyprPT+rNNNSG7BOLZ
SHcx79Ioxh1GkYW3JocDUykAuNPkFu0qcYaO3h+zUlhjG1NnfsJCGzs/bmon
x9HOd3rcGbVp1j43mv+0RfGSGkNvRQrI+famTpLF2ESZ3qy9JXpQMdN9teTK
81Ik+YUbGH5S8etK7evggdrX90IHfxtsOR1hZyQl5jEXevaqFXj4H6bzuSmX
IzMynPmOvXXiX+6e3lfEAHvtnTm+eDQtJ4uVCqW4UMZFM6jwlo5BqzsXayzi
zAzqiX4TkwpHhYQo2wZ0YiTTOujPpvthf7plTLLTDKMOsRqK9BJkXGDw5m2u
qiLLMgzFLb+idwFnaooKkd2JGuol38fB+xeAqHCKBcExIdbYYo5pq110gyO4
w5nSyTBCuWFbdCxJwSEPyDpUW/CvtnxLritTILtaT4HjJ5w3YDZRmplM2FRA
iwKukJZP1CTR5c8syuHsEapAhQnloCJdNvlWQpeMcyIpqDi7W9/EDZUCFJwm
l2tBhSbldsLlWeiCVPc00aOvARR5SndNDEOm1Fx9lQyq9wEDJHmRVy3bpVk4
iJGkLb4sQPA7ItCUBYlDUPM6wflNiqqzDJ3m5dwjV7BQwRGIwFRxKwcdIkty
pAEEBhGVD4PnQAjCAGNNdbV9wt8zqqnWEoO1aOu6Znwpa8SMdRbPpzQUX1XY
2ulxi1Y9Zn+ERNFpe5JfpohO30f5LXtEuYOHrYnBq5mHWjJqsFZloEMZyxNg
SjVxTImfYUvSwf32pRzOXyku/bG1ZWynUBvnWnrD3Zla2TZmB6ja6dR7zIp4
JK1tnHAtjv/XPgSSk5Ybixv+zkjmvQSKsvSQBJUQKr5H9Nkp347ikOWzZjEw
DAWx8Tlsn60gSgb0V61yMsNoidNWj+eKZrbampXfsXraIfMY7Y/ActPWsVKt
WVWpjXZe0oxI/lRGdyGthKwZZAXBB9UNrsAkfHD4lEvdVvOUq5CZS2Txptqs
guwbC7VqB1GSc17wMoiB1pEfqzwEn4+3YFOCPEO2bRwiQH+lhQbWAgQ+kGKb
DXadUGFOt4GnmYZSyRgJkW2icnZOD47zHFZAhPLuKb3bUeYjQMdxpVZDlkQd
ehDlV5zEL7OkC5o7xFwIJIkxbPJw/U1eNLzNtZvEEjNqa8VJMUTrG2LnMz2g
y/6lvJgI+d0qpZ3oKoXwOjER7s2RTu3tNMH3eWk69HNpTu0o43BCSYSSFTD/
S/igTTY9V/yaqowv5zVl6Tfd0mlFOY0dfp8Cu5oVlMaU664pfP6eh8NgZ5vO
W4tzvLl2eRecH47h+LB+zQlVSI70QpqZcjwctUatQgtdNnhyzlkmy+t0fk22
Cfa7kWtqtslpSzdphsGKtEphfrbJL00fzlWyECenTO+UmnclBpSoUIowaf3u
0SYYXJhxSux8riZpxivhfjWZfZYK6mHaGyaITTYtGskBB/4piEEm8u39WtX9
1hoXP/QVS5Zs1MDH4rmIwHJ7fV5Qboxdc7Eof5BYcw4ydshF69wZPGeoritI
yk3lShLZd2I31dIduTww1XK4TvK1lrT0F/ZsAXkSKX1LYrTBDvNU7ub3ENZx
dcDcuqHIYk7XBnB0VUjmZBbnGBch1goboz1BJea/WQJAt7nk0pnzm4J6z0qS
vkKw67qBuWgkO6AoBnmGp7DULhy2tclcJDph0h8HtuZhutI5+G6WIxpoz9YL
KrKKQkYUZXi1hJt6plsy1Hby9UIqLFgx0jEU+EoUxbeaIcspliBdov52GLwB
TRNkn3QqNwrTr+xKrJb8YI92X46radQeaB66tVk76ZKHmAx9TdB/i8aEfJas
7l1UrXqvSkLJL7nkgbPk51wR5J8NxR1nSe85P02KIn0iIAlJT8dvxqgvYuBG
pv09T+VzQVbOgZM8Z41lhJFcQRaUFUySsM3Y21aoMmnR5tRsEl1bjKm4yn/Q
dzrfjor1rr5tzopilR8+e3Zzc9PFrLxuml0+A/FEVLv8Ge6H/tO9nRWLeUtn
Relp4S4cskRhhiZitkgoUBGXaTuaOQScKMl6IgqRk+xnlPt7+3YHLzjBR8vm
Nl4hSinDGbZ3yRUnPyP5iohWrFOdMxAexKy6PbtZh0oBjcA9nR6N3wLFwCE7
XKajc3qMmurYrMEcig6sCtM0A5TWwgWdubZrkDxfuzLJPeHeaO6KgAifSUZT
jooXKEGwOElStGSNAgtyJ+hKwMu0Guc+PTl/wQoYJoVK4jbaKeA4f7AohSG0
bxCZbFhmcEyy6qo+9tQLALWhmIH7R83f235omN5tr29nN3eN/xabn47s29LE
XYYZ+MNoUgJ/O2hWU/ggdzYFw+z4wxiCUxrG1r0tjSXDDP1h+Na6m3Ly2Fh9
8u/CD+iDdlODzT1DL3OJEthrut+ZgO5IKBJ5d9bPv811uJt89viLWEiFVjM2
+fBS2+xJ7iZVAwCVJL5OgLY1z4T3D7sjDsgDzN7vD3aRbOtIVEFs+JqQggLG
DhiRX1Ag5BGI4m35/YzFU2fgYe3AMmjvdtzjEU9ebLlQzmWhe1JKm/duyqMu
in9LKvfiUddEo1PPmfp9LLJ5zZ/bV0Iw7TBItw9yWDq4yiAAxg5B8d5Btp4X
D/KCB3lBg3h1I0p/fsjrerxU7oaD2Hg7jrIEBM9EbP420o8ysK0J36HOlCpa
mDpsNv2VdKIZu0NFwQJR3aHnYm3l1O4Y06HgYyp943WvYNnYjuO/7uCS7g0m
RZEKdiOt1hlOa5iWvn3Ar10ZxgoVnpUL8P5/6Xz8TkYH+x9JXExRHPiLFBnC
GvDztWsPUiTix52bOL4K+C0pbadbAoB2nrC2QwVqMk78rYK1G3yjTUyq8Idq
bzsJ4rFxQgAjD8I1zRDFy00VgLJt9iqg7Xi9ZCoNTyb4Uki2fs0fZQVUWQvf
QMbdhRu9TDBES/BFN5mkJL3VXC2N3Zfqjkg2P/VJzdeXQCwNfQSFB00EyGg2
tviKkSUtsm49PTbGZJzOb/KwOQBajgDLH+lA+ME+qHWbXFs8JkSBCysNnH31
WU5hKUuaBscBMTedr0XjBF0rDtcUHVsjyr7nqnxjLryH6YzaE9/0SwOZYkOt
YE7OdannJ4ZmdvuwbZMEIIxa4nuOkbL0BsPMBjr7TJG0bi4AKPY9Us+0Do3m
VlT2x0dau6PTRWMC2tt5NXg1m9rKoTNjF2lkTBUtm8Z5GS/XmOugba5tnTMe
ZqDa4kgcmARLRgHeesI+2HxMN1R7i+uMoiV4NG5E4FlOCBes1Re9TWK6Es8L
4xf8fRVvcs43p7idpWIvIUnc4he7Xs8x3YL099Svt4hyZhzOluk8vcRqiDpE
RpJnTihEJ5Om0WZ1OpkFC3nRCzwWL4NLB+GNVxE69mwNEbqnUh82S2cJCC28
WLz+gIHXcKtiqT465w402upnjDriGLR1XhcqK1YzIEU5XSy3lqQtUOGkyopN
IK8OSZagxYTyXBw7DplLTZECv0+HNikVpiRSyS47Ng0frAGVRF3bH8HXL9um
cqVb2DNLUw4gyyTcjc37KsEwSr4BbdOsV7zFUkqD0cryv9K2pYIDRY+Urbhn
hqRtMfC1jcasbalev6aqPh+4pWzrlPmFrgTp0gB0MErpJu3P12VIr+J6+y2p
okwZVFisCZ9qDdvPN8H//T//rx3u//6f/y+QGMrCDyHQEQOI2yoM0W2KuOva
r6k6nTVgt6UQF98DzyTtnoS13pd8BltafzTdUqXidKvWy2J511Ih49TQ9Ie7
xkgvGmCVnkVSUAdUTJJjCo4HpqfIJYuuiCVb3tuiCJRCJQyeaZuqmELvMXPD
pt+/EF0aCLFt7SCvvsKr+XaK4bEzE2tj4CMV34y0xHUA0R1VqRTGjmcgoim5
IaTUrPXQCEgrjp2PNpJMR4dhv4kt1m+2lGecNYZkWkK2QGZgSwJTYm2E3Zga
u5xnw+GQLiUSG/gWhbhCSJzWLOLJxutnP3Vd0QFlbDlW8ZnXY6qKw7IWOxp6
uDswUleLDhVKR2UxswUJDs31kv4lSTVPTXAE8gumxOTGAnSgO0j1hkMUfnLm
1lyLIMJ4nlBJBprOV8NrPE9maaoT88okT4fTcEyFhBkz8WAizaGOM6wDRUYk
UBij9MbdGVN8l4iXYd2uh3TbPwMNNcnmI5eBcGuyPqO1TxoLxRspJ0ksSgQB
2/LZmuEsMZO41xoi4C9CIho8x7JDqbfeIqzOQwl3liDp2+T38+EwJdPA2lYy
bTROPTd6rkNhwllKWobm3ffZiO/jKARvJVAzHh8dQ4Xo8mnFn50uZ0rEUizX
WSlsSAYnzbVKulKlJnWumRhVWKUeUxUhWLKLdffp772uXRzyL8Wv3D5tJCaZ
xeUc6yqhKvXWnzYTX2csG1wqlcl1lW+JnXCLSLu3qPk4mkrhuSbc5RYVrKQg
xqrZOoyrp3QrphBREJe9N69xUXq1PfGDmdP04ZXQFH1tvLDHFrNPqT7qNDtg
3VKyXMgDLMW9WE+bqwwVtGa/j1gOzNnW3EFQVU9emKcXmwGinLriLElGmFiH
kZE0qTJr9NWhGz56YJRuCS2N2Otkz9pmf7pXGUAvBzqly/vwbLoTBVvpTBCC
JX7kLGeNRRpCTkyTyKhlQ5WIvjh1imujxGyWpQKdNlZXEaYmwxgcXc6ZvGzn
9p2xVJQswoQGphiUnGgQC18wwKqWxMeFI+FqKrdATysY3DoEHf54ZUIZ4Q+m
m+2gf+tSeJoKPpKQL1TMhV07keqsa2C+PSGrF4EmORygmp1g7rFxBHulr0uh
+HhwQBNQ4XCZLpKpfX4kZ+m0yRYOqXDWsrInQJsCeyyUcebPP+/vyvuff67d
1A4N5MwT3eSy1PDFQRHMlVwV5t61tB7o4b0uUi4luwHzcoT0jSS1IzJXm+Le
xCIBkEtNh1x1tf+Kq4vBt58PenojQiF4/8fcDpOxlhBf9ORpwsFjFYBSQbpS
8z4mF5ym7oLQY14E588/37EQhZUILN2XvqgcRUuD3u0W4MK+36uB+gMw1pfH
K6ve3G+5RdoddLFnZ7Or3ZwQv5kG7vSgFuD3Acrd3uefD0YOoDRPfwSkQNT4
+s04sL1h3k6nFBhqfHn1rWQbDSkDgUEXebjONevwR0tlNN2xQ0fbSQ6A21Po
J3m222X3b8W3TWe53efPZEMvlyMFC62fHZ++PrFJfszWkNKK9zb0TIKeUKQd
1lxOYaZnMOU/fGhJXx4p5SHVO+IIsTOL0bTgzSTB0ZtSdCVjjcxjTfskotti
1BsJ1ZSwsMhENltN0jbphP/BOFmLbFYT0d3jJbmxmCcbTkfRQFxKpRRQFjSF
4Uvdy2l842SqcXdJV0Gl7e90THaGuxcTK04CKo7P11R7ARLeok2RpBqTHANE
oiCvja3qUm/9zZk18mrf393TaJl3cvmYgxVR2dRWh5WU3u+gNQKr1pXlfsr6
wDThjCbQIwE3JVxpO72s20FchF06fClzQdIrxf8YPd0UOa/BMK3lo3JUWgld
5jdnbn8svUWSDsRGyKyD3pT4g3UuIdETvHh4OFhzhwuCxkwkzJ5MzqA0F9kd
6hiQcYj1xbG7EKnfGJz+fgNI8J/rBKghKG5/Jab7GqkILeivcIirGTn7Cwbk
+L9Agwf8XWXAutvBq1dHHPSuMhZ/gUpuViJoU07+LJ3bPrwRmqNLJeFhEUcq
A6lkGTxHmrZcGj+rlGIkr4qIFSInJUUHjnu9WHZu0L4jFTNoJVw1N2jq2rxE
eVpIyGGmMxBNgXZmiTiaV2myJK6AxnXC9G+SzoukdJVzST4mMxqXG8Rb60VY
xmTOl7gc1OCSS4yb0GZt7IRT7U0mIqqh8VZ7HYOYztE1EodnbJZ+WmCTMiqR
a3KqHKUU6xxHcviLJGUSoVm/Pqgr4JS3AERfqQng8Tw4Sm+DJmonmV4tDEEi
PsXsBDrTEHslR25DawrERL+Via+p3AH81ER3iDNJZ7nSoo+tn43dvLCw1+mM
mmo/T9ehinBdzWMdo3Q2AzyNs4hd6VyLltS8ItRaEFO0AvHtJAPp+OvNMrwC
PGHmemzfvFwnEXfckggBwlyZCRMPC6K2TkAMDHkOxNR2DXMzRBASQHY5LeF9
El4FZ2r+PTaLCkE35YyC16CUw2UD1A2al0grC/78OIGvAJWXuXn0qxRP+AVs
f7ZGd3WzyK/N83CR5mkePI8zGCNKqep0YV59Hs/CGNuxZcmV2sC4SVo4S0DD
KoiWCBP0xPHH71MAZHAMwJwnN+4Xr9dZBgrI34DWwJW72bjfAXyvgr9RPU3n
028UlhqCNxawAPeLdwpY6jdwA4k78ecNDCnAbmZEt3xUPSvIgX33lCqkEh/o
RIm6BETHvIq60jQzJaWApJczjUCBk0DETpdkI2TZhZoPVoLTdQQbjs0SdikK
hpjCkvqekS5W4BHMiSeiTQh0ScRl1Do5D0sc06dIS5dxIaWIUKfJudAE8maY
ArtpcTw50JUVkCJRLIQMEcvHWhGxXnM4x7A5c9t0Ux7Sydmvc2t4jjE6aNML
XPQnILHgyT0xXDvXqWOOUdIr5W42AaRqSdlsQIzZlU6j60bm+QZuYIF3L8w2
qyKFA1vNNsxRdQEI8YPw5aI8gOa7v7XYT4TQm6U3uOl0gvo2brqOAV+i7Eg7
pkKunAAc4KssXpJhm2RLUH+56BFyZZ0dJeu9L4dQKihQ3sy7v30mRirfkUaC
pi5SS2IWzUsh1+gHzYtD2uu7vzk+BR2Vx4Oi6WIeX6NfB2VfrSKa0EztfMl5
c7KgyqA1LfjcfucsqSKscdc4j5NtXtmXE3FKfd8WMSZHJPkir+nlJxa0bSl5
KA6W6hgoyqjg+v2UMB+xsrtKKSqglE3BRaUAFdwyDzmajwyfNXImLOUmiYoZ
1mNgQYtuspxQGdtdCyGApsN2OvFOgyZtPcSMsYuUTkRJ2N7WcvX1ErpoJYmx
vdKlMN6NaxKCMLf1VjCP5Q9PUAeCQDYaJgAbwXVd94tJnnDC5XW8kZrickEz
w+0o0Uh8xQXlbaL88Az1RN2zUsYKOWd2TtPqCBitWpfTXY2TlDLNm+QMKXK3
m5298y0Tv6DEIyrwYZflJAb0CMgNxWKb71GTDaClVw/OlI63w/l+KONMvXgm
ADpWeutS5Ck9aeLYjnBEjqWjUgL3BLDd/7M10O6xkagPxN8hP7OTBc8xVoVC
AtMyRpays9CGuImLmo7cZt3vOHFej/0Vcv9SzGrNwHjDdRW8lRPD6o/9YSkc
CCP0fkB6A1p9dWwUF58ZubHGsOv6EWgoGps9nIQ6PwR/j1E0w7NEORjVeglY
2uIRdar4Vdf9tQ5U0DDBKGf4hYSIbSPKFaSb7uRblcc+Fy+sOcs1h3fqPl5k
5NHzk9UFrSMk+VIeoZZ4dNwNRZOcnLO2oV28CNwCg2hcSNGkGCQZ8dQiH23N
mMoe2A6O/Z9rdoPKKbyltlul3ZD122zpT+56jEZIRjMviISGPwIlaZ6wfxRG
fbfOVvPa4TVUP2F0G8JZJ4dSuC0ofEdMdf7kxtvqOlt4LQ/lNmIDY/hXcoCi
eArCbyGkiTnPMq0Il46Xe8Y3tWTvYduJXNFDvpx3T0HAImNJsJKyCO40qkb/
I05Yc4OFq9XT9NKSUMjEfCxeknOzD+VeAwTwX1qYs6BkWR6fNFVTPCvNvGqS
tDg2KFmfv9T2FUWySjwCJw1E26EsuSjHuMgGLPk41NTj7umGftkO3AcB5u2D
tsEuTues2yZizLJG4mu0oo3jI207ZEqMyYLbh0KUEBng3zLQyZBev0qRxm32
hgU62xfYAIAGFF0bGuMvSgFe9wWbaFnX9WRzDdyKw9WCbKEbM8pNPmTKiNdq
Hf8y22vfsz96HzcZb6OP7R+1R1t3xFGFdANCQTjOjrXkXoi6yErOU/huqf5x
5S2dVukrHD4LYf7RxHTI9URnFPGD7cAWaUkzDkDFpuFlKF/HhaRxrlgnSTLe
IbluvFjpVYpudQlmFXcsL6q8jba+ulS5CI0eEeigEYVuYVTIJegn34vK0NJQ
1Ne8bReD7S5xBFC9aPJN2wUQxaG6gCDYuNyUrMy6Z5HL8Q41w7t7mtIvFUQt
bC/1RUL1S7ehraEZJvbasMzm3R3fckmedFgcBjbEERuCz6U6jI4zT0Q7oOwb
xHQzYEI+akyP82vZTEkK9i4ztpez7XyIlpFp1sU2ux4KcaG5nDVum42uV14R
Ohxhw0xu562g+teVqUVlMb5+BsJ6hdBObgkdpdHT8rF32OcZSJ1QisLM3+jX
p02SF71dbPukTTki1qEWsO6eruiXnxWdtYiG3VWRpt+DzPcQSZVkFPy+lUQ+
dAnOLV38XdwBsicQ1ZLy1o+6FbLLX/xSePW+/BKmwRg+2+RJXqoDxsE1zMyq
hZZqqzZVA48lSGZBNbs21GBQ1CXtldC23jpbi2djWKDhn910+XrBAr6kElJk
TGyzdvzFYvoOITjdegz/wJvvBu0AhE6X7LJww2pyT3Yol95hcdutSuqWnsKr
ZOtBoZ+o33KqQjWxdE3bKQ6FnwxbNs6o4gFD+WGRUgzbFdV0o0p4hZQA09a6
5uCWC1pRYZtNiAFJXuyFDiRhg595qssFnHAjbF2Uhl+pbZJumzVyaSC9Ud2I
OsnDdJ1RqVrSWbDKzxL9c/gA6/loE7pOk8jE5Yoh8/0LQgdA3UWbwng5Ly5j
iRyOm5j6X0ATNsI5gAgjLw6xDvDJOktX0jjDjarSZj8A7YjKAFPwnT5OKiH8
V7VSKCLepN5Z9Upn1ZezKuk0dIpeBdKuieGC73ZoUvZxw3pFVxIn4ckizi6p
bh7qsevc1Ty0Oql7KeQYGcgBHfy3a9vGteOb6zmHQdvWKwgPG0xYUyvUFjhr
k+UdhSmJPzmsL84v0SjfcSuB7yio9Mtg/4AKuY+Cz3G+77B93nemlKp5B1Xc
7zgI58sAuA7WKGs260a0pcBbWIG8pu52QzsLpk7Q8ZY16/iY2kXvw5qbZtHi
EP4i2Gm17Hv1C68d9hErxzJriwRDIeTUTNCVZJ3CGVJsjnJCuDGYkcg/zrJl
n2jy37LW/s5eeWnw9V7d8o5MAKepF4Zd1HXQ0RbL+ooL83CgpWRvVCK2KPJO
xw5ZJy0lUfu09QcbBnXzDGPA4BMb92Q+8l/6oual8hPVQRoPFiWoMQ4/bC9+
hEWZc5x9w2MwCpq7Le+T3aC517r/oYpNt/pSndnX7+pWfal27j2K97tv7oee
oLn97nHVl2rnPgia/d49Q/8Q7AfNgwfn3vE/qbxUswUAVh8mH2wf+wcMqGz2
+/ctD+Ye+p9UtlQ/9w48Nbx37gdWR3OPSi+9eTYufVIzd/mhmrkHMPfOA3Pv
Pjh35egeNfcQ5h49MPfeLzQ3XMP+ffcQ597/hebexfYpD8x98ODclQv1qLlh
xf37bhnRFo+w/Xxzw1uDe0lAgy7DI+buf+rcA7jfg/vvGLYDKXUQMw1BkEP+
yZPi0D1BnD6fqUyyVsgH4nFTm/nEbtSRz9Sk2OQZ50AHRwoUP/roafD/xFnq
P9xoVD9jNa7S90yajoDsYWq8OqHJNbVZvfbRTsNkv8A7h6VQr3EUag6CJ1q/
yOcpgEQyPtwCr5jYXF4CFn3PsSg2viT5R6HyXBixyTHwtxumHV0GScIiCebu
lF0B4Mk8xuDgEgjrPn0QiKp0itxJ7jq90ueeFGttmqHqCzq2Fkvo27QtjqCW
FZhA11tXzPeW9ZIFWrfOpXW4eIohUFIW2FgG1uFMkoqOllYCOYVra7feBeqA
bkAli8JrakB5pZu28bAkHg96uvmzjE+FS9Kl6ZBYiYtkNaV5Abe+74iwwZcg
wF+0yMaia1piQ6KEspUQdmR5kj7wYispN5IB8tMN3qHqjClAfYZ3ucH9x0qA
FBoOU2mxBmROmjvpxolNrEwgtdFxRbTdlm59zk41BiUP0G+XkyNW83VuentL
1sKNbkKJG2Q9oasLxWXJdZzXWD7w2UqKAN4IMpxjlJVJBPFaCL60qWuo2Pf7
rI6+qAmskcapshKdHULBvaHuhogtzE30bL/X+/cqltZlnXDoU7WbDN0eWfhg
9O9eIlod7nRr+3Ro5+MMPaJAYktv0iS6LIdcnjzmKqjXVEODbRSPJI1dKjTu
AbnUVcSpGk32mENSbp1Uw3paJjlt1WWUaiGQjRZmtCXInaGVn64kZexrU8bp
dbGBw45qCph3S7hgOt5iqh0pgpQEgeMsYjRUsdEMA+PRzn6JEdpptmF4m0rm
gL/rqSLKwqFFutcNkW6Mz6aa0lQV9wZok24tWG4G/MifamNx+WHufYZMZ6v0
0aOaVa6cD5+N8LM9+/c+0rJdFGj25MW6pW7vbWx+w6XejX94/sPRD8cf21+3
z9qn7bdB6TPUnv/Ra+9/i3O/evbNP3rf/toz9n/1GQe/+ow7v/qMw199xtGv
PuPurz7j3k+asTEOvrTGZMcGDWoLVoPH2Jd+4/nDDw0aRw8/tNM4fvihYeNr
eEgbtJ99DfJJmrnP9luNU3hC266db3ZajTP8hp0UzhfDVuMtfLHV3g6qzT82
7e+/hWdsuuEW6yHZ0RvfeM9rVnbvK6+9Vx4yUvI7QbDBDVGHQZQQ4IPv4YMT
DCXHPxtP8a/Fqtg45L7xOXzotBB4zHxe43kQ0js627yDn4haWJaqgImXZR7j
mgnOdLq6yF2oQJ4Q/5SUNOOq0sy8+UBHkiR3WkGw5FnOS9dI4SbusuuHA9fd
BFyS2SrJwZiHRyzzQnijtBoWrnjB7reCerFQIqSNZiassV4JIzDx1DrukYSa
TPqac58BJ3k/B/l+mTst6rX9HJ+k+g0opn4Yy9/vx/Q3fLzlAWrjBR/Ag58+
hHavVNxLrhvwN78yqmBMr3H9fZxY/Aek30v3UbeRpYsVbUSJfXPaPsJUotuK
Gdcuxpe4EC773Hx1waZF2Cw+qSbZ39k1c+EDUr6nXsKVcj6lTIFyj4g/cxJJ
juilC+sM7SZMO2CpwEf3AtuI2L4paF94r26sCjVGt7beg81gw3B9XMHLU422
oET3D3emh9O41zvs90aHanAwgQ+mw8PBYLB7GPaGcWMymsbT0U4vGo56oBlM
RgfxRE1Vf3/S60V701Ec9VTY21f7/YO9UW9nODjYm8RqAN/2hv39/o6c5rm3
ljoHuFVfPNqgF9sbDGG5uOReD5YIS4bfRrhiXDCuF5fbc34a+PTjfnZ7A3q2
sQP/DEd7+7v93Wivtxvujga90c7uCH7bHfSGB8Nh+dXGsG6Wft1HsRr1ewfw
yqhmluEUfhvtDXb7e8Pd6d7An+1X2v6P2Is+Xk6zIzJr7FJ0925MlvkKS3lx
IwZEY3NvDT4ORr3e3v6BGX240x9O9ke7w0l/L97dxSPw94+v9MtAuB9j8ZXB
w2jrzoSv7OB0k/3BZNoPDw6i/b3B3k4fvg/3d6a7cRgdTA76+8PBFNAlhIXg
K8Mo2utH+3F/d6Si/n6oDvqRmh4MDg7U3k4ch/ujXrg32lV78cEkHu7iK6Pp
qB9F0VT1pr2DaLI3mUZR3B/Cw729cE/tRlG/t9sP+9FIhfHBEF/ZjQ5UdLB3
MOxFg/2Hjxpf2VO9nUlvCuNN40kv6h/s93f3ACF7o/1wGg4PprA1WGV/D5Au
gr34R2zLdP3Ec56Ycx7EPYAVXIPdXr8/inf3yqhL5/ww/rroS+f8OBzWZ03n
vO1qTXtxqKLRfh+A1wvV3kGvPxooOufBtLcfTUd7uwM13N2JB0O1NxxE/RCQ
Jg4P9vYmE9hfH5jHwV48mNA5Tw7gfHfh+Ed7E0CK/mCwF8ZAD0bDCQwfKRVF
aqh2J/vDvWEU0zkfqN3BdDfcAXQd9PYHu484Z0Dz/TiehBOgLvvhAFEd3hvt
wF0KYY/RKNoDvJ9O98I+bLt0zi4HtEetqbSxmegoJX5Bp8sbDuadORy5gfpO
+czrdgCIvjc6GO7vjab7u/D6MNrtR+HBYDCMw+k+QGcwiYb7u3AXh3Ch+3Tm
g1AN4tF0MNlXsFGA6N5kH1B5uLe7O4FP4snuqD+J92I1hYH26cz39/eHMRzc
vhoMp9FoBEcf+iO7g9KZ14+8jT7TmRtMmgDU94e78R4gBUJi7wBI/+40Otid
DoE27IUjNaSF7YbDcGeys9MDBBpNwqE6GO3HB7vD/l5/Xym101exmqhoZ3d/
Z39XEdHZO4ijQRTGg73dA7hFkdrfARIYRkDrRvtAPuKd0R5gXQzMp7fTJ2q4
H++FvV01AgIWA46pg529nYN+OIFNHOzvjHYOgARNBvHu/v5kD8gdn+f/D/z9
ZMXoTAEA
<!-- [rfced] We have the following questions regarding the use of elements used
for emphasis.
a) Is the intent to use <tt> to denote field names? If so, it does not appear t
o have been
applied consistently. For example, in the explanatory text following figures, <
tt> is
not used for field names.
<t>Authentication Data / Signature: (0 to 255 octets)</t>
Please review and update as needed.
b1) Does <tt>evidence</tt> refer to the Evidence field? Should instances such
as the following be updated to <tt>Evidence</tt>?
<tt>evidence</tt> field
<tt>evidence</tt> data
b2) In the following, should "section" be "field"? Also, should "section of
the structure" be updated to "section of the <tt>UA Signed Evidence
Structure</tt>"?
<tt>evidence</tt> section
<tt>evidence</tt> section of the structure
<tt>evidence</tt> section of the <tt>UA Signed Evidence Structure</tt>
<tt>ASTM Messaged Hashes</tt> section
b3) May we update instances of "UA Signed Evidence Structure" and "UA Signed
Evidence" to include a hyphen (that is, "UA-Signed Evidence Structure" and
"UA-Signed Evidence")?
c) It is unclear why the following appear in <tt>. For example, why do "361"
and "255" appear within <tt>?
<tt>361 - Authentication Data / Signature Length</tt>
<tt>255</tt>
<tt>00 - 04</tt> and <tt>05 - 07</tt> (slots)
<tt>number of padding octets + number of parity octets</tt>
<tt>2019-01-01 00:00:00 UTC</tt>
<tt>wrapperLength</tt>
<tt>manifestLength</tt>
d) Please review the use of <tt> for the following, as <tt> seems to be applied
inconsistently. Please review and update as needed.
<tt>Valid Not Before (VNB)</tt>
<tt>Valid Not After (VNA)</tt>
<tt>VNB</tt>
<tt>VNA</tt>
e) We also note a few instances of <strong> and <em>. Are these necessary?
If so, should they be made consistent? Note that we see a few instances of "N
frames" that are not enclosed within either of these elements.
<strong>16 frames</strong>
<strong>36 frames</strong>
<strong>25 frames</strong>
<em>20 frames</em>
<em>9 frames</em>
-->
<!-- [rfced] Terminology:
Please consider whether any of the following instances of "authentication
message" should be capitalized (i.e., Authentication Message as in RFC 9153).
There are some discrepancies; for example, we also see "a full Authentication Me
ssage".
single authentication message, a DET (and its associated public key),
full authentication message has yet to be compiled.
A pending state where a full authentication message has been received
A state where all authentication messages that have been received, up
A state where all authentication messages that have been received, up
A state where there is a mix of authentication messages received that
A state where all authentication messages that have been received, up
A state where there is a mix of authentication messages received that
vs.
entirely new messages. Using DRIP in [F3411] Authentication message
UAS operation may impact the frequency of sending DRIP Authentication message
s.
these keys are stored on DNS and one use of DRIP Authentication messages
Authentication message framing
Should "Location message" be "Location Message"?
The [F3411] Location message reporting precise UA position and
-->
<!-- [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.
In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
For example, please consider whether the following should be updated:
Sanity
--> -->
</rfc> </rfc>
 End of changes. 142 change blocks. 
1663 lines changed or deleted 1504 lines changed or added

This html diff was produced by rfcdiff 1.48.