rfc9943.original.xml   rfc9943.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-scitt-architecture-22" category="std" consensus="true" submissionType="IET <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
F" tocInclude="true" sortRefs="true" symRefs="true" version="3"> -ietf-scitt-architecture-22" number="9943" updates="" obsoletes="" xml:lang="en"
<!-- xml2rfc v2v3 conversion 2.46.0 --> category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<front> <front>
<title abbrev="SCITT Architecture">An Architecture for Trustworthy and Trans parent Digital Supply Chains</title> <title abbrev="SCITT Architecture">An Architecture for Trustworthy and Trans parent Digital Supply Chains</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/> <seriesInfo name="RFC" value="9943"/>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization> <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
<address> <address>
<postal> <postal>
<street>Rheinstrasse 75</street> <street>Rheinstrasse 75</street>
<city>Darmstadt</city> <city>Darmstadt</city>
<code>64295</code> <code>64295</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>henk.birkholz@sit.fraunhofer.de</email> <email>henk.birkholz@ietf.contact</email>
</address> </address>
</author> </author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-L avaud"> <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-L avaud">
<organization>Microsoft Research</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street>21 Station Road</street> <country>United Kingdom</country>
<city>Cambridge</city>
<code>CB1 2FB</code>
<country>UK</country>
</postal> </postal>
<email>antdl@microsoft.com</email> <email>antdl@microsoft.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Fournet" fullname="Cedric Fournet"> <author initials="C." surname="Fournet" fullname="Cédric Fournet">
<organization>Microsoft Research</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street>21 Station Road</street> <country>United Kingdom</country>
<city>Cambridge</city>
<code>CB1 2FB</code>
<country>UK</country>
</postal> </postal>
<email>fournet@microsoft.com</email> <email>fournet@microsoft.com</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande"> <author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande">
<organization>ARM</organization> <organization>ARM</organization>
<address> <address>
<postal> <postal>
<street>110 Fulbourn Road</street> <street>110 Fulbourn Road</street>
<city>Cambridge</city> <city>Cambridge</city>
<code>CB1 9NJ</code> <code>CB1 9NJ</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>yogesh.deshpande@arm.com</email> <email>yogesh.deshpande@arm.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Lasker" fullname="Steve Lasker"> <author initials="S." surname="Lasker" fullname="Steve Lasker">
<organization/> <organization/>
<address> <address>
<email>stevenlasker@hotmail.com</email> <email>stevenlasker@hotmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="October" day="10"/> <date year="2026" month="April"/>
<area>Security</area>
<workgroup>SCITT</workgroup> <area>SEC</area>
<keyword>Internet-Draft</keyword> <workgroup>scitt</workgroup>
<abstract>
<?line 156?>
<keyword>COSE</keyword>
<abstract>
<t>Traceability in supply chains is a growing security concern. <t>Traceability in supply chains is a growing security concern.
While verifiable data structures have addressed specific issues, such as equivoc ation over digital certificates, they lack a universal architecture for all supp ly chains. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for a ll supply chains.
This document defines such an architecture for single-issuer signed statement tr ansparency. This document defines such an architecture for single-issuer signed statement tr ansparency.
It ensures extensibility, interoperability between different transparency servic es, and compliance with various auditing procedures and regulatory requirements. </t> It ensures extensibility and interoperability between different transparency ser vices as well as compliance with various auditing procedures and regulatory requ irements.</t>
</abstract> </abstract>
<note removeInRFC="true"> <note removeInRFC="true">
<name>About This Document</name> <name>About This Document</name>
<t> <t>
Status information for this document may be found at <eref target="https ://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/"/>. Status information for this document may be found at <eref target="https ://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/"/>.
</t> </t>
<t> <t>
Discussion of this document takes place on the Discussion of this document takes place on the
SCITT Working Group mailing list (<eref target="mailto:scitt@ietf.org"/> ), SCITT Working Group mailing list (<eref target="mailto:scitt@ietf.org"/> ),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro wse/scitt/"/>. which is archived at <eref target="https://mailarchive.ietf.org/arch/bro wse/scitt/"/>.
skipping to change at line 99 skipping to change at line 96
</t> </t>
<t>Source for this draft and an issue tracker can be found at <t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-scitt/draft-ietf-scitt-architec ture"/>.</t> <eref target="https://github.com/ietf-wg-scitt/draft-ietf-scitt-architec ture"/>.</t>
</note> </note>
</front> </front>
<middle> <middle>
<?line 163?> <?line 163?>
<section anchor="sec-introduction"> <section anchor="sec-introduction">
<name>Introduction</name> <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 verifia ble data structures maintained by corresponding transparency services. <t>This document defines an architecture, a base set of extensible message structures, and associated flows to make signed content transparent via VDSs ma intained 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 f or single-issuer signed content (statements) that are about supply chain commodi ties (artifacts).</t> The goal of the transparency enabled by the Supply Chain Integrity, Transparency , and Trust (SCITT) architecture is to enhance auditability and accountability f or single-issuer signed content (statements) that are about supply chain commodi ties (artifacts).</t>
<t>Registering signed statements with a transparency service is akin to a <t>Registering signed statements with a Transparency Service (TS) is akin
notarization procedure. to a notarization procedure.
Transparency services confirm a policy is met before recording the statement on TSs confirm a policy is met before recording the statement on the ledger.
the ledger.
The SCITT ledger represents a linear and irrevocable history of statements made. The SCITT ledger represents a linear and irrevocable history of statements made.
Once the signed statement is registered, the transparency service issues a recei Once the signed statement is registered, the TS issues a receipt.</t>
pt.</t> <t>Similar approaches have been implemented for specific classes of artifa
<t>Similar approaches have been implemented for specific classes of artifa cts, such as Certificate Transparency (CT) <xref target="RFC9162"/>.
cts, such as Certificate Transparency <xref target="RFC9162"/>.
The SCITT approach follows a more generic paradigm than previous approaches. 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 syste ms. This "content-agnostic" approach allows TSs to be either integrated in existing solutions or 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 interoperab ility with respect to registration procedures and corresponding auditability and accountability. Extensibility is a vital feature of the SCITT architecture, so that requirements from various applications can be accommodated while always ensuring interoperab ility with respect to registration procedures and corresponding auditability and accountability.
For simplicity, the scope of this document is limited to use cases originating f For simplicity, the scope of this document is limited to use cases originating f
rom the software supply chain domain, but the specification defined is applicabl rom the software supply chain domain. However, the specification defined is app
e to any other type of supply chain statements (also referred to as value-add gr licable to any other type of supply chain statements (also referred to as "value
aphs), for example, statements about hardware supply chains.</t> -add graphs"), for example, statements about hardware supply chains.</t>
<t>This document also defines message structures for signed statements and <t>This document also defines message structures for signed statements and
transparent statements, which embed COSE receipts <xref target="I-D.draft-ietf- transparent statements, which embed CBOR Object Signing and Encryption (COSE) r
cose-merkle-tree-proofs"/>, i.e., signed verifiable data structure proofs). eceipts <xref target="RFC9942"/>, i.e., signed Verifiable Data Structure Proofs
These message structures are based on the Concise Binary Object Representation S (VDP).
tandard <xref target="STD94"/> and corresponding signing is facilitated via the These message structures are based on the Concise Binary Object Representation (
CBOR Object Signing and Encryption Standard <xref target="STD96"/>. CBOR) Standard <xref target="STD94"/> and corresponding signing is facilitated v
The message structures are defined using the Concise Data Definition Language <x ia the COSE Standard <xref target="STD96"/>.
ref target="RFC8610"/>. The message structures are defined using the Concise Data Definition Language (C
The signed statements and receipts are based respectively on the COSE_Sign1 spec DDL) <xref target="RFC8610"/>.
ification in <xref section="4.2" sectionFormat="of" target="STD96"/> and on COSE The signed statements and receipts are, respectively, based on the COSE_Sign1 sp
receipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>. ecification in Section <xref section="4.2" sectionFormat="bare" target="RFC9052"
The application-domain-agnostic nature of COSE_Sign1 and its extensibility throu /> of RFC 9052 <xref target="STD96"/> and on COSE receipts <xref target="RFC9942
gh COSE Header Parameters are prerequisites for implementing the interoperable m "/>.
essage layer defined in this document.</t> The application-domain-agnostic nature of COSE_Sign1 and its extensibility throu
gh COSE header parameters are prerequisites for implementing the interoperable m
essage 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. <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, how participating entities discover and notify each other of changes is out-of-scope of this document.</t> How these statements are managed or stored as well as how participating entities discover and notify each other of changes is out of scope of this document.</t>
<section anchor="sec-requirements-notation"> <section anchor="sec-requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, be interpreted as
and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
</section> </section>
<section anchor="sec-software-supply-chain-scope"> <section anchor="sec-software-supply-chain-scope">
<name>Software Supply Chain Scope</name> <name>Software Supply Chain Scope</name>
<t>To illustrate the applicability of the SCITT architecture and its messa <t>To illustrate the applicability of the SCITT architecture and its messa
ges, this section details the exemplary context of software supply chain (SSC) u ges, this section details the exemplary context of Software Supply Chain (SSC) u
se cases. se cases.
The building blocks provided by the SCITT architecture are not restricted to sof The building blocks provided by the SCITT architecture are not restricted to SSC
tware supply chain use cases. use cases.
Software supply chains serve as a useful application guidance and first usage sc SSCs serve as useful application guidance and first usage scenarios.</t>
enario.</t>
<section anchor="sec-generic-ssc-problem-statement"> <section anchor="sec-generic-ssc-problem-statement">
<name>Generic SSC Problem Statement</name> <name>Generic SSC Problem Statement</name>
<t>Supply chain security is a prerequisite to protecting consumers and m inimizing economic, public health, and safety threats. <t>Supply chain security is a prerequisite to protecting consumers and m inimizing economic, public health, and safety threats.
Supply chain security has historically focused on risk management practices to s afeguard logistics, meet regulatory requirements, forecast demand, and optimize inventory. Supply chain security has historically focused on risk management practices to s afeguard logistics, meet regulatory requirements, forecast demand, and optimize inventory.
While these elements are foundational to a healthy supply chain, an integrated c While these elements are foundational to a healthy supply chain, an integrated c
yber-security-based perspective of the software supply chains remains broadly un yber-security-based perspective of the SSCs remains broadly undefined.
defined. Recently, the global community has experienced numerous supply chain attacks tar
Recently, the global community has experienced numerous supply chain attacks tar geting weaknesses in SSCs.
geting weaknesses in software supply chains. As illustrated in <xref target="lifecycle-threats"/>, an SSC attack may l
As illustrated in <xref target="lifecycle-threats"/>, a software supply chain at everage one or more life-cycle stages and directly or indirectly target the comp
tack may leverage one or more life-cycle stages and directly or indirectly targe onent.</t>
t 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"> <figure anchor="lifecycle-threats">
<name>Example SSC Life-Cycle Threats</name> <name>Example SSC Life-Cycle Threats</name>
<artset> <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"> <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,80 L 8,144" fill="none" stroke="black"/>
<path d="M 8,176 L 8,240" 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,272 L 8,336" fill="none" stroke="black"/>
<path d="M 8,368 L 8,432" 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,464 L 8,528" fill="none" stroke="black"/>
<path d="M 8,560 L 8,624" fill="none" stroke="black"/> <path d="M 8,560 L 8,624" fill="none" stroke="black"/>
skipping to change at line 182 skipping to change at line 199
<path d="M 8,432 L 104,432" 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,464 L 104,464" fill="none" stroke="black"/>
<path d="M 8,528 L 104,528" 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,560 L 104,560" fill="none" stroke="black"/>
<path d="M 8,624 L 104,624" 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,656 L 104,656" fill="none" stroke="black"/>
<path d="M 8,720 L 104,720" fill="none" stroke="black"/> <path d="M 8,720 L 104,720" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="60" y="36">Dependencies</text> <text x="60" y="36">Dependencies</text>
<text x="208" y="36">Malicious</text> <text x="208" y="36">Malicious</text>
<text x="288" y="36">3rd-party</text> <text x="288" y="36">third-party</text>
<text x="360" y="36">package</text> <text x="360" y="36">package</text>
<text x="404" y="36">or</text> <text x="404" y="36">or</text>
<text x="448" y="36">version</text> <text x="448" y="36">version</text>
<text x="52" y="116">Code</text> <text x="52" y="116">Code</text>
<text x="212" y="116">Compromise</text> <text x="212" y="116">Compromise</text>
<text x="284" y="116">source</text> <text x="284" y="116">source</text>
<text x="344" y="116">control</text> <text x="344" y="116">control</text>
<text x="208" y="196">Malicious</text> <text x="208" y="196">Malicious</text>
<text x="284" y="196">plug-ins</text> <text x="284" y="196">plug-ins</text>
<text x="52" y="212">Commit</text> <text x="52" y="212">Commit</text>
skipping to change at line 247 skipping to change at line 264
<text x="196" y="692">Tamper</text> <text x="196" y="692">Tamper</text>
<text x="244" y="692">with</text> <text x="244" y="692">with</text>
<text x="308" y="692">versioning</text> <text x="308" y="692">versioning</text>
<text x="368" y="692">and</text> <text x="368" y="692">and</text>
<text x="412" y="692">update</text> <text x="412" y="692">update</text>
<text x="472" y="692">process</text> <text x="472" y="692">process</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
Dependencies Malicious 3rd-party package or version Dependencies Malicious third-party package or version
| |
| |
+-----+-----+ +-----+-----+
| | | |
| Code | Compromise source control | Code | Compromise source control
| | | |
+-----+-----+ +-----+-----+
| |
+-----+-----+ +-----+-----+
| | Malicious plug-ins | | Malicious plug-ins
skipping to change at line 295 skipping to change at line 312
| |
+-----+-----+ +-----+-----+
| | | |
| Deploy | Tamper with versioning and update process | Deploy | Tamper with versioning and update process
| | | |
+-----------+ +-----------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>DevSecOps, as defined in <xref target="NIST.SP.800-204C"/>, often dep ends on third-party and open-source software. <t>DevSecOps, as defined in <xref target="NIST.SP.800-204C"/>, often dep ends 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 is difficult. These dependencies can be quite complex throughout the supply chain, so checking provenance and traceability throughout their life cycle is difficult.
There is a need for manageable auditability and accountability of digital produc ts. There is a need for manageable auditability and accountability of digital produc ts.
Typically, the range of types of statements about digital products (and their de pendencies) is vast, heterogeneous, and can differ between community policy requ irements. Typically, the range of types of statements about digital products (and their de pendencies) is vast, heterogeneous, and can differ between community policy requ irements.
Taking the type and structure of all statements about digital products into acco unt might not be possible. Taking the type and structure of all statements about digital products into acco unt might not be possible.
Examples of statements may include commit signatures, build environment and para Examples of statements may include commit signatures, build environment and para
meters, software bill of materials, static and dynamic application security test meters, Software Bill of Materials (SBOM), static and dynamic application securi
ing results, fuzz testing results, release approvals, deployment records, vulner ty testing results, fuzz testing results, release approvals, deployment records,
ability scan results, and patch logs. vulnerability scan results, and patch logs.
In consequence, instead of trying to understand and describe the detailed syntax Consequently, instead of trying to understand and describe the detailed syntax a
and semantics of every type of statement about digital products, the SCITT arch nd semantics of every type of statement about digital products, the SCITT archit
itecture focuses on ensuring statement authenticity, visibility/transparency, an ecture focuses on ensuring statement authenticity, ensuring visibility/transpare
d intends to provide scalable accessibility. ncy, and intends to provide scalable accessibility.
Threats and practical issues can also arise from unintended side-effects of usin Threats and practical issues can also arise from unintended side effects of usin
g security techniques outside their proper bounds. g security techniques outside their proper bounds.
For instance digital signatures may fail to verify past their expiry date even t For instance, digital signatures may fail to verify past their expiry date even
hough the signed item itself remains completely valid. though the signed item itself remains completely valid.
Or a signature may verify even though the information it is securing is now foun d unreliable but fine-grained revocation is too hard.</t> Or a signature may verify even though the information it is securing is now foun d unreliable but fine-grained revocation is too hard.</t>
<t>Lastly, where data exchange underpins serious business decision-makin g, it is important to hold the producers of those data to a higher standard of a uditability. <t>Lastly, where data exchange underpins serious business decision-makin g, it is important to hold the producers of those data to a higher standard of a uditability.
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> 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 o n the generic problem statement above.</t> <t>The following use cases illustrate the scope of SCITT and elaborate o n the generic problem statement above.</t>
</section> </section>
<section anchor="sec-eclectic-ssc-use-cases"> <section anchor="sec-eclectic-ssc-use-cases">
<name>Eclectic SSC Use Cases</name> <name>Eclectic SSC Use Cases</name>
<t>The three following use cases are a specialization derived from the g eneric problem statement above.</t> <t>The three following use cases are a specialization derived from the g eneric problem statement above.</t>
<section anchor="sec-security-analysis-of-a-software-product"> <section anchor="sec-security-analysis-of-a-software-product">
<name>Security Analysis of a Software Product</name> <name>Security Analysis of a Software Product</name>
<t>A released software product is often accompanied by a set of comple mentary statements about its security properties. <t>A released software product is often accompanied by a set of comple mentary statements about its security properties.
This gives enough confidence to both producers and consumers that the released s oftware meets the expected security standards and is suitable to use.</t> This gives enough confidence to both producers and consumers that the released s oftware 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. <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 p ackage.</t> The intention is to identify any security weaknesses or vulnerabilities in the p ackage.</t>
<t>Initially, a particular analysis can identify a simple weakness in a software component. <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 illustrates that the weakn Over a period of time, a statement from a third party illustrates that the weakn
ess is exposed in a way that represents an exploitable vulnerability. ess is exposed in a way that represents an exploitable vulnerability.
The producer of the software product provides a statement that confirms the link The producer of the software product provides a statement that confirms the link
ing of a software component vulnerability with the software product by issuing a ing of a software component vulnerability with the software product by issuing a
product vulnerability disclosure report and also issues an advisory statement o product vulnerability disclosure report and also issuing an advisory statement
n how to mitigate the vulnerability. 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 e xploitation. 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 e xploitation.
Later, a second update of the software product includes a security patch to the affected software component from the software producer. 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. 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> 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> <t>A consumer of a released software wants to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>know where to get these security statements from producers and t hird-parties related to the software product in a timely and unambiguous fashion </li> <li>know where to get these security statements from producers and t hird parties related to the software product in a timely and unambiguous fashion </li>
<li>attribute them to an authoritative issuer</li> <li>attribute them to an authoritative issuer</li>
<li>associate the statements in a meaningful manner via a set of wel l-known semantic relationships</li> <li>associate the statements in a meaningful manner via a set of wel l-known semantic relationships</li>
<li>consistently, efficiently, and homogeneously check their authent icity</li> <li>consistently, efficiently, and homogeneously check their authent icity</li>
</ul> </ul>
<t>SCITT provides a standardized way to:</t> <t>SCITT provides a standardized way to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>know the various sources of statements</li> <li>know the various sources of statements</li>
<li>express the provenance and historicity of statements</li> <li>express the provenance and historicity of statements</li>
<li>relate and link various heterogeneous statements in a simple fas hion</li> <li>relate and link various heterogeneous statements in a simple fas hion</li>
<li>check that the statement comes from a source with authority to i ssue that statement</li> <li>check that the statement comes from a source with authority to i ssue that statement</li>
<li>confirm that sources provide a complete history of statements re lated to a given component</li> <li>confirm that sources provide a complete history of statements re lated to a given component</li>
</ul> </ul>
</section> </section>
<section anchor="sec-promotion-of-a-software-component-by-multiple-entit ies"> <section anchor="sec-promotion-of-a-software-component-by-multiple-entit ies">
<name>Promotion of a Software Component by Multiple Entities</name> <name>Promotion of a Software Component by Multiple Entities</name>
<t>A software component (e.g., a library or software product), open-so <t>A software component (e.g., a library or software product), open-so
urce or commercial, is often initially released by a single trusted producer, wh urce or commercial, is often initially released by a single trusted producer who
o can choose to attach a statement of authenticity to it. can choose to attach a statement of authenticity to it.
As that component becomes used in a growing range of other products, providers o As that component becomes used in a growing range of other products, providers o
ther than the original trusted producer often re-distribute, or release their ow ther than the original trusted producer often re-distribute or release their own
n version of that component.</t> version of that component.</t>
<t>Some providers include it as part of their release product/package <t>Some providers include it as part of their release product or packa
bundle and provide the package with proof of authenticity using their issuer aut ge bundle and provide the package with proof of authenticity using their issuer
hority. authority.
Some packages include the original statement of authenticity, and some do not. Some packages include the original statement of authenticity, and some do not.
Over time, some providers no longer offer the exact same software component sour ce code but pre-compiled software component binaries. Over time, some providers no longer offer the exact same software component sour ce code but pre-compiled software component binaries.
Some sources do not provide the exact same software component, but include patch es and fixes produced by third-parties, as these emerge faster than solutions fr om the original producer. Some sources do not provide the exact same software component but include patche s and fixes produced by third parties as these emerge faster than solutions from the original producer.
Due to complex distribution and promotion life-cycle scenarios, the original sof tware component takes myriad forms.</t> Due to complex distribution and promotion life-cycle scenarios, the original sof tware component takes myriad forms.</t>
<t>A consumer of a released software wants to:</t> <t>A consumer of a released software wants to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>understand if a particular provider is a trusted originating pro ducer or an alternative party</li> <li>understand if a particular provider is a trusted originating pro ducer or an alternative party</li>
<li>know if and how the source, or resulting binary, of a promoted s oftware component differs from the original software component</li> <li>know if and how the source, or resulting binary, of a promoted s oftware component differs from the original software component</li>
<li>check the provenance and history of a software component's sourc e back to its origin</li> <li>check the provenance and history of a software component's sourc e back to its origin</li>
<li>assess whether to trust a component or product based on a downlo aded package location and source supplier</li> <li>assess whether to trust a component or product based on a downlo aded package location and source supplier</li>
</ul> </ul>
<t>SCITT provides a standardized way to:</t> <t>SCITT provides a standardized way to:</t>
<ul spacing="normal"> <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>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 particu lar provider</li> <li>track the provenance path from an original producer to a particu lar provider</li>
<li>check the trustworthiness of a provider</li> <li>check the trustworthiness of a provider</li>
<li>check the integrity of modifications or transformations applied by a provider</li> <li>check the integrity of modifications or transformations applied by a provider</li>
</ul> </ul>
</section> </section>
<section anchor="sec-software-integrator-assembling-a-software-product-f or-a-vehicle"> <section anchor="sec-software-integrator-assembling-a-software-product-f or-a-vehicle">
<name>Software Integrator Assembling a Software Product for a Vehicle< /name> <name>Software Integrator Assembling a Software Product for a Vehicle< /name>
<t>Software Integration is a complex activity. <t>Software integration is a complex activity. Typically, it
This typically involves getting various software components from multiple suppli involves getting various software components from multiple suppliers and produci
ers, producing an integrated package deployed as part of device assembly. ng an integrated package deployed as part of device assembly.
For example, car manufacturers source integrated software for their vehicles fro m third parties that integrate software components from various sources. For example, car manufacturers source integrated software for their vehicles fro m third parties that integrate software components from various sources.
Integration complexity creates a higher risk of security vulnerabilities to the delivered software.</t> Integration complexity creates a higher risk of security vulnerabilities to the delivered software.</t>
<t>Consumers of integrated software want:</t> <t>Consumers of integrated software want:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a list of all components present in a software product</li> <li>a list of all components present in a software product</li>
<li>the ability to identify and retrieve all components from a secur e and tamper-proof location</li> <li>the ability to identify and retrieve all components from a secur e and tamper-proof location</li>
<li>verifiable proofs on build process and build environment with al l supplier tiers to ensure end to end build quality and security</li> <li>verifiable proofs on build process and build environment with al l supplier tiers to ensure end-to-end build quality and security</li>
</ul> </ul>
<t>SCITT provides a standardized way to:</t> <t>SCITT provides a standardized way to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>provide a tiered and transparent framework that allows for verif ication of integrity and authenticity of the integrated software at both compone nt and product level before installation</li> <li>provide a tiered and transparent framework that allows for verif ication of integrity and authenticity of the integrated software at both compone nt and product level before installation</li>
<li>provide valid annotations on build integrity to ensure conforman ce</li> <li>provide valid annotations on build integrity to ensure conforman ce</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The terms defined in this section have special meaning in the context o <t>The terms defined in this section have special meaning in the context o
f Supply Chain Integrity, Transparency, and Trust, and are used throughout this f SCITT and are used throughout this document.</t>
document.</t> <t>This document has been developed in coordination with the COSE, OAUTH,
<t>This document has been developed in coordination with the COSE, OAUTH a and RATS working groups (WGs) and uses terminology common to these WGs as often
nd RATS WG and uses terminology common to these working groups as much as possib as possible.</t>
le.</t>
<t>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 terms "header", "payload", and "to-be-signed bytes" are defined in <xref target="STD96"/>.</t> <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> <t>The term "claim" is defined in <xref target="RFC8392"/>.</t>
<t>When used in text in the sense defined, the following terms are capitalized
.
To ensure readability, only a core set of terms is included in this section.</t>
<dl anchor="mybody"> <dl anchor="mybody">
<dt>Append-only Log:</dt> <dt>Append-only Log:</dt>
<dd> <dd>
<t>a Statement Sequence comprising the entire registration history of <t>a Statement Sequence comprising the entire registration history of
the Transparency Service. the TS.
To make the Append-only property verifiable and transparent, the Transparency Se To make the append-only property verifiable and transparent, the TS defines how
rvice defines how Signed Statements are made available to Auditors.</t> Signed Statements are made available to Auditors.</t>
</dd> </dd>
<dt>Artifact:</dt> <dt>Artifact:</dt>
<dd> <dd>
<t>a physical or non-physical item that is moving along a supply chain .</t> <t>a physical or non-physical item that is moving along a supply chain .</t>
</dd> </dd>
<dt>Attestation:</dt>
<dd>
<t><xref target="NIST.SP.1800-19"/> defines "attestation" as:</t>
<blockquote><t>The process of providing a digital signature for a set o
f measurements securely stored in hardware, and then having the requester valida
te the signature and the set of measurements.</t></blockquote>
<t>NIST guidance "Software Supply Chain Security Guidance EO 14028" <xr
ef target="NIST_EO14028"/> uses the definition from <xref target="ISO_IEC_17000"
/>, which states that an "attestation" is:</t><blockquote>
<t>The issue of a statement, based on a decision, that fulfillment of s
pecified 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>Auditor:</dt> <dt>Auditor:</dt>
<dd> <dd>
<t>an entity that checks the correctness and consistency of all Transp arent Statements, or the transparent Statement Sequence, issued by a Transparenc y Service. <t>an entity that checks the correctness and consistency of all Transp arent Statements, or the transparent Statement Sequence, issued by a TS.
An Auditor is an example of a specialized Relying Party.</t> An Auditor is an example of a specialized Relying Party.</t>
</dd> </dd>
<dt>Client:</dt> <dt>Client:</dt>
<dd> <dd>
<t>an application making protected Transparency Service resource reque sts on behalf of the resource owner and with its authorization.</t> <t>an application making protected TS resource requests on behalf of t he resource owner and with its authorization.</t>
</dd> </dd>
<dt>Envelope:</dt> <dt>Envelope:</dt>
<dd> <dd>
<t>metadata, created by the Issuer to produce a Signed Statement. <t>metadata, created by the Issuer to produce a Signed Statement.
The Envelope contains the identity of the Issuer and information about the Artif act, enabling Transparency Service Registration Policies to validate the Signed Statement. The Envelope contains the identity of the Issuer and information about the Artif act, enabling TS Registration Policies to validate the Signed Statement.
A Signed Statement is a COSE Envelope wrapped around a Statement, binding the me tadata in the Envelope to the Statement. A Signed Statement is a COSE Envelope wrapped around a Statement, binding the me tadata in the Envelope to the Statement.
In COSE, an Envelope consists of a protected header (included in the Issuer's si gnature) and an unprotected header (not included in the Issuer's signature).</t> In COSE, an Envelope consists of a protected header (included in the Issuer's si gnature) and an unprotected header (not included in the Issuer's signature).</t>
</dd> </dd>
<dt>Equivocation:</dt> <dt>Equivocation:</dt>
<dd> <dd>
<t>a state where a Transparency Service provides inconsistent proofs t o Relying Parties, containing conflicting claims about the Signed Statement boun d at a given position in the Verifiable Data Structure.</t> <t>a state where a TS provides inconsistent proofs to Relying Parties, containing conflicting claims about the Signed Statement bound at a given posit ion in the VDS.</t>
</dd> </dd>
<dt>Issuer:</dt> <dt>Issuer:</dt>
<dd> <dd>
<t>an identifier representing an organization, device, user, or entity securing Statements about supply chain Artifacts. <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, or an independent third party An Issuer may be the owner or author of Artifacts or an independent third party
such as an Auditor, reviewer or an endorser. such as an Auditor, reviewer, or endorser.
In SCITT Statements and Receipts, the <tt>iss</tt> Claim is a member of the COSE 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"/>, w header parameter <tt>15: CWT Claims</tt> defined in <xref target="RFC9597"/>, w
hich embeds a CWT Claim Set <xref target="RFC8392"/> within the protected header hich embeds a CBOR Web Token (CWT) Claims Set <xref target="RFC8392"/> within th
of a COSE Envelope. e protected header of a COSE Envelope.
This document uses the terms "Issuer", and "Subject" as described in <xref targe This document uses the terms "Issuer" and "Subject" as described in <xref target
t="RFC8392"/>, however the usage is consistent with the broader interpretation o ="RFC8392"/>; however, the usage is consistent with the broader interpretation o
f these terms in both JOSE and COSE, and the guidance in <xref target="RFC8725"/ f these terms in both JSON Object Signing and Encryption (JOSE) and COSE, and th
> generally applies the COSE equivalent terms with consistent semantics.</t> e guidance in <xref target="RFC8725"/> generally applies the COSE equivalent ter
ms with consistent semantics.</t>
</dd> </dd>
<dt>Non-equivocation:</dt> <dt>Non-equivocation:</dt>
<dd> <dd>
<t>a state where all proofs provided by the Transparency Service to Re <t>a state where all proofs provided by the TS to Relying Parties are
lying Parties are produced from a single Verifiable Data Structure describing a produced from a single VDS describing a unique sequence of Signed Statements and
unique sequence of Signed Statements and are therefore consistent <xref target=" are therefore consistent <xref target="EQUIVOCATION"/>.
EQUIVOCATION"/>. Over time, an Issuer may register new Signed Statements about an Artifact in a T
Over time, an Issuer may register new Signed Statements about an Artifact in a T S with new information.
ransparency Service with new information.
However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.</t> However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.</t>
</dd> </dd>
<dt>Receipt:</dt> <dt>Receipt:</dt>
<dd> <dd>
<t>a cryptographic proof that a Signed Statement is included in the Ve <t>a COSE Single Signer Data Object as defined in <xref target="RFC994
rifiable Data Structure. 2"/>.
See <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> for implementations. See <xref target="RFC9942"/> for implementations.
Receipts are signed proofs of verifiable data-structure properties. Receipts are signed proofs of VDS properties.
Receipt Profiles implemented by a Transparency Service <bcp14>MUST</bcp14> suppo Receipt Profiles implemented by a TS <bcp14>MUST</bcp14> support inclusion proof
rt inclusion proofs and <bcp14>MAY</bcp14> support other proof types, such as co s and <bcp14>MAY</bcp14> support other Proof Types (see <xref section="3" sectio
nsistency proofs.</t> nFormat="of" target="RFC9942"/>), such as consistency proofs.</t>
</dd> </dd>
<dt>Registration:</dt> <dt>Registration:</dt>
<dd> <dd>
<t>the process of submitting a Signed Statement to a Transparency Serv ice, applying the Transparency Service's Registration Policy, adding to the Veri fiable Data Structure, and producing a Receipt.</t> <t>the process of submitting a Signed Statement to a TS, applying the TS's Registration Policy, adding to the VDS, and producing a Receipt.</t>
</dd> </dd>
<dt>Registration Policy:</dt> <dt>Registration Policy:</dt>
<dd> <dd>
<t>the pre-condition enforced by the Transparency Service before regis tering a Signed Statement, based on information in the non-opaque header and met adata contained in its COSE Envelope.</t> <t>the precondition enforced by the TS before registering a Signed Sta tement, based on information in the non-opaque header and metadata contained in its COSE Envelope.</t>
</dd> </dd>
<dt>Relying Party:</dt> <dt>Relying Party:</dt>
<dd> <dd>
<t>Relying Parties consumes Transparent Statements, verifying their pr oofs and inspecting the Statement payload, either before using corresponding Art ifacts, or later to audit an Artifact's provenance on the supply chain.</t> <t>Relying Parties consume Transparent Statements, verifying their pro ofs and inspecting the Statement payload, either before using corresponding Arti facts or later to audit an Artifact's provenance on the supply chain.</t>
</dd> </dd>
<dt>Signed Statement:</dt> <dt>Signed Statement:</dt>
<dd> <dd>
<t>an identifiable and non-repudiable Statement about an Artifact sign ed by an Issuer. <t>an identifiable and non-repudiable Statement about an Artifact sign ed by an Issuer.
In SCITT, Signed Statements are encoded as COSE signed objects; the <tt>payload< In SCITT, Signed Statements are encoded as Enveloped COSE Structures; the <tt>pa
/tt> of the COSE structure contains the issued Statement.</t> yload</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 proc
ess of providing a digital signature for a set of measurements securely stored i
n hardware, and then having the requester validate the signature and the set of
measurements."
NIST guidance "Software Supply Chain Security Guidance EO 14028" uses the defini
tion from <xref target="NIST_EO14028"/>, which states that an "attestation" is "
The issue of a statement, based on a decision, that fulfillment of specified req
uirements has been demonstrated.".
It is often useful for the intended audience to qualify the term "attestation" i
n their specific context to avoid confusion and ambiguity.</t>
</dd> </dd>
<dt>Statement:</dt> <dt>Statement:</dt>
<dd> <dd>
<t>any serializable information about an Artifact. <t>any serializable information about an Artifact.
To help interpretation of Statements, they must be tagged with a relevant media To help interpret Statements, they must be tagged with a relevant media type (as
type (as specified in <xref target="RFC6838"/>). specified in <xref target="RFC6838"/>).
A Statement may represent a Software Bill Of Materials (SBOM) that lists the ing A Statement may represent an SBOM that lists the ingredients of a software Artif
redients of a software Artifact, an endorsement or attestation about an Artifact act, contains an endorsement or attestation about an Artifact, indicates the End
, indicate the End of Life (EOL), redirection to a newer version, or any content of Life (EOL), redirects to a newer version, or contains any content an Issuer
an Issuer wishes to publish about an Artifact. wishes to publish about an Artifact.
Additional Statements about an Artifact are correlated by the Subject Claim as d Additional Statements about an Artifact are correlated by the Subject Claim as d
efined in the IANA CWT <xref target="IANA.cwt"/> registry and used as a protecte efined in the "CBOR Web Token (CWT) Claims" registry <xref target="IANA.cwt"/> a
d header parameter as defined in <xref target="RFC9597"/>. nd used as a protected header parameter as defined in <xref target="RFC9597"/>.
The Statement is considered opaque to Transparency Service, and <bcp14>MAY</bcp1 The Statement is considered opaque to TS and <bcp14>MAY</bcp14> be encrypted.</t
4> be encrypted.</t> >
</dd> </dd>
<dt>Statement Sequence:</dt> <dt>Statement Sequence:</dt>
<dd> <dd>
<t>a sequence of Signed Statements captured by a Verifiable Data Struc ture. <t>a sequence of Signed Statements captured by a VDS.
See Verifiable Data Structure.</t> See Verifiable Data Structure.</t>
</dd> </dd>
<dt>Subject:</dt> <dt>Subject:</dt>
<dd> <dd>
<t>an identifier, defined by the Issuer, which represents the organiza tion, device, user, entity, or Artifact about which Statements (and Receipts) ar e made and by which a logical collection of Statements can be grouped. <t>an identifier, defined by the Issuer, that represents the organizat ion, 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. 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 sequenc e of Signed Statements about the same Artifact and Relying Parties can leverage <tt>sub</tt> to ensure completeness and Non-equivocation across Statements by id entifying all Transparent Statements associated to a specific Subject.</t> 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 sequenc e of Signed Statements about the same Artifact, and Relying Parties can leverage <tt>sub</tt> to ensure completeness and Non-equivocation across Statements by i dentifying all Transparent Statements associated to a specific Subject.</t>
</dd> </dd>
<dt>Transparency Service:</dt> <dt>Transparency Service:</dt>
<dd> <dd>
<t>an entity that maintains and extends the Verifiable Data Structure <t>an entity that maintains and extends the VDS and endorses its state
and endorses its state. .
The identity of a Transparency Service is captured by a public key that must be The identity of a TS is captured by a public key that must be known by Relying P
known by Relying Parties in order to validate Receipts.</t> arties in order to validate Receipts.</t>
</dd> </dd>
<dt>Transparent Statement:</dt> <dt>Transparent Statement:</dt>
<dd> <dd>
<t>a Signed Statement that is augmented with a Receipt created via Reg istration in a Transparency Service. <t>a Signed Statement that is augmented with a Receipt created via Reg istration in a TS.
The Receipt is stored in the unprotected header of COSE Envelope of the Signed S tatement. The Receipt is stored in the unprotected header of COSE Envelope of the Signed S tatement.
A Transparent Statement remains a valid Signed Statement and may be registered a gain in a different Transparency Service.</t> A Transparent Statement remains a valid Signed Statement and may be registered a gain in a different TS.</t>
</dd> </dd>
<dt>Verifiable Data Structure:</dt> <dt>Verifiable Data Structure:</dt>
<dd> <dd>
<t>a data structure which supports one or more proof types, such as "i <t>a data structure defined in <xref target="RFC9942"/> in which Signe
nclusion proofs" or "consistency proofs", for Signed Statements as they are Regi d Statements can be inserted as they are Registered by a TS.
stered to a Transparency Service. SCITT supports multiple VDSs and Receipt formats as defined in <xref target="RFC
SCITT supports multiple Verifiable Data Structures and Receipt formats as define 9942"/>, accommodating different TS implementations.</t>
d in <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, accommodating diff
erent Transparency Service implementations.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-definition-of-transparency"> <section anchor="sec-definition-of-transparency">
<name>Definition of Transparency</name> <name>Definition of Transparency</name>
<t>In this document, the definition of transparency is intended to build o <t>In this document, the definition of transparency is intended to build o
ver abstract notions of Append-only Logs and Receipts. ver abstract notions of append-only Logs and Receipts.
Existing transparency systems such as Certificate Transparency <xref target="RFC Existing transparency systems such as CT <xref target="RFC9162"/> are instances
9162"/> are instances of this definition. of this definition.
SCITT supports multiple Verifiable Data Structures, as defined in <xref target=" SCITT supports multiple VDSs, as defined in <xref target="RFC9942"/>.</t>
I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t>
<t>A Signed Statement is an identifiable and non-repudiable Statement made by an Issuer. <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 m ost cases, a signature) using the identity key of the Issuer that binds the Stat ement and its metadata. The Issuer selects additional metadata and attaches a proof of endorsement (in m ost cases, a signature) using the identity key of the Issuer that binds the Stat ement and its metadata.
Signed Statements can be made transparent by attaching a proof of Registration b Signed Statements can be made transparent by attaching a proof of Registration b
y a Transparency Service, in the form of a Receipt. y a TS in the form of a Receipt.
Receipts demonstrate inclusion of Signed Statements in the Verifiable Data Struc Receipts demonstrate inclusion of Signed Statements in the VDS of a TS.
ture of a Transparency Service. By extension, the Signed Statement may say an Artifact (for example, a firmware
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
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
its author or owner, though the context should make it clear what type of Signed Statement is expected for a given Artifact.</t>
Statements is expected for a given Artifact.</t>
<t>Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable. <t>Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.
Any Artifact that may be verified, is subject to scrutiny and auditing by other Any Artifact that may be verified is subject to scrutiny and auditing by other p
parties. arties.
The Transparency Service provides a history of Statements, which may be made by The TS provides a history of Statements, which may be made by multiple Issuers,
multiple Issuers, enabling Relying Parties to make informed decisions.</t> enabling Relying Parties to make informed decisions.</t>
<t>Transparency is implemented by providing a consistent, append-only, cry ptographically verifiable, publicly available record of entries. <t>Transparency is implemented by providing a consistent, append-only, cry ptographically verifiable, publicly available record of entries.
Implementations of Transparency Services may protect their registered sequence o Implementations of TSs may protect their registered sequence of Signed Statement
f Signed Statements and Verifiable Data Structure using a combination of trusted s and VDS using a combination of trusted hardware, consensus protocols, and cryp
hardware, consensus protocols, and cryptographic evidence. tographic evidence.
A Receipt is a signature over one or more Verifiable Data Structure Proofs that A Receipt is a signature over one or more VDP that a Signed Statement is registe
a Signed Statement is registered in the Verifiable Data Structure. red in the VDS.
It is universally verifiable without online access to the TS. 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. 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 paramet ers or other claims <bcp14>MAY</bcp14> change each time a Receipt is produced.</ t> A Receipt's verification key, signing algorithm, validity period, header paramet ers 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 <t>Anyone with access to the TS can independently verify its consistency a
its consistency and review the complete list of Transparent Statements register nd review the complete list of Transparent Statements registered by each Issuer.
ed by each Issuer.</t> </t>
<t>Reputable Issuers are thus incentivized to carefully review their State <t>Thus, reputable Issuers are incentivized to carefully review their Stat
ments before signing them to produce Signed Statements. ements before signing them to produce Signed Statements.
Similarly, reputable Transparency Services are incentivized to secure their Veri Similarly, reputable TSs are incentivized to secure their VDS, as any inconsiste
fiable Data Structure, as any inconsistency can easily be pinpointed by any Audi ncy can easily be pinpointed by any Auditor with read access to the TS.</t>
tor with read access to the Transparency Service.</t> <t>The building blocks specified in this document enable the unequivocal a
<t>The building blocks specified in this document enable the unequivocal a nd auditable production of statements about software supply chain artifacts. The
nd auditable production of statements about software supply chain artifacts. The extensible design of the SCITT architecture potentially allows future usage wit
extensible design of the SCITT architecture potentially allows future usage wit h other supply chains in different domains, for example, advanced manufacturing
h other supply chains in different domains, for example advanced manufacturing o or food supply.</t>
r food supply.</t> <t>SCITT is a generalization of CT <xref target="RFC9162"/>, which can be
<t>SCITT is a generalization of Certificate Transparency (CT) <xref target interpreted as a transparency architecture for the supply chain of X.509 certifi
="RFC9162"/>, which can be interpreted as a transparency architecture for the su cates.
pply chain of X.509 certificates.
Considering CT in terms of SCITT:</t> Considering CT in terms of SCITT:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to <li>Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER-encoded t
produce an X.509 certificate (Signed Statements)</li> bsCertificate structure to produce an X.509 certificate (Signed Statements)</li>
<li>CAs submit the certificates to one or more CT logs (Transparency Ser <li>CAs submit the certificates to one or more CT logs (TSs)</li>
vices)</li>
<li>CT logs produce Signed Certificate Timestamps (Transparent Statement s)</li> <li>CT logs produce Signed Certificate Timestamps (Transparent Statement s)</li>
<li>Signed Certificate Timestamps, Signed Tree Heads, and their respecti ve consistency proofs are checked by Relying Parties</li> <li>Signed Certificate Timestamps, Signed Tree Heads, and their respecti ve consistency proofs are checked by Relying Parties</li>
<li>The Verifiable Data Structure can be checked by Auditors</li> <li>The VDS can be checked by Auditors</li>
</ul> </ul>
</section> </section>
<section anchor="sec-architecture-overview"> <section anchor="sec-architecture-overview">
<name>Architecture Overview</name> <name>Architecture Overview</name>
<t>The SCITT architecture enables Transparency Services in a given applica <t>The SCITT architecture enables TSs in a given application domain to imp
tion domain to implement a collective baseline, by providing a set of common for lement a collective baseline by providing a set of common formats and protocols
mats and protocols for issuing and registering Signed Statements and auditing Tr for issuing and registering Signed Statements and auditing Transparent Statement
ansparent Statements.</t> s.</t>
<t>In order to accommodate as many Transparency Service implementations as <t>In order to accommodate as many TS implementations as possible, this do
possible, this document only specifies the format of Signed Statements (which m cument only specifies the format of Signed Statements (which must be used by all
ust be used by all Issuers) and a very thin wrapper format for Receipts, which s Issuers) and a very thin wrapper format for Receipts, which specifies the TS id
pecifies the Transparency Service identity and the agility parameters for the Si entity and the agility parameters for the signed proofs.
gned Inclusion Proofs. The remaining details of the Receipt's contents are specified in <xref target="R
The remaining details of the Receipt's contents are specified in <xref target="I FC9942"/>.</t>
-D.draft-ietf-cose-merkle-tree-proofs"/>.</t> <t><xref target="fig-concept-relationship"/> illustrates the roles and pro
<t><xref target="fig-concept-relationship"/> illustrates the roles and pro cesses that comprise a TS independent of any one use case:</t>
cesses that comprise a Transparency Service independent of any one use case:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Issuers that use their credentials to create Signed Statements about <li>Issuers that use their credentials to create Signed Statements about
Artifacts</li> Artifacts.</li>
<li>Transparency Services that evaluate Signed Statements against Regist <li>TSs that evaluate Signed Statements against Registration Policies pr
ration Policies, producing Receipts upon successful Registration. oducing Receipts upon successful Registration.
The returned Receipt may be combined with the Signed Statement to create a Trans parent Statement.</li> The returned Receipt may be combined with the Signed Statement to create a Trans parent Statement.</li>
<li> <li>
<t>Relying Parties that: <t>Relying Parties that:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>collect Receipts of Signed Statements for subsequent registratio n of Transparent Statements;</li> <li>collect Receipts of Signed Statements for subsequent registratio n of Transparent Statements;</li>
<li>retrieve Transparent Statements for analysis of Statements about <li>retrieve Transparent Statements for analysis of Statements about
Artifacts themselves (e.g. verification);</li> Artifacts themselves (e.g., verification);</li>
<li>or replay all the Transparent Statements to check for the consis <li>or replay all the Transparent Statements to check for the consis
tency and correctness of the Transparency Service's Verifiable Data Structure (e tency and correctness of the TS's VDS (e.g., auditing).</li>
.g. auditing)</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>In addition, <xref target="fig-concept-relationship"/> illustrates mult <t>In addition, <xref target="fig-concept-relationship"/> illustrates mult
iple Transparency Services and multiple Receipts as a single Signed Statement <b iple TSs and multiple Receipts as a single Signed Statement <bcp14>MAY</bcp14> b
cp14>MAY</bcp14> be registered with one or more Transparency Service. e registered with one or more TS.
Each Transparency Service produces a Receipt, which may be aggregated in a singl Each TS produces a Receipt, which may be aggregated in a single Transparent Stat
e Transparent Statement, demonstrating the Signed Statement was registered by mu ement, demonstrating the Signed Statement was registered by multiple TSs.</t>
ltiple Transparency Services.</t>
<t>The arrows indicate the flow of information.</t> <t>The arrows indicate the flow of information.</t>
<figure anchor="fig-concept-relationship"> <figure anchor="fig-concept-relationship">
<name>Relationship of Concepts in SCITT</name> <name>Relationship of Concepts in SCITT</name>
<artset> <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"> <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 8,224 L 8,240" fill="none" stroke="black"/>
<path d="M 32,448 L 32,480" 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 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,64 L 56,88" fill="none" stroke="black"/>
<path d="M 56,128 L 56,200" fill="none" stroke="black"/> <path d="M 56,128 L 56,200" fill="none" stroke="black"/>
skipping to change at line 768 skipping to change at line 793
v v v v v v v v
.--------+---------. .--+--------------+--. .------+----------. .--------+---------. .--+--------------+--. .------+----------.
/ Collect Receipts / / Verify Transparent / / Replay Log / / Collect Receipts / / Verify Transparent / / Replay Log /
'--+---------------+ / Statement / '-+---------------+ '--+---------------+ / Statement / '-+---------------+
| Relying Party | '----+---------------+ | Relying Party | | Relying Party | '----+---------------+ | Relying Party |
+---------------+ | Relying Party | +---------------+ +---------------+ | Relying Party | +---------------+
+---------------+ +---------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more de tail.</t> <t>The subsequent sections describe the main concepts, namely TS, Signed S tatements, Registration, and Transparent Statements in more detail.</t>
<section anchor="sec-transparency-service"> <section anchor="sec-transparency-service">
<name>Transparency Service</name> <name>Transparency Service</name>
<t>Transparency Services <bcp14>MUST</bcp14> produce COSE Receipts <xref <t>TSs <bcp14>MUST</bcp14> produce COSE Receipts <xref target="RFC9942"/
target="I-D.draft-ietf-cose-merkle-tree-proofs"/>.</t> >.</t>
<t>Typically a Transparency Service has a single Issuer identity which i <t>Typically, a TS has a single Issuer identity that is present in the <
s present in the <tt>iss</tt> Claim of Receipts for that service.</t> tt>iss</tt> Claim of Receipts for that service.</t>
<t>Multi-tenant support can be enabled through the use of identifiers in <t>Multi-tenant support can be enabled through the use of identifiers in
the <tt>iss</tt> Claim, for example, <tt>ts.example.</tt> may have a distinct I the <tt>iss</tt> Claim; for example, <tt>ts.example.</tt> may have a distinct I
ssuer identity for each sub domain, such as <tt>tenant1.ts.example.</tt> and <tt ssuer identity for each subdomain, such as "<tt>tenant1.ts.example.</tt>" and "<
>tenant2.ts.example.</tt>.</t> tt>tenant2.ts.example.</tt>".</t>
<section anchor="sec-registration-policies"> <section anchor="sec-registration-policies">
<name>Registration Policies</name> <name>Registration Policies</name>
<t>Registration Policies refer to additional checks over and above the <t>Registration Policies refer to additional checks over and above the
Mandatory Registration Checks that are performed before a Signed Statement is r mandatory Registration checks that are performed before a Signed Statement is r
egistered to the Verifiable Data Structure. egistered to the VDS.
To enable audit-ability, Transparency Services <bcp14>MUST</bcp14> maintain Regi To enable auditability, TSs <bcp14>MUST</bcp14> maintain Registration Policies.
stration Policies.
The presence of an explicit transparent registration policy, even if it allows a ll authenticated submissions, facilitates service audit, and enables potential f uture changes to that policy.</t> The presence of an explicit transparent registration policy, even if it allows a ll authenticated submissions, facilitates service audit, and enables potential f uture changes to that policy.</t>
<t>Beyond the mandatory Registration checks, the scope of additional c hecks, including no additional checks, is up to the implementation.</t> <t>Beyond the mandatory Registration checks, the scope of additional c hecks, including no additional checks, is up to the implementation.</t>
<t>This specification leaves implementation, encoding and documentatio <t>This specification leaves implementation, encoding, and documentati
n of Registration Policies and trust anchors to the operator of the Transparency on of Registration Policies and trust anchors to the operator of the TS.</t>
Service.</t>
<section anchor="sec-mandatory-registration-checks"> <section anchor="sec-mandatory-registration-checks">
<name>Mandatory Registration Checks</name> <name>Mandatory Registration Checks</name>
<t>During Registration, a Transparency Service <bcp14>MUST</bcp14> s yntactically check the Issuer of the Signed Statement by cryptographically verif ying the COSE signature according to <xref target="STD96"/>. <t>During Registration, a TS <bcp14>MUST</bcp14> syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE sign ature according to <xref target="STD96"/>.
The Issuer identity <bcp14>MUST</bcp14> be bound to the Signed Statement by incl uding an identifier in the protected header. The Issuer identity <bcp14>MUST</bcp14> be bound to the Signed Statement by incl uding an identifier in the protected header.
If the protected header includes multiple identifiers, all those that are regist If the protected header includes multiple identifiers, all those that are regist
ered by the Transparency Service <bcp14>MUST</bcp14> be checked.</t> ered by the TS <bcp14>MUST</bcp14> be checked.</t>
<t>Transparency Services <bcp14>MUST</bcp14> maintain a list of trus <t>TSs <bcp14>MUST</bcp14> maintain a list of trust anchors (see def
t anchors (see definition of trust anchor in <xref target="RFC4949"/>) in order inition of trust anchor in <xref target="RFC4949"/>) in order to check the signa
to check the signatures of Signed Statements, either separately, or inside Regis tures of Signed Statements either separately or inside Registration Policies.
tration Policies. TSs <bcp14>MUST</bcp14> authenticate Signed Statements as part of a R
Transparency Services <bcp14>MUST</bcp14> authenticate Signed Statements as part egistration Policy. For instance, a trust anchor could be an X.509 root certifi
of a Registration Policy. cate (directly or its thumbprint), a pointer to an OpenID Connect identity provi
For instance, a trust anchor could be an X.509 root certificate (directly or its der, or any other trust anchor that can be referenced in a COSE header parameter
thumbprint), a pointer to an OpenID Connect identity provider, or any other tru .</t>
st anchor that can be referenced in a COSE header parameter.</t> <t>When using X.509 Signed Statements, the TS <bcp14>MUST</bcp14> bu
<t>When using X.509 Signed Statements, the Transparency Service <bcp ild and validate a complete certification path from an Issuer's certificate to o
14>MUST</bcp14> build and validate a complete certification path from an Issuer' ne of the root certificates currently registered as a trust anchor by the TS.
s certificate to one of the root certificates currently registered as a trust an
chor by the Transparency Service.
The protected header of the COSE_Sign1 Envelope <bcp14>MUST</bcp14> include eith er 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"/>. The protected header of the COSE_Sign1 Envelope <bcp14>MUST</bcp14> include eith er 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 i ncluded in the unprotected header.</t> 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 i ncluded in the unprotected header.</t>
<t>Registration Policies and trust anchors <bcp14>MUST</bcp14> be ma <t>Registration Policies and trust anchors <bcp14>MUST</bcp14> be ma
de Transparent and available to all Relying Parties of the Transparency Service de Transparent and available to all Relying Parties of the TS by Registering the
by Registering them as Signed Statements on the Verifiable Data Structure.</t> m as Signed Statements on the VDS.</t>
<t>The Transparency Service <bcp14>MUST</bcp14> apply the Registrati <t>The TS <bcp14>MUST</bcp14> apply the Registration Policy that was
on Policy that was most recently committed to the Verifiable Data Structure at t most recently committed to the VDS at the time of Registration.</t>
he time of Registration.</t>
</section> </section>
<section anchor="sec-auditability-of-registration"> <section anchor="sec-auditability-of-registration">
<name>Auditability of Registration</name> <name>Auditability of Registration</name>
<t>The operator of a Transparency Service <bcp14>MAY</bcp14> update <t>The operator of a TS <bcp14>MAY</bcp14> update the Registration P
the Registration Policy or the trust anchors of a Transparency Service at any ti olicy or the trust anchors of a TS at any time.</t>
me.</t> <t>TSs <bcp14>MUST</bcp14> ensure that for any Signed Statement they
<t>Transparency Services <bcp14>MUST</bcp14> ensure that for any Sig register, enough information is made available to Auditors to reproduce the Reg
ned Statement they register, enough information is made available to Auditors to istration checks that were defined by the Registration Policies at the time of R
reproduce the Registration checks that were defined by the Registration Policie egistration.
s 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 Reg istration Policy at the time of Registration.</t> At a minimum, this consists of the Signed Statements themselves, any additional collateral data required to perform their authentication, and the applicable Reg istration Policy at the time of Registration.</t>
</section> </section>
</section> </section>
<section anchor="ts-initialization"> <section anchor="ts-initialization">
<name>Initialization and Bootstrapping</name> <name>Initialization and Bootstrapping</name>
<t>Since the mandatory Registration checks rely on having registered S igned Statements for the Registration Policy and trust anchors, Transparency Ser vices <bcp14>MUST</bcp14> support at least one of the three following bootstrapp ing mechanisms:</t> <t>Since the mandatory Registration checks rely on having registered S igned Statements for the Registration Policy and trust anchors, TSs <bcp14>MUST< /bcp14> support at least one of the three following bootstrapping mechanisms:</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Pre-configured Registration Policy and trust anchors;</li> <li>Preconfigured Registration Policy and trust anchors;</li>
<li>Acceptance of a first Signed Statement whose payload is a valid <li>Acceptance of a first Signed Statement whose payload is a valid
Registration Policy, without performing Registration checks</li> Registration Policy, without performing Registration checks; or</li>
<li>An out-of-band authenticated management interface</li> <li>An out-of-band authenticated management interface.</li>
</ul> </ul>
</section> </section>
<section anchor="sec-verifiable-data-structure"> <section anchor="sec-verifiable-data-structure">
<name>Verifiable Data Structure</name> <name>Verifiable Data Structure</name>
<t>The security properties are determined by the choice of the Verifia <t>The security properties are determined by the choice of the VDS (se
ble Data Structure (<xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>) use e <xref target="RFC9942"/>) used by the TS implementation.
d by the Transparency Service implementation. This VDS <bcp14>MUST</bcp14> support the following security requirements:</t>
This verifiable data structure <bcp14>MUST</bcp14> support the following securit
y requirements:</t>
<dl> <dl>
<dt>Append-Only:</dt> <dt>Append-only:</dt>
<dd> <dd>
<t>a property required for a verifiable data structure to be appli cable to SCITT, ensuring that the Statement Sequence cannot be modified, deleted , or reordered.</t> <t>a property required for a VDS to be applicable to SCITT, ensuri ng that the Statement Sequence cannot be modified, deleted, or reordered.</t>
</dd> </dd>
<dt>Non-equivocation:</dt> <dt>Non-equivocation:</dt>
<dd> <dd>
<t>there is no fork in the registered sequence of Signed Statement s accepted by the Transparency Service and committed to the Verifiable Data Stru cture. <t>there is no fork in the registered sequence of Signed Statement s accepted by the TS and committed to the VDS.
Everyone with access to its content sees the same ordered collection of Signed S tatements and can check that it is consistent with any Receipts they have verifi ed.</t> Everyone with access to its content sees the same ordered collection of Signed S tatements and can check that it is consistent with any Receipts they have verifi ed.</t>
</dd> </dd>
<dt>Replayability:</dt> <dt>Replayability:</dt>
<dd> <dd>
<t>the Verifiable Data Structure includes sufficient information t o enable authorized actors with access to its content to check that each data st ructure representing each Signed Statement has been correctly registered.</t> <t>the VDS includes sufficient information to enable authorized ac tors with access to its content to check that each data structure representing e ach Signed Statement has been correctly registered.</t>
</dd> </dd>
</dl> </dl>
<t>In addition to Receipts, some verifiable data structures might supp <t>In addition to Receipts, some VDSs might support additional Proof T
ort additional proof types, such as proofs of consistency, or proofs of non-incl ypes, such as proofs of consistency or proofs of non-inclusion.</t>
usion.</t> <t>Specific VDSs, such those describes in <xref target="RFC9162"/> and
<t>Specific verifiable data structures, such those describes in <xref <xref target="RFC9942"/>, and the review of their security requirements for SCI
target="RFC9162"/> and <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/>, TT are out of scope for this document.</t>
and the review of their security requirements for SCITT are out of scope for thi
s document.</t>
</section> </section>
<section anchor="sec-adjacent-services"> <section anchor="sec-adjacent-services">
<name>Adjacent Services</name> <name>Adjacent Services</name>
<t>Transparency Services can be deployed along side other database or <t>TSs can be deployed alongside other database or object storage tech
object storage technologies. nologies.
For example, a Transparency Service that supports a software package management For example, a TS that supports a software package management system, might be r
system, might be referenced from the APIs exposed for package management. eferenced from the APIs exposed for package management.
It can also provide the ability to request a fresh Receipt for a given software It can also provide the ability to request a fresh Receipt for a given software
package, or a list of Signed Statements associated with that package.</t> package or a list of Signed Statements associated with that package.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="signed-statements"> <section anchor="signed-statements">
<name>Signed Statements</name> <name>Signed Statements</name>
<t>This specification prioritizes conformance to <xref target="STD96"/> an d its required and optional properties. <t>This specification prioritizes conformance to <xref target="STD96"/> an d its required and optional properties.
Signed Statements produced by Issuers must be COSE_Sign1 messages, as defined by <xref target="STD96"/>. Signed Statements produced by Issuers must be COSE_Sign1 messages, as defined by <xref target="STD96"/>.
Profiles and implementation specific choices should be used to determine admissi bility of conforming messages. Profiles and implementation-specific choices should be used to determine admissi bility of conforming messages.
This specification is left intentionally open to allow implementations to make R egistration restrictions that make the most sense for their operational use case s.</t> This specification is left intentionally open to allow implementations to make R egistration restrictions that make the most sense for their operational use case s.</t>
<t>There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statemen ts. <t>There are many types of Statements (such as an SBOM, malware scans, aud it reports, policy definitions) that Issuers may want to turn into Signed Statem ents.
An Issuer must first decide on a suitable format (<tt>3</tt>: payload type) to s erialize the Statement payload. An Issuer must first decide on a suitable format (<tt>3</tt>: payload type) to s erialize the Statement payload.
For a software supply chain, payloads describing the software Artifacts may incl For a software supply chain, payloads describing the software Artifacts ma
ude:</t> y include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<xref target="CoSWID"/> Concise Software Identification Tags format</l i> Concise Software Identification Tags format <xref target="RFC9393"/></ li>
<li> <li>
<xref target="CycloneDX"/> Bill of Materials format</li> Bill of Materials format <xref target="CycloneDX"/></li>
<li> <li>
<xref target="in-toto"/> Supply chain description metadata</li> Supply chain description metadata <xref target="in-toto"/></li>
<li> <li>
<xref target="SPDX-CBOR"/> Software component description format</li> Software component description format <xref target="SPDX-CBOR"/></li>
<li> <li>
<xref target="SPDX-JSON"/> Software component description format</li> Software component description format <xref target="SPDX-CBOR"/></li>
<li> <li>
<xref target="SLSA"/> Supply-chain Levels for Software Artifacts</li> Supply-chain Levels for Software Artifacts <xref target="SLSA"/></li>
<li> <li>
<xref target="SWID"/> Software Identification Tag format</li> Software Identification Tag format <xref target="SWID"/></li>
</ul> </ul>
<t>Issuers can produce Signed Statements about different Artifacts under t he same Identity. <t>Issuers can produce Signed Statements about different Artifacts under t he same Identity.
Issuers and Relying Parties must be able to recognize the Artifact to which the Statements pertain by looking at the Signed Statement. 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> protect ed header, are used to identify the Artifact the Statement pertains to. The <tt>iss</tt> and <tt>sub</tt> Claims, within the <tt>CWT Claims</tt> protect ed header, are used to identify the Artifact the Statement pertains to.
(See Subject under <xref target="terminology"/> Terminology.)</t> (See Subject in <xref target="terminology"/>.)</t>
<t>Issuers <bcp14>MAY</bcp14> use different signing keys (identified by <t <t>Issuers <bcp14>MAY</bcp14> use different signing keys (identified by <t
t>kid</tt> in the <xref target="STD96"/> protected header) for different Artifac t>kid</tt> in the protected header from <xref target="STD96"/>) for different Ar
ts or sign all Signed Statements under the same key.</t> tifacts or sign all Signed Statements under the same key.</t>
<t>An Issuer can make multiple Statements about the same Artifact. <t>An Issuer can make multiple Statements about the same Artifact.
For example, an Issuer can make amended Statements about the same Artifact as th eir view changes over time.</t> For example, an Issuer can make amended Statements about the same Artifact as th eir view changes over time.</t>
<t>Multiple Issuers can make different, even conflicting Statements, about the same Artifact. <t>Multiple Issuers can make different, even conflicting, Statements about the same Artifact.
Relying Parties can choose which Issuers they trust.</t> Relying Parties can choose which Issuers they trust.</t>
<t>Multiple Issuers can make the same Statement about a single Artifact, a ffirming multiple Issuers agree.</t> <t>Multiple Issuers can make the same Statement about a single Artifact, a ffirming multiple Issuers agree.</t>
<t>Additionally, <tt>x5chain</tt> that corresponds to either <tt>x5t</tt> or <tt>kid</tt> identifying the leaf certificate in the included certification p ath <bcp14>MAY</bcp14> be included in the unprotected header of the COSE Envelop e.</t> <t>Additionally, an <tt>x5chain</tt> that corresponds to either <tt>x5t</t t> or <tt>kid</tt> identifying the leaf certificate in the included certificatio n path <bcp14>MAY</bcp14> be included in the unprotected header of the COSE Enve lope.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>When using x.509 certificates, support for either <tt>x5t</tt> or <t t>x5chain</tt> in the protected header is <bcp14>REQUIRED</bcp14> to implement.< /li> <li>When using X.509 certificates, support for either <tt>x5t</tt> or <t t>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> <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> </ul>
<t>When <tt>x5t</tt> or <tt>x5chain</tt> is present in the protected heade <t>When <tt>x5t</tt> or <tt>x5chain</tt> is present in the protected heade
r, <tt>iss</tt> <bcp14>MUST</bcp14> be a string that meets URI requirements defi r, the <tt>iss</tt> Claim value <bcp14>MUST</bcp14> be a string that meets URI r
ned in <xref target="RFC8392"/>. equirements defined in <xref target="RFC8392"/>.
The <tt>iss</tt> value's length <bcp14>MUST</bcp14> be between 1 and 8192 charac The <tt>iss</tt> Claim value's length <bcp14>MUST</bcp14> be between 1 and 8192
ters in length.</t> characters in Length.</t>
<t>The <tt>kid</tt> header parameter <bcp14>MUST</bcp14> be present when n either <tt>x5t</tt> nor <tt>x5chain</tt> is present in the protected header. <t>The <tt>kid</tt> header parameter <bcp14>MUST</bcp14> be present when n either <tt>x5t</tt> nor <tt>x5chain</tt> is present in the protected header.
Key discovery protocols are out-of-scope of this document.</t> Key discovery protocols are out of scope of this document.</t>
<t>The protected header of a Signed Statement and a Receipt <bcp14>MUST</b cp14> include the <tt>CWT Claims</tt> header parameter as specified in <xref sec tion="2" sectionFormat="of" target="RFC9597"/>. <t>The protected header of a Signed Statement and a Receipt <bcp14>MUST</b cp14> include the <tt>CWT Claims</tt> header parameter as specified in <xref sec tion="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> 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. <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> See <xref target="RFC9942"/>.</t>
<section anchor="sec-signed-statement-examples"> <section anchor="sec-signed-statement-examples">
<name>Signed Statement Examples</name> <name>Signed Statement Examples</name>
<t><xref target="fig-signed-statement-cddl"/> illustrates a normative CD DL definition <xref target="RFC8610"/> for the protected header and unprotected header of Signed Statements and Receipts.</t> <t><xref target="fig-signed-statement-cddl"/> illustrates a normative CD DL 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. <t>The SCITT architecture specifies the minimal mandatory labels.
Implementation-specific Registration Policies may define additional mandatory la bels.</t> Implementation-specific Registration Policies may define additional mandatory la bels.</t>
<figure anchor="fig-signed-statement-cddl"> <figure anchor="fig-signed-statement-cddl">
<name>CDDL definition for Signed Statements and Receipts</name> <name>CDDL Definition for Signed Statements and Receipts</name>
<sourcecode type="cddl"> <sourcecode type="cddl"><![CDATA[
Signed_Statement = #6.18(COSE_Sign1) Signed_Statement = /6.18(COSE_Sign1)
Receipt = #6.18(COSE_Sign1) Receipt = /6.18(COSE_Sign1)
COSE_Sign1 = [ COSE_Sign1 = [
protected : bstr .cbor Protected_Header, protected : bstr .cbor Protected_Header,
unprotected : Unprotected_Header, unprotected : Unprotected_Header,
payload : bstr / nil, payload : bstr / nil,
signature : bstr signature : bstr
] ]
Protected_Header = { Protected_Header = {
&amp;(CWT_Claims: 15) =&gt; CWT_Claims &(CWT_Claims: 15) => CWT_Claims
? &amp;(alg: 1) =&gt; int ? &(alg: 1) => int
? &amp;(content_type: 3) =&gt; tstr / uint ? &(content_type: 3) => tstr / uint
? &amp;(kid: 4) =&gt; bstr ? &(kid: 4) => bstr
? &amp;(x5t: 34) =&gt; COSE_CertHash ? &(x5t: 34) => COSE_CertHash
? &amp;(x5chain: 33) =&gt; COSE_X509 ? &(x5chain: 33) => COSE_X509
* label =&gt; any * label => any
} }
CWT_Claims = { CWT_Claims = {
&amp;(iss: 1) =&gt; tstr &(iss: 1) => tstr
&amp;(sub: 2) =&gt; tstr &(sub: 2) => tstr
* label =&gt; any * label => any
} }
Unprotected_Header = { Unprotected_Header = {
? &amp;(x5chain: 33) =&gt; COSE_X509 ? &(x5chain: 33) => COSE_X509
? &amp;(receipts: 394) =&gt; [+ Receipt] ? &(receipts: 394) => [+ Receipt]
* label =&gt; any * label => any
} }
label = int / tstr label = int / tstr]]></sourcecode>
</sourcecode>
</figure> </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. <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, and ensure Signed Statements can int egrate with existing storage systems.</t> Detached payloads support large Statements and ensure Signed Statements can inte grate with existing storage systems.</t>
<figure anchor="fig-signed-statement-edn"> <figure anchor="fig-signed-statement-edn">
<name>CBOR Extended Diagnostic Notation example of a Signed Statement< <name>CBOR-Extended Diagnostic Notation Example of a Signed Statement<
/name> /name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18( / COSE_Sign1 / 18( / COSE_Sign1 /
[ [
h'a4012603...6d706c65', / Protected / h'a4012603...6d706c65', / Protected /
{}, / Unprotected / {}, / Unprotected /
nil, / Detached payload / nil, / Detached payload /
h'79ada558...3a28bae4' / Signature / h'79ada558...3a28bae4' / Signature /
] ]
) )]]></sourcecode>
</sourcecode>
</figure> </figure>
<t><xref target="fig-signed-statement-protected-header-edn"/> illustrate s the decoded protected header of the Signed Statement in <xref target="fig-sign ed-statement-edn"/>. <t><xref target="fig-signed-statement-protected-header-edn"/> illustrate s the decoded protected header of the Signed Statement in <xref target="fig-sign ed-statement-edn"/>.
It indicates the Signed Statement is securing a JSON content type, and identifyi ng the content with the <tt>sub</tt> Claim "vendor.product.example".</t> It indicates the Signed Statement is securing a JSON content type and identifyin g the content with the <tt>sub</tt> Claim "vendor.product.example".</t>
<figure anchor="fig-signed-statement-protected-header-edn"> <figure anchor="fig-signed-statement-protected-header-edn">
<name>CBOR Extended Diagnostic Notation example of a Signed Statement' <name>CBOR-Extended Diagnostic Notation Example of a Signed Statement'
s Protected Header</name> s Protected Header</name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
{ / Protected / { / Protected /
1: -7, / Algorithm / 1: -7, / Algorithm /
3: application/example+json, / Content type / 3: application/example+json, / Content type /
4: h'50685f55...50523255', / Key identifier / 4: h'50685f55...50523255', / Key identifier /
15: { / CWT Claims / 15: { / CWT Claims /
1: software.vendor.example, / Issuer / 1: software.vendor.example, / Issuer /
2: vendor.product.example, / Subject / 2: vendor.product.example, / Subject /
} }
} }]]></sourcecode>
</sourcecode>
</figure> </figure>
</section> </section>
<section anchor="sec-signing-large-or-sensitive-statements"> <section anchor="sec-signing-large-or-sensitive-statements">
<name>Signing Large or Sensitive Statements</name> <name>Signing Large or Sensitive Statements</name>
<t>Statements payloads might be too large or too sensitive to be sent to <t>Statement payloads might be too large or too sensitive to be sent to
a remote Transparency Service. a remote TS.
In these cases a Statement can be made over the hash of a payload, rather than t In these cases, a Statement can be made over the hash of a payload rather
he full payload bytes.</t> than the full payload bytes.</t>
<figure anchor="fig6">
<name>Workflow for Signing Large or Sensitive Statements</name>
<artset> <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"> <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,112 L 8,144" fill="none" stroke="black"/>
<path d="M 8,416 L 8,432" 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,64 L 40,80" fill="none" stroke="black"/>
<path d="M 40,176 L 40,200" 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,64 L 56,104" fill="none" stroke="black"/>
<path d="M 56,456 L 56,480" 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,512 L 56,584" fill="none" stroke="black"/>
<path d="M 56,656 L 56,680" fill="none" stroke="black"/> <path d="M 56,656 L 56,680" fill="none" stroke="black"/>
skipping to change at line 1145 skipping to change at line 1171
/ / / \ / / / \
/ Sign +<------+ To Be Signed Bytes | / Sign +<------+ To Be Signed Bytes |
/ / \ / / / \ /
'-----+-------' '----------------' '-----+-------' '----------------'
v v
.----+-------. .----+-------.
| COSE_Sign1 | | COSE_Sign1 |
'------------' '------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure>
</section> </section>
<section anchor="sec-registration-of-signed-statements"> <section anchor="sec-registration-of-signed-statements">
<name>Registration of Signed Statements</name> <name>Registration of Signed Statements</name>
<t>To register a Signed Statement, the Transparency Service performs the following steps:</t> <t>To register a Signed Statement, the TS performs the following steps:< /t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
<strong>Client authentication:</strong> A Client authenticates with
the Transparency Service before registering Signed Statements on behalf of one o <t>Client Authentication</t> <t>A Client authenticates with the TS b
r more Issuers. efore registering Signed Statements on behalf of one or more Issuers.
Authentication and authorization are implementation-specific and out of scope of Authentication and authorization are implementation specific and out of scope of
the SCITT architecture.</li> the SCITT architecture.</t></li>
<li> <li>
<strong>TS Signed Statement Verification and Validation:</strong> Th <t>TS Signed Statement Verification and Validation</t><t>The TS <bcp
e Transparency Service <bcp14>MUST</bcp14> perform signature verification per <x 14>MUST</bcp14> perform signature verification per Section <xref section="4.4" s
ref section="4.4" sectionFormat="of" target="STD96"/> and <bcp14>MUST</bcp14> ve ectionFormat="bare" target="RFC9052"/> of RFC 9052 <xref target="STD96"/> and <b
rify the signature of the Signed Statement with the signature algorithm and veri cp14>MUST</bcp14> verify the signature of the Signed Statement with the signatur
fication key of the Issuer per <xref target="RFC9360"/>. e algorithm and verification key of the Issuer per <xref target="RFC9360"/>.
The Transparency Service <bcp14>MUST</bcp14> also check the Signed Statement inc The TS <bcp14>MUST</bcp14> also check that the Signed Statement includes the req
ludes the required protected headers. uired protected headers.
The Transparency Service <bcp14>MAY</bcp14> validate the Signed Statement payloa The TS <bcp14>MAY</bcp14> validate the Signed Statement payload in order to enfo
d in order to enforce domain specific registration policies that apply to specif rce domain-specific registration policies that apply to specific content types.<
ic content types.</li> /t></li>
<li> <li>
<strong>Apply Registration Policy:</strong> The Transparency Service <t>Apply Registration Policy</t><t>The TS <bcp14>MUST</bcp14> check
<bcp14>MUST</bcp14> check the attributes required by a Registration Policy are the attributes required by a Registration Policy are present in the protected he
present in the protected headers. aders.
Custom Signed Statements are evaluated given the current Transparency Service Custom Signed Statements are evaluated given the current TS state and the enti
state and the entire Envelope and may use information contained in the attribute re Envelope and may use information contained in the attributes of named policie
s of named policies.</li> s.</t></li>
<li> <li>
<strong>Register the Signed Statement</strong></li> <t>Register the Signed Statement</t></li>
<li> <li>
<strong>Return the Receipt</strong>, which <bcp14>MAY</bcp14> be asy <t>Return the Receipt</t> <t>This <bcp14>MAY</bcp14> be asynchronous
nchronous from Registration. from Registration.
The Transparency Service <bcp14>MUST</bcp14> be able to provide a Receipt for al The TS <bcp14>MUST</bcp14> be able to provide a Receipt for all registered Signe
l registered Signed Statements. d Statements.
Details about generating Receipts are described in <xref target="Receipt"/>.</li Details about generating Receipts are described in <xref target="Receipt"/>.</t>
> </li>
</ol> </ol>
<t>The last two steps may be shared between a batch of Signed Statements <t>The last two steps may be shared between a batch of Signed Statements
registered in the Verifiable Data Structure.</t> registered in the VDS.</t>
<t>A Transparency Service <bcp14>MUST</bcp14> ensure that a Signed State <t>A TS <bcp14>MUST</bcp14> ensure that a Signed Statement is registered
ment is registered before releasing its Receipt.</t> before releasing its Receipt.</t>
<t>A Transparency Service <bcp14>MAY</bcp14> accept a Signed Statement w <t>A TS <bcp14>MAY</bcp14> accept a Signed Statement with content in its
ith content in its unprotected header, and <bcp14>MAY</bcp14> use values from th unprotected header and <bcp14>MAY</bcp14> use values from that unprotected head
at unprotected header during verification and registration policy evaluation.</t er during verification and registration policy evaluation.</t>
>
<t>However, the unprotected header of a Signed Statement <bcp14>MUST</bc p14> be set to an empty map before the Signed Statement can be included in a Sta tement Sequence.</t> <t>However, the unprotected header of a Signed Statement <bcp14>MUST</bc p14> be set to an empty map before the Signed Statement can be included in a Sta tement Sequence.</t>
<t>The same Signed Statement may be independently registered in multiple <t>The same Signed Statement may be independently registered in multiple
Transparency Services, producing multiple, independent Receipts. TSs, producing multiple independent Receipts.
The multiple Receipts may be attached to the unprotected header of the Signed St The multiple Receipts may be attached to the unprotected header of the Signed St
atement, creating a Transparent Statement.</t> atement creating a Transparent Statement.</t>
<t>An Issuer that knows of a changed state of quality for an Artifact, < <t>An Issuer that knows of a changed state of quality for an Artifact <b
bcp14>SHOULD</bcp14> Register a new Signed Statement, using the same <tt>15</tt> cp14>SHOULD</bcp14> Register a new Signed Statement using the same <tt>15</tt> C
CWT <tt>iss</tt> and <tt>sub</tt> Claims.</t> WT <tt>iss</tt> and <tt>sub</tt> Claims.</t>
</section> </section>
</section> </section>
<section anchor="Receipt"> <section anchor="Receipt">
<name>Transparent Statements</name> <name>Transparent Statements</name>
<t>The Client (which is not necessarily the Issuer) that registers a Signe d Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the unprotected header of the Signed Statement. <t>The Client (which is not necessarily the Issuer) that registers a Signe d 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 o ne or more Issuers. Client applications <bcp14>MAY</bcp14> register Signed Statements on behalf of o ne or more Issuers.
Client applications <bcp14>MAY</bcp14> request Receipts regardless of the identi ty of the Issuer of the associated Signed Statement.</t> Client applications <bcp14>MAY</bcp14> request Receipts regardless of the identi ty of the Issuer of the associated Signed Statement.</t>
<t>When a Signed Statement is registered by a Transparency Service a Recei <t>When a Signed Statement is registered by a TS a Receipt becomes availab
pt becomes available. le.
When a Receipt is included in a Signed Statement a Transparent Statement is prod When a Receipt is included in a Signed Statement, a Transparent Statement is pro
uced.</t> duced.</t>
<t>Receipts are based on Signed Inclusion Proofs as described in COSE Rece <t>Receipts are based on signed proofs as described in COSE Receipts <xref
ipts <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> that also provides target="RFC9942"/>, which also provides the COSE header parameter semantics for
the COSE header parameter semantics for label 394.</t> label 394.</t>
<t>The Registration time is recorded as the timestamp when the Transparenc <t>The Registration time is recorded as the timestamp when the TS added th
y Service added the Signed Statement to its Verifiable Data Structure.</t> e Signed Statement to its VDS.</t>
<t><xref target="fig-transparent-statement-cddl"/> illustrates a normative CDDL definition of Transparent Statements. <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 'C OSE_Sign1' as specified in <xref section="4.2" sectionFormat="of" target="STD96" /></t> See <xref target="fig-signed-statement-cddl"/> for the CDDL rule that defines CO SE_Sign1 as specified in Section <xref section="4.2" sectionFormat="bare" target ="RFC9052"/> of RFC 9052 <xref target="STD96"/>.</t>
<figure anchor="fig-transparent-statement-cddl"> <figure anchor="fig-transparent-statement-cddl">
<name>CDDL definition for a Transparent Statement</name> <name>CDDL Definition for a Transparent Statement</name>
<sourcecode type="cddl"> <sourcecode type="cddl"><![CDATA[
Transparent_Statement = #6.18(COSE_Sign1) Transparent_Statement = /6.18(COSE_Sign1)
Unprotected_Header = { Unprotected_Header = {
&amp;(receipts: 394) =&gt; [+ Receipt] &(receipts: 394) => [+ Receipt]
} }]]></sourcecode>
</sourcecode>
</figure> </figure>
<t><xref target="fig-transparent-statement-edn"/> illustrates a Transparen <t><xref target="fig-transparent-statement-edn"/> illustrates a Transparen
t Statement with a detached payload, and two Receipts in its unprotected header. t Statement with a detached payload and two Receipts in its unprotected header.
The type of label 394 <tt>receipts</tt> in the unprotected header is a CBOR arra The type of label 394 <tt>receipts</tt> in the unprotected header is a CBOR arra
y that can contain one or more Receipts (each entry encoded as a .cbor encoded R y that can contain one or more Receipts (each entry encoded as a .cbor-encoded R
eceipts).</t> eceipt).</t>
<figure anchor="fig-transparent-statement-edn"> <figure anchor="fig-transparent-statement-edn">
<name>CBOR Extended Diagnostic Notation example of a Transparent Stateme <name>CBOR-Extended Diagnostic Notation Example of a Transparent Stateme
nt</name> nt</name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18( / COSE_Sign1 / 18( / COSE_Sign1 /
[ [
h'a4012603...6d706c65', / Protected / h'a4012603...6d706c65', / Protected /
{ / Unprotected / { / Unprotected /
394: [ / Receipts (2) / 394: [ / Receipts (2) /
h'd284586c...4191f9d2' / Receipt 1 / h'd284586c...4191f9d2' / Receipt 1 /
h'c624586c...8f4af97e' / Receipt 2 / h'c624586c...8f4af97e' / Receipt 2 /
] ]
}, },
nil, / Detached payload / nil, / Detached payload /
h'79ada558...3a28bae4' / Signature / h'79ada558...3a28bae4' / Signature /
] ]
) )]]></sourcecode>
</sourcecode>
</figure> </figure>
<t><xref target="fig-receipt-edn"/> one of the decoded Receipt from <xref <t><xref target="fig-receipt-edn"/> illustrates one of the decoded Receipt
target="fig-transparent-statement-edn"/>. s from <xref target="fig-transparent-statement-edn"/>.
The Receipt contains inclusion proofs for verifiable data structures. The Receipt contains inclusion proofs for VDSs.
The unprotected header contains verifiable data structure proofs. The unprotected header contains VDP.
See the protected header for details regarding the specific verifiable data stru See the protected header for details regarding the specific VDS used.
cture used. Per the "COSE Verifiable Data Structure Algorithms" registry documented in <xref
Per the COSE Verifiable Data Structure Algorithms Registry documented in <xref t target="RFC9942"/>, the COSE Key Type RFC9162_SHA256 is value <tt>1</tt>.
arget="I-D.draft-ietf-cose-merkle-tree-proofs"/>, the COSE key type RFC9162_SHA2
56 is value <tt>1</tt>.
Labels identify inclusion proofs (<tt>-1</tt>) and consistency proofs (<tt>-2</t t>).</t> Labels identify inclusion proofs (<tt>-1</tt>) and consistency proofs (<tt>-2</t t>).</t>
<figure anchor="fig-receipt-edn"> <figure anchor="fig-receipt-edn">
<name>CBOR Extended Diagnostic Notation example of a Receipt</name> <name>CBOR-Extended Diagnostic Notation Example of a Receipt</name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
18( / COSE_Sign1 / 18( / COSE_Sign1 /
[ [
h'a4012604...6d706c65', / Protected / h'a4012604...6d706c65', / Protected /
{ / Unprotected / { / Unprotected /
-222: { / Proofs / -222: { / Proofs /
-1: [ / Inclusion proofs (1) / -1: [ / Inclusion proofs (1) /
h'83080783...32568964', / Inclusion proof 1 / h'83080783...32568964', / Inclusion proof 1 /
] ]
}, },
}, },
nil, / Detached payload / nil, / Detached payload /
h'10f6b12a...4191f9d2' / Signature / h'10f6b12a...4191f9d2' / Signature /
] ]
) )]]></sourcecode>
</sourcecode>
</figure> </figure>
<t><xref target="fig-receipt-protected-header-edn"/> illustrates the decod ed protected header of the Transparent Statement in <xref target="fig-transparen t-statement-edn"/>. <t><xref target="fig-receipt-protected-header-edn"/> illustrates the decod ed protected header of the Transparent Statement in <xref target="fig-transparen t-statement-edn"/>.
The verifiable data structure (<tt>-111</tt>) uses <tt>1</tt> from (RFC9162_SHA2 56).</t> The VDS (<tt>-111</tt>) uses <tt>1</tt> from RFC9162_SHA256.</t>
<figure anchor="fig-receipt-protected-header-edn"> <figure anchor="fig-receipt-protected-header-edn">
<name>CBOR Extended Diagnostic Notation example of a Receipt's Protected <name>CBOR-Extended Diagnostic Notation Example of a Receipt's Protected
Header</name> Header</name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
{ / Protected / { / Protected /
1: -7, / Algorithm / 1: -7, / Algorithm /
4: h'50685f55...50523255', / Key identifier / 4: h'50685f55...50523255', / Key identifier /
-111: 1, / Verifiable Data Structure / -111: 1, / Verifiable Data Structure /
15: { / CWT Claims / 15: { / CWT Claims /
1: transparency.vendor.example, / Issuer / 1: transparency.vendor.example, / Issuer /
2: vendor.product.example, / Subject / 2: vendor.product.example, / Subject /
} }
} }]]></sourcecode>
</sourcecode>
</figure> </figure>
<t><xref target="fig-receipt-inclusion-proof-edn"/> illustrates the decode d inclusion proof from <xref target="fig-receipt-edn"/>. <t><xref target="fig-receipt-inclusion-proof-edn"/> illustrates the decode d inclusion proof from <xref target="fig-receipt-edn"/>.
This inclusion proof indicates that the size of the Verifiable Data Structure wa This inclusion proof indicates that the size of the VDS was <tt>8</tt> at the ti
s <tt>8</tt> at the time the Receipt was issued. me the Receipt was issued.
The structure of this inclusion proof is specific to the verifiable data structu The structure of this inclusion proof is specific to the VDS used by RFC9162_SHA
re used (RFC9162_SHA256).</t> 256.</t>
<figure anchor="fig-receipt-inclusion-proof-edn"> <figure anchor="fig-receipt-inclusion-proof-edn">
<name>CBOR Extended Diagnostic Notation example of a Receipt's Inclusion <name>CBOR-Extended Diagnostic Notation Example of a Receipt's Inclusion
Proof</name> Proof</name>
<sourcecode type="cbor-diag"> <sourcecode type="cbor-diag"><![CDATA[
[ / Inclusion proof 1 / [ / Inclusion proof 1 /
8, / Tree size / 8, / Tree size /
7, / Leaf index / 7, / Leaf index /
[ / Inclusion hashes (3) / [ / Inclusion hashes (3) /
h'c561d333...f9850597' / Intermediate hash 1 / h'c561d333...f9850597' / Intermediate hash 1 /
h'75f177fd...2e73a8ab' / Intermediate hash 2 / h'75f177fd...2e73a8ab' / Intermediate hash 2 /
h'0bdaaed3...32568964' / Intermediate hash 3 / h'0bdaaed3...32568964' / Intermediate hash 3 /
] ]
] ]]]></sourcecode>
</sourcecode>
</figure> </figure>
<section anchor="validation"> <section anchor="validation">
<name>Validation</name> <name>Validation</name>
<t>Relying Parties <bcp14>MUST</bcp14> apply the verification process as described in <xref section="4.4" sectionFormat="of" target="STD96"/>, when chec king the signature of Signed Statements and Receipts.</t> <t>Relying Parties <bcp14>MUST</bcp14> apply the verification process as described in Section <xref section="4.4" sectionFormat="bare" target="RFC9052"/ > of RFC 9052 <xref target="STD96"/> when checking the signature of Signed State ments and Receipts.</t>
<t>A Relying Party <bcp14>MUST</bcp14> trust the verification key or cer tificate and the associated identity of at least one Issuer of a Receipt.</t> <t>A Relying Party <bcp14>MUST</bcp14> trust the verification key or cer tificate 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 Rec eipt that is acceptable to them and not check the signature on the Signed Statem ent or Receipts which rely on verifiable data structures which they do not under stand.</t> <t>A Relying Party <bcp14>MAY</bcp14> decide to verify only a single Rec eipt that is acceptable to them and not check the signature on the Signed Statem ent or Receipts that rely on VDSs they do not understand.</t>
<t>APIs exposing verification logic for Transparent Statements may provi de more details than a single boolean result. <t>APIs exposing verification logic for Transparent Statements may provi de more details than a single boolean result.
For example, an API may indicate if the signature on the Receipt or Signed State ment is valid, if Claims related to the validity period are valid, or if the inc lusion proof in the Receipt is valid.</t> For example, an API may indicate if the signature on the Receipt or Signed State ment is valid, if Claims related to the validity period are valid, or if the inc lusion proof in the Receipt is valid.</t>
<t>Relying Parties <bcp14>MAY</bcp14> be configured to re-verify the Iss uer's Signed Statement locally.</t> <t>Relying Parties <bcp14>MAY</bcp14> be configured to re-verify the Iss uer's Signed Statement locally.</t>
<t>In addition, Relying Parties <bcp14>MAY</bcp14> apply arbitrary valid ation policies after the Transparent Statement has been verified and validated. <t>In addition, Relying Parties <bcp14>MAY</bcp14> apply arbitrary valid ation 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> 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> </section>
<section anchor="sec-privacy-considerations"> <section anchor="sec-privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Interactions with Transparency Services are expected to use appropriate <t>Interactions with TSs are expected to use appropriately strong encrypti
ly strong encryption and authorization technologies.</t> on and authorization technologies.</t>
<t>The Transparency Service is trusted with the confidentiality of the Sig <t>The TS is trusted with the confidentiality of the Signed Statements pre
ned Statements presented for Registration. sented for Registration.
Issuers and Clients are responsible for verifying that the Transparency Service' Issuers and Clients are responsible for verifying that the TS's privacy and secu
s privacy and security posture is suitable for the contents of the Signed Statem rity posture is suitable for the contents of the Signed Statements they submit p
ents they submit prior to Registration. rior to Registration.
Issuers must carefully review the inclusion of private, confidential, or persona Issuers must carefully review the inclusion of private, confidential, or Persona
lly identifiable information (PII) in their Statements against the Transparency lly Identifiable Information (PII) in their Statements against the TS's privacy
Service's privacy posture.</t> posture.</t>
<t>In some deployments a special role such as an Auditor might require and <t>In some deployments, a special role such as an Auditor might require and be g
be given access to both the Transparency Service and related Adjacent Services. iven access to both the TS and related Adjacent Services.</t>
</t>
<t>Transparency Services can leverage Verifiable Data Structures which onl <t>TSs can leverage VDSs that only retain cryptographic metadata (e.g., a
y retain cryptographic metadata (e.g. a hash), rather than the complete Signed S hash) rather than the complete Signed Statement as part of an in-depth defensive
tatement, as part of a defense in depth approach to maintaining confidentiality. approach to maintaining confidentiality.
By analyzing the relationship between data stored in the Transparency Service an By analyzing the relationship between data stored in the TS and data stored in A
d data stored in Adjacent Services, it is possible to perform metadata analysis, djacent Services, it is possible to perform metadata analysis, which could revea
which could reveal the order in which artifacts were built, signed, and uploade l the order in which artifacts were built, signed, and uploaded.</t>
d.</t>
</section> </section>
<section anchor="SecConSec"> <section anchor="SecConSec">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>SCITT provides the following security guarantees:</t> <t>SCITT provides the following security guarantees:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Statements made by Issuers about supply chain Artifacts are identifi <li>Statements made by Issuers about supply chain Artifacts are identifi
able and can be authenticated</li> able and can be authenticated.</li>
<li>Statement provenance and history can be independently and consistent <li>Statement provenance and history can be independently and consistent
ly audited</li> ly audited.</li>
<li>Issuers can efficiently prove that their Statement is logged by a Tr <li>Issuers can efficiently prove that their Statement is logged by a TS
ansparency Service</li> .</li>
</ol> </ol>
<t>The first guarantee is achieved by requiring Issuers to sign their Stat ements. <t>The first guarantee is achieved by requiring Issuers to sign their Stat ements.
The second guarantee is achieved by proving a Signed Statement is present in a V erifiable Data Structure. The second guarantee is achieved by proving a Signed Statement is present in a V DS.
The third guarantee is achieved by the combination of both of these steps.</t> 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, Relyin g Parties can use the history of registered Signed Statements to decide which Is suers they choose to trust. <t>In addition to deciding whether to trust a TS, 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> This decision process is out of scope of this document.</t>
<section anchor="sec-ordering-of-signed-statements"> <section anchor="sec-ordering-of-signed-statements">
<name>Ordering of Signed Statements</name> <name>Ordering of Signed Statements</name>
<t>Statements are signed prior to submitting to a SCITT Transparency ser vice. <t>Statements are signed prior to submitting to a SCITT Transparency ser vice.
Unless advertised in the Transparency Service Registration Policy, the Relying P arty cannot assume that the ordering of Signed Statements in the Verifiable Data Structure matches the ordering of their issuance.</t> Unless advertised in the TS Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the VDS matches the ordering of their issuance.</t>
</section> </section>
<section anchor="sec-accuracy-of-statements"> <section anchor="sec-accuracy-of-statements">
<name>Accuracy of Statements</name> <name>Accuracy of Statements</name>
<t>Issuers can make false Statements either intentionally or unintention ally; registering a Statement only proves it was produced by an Issuer. <t>Issuers can make false Statements either intentionally or unintention ally; registering a Statement only proves it was produced by an Issuer.
A registered Statement may be superseded by a subsequently submitted Signed Stat ement from the same Issuer, with the same subject in the <tt>CWT Claims</tt> pro tected header. A registered Statement may be superseded by a subsequently submitted Signed Stat ement from the same Issuer, with the same subject in the <tt>CWT Claims</tt> pro tected header.
Other Issuers may make new Statements to reflect new or corrected information. Other Issuers may make new Statements to reflect new or corrected information.
Relying Parties may choose to include or exclude Statements from Issuers to dete rmine the accuracy of a collection of Statements.</t> Relying Parties may choose to include or exclude Statements from Issuers to dete rmine the accuracy of a collection of Statements.</t>
</section> </section>
<section anchor="sec-issuer-participation"> <section anchor="sec-issuer-participation">
<name>Issuer Participation</name> <name>Issuer Participation</name>
<t>Issuers can refuse to register their Statements with a Transparency S <t>Issuers can refuse to register their Statements with a TS or selectiv
ervice, or selectively submit some but not all the Statements they issue. ely submit some but not all the Statements they issue.
It is important for Relying Parties not to accept Signed Statements for which th It is important for Relying Parties not to accept Signed Statements for which th
ey cannot discover Receipts issued by a Transparency Service they trust.</t> ey cannot discover Receipts issued by a TS they trust.</t>
</section> </section>
<section anchor="sec-key-management"> <section anchor="sec-key-management">
<name>Key Management</name> <name>Key Management</name>
<t>Issuers and Transparency Services <bcp14>MUST</bcp14>:</t> <t>Issuers and TSs <bcp14>MUST</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>carefully protect their private signing keys</li> <li>carefully protect their private signing keys</li>
<li>avoid using keys for more than one purpose</li> <li>avoid using keys for more than one purpose</li>
<li>rotate their keys at a cryptoperiod (defined in <xref target="RFC4 949"/>) appropriate for the key algorithm and domain-specific regulations</li> <li>rotate their keys at a cryptoperiod (defined in <xref target="RFC4 949"/>) appropriate for the key-algorithm and domain-specific regulations</li>
</ul> </ul>
<section anchor="sec-verifiable-data-structure-1"> <section anchor="sec-verifiable-data-structure-1">
<name>Verifiable Data Structure</name> <name>Verifiable Data Structure</name>
<t>The security considerations for specific Verifiable Data Structures <t>The security considerations for specific VDSs are out of scope for
are out of scope for this document. this document.
See <xref target="I-D.draft-ietf-cose-merkle-tree-proofs"/> for the generic secu See <xref target="RFC9942"/> for the generic security considerations that apply
rity considerations that apply to Verifiable Data Structure and Receipts.</t> to VDSs and Receipts.</t>
</section> </section>
<section anchor="sec-key-compromise"> <section anchor="sec-key-compromise">
<name>Key Compromise</name> <name>Key Compromise</name>
<t>It is important for Issuers and Transparency Services to clearly co <t>It is important for Issuers and TSs to clearly communicate when key
mmunicate when keys are compromised, so that Signed Statements can be rejected b s are compromised so that Signed Statements can be rejected by TSs or Receipts c
y Transparency Services or Receipts can be ignored by Relying Parties. an be ignored by Relying Parties.
Transparency Services whose receipt signing keys have been compromised can roll TSs whose receipt signing keys have been compromised can roll back their Stateme
back their Statement Sequence to a point before compromise, establish new creden nt Sequence to a point before compromise, establish new credentials, and use the
tials, and use them to issue fresh Receipts going forward. new credentials to issue fresh Receipts going forward.
Issuers are encouraged to follow existing best practices if their credentials ar e compromised. Issuers are encouraged to follow existing best practices if their credentials ar e compromised.
Revocation strategies for compromised keys are out of scope for this document.</ t> Revocation strategies for compromised keys are out of scope for this document.</ t>
</section> </section>
<section anchor="sec-bootstrapping"> <section anchor="sec-bootstrapping">
<name>Bootstrapping</name> <name>Bootstrapping</name>
<t>Bootstrapping mechanisms that solely rely on Statement registration <t>Bootstrapping mechanisms that solely rely on Statement registration
to set and update registration policy can be audited without additional impleme to set and update registration policy can be audited without additional impleme
ntation-specific knowledge, and are therefore preferable. ntation-specific knowledge; therefore, they are preferable.
Mechanisms that rely on pre-configured values and do not allow updates are unsui Mechanisms that rely on preconfigured values and do not allow updates are unsuit
table for use in long-lived service deployments, in which the ability to patch a able for use in long-lived service deployments in which the ability to patch a p
potentially faulty policy is essential.</t> otentially faulty policy is essential.</t>
</section> </section>
</section> </section>
<section anchor="MediaTypeSecConSec"> <section anchor="MediaTypeSecConSec">
<name>Implications of Media-Type Usage</name> <name>Implications of 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. <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. The payload media type (content type) is included in the COSE envelope header.
<xref target="STD96"/> describes the security implications of reliance on this h eader parameter.</t> <xref target="STD96"/> describes the security implications of reliance on this h eader parameter.</t>
<t>Both media types describe COSE_Sign1 messages, which include a signat ure, and therefore provide integrity protection.</t> <t>Both media types describe COSE_Sign1 messages, which include a signat ure and therefore provide integrity protection.</t>
</section> </section>
<section anchor="sec-cryptographic-agility"> <section anchor="sec-cryptographic-agility">
<name>Cryptographic Agility</name> <name>Cryptographic Agility</name>
<t>Because the SCITT Architecture leverages <xref target="STD96"/> for S tatements and Receipts, it benefits from the format's cryptographic agility.</t> <t>Because the SCITT architecture leverages <xref target="STD96"/> for S tatements and Receipts, it benefits from the format's cryptographic agility.</t>
</section> </section>
<section anchor="sec-threat-model"> <section anchor="sec-threat-model">
<name>Threat Model</name> <name>Threat Model</name>
<t>This section provides a generic threat model for SCITT, describing it <t>This section provides a generic threat model for SCITT, describing it
s residual security properties when some of its actors (Issuers, Transparency Se s residual security properties when some of its actors (Issuers, TSs, and Audito
rvices, and Auditors) are either corrupt or compromised.</t> rs) are either corrupt or compromised.</t>
<t>SCITT primarily supports checking of Signed Statement authenticity, b <t>SCITT primarily supports checking of Signed Statement authenticity, b
oth from the Issuer (authentication) and from the Transparency Service (transpar oth from the Issuer (authentication) and from the TS (transparency).
ency). Issuers and TSs can both be compromised.</t>
Issuers and Transparency Services can both be compromised.</t> <t>The SCITT architecture does not require trust in a single centralized
<t>The SCITT Architecture does not require trust in a single centralized TS.
Transparency Service. Different actors may rely on different TSs, each registering a subset of Signed
Different actors may rely on different Transparency Services, each registering a Statements subject to their own policy.
subset of Signed Statements subject to their own policy. Running multiple, independent TSs provides different organizations to represent
Running multiple, independent Transparency Services provides different organizat consistent or divergent opinions.
ions to represent consistent or divergent opinions. It is the role of the relying party to decide which TSs and Issuers they choose
It is the role of the relying party to decide which Transparency Services and Is to trust for their scenario.</t>
suers they choose to trust for their scenario.</t> <t>In both cases, the SCITT architecture provides generic, universally v
<t>In both cases, the SCITT architecture provides generic, universally-v erifiable cryptographic proofs to hold Issuers or TSs accountable.
erifiable cryptographic proofs to hold Issuers or Transparency Services accounta
ble.
On one hand, this enables valid actors to detect and disambiguate malicious acto rs who employ Equivocation with Signed Statements to different entities. On one hand, this enables valid actors to detect and disambiguate malicious acto rs 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, and out of scope of the SCITT architecture.</t> On the other hand, their liability and the resulting damage to their reputation are application specific and out of scope of the SCITT architecture.</t>
<t>Relying Parties and Auditors need not be trusted by other actors. <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 inf rastructure they cannot "frame" an Issuer or a Transparency Service for Signed S tatements they did not issue or register.</t> So long as actors maintain proper control of their signing keys and identity inf rastructure they cannot "frame" an Issuer or a TS for Signed Statements they did not issue or register.</t>
</section> </section>
</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+co
se
https://www.iana.org/assignments/media-types/application/scitt-receipt+cose,
-->
<section anchor="sec-iana-considerations"> <section anchor="sec-iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register:</t> <t>IANA has registered the following media types in the "application" subr egistry of the "Media Types" registry group <xref target="IANA.media-types"/>:</ t>
<ul spacing="normal"> <ul spacing="normal">
<li>the media type application/scitt-statement+cose in the "Media Types" <li>application/scitt-statement+cose (see <xref target="sec-media-type-a
registry, see below.</li> pplicationscitt-statementcose-registration"/>)</li>
<li>the media type application/scitt-receipt+cose in the "Media Types" r <li>application/scitt-receipt+cose (see <xref target="sec-media-type-app
egistry, see below.</li> licationscitt-receiptcose-registration"/>)</li>
</ul> </ul>
<section anchor="sec-media-type-applicationscitt-statementcose-registratio n"> <section anchor="sec-media-type-applicationscitt-statementcose-registratio n">
<name>Media Type application/scitt-statement+cose Registration</name> <name>Registration of application/scitt-statement+cose</name>
<t>IANA is requested to add the following Media-Type to the "Media Types
" registry <xref target="IANA.media-types"/>.</t>
<table anchor="new-media-types-scitt-statement"> <table anchor="new-media-types-scitt-statement">
<name>SCITT Signed Statement Media Type Registration</name> <name>SCITT Signed Statement Media Type Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Template</th> <th align="left">Template</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">scitt-statement+cose</td> <td align="left">scitt-statement+cose</td>
<td align="left">application/scitt-statement+cose</td> <td align="left">application/scitt-statement+cose</td>
<td align="left"> <td align="left">
<xref target="signed-statements"/> of RFCthis</td> <xref target="signed-statements"/> of RFC 9943</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<dl spacing="compact"> <dl>
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>statement+cose</t> <t>statement+cose</t>
</dd> </dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>binary (CBOR data item)</t> <t>binary (CBOR data item)</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t><xref target="MediaTypeSecConSec"/> of RFCthis</t> <t><xref target="MediaTypeSecConSec"/> of RFC 9943</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>none</t> <t>none</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>RFCthis</t> <t>RFC 9943</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Used to provide an identifiable and non-repudiable Statement abou t an Artifact signed by an Issuer.</t> <t>Used to provide an identifiable and non-repudiable Statement abou t an Artifact signed by an Issuer.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd><t><br/></t>
<dl> <dl spacing="compact">
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd> <dd>
<t>.scitt</t> <t>.scitt</t>
</dd> </dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person &amp; email address to contact for further information:</dt >
<dd> <dd>
<t>iesg@ietf.org</t> iesg@ietf.org
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>none</t> <t>none</t>
</dd> </dd>
<dt>Author/Change controller:</dt> <dt>Author/Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-media-type-applicationscitt-receiptcose-registration" > <section anchor="sec-media-type-applicationscitt-receiptcose-registration" >
<name>Media Type application/scitt-receipt+cose Registration</name> <name>Registration of application/scitt-receipt+cose Registration</name>
<table anchor="new-media-types-receipt"> <table anchor="new-media-types-receipt">
<name>SCITT Receipt Media Type Registration</name> <name>SCITT Receipt Media Type Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Template</th> <th align="left">Template</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">scitt-receipt+cose</td> <td align="left">scitt-receipt+cose</td>
<td align="left">application/scitt-receipt+cose</td> <td align="left">application/scitt-receipt+cose</td>
<td align="left"> <td align="left">
<xref target="Receipt"/> of RFCthis</td> <xref target="Receipt"/> of RFC 9943</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<dl spacing="compact"> <dl>
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>
<t>application</t> <t>application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>
<t>receipt+cose</t> <t>receipt+cose</t>
</dd> </dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>
<t>binary (CBOR data item)</t> <t>binary (CBOR data item)</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t><xref target="MediaTypeSecConSec"/> of RFCthis</t> <t><xref target="MediaTypeSecConSec"/> of RFC 9943</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>
<t>none</t> <t>none</t>
</dd> </dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd>
<t>RFCthis</t> <t>RFC 9943</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>
<t>Used to establish or verify transparency over Statements. Typical ly emitted by a Transparency Service, for the benefit of Relying Parties wanting to ensure Non-equivocation over all or part of a Statement Sequence.</t> <t>Used to establish or verify transparency over Statements. Typical ly emitted by a TS for the benefit of Relying Parties wanting to ensure Non-equi vocation over all or part of a Statement Sequence.</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>
<t>n/a</t> <t>N/A</t>
</dd> </dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd> <dd><t><br/></t>
<dl> <dl spacing="compact">
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd> <dd>
<t>.receipt</t> <t>.receipt</t>
</dd> </dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd> <dd>
<t>N/A</t> <t>N/A</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person &amp; email address to contact for further information:</dt >
<dd> <dd>
<t>iesg@ietf.org</t> iesg@ietf.org
</dd> </dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>
<t>COMMON</t> <t>COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>
<t>none</t> <t>none</t>
</dd> </dd>
<dt>Author/Change controller:</dt> <dt>Author/Change controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-coap-content-format-registrations"> <section anchor="sec-coap-content-format-registrations">
<name>CoAP Content-Format Registrations</name> <name>CoAP Content-Format Registrations</name>
<t>IANA is requested to register the following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Enviro nments (CoRE) Parameters" Registry <xref target="IANA.core-parameters"/> in the 256-9999 Range:</t> <t>IANA has registered the following Content-Format numbers in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE ) Parameters" registry group <xref target="IANA.core-parameters"/> in the 256-99 99 range:</t>
<table anchor="new-content-formats"> <table anchor="new-content-formats">
<name>SCITT Content-Formats Registration</name> <name>SCITT Content-Formats Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Content-Type</th> <th align="left">Content Type</th>
<th align="left">Content Coding</th> <th align="left">Content Coding</th>
<th align="left">ID</th> <th align="left">ID</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">application/scitt-statement+cose</td> <td align="left">application/scitt-statement+cose</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">277</td> <td align="left">277</td>
<td align="left">RFCthis</td> <td align="left">RFC 9943</td>
</tr> </tr>
<tr> <tr>
<td align="left">application/scitt-receipt+cose</td> <td align="left">application/scitt-receipt+cose</td>
<td align="left">-</td> <td align="left">-</td>
<td align="left">278</td> <td align="left">278</td>
<td align="left">RFCthis</td> <td align="left">RFC 9943</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9393" to="CoSWID"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6838"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 838.xml"/>
<title>Media Type Specifications and Registration Procedures</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC6838"/> 392.xml"/>
<seriesInfo name="RFC" value="6838"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="BCP" value="13"/> 610.xml"/>
<author fullname="N. Freed" initials="N." surname="Freed"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
<author fullname="J. Klensin" initials="J." surname="Klensin"/> 94.xml"/>
<author fullname="T. Hansen" initials="T." surname="Hansen"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
<date month="January" year="2013"/> 96.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document defines procedures for the specification and regi 360.xml"/>
stration of media types for use in HTTP, MIME, and other Internet protocols. Thi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
s memo documents an Internet Best Current Practice.</t> 597.xml"/>
</abstract> <!-- [RFC9942]
</front> draft-ietf-cose-merkle-tree-proofs-18
</reference> companion doc RFC 9942
<reference anchor="RFC8392"> -->
<front> <reference anchor="RFC9942" target="https://www.rfc-editor.org/info/rfc9942">
<title>CBOR Web Token (CWT)</title> <front>
<seriesInfo name="DOI" value="10.17487/RFC8392"/> <title>CBOR Object Signing and Encryption (COSE) Receipts</title>
<seriesInfo name="RFC" value="8392"/> <author initials="O." surname="Steele" fullname="Orie Steele">
<author fullname="M. Jones" initials="M." surname="Jones"/> <organization>Tradeverifyd</organization>
<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/ </author>
> <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <organization>Fraunhofer SIT</organization>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/ </author>
> <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-L
<date month="May" year="2018"/> avaud">
<abstract> <organization>Microsoft</organization>
<t>CBOR Web Token (CWT) is a compact means of representing claims </author>
to be transferred between two parties. The claims in a CWT are encoded in the Co <author initials="C." surname="Fournet" fullname="Cedric Fournet">
ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio <organization>Microsoft</organization>
n (COSE) is used for added application-layer security protection. A claim is a p </author>
iece of information asserted about a subject and is represented as a name/value <date month='April' year='2026'/>
pair consisting of a claim name and a claim value. CWT is derived from JSON Web </front>
Token (JWT) but uses CBOR rather than JSON.</t> <seriesInfo name="RFC" value="9942"/>
</abstract> <seriesInfo name="DOI" value="10.17487/RFC9942"/>
</front> </reference>
</reference>
<reference anchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages 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 forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange 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 Pro
cess</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 de
signed 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 encrypt
ion using CBOR for serialization. This specification additionally describes how
to represent cryptographic keys using CBOR.</t>
<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
</abstract>
</front>
</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 struc
ture is used for transporting keys outside of COSE messages. This document exten
ds the way that keys can be identified and transported by providing attributes t
hat refer to or contain X.509 certificates.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC9597">
<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) cla
ims in the header parameters of any CBOR Object Signing and Encryption (COSE) st
ructure. This functionality helps to facilitate applications that wish to make u
se of CWT claims in encrypted COSE structures and/or COSE structures featuring d
etached signatures, while having some of those claims be available before decryp
tion and/or without inspecting the detached payload. Another use case is using C
WT claims with payloads that are not CWT Claims Sets, including payloads that ar
e 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">
<organization>Tradeverifyd</organization>
</author>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="De
lignat-Lavaud">
<organization>Microsoft</organization>
</author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization>Microsoft</organization>
</author>
<date day="10" month="September" year="2025"/>
<abstract>
<t> COSE (CBOR Object Signing and Encryption) Receipts prove pro
perties
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>
</front>
</reference>
<reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw t"> <reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cw t">
<front> <front>
<title>CBOR Web Token (CWT) Claims</title> <title>CBOR Web Token (CWT) Claims</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 174.xml"/>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
</reference>
<reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types"> <reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types">
<front> <front>
<title>Media Types</title> <title>Media Types</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters"> <reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">
<front> <front>
skipping to change at line 1811 skipping to change at line 1724
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="NIST.SP.1800-19" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.1800-19.pdf"> <reference anchor="NIST.SP.1800-19" target="https://nvlpubs.nist.gov/nis tpubs/SpecialPublications/NIST.SP.1800-19.pdf">
<front> <front>
<title>Trusted cloud :security practice guide for VMware hybrid clou <title>Trusted cloud: Security Practice Guide for VMware Hybrid Clou
d infrastructure as a service (IaaS) environments</title> d Infrastructure as a Service (IaaS) Environments</title>
<seriesInfo name="DOI" value="10.6028/NIST.SP.1800-19"/>
<seriesInfo name="NIST Special Publications (General)" value="1800-1
9"/>
<author fullname="Michael Bartock" surname="Bartock"> <author fullname="Michael Bartock" surname="Bartock">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author fullname="Donna Dodson" surname="Dodson"> <author fullname="Donna Dodson" surname="Dodson">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author fullname="Murugiah Souppaya" surname="Souppaya"> <author fullname="Murugiah Souppaya" surname="Souppaya">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author fullname="Daniel Carroll" surname="Carroll"> <author fullname="Daniel Carroll" surname="Carroll">
skipping to change at line 1877 skipping to change at line 1788
</author> </author>
<author fullname="Jeff Haskins" surname="Haskins"> <author fullname="Jeff Haskins" surname="Haskins">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author fullname="Carlos Phoenix" surname="Phoenix"> <author fullname="Carlos Phoenix" surname="Phoenix">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author fullname="Brenda Swarts" surname="Swarts"> <author fullname="Brenda Swarts" surname="Swarts">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </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"/> <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 demo
nstrate how trusted compute pools leveraging hardware roots of trust can provide
the necessary security capabilities. These capabilities not only provide assura
nce that cloud workloads are running on trusted hardware and in a trusted geoloc
ation or logical boundary, but also improve the protections for the data in the
workloads and in the data flows between workloads. The example solution leverage
s modern commercial off-the-shelf technology and cloud services to address lifti
ng and shifting a typical multi-tier application between an organization-control
led private cloud and a hybrid/public cloud over the internet.</t>
</abstract>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.1800-19"/>
<seriesInfo name="NIST SP" value="1800-19"/>
</reference> </reference>
<reference anchor="NIST.SP.800-204C" target="https://nvlpubs.nist.gov/ni stpubs/SpecialPublications/NIST.SP.800-204C.pdf"> <reference anchor="NIST.SP.800-204C" target="https://nvlpubs.nist.gov/ni stpubs/SpecialPublications/NIST.SP.800-204C.pdf">
<front> <front>
<title>Implementation of DevSecOps for a microservices-based applica tion with service mesh</title> <title>Implementation of DevSecOps for a Microservices-based Applica tion with Service Mesh</title>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-204C"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-204C"/>
<seriesInfo name="NIST Special Publications (General)" value="800-20 4C"/> <seriesInfo name="NIST Special Publications (General)" value="800-20 4C"/>
<author fullname="Ramaswamy Chandramouli" surname="Chandramouli"> <author fullname="Ramaswamy Chandramouli" surname="Chandramouli">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author> <date month="March" year="2022"/>
<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 arch
itecture consisting of multiple loosely coupled components called microservices
(often typically implemented as containers) that are supported by an infrastruct
ure for providing application services, such as service mesh. Both of these comp
onents are usually hosted on a container orchestration and resource management p
latform. In this architecture, the entire set of source code involved in the app
lication environment can be divided into five code types: 1) application code (w
hich 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 resour
ces), 4) policy as code (for defining runtime policies such as zero trust expres
sed as a declarative code), 5) and observability as code (for the continuous mon
itoring of an application runtime state). Due to security, business competitiven
ess, and the inherent structure of loosely coupled application components, this
class of applications needs a different development, deployment, and runtime par
adigm. DevSecOps (consisting of acronyms for Development, Security, and Operatio
ns, respectively) has been found to be a facilitating paradigm for these applica
tions with primitives such as continuous integration, continuous delivery, and c
ontinuous 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 imple
mentation of DevSecOps primitives for cloud-native applications with the archite
cture and code types described above. The benefits of this approach for high sec
urity assurance and for enabling continuous authority to operate (C-ATO) are als
o discussed.</t>
</abstract>
</front> </front>
<seriesInfo name="NIST SP" value="800-204C"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-204C"/>
</reference> </reference>
<reference anchor="NIST_EO14028" target="https://www.nist.gov/system/fil es/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-s ection-4e.pdf"> <reference anchor="NIST_EO14028" target="https://www.nist.gov/system/fil es/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-s ection-4e.pdf">
<front> <front>
<title>Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e</title> <title>Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date year="2022" month="February" day="04"/> <date year="2022" month="February" day="04"/>
</front> </front>
</reference> </reference>
<reference anchor="RFC4949"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 949.xml"/>
<title>Internet Security Glossary, Version 2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC4949"/> 725.xml"/>
<seriesInfo name="RFC" value="4949"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="FYI" value="36"/> 162.xml"/>
<author fullname="R. Shirey" initials="R." surname="Shirey"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="August" year="2007"/> 393.xml"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low 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, diction
ary 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 se
curity 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 num
erous protocols and applications, both in the area of digital identity and in ot
her application areas. This Best Current Practices document updates RFC 7519 to
provide actionable guidance leading to secure implementation and deployment of J
WTs.</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 Transpar
ency (CT) protocol for publicly logging the existence of Transport Layer Securit
y (TLS) server certificates as they are issued or observed, in a manner that all
ows anyone to audit certification authority (CA) activity and notice the issuanc
e of suspect certificates as well as to audit the certificate logs themselves. T
he 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 t
he logs.</t>
<t>This document obsoletes RFC 6962. It also specifies a new TLS e
xtension that is used to send various CT log artifacts.</t>
<t>Logs are network services that implement the protocol operation
s 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="Fitzge
rald-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 provid
e 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 define
s a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supp
orts 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 inform
ation, all in a more memory-efficient format.</t>
</abstract>
</front>
</reference>
<reference anchor="CycloneDX" target="https://cyclonedx.org/specificatio n/overview/"> <reference anchor="CycloneDX" target="https://cyclonedx.org/specificatio n/overview/">
<front> <front>
<title>CycloneDX</title> <title>CycloneDX</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="in-toto" target="https://in-toto.io/"> <reference anchor="in-toto" target="https://in-toto.io/">
<front> <front>
<title>in-toto</title> <title>in-toto</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="SLSA" target="https://slsa.dev/"> <reference anchor="SLSA" target="https://slsa.dev/">
<front> <front>
<title>SLSA</title> <title>SLSA</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="SPDX-CBOR" target="https://spdx.dev/use/specification s/"> <reference anchor="SPDX-CBOR" target="https://spdx.dev/use/specification s/">
<front> <front>
<title>SPDX Specification</title> <title>SPDX Specification</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="SPDX-JSON" target="https://spdx.dev/use/specification
s/">
<front>
<title>SPDX Specification</title>
<author>
<organization/>
</author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="SWID" target="https://csrc.nist.gov/Projects/Software -Identification-SWID/guidelines"> <reference anchor="SWID" target="https://csrc.nist.gov/Projects/Software -Identification-SWID/guidelines">
<front> <front>
<title>SWID Specification</title> <title>SWID Specification</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="EQUIVOCATION" target="https://www.read.seas.harvard.e du/~kohler/class/08w-dsi/chun07attested.pdf"> <reference anchor="EQUIVOCATION" target="https://www.read.seas.harvard.e du/~kohler/class/08w-dsi/chun07attested.pdf">
<front> <front>
<title>Attested Append-Only Memory: Making Adversaries Stick to thei r Word</title> <title>Attested Append-Only Memory: Making Adversaries Stick to thei r Word</title>
<seriesInfo name="DOI" value="10.1145/1323293.1294280"/> <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. 1
89-204</refcontent>
<seriesInfo name="DOI" value="10.1145/1323293.1294280"/>
</reference>
<reference anchor="ISO_IEC_17000" target="https://www.iso.org/standard/7
3029.html">
<front>
<title>Conformity assessment — Vocabulary and general principles</ti
tle>
<author> <author>
<organization/> <organization>ISO/IEC</organization>
</author> </author>
<date>n.d.</date> <date year="2020" month="December"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="17000:2020"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
<name>Contributors</name> <name>Contributors</name>
<contact initials="O." surname="Steele" fullname="Orie Steele"> <contact initials="O." surname="Steele" fullname="Orie Steele">
<organization>Tradeverifyd</organization> <organization>Tradeverifyd</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>orie@or13.io</email> <email>orie@or13.io</email>
</address> </address>
</contact> </contact>
<t>Orie contributed to improving the generalization of COSE building block s and document consistency.</t> <t>Orie contributed to improving the generalization of COSE building block s and document consistency.</t>
<contact initials="A." surname="Chamayou" fullname="Amaury Chamayou"> <contact initials="A." surname="Chamayou" fullname="Amaury Chamayou">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>amaury.chamayou@microsoft.com</email> <email>amaury.chamayou@microsoft.com</email>
</address> </address>
</contact> </contact>
<t>Amaury contributed elemental parts to finalize normative language on re gistration behavior and the single-issuer design, as well as overall document co nsistency</t> <t>Amaury contributed elemental parts to finalize normative language on re gistration behavior and the single-issuer design, as well as overall document co nsistency</t>
<contact initials="D." surname="Brooks" fullname="Dick Brooks"> <contact initials="D." surname="Brooks" fullname="Dick Brooks">
<organization>Business Cyber Guardian (TM)</organization> <organization>Business Cyber Guardian</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>dick@businesscyberguardian.com</email> <email>dick@businesscyberguardian.com</email>
</address> </address>
</contact> </contact>
<t>Dick contributed to the software supply chain use cases.</t> <t>Dick contributed to the software supply chain use cases.</t>
<contact initials="B." surname="Knight" fullname="Brian Knight"> <contact initials="B." surname="Knight" fullname="Brian Knight">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>brianknight@microsoft.com</email> <email>brianknight@microsoft.com</email>
</address> </address>
</contact> </contact>
<t>Brian contributed to the software supply chain use cases.</t> <t>Brian contributed to the software supply chain use cases.</t>
<contact initials="R. A." surname="Martin" fullname="Robert Martin"> <contact initials="R. A." surname="Martin" fullname="Robert Martin">
<organization>MITRE Corporation</organization> <organization>MITRE Corporation</organization>
<address> <address>
<postal> <postal>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>ramartin@mitre.org</email> <email>ramartin@mitre.org</email>
</address> </address>
</contact> </contact>
<t>Robert contributed to the software supply chain use cases.</t> <t>Robert contributed to the software supply chain use cases.</t>
</section> </section>
</back> </back>
<!-- ##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=
</rfc> </rfc>
 End of changes. 222 change blocks. 
1462 lines changed or deleted 718 lines changed or added

This html diff was produced by rfcdiff 1.48.