<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9942" updates="" obsoletes="" docName="draft-ietf-cose-merkle-tree-proofs-18" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 --> version="3" xml:lang="en">

  <front>
    <title>COSE
<!-- [rfced] Please note that the title of the document has been
     updated as follows:

a) We have flipped the abbreviation and expansion for COSE to match
similar uses in past RFC titles.

Original:
COSE (CBOR Object Signing and Encryption) Receipts

Current:
CBOR Object Signing and Encryption (COSE) Receipts

b) We have updated the "short title" (in the running header of the PDF
version) as follows:

Original:
COSE (CBOR Object Signing and Encryption) Receipts

Current:
COSE Receipts
-->

    <title abbrev="COSE Receipts">CBOR Object Signing and Encryption (COSE) Receipts</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cose-merkle-tree-proofs-18"/> name="RFC" value="9942"/>
    <author initials="O." surname="Steele" fullname="Orie Steele">
      <organization>Tradeverifyd</organization>
      <address>
        <postal>
          <country>United States</country> States of America</country>
        </postal>
        <email>orie@or13.io</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@ietf.contact</email>
      </address>
    </author>
    <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>antdl@microsoft.com</email>
      </address>
    </author>
    <author initials="C." surname="Fournet" fullname="Cedric Fournet">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>fournet@microsoft.com</email>
      </address>
    </author>
    <date year="2025" month="December" day="02"/>
    <area>Security</area>
    <workgroup>COSE</workgroup>
    <keyword>Internet-Draft</keyword> year="2026" month="March"/>

    <area>SEC</area>
    <workgroup>cose</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>
      <?line 89?>

<t>COSE (CBOR
<t>CBOR Object Signing and Encryption) Encryption (COSE) Receipts prove properties of a verifiable data structure Verifiable Data Structure (VDS) to a verifier.
Verifiable data structures Data Structures and associated proof types enable security properties, such as minimal disclosure, transparency transparency, and non-equivocation.
Transparency helps maintain trust over time, time and has been applied to certificates, end to end end-to-end encrypted messaging systems, and supply chain security.
This specification enables concise transparency oriented systems, transparency-oriented systems by building on CBOR (Concise Concise Binary Object Representation) Representation (CBOR) and COSE.
The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    CBOR Object Signing and Encryption Working Group mailing list (cose@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cose/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs"/>.</t>
    </note>
  </front>
  <middle>
    <?line 97?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>COSE Receipts are signed proofs that include metadata about certain states of a verifiable data structure Verifiable Data Structure (VDS) that are true when the COSE Receipt was issued.
COSE Receipts can include proofs that a document is in a database (proof of inclusion), that a database is append only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or proof that certain data is not yet present in a database (proofs (proof of non inclusion). non-inclusion).
Different VDS VDSs can produce different verifiable data Verifiable Data structure proofs Proofs (VDP).
The combination of representations of various VDS VDSs and VDP can significantly increase the burden for implementers and create interoperability challenges for transparency services.
This document describes how to convey VDS and associated VDP types in unified COSE envelopes.</t>
      <section anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>The
 <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
        <?line -18?> here.
        </t>

      </section>
    </section>
    <section anchor="param-list">
      <name>New COSE Header Parameters</name>
      <t>This document defines three new COSE header parameters, which are introduced up-front up front in this Section section and elaborated on later in this document.</t>
      <dl>
        <dt>TBD_0 (requested assignment 394):</dt>
        <dt>394:</dt>
        <dd>
          <t>A COSE header parameter named <tt>receipts</tt> with a value type of array where the array contains one or more COSE Receipts as specified in this document.</t>
        </dd>
        <dt>TBD_1 (requested assignment 395):</dt>
        <dt>395:</dt>
        <dd>
          <t>A COSE header parameter named <tt>vds</tt> (Verifiable (for Verifiable Data Structure), which conveys the algorithm identifier for a verifiable data structure. Verifiable Data Structure.
Correspondingly, this document introduces see <xref target="verifiable-data-structure-algorithms-registry"/> for a new registry (<xref target="verifiable-data-structure-registry"/>) defining the integers used to identify verifiable data structures.</t> Verifiable Data Structures.</t>
        </dd>
        <dt>TBD_2 (requested assignment 396):</dt>
        <dt>396:</dt>
        <dd>
          <t>A COSE header parameter named <tt>vdp</tt> (short for "verifiable data structure proofs"), (for Verifiable Data Structure Proofs), which conveys a map containing verifiable data structure proofs Verifiable Data Structure Proofs organized by proof type.
Correspondingly, this document introduces see <xref target="verifiable-data-structure-proofs-registry"/> for a new registry (<xref target="verifiable-data-structure-proofs-registry"/>) defining the integers used to identify verifiable data structure Verifiable Data Structure proof types.</t>
        </dd>
      </dl>
    </section>
    <section anchor="terminology">

<!--[rfced] We had the following questions related to the Terminology
     section:

a) Would you like the terms to be alphabetized for the ease of the
reader?

b) The Terminology section of draft-ietf-scitt-architecture has a
sentence introducing terms from [STD96] in its Terminology section
(see below) that are also used in this document.

Original:
   The terms "header", "payload", and "to-be-signed bytes" are defined
   in [STD96].

Should this sentence (or something similar as "to-be-signed bytes" is
not used in this document) be added along with a reference to [STD96]?
(Same goes for the sentence in the companion document about the
definition of "claim".)

If so, please let us know how/where to add as well as if the reference
entry would be normative or informative.

c) We note that this document uses the following terms that are
defined in the Terminology section of
draft-ietf-scitt-architecture-22.  Should any pointers/citations be
added to direct the reader to Section 3 of that document?

envelope
non-equivocation
statement
transparency service

d) Please see our cluster-wide questions related to discrepancies
between the definitions that appear in both documents in this cluster
and variances in their appearance (e.g., capitalization).

-->

      <name>Terminology</name>
      <dl>
        <dt>CDDL:</dt>
        <dd>
          <t>Concise Data Definition Language (CDDL) is defined in <xref target="RFC8610"/>.</t>
        </dd>
        <dt>EDN:</dt>
        <dd>
          <t>CBOR Extended Diagnostic Notation (EDN) is defined in <xref target="RFC8949"/>, where it is referred to as "diagnostic notation", and is revised in <xref target="I-D.draft-ietf-cbor-edn-literals"/>.</t> target="I-D.ietf-cbor-edn-literals"/>.</t>
        </dd>
        <dt>Verifiable Data Structure (VDS):</dt>
        <dd>
          <t>A data structure which that supports one or more Verifiable Data Structure Proof Types.
This property describes an algorithm used to maintain a verifiable data structure, Verifiable Data Structure, for example example, a binary Merkle tree algorithm.</t>
        </dd>
        <dt>Verifiable Data Structure Proofs (VDP):</dt>
        <dd>
          <t>A data structure used to convey proof types for proving different properties, such as authentication, inclusion, consistency, and freshness.
Parameters can include multiple proofs of a given type, type or multiple types of proof (inclusion and consistency).</t>
        </dd>
        <dt>Proof Type:</dt>
        <dd>
          <t>A property that can be obtained by verifying a given proof over one or more entries in a Verifiable Data Structure.
For example, a VDS, such as a binary Merkle tree, can support proofs of type "inclusion" where each proof confirms that a given entry is included in a Merkle root.</t>
        </dd>
        <dt>Proof Value:</dt>
        <dd>
          <t>An encoding of a Proof Type in CBOR <xref target="RFC8949"/>.</t>
        </dd>
        <dt>Entry:</dt>
        <dd>
          <t>An entry in a verifiable data structure Verifiable Data Structure for which proofs can be derived.</t>
        </dd>
        <dt>Receipt:</dt>
        <dd>
          <t>A COSE object, as defined in <xref target="RFC9052"/>, containing the header parameters necessary to convey VDP for an associated VDS.</t>
        </dd>
      </dl>
    </section>
    <section anchor="sec-generic-verifiable-data-structures">
      <name>Verifiable Data Structures in CBOR</name>
      <t>This section describes representations of verifiable data structure proofs Verifiable Data Structure Proofs in <xref target="RFC8949"/>.
For example, construction of a Merkle tree leaf, leaf or an inclusion proof from a leaf to a Merkle root, root might have several different representations, depending on the verifiable data structure Verifiable Data Structure used.
Differences in representations are necessary to support efficient verification, unique security or privacy properties, and for compatibility with specific implementations.
This document defines two extension points for enabling verifiable data structures Verifiable Data Structures with COSE and provides concrete examples for the structures and proofs defined in <xref section="2.1.3" sectionFormat="of" target="RFC9162"/> and <xref section="2.1.4" sectionFormat="of" target="RFC9162"/>.
The design of these structures is influenced by the conventions established for COSE Keys.</t>
      <section anchor="sec-cose-verifiable-data-structures">
        <name>Structures</name>

        <t>Similar to <eref target="https://www.iana.org/assignments/cose/cose.xhtml#key-type">COSE COSE Key Types</eref>, Types <xref target="IANA.cose_header-parameters"/>, different verifiable data structures Verifiable Data Structures support different algorithms.</t>
        <t>This document establishes a registry of verifiable data structure algorithms, Verifiable Data Structure algorithms; see <xref target="verifiable-data-structure-registry"/> target="verifiable-data-structure-algorithms-registry"/> for details.</t>
      </section>
      <section anchor="sec-cose-verifiable-data-structure-proofs">
        <name>Proofs</name>

<!--[rfced] This sentence doesn't parse.  Please let us know how to
     update.

Original:
...such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (TBD_1
(requested assignment 395) : 1) supports both (-1) inclusion and (-2)
consistency proofs.
-->

        <t>Similar to <eref target="https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters">COSE COSE Key Type Parameters</eref>, Parameters <xref target="IANA.cose_header-parameters" format="default"/>, as EC2 keys (1: 2) keys require and give meaning to specific parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (TBD_1 (requested assignment 395) : (395: 1) supports both (-1) inclusion and (-2) consistency proofs.</t>
        <t>This document establishes a registry of verifiable data structure algorithm proofs, Verifiable Data Structure Proofs; see <xref target="verifiable-data-structure-proofs-registry"/> for details.</t>
        <t>Proof types are specific to their associated "verifiable data structure", "Verifiable Data Structure"; for example, different Merkle trees might support different representations of "inclusion proof" or "consistency proof".
Implementers should not expect interoperability across "verifiable data structures". "Verifiable Data Structures".
Security analysis <bcp14>MUST</bcp14> be conducted prior to migrating to new structures to ensure the new security and privacy assumptions are acceptable for the use case.</t>
      </section>
      <section anchor="receipt-spec">
        <name>Usage</name>
        <t>This document registers a new COSE Header Parameter <tt>receipts</tt> (TBD_0 (requested assignment 394)) (394) to enable Receipts to be conveyed in the protected and unprotected headers of COSE Objects.</t>
        <t>When the receipts header parameter is present, the verifier <bcp14>MUST</bcp14> confirm that the associated verifiable data structure Verifiable Data Structure and verifiable data structure proofs Verifiable Data Structure Proofs match entries present in the registries established in this specification, including values added in subsequent registrations..</t> registrations.</t>
        <t>Receipts <bcp14>MUST</bcp14> be tagged as COSE_Sign1.</t>
        <t>The following definition from <xref target="RFC8610"/> definition is provided:</t>

<!--[rfced] Please note that Figure 1 exceeds our character limit in
     three places (line 319 is 5 characters over the character limit).
     Please review how these lines could be broken to fit within the
     69 character limit associated with sourcecode.
	-->

<figure anchor="fig-receipts-cddl">
          <name>CDDL for a COSE Sign1 with attached receipts</name> Attached Receipts</name>
          <sourcecode type="cddl"><![CDATA[
Signature_With_Receipt = #6.18(COSE_Sign1)

cose.label = int / text
cose.values = any

Protected_Header = {
  * cose.label => cose.values
}

Unprotected_Header = {
  &(receipts: 394)  => [+ bstr .cbor Receipt]
  * cose.label => cose.values
}

COSE_Sign1 = [
  protected   : bstr .cbor Protected_Header,
  unprotected : Unprotected_Header,
  payload     : bstr / nil,
  signature   : bstr
]

Receipt = Receipt_For_Inclusion / Receipt_For_Consistency

; Note the the proof formats shown here are for RFC9162_SHA256.
; Other verifiable data structures Verifiable Data Structures may have different proof formats.

Receipt_For_Inclusion = #6.18(Signed_Inclusion_Proof)

Signed_Inclusion_Proof = [
  protected   : bstr .cbor RFC9162_SHA256_Inclusion_Protected_Header
  unprotected : RFC9162_SHA256_Inclusion_Unprotected_Header
  payload     : bstr / nil
  signature   : bstr
]

RFC9162_SHA256_Inclusion_Protected_Header = {
  &(alg: 1) => int
  &(vds: 395) => int
  * cose.label => cose.values
}

RFC9162_SHA256_Inclusion_Unprotected_Header = {
  &(vdp: 396) => RFC9162_SHA256_Verifiable_Inclusion_Proofs
  * cose.label => cose.values
}

RFC9162_SHA256_Verifiable_Inclusion_Proofs = {
  &(inclusion-proof: -1) => RFC9162_SHA256_Inclusion_Proofs
}

RFC9162_SHA256_Inclusion_Proofs = [ + RFC9162_SHA256_Inclusion_Proof ]

RFC9162_SHA256_Inclusion_Proof = bstr .cbor [
  tree_size: uint,
  leaf_index: uint,
  inclusion_path: [ + bstr ]
]

Receipt_For_Consistency = #6.18(Signed_Consistency_Proof)

Signed_Consistency_Proof = [
  protected   : bstr .cbor RFC9162_SHA256_Consistency_Protected_Header,
  unprotected : RFC9162_SHA256_Consistency_Unprotected_Header,
  payload     : bstr / nil, ; Newer Merkle tree root
  signature   : bstr
]

RFC9162_SHA256_Consistency_Protected_Header = {
  &(alg: 1) => int,
  &(vds: 395) => int,
  * cose.label => cose.values
}

RFC9162_SHA256_Consistency_Unprotected_Header = {
  &(vdp: 396) => RFC9162_SHA256_Verifiable_Consistency_Proofs
  * cose.label => cose.values
}

RFC9162_SHA256_Verifiable_Consistency_Proofs = {
  &(consistency-proof: -2) => RFC9162_SHA256_Consistency_Proofs
}

RFC9162_SHA256_Consistency_Proofs = [ + RFC9162_SHA256_Consistency_Proof ]

RFC9162_SHA256_Consistency_Proof = bstr .cbor [
   tree_size_1: uint,
   tree_size_2: uint,
   consistency_path: [ + bstr ]
]

]]></sourcecode>
</figure>

<!--[rfced] We had two questions related to this document's use of the
     term "SHA256":

a) We note that the EDN provided in Section 4.3 uses RFC9162 SHA-256
while other uses of this term in prose use RFC9162_SHA256.  Please
confirm that this is as intended.

b) We see both SHA256 and sha-256 in running text.  Should these be
made uniform as SHA256?

-->

        <t>The following informative EDN is provided:</t>

<figure anchor="fig-receipts-edn">
          <name>An example Example COSE Signature with multiple receipts</name> Multiple Receipts</name>
          <sourcecode type="cbor-diag"><![CDATA[
/ cose-sign1 / 18([
  / protected   / <<{
    / kid / 4 : h'bc297b51...e4edf0de',
    / algorithm / 1 : -7,  # ES256
  }>>,
  / unprotected / {
    / receipts / 394 : {
      <</ cose-sign1 / 18([
        / protected   / <<{
          / kid / 4 : h'abcdef12...34567890',
          / algorithm / 1 : -7,  # ES256
          / vds       / 395 : 1, # RFC9162 SHA-256
        }>>,
        / unprotected / {
          / proofs / 396 : {
            / inclusion / -1 : [
              <<[
                / size / 9, / leaf / 8,
                / inclusion path /
                h'7558a95f...e02e35d6'
              ]>>
            ],
          },
        },
        / payload     / null,
        / signature   / h'02d227ed...ccd3774f'
      ])>>,
      <</ cose-sign1 / 18([
        / protected   / <<{
          / kid / 4 : h'abcdef12...34567890',
          / algorithm / 1 : -7,  # ES256
          / vds       / 395 : 1, # RFC9162 SHA-256
        }>>,
        / unprotected / {
          / proofs / 396 : {
            / inclusion / -1 : [
              <<[
                / size / 6, / leaf / 5,
                / inclusion path /
                h'9352f974...4ffa7ce0',
                h'54806f32...f007ea06'
              ]>>
            ],
          },
        },
        / payload     / null,
        / signature   / h'36581f38...a5581960'
      ])>>
    },
  },
  / payload     / h'0167c57c...deeed6d4',
  / signature   / h'2544f2ed...5840893b'
])
]]></sourcecode>
        </figure>

        <t>The specific structure of COSE Receipts is dependent on the structure of the COSE_Sign1 payload and the verifiable data structure proofs Verifiable Data Structure Proofs contained in the COSE_Sign1 unprotected header.
The CDDL definition for verifiable data structure proofs Verifiable Data Structure Proofs is specific to each verifiable data structure. Verifiable Data Structure.
This document describes proofs for RFC9162_SHA256 in the following sections.</t>
      </section>
      <section anchor="profiles-def">
        <name>Profiles</name>
        <t>New verifiable data structures Verifiable Data Structures can require the definition of a profile.
The payload in such definitions <bcp14>SHOULD</bcp14> be detached.
Detached payloads force verifiers to recompute the root from the proof and protect against implementation errors where the signature is verified but the payload is incompatible with the proof.
Profiles of proof signatures that define additional protected header parameters are encouraged to make their presence mandatory to ensure that claims are processed with their intended semantics.
One way to include this information in the COSE structure is use of the typ (type) Header Parameter, Parameter; see <xref target="RFC9596"/> and the similar guidance provided in <xref target="RFC9597"/>.</t>
        <section anchor="registration-requirements">
          <name>Registration Requirements</name>
          <t>Each verifiable data structure Verifiable Data Structure specification applying for inclusion in this registry <bcp14>MUST</bcp14> define how to encode the verifiable data structure Verifiable Data Structure identifier and its proof types in CBOR.
Each specification <bcp14>MUST</bcp14> define how to produce and consume the supported proof types.
See <xref target="sec-rfc-9162-verifiable-data-structure-definition"/> as an example.</t>

          <t>Where a specification supports a choice of hash algorithm, a separate IANA registration must be made for each supported algorithm.
For example, to provide support for SHA256 and SHA3_256 with Merkle Consistency and Inclusion Proofs defined respectively and Merkle Consistency Proofs defined, respectively, in <xref section="2.1.3" sectionFormat="of" target="RFC9162"/> and <xref section="2.1.4" sectionFormat="of" target="RFC9162"/>, both "RFC9162_SHA256" and "RFC9162_SHA3_256" require entries in the relevant IANA registries.
This document only defines "RFC9162_SHA256".</t>
        </section>
      </section>
    </section>
    <section anchor="sec-rfc-9162-verifiable-data-structure-definition">
      <name>RFC9162_SHA256</name>
      <t>This section defines how the data structure described in <xref section="2.1" sectionFormat="of" target="RFC9162"/> is mapped to the terminology defined in this document, using <xref target="RFC8949"/> and <xref target="RFC9053"/>.</t>
      <section anchor="verifiable-data-structure">
        <name>Verifiable Data Structure</name>
        <t>The integer identifier for this Verifiable Data Structure is 1.
The string identifier for this Verifiable Data Structure is "RFC9162_SHA256", a Merkle Tree where SHA256 is used as the hash algorithm.
See algorithm
(see <xref target="verifiable-data-structure-proofs-registry"/>. target="verifiable-data-structure-algorithms-registry-table"/>). See <xref section="2.1.1" sectionFormat="of" target="RFC9162"/> (Definition of the Merkle Tree), for a complete description of this verifiable data structure.</t> Verifiable Data Structure.</t>
      </section>
      <section anchor="sec-rfc9162-sha256-inclusion-proof">
        <name>Inclusion Proof</name>
        <t>See <xref section="2.1.3.1" sectionFormat="of" target="RFC9162"/> (Generating an Inclusion Proof), for a complete description of this verifiable data structure proof Verifiable Data Structure Proof type.</t>
        <t>The CBOR representation of an inclusion proof for RFC9162_SHA256 is:</t>
        <figure anchor="rfc9162-sha256-cbor-inclusion-proof">
          <name>CBOR Encoded RFC9162
          <name>CBOR-Encoded Inclusion Proof</name> Proof for RFC9162_SHA256</name>
          <sourcecode type="cddl"><![CDATA[
inclusion-proof = bstr .cbor [

    ; tree size at current Merkle root
    tree-size: uint

    ; index of leaf in tree
    leaf-index: uint

    ; path from leaf to current Merkle root
    inclusion-path: [ + bstr ]
]
]]></sourcecode>
]]]></sourcecode>
        </figure>
<!-- [rfced] We note that [RFC9162] uses "leaf_index" rather than
     "leaf-index".  Please review and let us know if updates should be
     made.

Current:
  The term leaf-index is used for alignment with the use established in
  Section 2.1.3.2 of [RFC9162].
-->
        <t>The term <tt>leaf-index</tt> is used for alignment with the use established in <xref section="2.1.3.2" sectionFormat="of" target="RFC9162"/>.</t>
        <t>Note that <xref target="RFC9162"/> defines inclusion proofs only for leaf nodes, and that:</t>
        <ul empty="true">
          <li>
            <t>If
            <blockquote>If leaf_index is greater than or equal to tree_size, then fail the proof verification.</t>
          </li>
        </ul> verification.</blockquote>
        <t>The identifying index of a leaf node is relative to all nodes in the tree size for which the proof was obtained.</t>
        <section anchor="receipt-of-inclusion">
          <name>Receipt of Inclusion</name>
          <t>In a signed inclusion proof, the payload is the Merkle tree root that corresponds to the log at size <tt>tree-size</tt>.
The protected header for an RFC9162_SHA256 inclusion proof signature is:</t>
          <figure anchor="vds-in-inclusion-receipt-protected-header">
            <name>Protected Header for a Receipt of Inclusion</name>
            <sourcecode type="cddl"><![CDATA[
protected-header-map = {
  &(alg: 1) => int
  &(vds: 395) => int
  * cose-label => cose-value
}
]]></sourcecode>
}]]></sourcecode>
          </figure>
          <ul spacing="normal">
            <li>
              <t>alg
          <dl spacing="normal" newline="false">
            <dt>alg (label: 1): <bcp14>REQUIRED</bcp14>. 1):</dt><dd><bcp14>REQUIRED</bcp14>. Signature algorithm identifier. Value type: int.</t>
            </li>
            <li>
              <t>vds int.</dd>
            <dt>vds (label: TBD_1 (requested assignment 395)): 395):</dt><dd> <bcp14>REQUIRED</bcp14>. Verifiable data structure Data Structure algorithm identifier. Value type: int.</t>
            </li>
          </ul> int.</dd>
          </dl>
          <t>The unprotected header for an RFC9162_SHA256 inclusion proof signature is:</t>
          <figure anchor="vdp-in-unprotected-header">
            <name>A Verifiable Data Structure Proofs in an Unprotected Header</name>
            <sourcecode type="cddl"><![CDATA[
inclusion-proofs = [ + inclusion-proof ]

verifiable-proofs = {
  &(inclusion-proof: -1) => inclusion-proofs
}

unprotected-header-map = {
  &(vdp: 396) => verifiable-proofs
  * cose-label => cose-value
}
]]></sourcecode>
}]]></sourcecode>
          </figure>
          <ul spacing="normal">
            <li>
              <t>vdp
          <dl spacing="normal" newline="false">
            <dt>vdp (label: TBD_2 (requested assignment 396)): <bcp14>REQUIRED</bcp14>. 396):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable data structure proofs. Data Structure Proofs. Value type: Map.</t>
            </li>
            <li>
              <t>inclusion-proof Map.</dd>
            <dt>inclusion-proof (label: -1): <bcp14>REQUIRED</bcp14>. -1):</dt><dd><bcp14>REQUIRED</bcp14>. Inclusion proofs. Value type: Array of bstr.</t>
            </li>
          </ul> bstr.</dd>
          </dl>
<!-- [rfced] We note that [RFC9162] uses "Merkle Tree Hash" rather
     than "Merkle tree hash".  Please note that there is inconsistency
     in this document related to Merkle Tree vs. Merkle tree as well.

Current:
  The payload of an RFC9162_SHA256 inclusion proof signature is the
  Merkle tree hash as defined in [RFC9162].
-->
          <t>The payload of an RFC9162_SHA256 inclusion proof signature is the Merkle tree hash as defined in <xref target="RFC9162"/>.</t>
          <t>An EDN example for a Receipt containing an inclusion proof for RFC9162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t>
          <figure anchor="rfc9162_sha256_inclusion_receipt">
            <name>Receipt of Inclusion</name>
            <sourcecode type="cbor-diag"><![CDATA[
/ cose-sign1 / 18([
  / protected   / <<{
    / algorithm / 1 : -7,  # ES256
    / vds       / 395 : 1, # RFC9162 SHA-256
  }>>,
  / unprotected / {
    / proofs / 396 : {
      / inclusion / -1 : [
        <<[
          / size / 20, / leaf / 17,
          / inclusion path /
          h'fc9f050f...221c92cb',
          h'bd0136ad...6b28cf21',
          h'd68af9d6...93b1632b'
        ]>>
      ],
    },
  },
  / payload     / null,
  / signature   / h'de24f0cc...9a5ade89'
])
]]></sourcecode>
])]]></sourcecode>
          </figure>
          <t>The VDS in the protected header is necessary to understand the inclusion proof structure in the unprotected header.</t>
          <t>The inclusion proof and signature are verified in order.

<!--[rfced] This sentence doesn't seem to parse.  Please rephrase.

Original:
First the verifier applies the inclusion proof to a possible entry
(set member) bytes.

-->

First, the verifier applies the inclusion proof to a possible entry (set member) bytes.
If this process fails, the inclusion proof may have been tampered with.

<!--[rfced] Please review this text for clarity (particularly for a
     missing verb after which?).

Original:
If this process succeeds, the result is a Merkle root, which in the
attached as the COSE Sign1 payload.
Second
-->

If this process succeeds, the result is a Merkle root, which in the attached as the COSE Sign1 payload.
Second, the verifier checks the signature of the COSE Sign1.
If the resulting signature verifies, can be verified, the Receipt has proved inclusion of the entry in the verifiable data structure. Verifiable Data Structure.
If the resulting signature does not verify, cannot be verified, the signature may have been tampered with.</t>
        </section>
      </section>
      <section anchor="sec-rfc9162-sha256-consistency-proof">
        <name>Consistency Proof</name>
        <t>See <xref section="2.1.4.1" sectionFormat="of" target="RFC9162"/> (Generating a Consistency Proof), for a complete description of this verifiable data structure proof Verifiable Data Structure Proof type.</t>
        <t>The cbor representation of a consistency proof for RFC9162_SHA256 is:</t>
        <figure anchor="rfc9162_sha256_consistency_proof">
          <name>CBOR Encoded RFC9162
          <name>CBOR-Encoded Consistency Proof</name> Proof for RFC9162_SHA256</name>
          <sourcecode type="cddl"><![CDATA[
consistency-proof =  bstr .cbor [

    ; older Merkle root tree size
    tree-size-1: uint

    ; newer Merkle root tree size
    tree-size-2: uint

    ; path from older Merkle root to newer Merkle root.
    consistency-path: [ + bstr ]

]
]]></sourcecode>

]]]></sourcecode>
        </figure>
        <section anchor="receipt-of-consistency">
          <name>Receipt of Consistency</name>
          <t>In a signed consistency proof, the newer Merkle tree root (proven to be consistent with an older Merkle tree root) root), is an attached payload and corresponds to the log at size tree-size-2.</t>
          <t>The protected header for an RFC9162_SHA256 consistency proof signature is:</t>
          <figure anchor="vds-in-consistency-receipt-protected-header">
            <name>Protected Header for a Receipt of Consistency</name>
            <sourcecode type="cddl"><![CDATA[
protected-header-map = {
  &(alg: 1) => int
  &(vds: 395) => int
  * cose-label => cose-value
}
]]></sourcecode>
}]]></sourcecode>
          </figure>
          <ul spacing="normal">
            <li>
              <t>alg
          <dl spacing="normal" newline="false">
            <dt>alg (label: 1): <bcp14>REQUIRED</bcp14>. 1):</dt><dd><bcp14>REQUIRED</bcp14>. Signature algorithm identifier. Value type: int.</t>
            </li>
            <li>
              <t>vds int.</dd>
            <dt>vds (label: TBD_1 (requested assignment 395)): <bcp14>REQUIRED</bcp14>. 395):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable data structure Data Structure algorithm identifier. Value type: int.</t>
            </li>
          </ul> int.</dd>
          </dl>
          <t>The unprotected header for an RFC9162_SHA256 consistency proof signature is:</t>
          <sourcecode type="cddl"><![CDATA[
consistency-proofs = [ + consistency-proof ]

verifiable-proofs = {
  &(consistency-proof: -2) => consistency-proofs
}

unprotected-header-map = {
  &(vdp: 396) => verifiable-proofs
  * cose-label => cose-value
}
]]></sourcecode>
          <ul spacing="normal">
            <li>
              <t>vdp
}]]></sourcecode>
          <dl spacing="normal" newline="false">
            <dt>vdp (label: TBD_2 (requested assignment 396)): <bcp14>REQUIRED</bcp14>. 396):</dt><dd><bcp14>REQUIRED</bcp14>. Verifiable data structure proofs. Data Structure Proofs. Value type: Map.</t>
            </li>
            <li>
              <t>consistency-proof Map.</dd>
            <dt>consistency-proof (label: -2): <bcp14>REQUIRED</bcp14>. -2):</dt><dd><bcp14>REQUIRED</bcp14>. Consistency proofs. Value type: Array of bstr.</t>
            </li>
          </ul> bstr.</dd>
          </dl>
          <t>The payload of an RFC9162_SHA256 consistency proof signature is:
The newer Merkle tree hash as defined in <xref target="RFC9162"/>.</t>
          <t>An example EDN example for a Receipt containing a consistency proof for RFC9162_SHA256 with a detached payload (see <xref target="profiles-def"/>) is:</t>
          <figure anchor="rfc9162_sha256_consistency_receipt">
            <name>Example consistency receipt</name> Consistency Receipt</name>
            <sourcecode type="cbor-diag"><![CDATA[
/ cose-sign1 / 18([
  / protected   / <<{
    / algorithm / 1 : -7,  # ES256
    / vds       / 395 : 1, # RFC9162 SHA-256
  }>>,
  / unprotected / {
    / proofs / 396 : {
      / consistency / -2 : [
        <<[
          / old / 20, / new / 104,
          / consistency path /
          h'e5b3e764...c4a813bc',
          h'87e8a084...4f529f69',
          h'f712f76d...92a0ff36',
          h'd68af9d6...93b1632b',
          h'249efab6...b7614ccd',
          h'85dd6293...38914dc1'
        ]>>
      ],
    },
  },
  / payload     / null,
  / signature   / h'94469f73...52de67a1'
])
]]></sourcecode>
])]]></sourcecode>
          </figure>
          <t>The VDS in the protected header is necessary to understand the consistency proof structure in the unprotected header.</t>
          <t>The signature and consistency proof are verified in order.</t>
          <t>First
          <t>First, the verifier checks the signature on the COSE Sign1.
If the verification fails, the consistency proof is not checked.
Second
Second, the consistency proof is checked by applying a previous inclusion proof, proof to the consistency proof.
If the verification fails, the append only property of the verifiable data structure Verifiable Data Structure is not assured.
This approach is specific to RFC9162_SHA256, RFC9162_SHA256; different verifiable data structures Verifiable Data Structures may not support consistency proofs.
It is recommended that implementations return a single boolean result for Receipt verification operations, Receipt-verification operations to reduce the chance of accepting a valid signature over an invalid consistency proof.</t>
        </section>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
<!--[rfced] The following may require clarification:

Current:
  The privacy considerations section of [RFC9162] and [RFC9053] apply to
  this document.

RFCs 9162 and 9053 do not have sections explicitly named "Privacy
Considerations". RFC 9053 doesn't appear to contain the term "privacy" at
all.  Please review.
-->
      <t>The privacy considerations section of <xref target="RFC9162"/> and <xref target="RFC9053"/> apply to this document.</t>
      <section anchor="log-length">
        <name>Log Length</name>
        <t>Some structures and proofs leak the size of the log at the time of inclusion.
In the case that a log only stores certain kinds of information, this can reveal details that could impact reputation.
For example, if a transparency log only stored breach notices, a receipt for a breach notice would reveal the number of previous breaches at the time the notice was made transparent.</t>
      </section>
      <section anchor="header-parameters">
        <name>Header Parameters</name>
        <t>Additional header parameters can reveal information about the transparency service or its log entries.
The receipt producer <bcp14>MUST</bcp14> perform a privacy analysis for all mandatory fields in profiles based on this specification.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>See the security considerations section Security Considerations sections of:</t>
      <ul spacing="normal">
        <li>
          <t><xref target="RFC9162"/></t>
        </li>
          <xref target="RFC9162"/></li>
        <li>
          <t><xref target="RFC9053"/></t>
        </li>
          <xref target="RFC9053"/></li>
      </ul>
      <section anchor="choice-of-signature-algorithms">
        <name>Choice of Signature Algorithms</name>
        <t>A security analysis ought to be performed to ensure that the digital signature algorithm <tt>alg</tt> has the appropriate strength to secure receipts.</t>
        <t>It is recommended to select signature algorithms that share cryptographic components with the verifiable data structure used, Verifiable Data Structure used; for example:
Both example,
both RFC9162_SHA256 and ES256 depend on the sha-256 hash function.</t>
      </section>
      <section anchor="validity-period">
        <name>Validity Period</name>
        <t>In some cases, receipts <bcp14>MAY</bcp14> include strict validity periods, for example, activation not too far in the future, future or expiration, expiration not too far in the past.
See the <tt>iat</tt>, <tt>nbf</tt>, and <tt>exp</tt> claims in <xref target="RFC8392"/>, target="RFC8392"/> for one way to accomplish this.
The details of expressing validity periods are out of scope for this document.</t>
      </section>
      <section anchor="status-updates">
        <name>Status Updates</name>
        <t>In some cases, receipts should be "revocable" or "suspendible", "suspendable" after being issued, regardless of their validity period.
The details of expressing statuses are out of scope for this document.</t>
      </section>
    </section>

<!--[rfced] We had the following questions/comments related to the
     IANA Considerations section:

a) For clarity, we have updated the IANA Considerations section by
breaking Section 8.2.2 up into subsections for each of the two
registries.  Please review this reorganization as well as any pointers
to it throughout the text to ensure we have correctly maintained your
intent.

b) Please note that we have updated Tables 2 and 3 to include the
Change Controller column as appears at the corresponding IANA
registries.  Please let us know any concerns.

c) Note: Any updates to Section 2 and/or Tables 1-3 that have been
made or resulting from author replies to our separate terminology or
abbreviation queries that would impact the information actually
registered at
https://www.iana.org/assignments/cose/cose.xhtml#verifiable-data-structure-algorithms
will be communicate to IANA by the RPC once AUTH48 completes.-->

    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="cose-header-parameter">
        <name>COSE Header Parameter</name>
        <t>IANA is requested to add has added the COSE header parameters defined in <xref target="param-list"/>, and as listed in <xref target="iana-header-params"/>, to the "COSE Header Parameters" registry subregistry <xref target="IANA.cose_header-parameters"/> in the "CBOR Object Signing and Encryption (COSE)" registry group.  These COSE header parameters fall in the 'Integer values from 256 to 65535' range ('Specification Required' Registration Procedure). (with a Specification Required registration procedure (see <xref target="RFC8126" format="default"/>)).
The Value Registry listed for "vds" is the COSE "COSE Verifiable Data Structure registry. Algorithm" subregistry.
	The map labels in the "vdp" are assigned from the COSE "COSE Verifiable Data Structure Proofs registry.</t> Proofs" subregistry.</t>

        <table anchor="iana-header-params">
          <name>Newly registered Registered COSE Header Parameters</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Label</th>
              <th align="left">Value Type</th>
              <th align="left">Value Registry</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">
                <tt>receipts</tt></td>
              <td align="left">TBD_0 (requested assignment: 394)</td> align="left">394</td>
              <td align="left">array</td>
              <td align="left"> </td>
              <td align="left">Priority ordered sequence of CBOR encoded Receipts</td>
              <td align="left">RFCthis, align="left">RFC 9942, <xref target="param-list"/></td>
            </tr>
            <tr>
              <td align="left">
                <tt>vds</tt></td>
              <td align="left">TBD_1 (requested assignment: 395)</td> align="left">395</td>
              <td align="left">int</td>
              <td align="left">COSE Verifiable Data Structure</td>
              <td align="left">Algorithm identifier for verifiable data structures, Verifiable Data Structures that is used to produce verifiable data structure proofs</td> Verifiable Data Structure Proofs</td>
              <td align="left">RFCthis, align="left">RFC 9942, <xref target="param-list"/></td>
            </tr>
            <tr>
              <td align="left">
                <tt>vdp</tt></td>
              <td align="left">TBD_2 (requested assignment: 396)</td> align="left">396</td>
              <td align="left">map</td>
              <td align="left">map key in COSE Verifiable Data Structure Proofs</td>
              <td align="left">Location for verifiable data structure proofs Verifiable Data Structure Proofs in COSE Header Parameters</td>
              <td align="left">RFCthis, align="left">RFC 9942, <xref target="param-list"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="verifiable-data-structure-registries">
        <name>Verifiable Data Structure Registries</name>
        <t>IANA established the COSE "COSE Verifiable Data Structure Algorithms Algorithms" and COSE "COSE Verifiable Data Structure Proofs registries Proofs" subregistries under a Specification Required policy as described in <xref section="4.6" sectionFormat="of" target="RFC8126"/>.</t>
        <section anchor="expert-review">
          <name>Expert Review</name>
          <t>Expert reviewers (see <xref target="RFC8126" format="default"/>) should take into consideration the following points:</t>
          <ul spacing="normal">
            <li>
              <t>Experts
            <li>Experts are advised to assign the next available positive integer for verifiable data structures.</t>
            </li>
            <li>
              <t>Point Verifiable Data Structures.</li>
            <li>Point squatting should be discouraged.
Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered, registered and that the point is likely to be used in deployments.</t>
            </li>
            <li>
              <t>Specifications deployments.</li>
            <li>Specifications are required for all point assignments.
Early Allocation
early allocation is permissible, see Section 2 of <xref target="RFC7120"/>.</t>
            </li>
            <li>
              <t>It target="RFC7120" section="2"/>.</li>
            <li>It is not permissible to assign points in COSE Verifiable Data Structure Algorithms, Algorithms for which no corresponding COSE Verifiable Data Structure Proofs entry exists, and vice versa.</t>
            </li>
            <li>
              <t>The Change Controller versa.</li>
            <li>The change controller for related registrations of structures and proofs should be the same.</t>
            </li> same.</li>
          </ul>
        </section>
	<section anchor="verifiable-data-structure-registry"> anchor="IANA_registry_info">
	  <name>Templates and Initial Contents</name>
        <section anchor="verifiable-data-structure-algorithms-registry">
          <name>COSE Verifiable Data Structure Algorithms</name>
          <t>Registration Template:</t>
          <ul spacing="normal">
            <li>
              <t>Name:
This Algorithms Registry</name>

          <dl spacing="normal" newline="true">
          <dt>Registration Template:</dt>
          <dd>
	    <dl spacing="normal" newline="true">
            <dt>Name:</dt>
	    <dd>This is a descriptive name for the verifiable data structure Verifiable Data Structure
	    that enables easier reference to the item.</t>
            </li>
            <li>
              <t>Value:
This item.</dd>
            <dt>Value:</dt>
	    <dd>This is the value used to identify the verifiable data structure.</t>
            </li>
            <li>
              <t>Description:
This Verifiable Data Structure.</dd>
            <dt>Description:</dt>
	    <dd>This field contains a brief description of the verifiable data structure.</t>
            </li>
            <li>
              <t>Reference:
This Verifiable Data Structure.</dd>
            <dt>Reference:</dt>
	    <dd>This contains a pointer to the public specification for the verifiable data structure.</t>
            </li>
            <li>
              <t>Change Controller:
For Verifiable Data Structure.</dd>
            <dt>Change Controller:</dt>
	    <dd>For Standards Track RFCs, list the "IETF".  For others, give the name of the responsible party.  Other details (e.g., postal address, email address, home page URI) may also be included.</t>
            </li>
          </ul>
          <t>Initial contents:</t> included.</dd>
            </dl>
	  </dd>
	  </dl>
            <table align="left" anchor="verifiable-data-structure-proofs-registry"> anchor="verifiable-data-structure-algorithms-registry-table">
            <name>COSE Verifiable Data Structure Algorithms</name> Algorithms Initial Registry Contents</name>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Value</th>
                <th align="left">Description</th>
                <th align="left">Change Controller</th>
		<th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">Reserved</td>
                <td align="left">0</td>
                <td align="left">Reserved</td>
		<td align="left">Reserved</td> align="left"></td>
                <td align="left">RFC 9942</td>
              </tr>
              <tr>
                <td align="left">RFC9162_SHA256</td>
                <td align="left">1</td>
                <td align="left">SHA256 Binary Merkle Tree</td>
		<td align="left">IETF</td>
                <td align="left">
                  <xref section="2.1" sectionFormat="of" target="RFC9162"/></td>
              </tr>
            </tbody>
          </table>
          <t>Registration Template:</t>
          <ul spacing="normal">
            <li>
              <t>Verifiable
	</section>

        <section anchor="verifiable-data-structure-proofs-registry">
          <name>COSE Verifiable Data Structure:
This Structure Proofs Registry</name>

          <dl spacing="normal" newline="true">
          <dt>Registration Template:</dt>
          <dd><dl spacing="normal" newline="true">
            <dt>Verifiable Data Structure:</dt>
	    <dd>This value used identifies the related verifiable data structure.</t>
            </li>
            <li>
              <t>Name:
This Verifiable Data Structure.</dd>
            <dt>Name:</dt>
	    <dd>This is a descriptive name for the proof type that enables easier reference to the item.</t>
            </li>
            <li>
              <t>Label:
This item.</dd>
            <dt>Label:</dt>
	    <dd>This is the value used to identify the verifiable data structure proof type.</t>
            </li>
            <li>
              <t>CBOR Type:
This Verifiable Data Structure Proof type.</dd>
            <dt>CBOR Type:</dt>
	    <dd>This contains the CBOR type for the value portion of the label.</t>
            </li>
            <li>
              <t>Description:
This label.</dd>
            <dt>Description:</dt>
	    <dd>This field contains a brief description of the proof type.</t>
            </li>
            <li>
              <t>Reference:
This type.</dd>
            <dt>Reference:</dt>
	    <dd>This contains a pointer to the public specification for the proof type.</t>
            </li>
            <li>
              <t>Change Controller:
For type.</dd>
            <dt>Change Controller:</dt>
	    <dd>For Standards Track RFCs, list the "IETF".  For others, give the name of the responsible party.  Other details (e.g., postal address, email address, home page URI) may also be included.</t>
            </li>
          </ul>
          <t>Initial contents:</t> included.</dd>
          </dl>
	  </dd>
	  </dl>
            <table align="left" anchor="cose-verifiable-data-structure-proofs"> anchor="cose-verifiable-data-structure-proofs-table">
            <name>COSE Verifiable Data Structure Proofs</name> Proofs Initial Registry Contents</name>
            <thead>
              <tr>
                <th align="left">Verifiable Data Structure</th>
                <th align="left">Name</th>
                <th align="left">Label</th>
                <th align="left">CBOR Type</th>
                <th align="left">Description</th>
		<th align="left">Change Controller</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">1</td>
                <td align="left">inclusion proofs</td>
                <td align="left">-1</td>
                <td align="left">array (of bstr)</td>
                <td align="left">Proof of inclusion</td>
		<td align="left">RFCthis, align="left">IETF</td>
                <td align="left">RFC 9942, <xref target="sec-rfc9162-sha256-inclusion-proof"/></td>
              </tr>
              <tr>
                <td align="left">1</td>
                <td align="left">consistency proofs</td>
                <td align="left">-2</td>
                <td align="left">array (of bstr)</td>
                <td align="left">Proof of append only property</td>
		<td align="left">RFCthis, align="left">IETF</td>
                <td align="left">RFC 9942, <xref target="sec-rfc9162-sha256-consistency-proof"/></td>
              </tr>
            </tbody>
          </table>
        </section>
        </section>
      </section>
    <section anchor="Acknowledgements">
      <name>Acknowledgements</name>
      <t>We would like to thank
Maik Riechert,
Jon Geater,
Michael B. Jones,
Mike Prorock,
Ilari Liusvaara,
Amaury Chamayou,
for their contributions (some of which substantial) to this draft and to the initial set of implementations.</t>
    </section>

  </middle>
  <back>
    <displayreference target="I-D.ietf-cbor-edn-literals" to="CBOR-EDN"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC9053">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
              <t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9053"/>
          <seriesInfo name="DOI" value="10.17487/RFC9053"/>
        </reference>
        <reference anchor="RFC9162">
          <front>
            <title>Certificate Transparency Version 2.0</title>
            <author fullname="B. Laurie" initials="B." surname="Laurie"/>
            <author fullname="E. Messeri" initials="E." surname="Messeri"/>
            <author fullname="R. Stradling" initials="R." surname="Stradling"/>
            <date month="December" year="2021"/>
            <abstract>
              <t>This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t>
              <t>This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.</t>
              <t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9162"/>
          <seriesInfo name="DOI" value="10.17487/RFC9162"/>
        </reference>
        <reference anchor="RFC9597">
          <front>
            <title>CBOR Web Token (CWT) Claims in COSE Headers</title>
            <author fullname="T. Looker" initials="T." surname="Looker"/>
            <author fullname="M.B. Jones" initials="M.B." surname="Jones"/>
            <date month="June" year="2024"/>
            <abstract>
              <t>This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9597"/>
          <seriesInfo name="DOI" value="10.17487/RFC9597"/>
        </reference>
        <reference anchor="RFC9596">
          <front>
            <title>CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter</title>
            <author fullname="M.B. Jones" initials="M.B." surname="Jones"/>
            <author fullname="O. Steele" initials="O." surname="Steele"/>
            <date month="June" year="2024"/>
            <abstract>
              <t>This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) "typ" (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, "JSON Web Token Best Current Practices") to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9596"/>
          <seriesInfo name="DOI" value="10.17487/RFC9596"/>
        </reference>
        <reference anchor="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">
          <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.8610.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9162.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9597.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9596.xml"/>
        <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="IANA.cose_header-parameters" target="https://www.iana.org/assignments/cose">
          <front>
            <title>COSE Header Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC7120">
          <front>
            <title>Early IANA Allocation of Standards Track Code Points</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <date month="January" year="2014"/>
            <abstract>
              <t>This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="100"/>
          <seriesInfo name="RFC" value="7120"/>
          <seriesInfo name="DOI" value="10.17487/RFC7120"/>
        </reference>
        <reference anchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="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="BCP205">
          <front>
            <title>Improving Awareness of Running Code: The Implementation Status Section</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="July" year="2016"/>
            <abstract>
              <t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t>
              <t>This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="205"/>
          <seriesInfo name="RFC" value="7942"/>
          <seriesInfo name="DOI" value="10.17487/RFC7942"/>
        </reference>
        <reference anchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.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.8392.xml"/>
<!-- [I-D.ietf-cbor-edn-literals]
draft-ietf-cbor-edn-literals-19
IESG State: I-D Exists as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8392"/>
          <seriesInfo name="DOI" value="10.17487/RFC8392"/>
        </reference>
        <reference anchor="I-D.draft-ietf-cbor-edn-literals">
          <front>
            <title>CBOR Extended Diagnostic Notation (EDN)</title>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <date day="16" month="October" year="2025"/>
            <abstract>
              <t>   This document formalizes and consolidates the definition of the
   Extended Diagnostic Notation (EDN) of the Concise Binary Object
   Representation (CBOR), addressing implementer experience.

   Replacing EDN's previous informal descriptions, it updates RFC 8949,
   obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G.

   It also specifies and uses registry-based extension points, using one
   to support text representations of epoch-based dates/times and of IP
   addresses and prefixes.

   // (This cref will be removed by the RFC editor:) The present -19
   // includes the definition of the cri'' application- extension. cri''
   // was previously defined in draft-ietf-core-href; however the latter
   // document overtook the present document in the approval process.
   // As the definition of cri'' is dependent on the present document
   // (and conversely has essentially no dependency on the technical
   // content of draft-ietf-core-href beyond its mere existence), the
   // text (including IANA considerations) has been moved here. -19 is
   // intended for use at the CBOR WG meeting at IETF 124.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-edn-literals-19"/>
        </reference> 2/25/26
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cbor-edn-literals.xml"/>
      </references>
    </references>
    <?line 757?>

    <section anchor="implementation-status">
      <name>Implementation Status</name>
      <t>Note to RFC Editor: Please remove this section as well as references to <xref target="BCP205"/> before AUTH48.</t>
      <t>This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="BCP205"/>.
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>We would like to verify the information presented here that was supplied by IETF contributors.
This is not intended as, thank <contact fullname="Maik Riechert"/>, <contact
      fullname="Jon Geater"/>, <contact fullname="Michael B. Jones"/>,
      <contact fullname="Mike Prorock"/>, <contact fullname="Ilari
      Liusvaara"/>, and must not be construed to be, a catalog of available implementations or <contact fullname="Amaury Chamayou"/> for their features.
Readers are advised to note that other implementations may exist.</t>
      <t>According to <xref target="BCP205"/>, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit
      contributions (some of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
It is up to the individual working groups substantial) to use this information as they see fit".</t>
      <section anchor="transmute-prototype">
        <name>Transmute Prototype</name>
        <t>An open-source implementation was initiated document and is maintained by the Transmute Industries Inc. - Transmute.
An application demonstrating the concepts is available at <eref target="https://github.com/transmute-industries/cose?tab=readme-ov-file#transparent-statement">COSE SCITT Receipts</eref></t>
        <t>Implementation URL: https://github.com/transmute-industries/cose
Maturity: The code's level of maturity is considered to be "prototype".
Coverage and Version Compatibility: The current version ('main') implements the verifiable data structure algorithm, inclusion proof and consistency proof concepts
      initial set of this draft.
License: The project and all corresponding code and data maintained on GitHub are provided under the Apache License, version 2.
Contact: Orie Steele (orie@transmute.industries)</t>
      </section> implementations.</t>
    </section>

    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> toc="include">
      <name>Contributors</name>
      <contact initials="A." surname="Chamayou" fullname="Amaury Chamayou">
        <organization>Microsoft</organization>
        <address>
          <postal>
            <country>United Kingdom</country>
          </postal>
          <email>amaury.chamayou@microsoft.com</email>
        </address>
      </contact>
      <contact initials="S." surname="Lasker" fullname="Steve Lasker">
        <organization/>
        <address>
          <email>stevenlasker@hotmail.com</email>
        </address>
      </contact>
      <contact initials="R. A." surname="Martin" fullname="Robert Martin">
        <organization>MITRE Corporation</organization>
        <address>
          <postal>
            <country>United States</country> States of America</country>
          </postal>
          <email>ramartin@mitre.org</email>
        </address>
      </contact>
      <contact initials="M." surname="Wiseman" fullname="Monty Wiseman">
        <organization/>
        <address>
          <postal>
            <country>USA</country>
            <country>United States of America</country>
          </postal>
          <email>mwiseman32@acm.org</email>
        </address>
      </contact>
      <contact initials="R." surname="Williams" fullname="Roy Williams">
        <organization/>
        <address>
          <postal>
            <country>USA</country>
            <country>United States of America</country>
          </postal>
          <email>roywill@msn.com</email>
        </address>
      </contact>
    </section>
  </back>

 <!--[rfced] We had the following questions/comments related to
      abbreviations used throughout the document.

a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide").  Please review each
expansion in the document carefully to ensure correctness.

b) We would like to update to use an abbreviation (instead of its
expanded form) after first use in accordance with the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev for the
following abbreviations.  Please let us know any objections.

VDS
VDP

*Note: In the meantime, we have updated all uses in prose to be
capitalized for these two terms.  Please review the use of "verifiable
data structure" (in quotes): may this instance be changed to VDS as
well?

**Note: We also see "verifiable data structure algorithm proofs".
Could this be made "VDP algorithms"?

c) Things get a bit messy when we look at the expansion of VDP if the
expansion of "P" is plural "proofs".

For example, in the following:

Original:
This document describes how to convey VDS and associated VDP types in
unified COSE envelopes.

If we were to expand this, we'd get "verifiable data structure proofs
types" (with the double plurals).

However, sometimes the -s on proof disappears when this was expanded
in the text.

For example:

Original:
..defining the integers used to identify verifiable data structure
proof types...

and

Original:
A data structure which supports one or more Verifiable Data Structure
Proof Types.

It's also a bit strange for it to be plural here:

Original:
The combination of representations of various VDS and VDP can
significantly increase the burden for implementers and create
interoperability challenges for transparency services.

Where we will have to make it "various VDSs and VDP" (the reader will
likely expect VDPs).

Is it possible to update to use Verifiable Data Structure Proofs
(VDPs)?

 -->

 <!-- [rfced] See a list below of terms enclosed in <tt> in this
      document.  Some of these terms appear both with and without <tt>
      (alg, receipts, vdp, vds).  Please review to ensure the usage of
      <tt> is correct and consistent.  Let us know if any updates are
      needed.

<tt>alg</tt>
<tt>exp</tt>
<tt>iat</tt>
<tt>leaf-index</tt>
<tt>nbf</tt>
<tt>receipts</tt>
<tt>tree-size</tt>
<tt>vdp</tt>
<tt>vds</tt>

-->

<!-- ##markdown-source:
H4sIAAAAAAAAA+09a3PjyHHf8Ssm3KqslJCUSL1p3/l0ks6neF9ZaX3lutrS
DoEhiQgEaACkltbKvyW/Jb8s/ZgZDB58yLtxUuVcubwiMI+enu6efk2j0+l4
i4E48Lw8zCM1EBdvb67EzsWPb9+Lt8P/UH4ubsJxHMZjIeNAXMV+upzlYRLv
ivfKV+Esz7wg8WM5hb5BKkd5J1T5qOMnmepMVXofqU6eKtWZpUkyyjq9Uy/L
YaQ7GSUxdMnTufLCWUp/ZXl/f/9sv+/JVMmBuFH+PA3zpfcwZri8+4eBuI5z
lcYq71zibJ4v84HI8sDL5sNpmGUAWr6cwcjXV7c/ebNw4AmRJ/5ALFUGf2ZJ
CuCMMvt7OS1+enKeT5J04HVEGMOzt11xkysVKWjIK3ybhqp4lqRjGYd/kYiP
gbhNZaAWKg1HywBeqqkMowG0CdUPSdo76IYJPPWTeZyny4H4EIe5CmAsmcPM
esKfu+LHML2fJNFf7JQ/q/jefQqTDsRPqZzHk2SkUnFzfQtP5XCYqkXDCw3G
BEbpDvUoP+AWdX3AlPRzRALuEKDx/UQBGHkqs0yJkyMCNwAQXh4f9s+OXuJv
2I6BuJTpFHYxyN0F/V6lUxkvzVLOu+JSRUA6Mu+8kgs5D+yKzuM8CWPV8L6M
0NehnyZZMsqLZcg4D6IfpuYFrGFaQuofzPQXXfFTMkc6sdNeqCANfefxxtlG
3HTtfB6iMQ2H8xwJR4hi+RcTOZXLZA4P7cqncp4uy29WQ1Gsmrp1fd2tBk+d
rP4ADBvQOw3PTVe8ktm9Sh1ogI4Xyn2sp8vweRzR8x8mSY5P9Ux6tPddXOBr
meZh7Az4PhmqNHefVxZ3ffv+Slwk6SxJ6ZE7awqLw36wOiDHLvRsXJlmGAvK
6674JcxgDBeQ1ygESs+Rayrj3Zy7008fuPVB/wfpT/X0xXJ/CaMolNOstNpl
+fHGOdJk+QAdfphmMeHTixPgmTxcKOz3/qeL0+PePhDq5eUr/fvs8Ax+gzDm
32f7RwdaFPLv3nFfdz07OjsZCP8h70wUyKG040cyJMD45TG8RJkMwtHzwnhU
mfmk198f2EnMoKe9PvQLZSxBoMdZCOPSvmWd8Rx+QKMfL971948GNMTZYV93
OzjrA5i/oPy57lx23XNhmKQdFcSdCHYzlRFgt/bI8zwV5yhpoP/N1aufBqIF
o+aTMGt5XqfTAWmHUgpkl/f840rASQRkD/8/A2INVSaSkZCCBHcoh5ESgcwl
ysS5n89TBaeHfa3SrvfHVQ0zmhJkZ+KHEkmVjjyBp1EmVEw9Mn2kOdO3RTb3
J9BPTMM4nMpIBGHmR0kGQ7bhVJRxNoPzMPaXNH6cxB3153m4SHzaiq536zaZ
qGgGI8kQZHsY86EqYL2pyMMpjIdDTGCuoVKxkLNZFAKgsEIfgRmFPjJXG6Cl
h/iPYhRCq6nKMjlG1GZLEBHTjEfL5jDKUoBwgvnM+gAq2C2RzZTPowKkGgcZ
0GHsA7OV14bnZIzT2MGHSzGch1GAM0Jv2uOdC933xzCWIEn1nr9XM8A/9Je8
1wgXUgaCoYT6nCsg3mEYIeZxS+AhrD1NJCAewAzUNKFzD+cf0uYsQpqXJgX4
EvyVwYGQitek1IBg8KM5ahs0GXEHwI0rYU2ny5Q6DYMAdAXvBeotaRIAqaDc
Y7q1JAk4EBnQrSGaDECUOc8RKMA8HLZIa3KYzHPaK0I2icJN5Lvzx8ubXR4P
p0GFSzyAOkBYcMEQD0AXoEHNVdCtwOfL2ALjAigF6H7zKSAe0QggSZp9KGGH
dpj84X8WVbtt2820gm6wE0hoSQxUVHRyMFp0y4A9IqDlTOXYhhCAszMGSaEJ
EYkESSTTsWpoWszhMppkYgX28xEueNsIPxCAZmuEyOwEoRyWEic5KJK50NTY
iBHaMOBiZ9iudxmOQGXDLrBbhO4ZEQvspn2zeov1uLDT73aZ5OF0GQKHENvB
dGmJPwiChUzDZJ7RfEjB0JfmRTIklo1z2A+AEVRx5FUYdDhPA6AbZIJwOosI
nSplsYfNcuQKeIKSTWpuA7EAOxaPFTNPieUzlS5CX2VaWFhSClTmg0YFXSbJ
AwmnJF6opQXVEbEINQtYQPUcAVfM+cC0CxUBJMiIL14AKYPMTDUFvEkYER7h
6h6GfkjSIBOt1x9ubltt/le8eUt/v7/69w/X768u8e+bn89fvbJ/eLrFzc9v
P7y6LP4qel68ff366s0ld4anovTIa70+/1OLpWjr7bvb67dvzl+1cCV5CR+S
D6GhRi9sJS5dguGlEUUEDyfxf/1n71A8Pv4THJb9Xu/s6Un/OO2dHMIP5Hqe
jXiNf8LGLj1kQZkSuUbIALMwh3O4jYdSBnsQw7ECKpnn/cuviJmPA/HboT/r
HX6vH+CCSw8NzkoPCWf1J7XOjMSGRw3TWGyWnlcwXYb3/E+l3wbvzsPf/i5C
8wRs1d9976HofqMemKh+JtVKvJOgrCqi/ccXM/wBukuWP3k1Qh7BQCgrwb4S
sRmFFTQxs6O0YS9C1AFS2mLm/EDMZ51RmrAYIYoAgzg3J46K4DDgEwueRPBH
WqMc2LHbHy/v9sVOCuSvMiYb5HAC7+DscHfgeWCWNMNFem4gPqX6GPgkHsJ8
goeNjOAQQb6jwydNJVFTymKCf2thDLIGUAmcP03S8nGTEXWxgsAU3AR7byXs
R1vBvggA7B1HZ7tE0XljROeuQT2LmIwXEI1BG8knUwE6bpyT3kfSa80x2wVV
FQwbkLKzJEZlIVq2K2xsdxZWTsSQqjFQDWgxO4+PxcAdHLhjB+6YVk9Pu0xQ
qJcgmCgMxkiD84x1OA3tcjWUmcZqfyVWj7fE6gywCqIBrD1ETGvT2dSqIVqC
kjozVIJL2ni8aVvSqmhat/6fw7x2WX3LDXBtAjyYxK1KQe1PomS8BKUQDL8B
YN8ouUSrlzQl8f0rGY/nEpSaHWy5y6rryGg8j4/agnx6gqGvLt/QUKjAXqEC
HECry1CO4yTLQ9+egWIHWjYPBcbn01Nbc3ZIKl6qQBlJebXAvq2gGDDWA+oD
jRovwswMWLf8CMyVnMl6qybGChKZktDwAAIsS5jV470jzN8y5oUgSa2tsKWj
csjY4X+zsdaeWiMB2sQJ6rNE1QgaDtlC0eYCetiKgdcu/J2jzTWv34Cl9SLX
zhyxgrpAGi1UxyZrE32dSK5snLULdbTt6t68mSPgrgmcZIQ55/Rz7YLpPMpD
XHqh5UoxDhdoaQBopDrbNgysVbJ3VlpToM96xc5pdNhtYyUcgADdKBlq5X+o
+W9JXgANglbm0RB2yUWh705p02XlluCqfyo2F40FIE4HlQ2b3WZtmmnUwQmd
mi273pZmL4WmKAMJqx+F6dSaWLwAhHTJVhbhWxs5ekbomFtM/RGPZ0ZVbI1X
3o8CldidhAOwJv7LQoPcVrYnzbiW6InemB31EvVuwLEBYIMh6enj3j1WErLa
Sb2sCh10PqHQcQ4GFLU1lQnEuI/+CIDQNRDe8Tkdl22EGxK1K7c3K3DxIlN+
Z6xiaOp3Vp4MmdH0Mq2QFeKjydLadLCxfDSbUCI0n/wS7DTgHXTlSaTkiPhK
OtakpiLQHKdoBEMT9mA5lNIW03A8ycVELtBAXqA4dqRFZQ1tWB5a6NoPg9ux
ekkomgpz1mfcVpGCem5p/wybqBFYnmFh7BrZBJYdaCuF94yEXLiQftmRRqIK
3oH1O4Oe2gQlpdV4ogrLlWGp255aZX9IjN8IUZqEaDeSgEcn1lp9JeMZidIR
IvYmab8X2m5me7VJDPis+BA1XZR4w+j+/W6ve4CkoN2/YNdhl3KDw1IDdgkA
BKDmafdXVpqTpMoIhEbss/zMyYUAPBXzhoGiiKvOJooRTGv7A6hxbFw7nMQc
RJ7mtexzE07DCExO2PxfzWh8OH/cmeT5LBvs7T08PHTR94zO+L1CS832cHj6
v+7nST6NXoAFj35t1Oa3cJdkltyKxvZkJg25RBHF2lHQW81xLWMXw8EhAYy6
nX5PqA0UyL1II1arAtsgVWur61DrnNxfgeROIYR3SYRfXfTRhwIaS28g+rv8
d8r+FqJNPMDEVEmW5knBi64FbM7SDlh8frqAoTtgpXzGfw/EDvoAO4diJ4B/
NV3f3fx83j86FjubzEQxEL3dQlscJsCcOx14VFY6djoAe6Mf9xvSgx50M1XU
bI8KcbxzdD7yHhucAn6Be8PUPQFXm2etktbqso9zzmT6uKizTcNp16ocRC0U
1q0aXltd79r1IYItOY8CcqCqzzP06ddciRKDntmaxWQwqMkZgC2V0RLmFOSg
GpI8Q+87udjDhNgDloXxLKZKtAsdGUHhj2yufRr0shg6sMcPYHk+nRXHmvR9
NcsJOCPc4UgknzKz9IcMDbjHF9qp0sGNqzmOeNvJt1q4jarOJ9cxs7PJz7PL
CyLArAOGnYqsPBkXDGkluSJE4ULncfGbtTDaZoKIoy9Ijr+YgIIBqe46IHOL
iKXt6BDwgjZIK72s85ITpiDfNXwVr3urj9GpzEG0GE3fcc0zvMRg+MY95Iw3
qhTA0jYSKULkAoPtCbQmns2HGeLebp4OlHYLDbggxVyOx7RFhMY7jFj2uuyM
HiVRlDzgDKgSgpUPnB8UHgC2WVGdCECh/utf/yr8IIi8G8qjgDXf/QJS5s4E
dL4TL467vdOdYpZdzFcAUozkUEXwHphM7IkcNB1+rpf1ncBMDhQyvPN3mva+
E49gCv2LcMf4Xjg9PSDlDwXFlPv9846hjgHRpMDOv/6rwGCu6KJ/wJDmx82z
FGuC0X+F9gWZCpD4zpjVVbShsUvVmFpQhRjbzOQySiQOZwfcE3EY4bvMINy+
8z7ajQaA9F93oMzfXVuBuFd6flHIRM/7DTpkWNZoHkQdnoL0rg+eZAwKlvIh
2IX+b6Ffuk7rmcola/wlv0AxDVCg1wy3oaMbClEWL+7oFNr1vOYXmzamvIZy
79Ju1DZsZc/6Tq7ZyNX7uC1glrDhgCctA+gUWIoeLQIi8yPn4QaSfsaq7MSL
YDYgty2OVxmgMHirO5M9G5g1Y1lY7MnP2stAdHpNYNVgWbd0O8Wv4l83DCQ2
7BwRpEN+SJuo3txl4V/UQMxhj5C10WK+C+NAfS6e2ZXdgV05GRAwNNJHJBdv
BVdX+cZ5VeWc2qtn8k6l/wZ5t6bzM0Wh+A0Gx1Rackugi2Fb3loH+Aruajey
V/vZJL1+2c/lsNoOfhWP1Uez8DiqtOWzfhNwDRCtR8I6XqsT6Ma9bOK3guHu
egV7OU/7zlNnpY18B+qP9zgQL0bhuGM0iw7qQ4Jymb9rof6kA3ekr7K6wEHM
PJc+anqmY+upqoA5SXLi6vJNk+6FIQ0MgXh7nFyX0QR7AngeV7tX4t898dvf
PlI64J64DwP4/0Pgi8nLod8/Oxke9brdrjpUwWg/UC/bul1hOMKg0Lpz0hbi
hbi6AXxDk6fvv2/TPC5/7wkzi1XG91Dfgu78QgAgzQDzf6vANm9d4OXQB/W0
1wfgDw6Pjk9Oz/Y18Kb1hiUUDYGj7d/A2Gi2t6GhJjIBRNZxu+i1mx5NGHCW
g4SNwx47WDCvQ0dB6yCIv5YaILqqT7Ab0iv8c9aG/yM36544bTe0cwxiIGKx
V2syeXlydHQqz45GSAL7fXVwFBy/rDT7+P33pScf3ameih9PLlJcuQ0Cex5F
7ltXQO8BFPv9oN8/UQFA4fvBwcnJ4chA8XG3wPb/E4/7+uuI59ghnqO/kXjO
Do76o7OTQ8Di4WgkT3xVxqJpd3R4un88OkBsj/b3T5Tc/98gsoPjo9Pe6OAU
oJBA9b2z432XyDw7/BNLtvLoQKS94xP/6MSH/oFSKjgODl9yy+pM/aPDw1Gf
yPno9HD/9Oxg+NL7uNt8bKggNqcGhr50FNeeGjwunRw2hlk9OawLrvBAGEeJ
9QBQmB2DKWh96WBKqblJytSmrVk9OjrWB15M+M3NgawMVnflcGSAjknHyYAn
5uagVVbyOVL8ck12zKoMPz1a3aQ18BfnsQ62Fa7xURhRxGGm/+zAGmAvMFtr
jRmMAUrjnc4pLmIXTgE2PRqjxuCfPDywwqJxJnRSGgU7WZnoepf6L9ORVuYX
zi7yuQHhJNPZXJv7qC1ztK4w/HUQCPdKyDGmUeWVwJVQaZrAcEXaVUH+gGk9
XyCGc3an2YVQAFnHxyJN0nbirmfRamPzdlwdkOaoFHq+CA8yElWqcsO0koLs
fjJP5djkUtwr7aJmXxygZwoLlnnCwUDrdsXYPl1ioFFgFowYwiAG5jAlJzFl
ttDdjTz0gTreAnQPkoYyuQnky7P6HOXeFunPBWmHlMpj2DBfzsQOhZVqrlfj
v++YKxU6Csf7wOEXvCEhcXFGaTR5MNUrGhR5f0E5qoXjsJSw6nlXa9mrkmeP
af2U/ECZuvYAMT5NG7Igd6TeTp1pS9kCaoOocbLiKNMnz0opKDqY3mWgy6A1
TGkSnU3iB0gIxiNHG8r3KNDBj4jHeFg68jsoMNbExAp2xQ2i5B4t2tlnjQ61
CoQ2TiSFP0lCn8hhIrNJoYtQsrhCIgcWvj5/c15y+cIBAdw6RKIO2FdHsrFY
jpMFVIr1My6QVGykBXtrcYjogT8P7vAHcYA2uV2HAzYq3HbvymFkzJBDEbpQ
lNj9dTHlNsfRWmWh3eJcZuchwduyAtfJt2Hve6QWwLclLIb1jHDKVzah+eqc
lNxROTw4Yvo8CqnldPB0RKaTGhOUcq9LmCojMkTH62zGso/ESpHx50b4SxmL
bZBDJgZAaSF6PzoosLS8WJ3PwuqIzk6s5rDSPKuTz+Blj48+3Am0gp/bvbo9
7SL35Ba9Q3ximUNeJ09Kzrwt85lh9mdESU0Xl3ArG7JzWTrwcVoHvN22dhjg
GRlhsgZv9Kxob4/XRkUHd6bCggU1EjFmEwlL71S8pRi4r4F+UAP+95ibxDFL
EGaVib4S+FJSLWuGmBRVDvKSktSQbtSgwGXsJtExqsp6q74hUvx/ww5EMo7w
9J+nbixa+xXZXdQpvLamLzltET4yqOj2m1L0Dh90HJ+u6UE2FeleJk9q1ZQO
9HVP1F+NSVHZYvIPVdct8dLzd61IjfKWdVRRli6dvYG1WSuba8wMlB/iU7Gi
T5aJaO8jE/W1mh2qNJXYZpXK+pV8IU8Ho2APOCuPqc+IxMrmZyyfcXpCYwzL
0NlYOARQwffieuQ41hHiMV0YQoEC1ITH4J/noEqijDS+QAoTgzUiw8hRjd3E
ME2lJu2anXaaBmQBC+ciR+zJw1y4KGIYzTFUEF2RzljMiNfiTHKp1dQ40Adv
7S553jWmSuprfBUUtatKuCN2rM9cq7w2lz0zRwacFcgOBOEnS/yftIlS1b51
BmTNnCozrGsulPjUjme0VMzT/1viXJ2S27tDbm/vqWAW6AgU7PCHSYmoQtDI
MjZYYJRzlnxNO4Oc08FjRewQSLiCgTB3lLqOgd9086PL+bSCq0qEeDOlQ+4m
M9im/KPSXCtvD287N+153ZL/2l2vimcTBqhKr4+e5xzHtun6AGB1bIxDOEto
IrRS1KU24zNobIY0Vp+skabON10f4ETx2E0Y0OTHNAbTlchi3T2bLclCZ6GV
COG1nHWp0EV5b8zMnTJ5X1ekdXmsc7qtBb3xNNPkZeQUH/XPIKmaWGOFriHN
2xw05zHFVozDrczEThL4diqHvp8WVLwwYofN9ZKj6GnX5YG/OZKz0UP9DN/0
hnDOCk/0Wh902fts/c79fcfx3DspO93X+JwnL0HDGe0f7WOoot/v+Wd9f1jy
Nk9eDoP93sGxRL/r8bB/6o/6vUqL4PhUjs6CY2hxdjDsHR/0h4UnuvBBa+/z
am+w8TXXfb+B6h+O9n30Ep/JI2DQ0zPj+y1panesqd0VAX59CDXKh1WHC/IM
Xk6uJdBpWRNWrivMY0yjy43HqMZRhTnFAzY5brWNV+5J9RiK0yxVhSMwRC2L
ev4UwtzlFDwuBJE1QkOXB2YJCC+UTnwpZAdv1U/VdKjSXTFc5mixX2vzQvvp
SG/L2o1D2kwkqkKRA+urVPv16uNkc99XKtBDgWo0j+gqWuVGA2ttGmE2uqvt
Sif6qymIMkWTklcd8AB9/Pus4k51vPJCp+pdjxxgyDdtW+uxNLiGYrDkBjp3
SpqhHtjes1nrdVs7aZAoLj7AF5/alRWsxTcarK4PaY3JWks9aDRaD9carfW5
vrnVShZlg9Vaz+7ewmytrRlUlEbLNYmCIg+G1XljVpSN1k6vbITGbgLN2o79
VdZrw9xJfdwu9SstqGrLNhizRkSWsjGeZ8nWthyFZsWOKmVDupZUbdPaJiO7
Ie2IamzQlUOT2sx9tTmMpqaLKtuPLsDitbG8ojmwV3qtRebsj9GftlPO6+T4
f8Yoc4nkG5tlzkb/Axtmz9j7uggyxlldNq01z1ZnjtVn+PuYaH93k6mOMWs0
9UujX1T352vNpk0bftso07axn4zthHbUavtpu8PvH9SAcnGzhxfP1plQcIJY
Cwov5wDY+4dlC6qE67oNpY6GB+rkGDN2/EN52jsY+hUL6fREncr9U87pOeqf
jY7PKi1GJ73+6OQYrayzvtwfjQ6Ot7Cyyi36h2dqJIfYYnhy3Dv0/aAKx1EQ
HPfPDjBD6/Ssdxj4vW9sqZ0dHh6fjU5whqN+oI5PZG+tpeaqIetstSvNFe5W
6PbfwGRr4OatjTbHQGuqHLfKbGuy25rtlXiVveL6zl37rA6DrmVG46uysdTY
WDfEu8M2+wBTadSCiozVveFJ81gbQXWLxc1MGYhktN52MsvBy3opLocCvW4F
QDeVqSwSt7xSjCYWTmEi900XSa91CRWwc6actcJV/so30qEBDMkKcDyGqYZJ
EilKWiLTd1Rckypjie5K6hv7lGVEaRWE5gkloiBt0fVE3h04iUPXXUDFMcjP
xm8aNsfDvCu++HhRqgdq9F5+V64VaiPqaFY+VlMMdEibyYbpolwFCsyEV6Bt
v1LxOJ+AvZlMV92XByzda174izXbtaZOYZ5wqkr1/LpoaBCCuMQdldvADkRe
WZ5Qvpiu8Xcfov5P3W0ekS40xCllC4VVFPiGrgnl4J1W2F/p013Zea7DVqW8
jxBN01JhvDIIwFUppZAAfWG5vDZdO2YC4PO+9F480KwaHjKV5uio4YwuzZDc
A9HnoIba6jGwHCnmrxRw6b2olUADHaRIBasngDm4cROwuJIlB9/qJQExIIhp
RYgInTLCwS6zbp00pC+PAuHjyCRx9LVcc/uXY6KRk2EGgjMKyJFvtBmB1RkD
lpvVO59E8/ZScZXo0flBBGcarKT8Aeq6DvXTL0377IKxyUaF1XNuywgAkt37
x3pxyRyvZbOpq3GggmoKHeWuhGOs6OcePVbr+gR/fiIHlS2LCljE1CbgMmI6
urOPkxc5r4CWBmmGzSLMWWyYR7MEnOJYqRNLyibjVM4mIHPR75PEVJnRBq3X
Vxgp3VofeD9iKlJFk6Xyv6hD6oRbm207kagssmY9mse+2eUXqN+HASL4HUye
BOSGyFDcoHgAtrPXKV6f/8mmFmKaDKx4YfrOqG9WuVcvMe+KKT8m70wCh1pq
c1znXECKeszCVMuWhpYzmeVdS3afYJs+tcWneDj6xPH2T9D/k8ma1HVlfrnF
dC0EJykyI+EgQG9bmE2I6E2JEBZeQIQwDgi/TF91Li2NFBTkXtR6fDh1isSg
stjGUt0gaz7MAirZvRKd+u4/EHELJEXi465z2YBsnlHlGXwACxxhwsBQUZyf
6tTiIGOZBhE6ilngh2kV4HVrywhEte2aOE+tKgWQe5su6MOKsXnI1TDYokXU
B0GhoNUFZsnUc4pLPlGxDfzTvKS63Nowp4YZNtKqVau5YGWrSP98fPwnhK+L
5tqdOww1xNQ1prmX1zqTTF8OJ48jshDMdHx0dHD0UoAIx6p0L29KqZQ6hTV4
Wc5sfYeO/QCLL/LOsFn93oDF9QQDgDR0nPerA7NmPTwYOijIorfJHTDWrMW1
GTLtUrTZ1huG1jHfYgbvi3gD+NH2zxfxilwb6/77opdH9Ve+VNf6RVw6ru6/
x39fYHJdmqn+zvvScf4r/Vjx3/oO24zwbf9bNyMszy2Z8UWsqZmhCxR80cVM
NepquHyHlUS4IFVAIRWuAcHneFE7HF3hRth95e49Pv4zVsRHRi9LB0HLo3Kn
uuka96f2DX+h+g927A3c8KXQR6pZoasNo7YtVmjyvDfeLNlikbPSIle4DLVz
8gvJBLtI/IEVnzFLfSvuBy5PjB261cWYeFWt4K/fYfSH1KW+cXm8UQ/R0taO
MYWw60fA0/r0YSOeQjqz8QRzswe3EJuF2moL8W8tZDEKTb4WUOabTxMxS6KQ
Ku+sysE+7B7rACR+v8Jer7j6jN4CGGcRqgdP/0rpl1OBKMfrKcAWSVmXr9xF
4oJwpNTzQLr6T8AVT6k6KpVb41DVZzAsF6B+0PpnSRZSKqLJ0F7PQfghAfEO
5xPZn+cy59CvVZmwhr2+XdP13tvV1O/djBV6J2yBPdcYG1G81DmiNTtlTbbE
nAoYaY/KONHVk4I5KJP49QhSMtmvAVBEYGcGLk0WaaGsz9K6QtRr7hXb/0Nd
3xTL6qtZlCzpCgxhoUQQvMbUUIUx9HhEp5AZ3kNJYehz2DtNSphdgFn4nNPA
l3lsBNu6KfCTKEQ8HcG2Di7Y6efssq4PuFmmnDuF4Ypc0zhxYoz02YmtWIYT
B9RnQK1OtyXbGUgpkwQ2pXBPSDe7wK8UJfTxBN7tiEorlWoVCdeNWfKsFORG
JhQIEs1T20uCxxdblMDDUhoOGd4qMFEATuIzVLzwgzDku6P8D5smALyEhalt
xa0133JBwjPfIVEywwMstQqRVp3DXE0Jf7qQajEnDU4qXK3k84bkDRjNUfXs
mOSMKGqloysnVKN6AsSmsa1SZ0d2xiTqVKlZ3mwOstyvXHvaiDqapkZMOB06
s27QMy7xGwq3qfTvUfYCSeK5xTo4foyt1eW2YKxTxT8qC0jyUU6tu46ZgPkL
Trd8CZ24spEx4HZUd9xtoxRFjwYYU2jLtfkTS8XPCRqaM5RUH95f75J7VkaZ
/ogCF9BFHwbeA8FPfiR4j5AEeknD10cya+1bKOuOdk26tIcP0KelgqLJvm1a
ftM4GjfBccruDXjZ0430kx9LJYjpqo2jU6y6n8RB/20v2DSnfGwrA1pbyYx3
publ9td+1omNlRNZTnEY2qq1mbmetr4AXfeZgqlIVXqmJCJD81tIonK2VIeN
FC6tXRUcubkARPBaAUGTYozDEU5kcX8DIVcB7ptJteqi/xHE2DpDririROHM
+FKQRPFqveBrkHq9NUKtdnsIH3Z6/JLt7R2dWLHLRjaVbnfiNuXxSgbTFhft
njbAVw/dIXz9zfA1xiY3w1fPqmSpvFW9379FIrOEJTNQnPv3cfIQqWCsv430
+KL6CNr9YqJKqKYzx8n43nstQ+CRUPlA2Hnb+zfYmd/Tra629xr0Wgnk9GNX
wGOV4ZN7mjpN/Pu2dx3JNBSvwnm2kGCZtr3KpzHbnubdMBX2C5ukpO6QDxnv
ZemvQAwxLI/0v1uED/GDg2xpaEGqOUR/DaxWBJy+1TYElicnb7nSAruxzZ04
ig+LqyDE732KdxF9HStV02ShywyYmA/Ypw8KDBKZFXKdDKrHR/5oIlj0QzXC
rxCcf7j9+fC0W7mAjKEVFEWkcrMrHUDHvYlrMeNCfuaJn0TWiUy1vGsf4qvE
Q1EG6S8EUOPyF3bt5zxslIxqZEAnCneWLHCzMFtx3BXwVZhtjVW9XirRkNtQ
EppWWu6i2MXmGBIMYCFGeFA9CBPKGxufPm1+pncK9lbvUWyvNNKJFdo1yxi9
QUG4CAO8glips0G3lW1+Nb5c4ncRkzSjRqZaOoLY9X6apyjk8dMSGL7BevaY
DGA/uIjRDArYcZ62Js3CENcpy5QxYqwVDMXSNxZD3k9ChvPRWXNZXhuoFoVS
24RUjgDf6HxY/ABgwIY2RpKBJCTFm0eOi6JGXoYVR0pqp8R7XQu44vYosEzn
Y20kPMHIYsXcNR8JXDsQCuJpixbRBX4qFU365MHx0uCKHpL0HnuN02Q+yxwz
PJirqtcmsfEbHYCkPHjE+1DFwCQkDtJ5TEly6Ko1NwkQUFK+kYEVVmXQbl1U
gAhJWKc6DQtKoa8PKBWgGHHm4jD6xEEql7QgRs34MyRTqVP8yc8wnxViy5Jl
fdHzrKGwCYdxl+TSgNW1OBJHnwidYsUZzM9NUBGi1EE4o+JOlsyxRE2F7ulj
kCQ1TSXosPiuaPGVgGLk6ziYawfedex3Rad418W56I6JFkDFBzfNBz7w2whK
V0gq6BBwyCXsby6ub2+tE72oXj8Gw2I+xI/p7uVmNrwWrSGh+vW/y+XwO/RD
TVUnWXQw5P/CSWvo2E9D7npeRfR/eP9qIJ4zFxyJOQXpB+R8QYJ6iYkpCzgK
6eILvxWsyhKhGmYUrZnZG9i1C8zGQb2Pvs0IlI/gXLjftdAz6PvqC91k5yXu
0cvdYjuzDQaBU9ak6TpRPd3LbpU5L0jgdr1Xoa/iTDFc0JS+zErfa8RvCpb8
W1RkBl8RLA5VoQYR5j/Ph6bkD1fOYY8wruN8hnkrQs/VtuvuI8roe+alj7SD
pobfX7f71S32a9f7b8rrUyz8fgAA [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.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.

-->

  </back>

</rfc>