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

<!DOCTYPE rfc [
  <!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-scitt-architecture-22" number="9943" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.46.0 -->

  <front>
    <title abbrev="SCITT Architecture">An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/> name="RFC" value="9943"/>
    <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@sit.fraunhofer.de</email>
        <email>henk.birkholz@ietf.contact</email>
      </address>
    </author>
    <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
      <organization>Microsoft Research</organization>
      <address>
        <postal>
          <street>21 Station Road</street>
          <city>Cambridge</city>
          <code>CB1 2FB</code>
          <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 Research</organization>
      <address>
        <postal>
          <street>21 Station Road</street>
          <city>Cambridge</city>
          <code>CB1 2FB</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>fournet@microsoft.com</email>
      </address>
    </author>
    <author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande">
      <organization>ARM</organization>
      <address>
        <postal>
          <street>110 Fulbourn Road</street>
          <city>Cambridge</city>
          <code>CB1 9NJ</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>yogesh.deshpande@arm.com</email>
      </address>
    </author>
    <author initials="S." surname="Lasker" fullname="Steve Lasker">
      <organization/>
      <address>
        <email>stevenlasker@hotmail.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="10"/>
    <area>Security</area>
    <workgroup>SCITT</workgroup>
    <keyword>Internet-Draft</keyword> year="2026" month="March"/>

    <area>SEC</area>
    <workgroup>scitt</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 156?>
<t>Traceability in supply chains is a growing security concern.
While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains.
This document defines such an architecture for single-issuer signed statement transparency.
It ensures extensibility, extensibility and interoperability between different transparency services, and services as well as compliance with various auditing procedures and regulatory requirements.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        SCITT Working Group mailing list (<eref target="mailto:scitt@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/scitt/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/scitt/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture"/>.</t>
    </note>
  </front>
  <middle>
    <?line 163?>

<section anchor="sec-introduction">
      <name>Introduction</name>
      <t>This document defines an architecture, a base set of extensible message structures, and associated flows to make signed content transparent via verifiable data structures maintained by corresponding transparency services.
The goal of the transparency enabled by the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture is to enhance auditability and accountability for single-issuer signed content (statements) that are about supply chain commodities (artifacts).</t>
      <t>Registering signed statements with a transparency service is akin to a notarization procedure.
Transparency services Services (TSs) confirm a policy is met before recording the statement on the ledger.
The SCITT ledger represents a linear and irrevocable history of statements made.
Once the signed statement is registered, the transparency service issues a receipt.</t>
      <t>Similar approaches have been implemented for specific classes of artifacts, such as Certificate Transparency (CT) <xref target="RFC9162"/>.
The SCITT approach follows a more generic paradigm than previous approaches.
This "content-agnostic" approach allows SCITT transparency services to be either integrated in existing solutions or to be an initial part of new emerging systems.
Extensibility is a vital feature of the SCITT architecture, so that requirements from various applications can be accommodated while always ensuring interoperability with respect to registration procedures and corresponding auditability and accountability.
For simplicity, the scope of this document is limited to use cases originating from the software supply chain domain, but domain.  However, the specification defined is applicable to any other type of supply chain statements (also referred to as value-add graphs), "value-add graphs"), for example, statements about hardware supply chains.</t>
      <t>This document also defines message structures for signed statements and transparent statements, which embed COSE CBOR Object Signing and Encryption (COSE) receipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, target="RFC9942"/>, i.e., signed verifiable data structure proofs).
These message structures are based on the Concise Binary Object Representation (CBOR) Standard <xref target="STD94"/> and corresponding signing is facilitated via the CBOR Object Signing and Encryption COSE Standard <xref target="STD96"/>.
The message structures are defined using the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>.
The signed statements and receipts are are, respectively, based respectively on the COSE_Sign1 specification in Section <xref section="4.2" sectionFormat="of" sectionFormat="bare" target="RFC9052"/> of RFC 9052 <xref target="STD96"/> and on COSE receipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>. target="RFC9942"/>.
The application-domain-agnostic nature of COSE_Sign1 and its extensibility through COSE Header Parameters are prerequisites for implementing the interoperable message layer defined in this document.</t>
      <t>In summary, this specification supports relying parties obtaining proof that signed statements were recorded and checked for their validity at the time they were registered.
How these statements are managed or stored, stored as well as how participating entities discover and notify each other of changes is out-of-scope out of scope of this document.</t>
      <section anchor="sec-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&nbsp;14 BCP 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="sec-software-supply-chain-scope">
      <name>Software Supply Chain Scope</name>
      <t>To illustrate the applicability of the SCITT architecture and its messages, this section details the exemplary context of software supply chain Software Supply Chain (SSC) use cases.
The building blocks provided by the SCITT architecture are not restricted to software supply chain SSC use cases.
Software supply chains
SSCs serve as a useful application guidance and first usage scenario.</t> scenarios.</t>
      <section anchor="sec-generic-ssc-problem-statement">
        <name>Generic SSC Problem Statement</name>
        <t>Supply chain security is a prerequisite to protecting consumers and minimizing economic, public health, and safety threats.
Supply chain security has historically focused on risk management practices to safeguard logistics, meet regulatory requirements, forecast demand, and optimize inventory.
While these elements are foundational to a healthy supply chain, an integrated cyber-security-based perspective of the software supply chains SSCs remains broadly undefined.
Recently, the global community has experienced numerous supply chain attacks targeting weaknesses in software supply chains. SSCs.
	As illustrated in <xref target="lifecycle-threats"/>, a software supply chain an SSC attack may leverage one or more life-cycle stages and directly or indirectly target the component.</t>

<!--[rfced] We had the following questions related to SVG used
     throughout the document:

a) Please review our update to Figure 1 from "3rd-party" to
"third-party".  It looks like making this change may have affected the
spacing of that sentence.  Please regenerate.

b) We note that the text within at least one (maybe more) of the SVG
figures is not able to be selected.  Is it possible to modify the SVG
using your preferred SVG editing software to improve the rendering of
the string in the SVG?

Here is an example of SVG where the strings within the SVG are
selectable and searchable:

https://www.rfc-editor.org/rfc/rfc9576.html#figure-1

-->

        <figure anchor="lifecycle-threats">
          <name>Example SSC Life-Cycle Threats</name>
          <artset>
            <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="752" width="520" viewBox="0 0 520 752" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
                <path d="M 8,80 L 8,144" fill="none" stroke="black"/>
                <path d="M 8,176 L 8,240" fill="none" stroke="black"/>
                <path d="M 8,272 L 8,336" fill="none" stroke="black"/>
                <path d="M 8,368 L 8,432" fill="none" stroke="black"/>
                <path d="M 8,464 L 8,528" fill="none" stroke="black"/>
                <path d="M 8,560 L 8,624" fill="none" stroke="black"/>
                <path d="M 8,656 L 8,720" fill="none" stroke="black"/>
                <path d="M 56,48 L 56,80" fill="none" stroke="black"/>
                <path d="M 56,144 L 56,176" fill="none" stroke="black"/>
                <path d="M 56,240 L 56,272" fill="none" stroke="black"/>
                <path d="M 56,336 L 56,368" fill="none" stroke="black"/>
                <path d="M 56,432 L 56,464" fill="none" stroke="black"/>
                <path d="M 56,528 L 56,560" fill="none" stroke="black"/>
                <path d="M 56,624 L 56,656" fill="none" stroke="black"/>
                <path d="M 104,80 L 104,144" fill="none" stroke="black"/>
                <path d="M 104,176 L 104,240" fill="none" stroke="black"/>
                <path d="M 104,272 L 104,336" fill="none" stroke="black"/>
                <path d="M 104,368 L 104,432" fill="none" stroke="black"/>
                <path d="M 104,464 L 104,528" fill="none" stroke="black"/>
                <path d="M 104,560 L 104,624" fill="none" stroke="black"/>
                <path d="M 104,656 L 104,720" fill="none" stroke="black"/>
                <path d="M 8,80 L 104,80" fill="none" stroke="black"/>
                <path d="M 8,144 L 104,144" fill="none" stroke="black"/>
                <path d="M 8,176 L 104,176" fill="none" stroke="black"/>
                <path d="M 8,240 L 104,240" fill="none" stroke="black"/>
                <path d="M 8,272 L 104,272" fill="none" stroke="black"/>
                <path d="M 8,336 L 104,336" fill="none" stroke="black"/>
                <path d="M 8,368 L 104,368" fill="none" stroke="black"/>
                <path d="M 8,432 L 104,432" fill="none" stroke="black"/>
                <path d="M 8,464 L 104,464" fill="none" stroke="black"/>
                <path d="M 8,528 L 104,528" fill="none" stroke="black"/>
                <path d="M 8,560 L 104,560" fill="none" stroke="black"/>
                <path d="M 8,624 L 104,624" fill="none" stroke="black"/>
                <path d="M 8,656 L 104,656" fill="none" stroke="black"/>
                <path d="M 8,720 L 104,720" fill="none" stroke="black"/>
                <g class="text">
                  <text x="60" y="36">Dependencies</text>
                  <text x="208" y="36">Malicious</text>
                  <text x="288" y="36">3rd-party</text> y="36">third-party</text>
                  <text x="360" y="36">package</text>
                  <text x="404" y="36">or</text>
                  <text x="448" y="36">version</text>
                  <text x="52" y="116">Code</text>
                  <text x="212" y="116">Compromise</text>
                  <text x="284" y="116">source</text>
                  <text x="344" y="116">control</text>
                  <text x="208" y="196">Malicious</text>
                  <text x="284" y="196">plug-ins</text>
                  <text x="52" y="212">Commit</text>
                  <text x="208" y="212">Malicious</text>
                  <text x="276" y="212">commit</text>
                  <text x="196" y="292">Modify</text>
                  <text x="248" y="292">build</text>
                  <text x="296" y="292">tasks</text>
                  <text x="332" y="292">or</text>
                  <text x="360" y="292">the</text>
                  <text x="400" y="292">build</text>
                  <text x="472" y="292">environment</text>
                  <text x="56" y="308">Build</text>
                  <text x="196" y="308">Poison</text>
                  <text x="240" y="308">the</text>
                  <text x="280" y="308">build</text>
                  <text x="364" y="308">agent/compiler</text>
                  <text x="196" y="324">Tamper</text>
                  <text x="244" y="324">with</text>
                  <text x="288" y="324">build</text>
                  <text x="336" y="324">cache</text>
                  <text x="212" y="388">Compromise</text>
                  <text x="276" y="388">test</text>
                  <text x="320" y="388">tools</text>
                  <text x="60" y="404">Test</text>
                  <text x="224" y="404">Falsification</text>
                  <text x="292" y="404">of</text>
                  <text x="324" y="404">test</text>
                  <text x="376" y="404">results</text>
                  <text x="184" y="484">Use</text>
                  <text x="216" y="484">bad</text>
                  <text x="268" y="484">packages</text>
                  <text x="56" y="500">Package</text>
                  <text x="212" y="500">Compromise</text>
                  <text x="288" y="500">package</text>
                  <text x="364" y="500">repository</text>
                  <text x="196" y="580">Modify</text>
                  <text x="256" y="580">release</text>
                  <text x="312" y="580">tasks</text>
                  <text x="56" y="596">Release</text>
                  <text x="196" y="596">Modify</text>
                  <text x="248" y="596">build</text>
                  <text x="292" y="596">drop</text>
                  <text x="336" y="596">prior</text>
                  <text x="372" y="596">to</text>
                  <text x="416" y="596">release</text>
                  <text x="52" y="692">Deploy</text>
                  <text x="196" y="692">Tamper</text>
                  <text x="244" y="692">with</text>
                  <text x="308" y="692">versioning</text>
                  <text x="368" y="692">and</text>
                  <text x="412" y="692">update</text>
                  <text x="472" y="692">process</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art"><![CDATA[
      Dependencies        Malicious 3rd-party third-party package or version
           |
           |
     +-----+-----+
     |           |
     |   Code    |        Compromise source control
     |           |
     +-----+-----+
           |
     +-----+-----+
     |           |        Malicious plug-ins
     |  Commit   |        Malicious commit
     |           |
     +-----+-----+
           |
     +-----+-----+
     |           |        Modify build tasks or the build environment
     |   Build   |        Poison the build agent/compiler
     |           |        Tamper with build cache
     +-----+-----+
           |
     +-----+-----+
     |           |        Compromise test tools
     |    Test   |        Falsification of test results
     |           |
     +-----+-----+
           |
     +-----+-----+
     |           |        Use bad packages
     |  Package  |        Compromise package repository
     |           |
     +-----+-----+
           |
     +-----+-----+
     |           |        Modify release tasks
     |  Release  |        Modify build drop prior to release
     |           |
     +-----+-----+
           |
     +-----+-----+
     |           |
     |  Deploy   |        Tamper with versioning and update process
     |           |
     +-----------+
]]></artwork>
          </artset>
        </figure>
        <t>DevSecOps, as defined in <xref target="NIST.SP.800-204C"/>, often depends on third-party and open-source software.
These dependencies can be quite complex throughout the supply chain, so checking provenance and traceability throughout their lifecycle life cycle is difficult.
There is a need for manageable auditability and accountability of digital products.
Typically, the range of types of statements about digital products (and their dependencies) is vast, heterogeneous, and can differ between community policy requirements.
Taking the type and structure of all statements about digital products into account might not be possible.
Examples of statements may include commit signatures, build environment and parameters, software bill Software Bill of materials, Materials (SBOM), static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs.
In consequence,
Consequently, instead of trying to understand and describe the detailed syntax and semantics of every type of statement about digital products, the SCITT architecture focuses on ensuring statement authenticity, ensuring visibility/transparency, and intends to provide scalable accessibility.
Threats and practical issues can also arise from unintended side-effects side effects of using security techniques outside their proper bounds.
For instance instance, digital signatures may fail to verify past their expiry date even though the signed item itself remains completely valid.
Or a signature may verify even though the information it is securing is now found unreliable but fine-grained revocation is too hard.</t>
        <t>Lastly, where data exchange underpins serious business decision-making, it is important to hold the producers of those data to a higher standard of auditability.
The SCITT architecture provides mechanisms and structures for ensuring that the makers of authoritative statements can be held accountable and not hide or shred the evidence when it becomes inconvenient later.</t>
        <t>The following use cases illustrate the scope of SCITT and elaborate on the generic problem statement above.</t>
      </section>
      <section anchor="sec-eclectic-ssc-use-cases">
        <name>Eclectic SSC Use Cases</name>
        <t>The three following use cases are a specialization derived from the generic problem statement above.</t>
        <section anchor="sec-security-analysis-of-a-software-product">
          <name>Security Analysis of a Software Product</name>
          <t>A released software product is often accompanied by a set of complementary statements about its security properties.
This gives enough confidence to both producers and consumers that the released software meets the expected security standards and is suitable to use.</t>
          <t>Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product.
The intention is to identify any security weaknesses or vulnerabilities in the package.</t>
          <t>Initially, a particular analysis can identify a simple weakness in a software component.
Over a period of time, a statement from a third-party third party illustrates that the weakness is exposed in a way that represents an exploitable vulnerability.
The producer of the software product provides a statement that confirms the linking of a software component vulnerability with the software product by issuing a product vulnerability disclosure report and also issues issuing an advisory statement on how to mitigate the vulnerability.
At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that inhibits exploitation.
Later, a second update of the software product includes a security patch to the affected software component from the software producer.
Finally, a third update includes a new release (updated version) of the formerly insecure software component.
For this release, both the software product and the affected software component are deemed secure by the producer and consumers.</t>
          <t>A consumer of a released software wants to:</t>
          <ul spacing="normal">
            <li>know where to get these security statements from producers and third-parties third parties related to the software product in a timely and unambiguous fashion</li>
            <li>attribute them to an authoritative issuer</li>
            <li>associate the statements in a meaningful manner via a set of well-known semantic relationships</li>
            <li>consistently, efficiently, and homogeneously check their authenticity</li>
          </ul>
          <t>SCITT provides a standardized way to:</t>
          <ul spacing="normal">
            <li>know the various sources of statements</li>
            <li>express the provenance and historicity of statements</li>
            <li>relate and link various heterogeneous statements in a simple fashion</li>
            <li>check that the statement comes from a source with authority to issue that statement</li>
            <li>confirm that sources provide a complete history of statements related to a given component</li>
          </ul>
        </section>
        <section anchor="sec-promotion-of-a-software-component-by-multiple-entities">
          <name>Promotion of a Software Component by Multiple Entities</name>
          <t>A software component (e.g., a library or software product), open-source or commercial, is often initially released by a single trusted producer, producer who can choose to attach a statement of authenticity to it.
As that component becomes used in a growing range of other products, providers other than the original trusted producer often re-distribute, re-distribute or release their own version of that component.</t>
          <t>Some providers include it as part of their release product/package product or package bundle and provide the package with proof of authenticity using their issuer authority.
Some packages include the original statement of authenticity, and some do not.
Over time, some providers no longer offer the exact same software component source code but pre-compiled software component binaries.
Some sources do not provide the exact same software component, component but include patches and fixes produced by third-parties, third parties as these emerge faster than solutions from the original producer.
Due to complex distribution and promotion life-cycle scenarios, the original software component takes myriad forms.</t>
          <t>A consumer of a released software wants to:</t>
          <ul spacing="normal">
            <li>understand if a particular provider is a trusted originating producer or an alternative party</li>
            <li>know if and how the source, or resulting binary, of a promoted software component differs from the original software component</li>
            <li>check the provenance and history of a software component's source back to its origin</li>
            <li>assess whether to trust a component or product based on a downloaded package location and source supplier</li>
          </ul>
          <t>SCITT provides a standardized way to:</t>
          <ul spacing="normal">
            <li>reliably discern if a provider is the original, trusted producer or is a trustworthy alternative provider or is an illegitimate provider</li>
            <li>track the provenance path from an original producer to a particular provider</li>
            <li>check the trustworthiness of a provider</li>
            <li>check the integrity of modifications or transformations applied by a provider</li>
          </ul>
        </section>
        <section anchor="sec-software-integrator-assembling-a-software-product-for-a-vehicle">
          <name>Software Integrator Assembling a Software Product for a Vehicle</name>
          <t>Software Integration is a complex activity.
This typically  Typically, it
involves getting various software components from multiple suppliers, suppliers and producing an integrated package deployed as part of device assembly.
For example, car manufacturers source integrated software for their vehicles from third parties that integrate software components from various sources.
Integration complexity creates a higher risk of security vulnerabilities to the delivered software.</t>
          <t>Consumers of integrated software want:</t>
          <ul spacing="normal">
            <li>a list of all components present in a software product</li>
            <li>the ability to identify and retrieve all components from a secure and tamper-proof location</li>
            <li>verifiable proofs on build process and build environment with all supplier tiers to ensure end to end end-to-end build quality and security</li>
          </ul>
          <t>SCITT provides a standardized way to:</t>
          <ul spacing="normal">
            <li>provide a tiered and transparent framework that allows for verification of integrity and authenticity of the integrated software at both component and product level before installation</li>
            <li>provide valid annotations on build integrity to ensure conformance</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The terms defined in this section have special meaning in the context of Supply Chain Integrity, Transparency, and Trust, SCITT and are used throughout this document.</t>
      <t>This document has been developed in coordination with the COSE, OAUTH OAUTH, and RATS WG working groups (WGs) and uses terminology common to these working groups WGs as much often as possible.</t>
      <t>When

      <t>The terms "header", "payload", and "to-be-signed bytes" are defined in <xref target="STD96"/>.</t>
      <t>The term "claim" is defined in <xref target="RFC8392"/>.</t>

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

a) We have moved the following paragraph to appear directly before the
list of terms defined in this document as the terms borrowed from
other documents (e.g., "header") are not capitalized in the text.  We
have also changed "corresponding" to "following" for clarity.  Please
review and let us know any objections.

Original:
   When used in text, the corresponding terms are capitalized.  To
   ensure readability, only a core set of terms is included in this section.</t>
      <t>The
   section.

Current:
   When used in text, the following terms "header", "payload", are capitalized.  To
   ensure readability, only a core set of terms is included in this
   section.

b) Related to the paragraph above in part (a): Note that several of
the terms in the Terminology list are not consistently capped
throughout the rest of the document.

For example, should "attestation" be capped within the Attestation
definition (occurs two times lowercase)?  Here is a list of terms that
appear in lowercase in the body of the document:

append-only
artifact
attestation
equivocation
issuer (see also single-issuer)
non-equivocation
receipt (see related cluster-wide query as this affects both documents)
registration
relying party (or parties)
signed statement
statement
transparent statement
transparency service (or services)
verifiable data structure (see related question about abbreviation use)

We suggest the following possible ways forward:

-Cap the terms on their introduction (i.e., <dt>) in the list in the
Terminology section only: lowercase when used in prose.  Remove the
sentence about these terms being capped from the Terminology section
(from (a) above).

-Cap the terms consistently throughout the document.  Leave the
sentence from (a) as is.

-Leave the variation between capitalization and "to-be-signed bytes" lowercase if there is
meaning involved (e.g., when capped it has this definition but when
lowercase it does not) and update the sentence in (a) to explain the
meaning behind the variation.

NOTE: Generally, we believe over-capitalizing nouns can get
distracting to readers, but we understand the desire to match past use
or add meaning, etc.  Our main goal is to ensure the reader
understands your intent.

c) The only term that seems to be out of alphabetical order in this is
"Attestation".  May we move this term to fit in the A's?

d) We note that [RFC8392] uses "CWT Claims Set" rather than
     "CWT Claim Set".  Please review and let us know what/if any
     updates are necessary.

Current:
   In SCITT Statements and Receipts, the iss Claim is a member of the
   COSE header parameter 15: CWT Claims defined in <xref target="STD96"/>.</t>
      <t>The [RFC9597], which
   embeds a CWT Claim Set [RFC8392] within the protected header of a COSE
   Envelope.

e) Section 4 is titled "Definition of Transparency".  Does this seem
like something that should be grouped with "Terminology" (i.e., should
it be Section 3.1)?

f) Section 5.1.1.1: Should this pointer to the definition of "trust
anchor" be replaced by an entry in the Terminology section instead?
We note that the term "claim" was already used at the end of Section 5.1.1.

Original:
   Transparency Services MUST maintain a list of trust anchors (see
   definition of trust anchor in [RFC4949]) in order to check the
   signatures of Signed Statements, either separately, or inside
   Registration Policies.

g) Section 9.4: Should this pointer to the definition of cryptoperiod
be replaced by an entry in the Terminology section instead?

Original:

   *  rotate their keys at a cryptoperiod (defined in [RFC4949])
   appropriate for the key algorithm and domain-specific regulations

h) Please see our cluster-wide questions related to discrepancies
between the definitions that appear in both documents in this cluster.

-->

  <t>When used in text, the following terms are capitalized.
To ensure readability, only a core set of terms is defined included in <xref target="RFC8392"/>.</t> this section.</t>

      <dl anchor="mybody">
        <dt>Append-only Log:</dt>
        <dd>
          <t>a Statement Sequence comprising the entire registration history of the Transparency Service.
To make the Append-only property verifiable and transparent, the Transparency Service defines how Signed Statements are made available to Auditors.</t>
        </dd>
        <dt>Artifact:</dt>
        <dd>
          <t>a physical or non-physical item that is moving along a supply chain.</t>
        </dd>
        <dt>Auditor:</dt>
        <dd>
          <t>an entity that checks the correctness and consistency of all Transparent Statements, or the transparent Statement Sequence, issued by a Transparency Service.
An Auditor is an example of a specialized Relying Party.</t>
        </dd>
        <dt>Client:</dt>
        <dd>
          <t>an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization.</t>
        </dd>
        <dt>Envelope:</dt>
        <dd>
          <t>metadata, created by the Issuer to produce a Signed Statement.
The Envelope contains the identity of the Issuer and information about the Artifact, enabling Transparency Service Registration Policies to validate the Signed Statement.
A Signed Statement is a COSE Envelope wrapped around a Statement, binding the metadata in the Envelope to the Statement.
In COSE, an Envelope consists of a protected header (included in the Issuer's signature) and an unprotected header (not included in the Issuer's signature).</t>
        </dd>
        <dt>Equivocation:</dt>
        <dd>
          <t>a state where a Transparency Service provides inconsistent proofs to Relying Parties, containing conflicting claims about the Signed Statement bound at a given position in the Verifiable Data Structure.</t>
        </dd>
        <dt>Issuer:</dt>
        <dd>

          <t>an identifier representing an organization, device, user, or entity securing Statements about supply chain Artifacts.
An Issuer may be the owner or author of Artifacts, Artifacts or an independent third party such as an Auditor, reviewer reviewer, or an endorser.
In SCITT Statements and Receipts, the <tt>iss</tt> Claim is a member of the COSE header parameter <tt>15: CWT Claims</tt> defined in <xref target="RFC9597"/>, which embeds a CWT CBOR Web Token (CWT) Claim Set <xref target="RFC8392"/> within the protected header of a COSE Envelope.
This document uses the terms "Issuer", "Issuer" and "Subject" as described in <xref target="RFC8392"/>, however target="RFC8392"/>; however, the usage is consistent with the broader interpretation of these terms in both JOSE JSON Object Signing and Encryption (JOSE) and COSE, and the guidance in <xref target="RFC8725"/> generally applies the COSE equivalent terms with consistent semantics.</t>
        </dd>
        <dt>Non-equivocation:</dt>
        <dd>
          <t>a state where all proofs provided by the Transparency Service to Relying Parties are produced from a single Verifiable Data Structure describing a unique sequence of Signed Statements and are therefore consistent <xref target="EQUIVOCATION"/>.
Over time, an Issuer may register new Signed Statements about an Artifact in a Transparency Service with new information.
However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.</t>
        </dd>
        <dt>Receipt:</dt>
        <dd>
          <t>a cryptographic proof that a Signed Statement is included in the Verifiable Data Structure.
See <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> target="RFC9942"/> for implementations.
Receipts are signed proofs of verifiable data-structure properties.
Receipt Profiles implemented by a Transparency Service <bcp14>MUST</bcp14> support inclusion proofs and <bcp14>MAY</bcp14> support other proof types, such as consistency proofs.</t>
        </dd>
        <dt>Registration:</dt>
        <dd>
          <t>the process of submitting a Signed Statement to a Transparency Service, applying the Transparency Service's Registration Policy, adding to the Verifiable Data Structure, and producing a Receipt.</t>
        </dd>
        <dt>Registration Policy:</dt>
        <dd>
          <t>the pre-condition precondition enforced by the Transparency Service before registering a Signed Statement, based on information in the non-opaque header and metadata contained in its COSE Envelope.</t>
        </dd>
        <dt>Relying Party:</dt>
        <dd>
          <t>Relying Parties consumes consume Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, Artifacts or later to audit an Artifact's provenance on the supply chain.</t>
        </dd>
        <dt>Signed Statement:</dt>
        <dd>
          <t>an identifiable and non-repudiable Statement about an Artifact signed by an Issuer.
In SCITT, Signed Statements are encoded as COSE signed objects; the <tt>payload</tt> of the COSE structure contains the issued Statement.</t>
        </dd>
        <dt>Attestation:</dt>
        <dd>
          <t><xref target="NIST.SP.1800-19"/> defines "attestation" as "The as:</t>
	  <blockquote><t>The process of providing a digital signature for a set of measurements securely stored in hardware, and then having the requester validate the signature and the set of measurements." measurements.</t></blockquote>

<!--[rfced] Can you let us know how "NIST guidance "Software Supply
     Chain Security Guidance EO 14028" is different from
     [NIST_E014028]?  This currently reads as if the reference is
     using itself.

Original:

 NIST guidance "Software Supply Chain Security Guidance EO 14028" uses
 the definition from <xref target="NIST_EO14028"/>, [NIST_EO14028], which states that an
 "attestation" is "The issue of a statement, based on a decision, that
 fulfillment of specified requirements has been demonstrated.".
It

The related reference entry:

   [NIST_EO14028]
              NIST, "Software Supply Chain Security Guidance Under
              Executive Order (EO) 14028 Section 4e", 4 February 2022,
              <https://www.nist.gov/system/files/documents/2022/02/04/
              software-supply-chain-security-guidance-under-EO-14028-
              section-4e.pdf>.

Perhaps:
[NIST_EO14028] states that an "attestation" is:

  The issue of a statement, based on a decision, that fulfillment of
  specified requirements has been demonstrated.

-->

	  <t>NIST guidance "Software Supply Chain Security Guidance EO 14028" uses the definition from <xref target="NIST_EO14028"/>, which states that an "attestation" is:</t><blockquote>
	  <t>The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.</t></blockquote>
<t>It is often useful for the intended audience to qualify the term "attestation" in their specific context to avoid confusion and ambiguity.</t>
        </dd>
        <dt>Statement:</dt>
        <dd>
          <t>any serializable information about an Artifact.
To help interpretation of interpret Statements, they must be tagged with a relevant media type (as specified in <xref target="RFC6838"/>).
A Statement may represent a Software Bill Of Materials (SBOM) an SBOM that lists the ingredients of a software Artifact, contains an endorsement or attestation about an Artifact, indicate indicates the End of Life (EOL), redirection redirects to a newer version, or contains any content an Issuer wishes to publish about an Artifact.
Additional Statements about an Artifact are correlated by the Subject Claim as defined in the IANA CWT registry <xref target="IANA.cwt"/> registry and used as a protected header parameter as defined in <xref target="RFC9597"/>.
The Statement is considered opaque to Transparency Service, Service and <bcp14>MAY</bcp14> be encrypted.</t>
        </dd>
        <dt>Statement Sequence:</dt>
        <dd>
          <t>a sequence of Signed Statements captured by a Verifiable Data Structure.
See Verifiable Data Structure.</t>
        </dd>
        <dt>Subject:</dt>
        <dd>
          <t>an identifier, defined by the Issuer, which that represents the organization, device, user, entity, or Artifact about which Statements (and Receipts) are made and by which a logical collection of Statements can be grouped.
It is possible that there are multiple Statements about the same Artifact.
In these cases, distinct Issuers (<tt>iss</tt>) might agree to use the <tt>sub</tt> CWT Claim, defined in <xref target="RFC8392"/>, to create a coherent sequence of Signed Statements about the same Artifact Artifact, and Relying Parties can leverage <tt>sub</tt> to ensure completeness and Non-equivocation across Statements by identifying all Transparent Statements associated to a specific Subject.</t>
        </dd>
        <dt>Transparency Service:</dt>
        <dd>
          <t>an entity that maintains and extends the Verifiable Data Structure and endorses its state.
The identity of a Transparency Service is captured by a public key that must be known by Relying Parties in order to validate Receipts.</t>
        </dd>
        <dt>Transparent Statement:</dt>
        <dd>
          <t>a Signed Statement that is augmented with a Receipt created via Registration in a Transparency Service.
The Receipt is stored in the unprotected header of COSE Envelope of the Signed Statement.
A Transparent Statement remains a valid Signed Statement and may be registered again in a different Transparency Service.</t>
        </dd>
        <dt>Verifiable Data Structure:</dt>
        <dd>
          <t>a data structure which that supports one or more proof types, such as "inclusion proofs" or "consistency proofs", for Signed Statements as they are Registered to a Transparency Service.
SCITT supports multiple Verifiable Data Structures and Receipt formats as defined in <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, target="RFC9942"/>, accommodating different Transparency Service implementations.</t>
        </dd>
      </dl>
    </section>
    <section anchor="sec-definition-of-transparency">
      <name>Definition of Transparency</name>
      <t>In this document, the definition of transparency is intended to build over abstract notions of Append-only Logs and Receipts.
Existing transparency systems such as Certificate Transparency CT <xref target="RFC9162"/> are instances of this definition.
SCITT supports multiple Verifiable Data Structures, as defined in <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t> target="RFC9942"/>.</t>
      <t>A Signed Statement is an identifiable and non-repudiable Statement made by an Issuer.
The Issuer selects additional metadata and attaches a proof of endorsement (in most cases, a signature) using the identity key of the Issuer that binds the Statement and its metadata.
Signed Statements can be made transparent by attaching a proof of Registration by a Transparency Service, Service in the form of a Receipt.
Receipts demonstrate inclusion of Signed Statements in the Verifiable Data Structure of a Transparency Service.
By extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements Statement is expected for a given Artifact.</t>
      <t>Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.
Any Artifact that may be verified, verified is subject to scrutiny and auditing by other parties.
The Transparency Service provides a history of Statements, which may be made by multiple Issuers, enabling Relying Parties to make informed decisions.</t>
      <t>Transparency is implemented by providing a consistent, append-only, cryptographically verifiable, publicly available record of entries.
Implementations of Transparency Services may protect their registered sequence of Signed Statements and Verifiable Data Structure using a combination of trusted hardware, consensus protocols, and cryptographic evidence.
A Receipt is a signature over one or more Verifiable Data Structure Proofs that a Signed Statement is registered in the Verifiable Data Structure.
It is universally verifiable without online access to the TS.
Requesting a Receipt can result in the production of a new Receipt for the same Signed Statement.
A Receipt's verification key, signing algorithm, validity period, header parameters or other claims <bcp14>MAY</bcp14> change each time a Receipt is produced.</t>
      <t>Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent Statements registered by each Issuer.</t>
      <t>Reputable
      <t>Thus, reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.
Similarly, reputable Transparency Services are incentivized to secure their Verifiable Data Structure, as any inconsistency can easily be pinpointed by any Auditor with read access to the Transparency Service.</t>
      <t>The building blocks specified in this document enable the unequivocal and auditable production of statements about software supply chain artifacts. The extensible design of the SCITT architecture potentially allows future usage with other supply chains in different domains, for example example, advanced manufacturing or food supply.</t>
      <t>SCITT is a generalization of Certificate Transparency (CT) CT <xref target="RFC9162"/>, which can be interpreted as a transparency architecture for the supply chain of X.509 certificates.
Considering CT in terms of SCITT:</t>
      <ul spacing="normal">
        <li>CAs
        <li>Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER encoded DER-encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements)</li>
        <li>CAs submit the certificates to one or more CT logs (Transparency Services)</li>
        <li>CT logs produce Signed Certificate Timestamps (Transparent Statements)</li>
        <li>Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties</li>
        <li>The Verifiable Data Structure can be checked by Auditors</li>
      </ul>
    </section>
    <section anchor="sec-architecture-overview">
      <name>Architecture Overview</name>
      <t>The SCITT architecture enables Transparency Services in a given application domain to implement a collective baseline, baseline by providing a set of common formats and protocols for issuing and registering Signed Statements and auditing Transparent Statements.</t>
      <t>In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs.
The remaining details of the Receipt's contents are specified in <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t> target="RFC9942"/>.</t>
      <t><xref target="fig-concept-relationship"/> illustrates the roles and processes that comprise a Transparency Service independent of any one use case:</t>
      <ul spacing="normal">
        <li>Issuers that use their credentials to create Signed Statements about Artifacts</li> Artifacts.</li>
        <li>Transparency Services that evaluate Signed Statements against Registration Policies, Policies producing Receipts upon successful Registration.
The returned Receipt may be combined with the Signed Statement to create a Transparent Statement.</li>
        <li>
          <t>Relying Parties that:
          </t>
          <ul spacing="normal">
            <li>collect Receipts of Signed Statements for subsequent registration of Transparent Statements;</li>
            <li>retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. (e.g., verification);</li>
            <li>or replay all the Transparent Statements to check for the consistency and correctness of the Transparency Service's Verifiable Data Structure (e.g. auditing)</li> (e.g., auditing).</li>
          </ul>
        </li>
      </ul>
      <t>In addition, <xref target="fig-concept-relationship"/> illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement <bcp14>MAY</bcp14> be registered with one or more Transparency Service.
Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services.</t>
      <t>The arrows indicate the flow of information.</t>
      <figure anchor="fig-concept-relationship">
        <name>Relationship of Concepts in SCITT</name>
        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="512" width="536" viewBox="0 0 536 512" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,224 L 8,240" fill="none" stroke="black"/>
              <path d="M 32,448 L 32,480" fill="none" stroke="black"/>
              <path d="M 40,352 L 40,368" fill="none" stroke="black"/>
              <path d="M 56,64 L 56,88" fill="none" stroke="black"/>
              <path d="M 56,128 L 56,200" fill="none" stroke="black"/>
              <path d="M 72,256 L 72,328" fill="none" stroke="black"/>
              <path d="M 88,176 L 88,200" fill="none" stroke="black"/>
              <path d="M 96,384 L 96,408" fill="none" stroke="black"/>
              <path d="M 120,288 L 120,328" fill="none" stroke="black"/>
              <path d="M 128,224 L 128,240" fill="none" stroke="black"/>
              <path d="M 152,352 L 152,368" fill="none" stroke="black"/>
              <path d="M 160,448 L 160,480" fill="none" stroke="black"/>
              <path d="M 208,272 L 208,288" fill="none" stroke="black"/>
              <path d="M 216,464 L 216,496" fill="none" stroke="black"/>
              <path d="M 224,304 L 224,320" fill="none" stroke="black"/>
              <path d="M 224,384 L 224,408" fill="none" stroke="black"/>
              <path d="M 288,32 L 288,64" fill="none" stroke="black"/>
              <path d="M 288,128 L 288,144" fill="none" stroke="black"/>
              <path d="M 288,272 L 288,288" fill="none" stroke="black"/>
              <path d="M 304,64 L 304,88" fill="none" stroke="black"/>
              <path d="M 304,304 L 304,320" fill="none" stroke="black"/>
              <path d="M 344,208 L 344,272" fill="none" stroke="black"/>
              <path d="M 344,384 L 344,408" fill="none" stroke="black"/>
              <path d="M 344,464 L 344,496" fill="none" stroke="black"/>
              <path d="M 368,272 L 368,336" fill="none" stroke="black"/>
              <path d="M 384,176 L 384,200" fill="none" stroke="black"/>
              <path d="M 384,448 L 384,480" fill="none" stroke="black"/>
              <path d="M 392,64 L 392,88" fill="none" stroke="black"/>
              <path d="M 408,32 L 408,64" fill="none" stroke="black"/>
              <path d="M 432,128 L 432,144" fill="none" stroke="black"/>
              <path d="M 440,336 L 440,360" fill="none" stroke="black"/>
              <path d="M 440,376 L 440,408" fill="none" stroke="black"/>
              <path d="M 472,208 L 472,272" fill="none" stroke="black"/>
              <path d="M 488,256 L 488,336" fill="none" stroke="black"/>
              <path d="M 504,160 L 504,352" fill="none" stroke="black"/>
              <path d="M 512,448 L 512,480" fill="none" stroke="black"/>
              <path d="M 24,32 L 96,32" fill="none" stroke="black"/>
              <path d="M 288,32 L 408,32" fill="none" stroke="black"/>
              <path d="M 24,64 L 96,64" fill="none" stroke="black"/>
              <path d="M 288,64 L 408,64" fill="none" stroke="black"/>
              <path d="M 24,96 L 88,96" fill="none" stroke="black"/>
              <path d="M 256,96 L 344,96" fill="none" stroke="black"/>
              <path d="M 384,96 L 472,96" fill="none" stroke="black"/>
              <path d="M 24,128 L 88,128" fill="none" stroke="black"/>
              <path d="M 240,128 L 328,128" fill="none" stroke="black"/>
              <path d="M 368,128 L 456,128" fill="none" stroke="black"/>
              <path d="M 432,144 L 488,144" fill="none" stroke="black"/>
              <path d="M 104,160 L 272,160" fill="none" stroke="black"/>
              <path d="M 304,160 L 368,160" fill="none" stroke="black"/>
              <path d="M 24,208 L 112,208" fill="none" stroke="black"/>
              <path d="M 344,208 L 472,208" fill="none" stroke="black"/>
              <path d="M 128,224 L 336,224" fill="none" stroke="black"/>
              <path d="M 24,256 L 112,256" fill="none" stroke="black"/>
              <path d="M 224,256 L 272,256" fill="none" stroke="black"/>
              <path d="M 472,256 L 488,256" fill="none" stroke="black"/>
              <path d="M 136,272 L 208,272" fill="none" stroke="black"/>
              <path d="M 296,272 L 312,272" fill="none" stroke="black"/>
              <path d="M 344,272 L 472,272" fill="none" stroke="black"/>
              <path d="M 136,288 L 168,288" fill="none" stroke="black"/>
              <path d="M 224,304 L 272,304" fill="none" stroke="black"/>
              <path d="M 200,320 L 224,320" fill="none" stroke="black"/>
              <path d="M 312,320 L 368,320" fill="none" stroke="black"/>
              <path d="M 56,336 L 136,336" fill="none" stroke="black"/>
              <path d="M 240,336 L 288,336" fill="none" stroke="black"/>
              <path d="M 368,336 L 488,336" fill="none" stroke="black"/>
              <path d="M 152,368 L 208,368" fill="none" stroke="black"/>
              <path d="M 360,368 L 488,368" fill="none" stroke="black"/>
              <path d="M 56,384 L 136,384" fill="none" stroke="black"/>
              <path d="M 24,416 L 176,416" fill="none" stroke="black"/>
              <path d="M 200,416 L 368,416" fill="none" stroke="black"/>
              <path d="M 384,416 L 528,416" fill="none" stroke="black"/>
              <path d="M 8,448 L 160,448" fill="none" stroke="black"/>
              <path d="M 368,448 L 512,448" fill="none" stroke="black"/>
              <path d="M 176,464 L 344,464" fill="none" stroke="black"/>
              <path d="M 32,480 L 160,480" fill="none" stroke="black"/>
              <path d="M 384,480 L 512,480" fill="none" stroke="black"/>
              <path d="M 216,496 L 344,496" fill="none" stroke="black"/>
              <path d="M 8,448 L 24,416" fill="none" stroke="black"/>
              <path d="M 240,128 L 256,96" fill="none" stroke="black"/>
              <path d="M 160,448 L 176,416" fill="none" stroke="black"/>
              <path d="M 328,128 L 344,96" fill="none" stroke="black"/>
              <path d="M 176,464 L 200,416" fill="none" stroke="black"/>
              <path d="M 368,128 L 384,96" fill="none" stroke="black"/>
              <path d="M 456,128 L 472,96" fill="none" stroke="black"/>
              <path d="M 344,464 L 368,416" fill="none" stroke="black"/>
              <path d="M 368,448 L 384,416" fill="none" stroke="black"/>
              <path d="M 512,448 L 528,416" fill="none" stroke="black"/>
              <path d="M 24,32 C 15.16936,32 8,39.16936 8,48" fill="none" stroke="black"/>
              <path d="M 96,32 C 104.83064,32 112,39.16936 112,48" fill="none" stroke="black"/>
              <path d="M 24,64 C 15.16936,64 8,56.83064 8,48" fill="none" stroke="black"/>
              <path d="M 96,64 C 104.83064,64 112,56.83064 112,48" fill="none" stroke="black"/>
              <path d="M 24,96 C 15.16936,96 8,103.16936 8,112" fill="none" stroke="black"/>
              <path d="M 88,96 C 96.83064,96 104,103.16936 104,112" fill="none" stroke="black"/>
              <path d="M 24,128 C 15.16936,128 8,120.83064 8,112" fill="none" stroke="black"/>
              <path d="M 88,128 C 96.83064,128 104,120.83064 104,112" fill="none" stroke="black"/>
              <path d="M 488,144 C 496.83064,144 504,151.16936 504,160" fill="none" stroke="black"/>
              <path d="M 104,160 C 95.16936,160 88,167.16936 88,176" fill="none" stroke="black"/>
              <path d="M 272,160 C 280.83064,160 288,152.83064 288,144" fill="none" stroke="black"/>
              <path d="M 304,160 C 295.16936,160 288,152.83064 288,144" fill="none" stroke="black"/>
              <path d="M 368,160 C 376.83064,160 384,167.16936 384,176" fill="none" stroke="black"/>
              <path d="M 24,208 C 15.16936,208 8,215.16936 8,224" fill="none" stroke="black"/>
              <path d="M 112,208 C 120.83064,208 128,215.16936 128,224" fill="none" stroke="black"/>
              <path d="M 344,240 C 335.16936,240 328,247.16936 328,256" fill="none" stroke="black"/>
              <path d="M 24,256 C 15.16936,256 8,248.83064 8,240" fill="none" stroke="black"/>
              <path d="M 112,256 C 120.83064,256 128,248.83064 128,240" fill="none" stroke="black"/>
              <path d="M 224,256 C 215.16936,256 208,263.16936 208,272" fill="none" stroke="black"/>
              <path d="M 272,256 C 280.83064,256 288,263.16936 288,272" fill="none" stroke="black"/>
              <path d="M 136,272 C 127.16936,272 120,279.16936 120,288" fill="none" stroke="black"/>
              <path d="M 312,272 C 320.83064,272 328,264.83064 328,256" fill="none" stroke="black"/>
              <path d="M 136,288 C 127.16936,288 120,295.16936 120,304" fill="none" stroke="black"/>
              <path d="M 168,288 C 176.83064,288 184,295.16936 184,304" fill="none" stroke="black"/>
              <path d="M 288,288 C 296.83064,288 304,295.16936 304,304" fill="none" stroke="black"/>
              <path d="M 224,304 C 215.16936,304 208,296.83064 208,288" fill="none" stroke="black"/>
              <path d="M 272,304 C 280.83064,304 288,296.83064 288,288" fill="none" stroke="black"/>
              <path d="M 200,320 C 191.16936,320 184,312.83064 184,304" fill="none" stroke="black"/>
              <path d="M 56,336 C 47.16936,336 40,343.16936 40,352" fill="none" stroke="black"/>
              <path d="M 136,336 C 144.83064,336 152,343.16936 152,352" fill="none" stroke="black"/>
              <path d="M 240,336 C 231.16936,336 224,328.83064 224,320" fill="none" stroke="black"/>
              <path d="M 288,336 C 296.83064,336 304,328.83064 304,320" fill="none" stroke="black"/>
              <path d="M 208,368 C 216.83064,368 224,375.16936 224,384" fill="none" stroke="black"/>
              <path d="M 360,368 C 351.16936,368 344,375.16936 344,384" fill="none" stroke="black"/>
              <path d="M 488,368 C 496.83064,368 504,360.83064 504,352" fill="none" stroke="black"/>
              <path d="M 56,384 C 47.16936,384 40,376.83064 40,368" fill="none" stroke="black"/>
              <path d="M 136,384 C 144.83064,384 152,376.83064 152,368" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="448,408 436,402.4 436,413.6 " fill="black" transform="rotate(90,440,408)"/>
              <path class="jump" d="M 440,376 C 446,376 446,360 440,360" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="400,88 388,82.4 388,93.6 " fill="black" transform="rotate(90,392,88)"/>
              <polygon class="arrowhead" points="392,200 380,194.4 380,205.6 " fill="black" transform="rotate(90,384,200)"/>
              <polygon class="arrowhead" points="352,408 340,402.4 340,413.6 " fill="black" transform="rotate(90,344,408)"/>
              <polygon class="arrowhead" points="344,224 332,218.4 332,229.6 " fill="black" transform="rotate(0,336,224)"/>
              <polygon class="arrowhead" points="320,320 308,314.4 308,325.6 " fill="black" transform="rotate(180,312,320)"/>
              <polygon class="arrowhead" points="312,88 300,82.4 300,93.6 " fill="black" transform="rotate(90,304,88)"/>
              <polygon class="arrowhead" points="304,272 292,266.4 292,277.6 " fill="black" transform="rotate(180,296,272)"/>
              <polygon class="arrowhead" points="232,408 220,402.4 220,413.6 " fill="black" transform="rotate(90,224,408)"/>
              <polygon class="arrowhead" points="128,328 116,322.4 116,333.6 " fill="black" transform="rotate(90,120,328)"/>
              <polygon class="arrowhead" points="104,408 92,402.4 92,413.6 " fill="black" transform="rotate(90,96,408)"/>
              <polygon class="arrowhead" points="96,200 84,194.4 84,205.6 " fill="black" transform="rotate(90,88,200)"/>
              <polygon class="arrowhead" points="80,328 68,322.4 68,333.6 " fill="black" transform="rotate(90,72,328)"/>
              <polygon class="arrowhead" points="64,200 52,194.4 52,205.6 " fill="black" transform="rotate(90,56,200)"/>
              <polygon class="arrowhead" points="64,88 52,82.4 52,93.6 " fill="black" transform="rotate(90,56,88)"/>
              <g class="text">
                <text x="60" y="52">Artifact</text>
                <text x="348" y="52">Issuer</text>
                <text x="56" y="116">Statement</text>
                <text x="292" y="116">sign</text>
                <text x="420" y="116">verify</text>
                <text x="68" y="228">Signed</text>
                <text x="404" y="228">Transparency</text>
                <text x="72" y="244">Statement</text>
                <text x="400" y="260">Service</text>
                <text x="248" y="276">Receipt</text>
                <text x="428" y="292">Transparency</text>
                <text x="264" y="324">Receipt</text>
                <text x="424" y="324">Service</text>
                <text x="96" y="356">Transparent</text>
                <text x="96" y="372">Statement</text>
                <text x="56" y="436">Collect</text>
                <text x="124" y="436">Receipts</text>
                <text x="228" y="436">Verify</text>
                <text x="304" y="436">Transparent</text>
                <text x="428" y="436">Replay</text>
                <text x="472" y="436">Log</text>
                <text x="272" y="452">Statement</text>
                <text x="72" y="468">Relying</text>
                <text x="128" y="468">Party</text>
                <text x="424" y="468">Relying</text>
                <text x="480" y="468">Party</text>
                <text x="256" y="484">Relying</text>
                <text x="312" y="484">Party</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
 .----------.                      +--------------+
|  Artifact  |                     |    Issuer    |
 '----+-----'                      +-+----------+-+
      v                              v          v
 .----+----.                   .-----+----.    .+---------.
| Statement |                 /   sign   /    /  verify  /
 '----+----'                 '-----+----+    '-------+--+
      |                            |                 '-------.
      |    .----------------------' '---------.               |
      |   |                                    |              |
      v   v                                    v              |
 .----+---+---.                           +----+----+-----+   |
|    Signed    +------------------------->+ Transparency  |   |
|   Statement  |                         .+               |   |
 '------+-----'           .-------.     | |   Service     +-+ |
        |      .---------+ Receipt +<--'  +--+------------+ | |
        |     |.-----.   |         +.        | Transparency | |
        |     |       |   '+------'  |       |              | |
        v     v        '---+ Receipt +<------+   Service    | |
     .--+-----+--.          '-------'        +--------+-----+ |
    | Transparent |                                   |       |
    |  Statement  +-------.                .----------)------'
     '-----+-----'         |              |           |
           v               v              v           v
  .--------+---------.  .--+--------------+--. .------+----------.
 / Collect Receipts /  / Verify Transparent / /   Replay Log    /
'--+---------------+  /      Statement     / '-+---------------+
   | Relying Party | '----+---------------+    | Relying Party |
   +---------------+      | Relying Party |    +---------------+
                          +---------------+
]]></artwork>
        </artset>
      </figure>
      <t>The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.</t>
      <section anchor="sec-transparency-service">
        <name>Transparency Service</name>
        <t>Transparency Services <bcp14>MUST</bcp14> produce COSE Receipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t>
        <t>Typically target="RFC9942"/>.</t>
        <t>Typically, a Transparency Service has a single Issuer identity which that is present in the <tt>iss</tt> Claim of Receipts for that service.</t>
        <t>Multi-tenant support can be enabled through the use of identifiers in the <tt>iss</tt> Claim, Claim; for example, <tt>ts.example.</tt> may have a distinct Issuer identity for each sub domain, subdomain, such as <tt>tenant1.ts.example.</tt> and <tt>tenant2.ts.example.</tt>.</t>
        <section anchor="sec-registration-policies">
          <name>Registration Policies</name>
          <t>Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is registered to the Verifiable Data Structure.
To enable audit-ability, auditability, Transparency Services <bcp14>MUST</bcp14> maintain Registration Policies.
The presence of an explicit transparent registration policy, even if it allows all authenticated submissions, facilitates service audit, and enables potential future changes to that policy.</t>
          <t>Beyond the mandatory Registration checks, the scope of additional checks, including no additional checks, is up to the implementation.</t>
          <t>This specification leaves implementation, encoding encoding, and documentation of Registration Policies and trust anchors to the operator of the Transparency Service.</t>

          <section anchor="sec-mandatory-registration-checks">
            <name>Mandatory Registration Checks</name>
            <t>During Registration, a Transparency Service <bcp14>MUST</bcp14> syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to <xref target="STD96"/>.
The Issuer identity <bcp14>MUST</bcp14> be bound to the Signed Statement by including an identifier in the protected header.
If the protected header includes multiple identifiers, all those that are registered by the Transparency Service <bcp14>MUST</bcp14> be checked.</t>
            <t>Transparency Services <bcp14>MUST</bcp14> maintain a list of trust anchors (see definition of trust anchor in <xref target="RFC4949"/>) in order to check the signatures of Signed Statements, Statements either separately, separately or inside Registration Policies.
	    Transparency Services <bcp14>MUST</bcp14> authenticate Signed Statements as part of a Registration Policy.  For instance, a trust anchor could be an X.509 root certificate (directly or its thumbprint), a pointer to an OpenID Connect identity provider, or any other trust anchor that can be referenced in a COSE header parameter.</t>
            <t>When using X.509 Signed Statements, the Transparency Service <bcp14>MUST</bcp14> build and validate a complete certification path from an Issuer's certificate to one of the root certificates currently registered as a trust anchor by the Transparency Service.
The protected header of the COSE_Sign1 Envelope <bcp14>MUST</bcp14> include either the Issuer's certificate as <tt>x5t</tt> or the chain including the Issuer's certificate as <tt>x5chain</tt>, as defined in <xref target="RFC9360"/>.
If <tt>x5t</tt> is included in the protected header, an <tt>x5chain</tt> with a leaf certificate corresponding to the <tt>x5t</tt> value <bcp14>MAY</bcp14> be included in the unprotected header.</t>
            <t>Registration Policies and trust anchors <bcp14>MUST</bcp14> be made Transparent and available to all Relying Parties of the Transparency Service by Registering them as Signed Statements on the Verifiable Data Structure.</t>
            <t>The Transparency Service <bcp14>MUST</bcp14> apply the Registration Policy that was most recently committed to the Verifiable Data Structure at the time of Registration.</t>
          </section>
          <section anchor="sec-auditability-of-registration">
            <name>Auditability of Registration</name>
            <t>The operator of a Transparency Service <bcp14>MAY</bcp14> update the Registration Policy or the trust anchors of a Transparency Service at any time.</t>
            <t>Transparency Services <bcp14>MUST</bcp14> ensure that for any Signed Statement they register, enough information is made available to Auditors to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration.
At a minimum, this consists of the Signed Statements themselves, any additional collateral data required to perform their authentication, and the applicable Registration Policy at the time of Registration.</t>
          </section>
        </section>
        <section anchor="ts-initialization">
          <name>Initialization and Bootstrapping</name>
          <t>Since the mandatory Registration checks rely on having registered Signed Statements for the Registration Policy and trust anchors, Transparency Services <bcp14>MUST</bcp14> support at least one of the three following bootstrapping mechanisms:</t>
          <ul spacing="normal">
            <li>Pre-configured
            <li>Preconfigured Registration Policy and trust anchors;</li>
            <li>Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing Registration checks</li> checks; or</li>
            <li>An out-of-band authenticated management interface</li> interface.</li>
          </ul>
        </section>
        <section anchor="sec-verifiable-data-structure">
          <name>Verifiable Data Structure</name>
          <t>The security properties are determined by the choice of the Verifiable Data Structure (<xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>) (see <xref target="RFC9942"/>) used by the Transparency Service implementation.
This verifiable data structure <bcp14>MUST</bcp14> support the following security requirements:</t>
          <dl>
            <dt>Append-Only:</dt>
            <dd>
              <t>a property required for a verifiable data structure to be applicable to SCITT, ensuring that the Statement Sequence cannot be modified, deleted, or reordered.</t>
            </dd>
            <dt>Non-equivocation:</dt>
            <dd>
              <t>there is no fork in the registered sequence of Signed Statements accepted by the Transparency Service and committed to the Verifiable Data Structure.
Everyone with access to its content sees the same ordered collection of Signed Statements and can check that it is consistent with any Receipts they have verified.</t>
            </dd>
            <dt>Replayability:</dt>
            <dd>
              <t>the Verifiable Data Structure includes sufficient information to enable authorized actors with access to its content to check that each data structure representing each Signed Statement has been correctly registered.</t>
            </dd>
          </dl>
          <t>In addition to Receipts, some verifiable data structures might support additional proof types, such as proofs of consistency, consistency or proofs of non-inclusion.</t>
          <t>Specific verifiable data structures, such those describes in <xref target="RFC9162"/> and <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, target="RFC9942"/>, and the review of their security requirements for SCITT are out of scope for this document.</t>
        </section>
        <section anchor="sec-adjacent-services">
          <name>Adjacent Services</name>
          <t>Transparency Services can be deployed along side alongside other database or object storage technologies.
For example, a Transparency Service that supports a software package management system, might be referenced from the APIs exposed for package management.
It can also provide the ability to request a fresh Receipt for a given software package, package or a list of Signed Statements associated with that package.</t>
        </section>
      </section>
    </section>
    <section anchor="signed-statements">
      <name>Signed Statements</name>
      <t>This specification prioritizes conformance to <xref target="STD96"/> and its required and optional properties.
Signed Statements produced by Issuers must be COSE_Sign1 messages, as defined by <xref target="STD96"/>.
Profiles and implementation specific implementation-specific choices should be used to determine admissibility of conforming messages.
This specification is left intentionally open to allow implementations to make Registration restrictions that make the most sense for their operational use cases.</t>
      <t>There are many types of Statements (such as SBOMs, an SBOM, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements.
An Issuer must first decide on a suitable format (<tt>3</tt>: payload type) to serialize the Statement payload.
      For a software supply chain, payloads describing the software Artifacts may include:</t>

<!--[rfced] In the following list, we will update to have the citation
     follow the text unless we hear objection.

Original:
   *  [CoSWID] Concise Software Identification Tags format

   *  [CycloneDX] Bill of Materials format

   *  [in-toto] Supply chain description metadata

   *  [SPDX-CBOR] Software component description format

   *  [SPDX-JSON] Software component description format

   *  [SLSA] Supply-chain Levels for Software Artifacts

   *  [SWID] Software Identification Tag format
-->

      <ul spacing="normal">
        <li>
          <xref target="CoSWID"/> target="RFC9393"/> Concise Software Identification Tags format</li>
        <li>
          <xref target="CycloneDX"/> Bill of Materials format</li>
        <li>
          <xref target="in-toto"/> Supply chain description metadata</li>
        <li>
          <xref target="SPDX-CBOR"/> Software component description format</li>
        <li>
          <xref target="SPDX-JSON"/> Software component description format</li>
        <li>
          <xref target="SLSA"/> Supply-chain Levels for Software Artifacts</li>
        <li>
          <xref target="SWID"/> Software Identification Tag format</li>
      </ul>
      <t>Issuers can produce Signed Statements about different Artifacts under the same Identity.
Issuers and Relying Parties must be able to recognize the Artifact to which the Statements pertain by looking at the Signed Statement.
The <tt>iss</tt> and <tt>sub</tt> Claims, within the <tt>CWT Claims</tt> protected header, are used to identify the Artifact the Statement pertains to.
(See Subject under in <xref target="terminology"/> Terminology.)</t> target="terminology"/>.)</t>
      <t>Issuers <bcp14>MAY</bcp14> use different signing keys (identified by <tt>kid</tt> in the <xref target="STD96"/> protected header) header from <xref target="STD96"/>) for different Artifacts or sign all Signed Statements under the same key.</t>
      <t>An Issuer can make multiple Statements about the same Artifact.
For example, an Issuer can make amended Statements about the same Artifact as their view changes over time.</t>
      <t>Multiple Issuers can make different, even conflicting Statements, conflicting, Statements about the same Artifact.
Relying Parties can choose which Issuers they trust.</t>
      <t>Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree.</t>
      <t>Additionally, an <tt>x5chain</tt> that corresponds to either <tt>x5t</tt> or <tt>kid</tt> identifying the leaf certificate in the included certification path <bcp14>MAY</bcp14> be included in the unprotected header of the COSE Envelope.</t>
      <ul spacing="normal">
        <li>When using x.509 certificates, support for either <tt>x5t</tt> or <tt>x5chain</tt> in the protected header is <bcp14>REQUIRED</bcp14> to implement.</li>
        <li>Support for <tt>kid</tt> in the protected header and <tt>x5chain</tt> in the unprotected header is <bcp14>OPTIONAL</bcp14> to implement.</li>
      </ul>
      <t>When <tt>x5t</tt> or <tt>x5chain</tt> is present in the protected header, <tt>iss</tt> <bcp14>MUST</bcp14> be a string that meets URI requirements defined in <xref target="RFC8392"/>.
The <tt>iss</tt> value's length <bcp14>MUST</bcp14> be between 1 and 8192 characters in length.</t>
      <t>The <tt>kid</tt> header parameter <bcp14>MUST</bcp14> be present when neither <tt>x5t</tt> nor <tt>x5chain</tt> is present in the protected header.
Key discovery protocols are out-of-scope out of scope of this document.</t>
      <t>The protected header of a Signed Statement and a Receipt <bcp14>MUST</bcp14> include the <tt>CWT Claims</tt> header parameter as specified in <xref section="2" sectionFormat="of" target="RFC9597"/>.
The <tt>CWT Claims</tt> value <bcp14>MUST</bcp14> include the <tt>Issuer Claim</tt> (Claim label 1) and the <tt>Subject Claim</tt> (Claim label 2) <xref target="IANA.cwt"/>.</t>
      <t>A Receipt is a Signed Statement (COSE_Sign1) with additional Claims in its protected header related to verifying the inclusion proof in its unprotected header.
See <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t> target="RFC9942"/>.</t>
      <section anchor="sec-signed-statement-examples">
        <name>Signed Statement Examples</name>
        <t><xref target="fig-signed-statement-cddl"/> illustrates a normative CDDL definition <xref target="RFC8610"/> for the protected header and unprotected header of Signed Statements and Receipts.</t>
        <t>The SCITT architecture specifies the minimal mandatory labels.
Implementation-specific Registration Policies may define additional mandatory labels.</t>
        <figure anchor="fig-signed-statement-cddl">
          <name>CDDL definition Definition for Signed Statements and Receipts</name>
          <sourcecode type="cddl"> type="cddl"><![CDATA[
Signed_Statement = #6.18(COSE_Sign1)
Receipt = #6.18(COSE_Sign1)

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

Protected_Header = {
  &amp;(CWT_Claims:
  &(CWT_Claims: 15) =&gt; => CWT_Claims
  ? &amp;(alg: &(alg: 1) =&gt; => int
  ? &amp;(content_type: &(content_type: 3) =&gt; => tstr / uint
  ? &amp;(kid: &(kid: 4) =&gt; => bstr
  ? &amp;(x5t: &(x5t: 34) =&gt; => COSE_CertHash
  ? &amp;(x5chain: &(x5chain: 33) =&gt; => COSE_X509
  * label =&gt; => any
}

CWT_Claims = {
  &amp;(iss:
  &(iss: 1) =&gt; => tstr
  &amp;(sub:
  &(sub: 2) =&gt; => tstr
  * label =&gt; => any
}

Unprotected_Header = {
  ? &amp;(x5chain: &(x5chain: 33) =&gt; => COSE_X509
  ? &amp;(receipts: &(receipts: 394)  =&gt;  => [+ Receipt]
  * label =&gt; => any
}

label = int / tstr
</sourcecode> tstr]]></sourcecode>
        </figure>
        <t><xref target="fig-signed-statement-edn"/> illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that is detached.
Detached payloads support large Statements, Statements and ensure Signed Statements can integrate with existing storage systems.</t>
        <figure anchor="fig-signed-statement-edn">
          <name>CBOR Extended
          <name>CBOR-Extended Diagnostic Notation example Example of a Signed Statement</name>
          <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
18(                                 / COSE_Sign1       /
    [
      h'a4012603...6d706c65',       / Protected        /
      {},                           / Unprotected      /
      nil,                          / Detached payload /
      h'79ada558...3a28bae4'        / Signature        /
    ]
)
</sourcecode>
)]]></sourcecode>
        </figure>
        <t><xref target="fig-signed-statement-protected-header-edn"/> illustrates the decoded protected header of the Signed Statement in <xref target="fig-signed-statement-edn"/>.
It indicates the Signed Statement is securing a JSON content type, type and identifying the content with the <tt>sub</tt> Claim "vendor.product.example".</t>
        <figure anchor="fig-signed-statement-protected-header-edn">
          <name>CBOR Extended
          <name>CBOR-Extended Diagnostic Notation example Example of a Signed Statement's Protected Header</name>
          <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
{                                   / Protected        /
  1: -7,                            / Algorithm        /
  3: application/example+json,      / Content type     /
  4: h'50685f55...50523255',        / Key identifier   /
  15: {                             / CWT Claims       /
    1: software.vendor.example,     / Issuer           /
    2: vendor.product.example,      / Subject          /
  }
}
</sourcecode>
}]]></sourcecode>
        </figure>
      </section>
      <section anchor="sec-signing-large-or-sensitive-statements">
        <name>Signing Large or Sensitive Statements</name>
        <t>Statements
        <t>Statement payloads might be too large or too sensitive to be sent to a remote Transparency Service.
	In these cases cases, a Statement can be made over the hash of a payload, payload rather than the full payload bytes.</t>

<!--[rfced] We had the following questions about the figure in Section
     6.2:

a) There is no number or title.  How may we update?

b) We believe To Be Signed Bytes should be made To-Be-Signed Bytes to
match the use in the Terminology section.  If this is the case, please
update and regenerate the SVG.

-->

        <artset>
          <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="736" width="376" viewBox="0 0 376 736" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,112 L 8,144" fill="none" stroke="black"/>
              <path d="M 8,416 L 8,432" fill="none" stroke="black"/>
              <path d="M 40,64 L 40,80" fill="none" stroke="black"/>
              <path d="M 40,176 L 40,200" fill="none" stroke="black"/>
              <path d="M 56,64 L 56,104" fill="none" stroke="black"/>
              <path d="M 56,456 L 56,480" fill="none" stroke="black"/>
              <path d="M 56,512 L 56,584" fill="none" stroke="black"/>
              <path d="M 56,656 L 56,680" fill="none" stroke="black"/>
              <path d="M 104,416 L 104,432" fill="none" stroke="black"/>
              <path d="M 144,128 L 144,224" fill="none" stroke="black"/>
              <path d="M 272,432 L 272,520" fill="none" stroke="black"/>
              <path d="M 272,560 L 272,584" fill="none" stroke="black"/>
              <path d="M 328,192 L 328,288" fill="none" stroke="black"/>
              <path d="M 328,352 L 328,584" fill="none" stroke="black"/>
              <path d="M 40,32 L 112,32" fill="none" stroke="black"/>
              <path d="M 40,64 L 112,64" fill="none" stroke="black"/>
              <path d="M 40,112 L 112,112" fill="none" stroke="black"/>
              <path d="M 128,128 L 144,128" fill="none" stroke="black"/>
              <path d="M 40,144 L 112,144" fill="none" stroke="black"/>
              <path d="M 264,160 L 336,160" fill="none" stroke="black"/>
              <path d="M 144,176 L 168,176" fill="none" stroke="black"/>
              <path d="M 216,176 L 240,176" fill="none" stroke="black"/>
              <path d="M 264,192 L 336,192" fill="none" stroke="black"/>
              <path d="M 40,208 L 104,208" fill="none" stroke="black"/>
              <path d="M 120,224 L 144,224" fill="none" stroke="black"/>
              <path d="M 40,240 L 104,240" fill="none" stroke="black"/>
              <path d="M 24,400 L 88,400" fill="none" stroke="black"/>
              <path d="M 104,432 L 272,432" fill="none" stroke="black"/>
              <path d="M 24,448 L 88,448" fill="none" stroke="black"/>
              <path d="M 24,480 L 112,480" fill="none" stroke="black"/>
              <path d="M 24,512 L 112,512" fill="none" stroke="black"/>
              <path d="M 240,528 L 296,528" fill="none" stroke="black"/>
              <path d="M 240,560 L 296,560" fill="none" stroke="black"/>
              <path d="M 40,592 L 152,592" fill="none" stroke="black"/>
              <path d="M 216,592 L 352,592" fill="none" stroke="black"/>
              <path d="M 144,624 L 200,624" fill="none" stroke="black"/>
              <path d="M 8,656 L 120,656" fill="none" stroke="black"/>
              <path d="M 216,656 L 352,656" fill="none" stroke="black"/>
              <path d="M 24,688 L 112,688" fill="none" stroke="black"/>
              <path d="M 24,720 L 112,720" fill="none" stroke="black"/>
              <path d="M 200,624 L 216,656" fill="none" stroke="black"/>
              <path d="M 352,592 L 368,624" fill="none" stroke="black"/>
              <path d="M 176,176 L 196,216" fill="none" stroke="black"/>
              <path d="M 196,136 L 216,176" fill="none" stroke="black"/>
              <path d="M 176,176 L 196,136" fill="none" stroke="black"/>
              <path d="M 196,216 L 216,176" fill="none" stroke="black"/>
              <path d="M 8,656 L 40,592" fill="none" stroke="black"/>
              <path d="M 120,656 L 152,592" fill="none" stroke="black"/>
              <path d="M 200,624 L 216,592" fill="none" stroke="black"/>
              <path d="M 352,656 L 368,624" fill="none" stroke="black"/>
              <path d="M 40,32 C 31.16936,32 24,39.16936 24,48" fill="none" stroke="black"/>
              <path d="M 112,32 C 120.83064,32 128,39.16936 128,48" fill="none" stroke="black"/>
              <path d="M 40,64 C 31.16936,64 24,56.83064 24,48" fill="none" stroke="black"/>
              <path d="M 112,64 C 120.83064,64 128,56.83064 128,48" fill="none" stroke="black"/>
              <path d="M 24,96 C 15.16936,96 8,103.16936 8,112" fill="none" stroke="black"/>
              <path d="M 24,96 C 32.83064,96 40,88.83064 40,80" fill="none" stroke="black"/>
              <path d="M 40,112 C 31.16936,112 24,119.16936 24,128" fill="none" stroke="black"/>
              <path d="M 112,112 C 120.83064,112 128,119.16936 128,128" fill="none" stroke="black"/>
              <path d="M 40,144 C 31.16936,144 24,136.83064 24,128" fill="none" stroke="black"/>
              <path d="M 112,144 C 120.83064,144 128,136.83064 128,128" fill="none" stroke="black"/>
              <path d="M 24,160 C 15.16936,160 8,152.83064 8,144" fill="none" stroke="black"/>
              <path d="M 24,160 C 32.83064,160 40,167.16936 40,176" fill="none" stroke="black"/>
              <path d="M 264,160 C 255.16936,160 248,167.16936 248,176" fill="none" stroke="black"/>
              <path d="M 336,160 C 344.83064,160 352,167.16936 352,176" fill="none" stroke="black"/>
              <path d="M 264,192 C 255.16936,192 248,184.83064 248,176" fill="none" stroke="black"/>
              <path d="M 336,192 C 344.83064,192 352,184.83064 352,176" fill="none" stroke="black"/>
              <path d="M 40,208 C 31.16936,208 24,215.16936 24,224" fill="none" stroke="black"/>
              <path d="M 104,208 C 112.83064,208 120,215.16936 120,224" fill="none" stroke="black"/>
              <path d="M 40,240 C 31.16936,240 24,232.83064 24,224" fill="none" stroke="black"/>
              <path d="M 104,240 C 112.83064,240 120,232.83064 120,224" fill="none" stroke="black"/>
              <path d="M 24,400 C 15.16936,400 8,407.16936 8,416" fill="none" stroke="black"/>
              <path d="M 88,400 C 96.83064,400 104,407.16936 104,416" fill="none" stroke="black"/>
              <path d="M 24,448 C 15.16936,448 8,440.83064 8,432" fill="none" stroke="black"/>
              <path d="M 88,448 C 96.83064,448 104,440.83064 104,432" fill="none" stroke="black"/>
              <path d="M 24,480 C 15.16936,480 8,487.16936 8,496" fill="none" stroke="black"/>
              <path d="M 112,480 C 120.83064,480 128,487.16936 128,496" fill="none" stroke="black"/>
              <path d="M 24,512 C 15.16936,512 8,504.83064 8,496" fill="none" stroke="black"/>
              <path d="M 112,512 C 120.83064,512 128,504.83064 128,496" fill="none" stroke="black"/>
              <path d="M 240,528 C 231.16936,528 224,535.16936 224,544" fill="none" stroke="black"/>
              <path d="M 296,528 C 304.83064,528 312,535.16936 312,544" fill="none" stroke="black"/>
              <path d="M 240,560 C 231.16936,560 224,552.83064 224,544" fill="none" stroke="black"/>
              <path d="M 296,560 C 304.83064,560 312,552.83064 312,544" fill="none" stroke="black"/>
              <path d="M 24,688 C 15.16936,688 8,695.16936 8,704" fill="none" stroke="black"/>
              <path d="M 112,688 C 120.83064,688 128,695.16936 128,704" fill="none" stroke="black"/>
              <path d="M 24,720 C 15.16936,720 8,712.83064 8,704" fill="none" stroke="black"/>
              <path d="M 112,720 C 120.83064,720 128,712.83064 128,704" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="336,584 324,578.4 324,589.6 " fill="black" transform="rotate(90,328,584)"/>
              <polygon class="arrowhead" points="280,584 268,578.4 268,589.6 " fill="black" transform="rotate(90,272,584)"/>
              <polygon class="arrowhead" points="280,520 268,514.4 268,525.6 " fill="black" transform="rotate(90,272,520)"/>
              <polygon class="arrowhead" points="248,176 236,170.4 236,181.6 " fill="black" transform="rotate(0,240,176)"/>
              <polygon class="arrowhead" points="176,176 164,170.4 164,181.6 " fill="black" transform="rotate(0,168,176)"/>
              <polygon class="arrowhead" points="152,624 140,618.4 140,629.6 " fill="black" transform="rotate(180,144,624)"/>
              <polygon class="arrowhead" points="64,680 52,674.4 52,685.6 " fill="black" transform="rotate(90,56,680)"/>
              <polygon class="arrowhead" points="64,584 52,578.4 52,589.6 " fill="black" transform="rotate(90,56,584)"/>
              <polygon class="arrowhead" points="64,456 52,450.4 52,461.6 " fill="black" transform="rotate(270,56,456)"/>
              <polygon class="arrowhead" points="64,104 52,98.4 52,109.6 " fill="black" transform="rotate(90,56,104)"/>
              <polygon class="arrowhead" points="48,200 36,194.4 36,205.6 " fill="black" transform="rotate(90,40,200)"/>
              <g class="text">
                <text x="76" y="52">Artifact</text>
                <text x="60" y="132">Hash</text>
                <text x="196" y="180">OR</text>
                <text x="296" y="180">Payload</text>
                <text x="72" y="228">Statement</text>
                <text x="104" y="292">...</text>
                <text x="164" y="292">Producer</text>
                <text x="232" y="292">Network</text>
                <text x="280" y="292">...</text>
                <text x="192" y="324">...</text>
                <text x="104" y="356">...</text>
                <text x="164" y="356">Issuer</text>
                <text x="224" y="356">Network</text>
                <text x="272" y="356">...</text>
                <text x="52" y="420">Identity</text>
                <text x="168" y="420">(iss,</text>
                <text x="212" y="420">x5t)</text>
                <text x="52" y="436">Document</text>
                <text x="48" y="500">Private</text>
                <text x="96" y="500">Key</text>
                <text x="268" y="548">Header</text>
                <text x="76" y="628">Sign</text>
                <text x="220" y="628">To</text>
                <text x="244" y="628">Be</text>
                <text x="284" y="628">Signed</text>
                <text x="336" y="628">Bytes</text>
                <text x="60" y="708">COSE_Sign1</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art"><![CDATA[
   .----+-----.
  |  Artifact  |
   '+-+-------'
    | |
 .-'  v
|  .--+-------.
| |  Hash      +-+
|  '----------'  |     /\
 '-.             |    /  \     .----------.
    |            +-->+ OR +-->+  Payload   |
    v            |    \  /     '--------+-'
   .+--------.   |     \/               |
  | Statement +--+                      |
   '---------'                          |
                                        |
                                        |
           ...  Producer Network ...    |

                      ...

           ...   Issuer Network ...     |
                                        |
                                        |
 .---------.                            |
| Identity  |     (iss, x5t)            |
| Document  +--------------------+      |
 `----+----`                     |      |
      ^                          |      |
 .----+-------.                  |      |
| Private Key  |                 |      |
 '----+-------'                  v      |
      |                     .----+---.  |
      |                    |  Header  | |
      |                     '----+---'  |
      v                          v      v
    .-+-----------.       .------+------+--.
   /             /       /                  \
  /    Sign     +<------+ To Be Signed Bytes |
 /             /         \                  /
'-----+-------'           '----------------'
      v
 .----+-------.
| COSE_Sign1   |
 '------------'
]]></artwork>
        </artset>
      </section>
      <section anchor="sec-registration-of-signed-statements">
        <name>Registration of Signed Statements</name>
        <t>To register a Signed Statement, the Transparency Service performs the following steps:</t>
        <ol spacing="normal" type="1">
          <li>
            <strong>Client authentication:</strong> A

<!--[rfced] Section 6.3 (in the numbered list): Points 1-3 began with
     a phrase enclosed in <strong> followed by a colon; but points 4
     and 5 did not have text following the part in <strong>.

Please see our formatting updates where we:

- got rid of <strong>,
- got rid of the colons, and
- added a blank line after the text that was in <strong>

We believe that the current version of this list looks more parallel
(each entry is the step performed followed by any further info if it
exists) and might be easier for the reader's eyes (especially in the
text file).  Please review and let us know if we've not correctly
captured your intent.

	    -->

            <t>Client Authentication</t> <t>A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers.
Authentication and authorization are implementation-specific implementation specific and out of scope of the SCITT architecture.</li> architecture.</t></li>
          <li>
            <strong>TS
            <t>TS Signed Statement Verification and Validation:</strong> The Validation</t><t>The Transparency Service <bcp14>MUST</bcp14> perform signature verification per Section <xref section="4.4" sectionFormat="of" sectionFormat="bare" target="RFC9052"/> of RFC 9052 <xref target="STD96"/> and <bcp14>MUST</bcp14> verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per <xref target="RFC9360"/>.
The Transparency Service <bcp14>MUST</bcp14> also check that the Signed Statement includes the required protected headers.
The Transparency Service <bcp14>MAY</bcp14> validate the Signed Statement payload in order to enforce domain specific domain-specific registration policies that apply to specific content types.</li> types.</t></li>
          <li>
            <strong>Apply
            <t>Apply Registration Policy:</strong> The Policy</t><t>The Transparency Service <bcp14>MUST</bcp14> check the attributes required by a Registration Policy are present in the protected headers.
  Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope and may use information contained in the attributes of named policies.</li> policies.</t></li>
          <li>
            <strong>Register
            <t>Register the Signed Statement</strong></li> Statement</t></li>
          <li>
            <strong>Return
            <t>Return the Receipt</strong>, which Receipt</t> <t>This <bcp14>MAY</bcp14> be asynchronous from Registration.
The Transparency Service <bcp14>MUST</bcp14> be able to provide a Receipt for all registered Signed Statements.
Details about generating Receipts are described in <xref target="Receipt"/>.</li> target="Receipt"/>.</t></li>
        </ol>
        <t>The last two steps may be shared between a batch of Signed Statements registered in the Verifiable Data Structure.</t>
        <t>A Transparency Service <bcp14>MUST</bcp14> ensure that a Signed Statement is registered before releasing its Receipt.</t>
        <t>A Transparency Service <bcp14>MAY</bcp14> accept a Signed Statement with content in its unprotected header, header and <bcp14>MAY</bcp14> use values from that unprotected header during verification and registration policy evaluation.</t>
        <t>However, the unprotected header of a Signed Statement <bcp14>MUST</bcp14> be set to an empty map before the Signed Statement can be included in a Statement Sequence.</t>
        <t>The same Signed Statement may be independently registered in multiple Transparency Services, producing multiple, multiple independent Receipts.
The multiple Receipts may be attached to the unprotected header of the Signed Statement, Statement creating a Transparent Statement.</t>
        <t>An Issuer that knows of a changed state of quality for an Artifact, Artifact <bcp14>SHOULD</bcp14> Register a new Signed Statement, Statement using the same <tt>15</tt> CWT <tt>iss</tt> and <tt>sub</tt> Claims.</t>
      </section>
    </section>
    <section anchor="Receipt">
      <name>Transparent Statements</name>
      <t>The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the unprotected header of the Signed Statement.
Client applications <bcp14>MAY</bcp14> register Signed Statements on behalf of one or more Issuers.
Client applications <bcp14>MAY</bcp14> request Receipts regardless of the identity of the Issuer of the associated Signed Statement.</t>
      <t>When a Signed Statement is registered by a Transparency Service a Receipt becomes available.
When a Receipt is included in a Signed Statement Statement, a Transparent Statement is produced.</t>
      <t>Receipts are based on Signed Inclusion Proofs as described in COSE Receipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> that target="RFC9942"/>, which also provides the COSE header parameter semantics for label 394.</t>
      <t>The Registration time is recorded as the timestamp when the Transparency Service added the Signed Statement to its Verifiable Data Structure.</t>
      <t><xref target="fig-transparent-statement-cddl"/> illustrates a normative CDDL definition of Transparent Statements.
See <xref target="fig-signed-statement-cddl"/> for the CDDL rule that defines 'COSE_Sign1' as specified in Section <xref section="4.2" sectionFormat="of" target="STD96"/></t> sectionFormat="bare" target="RFC9052"/> of RFC 9052 <xref target="STD96"/>.</t>
      <figure anchor="fig-transparent-statement-cddl">
        <name>CDDL definition Definition for a Transparent Statement</name>
        <sourcecode type="cddl"> type="cddl"><![CDATA[
Transparent_Statement = #6.18(COSE_Sign1)

Unprotected_Header = {
  &amp;(receipts:
  &(receipts: 394)  =&gt;  => [+ Receipt]
}
</sourcecode>
}]]></sourcecode>
      </figure>
      <t><xref target="fig-transparent-statement-edn"/> illustrates a Transparent Statement with a detached payload, payload and two Receipts in its unprotected header.
The type of label 394 <tt>receipts</tt> in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts).</t> .cbor-encoded Receipt).</t>
      <figure anchor="fig-transparent-statement-edn">
        <name>CBOR Extended
        <name>CBOR-Extended Diagnostic Notation example Example of a Transparent Statement</name>
        <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
18(                                 / COSE_Sign1                /
    [
      h'a4012603...6d706c65',       / Protected                 /
      {                             / Unprotected               /
        394:   [                    / Receipts (2)              /
          h'd284586c...4191f9d2'    / Receipt 1                 /
          h'c624586c...8f4af97e'    / Receipt 2                 /
        ]
      },
      nil,                          / Detached payload          /
      h'79ada558...3a28bae4'        / Signature                 /
    ]
)
</sourcecode>
)]]></sourcecode>
      </figure>
      <t><xref target="fig-receipt-edn"/> illustrates one of the decoded Receipt Receipts from <xref target="fig-transparent-statement-edn"/>.
The Receipt contains inclusion proofs for verifiable data structures.
The unprotected header contains verifiable data structure proofs.
See the protected header for details regarding the specific verifiable data structure used.
Per the COSE Verifiable Data Structure Algorithms Registry documented in <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, target="RFC9942"/>, the COSE key type RFC9162_SHA256 is value <tt>1</tt>.
Labels identify inclusion proofs (<tt>-1</tt>) and consistency proofs (<tt>-2</tt>).</t>
      <figure anchor="fig-receipt-edn">
        <name>CBOR Extended
        <name>CBOR-Extended Diagnostic Notation example Example of a Receipt</name>
        <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
18(                                 / COSE_Sign1                /
    [
      h'a4012604...6d706c65',       / Protected                 /
      {                             / Unprotected               /
        -222: {                     / Proofs                    /
          -1: [                     / Inclusion proofs (1)      /
            h'83080783...32568964', / Inclusion proof 1         /
          ]
        },
      },
      nil,                          / Detached payload          /
      h'10f6b12a...4191f9d2'        / Signature                 /
    ]
)
</sourcecode>
)]]></sourcecode>
      </figure>
      <t><xref target="fig-receipt-protected-header-edn"/> illustrates the decoded protected header of the Transparent Statement in <xref target="fig-transparent-statement-edn"/>.

<!--[rfced] The parentheses at the end of these sentences make them
     read strangely (how does it relate to the rest of the sentence?).
     Please review:

Original:
The verifiable data structure (-111) uses 1 from (RFC9162_SHA256).

and

The structure of this inclusion proof is specific to the verifiable
data structure used (RFC9162_SHA256).
-->

The verifiable data structure (<tt>-111</tt>) uses <tt>1</tt> from (RFC9162_SHA256).</t>
      <figure anchor="fig-receipt-protected-header-edn">
        <name>CBOR Extended
        <name>CBOR-Extended Diagnostic Notation example Example of a Receipt's Protected Header</name>
        <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
{                                   / Protected                 /
  1: -7,                            / Algorithm                 /
  4: h'50685f55...50523255',        / Key identifier            /
  -111: 1,                          / Verifiable Data Structure /
  15: {                             / CWT Claims                /
    1: transparency.vendor.example, / Issuer                    /
    2: vendor.product.example,      / Subject                   /
  }
}
</sourcecode>
}]]></sourcecode>
      </figure>
      <t><xref target="fig-receipt-inclusion-proof-edn"/> illustrates the decoded inclusion proof from <xref target="fig-receipt-edn"/>.
This inclusion proof indicates that the size of the Verifiable Data Structure was <tt>8</tt> at the time the Receipt was issued.
The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256).</t>
      <figure anchor="fig-receipt-inclusion-proof-edn">
        <name>CBOR Extended
        <name>CBOR-Extended Diagnostic Notation example Example of a Receipt's Inclusion Proof</name>
        <sourcecode type="cbor-diag"> type="cbor-diag"><![CDATA[
[                                   / Inclusion proof 1         /
  8,                                / Tree size                 /
  7,                                / Leaf index                /
  [                                 / Inclusion hashes (3)      /
     h'c561d333...f9850597'         / Intermediate hash 1       /
     h'75f177fd...2e73a8ab'         / Intermediate hash 2       /
     h'0bdaaed3...32568964'         / Intermediate hash 3       /
  ]
]
</sourcecode>
]]]></sourcecode>
      </figure>
      <section anchor="validation">
        <name>Validation</name>
        <t>Relying Parties <bcp14>MUST</bcp14> apply the verification process as described in Section <xref section="4.4" sectionFormat="of" target="STD96"/>, sectionFormat="bare" target="RFC9052"/> of RFC 9052 <xref target="STD96"/> when checking the signature of Signed Statements and Receipts.</t>
        <t>A Relying Party <bcp14>MUST</bcp14> trust the verification key or certificate and the associated identity of at least one Issuer of a Receipt.</t>
        <t>A Relying Party <bcp14>MAY</bcp14> decide to verify only a single Receipt that is acceptable to them and not check the signature on the Signed Statement or Receipts which that rely on verifiable data structures which they do not understand.</t>
        <t>APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.
For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if Claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid.</t>
        <t>Relying Parties <bcp14>MAY</bcp14> be configured to re-verify the Issuer's Signed Statement locally.</t>
        <t>In addition, Relying Parties <bcp14>MAY</bcp14> apply arbitrary validation policies after the Transparent Statement has been verified and validated.
Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state.</t>
      </section>
    </section>
    <section anchor="sec-privacy-considerations">
      <name>Privacy Considerations</name>
      <t>Interactions with Transparency Services are expected to use appropriately strong encryption and authorization technologies.</t>
      <t>The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.
Issuers and Clients are responsible for verifying that the Transparency Service's privacy and security posture is suitable for the contents of the Signed Statements they submit prior to Registration.
Issuers must carefully review the inclusion of private, confidential, or personally identifiable information Personally Identifiable Information (PII) in their Statements against the Transparency Service's privacy posture.</t>
<t>In some deployments deployments, a special role such as an Auditor might require and be given access to both the Transparency Service and related Adjacent Services.</t>
      <t>Transparency

<!--[rfced] Please carefully review our edits to this text to ensure
     we have maintained your intended meaning.

Original:
   Transparency Services can leverage Verifiable Data Structures which
   only retain cryptographic metadata (e.g. a hash), rather than the
   complete Signed Statement, as part of a defense in depth approach to
   maintaining confidentiality.

Current:
   Transparency Services can leverage Verifiable Data Structures that
   only retain cryptographic metadata (e.g., a hash) rather than the
   complete Signed Statement as part of an in-depth defensive approach to
   maintaining confidentiality.
-->

      <t>Transparency Services can leverage Verifiable Data Structures that only retain cryptographic metadata (e.g., a hash) rather than the complete Signed Statement as part of an in-depth defensive approach to maintaining confidentiality.
By analyzing the relationship between data stored in the Transparency Service and data stored in Adjacent Services, it is possible to perform metadata analysis, which could reveal the order in which artifacts were built, signed, and uploaded.</t>
    </section>
    <section anchor="SecConSec">
      <name>Security Considerations</name>
      <t>SCITT provides the following security guarantees:</t>
      <ol spacing="normal" type="1">
        <li>Statements made by Issuers about supply chain Artifacts are identifiable and can be authenticated</li> authenticated.</li>
        <li>Statement provenance and history can be independently and consistently audited</li> audited.</li>
        <li>Issuers can efficiently prove that their Statement is logged by a Transparency Service</li> Service.</li>
      </ol>
      <t>The first guarantee is achieved by requiring Issuers to sign their Statements.
The second guarantee is achieved by proving a Signed Statement is present in a Verifiable Data Structure.
The third guarantee is achieved by the combination of both of these steps.</t>
      <t>In addition to deciding whether to trust a Transparency Service, Relying Parties can use the history of registered Signed Statements to decide which Issuers they choose to trust.
This decision process is out of scope of this document.</t>
      <section anchor="sec-ordering-of-signed-statements">
        <name>Ordering of Signed Statements</name>
        <t>Statements are signed prior to submitting to a SCITT Transparency service.
Unless advertised in the Transparency Service Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the Verifiable Data Structure matches the ordering of their issuance.</t>
      </section>
      <section anchor="sec-accuracy-of-statements">
        <name>Accuracy of Statements</name>
        <t>Issuers can make false Statements either intentionally or unintentionally; registering a Statement only proves it was produced by an Issuer.
A registered Statement may be superseded by a subsequently submitted Signed Statement from the same Issuer, with the same subject in the <tt>CWT Claims</tt> protected header.
Other Issuers may make new Statements to reflect new or corrected information.
Relying Parties may choose to include or exclude Statements from Issuers to determine the accuracy of a collection of Statements.</t>
      </section>
      <section anchor="sec-issuer-participation">
        <name>Issuer Participation</name>
        <t>Issuers can refuse to register their Statements with a Transparency Service, Service or selectively submit some but not all the Statements they issue.
It is important for Relying Parties not to accept Signed Statements for which they cannot discover Receipts issued by a Transparency Service they trust.</t>
      </section>
      <section anchor="sec-key-management">
        <name>Key Management</name>
        <t>Issuers and Transparency Services <bcp14>MUST</bcp14>:</t>
        <ul spacing="normal">
          <li>carefully protect their private signing keys</li>
          <li>avoid using keys for more than one purpose</li>
          <li>rotate their keys at a cryptoperiod (defined in <xref target="RFC4949"/>) appropriate for the key algorithm key-algorithm and domain-specific regulations</li>
        </ul>
        <section anchor="sec-verifiable-data-structure-1">
          <name>Verifiable Data Structure</name>
          <t>The security considerations for specific Verifiable Data Structures are out of scope for this document.
See <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> target="RFC9942"/> for the generic security considerations that apply to Verifiable Data Structure and Receipts.</t>
        </section>
        <section anchor="sec-key-compromise">
          <name>Key Compromise</name>
          <t>It is important for Issuers and Transparency Services to clearly communicate when keys are compromised, compromised so that Signed Statements can be rejected by Transparency Services or Receipts can be ignored by Relying Parties.
Transparency Services whose receipt signing keys have been compromised can roll back their Statement Sequence to a point before compromise, establish new credentials, and use them the new credentials to issue fresh Receipts going forward.
Issuers are encouraged to follow existing best practices if their credentials are compromised.
Revocation strategies for compromised keys are out of scope for this document.</t>
        </section>
        <section anchor="sec-bootstrapping">
          <name>Bootstrapping</name>
          <t>Bootstrapping mechanisms that solely rely on Statement registration to set and update registration policy can be audited without additional implementation-specific knowledge, and knowledge; therefore, they are therefore preferable.
Mechanisms that rely on pre-configured preconfigured values and do not allow updates are unsuitable for use in long-lived service deployments, deployments in which the ability to patch a potentially faulty policy is essential.</t>
        </section>
      </section>
      <section anchor="MediaTypeSecConSec">
        <name>Implications of Media-Type Media Type Usage</name>
        <t>The Statement (scitt-statement+cose) and Receipt (scitt-receipt+cose) media types describe the expected content of COSE envelope headers.
The payload media type ('content type') is included in the COSE envelope header.
<xref target="STD96"/> describes the security implications of reliance on this header parameter.</t>
        <t>Both media types describe COSE_Sign1 messages, which include a signature, signature and therefore provide integrity protection.</t>
      </section>
      <section anchor="sec-cryptographic-agility">
        <name>Cryptographic Agility</name>
        <t>Because the SCITT Architecture leverages <xref target="STD96"/> for Statements and Receipts, it benefits from the format's cryptographic agility.</t>
      </section>
      <section anchor="sec-threat-model">
        <name>Threat Model</name>
        <t>This section provides a generic threat model for SCITT, describing its residual security properties when some of its actors (Issuers, Transparency Services, and Auditors) are either corrupt or compromised.</t>
        <t>SCITT primarily supports checking of Signed Statement authenticity, both from the Issuer (authentication) and from the Transparency Service (transparency).
Issuers and Transparency Services can both be compromised.</t>
        <t>The SCITT Architecture does not require trust in a single centralized Transparency Service.
Different actors may rely on different Transparency Services, each registering a subset of Signed Statements subject to their own policy.
Running multiple, independent Transparency Services provides different organizations to represent consistent or divergent opinions.
It is the role of the relying party to decide which Transparency Services and Issuers they choose to trust for their scenario.</t>
        <t>In both cases, the SCITT architecture provides generic, universally-verifiable universally verifiable cryptographic proofs to hold Issuers or Transparency Services accountable.
On one hand, this enables valid actors to detect and disambiguate malicious actors who employ Equivocation with Signed Statements to different entities.
On the other hand, their liability and the resulting damage to their reputation are application specific, specific and out of scope of the SCITT architecture.</t>
        <t>Relying Parties and Auditors need not be trusted by other actors.
So long as actors maintain proper control of their signing keys and identity infrastructure they cannot "frame" an Issuer or a Transparency Service for Signed Statements they did not issue or register.</t>
      </section>
    </section>

<!--[rfced] FYI - the RPC will communicate any changes to Sections
     10.1 and 10.2 to IANA for them to update the following registries
     respectively to exactly match the document once AUTH48 completes.
     https://www.iana.org/assignments/media-types/application/scitt-statement+cose

https://www.iana.org/assignments/media-types/application/scitt-receipt+cose,

-->

    <section anchor="sec-iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to register:</t>
      <ul spacing="normal">
        <li>the media type application/scitt-statement+cose in has registered the "Media Types" registry, see below.</li>
        <li>the following media type application/scitt-receipt+cose types in the "Media Types" registry, see below.</li>
      </ul>
      <section anchor="sec-media-type-applicationscitt-statementcose-registration">
        <name>Media Type application/scitt-statement+cose Registration</name>
        <t>IANA is requested to add the following Media-Type to "application" subregistry of the "Media Types" registry group <xref target="IANA.media-types"/>:</t>
      <ul spacing="normal">
        <li>application/scitt-statement+cose (see <xref target="IANA.media-types"/>.</t> target="sec-media-type-applicationscitt-statementcose-registration"/>)</li>
        <li>application/scitt-receipt+cose (see <xref target="sec-media-type-applicationscitt-receiptcose-registration"/>)</li>
      </ul>
      <section anchor="sec-media-type-applicationscitt-statementcose-registration">
        <name>Registration of application/scitt-statement+cose</name>

        <table anchor="new-media-types-scitt-statement">
          <name>SCITT Signed Statement Media Type Registration</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Template</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">scitt-statement+cose</td>
              <td align="left">application/scitt-statement+cose</td>
              <td align="left">
                <xref target="signed-statements"/> of RFCthis</td> RFC 9943</td>
            </tr>
          </tbody>
        </table>
        <dl spacing="compact">
        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>Subtype name:</dt>
          <dd>
            <t>statement+cose</t>
          </dd>
          <dt>Required parameters:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Optional parameters:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>binary (CBOR data item)</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t><xref target="MediaTypeSecConSec"/> of RFCthis</t> RFC 9943</t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>none</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t>RFCthis</t>
            <t>RFC 9943</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>Used to provide an identifiable and non-repudiable Statement about an Artifact signed by an Issuer.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Additional information:</dt>
          <dd>
            <dl>
          <dd><t><br/></t>
            <dl spacing="compact">
              <dt>Deprecated alias names for this type:</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>Magic number(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>File extension(s):</dt>
              <dd>
                <t>.scitt</t>
              </dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
            </dl>
          </dd>
          <dt>Person and &amp; email address to contact for further information:</dt>
          <dd>
            <t>iesg@ietf.org</t>
            iesg@ietf.org
          </dd>
          <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>Restrictions on usage:</dt>
          <dd>
            <t>none</t>
          </dd>
          <dt>Author/Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="sec-media-type-applicationscitt-receiptcose-registration">
        <name>Media Type
        <name>Registration of application/scitt-receipt+cose Registration</name>
        <table anchor="new-media-types-receipt">
          <name>SCITT Receipt Media Type Registration</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Template</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">scitt-receipt+cose</td>
              <td align="left">application/scitt-receipt+cose</td>
              <td align="left">
                <xref target="Receipt"/> of RFCthis</td> RFC 9943</td>
            </tr>
          </tbody>
        </table>
        <dl spacing="compact">
        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>Subtype name:</dt>
          <dd>
            <t>receipt+cose</t>
          </dd>
          <dt>Required parameters:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Optional parameters:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>binary (CBOR data item)</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t><xref target="MediaTypeSecConSec"/> of RFCthis</t> RFC 9943</t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>none</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t>RFCthis</t>
            <t>RFC 9943</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>Used to establish or verify transparency over Statements. Typically emitted by a Transparency Service, Service for the benefit of Relying Parties wanting to ensure Non-equivocation over all or part of a Statement Sequence.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>n/a</t>
            <t>N/A</t>
          </dd>
          <dt>Additional information:</dt>
          <dd>
            <dl>
          <dd><t><br/></t>
            <dl spacing="compact">
              <dt>Deprecated alias names for this type:</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>Magic number(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>File extension(s):</dt>
              <dd>
                <t>.receipt</t>
              </dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
            </dl>
          </dd>
          <dt>Person and &amp; email address to contact for further information:</dt>
          <dd>
            <t>iesg@ietf.org</t>
            iesg@ietf.org
          </dd>
          <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>Restrictions on usage:</dt>
          <dd>
            <t>none</t>
          </dd>
          <dt>Author/Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="sec-coap-content-format-registrations">
        <name>CoAP Content-Format Registrations</name>
        <t>IANA is requested to register has registered the following Content-Format numbers in the "CoAP Content-Formats" sub-registry, subregistry within the "Constrained RESTful Environments (CoRE) Parameters" Registry registry group <xref target="IANA.core-parameters"/> in the 256-9999 Range:</t> range:</t>
        <table anchor="new-content-formats">
          <name>SCITT Content-Formats Registration</name>
          <thead>
            <tr>
              <th align="left">Content-Type</th> align="left">Content Type</th>
              <th align="left">Content Coding</th>
              <th align="left">ID</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">application/scitt-statement+cose</td>
              <td align="left">-</td>
              <td align="left">277</td>
              <td align="left">RFCthis</td> align="left">RFC 9943</td>
            </tr>
            <tr>
              <td align="left">application/scitt-receipt+cose</td>
              <td align="left">-</td>
              <td align="left">278</td>
              <td align="left">RFCthis</td> align="left">RFC 9943</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>

    <displayreference target="RFC9393" to="CoSWID"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <seriesInfo name="DOI" value="10.17487/RFC6838"/>
            <seriesInfo name="RFC" value="6838"/>
            <seriesInfo name="BCP" value="13"/>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8392">
          <front>
            <title>CBOR Web Token (CWT)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8392"/>
            <seriesInfo name="RFC" value="8392"/>
            <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 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>
        </reference>
        <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>
            <seriesInfo name="DOI" value="10.17487/RFC8610"/>
            <seriesInfo name="RFC" value="8610"/>
            <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>
        </reference>
        <reference anchor="STD94">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8949"/>
            <seriesInfo name="RFC" value="8949"/>
            <seriesInfo name="STD" value="94"/>
            <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>
        </reference>
        <reference anchor="STD96">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <seriesInfo name="DOI" value="10.17487/RFC9052"/>
            <seriesInfo name="RFC" value="9052"/>
            <seriesInfo name="STD" value="96"/>
            <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
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.94.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.96.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9360.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9597.xml"/>
<!-- [RFC9942]
draft-ietf-cose-merkle-tree-proofs-18
companion doc RFC 8152.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC9360">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates</title>
            <seriesInfo name="DOI" value="10.17487/RFC9360"/>
            <seriesInfo name="RFC" value="9360"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="February" year="2023"/>
            <abstract>
              <t>The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.</t>
            </abstract>
          </front>
        </reference> 9942
-->
<reference anchor="RFC9597"> anchor="RFC9942" target="https://www.rfc-editor.org/info/rfc9942">
  <front>
    <title>CBOR Web Token (CWT) Claims in COSE Headers</title>
            <seriesInfo name="DOI" value="10.17487/RFC9597"/>
            <seriesInfo name="RFC" value="9597"/>
            <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>
        </reference>
        <reference anchor="I-D.draft-ietf-cose-merkle-tree-proofs">
          <front>
            <title>COSE (CBOR Object Signing and Encryption) Receipts</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-cose-merkle-tree-proofs-17"/>
    <author fullname="Orie Steele" initials="O." surname="Steele"> surname="Steele" fullname="Orie Steele">
      <organization>Tradeverifyd</organization>
    </author>
    <author fullname="Henk Birkholz" initials="H." surname="Birkholz"> surname="Birkholz" fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
    </author>
    <author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud"> surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
      <organization>Microsoft</organization>
    </author>
    <author fullname="Cedric Fournet" initials="C." surname="Fournet"> surname="Fournet" fullname="Cedric Fournet">
      <organization>Microsoft</organization>
    </author>
    <date day="10" month="September" year="2025"/>
            <abstract>
              <t>   COSE (CBOR Object Signing and Encryption) Receipts prove properties
   of a verifiable data structure to a verifier.  Verifiable data
   structures and associated proof types enable security properties,
   such as minimal disclosure, transparency and non-equivocation.
   Transparency helps maintain trust over time, and has been applied to
   certificates, end to end encrypted messaging systems, and supply
   chain security.  This specification enables concise transparency
   oriented systems, by building on CBOR (Concise Binary Object
   Representation) and COSE.  The extensibility of the approach is
   demonstrated by providing CBOR encodings for Merkle inclusion and
   consistency proofs.

              </t>
            </abstract> month='March' year='2026'/>
  </front>
  <seriesInfo name="RFC" value="9942"/>
  <seriesInfo name="DOI" value="10.17487/RFC9942"/>
</reference>

        <reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cwt">
          <front>
            <title>CBOR Web Token (CWT) Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </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="IANA.media-types" target="https://www.iana.org/assignments/media-types">
          <front>
            <title>Media Types</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="NIST.SP.1800-19" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-19.pdf">
          <front>
            <title>Trusted cloud :security practice guide cloud: Security Practice Guide for VMware hybrid cloud infrastructure Hybrid Cloud Infrastructure as a service Service (IaaS) environments</title>
            <seriesInfo name="DOI" value="10.6028/NIST.SP.1800-19"/>
            <seriesInfo name="NIST Special Publications (General)" value="1800-19"/> Environments</title>
            <author fullname="Michael Bartock" surname="Bartock">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Donna Dodson" surname="Dodson">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Murugiah Souppaya" surname="Souppaya">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Daniel Carroll" surname="Carroll">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Robert Masten" surname="Masten">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Gina Scinta" surname="Scinta">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Paul Massis" surname="Massis">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Hemma Prafullchandra" surname="Prafullchandra">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Jason Malnar" surname="Malnar">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Harmeet Singh" surname="Singh">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Rajeev Ghandi" surname="Ghandi">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Laura E Storey" surname="Storey">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Raghuram Yeluri" surname="Yeluri">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Tim Shea" surname="Shea">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Michael Dalton" surname="Dalton">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Rocky Weber" surname="Weber">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Karen Scarfone" surname="Scarfone">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Anthony Dukes" surname="Dukes">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Jeff Haskins" surname="Haskins">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Carlos Phoenix" surname="Phoenix">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author fullname="Brenda Swarts" surname="Swarts">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author>
              <organization>National Institute of Standards and Technology (U.S.)</organization>
              <address>
                <postal>
                  <country>US</country>
                  <city>Gaithersburg</city>
                </postal>
              </address>
            </author>
            <date day="20" month="April" year="2022"/>
            <abstract>
              <t>A cloud workload is an abstraction of the actual instance of a functional application that is virtualized or containerized to include compute, storage, and network resources. Organizations need to be able to monitor, track, apply, and enforce their security and privacy policies on their cloud workloads, based on business requirements, in a consistent, repeatable, and automated way. The goal of this project is to develop a trusted cloud solution that will demonstrate how trusted compute pools leveraging hardware roots of trust can provide the necessary security capabilities. These capabilities not only provide assurance that cloud workloads are running on trusted hardware and in a trusted geolocation or logical boundary, but also improve the protections for the data in the workloads and in the data flows between workloads. The example solution leverages modern commercial off-the-shelf technology and cloud services to address lifting and shifting a typical multi-tier application between an organization-controlled private cloud and a hybrid/public cloud over the internet.</t>
            </abstract>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.1800-19"/>
          <seriesInfo name="NIST SP" value="1800-19"/>
        </reference>
        <reference anchor="NIST.SP.800-204C" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204C.pdf">
          <front>
            <title>Implementation of DevSecOps for a microservices-based application Microservices-based Application with service mesh</title> Service Mesh</title>
            <seriesInfo name="DOI" value="10.6028/NIST.SP.800-204C"/>
            <seriesInfo name="NIST Special Publications (General)" value="800-204C"/>
            <author fullname="Ramaswamy Chandramouli" surname="Chandramouli">
              <organization>Information Technology Laboratory</organization>
            </author>
            <author>
              <organization>National Institute of Standards and Technology (U.S.)</organization>
              <address>
                <postal>
                  <country>US</country>
                  <city>Gaithersburg</city>
                </postal>
              </address>
            </author>
            <date day="8" month="March" year="2022"/>
            <abstract>
              <t>Cloud-native applications have evolved into a standardized architecture consisting of multiple loosely coupled components called microservices (often typically implemented as containers) that are supported by an infrastructure for providing application services, such as service mesh. Both of these components are usually hosted on a container orchestration and resource management platform. In this architecture, the entire set of source code involved in the application environment can be divided into five code types: 1) application code (which embodies the application logic), 2) application services code (for services such as session establishment, network connection, etc.), 3) infrastructure as code (for provisioning and configuring computing, networking, and storage resources), 4) policy as code (for defining runtime policies such as zero trust expressed as a declarative code), 5) and observability as code (for the continuous monitoring of an application runtime state). Due to security, business competitiveness, and the inherent structure of loosely coupled application components, this class of applications needs a different development, deployment, and runtime paradigm. DevSecOps (consisting of acronyms for Development, Security, and Operations, respectively) has been found to be a facilitating paradigm for these applications with primitives such as continuous integration, continuous delivery, and continuous deployment (CI/CD) pipelines. These pipelines are workflows for taking the developer s source code through various stages, such as building, testing, packaging, deployment, and operations supported by automated tools with feedback mechanisms. The objective of this document is to provide guidance for the implementation of DevSecOps primitives for cloud-native applications with the architecture and code types described above. The benefits of this approach for high security assurance and for enabling continuous authority to operate (C-ATO) are also discussed.</t>
            </abstract>
          </front>
          <seriesInfo name="NIST SP" value="800-204C"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-204C"/>
        </reference>
        <reference anchor="NIST_EO14028" target="https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-section-4e.pdf">
          <front>
            <title>Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date year="2022" month="February" day="04"/>
          </front>
        </reference>
        <reference anchor="RFC4949">
          <front>
            <title>Internet Security Glossary, Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC4949"/>
            <seriesInfo name="RFC" value="4949"/>
            <seriesInfo name="FYI" value="36"/>
            <author fullname="R. Shirey" initials="R." surname="Shirey"/>
            <date month="August" year="2007"/>
            <abstract>
              <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8725">
          <front>
            <title>JSON Web Token Best Current Practices</title>
            <seriesInfo name="DOI" value="10.17487/RFC8725"/>
            <seriesInfo name="RFC" value="8725"/>
            <seriesInfo name="BCP" value="225"/>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC9162">
          <front>
            <title>Certificate Transparency Version 2.0</title>
            <seriesInfo name="DOI" value="10.17487/RFC9162"/>
            <seriesInfo name="RFC" value="9162"/>
            <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>
        </reference>
        <reference anchor="CoSWID">
          <front>
            <title>Concise Software Identification Tags</title>
            <seriesInfo name="DOI" value="10.17487/RFC9393"/>
            <seriesInfo name="RFC" value="9393"/>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="J. Fitzgerald-McKay" initials="J." surname="Fitzgerald-McKay"/>
            <author fullname="C. Schmidt" initials="C." surname="Schmidt"/>
            <author fullname="D. Waltermire" initials="D." surname="Waltermire"/>
            <date month="June" year="2023"/>
            <abstract>
              <t>ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format.</t>
            </abstract>
          </front>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.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.9393.xml"/>
        <reference anchor="CycloneDX" target="https://cyclonedx.org/specification/overview/">
          <front>
            <title>CycloneDX</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="in-toto" target="https://in-toto.io/">
          <front>
            <title>in-toto</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="SLSA" target="https://slsa.dev/">
          <front>
            <title>SLSA</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
<!-- [rfced] The reference entries for [SPDX-CBOR] and
     [SPDX-JSON] are identical. Should these references be condensed
     down into one reference? Or are these references meant to point
     to specific parts of the SPDX Specification?

Current:

   [SPDX-CBOR] "SPDX Specification",
   <https://spdx.dev/use/specifications/>.

   [SPDX-JSON] "SPDX Specification",
   <https://spdx.dev/use/specifications/>.

-->
        <reference anchor="SPDX-CBOR" target="https://spdx.dev/use/specifications/">
          <front>
            <title>SPDX Specification</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="SPDX-JSON" target="https://spdx.dev/use/specifications/">
          <front>
            <title>SPDX Specification</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="SWID" target="https://csrc.nist.gov/Projects/Software-Identification-SWID/guidelines">
          <front>
            <title>SWID Specification</title>
            <author>
              <organization/>
              <organization>NIST</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="EQUIVOCATION" target="https://www.read.seas.harvard.edu/~kohler/class/08w-dsi/chun07attested.pdf">
          <front>
            <title>Attested Append-Only Memory: Making Adversaries Stick to their Word</title>
            <author fullname="Byung-Gon Chun"/>
            <author fullname="Petros Maniatis"/>
            <author fullname="Scott Shenker"/>
            <author fullname="John Kubiatowicz"/>
            <date day="14" month="October" year="2007"/>
          </front>
          <refcontent>ACM SIGOPS Operating Systems Review, vol. 41, no. 6, pp. 189-204</refcontent>
          <seriesInfo name="DOI" value="10.1145/1323293.1294280"/>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact 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>
      </contact>
      <t>Orie contributed to improving the generalization of COSE building blocks and document consistency.</t>
      <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>
      <t>Amaury contributed elemental parts to finalize normative language on registration behavior and the single-issuer design, as well as overall document consistency</t>
      <contact initials="D." surname="Brooks" fullname="Dick Brooks">
        <organization>Business Cyber Guardian (TM)</organization> Guardian</organization>
        <address>
          <postal>
            <country>United States</country> States of America</country>
          </postal>
          <email>dick@businesscyberguardian.com</email>
        </address>
      </contact>
      <t>Dick contributed to the software supply chain use cases.</t>
      <contact initials="B." surname="Knight" fullname="Brian Knight">
        <organization>Microsoft</organization>
        <address>
          <postal>
            <country>United States</country> States of America</country>
          </postal>
          <email>brianknight@microsoft.com</email>
        </address>
      </contact>
      <t>Brian contributed to the software supply chain use cases.</t>
      <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>
      <t>Robert contributed to the software supply chain use cases.</t>
    </section>
  </back>

<!--[rfced] We had the following questions/comments related to
     abbreviation use 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) FYI - We have updated 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.  Please let
us know any objections.

c) Does TS refer to Transparency Service, Transparent Statement, or
something else?  After first use, we suggest using TS as described in
(b) above.

d) This document uses both:

verifiable data structure proofs and Verifiable Data Structure Proofs

We will capitalize on first use and introduce the VDP abbreviation as
was used in draft-ietf-cose-merkle-tree-proofs-18 for use thereafter
unless we hear objection.

e) As one of the T's in SCITT stands for transparency, is "SCITT
transparency" redundant?

Original:
This "content-agnostic" approach allows SCITT transparency services...

-->

<!--[rfced] We had the following questions related to terminology use
     throughout the document (see also our cluster-wide terminology
     questions that impact terms used in both documents in C557):

a) As the large majority of instances appear as shown on the right,
we will update to use that form consistently throughout the body of
the text unless we hear objection:

SCITT Architecture vs. SCITT architecture
x.509 vs. X.509

b) Should the following terms be made consistent throughout?  If so,
please let us know the preferred form:

Mandatory Registration Checks vs. mandatory Registration checks

c) We see that this document uses the term "proof type".  This term is
defined in draft-ietf-cose-merkle-tree-proofs-18.  Should there be any
type of citation pointing the reader to the Terminology section of
that document for more information?

d) Most instances of "iss" refer to it as a Claim.  Should these
sentences be updated as follow?

Original:
When x5t or x5chain is present in the protected header, iss MUST be a
string that meets URI requirements defined in [RFC8392].  The iss
value's length MUST be between 1 and 8192 characters in length.

Perhaps:
When x5t or x5chain is present in the protected header, the iss Claim
MUST be a string that meets URI requirements defined in [RFC8392].
The iss Claim value's length MUST be between 1 and 8192 characters in
length.

e) We note that Section 2.2.3 uses both "integrated software" and
"Software Integration".  Please review if these should be made
consistent and if capitalization is necessary.

f) We see the following various treatment for media type names (with
respect to quotation marks, parentheses, word ordering, etc.):

('content type') media type
(scitt-receipt+cose) media type
media type application/scitt-receipt+cose
media type application/scitt-statement+cose

May we make these consistent?

g) Should the iss Claims mentioned in the first sentence below be in
quotation marks to match the quotations used for the sub Claim in the
second sentence below?

Original:
Multi-tenant support can be enabled through the use of identifiers in
the iss Claim, for example, ts.example. may have a distinct Issuer
identity for each sub domain, such as tenant1.ts.example. and
tenant2.ts.example..

Original:
It indicates the Signed Statement is securing a JSON content type, and
identifying the content with the sub Claim "vendor.product.example".
-->

<!-- [rfced] See a list below of terms enclosed in <tt> in this document.  We
note that some of the terms enclosed in <tt> appear elsewhere in the
document without <tt> (e.g., payload, receipts).

<tt>-111</tt>
<tt>15: CWT Claims</tt>
<tt>15</tt>
<tt>-1</tt>
<tt>1</tt>
<tt>-2</tt>
<tt>3</tt>
<tt>8</tt>
<tt>CWT Claims</tt>
<tt>iss</tt> Claim
<tt>Issuer Claim</tt>
<tt>kid</tt>
<tt>payload</tt>
<tt>receipts</tt>
<tt>Subject Claim</tt>
<tt>sub</tt> CWT Claim
<tt>tenant1.ts.example.</tt>
<tt>tenant2.ts.example.</tt>
<tt>ts.example.</tt>
<tt>x5chain</tt>
<tt>x5t</tt>

Please review to ensure the usage of <tt> is correct and consistent.
Let us know if any updates are needed.

-->

<!-- ##markdown-source:
H4sIACi46GgAA+19a3fb2JHgd/4KjHzOWGqTlCW/lUmmZUlOK7FbXkmdx0l6
2yABkohBgAOAktm281vmt+wv23reB3BB2T3J7Nk9q5O4JTwu7q1bVbfeNRqN
BjdH0aPBoMmaPD2KjovouJousiadNusqjWZlFV1X67q5LatmsYniIoG/46Je
xVVaNNFpNs+aOI+u1qtVvolOFnFW1IN4MqlSGPfq5Pz62htwkJTTIl7Cl5Iq
njWjLG1mo3qaNc0odh4bHR4OBvCFGMZIp+sqazaD27kMOHh/exSdF01aFWkz
OsVxBtO4OYrqJhlMy6JOi3pdH0WbtB7U68kyq+usLJrNCr56fnb9ajB4X8XL
pLwtfipXDdyqjwZRFK+b8qcs+WlVpbPsAwyWTkeDwU1arFO8Pa/K9UonEEXL
OMvhGZz4t7iGcVnN8amsWawnRxEt63bOK9vfulRY57pZlNXRYBQxZL5Li/fR
y6x6vyjzn2FQGPooelXF62JRztIqujrHGSiMOzdSntsCRhlPZJRv66wZz8yT
4ySFB+umSlMA2+UihU1rqriu0+jZE7gzLROYx/2njw9fPLmPfwP8j6LTuFrW
TZw09MS6aCq4+Nu0WsbFxkz+uGjKrEij0zTP5kXcjF7HN/E64WXERfZzjBA/
it5k06qsy1kTXaZ1igBxZnR4EF019GB0WcaJndHJy4Po8NVLO6eTeDmpsmSe
2oXHRZPk3y51/PG0XLoT/uH3Zq4naVJl0+hVuUZM+m+c4oy/+EWT/HM5T+sF
wLNerID60s40jy/fOPM6OHgYvVrnE/xCYGYvvv/d1plt6GuAH/K1b2HPg5MD
jAFqGEev4/p9WsFtnu1Vk96k9qKMWuPVIqer3y7KBq/SqEiuTZVNgPaIAGjU
izEOk+apGfWiylJ7zV8+cKMERq+y2SaxXyzhjW/L6uDROCu9uRdAdwltHXAH
vCHfp7F+A1ci/pq5AU83ZZQtV1V5kxXzqFmk0Twt0irOZQ5ROYtOLq7Oosk6
yxN8ZpKX0/c1MUvgd+slckpkTBkAophuxrrS4zFyzGW8KddmrcfLeF1t3Os9
WOlgPL0ynsorW9CKV/97mGMid7rLlwm4AAC44xqAzwPbb2oEyCwrEABpVJTA
AJoMdj2Pi/k6nqcRgKRK5xmyFILPJF3ENxmcJAgQhF8NE8jTETDmNbAtQDZg
FcMorqPbNM/xv+UNwjcPQk+BdzqOXlZl+b42oDvNpu/tNR9sL9fw0bSuo5PN
BL7523VcJVlcRLvXb/YsJBMY4duJPDrFJ+fyYA8otyISzaeFSLR82JpbON2i
mk/NKZ6a0Rq47zSu09qgx8tx9Psimy8as8KXFc7ZXLwTMyb4/Ht6/E6s2LoU
/vB/YS2XY8T2N4A+WWGWc1kChBt7tbWe8+vLs+ikrFYlI5JdF5zf9A4sCvie
HL5ftSD59C9Z0cCgPAoGl69Onj5/9Fx+ff7oxaH++vTgIfDY09PX8PfV9emL
x0f05RFcfHlxSb//+oiefPH4hTzz1D4DHMV55sXDJ4c87otHTx/KJ148efEM
nvzj9U8nr4/P31z9JC+dj07HjtAxLet0tEyr90BzeEyMgJeVM9yUs5Oz87fX
V/jK8ffH4+ltczQYZMXMLhBufX9+dT2+ejs+eP7w4ejgxZFzCa8cPnx8otd+
Ors4ePzw8DmvoomrOZ5Ji6ZZ1Uf7+7e3t+MCqHg8L2/26w2Q83J/luVpva90
Xu8fPjw83H8I/3u8rxsx4o0Y0UaMapEHR/N1lsTFNB2t4ZyqRmcXI/o0PoAb
PXqcjlfJjCfCwu2V7qwrrRoBE3gCDwj4AwNGZx/gBjG2iwr/3j272IvoE/gK
MbbHKQ2fAJ6BRAAzHz2E/z3mzXkMuwryUV7WdVxtBCeeHT7RvTt4egh7d40Q
Pimv/nh+yvv86MUjurSZ5mWRnv4pDMop304+IO7v16t0ms2yKVHJPjLPmyy9
3XfXbsbDwQGMTdmU4aHlJhyc3gByGV+/en11HH63zusYhIcb7018nF57e/qn
EaJ+z7srWA2+C6Tmr6j2h4Nhoiv3vhn8d1cX3/9TBsfdCe9DXU0tTr+tyr8B
atT7immj8wSw2ow1woH2EXFBOi6IN9kvw63ul8/+xw/nf7g4Ob4+71sZEhUo
SskYRNR6vIirGziwxmmy3v/7+3KRp9X+FASvev/h89tRUmf708W6ePgsboA1
AtNrk8jOsdyIjlertEhGFwUQypt0WSJjfRO/R/HmOAEMA6TO0hqYLB5yzDqz
KvpjWSU7NGCd4n3kJTxvOA4vzkE+fTg+OHj8ZP/g0eGjwxePxgeHLx4fPn84
GCCcQChFaJ+9fgUzAWJoFlm9MxiMRiNQd1CcmDaDAQh80zSeZDnSLNCvy6br
KAOxC5W1W5yo8gpk81NQF8eDPy6A30QkLmbxBH4F2o1ReF6TMlZHIKmkUZwk
8HsNUFBUiUhWqYfwtekCJZT0P9bZTTkVAfAGxRhRheFDsuP4PIBlA5IRwCiO
1kVGgAMRp61jo7DjLWQ8uIbFWwEoAa0UMEa+X3RH8GUqlKhw+ngE0vuNUdpR
/jxvIlSSccHpB5Cq6ozhOQSAgl5drkD8EghP0uY2TQtY3gw0x/ZQuM032RRX
isIdSBarPCMmeguqcAS4mJVr2JJ1kjW4I3DyTAE38cP4PIiJ6zwG4X8DvwJE
K5osnrG458ssSUDiH9xDbb8qk/WUySIMmRZQYELRBA5smGGDErquE/Z8CXuL
cqrddp49kEk5zWLE/lle3pKcu4zfpwpNFBZ8ADTRTRZvQycQV0BuzvDtCaJh
BRdXZUFaQhCOuO+gYJSAJDBplEe8x9ICP0OD4T3vIEOTyLyiXbx23hmK0WZd
N9Eu2S/2fOzJaKFpsaB9o63SzSeoTEmw0ku9uKbQ2TVIV+/BJOMmwiM3Bo20
8UUqQJZliXgBcNpFcW4G9F3vweZfkvYAUEUabmFyzZgVB8FH5A88ChcUg2oC
zFKVNIN548F1CPA4/1lWLeG9VZlncAfGWgLuTFJYcgr4CbuXqAZoCQuGxguw
KfO04t1jsxdfgfdWsOc08ThCrh+zHpQBKiADQawBfCYagB131rkExXY8uMBN
YaWpRdIwv0oAlSbDLq5YmCDrgq/DEtJs1QCAr7JlluNEVgCWeLpQxjdBSgdd
l/U9pAPcbeWBdJDAozBNs12WI55YvufhX/Tx4+jk+vNnFzb6XRg/J0qLoyUC
mRRr+BK8GgM/XSL+4NalN8xGzHSFPe4I0o3ieVHWcBTt2KFjHpk/GKQ1xJJJ
GqWAT7BRGZEPUT8gUPoBAEv4V+akOMCyK3kBppSBipGJPozwKNJb0E1AXaRX
SLSFOZ65vJWPphs6I2ZpTKQnJC5A8bhXXTLxuHwxmlXl0jJVoCUVYkA3KWhq
U6YqWsYtHXZxfhtvaub3OLsOhyd6Qr4En8YVerp7i2H7HOwOXjEevCJmgWfC
lPgS4fEUPs4rd9k4/J4DVooiZtQttOQAUGPaC1p+v46WlMhuhxGoc/yUK03J
OZHQNjDkkPSQURRAeYQCaCMmInRHdShyN85rhA8chBXPE/D+Js7X6QhEBhA7
4tWi3hsS1aQfYqSjofs+M0GQ0ZLO5PHM8881+pYebt0jSxhxmzmSicU5n+yt
IeID0EW6nMArZLAShlAjiaou+PkzCAHjdDzUwXtPt4jVyD0i7Dp0rBLnx0M4
UTZ5AoJYBs++hC0FhncxQXk5ulQeyTsFinuRAJCIc4C+8PlzAPdwdoTOAIl4
ivhGOI/nMX0I3tPhr+RRHOSsmFabVfczAA5lUT3rUPxB69DcW8wpguUUb2c0
8Gs1hOHAoP/rwOHdMptggSXECNIioIdCDmb4E67koIXXgKIfPxqNdHyICCzr
ofHh6pbN5pk5rGTEVGQ4alQYVuVMgU6wpiU9wjyrcj1f8Pe+A6UEaOotsHI4
RkHupQXCRhNHq4HSGYfNcaNgdRiUI6zl8YZshULEhc8+gHrOURVYLgGthnzP
BxMSW4nGywqASqIonmHIYCYooIlwSmwJuG5A6kiNEAA3CB8X6fS9nJGs/QAr
yBLihcyAmmyZsgYgb+tpPR58V97inTr10AEeWsYFLDfB0waFAjzZF/AszXaa
rZgRkrKEk08yYKeofeCEQN7JZiAj4unHDA2WA9ylmKekGAHzGZXogwoxYIDg
vXtAic5p833ZxCpxp9F7XAasHk7dNz9cXe8M+b/R9xf0+yWqqpdnp/j71XfH
r1+bXwbyxNV3Fz+8PrW/2TdPLt68Ofv+lF+Gq5F3abDz5vjPOyzG7ly8RVX4
+PVOBwUIenxAEwYBpiFDiOtBktbTKpsw2rw8efu//vPgMVDBv4CGeXhw8ALo
hP94fvDsMfxxu0iLoZAO0B//ibs4ADJB8Q1GQX1tGq/wMK/Jcl3DJhURwBxE
tsE3f0HI/HgU/dtkujp4/Bu5gAv2LirMvIsEs+6VzssMxMClwGcMNL3rLUj7
8z3+s/e3wt25+G//juJsNDp4/u+/GaCW1mNfQ3QDFCqjLM/XJFiwQKunMPOO
XlHI8BrhBLWSt7C8JAX6zWt6O/2QAjeJxX0BzIlO86CwsHt1dbLnmnURx9se
HHL6JI6+FZhdhT4QlNNgadlU5Jc7jchXoQdqEk1TxKcYH56tc5c1R2ryJJCA
sgIa3ZqPqikohiAVMhH/VqRoWGH0tiqBiy7ZGI5kAsK/J92oiYSkU5c74zJg
/bhOhAh6YIDOKj60lsAxl9nPxIvgTrnMpsNotZ7AVIEI4rxZMAXV8SzlgwEk
Xlx28NsLWDDrQLDSPEclc7oWqaHK6vfCFInKV2gFUukdhycPTZSXyFuzKWDH
Mk2bPssCyWYp7AHaDWDURAgdJIIlerOy4gYeg7fUVMQ8WhxgzKFnIOImtCEg
yZOiySveeHs5ZDXB6BTkTbLWaz7o4ZDTk14JIIg5eGot6b8TUG4SuIxGbzoK
x6Atw+43uYjX87ycoBUK1IB1ocBNP6zQHAeoA6cE7iLqDx5qxk0TI8azeRH3
9TaN36MbDM+Oomda48Fx7ZB1wsJIns1SNFCnI9l3lCnjHprgD8MOb0BjRrcf
ORBTPP9IJcTBRjQanpRz0UMS2NBpg9IRsmPzF8+e4ICmKBiHDra///3vURzX
N3O1RKZo2wRw4BEqP29iVFIQLo+qZITH7QYO3el7mk+FUnDNLijz8ynwx4MR
/si/fOlT9ym8dFImqXf7pEQf8xIFyrpcV1PxQZd57zCBj33VZLpLX+Xr+Qgj
ePQBmBToZOGHp3Tvnz+7MkGphlgzbHD9njVx5dYgC91kVVkQbzNvvqRbzihv
y6wWSZpfg30tmn3EEiDzasv3r0GPA1GKtGR+dYomiH/sIp3NR/s7sJUyr53n
r/Gi8/wrkDusbIusAx+AM2idN/U/fUt+qFFTSZQ+7AffCsEEF6bUVKWrEg6Y
kpxi/9yJCu6AyJ+iKZiwxzx+KVd7UC0BHQROm4zNPjLEP23G5hLwprzcRD0I
KGxItdn1Ci09bKSp79r3kXwcuOHg41F0r8Om2Qn0650zNl2Q/PAa2e8Jsd9r
fmrn82Bwmt6AxnmxYtnXUco+fmy7hpH3A+NHDwJx3ZoV2swwWT5/02IkXE+P
CTUrJC6zFjMXHOgNs/g8/aBqZ6lmH+8UrktW1ETBg+PdSFCN60nyBwFlzoAH
RSP0fmRTIC6aFRvN46hIRf1j+YT01bvs50Cr6ilasU8DZc/NiiUfPsMrVNmI
qjcrtrd2jEjtMaJdCa7JKg9iezjTG5B3QI1ELbxEEytwb/HXxOrYMX4eKziI
Gdx3zFyzC5C0W7SWkZBnLEJoGUZP1p2zBcGoVMiAMDlfNCREw9YCbyAvDVpP
CQ3b60dJISum+TpJ5QgibT0WR07nUKAprowVYmjlENgR8rIsY/Q1kCaH3wER
lkSMTREv8XdHADcSK7JbhINwXBAr1z//3L2qjIeM0jf0hYTomybG1gS4drPO
C2uPrXFXzBA8+wZUehBxYQPOKQynhk1BcQ4ddnWTAi9GbKnIsIHmU4xgqBtC
P1yKKMC0bawvoXFjA1j5gXcQZWGUnslTBkxmY22hxt8Q3sphn2LEMjyRu7E9
O4Ot4TX8JNmFbzK1Ie03HdcVCtHIN1gfQX0MQZQztU2R8WVqbxYWxUBjRQGm
Kg4QBCsZVUFTgj0hYzJgOo2O4ICBRynQAuInLJztfM6OTxdF9h84EIABHxZq
W5GtKpqgVlCzyRv3hLiMAssiKKHvDDYAl8Nhi7C9tTIdENQzAD5xdYyZhMtk
UXMcQADgJerDaT4zWgFzwgbNhWSDGg8uKpS49bP0Vflae1gT7oO2RLLD85rZ
tlqUt6zwAKgAm9kOjAZ2ZPkj0G2I87Mri4fAjSrJyA2S92tYGnK1W2KaZD9O
P7BJipF0JVovSZQaeQc4Os3wnBstid0MZWLZEk14cUFuikWZczQhYyJqpqRC
lbV8iFUz4C3oo1RbL3Ioh0N7TikXewXT0OqA083qZe3zOjZeGswmqyHOBh3G
PBWO60a7NKp3DgeTQ2yR5s7pkKdqw4M5J6Rz1AvyMqBdA+dCXvVFSrs0Adax
JM0MmAFsaIY0lSMfG7O1jh1rODPrSmnZX4wdUJZfYKAnEDk9ILKycciJGcHj
Bjcp2xvO4JBEUiOBAWXDE/wczwNFi/BsyCvMRlobSgsYAcBKrKfnSyZwz8Zw
HYNOvqkzhr81SL1lZjUYHCtLTuwxIJyMLKQkqJATbQWbzoafWEMImMooEhZo
tHPIoY3KsAvmCmijFVflHNaFXjiiO/I1846ixbIEyc5iMfs61NpiEKs7cTR0
qN0LrQh4T7+vCM/DIVGvs0Y9XrAJ6AReT/gYIQpdwnGTodRnhqgk6p3RGQFT
rdEQsFqQpSX2vhcr4ElzUfSp4dBV+DKpEbu1jCLKOEBqQ144M5pje0Dd2zke
MzZHEN2zPkGmf/LG4jJisZSvyb2tk0KKs19il2RqvkIGXQtWx3JwQaZ1NNNk
JR+x2ZIiSywaEqbGnkRr6czZPvsxMseUNQvMcXQbb9TTayMF0AENcoJsmScf
MBwVXTpmI8Vmw8DcydJ3JNCBMSfPChLoiF66IGiJJqSDBD832dAxS4qJuei/
jL6KvMSoI1IBK5bM6ETWEAWARwKyQOmSF+ISekAwGAe2ea7sqwWU44YtokPv
THDAUIi2FKB8dvk0KA6SyOIOn6chsOAJWC8y4OD8NC2A93MWww3Cfxg0KxYg
nJCjjLcTUX8MxyJwasIjtJ4aPa5vL0XcrfkFYTAkE0rMckxii7s0O9Wu01yB
A8IKRvEz2RAC60ScD2Jkg4qxuwpBUUP3dMYoQaRVjoI5TTAEMxaNyHQv4w2Z
8wWXrKkC21bGXllAEuFDqZrpze57rHSM7F//YoTv8tTbuKAEh6PBYBS9R+mH
RRcAtFgW69Tjso0bmuEzccsTkGvBt+JQmLndZNwF4C85641rUD8m2XyNgpHg
FEwpbiReHQdZcvhCS9LgsCx8VuPZ/JAl4XfLNEY7AvoYQPgHXCffuTnsMBVj
hAAojHbAS8Bwk0W2quEDJiuDTpAUVeRM/sAVLMqlqpukj6cYKUpiriv9w0FE
8ofPsOjwyn7GKBbkj85+EHFKCAybDFoaIjwI1IYBnIoMrtKvfgbRxb3XeIvo
MeSL5jOe5twBpJwmdo90pcL5LSdjmU1ODDF3cDSbbOCGjkTiJcKT1GszMvFp
fEMWrgpRbFSAnmAyB/tikkUKS0gsQ4GMtCzVnOjITieW6W2iNyolnIkHGmkq
QJq76Xg+HlLE26RCaQnF2RbG7w09uw88gep8WqE8OLTSWKaHu6VWFsooCBGU
3jXFKyvpoa5R0oE/XZSoC+CK0cew8E5Ckc8VCQnuDbkz5Iw0ixZJe20ObI0u
NlYa9rVbhVg2BcUmDivCIDbEBIllyjuTVvkqHSUYekUEPkSIGMslkQ0So7De
SCMVXD/HVblMna+rlQT0hbg2oWo8lA4ss95X4+wEtDJRRRS3HFmLsZXjJNoQ
NHExMLpEhhq0HsvUxF5sZuYBpXdzxJWIIyQlakgimLEwVvuLLsooL4s5wXSW
ViIex8BgSRgN4KrxtiSs2QLrGIlfIHjsTDB2KWMn7jI1pMhT86C29bscp6aQ
oONcnFuz7AOTNuKG+J6dk4RsruKXxJBDYj2N4pmNVzQHv4GwPfhP10QYakE1
WIeYJXsvzMD1v4mXWWw+duO6MGpACwbdeVNlMVlIl7/g9HWMWNnMF+x1u9kM
q9TkhgpayqrohMwxXZzPRxLS9TTBkemoupVTGTdTSA8tcBQMQMFqQ540QyaM
GWxKDUG++7BzTvScUZs+ofy+HnzRJObkC5Qw+Vt87OPZB3ILc5+SASRnBM+0
NPzKxufFEebE52WM1jAl+FztOkyCbKFHA3sGIsaXn9xiOmIlAHZCdtTZRhdc
wwCDdPdaixG4m6pDyYMFamHpHI6OpXhI6DZMBa3+HagD+S3kYC669MKnZgD/
vE20U2MjVuku0Xsy00h9sj6j08nE8aKIjBZQY5OTaFU99cx4bPdQ3DiXQAN4
/Ri2fznJWRNrW0A42ST6Q7rIppha0RlANPPYsAY0ot6I2onbpJ4KDJUoc7Rp
gFxMZGKFsjbCCkVYE4MgEJ+VMC/2Z7nhEop/bC6nOC5zgiUpxbXHvFAJMzbx
ttOY/DFrDE8HnaAyxOKMbqboxO4xSAzxojakoruocvJ6/wJbYika6y1UBaCU
joRWaqIXMU9SkAsKbKpYtE0eojRg3tgNBhA6XrLBibEVwQihRSJXJSpEcaxu
1EvjzF4MDy1DiHAIpBnUxNRR5hlt0PYLRwdm/bfGVDGXNTPSh8iRydmnhrHA
6E6EMYcUIzdiP454Nun1rmeHZWdNncpIJCCbWSnpTfCfhP/S1/9jHRvPnEL7
K/iYlbfxSxII6sZbz9DPBExA5H9JQphxBInnsbdMgMwgriglWnVoL2FMUpod
LbhIDC/HCJpcM1bIC5HnCmWdOjkI4K1CojsdaNspWQii2oG8CLgkxvhdp9Uy
K8q8nG+ij/ca+9dnsfemaFlqh+lqrB4lmYjJVxVQNec5EXtfmdYk2VswWRLS
PU+uH+HqR9hjZBRlvGABiRx0EZrwtKQ8H94nY/DCkOZhdHH8w/V39LXL4+ur
6I+/ZU2dbEYOYCgHoxCiBTEN8QFXSkVkamRlS0masd7OwR/RtK9aBkJiKGDx
csYIvMR7OPoUEXSMwZWyXZgKGmsyH8WvIiuvTBocD5AZEbyzR2N3H3cWFMSN
YbmreIOigcbhNuVoko7EJTXZADfb8aLkKRbAhNWbIaOdaR5nyx3yqbuPSu48
PSyppzT71+UcCO8IjzKjHlyJ85OIAFinOqSRfkyYtXBdR5TCR7zEpCvOAyLw
UZ4fPuF+XIz4G5dDtQh+2Dusyd1A2fKKAXXVjvVGVnITZ7la5o/RN1WyrUpS
rGT5q8WmJm8msJKiLEbmb/IH8gkFeMVFSmJUgZCNOaEQOCSPziMWHEUuxmcS
TmqLcdOmUL7r1N7Qo8MtAWXXNNTArCZ022zbkNVDEWjCO4J1qHiyIs3J8S4i
sTqNYJBLCed/i1I9noY5mqB0ia7znn2JGtOaJuFdA2JjcQHjHtK6YfaYLuJ8
pkhkHgFxWYyMxCdQCheV92cx9A7OCmYtNKFl2sTomhyKBGDiis9ZX2YPN4qc
iO8tlGG7v45H7JJ8v3RSJLKXMkMZj73n1r3LfirCckGuIWeUIlyC0Lh0aekt
BoSINEKniJoWu1M97lxjqZIyQ8wabiuMqEfWTR5mh8aHqHSZbEuFmx4VZgAR
i5wPnxfCqmHzXVghBluRXBCAuVu06/NCBR+qWepA3+MjBhh00X0d1f4vGAKx
wckaF7omq4cYmcPUYOUS8vaKxVVFJQCBSwJkHxDckLDtGewah3Aj660dLOjs
0YT3oTE2QorUkywjfOMPlhFS1tOVusPRC0dLVsoTGTFzU2BFzHfLvAxFmh/i
0VcRBxFUNlEIV21Hqxc/rJhcE9MQxMdwBwl3YRot1RiFKHBsk1fZOgCoJiFT
jSP5b0xqa2y4EYb0YG0NY1iAt4Bdo0kFMI/FSHe+KClI3hWfFO+A972LTnAn
mCKWmI9n3HhEH4JXJmYpenfwhMq88HvwfuuU9QvAYMSdk+pHZKfvAk417mlL
jEv9qW3EJmrxKLZdlcB4y0RcYPCrjHC1pvy7HY4RdHJwnAlQdlN6I4Y6zmbI
asezYEUwCn2XRF3K7rHBryRliWhTsID8O5w3TkPZAfuTTAqFmcazwycABynp
hfISqRK13Q4q9RDnhBz0CZqRM0MTPQVE8D0czekdVJ7nSrzt/JIg+XcpPHK8
eIlRtNge3kuhugVsGFhTLFOkcWQkdXdlFBGr0Y7EOoWz6o8f3eIkKLg5RtnY
I0VNfCNnYuAzRNWxpWXWQ4PAINjjMM65Rtl0iEMqMfvyClzIc1FAwsvsHIsa
oqMpfiipwK61toEqFRBxyy5TamlJacAcsqJG+u5p3hXBtzLXqzT18zb91ElW
5MY6HUYQEc5VpZ61M3lHXiaviVaRMdBiRMWZvHoAvSJbRAlukmTJK6slfxy/
jpj05vjP5gHjMtEgV1tHwN0+fttUhKgsSQnDmoqhjep8shkqAGsy34VmPSRq
36icEXoEjvCuEITaZ5JIsOXWrRs6+jnP7tJUYQiM66wNnRBFwqdvisg+vYNP
mEIVtnhGFxZDa+/1Av8YA1GxKFcxcgY5AyjZS8UvkSsYY1HabR0OA08Yp7W0
OZd4AOpeFYKjFK0ryUEgkHZXko3mSX2R6KZDLeUgkGCPlK9A+2c/RcwReuDx
7rKg+7VrHtZwJl+dasO2Lfo4QX3FCIQg+AZdshPvcj6jUVsWakWLYY8eCWhQ
JmwjpR2RQUo6futfseAhQHrniRqWBfj6BCtojlw94MJQlgBtpL/UhQOepBrv
TmwfptN/59onVz73GEM7MbJioxaDxTKN0bDBi2VjYr6R1GhEQ62mYI54sjIp
jogSl1a+wmK/ZUpSdr823hngEq3IsPOlBeTOLrhQ3I4VkBJbHoDOawaf1suz
IhsJCmJxBgzwIZkJJDlCgFXhAGHHJn52yAPN1jmw8lx9q5IYT3G7Trq3Yw5b
loVk9I13qFqU8cZLVqrYzSMTPY0EpPGMZGOdbYxg2F5FIaRtC8uI6Q8J8abM
yOQw4/ODRBCKgyEfxKBNbFTNhQNIkbS62q5DXGToWaT5KiBCuiyowYz9JbrM
UIeI55iOL0WH0GV5gwHIyzTBShMYJL8b1w5IVa7EopCfP++RKmzonYUhtbY7
7pmXGHt2MYveaCpCtHv18uKNFFDKSXlleM8B7zPaL987aDV6q5UsxdXngL8L
lSElUE6VNM4KCnTEvB8sefh6D1UeTrDMSi2sRAqQRCKIErUxBaCs7Heb1Qs2
F1BqcL0I7clxwoccVhHfJhOyw6XSQBZTAYtrfLB2E7dMzynVtST15+NHLXEJ
jEpMhBs13yacct3RgKwK1k5z6ipdEkruCngkyiTkJ5BTFUDRI4eIgDQhbo5y
JNp1Lbob65kqFFsF92m8Qu4m8todcuU2nV7A21XqhwYcnglL2ZgTy8qO3X6N
n9V9wiK717T7PJSzrF1Xn95zTKgFTYOfjykXfEo50J7c3wnAJ3M8gpkZnNri
TeSWZPcbt2VQZaDoDovN54VooxTkPqTICpCGG4EPrIEsAHuS9BTPMTxeCh7R
MQ2S7Durrw97rORDit4gIyIpOAsuzXeHOheetFgpWnIagMjkY/OkXJ8Qx5oZ
E3Fb641irDVcux/HAGFxG7KFus+K7JbhI25jjglBxvFgEKKhkFVby+/xLKlY
jQTs9qvJ9CTzz5pj+nFqEr3u2Fl79KCsTX1SFQHLp/Cc5GDh2Ep4pA36DC1k
CculRmpRrPcW37Rlz4DqI46BeD0XFU5OMlXz1BKNwZ+eQtKrgzMo9H30HBlh
jGw4XQupFkg3Blkt9hGwGwdXZxKdYnFfdtZJegpb/WyZHSAvFNBoJbZ+ZXhN
g16MENC2il+JuKZVhdySBUG1dqetE+/g8ztdbXeH64cFyLdmyQR50qVdY69y
Oxa3tpmjYWS9S/UslhGLUnX37HNrhdmKc4jD26HcNVhgHvJyMykT9B/fc4to
AQTdIQbMWR3j47AtV1MGpPNRsrCIeIpZNuTi5mJJUkyWKiaRB3wWtZyOvu0W
k1GlHqBfSZAr/X1xDUTaO80OrG0NJrOIX7Jn3Rxsr75Xny/ma/RUOmV9nfTa
upnqNKekydhKcsZkQPI7hd+mImFx6Kgroe7CpJdl3eiZGbt+F1tuzTBfZKW+
o4u4HHqM6pZlwNYO4vmMO0q7kQZoja7nEtdLMzdJLTx1j0v2GsSGyg+Rivi8
MJYfY6ZzNC3HZhY8vO+yEfYfSePBy40WamOVMOD5Qd5ZxxtP4t716hjGmF+z
lMRpDIik1HIXYNkMQ405XJpOGZcp9hz2pAxbxyk+Th4bnKZJUVX9sIZLecK+
evxSjtW4bklak2zlANxqmx3HhgX2bFmRzZcmkjKtJZAXM2UxqBM+W2B5DY5Q
l3IWiUp0EsfbUEIq4d/SzepEt9TGwlTEEjqo2B6LFd4oP48VGaxqNK3WwGs0
MEhKJ0+0SuVKrc/XfZZAJ5DJiX9wVVw+vWQeSt2G15iVGedwW0bRysisb6eJ
sTjUbXhmHQOya/yx/gQyxSoHHvqmdPLLWOu1VppCZ40JnuBkemYtDYdnn/un
TftIUXBxTrYILSY83pyvd7tI+mmSmRcFU040pIiOKY5utbYr07aK5lGC5qIV
GjyXguYBo6DkCGBupjcdcC7h9c/urXiQ+z0UDhju9lGwFmWKnHtbRvwAtQ/Y
XSwax3n7aj2/vkKeSJY6z0Ye2UoIkXVSSh1wZnjoCnLkFavdhGRLefB+7Qfj
wXkyNPVE43yOKQsLUL1MOUfO/xx2rAIUrstEKb51VOElvZ3KMFIFyNjdK3Xb
4cFcbHCjWCD3ARKi6qnvqc5NRj+yT1eO5KhMdFML95TMIA3+7GHFzmZPpIqk
HvawO6s156KqHst+wTV5sfBcvqFoHNRK4c5szfk6OgegKFcVZPO8QryRRDYN
fekQ2VjrVSNjqMxMwrTMEpY/JYlB5Ylsc9XUZMhywixgZAR7GtdZTrxylRWr
MjO+MGTtEqckZZTj5Av2UiLi2uUGPSuiX9ySC7+LgqWqdm5PCI2edYijk6De
U4DNBFBE15SzYurkc2OmLZUZVyUlc7PbXCJd18L4TLYQ00erS4PbT4ALztZe
2WTMA46pXJ0N5aY05QqeKhMZbqyRu9z1oduVq08c3z253lOZXA9DEQP92qFR
q858p+1C2y2En/3T+MnDF14fiDEFaaMpEBdxcs0hnhhLoOUXKLr45LiOdoXA
9og+2Ct99f34IDo9uzSOnmZSu2uzWqkbQVZ0JxLtdohrT77LHlRmGM7McUT3
NIG5Yx2aaDdIfTSYPNEiZ28vgCvWGA3ujdO0ZrX1ReMKu0YDGtYaro0HiM5v
U1exq2GzKdm69lvCDXz6equk3Q0O0LBN1GG9/pkX0otn0FdnhOm67mFmnG9I
8qobycgUI33pctF0jLnzhstI4zk7bMtbtpIFBigbBZ9d1Cx3cGSB5vJzkw7j
UO6JEVEZNbyZXJzZ2LScGvUUCo1M9EusBW689LDFHkltV/ZZG70rbsJS267I
v2KKW2tSaZ5HhvxoYRHXQsIQKQ5WrHRchJIN7RJrkDeB8JpUiTUJ7nNOq3CE
CuUrMu9zoxi+lXCIa/JsLiXETwvgCp+2Qo44ZCQaxPdQ+SaCjx9n2XxEXXJW
zchN8/78uVXOAr5c5qnBmSlX6TCpqFRaqc806oTZofCGdfeL1JSEIRao4gUN
uDaZr1OQSvioqR3Ld5+J2zj5kZSDhEXDp1i6v2ccNBzWTTj+1c1aMqr8ekVF
xunoRw+p+6buWINtP619TdQvVg7UMhvUzl1jf5DGsM9eR0eDNWI/pZFyBjvZ
IFFQQwFTE8YPo++VGn9FHzA5QH1afukUY/F9Ma0dI2kQmBcmllESuSeq7/Hn
KDtzlcdMsT6ted9tpPifIam2mOzGum9JEQBi6j8OeJrKA/eI2akpbBh9MWkZ
7btHrkUDtz5i47xqG/nXwRrxJzpy/RarjCucnqHs32dZwEO9tjpNy5YQz+fw
vVhqAZu5Bfdn6Ni/TFBPexG3cVsz2Q4oEa3jqkJx1HNtY1MnzrxyQgexHKbU
Bh7bKpnjKPjjFtKkWpqfImva8SpvtoqRip2SS3Let6VA7/d9x/nSA1NQ9Cb8
tP44t29kNQ/6FjMe+bfH9oNjWJWFf3dR+/B/kk35V/xHFNFo311cd2337Ucf
2L/pii4xDMOo7+Z9M2fnCWcf3Z/75ukuSD4572+dQs9UPjk7dMcu2Qf9981+
PejHP/p5YIE4UlB+GtCEhHqiDqY6P7954BMOr5net7u+BQjjB60L/L4Ct4vX
uh1jeZq+JPyEp/rAqaX9yX8Jl6fn5YN/o4EfjEbe6h7gmK33P43NJ+1KHozt
Qx4IAu87f91/oPjjXfYgYN+/cf6NGEH9FeiWOSAw74/NnnoooHhroGrWrxjA
73/y+OyX4LFZkLzvooB+pIOLDn3tycQGzjzbGNABlvO7Wym5TTc3/X8Ce7Oz
cDiXA8GRc3usDzu3gGPsRydtwWgf2dkfmJu5sNwnVnfJQsfrco6T2B/c73wM
d3af5+hAEh8G4HSeHRA4vKBZ+Ns5HrxxA8/iAMEnQ+OGnnXh3/rpPquFo/sE
Gq0ffeleQzMMP0vqLKnAO5Is7Eibkn1qE0U48Yv7BPLrQ+oanYeVxUBo7NCT
wTVfOCgnkgOy0tq4XNUy9JVw5EnNwe9q8KBQh8uebku21HOflrRwZTqRG4zW
yLJW5mXst9OKyEUpX2e5FwtGGcMjlXAaNRjZ3Jh4fDFpaHtJbeTEOTnk+rCh
X3Xgo62eZ+9A6Zc/xu9INOS+qu1wKLswej2miIqJaeSmbvV3PNuDsTcs7qfc
OfTuSFHQoO4Wirrn6mwzsU5YJ7bkxJr+SlRxlFb+BqsDkF/NG+1Ek2il6eUq
rcQ9JibvO70sd6UTSKq3rTQ+MsneWzBTw6DCINGCkohQ7OaS8pNYjMBz8Pqd
ASURguoJs+tXbMColJl6Bly+AI2LNfkHh067ttr0qKS1DCX2ii1ixrisNmXt
ZNVIZ0SeAGz2y3RTijVlGd4Y3slW/8HOTg8lIweZZhHABPLTrle6Sb55SqsL
+F3H8jS+cVNohBWRHVfta2rEMpp2GEM58ZwK+RTTRVkZBwO1SmvKapsCyyRx
bzviDganbGVv8c1tCT9YQ5zLbLsl/pS8e+K8qBdu2MFrcnFMIoPE6U9N+9Wy
3bCvzUtoZsDNOJtVc4QDc7Db7Ses9iREjgfns+ANWy/T6KYOuxyKlYKK0Slr
8FXaXnOhLkVszT2hj20yt3VefITZrdNuxJR9QCyD2rL+8+c9LxbR7q5Tzjxk
STJ5OHWKVk0sSz7kRj1UNr2PCfUvzGUm4cA4LQ0UB0bf+EXZh1pFSlc9paCS
ieMxqcqy8d0mXr8hslKtl5MVEAtWMcSOweQ2knKcF6u0OD9FsadA4dLgpdZu
MhHzUh7QnQwbUvk0pjOJmzbRpgaTg23lEMRjnn9gR+7AMG6JA9RiAk6dipIW
EsT33VJZJs3dhZa6jKRaQguY8Oy6qtiB7YZq1u192UIXpgZyJ85UWYf0qTQR
p7RMLbYn6GkZVWsBKHJ8eNK803oW7Nmz3OKOF+nxd92wvMtXJy8ePX2IbAsY
CX8hkAbaXhZldJhhNX4XTpaZ9+1WoRjmevwRalGr5sD257rxusHUxPARpPyJ
Qohc4ZrkJbeySSB/dtuBxX4563jisKo6QP3l3ZUJegOlmLuQ95ZdJx3ewQSJ
RkiKUKyk15p0Hmm+QGTzmoG2Tnc9lo/dpjGtZ3j67iHfdyDD/kr95r7FmPos
7h72j0g5aBua+faTR/ICONlMmFsgFD21FD/UUvheFmq9pSQOd2FSJauzwqkj
e1O31VZ+Sg9Gb9ubY/SqUqfD9VIcjm4lkZBU4fovhgQGV4osc0o4hV8pNlay
7wiFRFUQd5dz4BnVlZyFtnF1aHvvxLRIKuVrjASO+xL4Mz61WiGdfbzX1KPM
e+ozZrpqF/qtAjb11o1Kk4HpsPewu6kPTzuMZqt6o0osZsql2EvFOX3a/Scm
3mptcw9yPr7lpOtZNqf0jS+a2a/gveMpGihi1Z6kNWfXlUEioOThSjt4ymYI
JphrxJxgRlsuF5Dj1wvt7DvxKsmR5uV0ziQRBZSvlFGhl2GJbabbyUIKfHGl
M0tZAIZsagC+xU/mmUL2jNe931feUrBIv+pvR+7hAkcA6K47PS1swuuRqTR2
UeQbLbOlJb8McXLQcP9nueWw31JesrW73WFCRcyoFB8dolQJFOOBkxQFr0Tq
0JIETsJ/sLpIow3JQGedYeVBOdi/PIaV0PeOzWBv6ZceeuPBGUZOBMIbJVhR
CqdISAFFbMoy7y7XIY3LnDLrmU23dIrGIPs1ljA6fcgKpWHXHNaYxxs5eE3t
hX4UNnpevdZi994B1jjGGa4DhpLtlI6vLXBwlCsMS0AzWAvJvBJK9ECHu5j0
bfFpe+L12PNKc0kZjV2hAtq9+F1LpqJhsvY8C+Y52XIjjq99KAWH5Q7mmZh0
Bwzi0wy//lnIB6S9k9iIa83FvZZe9+3cJDk2JRDVFD8PsgPOupIIrTSiYOWZ
WItm2rnC65YOclvyt3jK1MwHUp+UJBqdrWZLBfpIHWYlEJeLUVsUUcyZABi4
j1GU1HkMC0uSmuzVuu2R29jiqylEbkVXqarrnAqcwjSUXfa1TlPH+vjtue1a
g8DoDkTx36bFmlsF3SkcK+UY8IiEPV14kdsa6NaeLGvLxqIRUv9NvqhE0KBx
0DQHuhd45eM9LpExsjGyn4P2O+r/Cfj+M5cu0UqonhHKJBmZI0NbSiuVmNo6
3Zm4Vd419knD0hw91vY+d5TKyca1hJl6PTQd7+h0Ki3QWV1rJo3GvsFyzLkO
FE62WquNyMJZYOJ5jEPAggt5Omtsjycy62GPB1EAsd56K6ZPE0k80UZ7qfMT
nDEj5TlJC8NUCbd2MytHDG6nx7q06owpTbzY2G6abiSg8i0st4DNw+OcQ6QB
lRHaVBeG2xVh3BcLgdaEVkuFBrN18YbKLdMBua6opHUZimh3atXhbrPEiEk0
ScolPEy/Lok33H336N2RER5xKXsc2s7VL9KWeCEPMr/o6b091KdqtzYYncft
qhJe202SlT9+PCmv/nh+CviP/j0M+7PFxMX4KXhxHc9rWQa/uJkC+0tP/wTv
vpQenLbwhfNgVoyasinhMa9vPE92xUU9JbGPnr96e/qn0cnLi0t8I1Ce33nP
+Qq99bsrrGH2NW+9vjo2ExvxxF5jHWE5SDoQ5LcYYlsgpd8YKEohT+1NjTBN
OTWY3m4YtU+w0tW5WCHHZuBQ2r+yHhVkMatqXih62Sy2UjyRHtLVqKuQARo4
U16WVG41DpeaZAseexDJkcd1DyiLZuhWJXzn1j0MmMYqy8JMWXJ/rj5d8AyR
8YwHu1j+QiuIMLw+fnRrWn+OnHrX4z27KWRrQUnEAF6zWd6nG+AqxvxPXPrd
+yx5p2K5PTfaq9kjzAntJUZmYsQVGtG6ONDaaZgBJRcpg0EEIv75VYUsfDmj
Oxg8TZnVX1JfohY+TVKYuvFKrRaoPmkn89B+xkBDHI1uPVPXvt27jlBhC+kM
xChsI46xQgOq9lsnZD7RqeKlPnunEs8MU2bp3GyPR4U/cJuMOI1OEmvllYBq
NelyTXs2WxvTtKCVU1UDJ9cxDAveGbtvwJz/xaZhr3iYU/htFDlOiA+d/Jeh
UR/Iz99eh1l1XyVSkCwusdrk5dmpl/WAYc9XzsgeoXVGIT7T/lZgjfC1i7dY
1PL4detr7GoJTbwTkdFlVczs1GJOyo2xDXArzx8uz32VpK9EuuWdZNq/j4JX
MceNVNendPM+oEU/P3hxiHSHNQ8kfoOfF9s4g61T80gH05VR89nC273iK6Ew
Hvw+5SYwJWVW2KwT0bnQjGU89N3y/X1VaoP1QGzepef96ZwqoWJPrXSJKzFI
HOLn+mo/eYOKz6XzYeGj9Ni7aJdDdvJ4kubRwZ7RWN95da1azx3uedWsqMSD
lw3cgcauVSX2xBBh1XiesZZ07MDX6Rzne+hbBU10gJA/qVO+lEOsOvPUlu+a
kdLW0kbTJMlbcfMxIuGSuwCdnJ6+dh3ceNbCJSmX2ssUwnwubHlyC/GEU7r8
LCDyH8S5YzinTeykp4+Mjhb2VKD8zezAq7PRGRWj9CIEkyibP1no/jq693R8
8NxFBlPtNXRv4Cigv47+Mogc6EXRUYRVVKLxdAKgfas3fvqOuR087EL1KPrB
/uU8o/pMZAfcj4osx3s2+EPvDX4cDNpfgpl9hIf/dZeIklD5KDp4shf9+jeR
vQRP/Ds8E+fzIyQzuAeKmVwUK9xPqFMdRY/obsMzWdungEUeRY/pJk2FrwIT
hFf4MkELsxW/i+uFuU+sEZ55ZJ/5ExyPcP8bIWe4DNrp4DPA28zXrAqYvM64
4c/+K6iskyNkAvZad6guuGXIu2aF9yvBcXjgBawNH/mLCWL+Mfg9+RvBCnCj
abnhokFC1njRNtX2lD9yiA8DSHs4RJoUbQZRmNiPnsMCONfZB6kUdJrF86LE
BtfR99IhJ9o9O/1+b6ied6ODS2ktDBqdLtDGeiq/Wb1axZ48xj59nsBKoW7k
Ng2XpLH9pui7qRYgUrOg1B5SigcqHCUw9wEQcX9Qr/zsu7YluUShwH+RgODF
/fjxw4PDpw8fjcfjp8mzh0+nT5/cH5rX3zqMwHk9ij5+1ofC33Xw0n8RiX7b
i23YmhcX95+9iJP4yZPnMNVH8eHzSZw+vm9fvHLYiPPFHwd72zEUEMkg6MuL
y+0Y4rUnae/nFmw1wBjxuRNAXzxEkpTzvvvE8RBGb6MPLtYhuVF1zxC1bcEQ
R2gfsf4K4JSMwW3lQ58wqYyOXh/t3FDVp7GUKdCA3Z0OCn/chrvbcfDgKBo9
24aC8OKxlvhwX3x05KZY78vcHvytRv+7vHjirN+8+PgIUPDJw6fPn8yePAEU
fPLwyeGjwyeWWuBFFHqd+EKZ6pOjaPtK952mDx7ywipNAzgBqtHV+UWbcOa9
eHgUhTfBrFEFT+/Fz8DitxJLCI//QdQDyo3daT7KkKBEfETEe03MFQ8NrFxB
gqDlpU4N1dryZePtaMpSmDMKiGVJtmUegx27daoF5EEpK9uFJEw8ml/302tX
5dYXK7XTxQJkBGlHo8XLgdy9bsFYRMVwO2qx5WUrRk6GH+W/+bmI+MB9m0d4
XxJ8KNHsPmbQfPKSZTDpD66g6MLb/oCzG23KnM1/2v8rZnv5aUGfGHuiv9Jf
biblwNzWnweUhAZIwb9Eb40QyPlAN52B/6pZNWY6D3hFNm3Rpnr9db9FRp8I
OHZDHpgkmfYPQ81dcd+Pl7m09ecXPgmcJJKunYAU36cNNRWkq/hkz6Bwf9AZ
RZlBa5B/1hrs5m/LYqSUQzVK69ahuDuMQKjeaz95qpUewpmNmvQ0iN4ZongX
/qy/ov+5ZYL+inrT4ZwnP8GOZTcosyHHD2Tg2TG9LK8Aot348wwn85mJje94
EkmbJQYnWTE8ppnYfT+ttedHbt0MeD7u7iik/OS7B8ITfCrdb/3X+QFuw5ev
OOk4ctIor8vopZFdXiKPxDmHh1bm5N8cuEmL/k44vE9uKjjaKAEb7wnUNh1W
X8TTc9BOSgoZGQaY4WMa5oQaePSG6EikmJY/McFPTbrCYKeDcfTNN9werxVg
ePTNN9Fx1L2ldRz7g3S7LUeCAbq2f55bfEBs4ePBsTebSKPYTB89LurVYy4h
Z7sbrNFbr2rMILi+6gq7f3DrwVFNP46DF+BsDyDW2E1rsPDKy63IraQWxMfj
x2xDtLEDNIik0HvpFb3ivdkVJ0HGCLUUxt+qb9eql8pTcuLR74iQxpAOm/4R
0DYkLIqDbSQKoq2sbKtYiQ6IrS0Fbdikk5EibXG0HpJBiW6emuniLMHeZav5
hAj1taDIMT0V6s9zJzJYMMVNU2WTdZM6kSFULjYYV1qld9nOa2SbJ6AXlsu+
PjBS0CaRUBrSyDjZIjxjEuCN0Tnl/qkmZ0JraqOj041y89oAtVaK0V0xZjyu
TGIPQVRj+YOb+803+hDFTHBUMFl6vvlG64uIiyquN8V0UZUF9tmm+KRuoZ2t
mVTq2badnL0gJBC5t0Uts40Hqy2x049rzjVeJaDY9lozrhu+Z1rh5hilDMIY
82atnVIvYsIR8d3E0SRupouwKfqrKnN6ZdXbMHFj9+/MTzUMHwOtqXlzU+vK
t3wH9o6DTENf0HZ6jeB+2IlgW2QgOpJ3xfRqx1JRXRN+wraLmzZrD2SxKuVw
OKLXTS7sGwgsQxEMS6xxHli6XIFou4xXCrYgYzN1B63vNdTsWDAnWNtUEciv
DuqjyPaqOW5JK31y6BXssn4PnEa3EpHW/2nETCcRwv0u5K5gQyWu2NzUU+TK
iWqgXcceCpLAwmEFibA0uKSd3jkfxfHKX3138cPrU5NdJEVku9OxlccJ6O8O
nnBjjnDQCkUa9pQX+HhPGQBvokhauyabHwPAixRDg+Mqy92GKhJfpnsZ9O4x
UsMHbtzCTF7gUA9E6TxKTE6bvvnVezceqPBoTWgcJGMk2V8iF/YPymGkBvmw
5FSV5E4Vr56OyPKXEzLaXQo7+e9mhb0VHOwWTFKuhm4SmsY6uOOvbVF+Z3d7
ts6vJeydPqYTWE8FwU5D1i0lK+RgcIJ6ndaoHc+5aYVKZMdOoUcvHgvz8gQf
ylIikGJmd5pImBBdpxqfHG/Qn5CQUCXUEEuV8PptJyJbx53iBr/cydxbG0/9
3ts82eqXpkGrtXYf0k56961aeX9LWMLj8aGjVDg+YGdidziC+z2Gd/oDfdtw
P0y3+ft6sNy6TsLDBrx9PeQizruk5UaSJIFbmxCxLY4BkVhbDRjkjt4pfO4I
KoojMoXHVRVLXikFo7E07XFAM5ddyvWA+Vcbt8tjLG53vWR6Yv2jvIGOfQT/
/cVuwdY40Z0Oj45/sDNChDA/wkmFR7CwO9xr3XOsmIv7yeHzx0+eP53CSh4f
vDiYvUgO73sjRB1gtEaYPj3UEZ7PHsezF8/S1giHW0b4UX77PPylHtDOoF/t
Cm2N0PaJ9tLcL3Tt3EHiQkZC1E4Sp7o/jabGHTTvYAt+nyrT37TTmxjZT3/i
EY8SIGgzYH9qoLYvxmMgGHxE8b6iULIMY0TOO1OiKOx5PHgrOjWdx/2Za8bn
adoZb0xkXRrq62TGpMZlyPPQXHTw9PCnq++OD588RYbGMW7vDt6NB68p/MiG
YHegvPtudPBuT9IIOxW54e7hu/827vX4/yT3Gh0eHvY5fvdVQAvdc3jP6OAo
zP7Q89uB/MFedwSExvNHD58/fPYcefkj2NHnL54+Bmh0RnD4oDvCj+Z3w8H+
oazs4OHs6eTgMG7zZx7ha1mZw1t+IfMSRtJlV/+gGI4eKb/4UkbXzyiQ9A6Q
+KgbMZArM9Bdn6C71PcLwzC8nfhF8RjeCL8ovsIbAVd/FB1sxch+zvmLQzW8
ORAk3FYSnbiNQMxGa4RfELzhjdCO4tiGwP81IumJ2fDpxhwRI2Izd5BNO9rY
kQE8uUEyE7vByTbYSVKSakxrurNqAZZ+eff8nVdbw7WV4H1ul85kaMlOA9g7
U7F5k2pp2X7I302p4bOgjaHb+frzrVTKI1CzDYJbCL+20zmP8BqzU9Cu+CE0
wt3rcFeBMTRYJv6Rf76BYP7k6UHy6BEebLMXz4FhvHh23xsBc7ywgXcjgTh+
ECTK0U9mB8+ezRIY4TB99ih+Hk+2j3DYHuHhJInjNPEO160jPHJG+HHwY5BS
AyTzXybUlnFIYqus/zP6eO/G/PF50EmoatVQ8l2f3CCiY2/qc4cO2eZDPjQj
Cbve0Dtj8o8jv+wtzY4LtnRmR37Ryi/gpYV2rIHQ6/nrVpixJkWntWN3Asd/
1rxek0HB7UpMwpgxu2qvXi4nI46qhipfUXfOJlSDTwtgdaxgToMS05Wby/Ns
KfZg0jpRPaBPUnYhhk9TyzJTCKDjWqGu26TR9FjBpcseed2cars1R7wZaEzK
EmCsfd+6iYgwBUlGltL+2SwMEAVrIJpclJcMWy/O9NR2El0IVfzub2RYlXew
COCsLwfG/bR+ZhwgG/ZnOuWGKN125MQBmBJznennJZXMHLd6TYS+wZQZV5MM
DlVQ+iwtW894PFPPbFgINaVFtHSKVyoQVneFSfQrN1UFnXR4MharNdWF9et8
MZTU0Tx0YWardnR8/1T84DbF6rLcqI3AoP25B/c4+AqUSm22xS4DBBJW3ZJ6
AmQI7OmxgT50bRYqTdkBflW5qpAXYIuhpsLCHfAali8NB6v49Tr6PdLUPZUb
QZp4DkIH6XTjeC9CdSMoViBNpBGR6wN3E7zZhVJLzVHMJeXebsbosfHqE/U0
P1kJYHFEWxgKzpc1Vx5yixW4ceDb66RttOkYVdngojShdVBSeqitoN8zd8Wh
d0MPiFx5BkaRahRez2MXJ3ffnp/vCWb67Qq1F9AXwEdAwnRJdXW44osMxHIf
oCy2UDIVc5CnSQ9BDkuWaBGCNrAI6f9lKgdNym0hWewMZE7WKU/TW8UPDdE5
Or0xs2RLe3A+Huj4qlIyW/sNSk3fZ2mKQ6LNXje22dQW7bpdvWquSTqjWh9U
9WGFFnwkR+qsWZp6t4jBLcKhnsfUcehnlSO8SvUaYyHHn9u/vheqrWc7wB1K
GSrtUeaW9XP6YXMXJNN1kOqwYKvhmDsZcXAT9huj+6Y7Ixc1xEKtDTcrTcV3
sV4hbyQn4D2YixCnzwJBhoM7cA3+/axNEz13XqBW2nwdAyiaNJXgQe8o547B
htNwf0m3SIctXkDBe+1W4xL14BWr8z5C08Pi7gJ9bWRswiXcUAfPqkgXkKB4
RDeDP9WqXTmLIqnhfC7JUyGbcj7f5uRlvs5lWwygWHhbYCcsepUJGYFqigyU
pq2jx2TGWnMPC5n3jkc7RvERIYHGCR+Lt1aQRzV2kVVbPiQk6vYsJq7D3LxO
OW6pW1SMBF2cIYjxTPClVkvs6doQKs8gbd/c3tVbK0nqh4MVHaTWg05EzAPa
rtpoKNiXrBNE2i74FV1U0sIzHLnbCsdjKrWnG592jZTnjSVC1YOLadPwQ0HR
DHFyg9pJfQd7ChaQZKHK1UWk1CAoN+ulRX1mOX2rurvx/BKj1ISNuEMxjqNt
JC6kAj1WylxXeFJ6VZj8YjdUZmMW57VXqETKDrRqS1XYb9q99CsvGNkNpKJD
i4i+RkZ9G/vFt0yJE2wU7aJbO8gKuBzMNE2UO9gmJrkKNKG4EltMjcvx0LeG
TiQvXtUm8F9S+2Y8uCCIuKWnCHQUzeRRB0hO1OYG71DBcyoQSDjldELr1AKK
XerRIgakjfGvbjFXXJzD5Gw1MdKmnV2P2/UdHR6IGCJaNU1imq2kBLKLHygH
1lKdyAaV+jKbePvDPAer6aTSKtXsGYtrE+ABRCLSV7AtsJKlT1udZ0vM7cVq
XyyD++DDYbjbKcY9huvfOtq20KaWxnDCEci4uCXcqHEL1wAE0Rj+xtTlG3jq
QH8VXSrqZYVswTaBrIjWXpEjeDy+KbNE4uSo7tFMAxhI0EMjyWpdYdVAeLgq
GwnuhgHpaQo4ZflRdOxdr+CJ14nA0cOMloEGHD/unSPBR24k+DpXNfBrqt5O
ffmJemPqoFvk4/gLKkd2imGY9VA0MXygbxZ+BPuWiuO+TeyeIMUJ9mctl3Ca
DIIYfDeiYKHSPMVG7FQLFngvWWDIaMdbKqXT+DMJFhflWYdz3Knc5N+YF03C
jZ1qz46l0t+8KCUGr0V2fX0kuPay2FH9Yl1UFFYqp5qZM6cBThVNYra4eRKi
qd5LBzm1f9AgXzvIMMJAtkme1QtivU4TWxHdWdBZEn9F4PtlMetoXuIsYdjb
uEocxZ4aR4PqgOoaWSpYfLdFAiYYHrkimwf1kdbT2O2j29orPAC0rnDEHhi0
YBBmuIAx+/xFFVK96uKDwcue8tuMJDWoxaRZspnSgtsL2aaqh43oPpQwEoro
NgoGKQKmmrZTO6UvoQiDivM0mUuKe8yB2xXv7orKo3Io55vW9HXeK7+MuMSq
M3vS0wU2iyfPsFwXngmFMy4iLBI7yjMUyrVRkmNPGFotkQ5ZW2Z1RXkDsW2h
BPOaxeucjDYEHdgobNxMN+XcXTpBtliQEX0To2sM/PgBS36CCkmX8IqrS157
lrrdegrij3VQP5gC2e25DEkfEVKUB8gTIgU6vQ5wxhynCQLYTw7DUlLNUvGS
izSewI4X7d53M3zu74VaboRGHA9spT5bcLhxD4msBTNAgIzLjBRMDIFmLS9R
jwouN1juVULERfiKrZXb2EkNYrJlncuGSOH2huUs3uETz1JzzH3HsXvWNFaN
izUSr4O9WoVqp3AhFWgJu2DICDKBc2yWNbWVeVnMxG4p3iSk+bk03Ftg/H/0
pkzSXIvxipxoTBWxOSMbfnqJT9vSzUO3kinX5IUDdI1W4kA9ezq3SO5D0z1V
QqdS3bvCaHu6DjDotS/FHrNjVk9QtF6zz8Fjrcbkki05wt9UZza+roDyZc0j
1OGNVHADUhGUd/1UTqY181BQYNx14xD2xl8gIBIzxa9PWkeGUwPLw5qkFAlY
bZlsBXBbQqPtrKLSteGvjgenphKm7AtqJMpkbZnMnj2iyFlfGSRVraeKtKpe
7P3BosK3hWkxd7kuiv7UmDDMDM7amZbVHM6Ln23pY1PW3a1dTzVAgejm9Acc
lPi06hxkySxz211JxJ8VKfhtS0iPmwP2eZuNxKmsXMMuAcKWbOohFKACF0OH
XXjFz8yqhU6HqKDDYmo8hEaO49FnBBKqBjNYlLmdnedM9JYwBemnaPgcvmBV
A87iRNq0aA9Bbq8h2CNq6ZRFB1C04uUEjmgUIJYxuq4wpVCL9S9KTN+CozY6
c/otsF4ZtkCZXSZ3MYmiF3y6cIV3nR6CFY4JOa1tiXr0duJOJvGSqr4rHgKO
rBubBu0kwxiNZPhVSdAdRd/lZiCopuxqnqTGPTXRVmUMHVBhSpJNyHuhpCm9
55i90nENeOrU3HdFbls6CE/RYlbFTj8NRxvemeHBuePUn22lCjhcLVw1jD3Z
GS+JZWzqqcFsgWzmWEmx6zLEi1mtqUbqnuXXQFf+JiL4OnKGWz0oJAWprLFD
YlSEclS9o6IrcHfszTcBAeR2/EWDu/LTVwyNB6196u5J+52oglABkbrlQnBk
R3Gmh2cGIsW/UB1LWumI5CHKkf0UfY/mMPvzKbpGckRa7f5gq2PpWdC+AyMF
l/Xp7pV/gtl1uwR8Roz++PFfr85ev4I/PlGIDih3I2cJo9Z4GqLDxNhNHLXb
4UKbAuaO8LQFEvs8oPuYWn008CpVgWixnjTuTX8dSO6akK9iaI2PFfvxYHBh
uhR0751pk1LfCoH30TEA27dLQUfk1wL2styDuYQtF/jOx48B/cEHp3jqqZy/
8MfuOAXw+sHg7Zr0atSM3B4E/CEz3LGbOch5wiTpYqMxQ1z4zg9SQtxkhRdd
lxV2LUFmnPClTv1n6/NSy79vVh68AjmanTU2VDWwPoT9saOmWhst3j5FkYF7
O8GhBQwYt722+jevCCtmfr9/jLWA3sQYl1Osl5O02q33vHuvshxVrAZrXpWF
uTsmBOaXp9jBoAa5Ex8lPMN4TH+gt+Rf55KGcBDkyBIq8VZTmsSUZYrZuhIj
vrckOIPm32ZpMxuDgMQ4QEFsa9SB8IGTizdvLr5HTHb6QpSFfYBx4pjCMPZP
KBNYT6Ac2fVRdH52/epu5ucxVZ/1/eNZkvexKMiS/Ec+uZUEvoQPqbnL4z+m
JvI/mO24c/3/TOdrmI61EpqgHC9UnKvGOY6SyDaRT8Xd1OseGBrrsmjl3BnQ
lwCxZYm4JaUcRLvTmHRBx2YdlROfEaxT8H8PnxOc/X+T052Ux2+1ZOXoFXeR
cSn9Lim3JdS1RmJAG/fwTuBrIOmBVj2ycqjT1mMHBW6YCHl7Ls+urmfrHAMC
s6osWHLfPSkvz/YQRYVH7NjMNZUbp2WVjiwXwfQBHv7wydPRC/iJLhFCR8i+
dW7XWryzy7O1vucJs6BP0fmpx8mRd3+B3Dhqj3v47Bkxb8ut72b2NA6++rz1
qjJ6sWqOGMFqn8m3NqLN4f83sCQcUPgFAQA= [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>