<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> encoding='UTF-8'?>

<!-- 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"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<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">
  <!-- xml2rfc v2v3 conversion 3.7.0 -->

  <front>
    <title abbrev="DRIP Auth Formats">DRIP Entity Tag Authentication Formats &amp; and Protocols for Broadcast Remote ID</title> Identification</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-drip-auth-49"/> name="RFC" value="9575"/>
    <author initials="A." surname="Wiethuechter" fullname="Adam Wiethuechter" role="editor">
      <organization>AX Enterprize, LLC</organization>
      <address>
        <postal>
          <street>4947 Commercial Drive</street>
          <city>Yorkville</city>
          <region>NY</region>
          <code>13495</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>adam.wiethuechter@axenterprize.com</email>
      </address>
    </author>
    <author initials="S." surname="Card" fullname="Stuart Card">
      <organization>AX Enterprize, LLC</organization>
      <address>
        <postal>
          <street>4947 Commercial Drive</street>
          <city>Yorkville</city>
          <region>NY</region>
          <code>13495</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>stu.card@axenterprize.com</email>
      </address>
    </author>
    <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz">
      <organization>HTT Consulting</organization>
      <address>
        <postal>
          <street/>
          <city>Oak Park</city>
          <region>MI</region>
          <code>48237</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rgm@labs.htt-consult.com</email>
      </address>
    </author>
    <date year="2024" month="February" day="21"/>
    <area>Internet</area>
    <workgroup>DRIP Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="April"/>

    <area>INT</area>
    <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>
      <t>The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time real-time assessment of trustworthiness of received RID messages and observed UAS, even by Observers lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent recently detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The initial regulations (e.g., <xref target="FAA-14CFR" format="default"/>) and standards (e.g., <xref target="F3411" format="default"/>) for Unmanned Aircraft (UA)  Systems (UAS) Remote Identification (RID) and tracking (RID) do not address trust. However, this is a requirement that needs to be addressed for various different parties that have a stake in the safe operation of National Airspace Systems (NAS). Drone Remote ID Protocol's (DRIP's) goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations.</t>
      <t>UAS often operate in a volatile environment. Small UA offer A small Unmanned Aircraft (UA) offers little capacity for computation and communication. UAS RID must also be accessible with ubiquitous and inexpensive devices without modification. This limits options. Most current small UAS are IoT Internet of Things (IoT) devices even if they are not typically thought of as such. Thus many IoT considerations apply here. Some DRIP work, currently strongly scoped to UAS RID, is likely to be applicable to some other IoT use-cases.</t> use cases.</t>
<!-- [rfced] We have expanded the following terms. Please review and let us
know if any updates are needed.

RF: Radio Frequency
MAC: Media Access Control

Original:
   As defined in [F3411] and outlined in [RFC9153] and
   [RFC9434], Broadcast RID is a one-way RF transmission of MAC layer
   messages over Bluetooth or Wi-Fi.
-->

      <t>Generally, two communication schemes for UAS RID are considered: Broadcast and Network. This document focuses on adding trust to Broadcast RID (Section 3.2 of <xref (<xref target="RFC9153" format="default"/> sectionFormat="of" section="3.2"/> and Section 1.2.2 of <xref target="RFC9434" format="default"/>). sectionFormat="of" section="1.2.2"/>). As defined in <xref target="F3411" format="default"/> and outlined in <xref target="RFC9153" format="default"/> and <xref target="RFC9434" format="default"/>, Broadcast RID is a one-way RF Radio Frequency (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 have no standardized means to assess the trustworthiness of message content, nor verify whether the messages were sent by the UA identified therein, nor confirm that the UA identified therein is the one they are visually observing. Indeed, Observers have no way to detect whether the messages were sent by a UA, UA or spoofed by some other transmitter (e.g., a laptop or smartphone) anywhere in direct wireless broadcast range. Authentication is the primary strategy for mitigating this issue.</t>
      <section anchor="drip-entity-tag-det-authentication-goals-for-broadcast-rid" numbered="true" toc="default">
        <name>DRIP Entity Tag (DET) Authentication Goals for Broadcast RID</name>
        <t>ASTM <xref target="F3411" format="default"/> Authentication Messages (Message Type 0x2), when used with DRIP Entity Tag (DET) DET-based formats <xref target="RFC9374" format="default"/> based formats, format="default"/>, enable a high level of trust that the content of other ASTM Messages was generated by their claimed registered source. These messages are designed to provide the Observers with trustworthy and immediately actionable information. <xref target="auth-state-diagrams" format="default"/> provides a high-level overview of the various states of trustworthiness that may be used along with these formats.</t>

        <t>This authentication approach also provides some error correction (<xref 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 Transports (Bluetooth 4.x).</t>
        <t>These DRIP enhancements to ASTM's specification for RID and tracking <xref target="F3411" format="default"/> further support the important use case of Observers who may be offline at the time of observation.</t>
        <t>A summary of
        <t><xref target="req-sum" format="default"/> summarizes the DRIP requirements <xref target="RFC9153" format="default"/> addressed herein is provided herein.</t>
<!-- [rfced] Please review whether any of the notes in <xref target="req-sum" format="default"/>.</t>
        <ul empty="true" spacing="normal">
          <li>Note: this document should be
in the <aside> element. It is defined as "a container for content that is
semantically less important or tangential to the content that surrounds
it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

          <t>Note: The Endorsement (used in <xref target="drip-link" format="default"/>) that proves that a DET is registered MUST <bcp14>MUST</bcp14> come from its immediate parent in the registration hierarchy, e.g., a DRIP Identity Management Entity (DIME) <xref target="drip-registries" target="I-D.ietf-drip-registries" format="default"/>. In the 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 also assumed that all DRIP-aware entities use a DET as their identifier during interactions with other DRIP-aware entities.</li>
        </ul> entities.</t>

      </section>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <section anchor="required-terminology" numbered="true" toc="default">
        <name>Required Terminology</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
      <section anchor="definitions" numbered="true" toc="default">
        <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>In addition, the following terms are defined for this document:</t>
        <t>Extended Transports:</t>
        <ul empty="true" spacing="normal">
          <li>Use
	<dl>
        <dt>Extended Transports:</dt>
        <dd>Use of extended advertisements (Bluetooth 5.x), service info
        (Wi-Fi Neighbor Awareness Networking (NAN)), or IEEE 802.11 Beacons
        with vendor specific the vendor-specific information element as specified in <xref
        target="F3411" format="default"/>. Must use ASTM Message Pack (Message
        Type 0xF).</li>
        </ul>
        <t>Legacy Transports:</t>
        <ul empty="true" spacing="normal">
          <li>Use 0xF).</dd>
        <dt>Legacy Transports:</dt>
        <dd>Use of broadcast frames (Bluetooth 4.x) as specified in <xref
        target="F3411" format="default"/>.</li>
        </ul>
        <t>Manifest:</t>
        <ul empty="true" spacing="normal">
          <li>an format="default"/>.</dd>
        <dt>Manifest:</dt>
        <dd>An immutable list of items being transported (in this specific
        case over wireless communication).</li>
        </ul> communication).</dd>
        </dl>
      </section>
    </section>
    <section anchor="uas-rid-authentication-background-procedures" numbered="true" toc="default">
      <name>UAS RID Authentication Background &amp; and Procedures</name>
      <section anchor="protocol-desc" numbered="true" toc="default">
        <name>DRIP Authentication Protocol Description</name>
        <t><xref target="F3411" format="default"/> defines Authentication Message framing only. It does not define authentication formats or methods. It explicitly anticipates several signature options but does not fully define those. Annex A1 of <xref target="F3411" format="default"/> defines a Broadcast Authentication Verifier Service, which has a heavy reliance on Observer real-time connectivity to the Internet. Fortunately, <xref target="F3411" format="default"/> also allows third-party standard Authentication Types using the Type 5 Specific Authentication Method (SAM), several of which DRIP defines herein.</t>
<!-- [rfced] In most places, the SAM type is referred to as 0x5.  Should "Type 5" be "Type 0x5" for consistency?

Original:
   Fortunately, [F3411] also allows third party standard
   Authentication Types using Type 5 Specific Authentication Method
   (SAM), several of which DRIP defines herein.</t> herein.
-->

        <t>The standardization of specific formats to support the DRIP requirements in UAS RID for trustworthy communications over Broadcast RID is an important part of the chain of trust for a UAS ID. Per Section 5 of <xref target="RFC9434" format="default"/>, sectionFormat="of" section="5"/>, Authentication formats are needed to relay information for Observers to determine trust. No existing formats (defined in <xref target="F3411" format="default"/> or other organizations leveraging this feature) provide the  functionality to satisfy this goal goal, resulting in the work reflected in this document.</t>
        <section anchor="auth-dns" numbered="true" toc="default">
          <name>Usage of DNS</name>
          <t>Like most aviation matters, the overall objectives here are security and ultimately safety oriented. Since DRIP depends on DNS for some of its functions, DRIP usage of DNS needs to be protected as per best security practices. Many participating nodes will have limited local processing power and/or poor, low bandwidth low-bandwidth QoS paths. Appropriate and feasible security techniques will be highly dependent on the UAS and Observer situation dependent. Therefore situation. Therefore, specification of particular DNS security options, transports, etc. is outside the scope of this document (see also <xref target="dns-security" format="default"/>).</t>
          <t>In DRIP DRIP, Observers MUST <bcp14>MUST</bcp14> validate all signatures received. This requires that the Host Identity (HI) corresponding correspond to a DET <xref target="RFC9374" format="default"/>. HI's MAY <bcp14>MAY</bcp14> be retrieved from a local cache, if present. The local cache is pre-configured with well knowns well-known HIs (such as those of CAA DIMEs) and is further populated by received Broadcast Endorsements (BEs) (<xref target="dime-attestation" format="default"/>) and DNS lookups (when available).</t>
          <t>The Observer MUST <bcp14>MUST</bcp14> perform a DNS query, when connectivity allows, to obtain an HI not a previously known. unknown HI. If a query can not cannot be performed, the message SHOULD <bcp14>SHOULD</bcp14> be cached by the Observer to be validated once the HI is obtained.</t>
          <t>A more comprehensive specification of DRIP's use of DNS is out of scope for this document and can be found in <xref target="drip-registries" target="I-D.ietf-drip-registries" format="default"/>.</t>
        </section>
        <section anchor="rid-trust" numbered="true" toc="default">
          <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>First is the transmission of an entire trust chain via Broadcast Endorsements (<xref target="dime-attestation" format="default"/>). This provides a hierarchy of DIMEs down to and including an individual UA's registration of a claimed DET and corresponding HI (public key). This alone cannot be trusted as having any relevance to the observed UA because replay attacks are trivial.</t>
          <t>After an Observer has gathered such a complete key trust chain (from 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 the claimed DET and corresponding public key are properly registered, but the UA has not yet been proven to possess the corresponding private key.</t>
          <t>It is necessary for the UA to prove possession by dynamically signing data that is unique and unpredictable but easily verified by the Observer (<xref target="ua-attestation" format="default"/>). Verification of this signed data MUST <bcp14>MUST</bcp14> be performed by the Observer as part of the received UAS RID information trust assessment (<xref target="trust-assessment" format="default"/>).</t>
          <section anchor="dime-attestation" numbered="true" toc="default">
            <name>DIME Endorsements of Subordinate DETs</name>
            <t>Observers receive DRIP Link Authentication Messages (<xref target="drip-link" format="default"/>) containing Broadcast Endorsements by DIMEs of child DET registrations. A series of these Endorsements confirms a path through the hierarchy, defined in <xref target="drip-registries" target="I-D.ietf-drip-registries" format="default"/>, from the DET Prefix Owner all the way to an individual UA DET registration.</t>
            <ul empty="true" spacing="normal">
              <li>Note:
          <t>Note: For the remainder of this document document, <tt>Broadcast
          Endorsement: Parent, Child</tt> will be abbreviated to as <tt>BE:
          Parent, Child</tt>. For example example, <tt>Broadcast Endorsement: RAA, HDA</tt> will be abbreviated to as <tt>BE: RAA, HDA</tt>.</li>
            </ul> HDA</tt>.</t>
          </section>
          <section anchor="ua-attestation" numbered="true" toc="default">
            <name>UA Signed Evidence</name>
            <t>To
<!-- [rfced] Please clarify; how does "that is signed over" relate to the
earlier part of the sentence?

Original:
   To prove possession of the private key associated to the DET, the UA
   MUST send data that is unique and unpredictable but easily validated
   by the Observer, that is signed over.
-->

            <t>To prove possession of the private key associated with the DET, the 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 Observer receives this UA-signed UA signed Evidence from DRIP-based Authentication Messages (<xref (Sections <xref target="drip-wrapper" format="default"/> format="counter"/> or <xref target="drip-manifest" format="default"/>).</t> format="counter"/>).</t>
            <t>Whether the content is true is a separate question which that DRIP cannot address, but validation performed using observable and/or out of band out-of-band data (<xref target="reqs" format="default"/>) are is possible and encouraged.</t>
          </section>
        </section>
      </section>
      <section anchor="auth-message" numbered="true" toc="default">
        <name>ASTM Authentication Message Framing</name>
        <t>The Authentication Message (Message Type 0x2) is unique in the ASTM  <xref target="F3411" format="default"/> Broadcast standard standard, as it is the only message that can be larger than the Legacy Transport size. To address this limitation around transport size, it is defined as a set of "pages", each of which fits into a single Legacy Transport frame. For Extended Transports, pages are still used but all they are all in a single frame.</t>
        <ul empty="true" spacing="normal">
          <li>Informational
        <t>Informational Note: Message Pack (Message Type 0xF) is also
        larger than the Legacy Transport size but is limited for use only on
        Extended Transports where is can be supported.</li>
        </ul> supported.</t>
        <t>The following sub-sections subsections are a brief overview of the Authentication Message format defined in <xref target="F3411" format="default"/> for better context on how DRIP Authentication fills and uses various fields already defined by ASTM <xref target="F3411" format="default"/>.</t>
        <section anchor="auth-page" numbered="true" toc="default">
          <name>Authentication Page</name>
          <t>This document leverages Authentication Type 0x5, Specific 0x5 (Specific Authentication Method (SAM), (SAM)) as the principal authentication container, defining a set of SAM Types in <xref target="drip-authentication-formats" format="default"/>. Authentication 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">
            <name>Standard ASTM Authentication Message Page</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|  Page Header  |                                               |
+---------------+                                               |
|                                                               |
|                                                               |
|                     Authentication Payload                    |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
          </figure>
          <t>Page Header: (1
<dl><dt>Page Header:</dt><dd><t>(1 octet)</t>
          <ul empty="true" spacing="normal">
            <li>Authentication
          <t>Authentication Type (4 bits) and Page Number (4 bits)</li>
          </ul>
          <t>Authentication Payload: (23 bits)</t></dd>

          <dt>Authentication Payload:</dt><dd><t>(23 octets per page)</t>
          <ul empty="true" spacing="normal">
            <li>Authentication
          <t>Authentication Payload, including headers. Null padded. See
            <xref target="auth-payload" format="default"/>.</li>
          </ul> format="default"/>.</t></dd>
</dl>
          <t>The Authentication Message is structured as a set of pages per <xref target="astm-auth-page" format="default"/>. There is a technical maximum of 16 pages (indexed 0 to 15) that can be sent for a single Authentication Message, with each page carrying a maximum 23 octet 23-octet <tt>Authentication Payload</tt>. See <xref target="drip-restrictions" format="default"/> for more details. Over Legacy 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 Authentication Message Pages, the structure is further wrapped by outer ASTM framing and the specific link framing.</t>
        </section>
        <section anchor="auth-payload" numbered="true" toc="default">
          <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 target="F3411" format="default"/>. This data is placed into the <tt>Authentication Payload</tt> shown in <xref target="astm-auth-page" format="default"/>'s <tt>Authentication Payload</tt>, spanning format="default"/>, which spans multiple <tt>Authentication Pages</tt>.</t>
          <figure anchor="astm-auth">
            <name>ASTM Authentication Message Fields</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|                     Authentication Headers                    |
|                               +---------------+---------------+
|                               |                               |
+---------------+---------------+                               |
.                                                               .
.                Authentication Data / Signature                .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
|      ADL      |                                               |
+---------------+                                               |
.                                                               .
.                       Additional Data                         .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
          </figure>
          <t>Authentication Headers: (6
<dl><dt>Authentication Headers:</dt><dd><t>(6 octets)</t>
          <ul empty="true" spacing="normal">
            <li>As
          <t>As defined in <xref target="F3411" format="default"/>.</li>
          </ul>
          <t>Authentication format="default"/>.</t></dd>
          <dt>Authentication Data / Signature: (0 Signature:</dt><dd><t>(0 to 255 octets)</t>
          <ul empty="true" spacing="normal">
            <li>Opaque
          <t>Opaque authentication data. The length of this payload is
            known through a field in the <tt>Authentication Headers</tt>
            (defined in <xref target="F3411" format="default"/>).</li>
          </ul>
          <t>Additional format="default"/>).</t></dd>
          <dt>Additional Data Length (ADL): (1 (ADL):</dt><dd><t>(1 octet - unsigned)</t>
          <ul empty="true" spacing="normal">
            <li>Length
          <t>Length in octets of <tt>Additional Data</tt>. The
          value of <tt>ADL</tt> is calculated as the minimum of <tt>361 -
          Authentication Data / Signature Length</tt> and <tt>255</tt>. Only
          present with <tt>Additional Data</tt>.</li>
          </ul>
          <t>Additional Data: (<tt>ADL</tt> Data</tt>.</t></dd>
          <dt>Additional Data:</dt><dd><t>(<tt>ADL</tt> octets)</t>
          <ul empty="true" spacing="normal">
            <li>Data
          <t>Data that follows the <tt>Authentication Data /
          Signature</tt> but is not considered part of the <tt>Authentication Data</tt>
          Data</tt>, and thus is not covered 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
          target="fec-details" format="default"/>.</li>
          </ul> format="default"/>.</t></dd></dl>
        </section>
        <section anchor="specific-authentication-method-sam" numbered="true" toc="default">
          <name>Specific Authentication Method (SAM)</name>
          <section anchor="sam-data" numbered="true" toc="default">
            <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>Authentication Data/Signature</tt> Data / Signature</tt> field in <xref target="astm-auth" format="default"/>.</t>
            <figure anchor="sam-frame">
              <name>SAM Data Format</name>
              <artwork align="center" name="" type="" alt=""><![CDATA[
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
+---------------+---------------+---------------+---------------+
|   SAM Type    |                                               |
+---------------+                                               |
.                                                               .
.                     SAM Authentication Data                   .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
            </figure>
            <t>SAM Type: (1

<dl><dt>SAM Type:</dt><dd><t>(1 octet)</t>
            <ul empty="true" spacing="normal">
              <li>The
            <t>The following SAM Types are allocated to DRIP:</li>
            </ul> DRIP:</t>
            <table align="center">
              <name>DRIP SAM Types</name>
              <thead>
                <tr>
                  <th align="left">SAM Type</th>
                  <th align="left">Description</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left">0x01</td>
                  <td align="left">DRIP Link (<xref target="drip-link" format="default"/>)</td>
                </tr>
                <tr>
                  <td align="left">0x02</td>
                  <td align="left">DRIP Wrapper (<xref target="drip-wrapper" format="default"/>)</td>
                </tr>
                <tr>
                  <td align="left">0x03</td>
                  <td align="left">DRIP Manifest (<xref target="drip-manifest" format="default"/>)</td>
                </tr>
                <tr>
                  <td align="left">0x04</td>
                  <td align="left">DRIP Frame (<xref target="drip-frame" format="default"/>)</td>
                </tr>
              </tbody>
            </table>
            <ul empty="true" spacing="normal">
              <li>Note:
	  </dd></dl>
              <t>Note: ASTM International is the owner of these code points as they are defined in <xref target="F3411" format="default"/>. In accordance with Annex 5 of the ASTM's <xref target="F3411" format="default"/>, the International Civil Aviation Organization (ICAO) has been selected by ASTM as the registrar to manage allocations of these code points. The list of which can be found is available at <xref target="ASTM-Remote-ID" format="default"/>.</li>
            </ul>
            <t>SAM format="default"/>.</t>

<dl><dt>SAM Authentication Data: (0 Data:</dt><dd><t>(0 to 200 octets)</t>
            <ul empty="true" spacing="normal">
              <li>Contains
            <t>Contains opaque authentication data formatted as defined by the preceding SAM Type.</li>
            </ul> Type.</t></dd></dl>
          </section>
        </section>
        <section anchor="drip-restrictions" numbered="true" toc="default">
          <name>ASTM Broadcast RID Constraints</name>
          <section anchor="wireless-frame-constraints" numbered="true" toc="default">
            <name>Wireless Frame Constraints</name>

            <t>A UA has the option of broadcasting to broadcast using Bluetooth (4.x and 5.x), Wi-Fi NAN, or IEEE 802.11 Beacon, Beacon; see <xref target="reqs" format="default"/>. With Bluetooth, FAA and other Civil Aviation Authorities (CAA) mandate transmitting simultaneously over both 4.x and 5.x. The same application layer application-layer information defined in <xref target="F3411" format="default"/> MUST <bcp14>MUST</bcp14> be transmitted over all the physical layer physical-layer interfaces performing the function of RID. This is RID, because Observer transports may be limited.
<!--[rfced] For clarity, may 'transport received over' be rephrased?
Does it refer to the transport over which the data was received?

Original:
   If an Observer can
   support multiple transports it should be assumed to use the latest
   data regardless of the transport received over.

Perhaps:
   If an Observer can
   support multiple transports it should be assumed to use the latest
   data regardless of the transport over which that data was received.
-->
If an Observer can support multiple transports, it should be assumed to use the 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 payload-size challenge in that it can only transmit 25 octets of payload per frame frame, while other transports can support larger payloads per frame. However, the <xref target="F3411" format="default"/> messaging message framing dictated by Bluetooth 4.x constraints is inherited by <xref target="F3411" format="default"/> over other media.</t>
            <t>It
<!-- [rfced] We are having trouble parsing this text.  Please review.  Also, should 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 (<xref target="fec-details" format="default"/>) (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 Error Correction built in, unlike Legacy Transports. For Authentication Messages, this means that over Legacy Transport pages may not received by Observers resulting 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 issue, as the full message (all pages) are is sent using a single Message Pack. Furthermore Furthermore, the use of one-way RF broadcasts prohibits the use of any congestion control congestion-control or loss recovery loss-recovery schemes that require ACKs or NACKs.</t>
          </section>
          <section anchor="paged-authentication-message-constraints" numbered="true" toc="default">
            <name>Paged Authentication Message Constraints</name>
            <t>To keep consistent formatting across the different transports (Legacy and Extended) and their independent restrictions, the authentication data being sent is REQUIRED <bcp14>REQUIRED</bcp14> to fit within the page limit that the most constrained existing transport can support. Under Broadcast RID, the Extended Transport that can hold the least amount of authentication data is Bluetooth 5.x at 9 pages.</t>
            <t>As such such, DRIP transmitters are REQUIRED <bcp14>REQUIRED</bcp14> to adhere to the following when using the Authentication Message:</t>
            <ol spacing="normal" type="1"><li>
                <tt>Authentication type="1">
	      <li><tt>Authentication Data / Signature</tt> data MUST
	      <bcp14>MUST</bcp14> fit in the first 9 pages (Page Numbers 0
	      through 8).</li>
              <li>The <tt>Length</tt> field in the <tt>Authentication
              Headers</tt> (which encodes the length in octets of
              <tt>Authentication Data / Signature</tt> only) MUST NOT <bcp14>MUST
              NOT</bcp14> exceed the value of 201. This includes the SAM Type
              but excludes <tt>Additional Data</tt>.</li>
            </ol>
          </section>
          <section anchor="astm-timestamps" numbered="true" toc="default">
            <name>Timestamps</name>
            <t>In ASTM <xref target="F3411" format="default"/> format="default"/>, timestamps are a Unix-style timestamp with an epoch of <tt>2019-01-01 00:00:00 UTC</tt>. For DRIP DRIP, this format is adopted for Authentication to keep a common time format in Broadcast payloads.</t>
            <t>Under DRIP DRIP, there are two timestamps defined defined: <tt>Valid Not Before (VNB)</tt> and <tt>Valid Not After (VNA)</tt>.</t>
            <t>Valid
<dl><dt>Valid Not Before (VNB) Timestamp: (4 Timestamp:</dt><dd><t>(4 octets)</t>
            <ul empty="true" spacing="normal">
              <li>Timestamp
            <t>Timestamp denoting the recommended time at which to start trusting data in. MUST data. <bcp14>MUST</bcp14> follow the format defined in <xref target="F3411" format="default"/> as described above. MUST <bcp14>MUST</bcp14> be set no earlier than the time the signature (across a given structure) is generated.</li>
            </ul>
            <t>Valid generated.</t></dd>

            <dt>Valid Not After (VNA) Timestamp: (4 Timestamp:</dt><dd><t>(4 octets)</t>
            <ul empty="true" spacing="normal">
              <li>Timestamp
<!-- [rfced] Is this about a reasonable offset? If so, please consider
whether updating "a reasonable time" to "a reasonable offset" would be
more clear.

Original:
      A reasonable time would
      be to set VNA 2 minutes after VNB.

Perhaps:
      A reasonable offset would
      be to set VNA to 2 minutes after VNB.
-->
            <t>Timestamp denoting the recommended time at which to stop trusting data. MUST <bcp14>MUST</bcp14> follow the format defined in <xref target="F3411" format="default"/> as described above. Has an additional offset to push a short time 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 acceptable offset should be used taking and should take into consideration the UA environment, and propagation characteristics of the messages being sent, and clock differences between the UA and Observers. A reasonable time would be to set <tt>VNA</tt> 2 minutes after <tt>VNB</tt>.</li>
            </ul> <tt>VNB</tt>.</t></dd></dl>
          </section>
        </section>
      </section>
    </section>
    <section anchor="drip-authentication-formats" numbered="true" toc="default">
      <name>DRIP Authentication Formats</name>
      <t>All formats defined in this section are the content of contained in the <tt>Authentication Data / Signature</tt> field in <xref target="astm-auth" format="default"/> and use the Specific Authentication Method (SAM, Authentication Type 0x5). The first octet of the <tt>Authentication Data / Signature</tt> of <xref target="astm-auth" format="default"/> is used to multiplex among these various formats.</t>
<!-- [rfced] For readability, may we update the text as follows?

Original:
   When sending data over a medium that does not have underlying FEC,
   for example Legacy Transports, then Section 5 MUST be used.

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"/> MUST <bcp14>MUST</bcp14> be used.</t>
      <t>Examples of Link, Wrapper Wrapper, and Manifest are shown as part of an operational schedule in <xref target="raw-example" format="default"/>.</t>
      <section anchor="bas" numbered="true" toc="default">
        <name>UA Signed Evidence Structure</name>
        <t>The <tt>UA Signed Evidence Structure</tt> (<xref target="drip-data" format="default"/>) is used by the UA during flight to sign over information elements using the private key associated with the current UA DET. It is encapsulated by the <tt>SAM Authentication Data</tt> field of <xref target="sam-frame" format="default"/>.</t>
        <t>This structure is used by the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), Manifest <xref target="drip-manifest" format="default"/>, format="default"/>), and Frame (<xref target="drip-frame" format="default"/>). DRIP Link (<xref target="drip-link" format="default"/>) MUST NOT <bcp14>MUST NOT</bcp14> use it it, as it will not fit in the ASTM Authentication Message with its intended content (i.e., a Broadcast Endorsement).</t>
        <figure anchor="drip-data">
          <name>Endorsement Structure for UA Signed Evidence</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|                      VNB Timestamp by UA                      |
+---------------+---------------+---------------+---------------+
|                      VNA Timestamp by UA                      |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                            Evidence                           .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                              UA                               |
|                        DRIP Entity Tag                        |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                          UA Signature                         |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
        </figure>
        <t>Valid
<dl><dt>Valid Not Before (VNB) Timestamp by UA: (4 UA:</dt><dd><t>(4 octets)</t>
        <ul empty="true" spacing="normal">
          <li>See
        <t>See <xref target="astm-timestamps" format="default"/>. Set by the UA.</li>
        </ul>
        <t>Valid UA.</t></dd>

        <dt>Valid Not After (VNA) Timestamp by UA: (4 UA:</dt><dd><t>(4 octets)</t>
        <ul empty="true" spacing="normal">
          <li>See
	<t>See <xref target="astm-timestamps" format="default"/>. Set by the UA.</li>
        </ul>
        <t>Evidence: (0 UA.</t></dd>
        <dt>Evidence:</dt><dd><t>(0 to 112 octets)</t>
        <ul empty="true" spacing="normal">
          <li>The
        <t>The <tt>evidence</tt> section MUST be <bcp14>MUST</bcp14> filled in with data in the form of an opaque object specified in the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), Manifest (<xref target="drip-manifest" format="default"/>), or Frame (<xref target="drip-frame" format="default"/>).</li>
        </ul>
        <t>UA format="default"/>).</t></dd>

        <dt>UA DRIP Entity Tag:</dt><dd><t>(16 octets)</t>
<!-- [rfced] In the following, is the current DET or UA assumed to be a Specific Session ID?

Original:
   UA DRIP Entity Tag: (16 octets)</t>
        <ul empty="true" spacing="normal">
          <li>This octets)

      This is the current DET [RFC9374] being used by the UA assumed to
      be a Specific Session ID (a type of UAS ID).

Perhaps A (current DET is assumed to be a Specific Session ID):
   UA DRIP Entity Tag: (16 octets)

      This is the current DET [RFC9374] being used by the UA; it is assumed to
      be a Specific Session ID (a type of UAS ID).

Perhaps B (UA is assumed to be a Specific Session ID):
   UA DRIP Entity Tag: (16 octets)

      This is the current DET [RFC9374] being used by the UA that is assumed to
      be a Specific Session ID (a type of UAS ID).
-->

        <t>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>
        </ul>
        <t>UA ID).</t></dd>

<!-- [rfced] We are unsure what "Signature over concatenation" means.  Please review 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>
        <ul empty="true" spacing="normal">
          <li>Signature
        <t>Signature over concatenation of preceding fields (<tt>VNB</tt>, <tt>VNA</tt>, <tt>Evidence</tt>, and <tt>UA DET</tt>) using the keypair of the UA DET. The signature algorithm is specified by the HHIT Hierarchical Host Identity Tags (HHIT) Suite ID of the DET.</li>
        </ul> 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="drip-registries" target="I-D.ietf-drip-registries" format="default"/> or by extracting it from a Broadcast Endorsement (see Sections <xref target="drip-link" format="default"/> format="counter"/> and <xref target="drip-recommendations" format="default"/>).</t> format="counter"/>).</t>
      </section>
      <section anchor="drip-link" numbered="true" toc="default">
        <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" format="default"/>) as a DRIP Link message.</t>
        <t>DRIP Link is important as its contents are used to provide trust in the DET/HI pair that the UA is currently broadcasting. This message does not require 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 when 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 that the full Broadcast Endorsement chain is available offline. See <xref target="drip-recommendations" format="default"/> for further details.</t>
        <figure anchor="link-fig">
          <name>Broadcast Endorsement / DRIP Link</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|                    VNB Timestamp by Parent                    |
+---------------+---------------+---------------+---------------+
|                    VNA Timestamp by Parent                    |
+---------------+---------------+---------------+---------------+
|                                                               |
|                              DET                              |
|                            of Child                           |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                           HI of Child                         |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                              DET                              |
|                           of Parent                           |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                     Signature by Parent                       |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
        </figure>
        <t>VNB
<dl><dt>VNB Timestamp by Parent: (4 Parent:</dt><dd><t>(4 octets)</t>
        <ul empty="true" spacing="normal">
          <li>See
        <t>See <xref target="astm-timestamps" format="default"/>. Set by Parent Entity.</li>
        </ul>
        <t>VNA Entity.</t></dd>
        <dt>VNA Timestamp by Parent: (4 Parent:</dt><dd><t>(4 octets)</t>
        <ul empty="true" spacing="normal">
          <li>See
        <t>See <xref target="astm-timestamps" format="default"/>. Set by Parent Entity.</li>
        </ul>
        <t>DET Entity.</t></dd>
        <dt>DET of Child: (16 Child:</dt><dd><t>(16 octets)</t>
        <ul empty="true" spacing="normal">
          <li>DRIP
        <t>DRIP Entity Tag of Child Entity.</li>
        </ul>
        <t>HI Entity.</t></dd>
        <dt>HI of Child: (32 Child:</dt><dd><t>(32 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Host
        <t>Host Identity of Child Entity.</li>
        </ul>
        <t>DET Entity.</t></dd>
        <dt>DET of Parent: (16 Parent:</dt><dd><t>(16 octets)</t>
        <ul empty="true" spacing="normal">
          <li>DRIP
        <t>DRIP Entity Tag of Parent Entity in DIME Hierarchy.</li>
        </ul>
        <t>Signature Hierarchy.</t></dd>
        <dt>Signature by Parent: (64 Parent:</dt><dd><t>(64 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Signature
        <t>Signature over concatenation of preceding fields (<tt>VNB</tt>, <tt>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> DET.</t></dd></dl>
        <t>This DRIP Authentication Message is used in conjunction with other DRIP 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 Endorsement chain MUST <bcp14>MUST</bcp14> be included in each DRIP Manifest <xref (<xref target="drip-manifest" format="default"/>.</t> format="default"/>).</t>
      </section>
      <section anchor="drip-wrapper" numbered="true" toc="default">
        <name>DRIP Wrapper</name>
        <t>This SAM Type is used to wrap and sign over a list of other <xref target="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 Messages <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 <bcp14>MUST</bcp14> include the Message Type and Protocol Version octet and MUST NOT <bcp14>MUST NOT</bcp14> include the Message Counter octet (thus are fixed at 25 octets in length).</t>
        <section anchor="wrapped-count-format-validation" numbered="true" toc="default">
          <name>Wrapped Count &amp; and Format Validation</name>
          <t>When decoding a DRIP Wrapper on a receiver, a calculation of the number of messages wrapped and a validation MUST <bcp14>MUST</bcp14> be performed by using the number of octets (defined as <tt>wrapperLength</tt>) between the <tt>VNA Timestamp by UA</tt> and the <tt>UA DET</tt> as shown in <xref target="wrapper-check" format="default"/>.</t>
          <figure anchor="wrapper-check">
            <name>Pseudo-code
            <name>Pseudocode for Wrapper validation Validation and number Number of messages Messages calculation</name>

<sourcecode name="" type="" type="pseudocode" markers="true"><![CDATA[
if (wrapperLength MOD 25) != 0 {
  return DECODE_FAILURE;
}
wrappedCount = wrapperLength / 25;
if (wrappedCount == 0) {
  // DECODE_SUCCESS; treat as DRIP Wrapper over extended transport
}
else if (wrappedCount > 4) {
  return DECODE_FAILURE;
} else {
  // DECODE_SUCCESS; treat as standard DRIP Wrapper
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="extended-wrapper" numbered="true" toc="default">
          <name>Wrapper over Extended Transports</name>
          <t>When using Extended Transports Transports, an optimization can be made to DRIP Wrapper can be made to sign over co-located data in an ASTM Message Pack (Message Type 0xF).</t>
          <t>To perform this optimization optimization, the <tt>UA Signed Evidence Structure</tt> is filled with the ASTM Messages to be in the ASTM Message Pack, the signature is generated, and then the <tt>evidence</tt> field is cleared cleared, leaving the encoded form shown in <xref target="set-sig" format="default"/>.</t>
          <figure anchor="set-sig">
            <name>DRIP Wrapper over Extended Transports</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|                      VNB Timestamp by UA                      |
+---------------+---------------+---------------+---------------+
|                      VNA Timestamp by UA                      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                              UA                               |
|                        DRIP Entity Tag                        |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                          UA Signature                         |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
          </figure>
          <t>To verify the signature, the receiver MUST <bcp14>MUST</bcp14> concatenate all the messages in the Message Pack (excluding the Authentication Message found in the same Message Pack) in ASTM Message Type order and set the <tt>evidence</tt> section of the <tt>UA Signed Evidence Structure</tt> before performing signature verification.</t>
          <t>The functionality of a Wrapper in this form is equivalent to Message Set Signature (Authentication Type 0x3) when running over Extended Transports. What the The Wrapper provides is the same format but over both Extended and Legacy Transports allowing Transports, which allows the transports to be similar. Message Set Signature also implies using the ASTM validator system architecture architecture, which depends on Internet connectivity for verification which that the receiver may not have at the time of receipt of an Authentication Message. Message is received. This is something the Wrapper, and all DRIP Authentication Formats, avoid when the UA key is obtained via a DRIP Link Authentication Message.</t>
        </section>
        <section anchor="wrapper-limitations" numbered="true" toc="default">
          <name>Wrapper Limitations</name>
<!-- [rfced] What does "Observer on the ground" refer to?  Will this be understood by readers?

Original:
   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.
-->

          <t>The primary limitation of the Wrapper is the bounding of up to 4 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 being used, the wrapped data must effectively be sent twice, once as a single framed single-framed message (as specified in <xref target="F3411" format="default"/>) and then again within the Wrapper.</t>
        </section>
      </section>
      <section anchor="drip-manifest" numbered="true" toc="default">
        <name>DRIP Manifest</name>
        <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 in a UA's previous reports without re-transmitting retransmitting them. This is a way to evade the limitation of a maximum of 4 four messages in the Wrapper (<xref target="wrapper-limitations" format="default"/>) and greatly reduce overhead.</t>
        <t>Observers MUST <bcp14>MUST</bcp14> hash all received ASTM Messages and cross-check them against hashes in received Manifests.</t>
        <t>Judicious use of a Manifest enables an entire Broadcast RID message stream to be strongly authenticated with less than 100% overhead relative to a completely 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</tt> (<xref target="bas" format="default"/>) is populated with 8-octet hashes of <xref target="F3411" format="default"/> Broadcast RID messages (up to 11) and three special hashes (<xref target="block-hashes" format="default"/>). All of these hashes MUST <bcp14>MUST</bcp14> be concatenated to form a contiguous octet sequence in the <tt>evidence</tt> section. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the max maximum number of ASTM Message Hashes be used is be 10 (see <xref target="eleven-astm-messages" format="default"/>).</t>
        <t>The <tt>Previous Manifest Hash</tt>, <tt>Current Manifest Hash</tt>, and <tt>DRIP Link (BE: HDA, UA) Hash</tt> MUST <bcp14>MUST</bcp14> always come before the <tt>ASTM Message Hashes</tt> as seen in <xref target="manifest-fig" format="default"/>.</t>
        <t>An Observer MUST <bcp14>MUST</bcp14> use the Manifest to verify each ASTM Message hashed therein that it has previously received. It can do this without having received them all. A Manifest SHOULD <bcp14>SHOULD</bcp14> typically encompass a single transmission cycle of messages being sent, sent; see <xref target="operational-recommendations" format="default"/> and <xref target="operational-proof" format="default"/>.</t>
        <figure anchor="manifest-fig">
          <name>DRIP Manifest Evidence Structure</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|                       Previous Manifest                       |
|                              Hash                             |
+---------------+---------------+---------------+---------------+
|                       Current Manifest                        |
|                              Hash                             |
+---------------+---------------+---------------+---------------+
|                      DRIP Link (BE: HDA, UA)                  |
|                              Hash                             |
+---------------+---------------+---------------+---------------+
|                                                               |
.                                                               .
.                      ASTM Message Hashes                      .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
        </figure>
        <t>Previous
<dl>
<dt>Previous Manifest Hash: (8 Hash:</dt><dd><t>(8 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Hash
        <t>Hash of the previously sent Manifest Message.</li>
        </ul>
        <t>Current Message.</t></dd>
        <dt>Current Manifest Hash: (8 Hash:</dt><dd><t>(8 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Hash
          <t>Hash of the current Manifest Message.</li>
        </ul>
        <t>DRIP Message.</t></dd>
        <dt>DRIP Link (BE: HDA, UA): (8 UA):</dt><dd><t>(8 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Hash
          <t>Hash of the DRIP Link Authentication Message carrying <tt>BE: HDA, UA</tt> (see <xref target="drip-link" format="default"/>).</li>
        </ul>
        <t>ASTM format="default"/>).</t></dd>
        <dt>ASTM Message Hash: (8 Hash:</dt><dd><t>(8 octets)</t>
        <ul empty="true" spacing="normal">
          <li>Hash
          <t>Hash of a single full ASTM Message using hash operations described in <xref target="hash-op" format="default"/>.</li>
        </ul> format="default"/>.</t></dd></dl>
        <section anchor="hash-count-format-validation" numbered="true" toc="default">
          <name>Hash Count &amp; and Format Validation</name>
          <t>When decoding a DRIP Manifest on a receiver, a calculation of the number of hashes and a validation can be performed by using the number of octets (defined as <tt>manifestLength</tt>) between the <tt>UA DET</tt> and the <tt>VNB Timestamp by UA</tt> (defined as
<tt>manifestLength</tt>) such as shown in <xref target="manifest-check" format="default"/>.</t>
          <figure anchor="manifest-check">
            <name>Pseudo-code
            <name>Pseudocode for Manifest Sanity Check and Number of Hashes Calculation</name>

<sourcecode name="" type="" type="pseudocode" markers="true"><![CDATA[
if (manifestLength MOD 8) != 0 {
  return DECODE_FAILURE
}
hashCount = (manifestLength / 8) - 3;
]]></sourcecode>

          </figure>
        </section>
        <section anchor="block-hashes" numbered="true" toc="default">
          <name>Manifest Ledger Hashes</name>
<!-- [rfced] The text specifies three special hashes, but then says "these two hashes".  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 "are"?  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 combined?

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>Previous Manifest Hash</tt>, links to the previous Manifest, and the <tt>Current Manifest Hash</tt> 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.</t>
          <t>The <tt>DRIP Link (BE: HDA, UA)</tt> is included so there is a direct signature by the UA over the Broadcast Endorsement (see <xref target="drip-link" format="default"/>). Typical operation would expect that the list of <tt>ASTM Message Hash</tt>'s Hashes</tt> contain nonce-link 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"/>) format="default"/>), at least 1 one <tt>ASTM Message Hash</tt> MUST <bcp14>MUST</bcp14> be from an <xref target="F3411" format="default"/> message that satisfies the 4th fourth requirement in <xref target="drip-recommendations" format="default"/>.</t>
        </section>
        <section anchor="hash-op" numbered="true" toc="default">
          <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 signing the Manifest. This is encoded as part of the DET using the HHIT Suite ID.</t>
          <t>DET's using
          <t>DETs that use cSHAKE128 <xref target="NIST.SP.800-185" format="default"/> compute the hash as follows:</t>
	  <artwork name="" type="" align="left" alt=""><![CDATA[
   cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash")
]]></artwork>
          <t>For OGAs ORCHID Generation Algorithms (OGAs) other than "5" (EdDSA/cSHAKE128) <xref target="RFC9374" format="default"/>, use the construct appropriate for the associated hash. For example, the hash for "2" which (ECDSA/SHA-384) is ECDSA/SHA-384:</t> computed as follows:</t>
	  <artwork name="" type="" align="left" alt=""><![CDATA[
   Ltrunc( SHA-384( ASTM Message | "Remote ID Auth Hash" ), 8 )
]]></artwork>
          <t>When building the list of hashes, the <tt>Previous Manifest Hash</tt> is known from the previous Manifest. For the first built Manifest 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 Messaged Hashes</tt> section. 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) filled), and <tt>ASTM Messages Message Hashes</tt>. This hash value replaces the null filled null-filled <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="default">
            <name>Legacy Transport Hashing</name>
            <t>Under this transport transport, DRIP hashes the full ASTM Message being sent over the Bluetooth Advertising frame. This is the 25-octet object start that starts with the Message Type and Protocol Version octet along with the 24 octets of message data. The hash MUST NOT included <bcp14>MUST NOT</bcp14> include the Message Counter octet.</t>
            <t>For paged ASTM Messages (currently only Authentication Messages) Messages), all of the pages are concatenated together in Page Number order and hashed as one object.</t>
          </section>
          <section anchor="extended-transport-hashing" numbered="true" toc="default">
            <name>Extended Transport Hashing</name>
            <t>Under this transport transport, DRIP hashes the full ASTM Message Pack (Message Type 0xF) regardless of its content. The hash MUST NOT included <bcp14>MUST NOT</bcp14> include the Message Counter octet.</t>
          </section>
        </section>
      </section>
      <section anchor="drip-frame" numbered="true" toc="default">
        <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 and
   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" format="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>evidence</tt> data (up to 111 octets).</t>
<!-- [rfced] For clarity, please consider the following update.

Original:
   At the time of publication there are no defined
   Frame Types other than an Experimental range.

Perhaps:
   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 MUST <bcp14>MUST</bcp14> define the contents and register for a <tt>Frame Type</tt>. At the time of publication publication, there are no defined Frame Types other than an Experimental range.</t>
        <t>Observers MUST <bcp14>MUST</bcp14> check the signature of the structure (<xref target="bas" format="default"/>) per <xref target="ua-attestation" format="default"/> and MAY, <bcp14>MAY</bcp14>, if the specification of <tt>Frame Type</tt> is known, parse the content in <tt>Frame Evidence Data</tt>.</t>
        <figure anchor="frame-fig">
          <name>DRIP Frame</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
 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
+---------------+---------------+---------------+---------------+
|  Frame Type   |                                               |
+---------------+                                               .
.                      Frame Evidence Data                      .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
        </figure>
        <t>Frame
<dl>
        <dt>Frame Type:</dt><dd><t>(1 octet)</t>
<!-- [rfced] For clarity, may we update the text as follows?

Original (preceding text included for context):
   Frame Type: (1 octet)</t>
        <ul empty="true" spacing="normal">
          <li>Byte octet)

      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 the first octet in <xref target="frame-fig" format="default"/>, leaving 111 octets available for <tt>Frame Evidence Data</tt>. See <xref target="iana-drip-registry" format="default"/> for Frame Type allocations.</li>
        </ul> allocations.</t></dd></dl>
      </section>
    </section>
    <section anchor="fec-details" numbered="true" toc="default">
      <name>Forward Error Correction</name>
      <t>For Broadcast RID, FEC is provided by the lower layers in Extended Transports. The Bluetooth 4.x Legacy Transport does not have supporting support FEC, so with DRIP Authentication the following application level application-level scheme is used with DRIP Authentication to add some FEC. When sending data over a medium that does not have underlying FEC, for example Bluetooth 4.x, then this section MUST <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 higher 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 page data of an Authentication Message. This allows the correction of a single erased page in an Authentication Message. If more than a single page is missing missing, then handling of an incomplete Authentication Message is determined by higher layers.</t>
      <t>Other FEC schemes, to protect more than a single page of an Authentication Message or multiple <xref target="F3411" format="default"/> Messages, is are left for future standardization if operational experience proves it necessary and/or practical.</t>
      <t>The data added during FEC is not included in the <tt>Authentication Data / Signature</tt>, but instead in the <tt>Additional Data</tt> field of <xref target="astm-auth" format="default"/>. This may cause the Authentication Message to exceed 9-pages, 9 pages, up to a maximum of 16-pages.</t> 16 pages.</t>
      <section anchor="enc-single-page" numbered="true" toc="default">
        <name>Encoding</name>
        <t>When encoding encoding, two things are REQUIRED:</t> <bcp14>REQUIRED</bcp14>:</t>
        <ol spacing="normal" type="1"><li>The type="1">
	  <li>The FEC data MUST <bcp14>MUST</bcp14> start on a new Authentication
	  Page. To do this, the results of parity encoding MUST <bcp14>MUST</bcp14>
	  be placed in the <tt>Additional Data</tt> field of <xref
	  target="astm-auth" format="default"/> with null padding before it to
	  line up with the next page. The <tt>Additional Data Length</tt>
	  field MUST <bcp14>MUST</bcp14> be set to <tt>number of padding octets +
	  number of parity octets</tt>.</li>
          <li>The <tt>Last Page Index</tt> field (in Page 0) MUST
          <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 padding, and FEC.</li>
        </ol>
        <t>To generate the parity, a simple XOR operation using the previous parity 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 XOR operations. For Page 0, a 23-octet null pad is used for the previous parity page.</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 Page FEC. The <tt>Additional Data Length</tt> is set to 33 33, as there are always 23 octets of FEC data and in this example there are 10 octets of padding in this example to line it up into Page N.</t>
        <figure anchor="fig-single-fec">
          <name>Example Single Page FEC Encoding</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
Page N-1:
 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
+---------------+---------------+---------------+---------------+
|  Page Header  |                                               |
+---------------+                                               |
|                Authentication Data / Signature                |
|                                                               |
|               +---------------+---------------+---------------+
|               |    ADL=33     |                               |
+---------------+---------------+                               |
|                          Null Padding                         |
|                                                               |
+---------------+---------------+---------------+---------------+

Page N:
 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
+---------------+---------------+---------------+---------------+
|  Page Header  |                                               |
+---------------+                                               |
|                                                               |
|                     Forward Error Correction                  |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
]]></artwork>
        </figure>
      </section>
      <section anchor="dec-single-page" numbered="true" toc="default">
        <name>Decoding</name>
        <t>Frame decoding is independent of the transmit media. However However, the decoding 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 <bcp14>MUST</bcp14> test 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</tt> is performed. In general general, if the <tt>Last Page Index</tt> field is one greater than that necessary to hold <tt>Length</tt> octets of Authentication Data Data, then FEC has been used. Note that if <tt>Length</tt> octets are exhausted exactly at the end of an Authentication Page, the <tt>Additional Data Length</tt> field will occupy the first octet of the following page. The remainder of this page will be null padded under DRIP to align the FEC to its own page. In this case case, the <tt>Last Page Index</tt> will have been incremented once for initializing the <tt>Additional Data Length</tt> field and once for the FEC page, for a total of two additional pages, as in the last row of <xref target="tbl-page-counts" format="default"/>.</t>
        <t>To decode FEC in DRIP, a rolling XOR is used on each <tt>Authentication Page</tt> received in the current <tt>Authentication Message</tt>. A Message Counter, outside of the ASTM Message but specified in <xref target="F3411" format="default"/>, is used to signal a different <tt>Authentication Message</tt> and to correlate pages to messages. This Message Counter is only a single octet in length, so it will roll over (to 0x00) after reaching its maximum value (0xFF). If only a single page is missing in the <tt>Authentication Message</tt> the resulting parity octets should be the data of the erased page.</t>
        <t>Authentication Page 0 contains various important fields, only located 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 MUST <bcp14>MUST</bcp14> be validated by DRIP. The pseudo-code pseudocode in <xref target="decode-pseudo" format="default"/> can be used for both checks.</t>
        <figure anchor="decode-pseudo">
          <name>Pseudo-code
          <name>Pseudocode for Decode Checks</name>

<!-- [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="" type="pseudocode" markers="true"><![CDATA[
function decode_check(auth_pages[], decoded_lpi, decoded_length) {
  // check decoded_lpi does not exceed maximum value
  if (decoded_lpi >= 16) {
    return DECODE_FAILURE
  }

  // check that decoded length does not exceed DRIP maximum value
  if (decoded_length > 201) {
    return DECODE_FAILURE
  }

  // grab the page at index where length ends and extract its data
  auth_data = auth_pages[(decoded_length - 17) / 23].data
  // find the index of last auth byte
  last_auth_byte = (17 + (23 * last_auth_page)) - decoded_length

  // look for non-nulls after the last auth byte
  if (auth_data[(last_auth_byte + 2):] has non-nulls) {
    return DECODE_FAILURE
  }

  // check that byte directly after last auth byte is null
  if (auth_data[last_auth_byte + 1] equals null) {
    return DECODE_FAILURE
  }

  // we set our presumed Additional Data Length (ADL)
  presumed_adl = auth_data[last_auth_byte + 1]
  // use the presumed ADL to calculate a presumed LPI
  presumed_lpi = (presumed_adl + decoded_length - 17) / 23

  // check that presumed LPI and decoded LPI match
  if (presumed_lpi not equal decoded_lpi) {
    return DECODE_FAILURE
  }
  return DECODE_SUCCESS
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="fec-limitations" numbered="true" toc="default">
        <name>FEC Limitations</name>
        <t>The worst-case scenario is when the <tt>Authentication Data / Signature</tt> ends perfectly on a page boundary (Page N-1). This means the <tt>Additional 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 anchor="reqs" numbered="true" toc="default">
      <name>Requirements &amp; and Recommendations</name>
      <section anchor="legacy-transports" numbered="true" toc="default">
        <name>Legacy Transports</name>
        <t>Under DRIP, the goal is to attempt to bring reliable receipt of the paged Authentication Message using Legacy Transports. FEC (<xref target="fec-details" format="default"/>) MUST <bcp14>MUST</bcp14> be used, per mandated RID rules (for example example, the US FAA RID Rule Rules <xref target="FAA-14CFR" format="default"/>), when using Legacy Transports (such as Bluetooth 4.x).</t>
        <t>Under <xref target="F3411" format="default"/>, Authentication Messages are transmitted at the static rate (at least every 3 seconds). Any DRIP Authentication Messages containing dynamic data (such as the DRIP Wrapper) MAY <bcp14>MAY</bcp14> be sent at the dynamic rate (at least every 1 second).</t>
      </section>
      <section anchor="extended-transports" numbered="true" toc="default">
        <name>Extended Transports</name>
        <t>Under the ASTM specification, Extended Transports of RID must use the Message Pack (Message Type 0xF) format for all transmissions. Under Message Pack, ASTM Messages are sent together (in Message Type order) in a single frame (up to 9 single frame single-frame equivalent messages under Legacy Transports). Message Packs are required by <xref target="F3411" format="default"/> to be sent at a rate of 1 per second (like dynamic messages).</t>
        <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 a constituent Authentication Page has been dropped; DRIP FEC could never provide a benefit to a Message Pack, only consume its precious payload space. Therefore, DRIP FEC (<xref target="fec-details" format="default"/>) MUST NOT <bcp14>MUST NOT</bcp14> be used in Message Packs.</t>
      </section>
      <section anchor="drip-recommendations" numbered="true" toc="default">
        <name>Authentication</name>
        <t>To fulfill the requirements in <xref target="RFC9153" format="default"/>, a UA:</t>
        <ol spacing="normal" type="1"><li>MUST: type="1">
	  <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
	  format="default"/>) using the <tt>BE: Apex, RAA</tt> (partially
	  satisfying GEN-3); at least once per 5 minutes. Apex in this context
	  is the DET prefix owner</li>
          <li>MUST: owner.</li>
          <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
          format="default"/>) using the <tt>BE: RAA, HDA</tt> (partially
          satisfying GEN-3); at least once per 5 minutes</li>
          <li>MUST: minutes.</li>
          <li><bcp14>MUST</bcp14>: send DRIP Link (<xref target="drip-link"
          format="default"/>) using the <tt>BE: HDA, UA</tt> (satisfying ID-5,
          GEN-1 and partially satisfying GEN-3); at least once per minute</li>
          <li>MUST: minute.</li>
          <li><bcp14>MUST</bcp14>: send any other DRIP Authentication Format
          (non-DRIP Link) where the UA is dynamically signing data that is
          guaranteed to be unique, unpredictable unpredictable, and easily cross checked by
          the receiving device (satisfying ID-5, GEN-1 and GEN-2); at least
          once per 5 seconds</li> seconds.</li>
        </ol>
        <t>These four transmission requirements collectively satisfy GEN-3.</t>
      </section>
      <section anchor="operational-recommendations" numbered="true" toc="default">
        <name>Operational</name>
        <t>UAS operation may impact the frequency of sending DRIP Authentication messages. When a UA dwells at an approximate location, and the channel is heavily used by other devices, less frequent message authentication may be effective (to minimize RF packet collisions) for an Observer. Contrast this with a UA transiting an area, where authenticated messages SHOULD <bcp14>SHOULD</bcp14> be sufficiently frequent for an Observer to have a high probability of receiving an adequate number for validation during the transit.</t>
<!-- [rfced] For readability, please consider whether the suggested text correctly conveys the intended meaning.

Original:
   It consists
   of the following recommendations for every second:

Perhaps:
   It recommends the following once per second:
-->

        <t>A RECOMMENDED <bcp14>RECOMMENDED</bcp14> operational configuration (in alignment with <xref target="drip-recommendations" format="default"/>) with reasoning rationale can be found in <xref target="operational-proof" format="default"/>. It consists of the following recommendations for every second:</t>
        <ul spacing="normal">
          <li>
            <t>Under Legacy Transport:
            </t>
            <ul spacing="normal">
              <li>Two sets of those ASTM Messages required by a CAA in its jurisdiction (example: Basic ID, Location and System) and one set of other ASTM Messages (example: Self ID, Operator ID)</li>
              <li>An FEC protected FEC-protected DRIP Manifest enabling authentication of those ASTM Messages sent</li>
              <li>A single page of an FEC protected FEC-protected DRIP Link</li>
            </ul>
          </li>
          <li>
            <t>Under Extended Transport:
            </t>
            <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 a DRIP Link</li>
            </ul>
          </li>
        </ul>
        <section anchor="wrapper-operations" numbered="true" toc="default">
          <name>DRIP Wrapper</name>
          <t>If DRIP Wrappers are sent, they MUST <bcp14>MUST</bcp14> be sent in addition to any required ASTM Messages in a given jurisdiction. An implementation MUST NOT <bcp14>MUST NOT</bcp14> send DRIP Wrappers in place of any required ASTM Messages it may encapsulate. Thus, messages within a Wrapper are sent twice: once in the clear and once authenticated within the Wrapper.</t>
          <t>The DRIP Wrapper has a specific use case for DRIP aware DRIP-aware Observers. For an Observer plotting Location Messages (Message Type 0x2) on a map, display 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>
        </section>
        <section anchor="trust-assessment" numbered="true" toc="default">
          <name>UAS RID Trust Assessment</name>
          <t>As described in <xref target="rid-trust" format="default"/>, the Observer MUST <bcp14>MUST</bcp14> perform validation of the data being received in Broadcast RID. This is because trust in a key is different from trust that an observed 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 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. If the validation involves correlating physical world observations of the UA with claims in that data, then the probability is high that the observed UA is (or is collaborating with or observed in real time by) the agent with the key.</t>
          <t>After signature verification of any DRIP Authentication Message containing UAS RID information elements (e.g., DRIP Wrapper <xref target="drip-wrapper" format="default"/>) the Observer MUST <bcp14>MUST</bcp14> use other sources of information to correlate against and perform validation. An example of another source of information is a visual confirmation of the UA position.</t>
          <t>When correlation of these different data streams does not match in acceptable thresholds, the data MUST <bcp14>MUST</bcp14> be rejected as if the signature failed to validate. Acceptable thresholds threshold limits and what happens after such a rejection are out of scope for this document.</t>
        </section>
      </section>
    </section>
    <section anchor="req-sum" numbered="true" toc="default">
      <name>Summary of Addressed DRIP Requirements</name>
      <t>The following requirements as defined in <xref target="RFC9153" format="default"/> requirements are addressed in this document:</t>
      <t>ID-5: Non-spoofability</t>
      <ul empty="true" spacing="normal">
        <li>Addressed
<dl>
      <dt>ID-5:</dt><dd><t>Non-spoofability</t>
        <t>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) format="default"/>), or DRIP Frame (<xref target="drip-frame" format="default"/>).</li>
      </ul>
      <t>GEN-1: Provable format="default"/>).</t></dd>

      <dt>GEN-1:</dt><dd><t>Provable Ownership</t>
      <ul empty="true" spacing="normal">
        <li>Addressed

        <t>Addressed using the DRIP Link (<xref target="drip-link" format="default"/>) and DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) format="default"/>), or DRIP Frame (<xref target="drip-frame" format="default"/>).</li>
      </ul>
      <t>GEN-2: Provable format="default"/>).</t></dd>

      <dt>GEN-2:</dt><dd><t>Provable Binding</t>
      <ul empty="true" spacing="normal">
        <li>Addressed
        <t>Addressed using the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>) or DRIP Frame (<xref target="drip-frame" format="default"/>).</li>
      </ul>
      <t>GEN-3: Provable format="default"/>).</t></dd>

      <dt>GEN-3:</dt><dd><t>Provable Registration</t>
      <ul empty="true" spacing="normal">
        <li>Addressed
        <t>Addressed using the DRIP Link (<xref target="drip-link" format="default"/>).</li>
      </ul> format="default"/>).</t></dd></dl>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-drip-registry" numbered="true" toc="default">
        <name>IANA DRIP Registry</name>
        <t>This document requests two new registries, for DRIP
        <t>IANA has created the "DRIP SAM Type Types" and DRIP "DRIP Frame Type, under Types" registries within the <eref target="https://www.iana.org/assignments/drip/drip.xhtml">DRIP target="https://www.iana.org/assignments/drip">"Drone Remote ID Protocol" registry group</eref>.</t>
        <dl newline="false" newline="true" spacing="normal">
          <dt>DRIP SAM Type:</dt>
          <dd>
  This Types:</dt>
          <dd><t>This registry is a mirror for SAM Types containing the subset of
          allocations used by DRIP Authentication Messages. Future additions MUST
          <bcp14>MUST</bcp14> be done through ASTM's designated registrar registrar,
          which is ICAO <xref target="ASTM-Remote-ID" format="default"/> at the time of publication of this RFC RFC.
<!-- [rfced] This text seems to indicate that the registration procedure
is ICAO <xref target="ASTM-Remote-ID" format="default"/>. Standards Action - should this be called out for clarity?  In addition,
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 and are defined here:</dd>
        </dl> IETF:</t>

        <table align="center">
          <name>DRIP SAM Types</name>
          <thead>
            <tr>
              <th align="left">SAM Type</th>
              <th align="left">Name</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x01</td>
              <td align="left">DRIP Link</td>
              <td align="left">Format to hold Broadcast Endorsements</td>
            </tr>
            <tr>
              <td align="left">0x02</td>
              <td align="left">DRIP Wrapper</td>
              <td align="left">Authenticate full ASTM Messages</td>
            </tr>
            <tr>
              <td align="left">0x03</td>
              <td align="left">DRIP Manifest</td>
              <td align="left">Authenticate hashes of ASTM Messages</td>
            </tr>
            <tr>
              <td align="left">0x04</td>
              <td align="left">DRIP Frame</td>
              <td align="left">Format for future DRIP authentication</td>
            </tr>
          </tbody>
        </table>
        <dl newline="false" spacing="normal">
        </table></dd>

          <dt>DRIP Frame Type:</dt>
          <dd>
  This Types:</dt>
          <dd><t>This 8-bit valued value registry is for Frame Types in DRIP Frame
          Authentication Messages. Future additions to this registry are to be
          made through Expert Review (Section 4.5 of <xref (<xref target="RFC8126" format="default"/>)
          sectionFormat="of" section="4.5"/>) for the values of 0x01 to 0x9F
          and First Come, Come First Served (Section 4.4 of <xref (<xref target="RFC8126" format="default"/>)
          sectionFormat="of" section="4.4"/>) for values 0xA0 to 0xEF. The
          following values are defined:</dd>
        </dl> defined:</t>
        <table align="center">
          <name>DRIP Frame Types</name>
          <thead>
            <tr>
              <th align="left">Frame Type</th>
              <th align="left">Name</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x00</td>
              <td align="left">Reserved</td>
              <td align="left">Reserved</td>
            </tr>
            <tr>
              <td align="left">0x01 - 0x9F</td>
              <td align="left">Reserved</td>
              <td align="left">Reserved: Expert Review</td>
            </tr>
            <tr>
              <td align="left">0xA0 - 0xEF</td>
              <td align="left">Reserved</td> align="left">Unassigned</td>
              <td align="left">Reserved: First Come, First Served</td> align="left"></td>
            </tr>
	    <tr>
	      <td align="left">0xF0 - 0xFF</td> align="left">0xF0-0xFF</td>
	      <td align="left">Experimental</td>
	      <td align="left">Experimental align="left">Reserved for Experimental Use</td>
	      </tr>
          </tbody>
        </table>
	  </dd></dl>
        <t>Criteria that should be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality and whether the registration description is clear and fits the purpose of this registry.</t>
        <t>Registration requests MUST <bcp14>MUST</bcp14> be sent to <eref target="mailto:drip-reg-review@ietf.org">drip-reg-review@ietf.org</eref> and be evaluated within a three-week review period on the advice of by one or more designated experts. experts within a three-week review period. Within that review period, the designated experts will either approve or deny the registration request, and communicate their decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions to successfully register 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>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="replay-attacks" numbered="true" toc="default">
        <name>Replay Attacks</name>
        <t><xref target="F3411" format="default"/> (regardless of transport) lacks replay protection, as it more fundamentally lacks fully specified authentication. An attacker can spoof the UA sender MAC address and UAS ID, replaying (with or without modification) previous genuine messages, and/or crafting entirely new messages. Using DRIP in <xref target="F3411" format="default"/> Authentication message framing enables verification that messages were signed with registered keys, but when naively used may be vulnerable to replay attacks. Technologies such as Single Emitter Identification can detect such attacks, but they are not readily available and can be prohibitively expensive, especially for typical Observer devices such as smartphones.</t>
<!-- [rfced] We are having trouble parsing this sentence. Please review.

Original:
   Successful signature verification, using that key, of a Wrapper
   (Section 4.3) or Manifest (Section 4.4) message, authenticating
   content that is nonce-like, provides trust that the sender actually
   possesses that key.

Perhaps:
   Using that key, successful signature verification of a Wrapper
   (Section 4.3) or Manifest (Section 4.4) message and authentication of
   content that is nonce-like provides trust that the sender actually
   possesses that key.
-->

        <t>Replay attack detection using DRIP requires Observer devices to combine information from multiple messages and sources other than Broadcast RID. A complete chain of Link messages (<xref target="drip-link" format="default"/>), format="default"/>) from an Endorsement root of trust to the claimed sender, sender must be collected and verified by the Observer device to provide trust in a key. Successful signature verification, using that key, of a Wrapper (<xref target="drip-wrapper" format="default"/>) or Manifest (<xref target="drip-manifest" format="default"/>) message, authenticating content that is nonce-like, provides trust that the sender actually possesses that key.</t>
        <t>By
<!--[rfced] We see that "nonce-like" is meant also defined in RFC 9434. Would
you like to update the definition here to more closely match RFC 9434?

Current text:
   The term "nonce-like" means the that data is unique, not accurately
   predictable long in advance, and readily validated by the Observer.

RFC 9434:
   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 predictable long in advance, and readily validated by the Observer. This is described in <xref target="drip-recommendations" format="default"/> (requirement 4) and <xref target="ua-attestation" format="default"/>. The Location message <xref target="F3411" format="default"/> Location message reporting precise UA position and velocity at a precise and very recent time, time is to be checked by the Observer against visual observations of the UA within RF and thus typically visual RF. Thus, Visual Line Of of Sight is typically the recommended form of this data. For specification of the foregoing, see Sections <xref target="rid-trust" format="default"/> format="counter"/> and <xref target="trust-assessment" format="default"/>.</t> format="counter"/>.</t>
        <t>Messages that pass signature verification with trusted keys could still be replays if they contain only static information (e.g., Broadcast Endorsements (<xref target="drip-link" format="default"/>), <xref target="F3411" format="default"/> Basic ID or <xref target="F3411" format="default"/> Operator ID) 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 frequently 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, <xref target="F3411" format="default"/> Operator ID, or <xref target="F3411" format="default"/> Self-ID) remains a vulnerability, unless they are combined with messages containing nonce-like data (<xref target="F3411" format="default"/> Location or <xref target="F3411" format="default"/> System) in a Wrapper or Manifest. For specification of this last requirement, see <xref target="block-hashes" format="default"/>.</t>
      </section>
      <section anchor="wrapper-vs-manifest" numbered="true" toc="default">
        <name>Wrapper vs Manifest</name>
        <t>Implementations have a choice on of using Wrapper (<xref target="drip-wrapper" format="default"/>), Manifest (<xref target="drip-manifest" format="default"/>), or a combination to satisfy the 4th fourth requirement in <xref target="drip-recommendations" format="default"/>.</t>
<!-- [rfced] For readability, may we update this sentence as follows?

Original:
   Wrapper is an attached signature of the full content of one or more
   [F3411] messages, providing strong authentication.

Perhaps:
   Wrapper is a signature attached to the full content of one or more
   [F3411] messages, which provides strong authentication.
-->

        <t>Wrapper is an attached signature of the full content of one or more <xref target="F3411" format="default"/> messages, providing strong authentication. However, the size limitation means it can not cannot support such signatures over other Authentication Messages, thus Messages; thus, it can not cannot provide a direct binding to any part of the trust chain (<xref (Sections <xref target="rid-trust" format="default"/> format="counter"/> and <xref target="trust-assessment" format="default"/>).</t> format="counter"/>).</t>
        <t>Manifest explicitly provides the binding of the last link in the trust chain (with the inclusion of the hash of the Link containing <tt>BE: HDA, UA</tt>). The use of hashes and their length also allows for a larger number (11 vs 4) number of any <xref target="F3411" format="default"/> messages to be authenticated, making it more efficient compared to the Wrapper. However, the detached signature requires additional Observer overhead in storing and comparing hashes of received messages (some that of which may not be received) of with those in a Manifest.</t>
        <t><xref target="operational-proof" format="default"/> contains a breakdown of frame counts and an example of a schedule using both Manifest and Wrapper. Typical operation may see (as an example) 2x Basic ID, 2x Location, 2x System, 1x Operator ID and 1x Self ID broadcast per second to comply with jurisdiction mandates. Each of these messages are is a single frame in size. A Link message is 8 frames long (including FEC). This is a base frame count of <strong>16 frames</strong>.</t>
        <t>When Wrapper is used, up to 4 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 not being able to fit, size constraints, the Link message is left unauthenticated. The total frame count using Wrappers is <strong>36 frames</strong> (wrapper frame count + base frame count).</t>
        <t>When Manifest is used, up to 10 previous messages can be authenticated. For this example 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 anchor="vna-timestamp-offsets-for-drip-authentication-formats" numbered="true" toc="default">
        <name>VNA Timestamp Offsets for DRIP Authentication Formats</name>
        <t>Note the discussion of VNA Timestamp offsets here is in the context of the DRIP Wrapper (<xref target="drip-wrapper" format="default"/>), DRIP Manifest (<xref target="drip-manifest" format="default"/>), and DRIP Frame (<xref target="drip-frame" format="default"/>). For DRIP Link (<xref target="drip-link" format="default"/>) format="default"/>), these offsets are set by the DIME and have their own set of considerations in <xref target="drip-registries" target="I-D.ietf-drip-registries" format="default"/>.</t>
        <t>The offset of the <tt>VNA Timestamp by UA</tt> is one that needs careful 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 received 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 it is not limited by design.</t>
      </section>
      <section anchor="dns-security" numbered="true" toc="default">
        <name>DNS Security in DRIP</name>
<!-- [rfced] We are having trouble parsing "specify DRIP usage of best common practices".  Please consider whether the suggested update accurately conveys the intended meaning.

Original:
   [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"/> specification of particular DNS security options, transports, etc. is outside the scope of this document. <xref target="drip-registries" 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" format="default"/>).</t>
      </section>
    </section>
    <section anchor="acknowledgments" numbered="true" toc="default">
      <name>Acknowledgments</name>
<!-- [rfced] Please consider adding lead-in text to the Acknowledgements section.  For example, "The authors would like the acknowledge the following individuals:".  If this is acceptable, we would also like to start a new list of individuals 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">
        <li>Ryan Quigley, James Mussi and Joseph Stanton
        <li><t><contact fullname="Ryan Quigley"/>, <contact fullname="James
        Mussi"/>, and <contact fullname="Joseph Stanton"/> of AX Enterprize,
        LLC for early prototyping to find holes in the draft specifications</li>
        <li>Carsten Bormann earlier drafts of this
        specification</t></li>
        <li><t><contact fullname="Carsten Bormann"/> for the simple approach of using bit-column-wise
        parity for erasure (dropped frame) FEC</li>
        <li>Soren Friis FEC</t></li>
        <li><t><contact fullname="Soren Friis"/> for pointing out that Wi-Fi implementations would not always give access to the MAC Address, as was originally used in calculation of the hashes for DRIP Manifest. Also, for confirming that Message Packs (0xF) can only carry up to 9 ASTM frames worth of data (9 Authentication pages)</li>
        <li>Gabriel Cox pages)</t></li>
        <li><t><contact fullname="Gabriel Cox"/> (chair of the working group that produced <xref target="F3411" format="default"/>) in for reviewing the specification for the SAM Type request as the ASTM Designated Expert</li>
        <li>Mohamed Boucadair Expert</t></li>
        <li><t><contact fullname="Mohamed Boucadair"/> (Document Shepherd) for his many patches and comments</li>
        <li>Eric Vyncke comments</t></li>
        <li><t><contact fullname="Eric Vyncke"/> (DRIP AD) for his guidance through regarding the documents document's path to publication</li> publication</t></li>
        <li>
          <t>Thanks to the following reviewers:
          </t>
          <ul spacing="normal">
            <li>Rick
            <li><t><contact fullname="Rick Salz (secdir)</li>
            <li>Matt (secdir)"/></t></li>
            <li><t><contact fullname="Matt Joras (genart)</li>
            <li>Di (genart)"/></t></li>
            <li><t><contact fullname="Di Ma (dnsdir)</li>
            <li>Gorry (dnsdir)"/></t></li>
            <li><t><contact fullname="Gorry Fairhurst (tsvart)</li>
            <li>Carlos (tsvart)"/></t></li>
            <li><t><contact fullname="Carlos Bernardos (intdir)</li>
            <li>Behcet (intdir)"/></t></li>
            <li><t><contact fullname="Behcet Sarikaya (iotdir)</li>
            <li>Martin (iotdir)"/></t></li>
            <li><t><contact fullname="Martin Duke (IESG)</li>
            <li>Roman (IESG)"/></t></li>
            <li><t><contact fullname="Roman Danyliw (IESG)</li>
            <li>Murray (IESG)"/></t></li>
            <li><t><contact fullname="Murray Kucherawy (IESG)</li>
            <li>Erik (IESG)"/></t></li>
            <li><t><contact fullname="Erik Kline (IESG)</li>
            <li>Warren (IESG)"/></t></li>
            <li><t><contact fullname="Warren Kumari (IESG)</li>
            <li>Paul (IESG)"/></t></li>
            <li><t><contact fullname="Paul Wouters (IESG)</li> (IESG)"/></t></li>
          </ul>
        </li>
      </ul>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-drip-registries" to="DRIP-REG"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC9153" target="https://www.rfc-editor.org/info/rfc9153">
          <front>
            <title>Drone Remote Identification Protocol (DRIP) Requirements and Terminology</title>
            <author fullname="S. Card" initials="S." role="editor" surname="Card"/>
            <author fullname="A. Wiethuechter" initials="A." surname="Wiethuechter"/>
            <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 solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information 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/rfc9374">
          <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="Wiethuechter"/>
            <author fullname="A. Gurtov" initials="A." surname="Gurtov"/>
            <date month="March" year="2023"/>
            <abstract>
              <t>This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification (UAS RID) and tracking.</t>
              <t>Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third-party identifier endorsement.</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/rfc9434">
          <front>
            <title>Drone Remote Identification Protocol (DRIP) Architecture</title>
            <author fullname="S. Card" initials="S." surname="Card"/>
            <author fullname="A. Wiethuechter" initials="A." surname="Wiethuechter"/>
            <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 services to support Unmanned Aircraft System Remote Identification and tracking (UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements 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>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9153.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9374.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9434.xml"/>

        <reference anchor="F3411" target="https://www.astm.org/f3411-22a.html">
          <front>
            <title>Standard Specification for Remote ID and Tracking</title>
            <author>
              <organization>ASTM International</organization>
            </author>
            <date year="2022" month="July"/>
          </front>
          <seriesInfo name="ASTM" value="F3411-22A"/>
          <seriesInfo name="DOI" value="10.1520/F3411-22A"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 protocol 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>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
          <front>
            <title>SHA-3 derived functions: Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash</title>
            <author fullname="John Kelsey" surname="Kelsey">
              <organization>Information Technology Laboratory</organization>
            </author> surname="Kelsey"/>
            <author fullname="Shu-jen Change" surname="Change">
              <organization>Information Technology Laboratory</organization>
            </author> Chang" surname="Chang"/>
            <author fullname="Ray Perlner" surname="Perlner">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author>
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
              <address>
                <postal>
                  <country>US</country>
                  <city>Gaithersburg</city>
                </postal>
              </address>
            </author> surname="Perlner"/>
             <date month="December" year="2016"/>
          </front>
          <seriesInfo name="NIST Special Publications (General)" Publication" value="800-185"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/>
        </reference>

      </references>
      <references>
        <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="Wiethuechter">
              <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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-drip-registries-14"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when 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 Considerations 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 5226.</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/rfc9364">
          <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 called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to 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>

<!-- [rfced] [I-D.ietf-drip-registries] IESG State: I-D Exists -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-drip-registries.xml"/>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>

        <reference anchor="FAA-14CFR" target="https://www.govinfo.gov/content/pkg/FR-2021-01-15/pdf/2020-28948.pdf">
          <front>
            <title>Remote Identification of Unmanned Aircraft</title>
            <author>
              <organization/>
              <organization>Federal Aviation Administration (FAA)</organization>
            </author>
            <date year="2021" month="January"/>
          </front>
        </reference>

        <reference anchor="ASTM-Remote-ID" target="https://www.icao.int/airnavigation/IATF/Pages/ASTM-Remote-ID.aspx">
          <front>
            <title>ICAO Remote
            <title>Remote ID Number Registration</title>
            <author>
              <organization/>
              <organization>International Civil Aviation Organization (ICAO)</organization>
	    </author>
            <date year="2023" month="December"/>
          </front>
        </reference>
      </references>
    </references>

    <section anchor="auth-state-diagrams" numbered="true" toc="default">
      <name>Authentication States</name>
      <t>ASTM Authentication has only three states: None, Invalid, and Valid. This is because, under ASTM, the authentication is done by an external service hosted somewhere on the Internet so it is assumed an authoritative response will always be returned. This classification becomes more complex in DRIP with the support of "offline" scenarios where a an Observer does not have Internet connectivity. With the use of asymmetric cryptography cryptography, this means that the public key (PK) must somehow be obtained. <xref target="drip-registries" target="I-D.ietf-drip-registries" format="default"/> gets provides more into detail on how these keys are stored on the DNS and one use of how DRIP Authentication messages is 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 PKs of relevant DIMEs. This document describes how to send the PK of the UA over the Broadcast RID messages. The key keys of DIMEs are sent over Broadcast RID using the same mechanisms (see Sections <xref target="drip-link" format="default"/> format="counter"/> and <xref target="drip-recommendations" format="default"/>) format="counter"/>) but MAY <bcp14>MAY</bcp14> be sent at a far lower rate due to potential operational constraints (such as saturation of limited bandwidth). As such, there are scenarios where part of the key-chain may be unavailable at the moment a full Authentication Message is received and processed.</t>
      <t>The intent of this informative appendix is to give recommend a recommended way to classify these various states and convey it to the user through colors and state names/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 color.
-->

      <t>The table below lays out the recommended colors to associate with state and a brief description of each.</t>
      <table align="center">
        <name>Authentication State Names, Colors &amp; Colors, and Descriptions</name>
        <thead>
          <tr>
            <th align="left">State</th>
            <th align="left">Color</th>
            <th align="left">Details</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">None</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>
          </tr>
          <tr>
            <td align="left">Partial</td>
            <td align="left">Gray</td>
            <td align="left">Authentication being received but missing pages</td>
          </tr>
          <tr>
            <td align="left">Unsupported</td>
            <td align="left">Brown</td>
            <td align="left">Authentication Type/SAM Type / SAM Type of received message not supported</td>
          </tr>
          <tr>
            <td align="left">Unverifiable</td>
            <td align="left">Yellow</td>
            <td align="left">Data needed for signature verification is missing</td>
          </tr>
          <tr>
            <td align="left">Verified</td>
            <td align="left">Green</td>
            <td align="left">Valid signature verification and content validation</td>
          </tr>
          <tr>
            <td align="left">Trusted</td>
            <td align="left">Blue</td>
            <td align="left">evidence align="left">Evidence of Verified and DIME is marked as only registering DETs for trusted entities</td>
          </tr>
          <tr>
            <td align="left">Unverified</td>
            <td align="left">Red</td>
            <td align="left">Invalid signature verification or content validation</td>
          </tr>
          <tr>
            <td align="left">Questionable</td>
            <td align="left">Orange</td>
            <td align="left">evidence align="left">Evidence of both Verified &amp; both"Verified and Unverified for the same claimed sender</td>
          </tr>
          <tr>
            <td align="left">Conflicting</td>
            <td align="left">Purple</td>
            <td align="left">evidence align="left">Evidence of both Trusted &amp; and Unverified for the same claimed sender</td>
          </tr>
        </tbody>
      </table>
      <section anchor="black" numbered="true" toc="default">
        <name>None: Black</name>
        <t>The
<!-- [rfced] Please note that we have updated the description for Black,
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 anchor="gray" numbered="true" toc="default">
        <name>Partial: Gray</name>
        <t>A pending state where authentication pages are being received received, but a full authentication message has yet to be compiled.</t>
      </section>
      <section anchor="brown" numbered="true" toc="default">
        <name>Unsupported: Brown</name>
        <t>A state wherein authentication data is being or has been received, received but cannot be used, as the Authentication Type or SAM Type is not supported by the Observer.</t>
      </section>
      <section anchor="yellow" numbered="true" toc="default">
        <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>
      </section>
      <section anchor="green" numbered="true" toc="default">
        <name>Verified: Green</name>
        <t>A state where all authentication messages that have been received, received from that claimed sender up to that point from that claimed sender, pass signature verification and the requirement of <xref target="trust-assessment" format="default"/> has been met.</t>
      </section>
      <section anchor="blue" numbered="true" toc="default">
        <name>Trusted: Blue</name>
        <t>A state where all authentication messages that have been received, up to that point, received from that claimed sender, sender up to that point have passed signature verification, the requirement of <xref target="trust-assessment" format="default"/> has been met, and the public key of the sending UA is has been marked as trusted.</t>
        <t>The sending UA key will have been marked as trusted if the relevant DIMEs only register DETs (of subordinate DIMEs, UAS operators, and UA) that have been vetted as per their published registration policies, and those DIMEs have been 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 anchor="orange" numbered="true" toc="default">
        <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 target="red" format="default"/>).</t>
        <t>Transition to this state is
        <t>State transitions from Verified to Questionable if a subsequent message fails verification verification, so it would have otherwise been marked Unverified, or Unverified.  State transitions from Unverified to Questionable if a subsequent message passes verification or validation validation, so it would otherwise have been marked Verified, or Verified.  It may transition from either of those state states upon mixed results on the requirement of <xref target="trust-assessment" format="default"/>.</t>
      </section>
      <section anchor="red" numbered="true" toc="default">
        <name>Unverified: Red</name>
        <t>A state where all authentication messages that have been received, up to that point, received from that claimed sender, sender up to that point failed signature verification or the requirement of <xref target="trust-assessment" format="default"/>.</t>
      </section>
      <section anchor="purple" numbered="true" toc="default">
        <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 target="red" format="default"/>) and the public key of the aircraft is marked as trusted.</t>
        <t>Transition to this state is
        <t>State transitions from Trusted to Conflicting if a subsequent message fails verification verification, so it would have otherwise been marked Unverified, or Unverified.  State transitions from Unverified to Conflicting if a subsequent message passes verification or validation and policy checks checks, so it would otherwise have been marked Trusted, or Trusted. It may transition from either of those state states upon mixed results on the requirement of <xref target="trust-assessment" format="default"/>.</t>
      </section>
    </section>
    <section anchor="operational-proof" numbered="true" toc="default">
      <name>Operational Recommendation Analysis</name>
      <t>The recommendations found in <xref target="operational-recommendations" format="default"/> may seem heavy handed heavy-handed and specific. This informative appendix lays out the math and assumptions made that resulted in those recommendations and provides an example.</t>
<!-- [rfced] Are the values for Basic ID and Location correct?  In other places, we see Basic, Location, and System associated as follows:

- Basic ID: 0x0
- Location: 0x1
- System: 0x4 (seems correct)

Original:
   In many jurisdictions, the required ASTM Messages to come be transmitted
   every second are: Basic ID (0x1), Location (0x2), and System (0x4).

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 recommendations listed there as well as Operator ID Message (0x5) is
      also required.  In Japan, transmission of two Basic IDs (0x0), a Location (0x1),
      and an example.</t> Authentication (0x2) are required.  Self ID (0x3) transmission is optional but
      can carry Emergency Status information.
-->

      <t>In many jurisdictions, the required ASTM Messages to be transmitted every second are: Basic ID (0x1), Location (0x2), and System (0x4). Typical implementations will most likely send at a higher rate (2x sets per cycle) resulting in 6 frames sent per cycle. Transmitting this set of message messages more than once a second is not discouraged discouraged, but awareness is needed to avoid congesting the RF spectrum, causing further issues.</t>
      <ul empty="true" spacing="normal">
        <li>Informational
        <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 information.</li>
      </ul> information.</t>
      <section anchor="page-counts-vs-frame-counts" numbered="true" toc="default">
        <name>Page Counts vs Frame Counts</name>
        <t>There are two formulas to determine the number of Authentication Pages required, one required.  The following formula is for Wrapper:</t>
<sourcecode name="" type="" markers="true"><![CDATA[
wrapper_struct_size = 89 + (25 * num_astm_messages)
wrapper_page_count = ceiling((wrapper_struct_size - 17) / 23) + 1
]]></sourcecode>
        <t>and one

        <t>The following formula is for Manifest:</t>
        <sourcecode name="" type="" markers="true"><![CDATA[
manifest_struct_size = 89 + (8 * (num_astm_hashes + 3))
manifest_page_count = ceiling((manifest_struct_size - 17) / 23) + 1
]]></sourcecode>

        <t>A similar formula can be applied to Link Links, as they are of fixed size:</t>
        <sourcecode name="" type="" markers="true"><![CDATA[
link_page_count = ceiling((137 - 17) / 23) + 1 = 7
]]></sourcecode>

        <t>Comparing Wrapper and Manifest Authentication Message page counts against total frame counts counts, we have the following:</t>
        <table anchor="tbl-page-counts" align="center">
          <name>Page &amp; and Frame Counts</name>
          <thead>
            <tr>
              <th align="left">ASTM Messages</th>
              <th align="left">Wrapper (w/FEC)</th>
              <th align="left">Manifest (w/FEC)</th>
              <th align="left">ASTM Messages + Wrapper (w/FEC)</th>
              <th align="left">ASTM Messages + Manifest (w/FEC)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">5 (6)</td>
              <td align="left">6 (7)</td>
              <td align="left">5 (6)</td>
              <td align="left">6 (7)</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">6 (7)</td>
              <td align="left">6 (7)</td>
              <td align="left">7 (8)</td>
              <td align="left">7 (8)</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">7 (8)</td>
              <td align="left">6 (7)</td>
              <td align="left">9 (10)</td>
              <td align="left">8 (9)</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">8 (9)</td>
              <td align="left">7 (8)</td>
              <td align="left">11 (12)</td>
              <td align="left">10 (11)</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">9 (10)</td>
              <td align="left">7 (8)</td>
              <td align="left">13 (14)</td>
              <td align="left">11 (12)</td>
            </tr>
            <tr>
              <td align="left">5</td>
              <td align="left">N/A</td>
              <td align="left">7 (8)</td>
              <td align="left">N/A</td>
              <td align="left">12 (13)</td>
            </tr>
            <tr>
              <td align="left">6</td>
              <td align="left">N/A</td>
              <td align="left">8 (9)</td>
              <td align="left">N/A</td>
              <td align="left">14 (15)</td>
            </tr>
            <tr>
              <td align="left">7</td>
              <td align="left">N/A</td>
              <td align="left">8 (9)</td>
              <td align="left">N/A</td>
              <td align="left">15 (16)</td>
            </tr>
            <tr>
              <td align="left">8</td>
              <td align="left">N/A</td>
              <td align="left">8 (9)</td>
              <td align="left">N/A</td>
              <td align="left">16 (17)</td>
            </tr>
            <tr>
              <td align="left">9</td>
              <td align="left">N/A</td>
              <td align="left">9 (10)</td>
              <td align="left">N/A</td>
              <td align="left">18 (19)</td>
            </tr>
            <tr>
              <td align="left">10</td>
              <td align="left">N/A</td>
              <td align="left">9 (10)</td>
              <td align="left">N/A</td>
              <td align="left">19 (20)</td>
            </tr>
            <tr>
              <td align="left">11</td>
              <td align="left">N/A</td>
              <td align="left">9 (11)</td>
              <td align="left">N/A</td>
              <td align="left">20 (22)</td>
            </tr>
          </tbody>
        </table>
        <t>Link shares the same page counts as Manifest with 5 ASTM Messages.</t>
        <section anchor="special-cases" numbered="true" toc="default">
          <name>Special Cases</name>
          <section anchor="zero-astm-messages" numbered="true" toc="default">
            <name>Zero ASTM Messages</name>
            <t>Zero ASTM Messages in (see <xref target="tbl-page-counts" format="default"/> format="default"/>) is where Extended Wrapper (<xref target="extended-wrapper" format="default"/>) without FEC is used in Message Packs. With a max maximum of 9 nine "message slots" in a Message Pack Pack, an Extended Wrapper fills 5 slots, five slots; thus it can authenticate up to 4 four ASTM Messages co-located in the same Message Pack.</t>
          </section>
          <section anchor="eleven-astm-messages" numbered="true" toc="default">
            <name>Eleven ASTM Messages</name>
            <t>Eleven ASTM Messages in (see <xref target="tbl-page-counts" format="default"/> format="default"/>) is where a Manifest with FEC invokes the situation mentioned in <xref target="fec-limitations" format="default"/>.</t>
            <t>Eleven is the max maximum number of ASTM Messages Message Hashes that can be supported resulting in 14 total hashes. This completely fills the <tt>evidence</tt> section of the structure making its total size 200 octets. This fits on exactly 9 Authentication Pages (<tt>(201 - 17) / 23 == 8</tt>) 8</tt>), so when the ADL is added added, it is placed on the next page (Page 10). Per rule 1 in <xref target="enc-single-page" format="default"/> format="default"/>, this means that all of Page 10 is null padded (expect the ADL octet) and FEC data fills Page 11, resulting in a plus two plus-two page count when FEC is applied.</t>
            <t>This drives the recommendation is <xref target="drip-manifest" format="default"/> to only use up to 10 ASTM Message Hashes and Hashes, not 11.</t>
          </section>
        </section>
      </section>
      <section anchor="full-authentication-example" numbered="true" toc="default">
        <name>Full Authentication Example</name>
<!-- [rfced] "Authentication with DRIP in that case" is unclear.  May we update the text as follows?

Original:
   Extended Transports is not shown as
   Authentication with DRIP in that case is covered using Extended
   Wrapper (Section 4.3.2).

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 Transports Transport is not shown as Authentication with DRIP in that case is covered using Extended Wrapper (<xref target="extended-wrapper" format="default"/>). Two ASTM Message Packs are sent in a given cycle: one containing up to 4 four ASTM Messages and an Extended Wrapper (authenticating the pack) pack), and one containing a Link message with a Broadcast Endorsement and up to two other ASTM Messages.</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">
          <name>Full
          <name>Example of a Fully Authenticated Legacy Transport Transmit Schedule Example</name> Schedule</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------------------------------------------+
|                      Frame Slots                     |
| 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[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[3] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[4] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[5] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[6] |
+-------------------+---------------+---------+--------+
| {A|B|C|D},V,S,I,O | {A|B|C|D},V,S | M[0,8]  | L/W[7] |
+-------------------+---------------+---------+--------+

A = Basic ID Message (0x0) ID Type 1
B = Basic ID Message (0x0) ID Type 2
C = Basic ID Message (0x0) ID Type 3
D = Basic ID Message (0x0) ID Type 4
V = Location/Vector Message (0x1)
I = Self ID Message (0x3)
S = System Message (0x4)
O = Operator ID Message (0x5)

L[y,z] = DRIP Link Authentication Message (0x2)
W[y,z] = DRIP Wrapper Authentication Message (0x2)
M[y,z] = DRIP Manifest Authentication Message (0x2)
  y = Start Page
  z = End Page

# = Empty Frame Slot
* = Message in DRIP Manifest Authentication Message
]]></artwork>
        </figure>
        <t>Every common required message (Basic ID, Location Location, and System) is sent twice plus along with Operator ID and Self ID in a single second. The Manifest is over all messages (8) in slots <tt>00 - 04</tt> and <tt>05 - 07</tt>.</t>
        <t>In two seconds seconds, either a Link or Wrapper are sent. The content and order of Links and Wrappers runs as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location (0x1), System (0x4)
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Link: Apex on RAA
Link: HDA on UA
Link: RAA on HDA
Link: HDA on UA
Wrapper: Location (0x1), System (0x4)
Link: IANA on UAS RID Apex
]]></artwork>
        <t>With
<!-- [rfced] We are unsure what "then all in future" means.

Original:
   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 be validated; interspersed with four messages directly signed over via Wrapper.</t>
        <section anchor="raw-example" numbered="true" toc="default">
          <name>Raw Example</name>
          <t>Assuming the following DET and HI:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
2001:3f:fe00:105:a29b:3ff4:2226:c04e
b5fef530d450dedb59ebafa18b00d7f5ed0ac08a81975034297bea2b00041813
]]></artwork>
          <t>The following ASTM Messages are to be sent in a single second:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
32004578616d706c652053656c662049440000000000000000
420000000000000000000100000000000000000010ea510900
52004578616d706c65204f70657261746f7220494400000000
0240012001003ffe000105a29b3ff42226c04e000000000000
12000000000000000000000000000000000000000060220000
420000000000000000000100000000000000000010ea510900
]]></artwork>
          <t>This is a Link with FEC that would be spread out over 8 seconds:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
2250078910ea510904314b8564b17e66662001003ffe000105
2251a29b3ff42226c04eb5fef530d450dedb59ebafa18b00d7
2252f5ed0ac08a81975034297bea2b000418132001003ffe00
22530105b82bf1c99d87273103fc83f6ecd9b91842f205c222
2254dd71d8e165ad18ca91daf9299a73eec850c756a7e9be46
2255f51dddfa0f09db7bfdde14eec07c7a6dd1061c1d5ace94
2256d9ad97940d280000000000000000000000000000000000
2257a03b0f7a6feb0d198167045058cfc49f73129917024d22
]]></artwork>
          <t>This is a Wrapper with FEC that would be spread out over 8 seconds:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
2250078b10ea510902e0dd7c6560115e671200000000000000
22510000000000000000000000000060220000420000000000
2252000000000100000000000000000010ea5109002001003f
2253fe000105a29b3ff42226c04ef0ecad581a030ca790152a
22542f08df5762a463e24a742d1c530ec977bbe0d113697e2b
2255b909d6c7557bdaf1227ce86154b030daadda4a6b8474de
22569a62f6c375020826000000000000000000000000000000
2257f5e8eebcb04f8c2197526053e66c010d5d7297ff7c1fe0
]]></artwork>
          <t>This is the Manifest with FEC sent in the same second as the original messages:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
225008b110ea510903e0dd7c6560115e670000000000000000
2251d57594875f8608b4d61dc9224ecf8b842bd4862734ed01
22522ca2e5f2b8a3e61547b81704766ba3eeb651be7eafc928
22538884e3e28a24fd5529bc2bd4862734ed012ca2e5f2b8a3
2254e61547b81704766ba3eeb62001003ffe000105a29b3ff4
22552226c04efb729846e7d110903797066fd96f49a77c5a48
2256c4c3b330be05bc4a958e9641718aaa31aeabad368386a2
22579ed2dce2769120da83edbcdc0858dd1e357755e7860317
2258e7c06a5918ea62a937391cbfe0983539de1b2e688b7c83
]]></artwork>
        </section>
      </section>
    </section>
  </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 to 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 Message".

   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 messages.
   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>