rfc9943.original   rfc9943.txt 
SCITT H. Birkholz Internet Engineering Task Force (IETF) H. Birkholz
Internet-Draft Fraunhofer SIT Request for Comments: 9943 Fraunhofer SIT
Intended status: Standards Track A. Delignat-Lavaud Category: Standards Track A. Delignat-Lavaud
Expires: 13 April 2026 C. Fournet ISSN: 2070-1721 C. Fournet
Microsoft Research Microsoft Research
Y. Deshpande Y. Deshpande
ARM ARM
S. Lasker S. Lasker
10 October 2025 March 2026
An Architecture for Trustworthy and Transparent Digital Supply Chains An Architecture for Trustworthy and Transparent Digital Supply Chains
draft-ietf-scitt-architecture-22
Abstract Abstract
Traceability in supply chains is a growing security concern. While Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different ensures extensibility and interoperability between different
transparency services, and compliance with various auditing transparency services as well as compliance with various auditing
procedures and regulatory requirements. procedures and regulatory requirements.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/.
Discussion of this document takes place on the SCITT Working Group
mailing list (mailto:scitt@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at
https://www.ietf.org/mailman/listinfo/scitt/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 13 April 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9943.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation
2. Software Supply Chain Scope . . . . . . . . . . . . . . . . . 5 2. Software Supply Chain Scope
2.1. Generic SSC Problem Statement . . . . . . . . . . . . . . 5 2.1. Generic SSC Problem Statement
2.2. Eclectic SSC Use Cases . . . . . . . . . . . . . . . . . 7 2.2. Eclectic SSC Use Cases
2.2.1. Security Analysis of a Software Product . . . . . . . 7 2.2.1. Security Analysis of a Software Product
2.2.2. Promotion of a Software Component by Multiple 2.2.2. Promotion of a Software Component by Multiple Entities
Entities . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Software Integrator Assembling a Software Product for a 2.2.3. Software Integrator Assembling a Software Product for a
Vehicle . . . . . . . . . . . . . . . . . . . . . . . 10 Vehicle
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology
4. Definition of Transparency . . . . . . . . . . . . . . . . . 14 4. Definition of Transparency
5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 15 5. Architecture Overview
5.1. Transparency Service . . . . . . . . . . . . . . . . . . 17 5.1. Transparency Service
5.1.1. Registration Policies . . . . . . . . . . . . . . . . 18 5.1.1. Registration Policies
5.1.2. Initialization and Bootstrapping . . . . . . . . . . 19 5.1.2. Initialization and Bootstrapping
5.1.3. Verifiable Data Structure . . . . . . . . . . . . . . 20 5.1.3. Verifiable Data Structure
5.1.4. Adjacent Services . . . . . . . . . . . . . . . . . . 20 5.1.4. Adjacent Services
6. Signed Statements . . . . . . . . . . . . . . . . . . . . . . 21 6. Signed Statements
6.1. Signed Statement Examples . . . . . . . . . . . . . . . . 22 6.1. Signed Statement Examples
6.2. Signing Large or Sensitive Statements . . . . . . . . . . 24 6.2. Signing Large or Sensitive Statements
6.3. Registration of Signed Statements . . . . . . . . . . . . 26 6.3. Registration of Signed Statements
7. Transparent Statements . . . . . . . . . . . . . . . . . . . 27 7. Transparent Statements
7.1. Validation . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Validation
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 8. Privacy Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations
9.1. Ordering of Signed Statements . . . . . . . . . . . . . . 31 9.1. Ordering of Signed Statements
9.2. Accuracy of Statements . . . . . . . . . . . . . . . . . 31 9.2. Accuracy of Statements
9.3. Issuer Participation . . . . . . . . . . . . . . . . . . 31 9.3. Issuer Participation
9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 31 9.4. Key Management
9.4.1. Verifiable Data Structure . . . . . . . . . . . . . . 32 9.4.1. Verifiable Data Structure
9.4.2. Key Compromise . . . . . . . . . . . . . . . . . . . 32 9.4.2. Key Compromise
9.4.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . 32 9.4.3. Bootstrapping
9.5. Implications of Media-Type Usage . . . . . . . . . . . . 32 9.5. Implications of Media Type Usage
9.6. Cryptographic Agility . . . . . . . . . . . . . . . . . . 33 9.6. Cryptographic Agility
9.7. Threat Model . . . . . . . . . . . . . . . . . . . . . . 33 9.7. Threat Model
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations
10.1. Media Type application/scitt-statement+cose 10.1. Registration of application/scitt-statement+cose
Registration . . . . . . . . . . . . . . . . . . . . . . 34 10.2. Registration of application/scitt-receipt+cose
10.2. Media Type application/scitt-receipt+cose Registration
Registration . . . . . . . . . . . . . . . . . . . . . . 35 10.3. CoAP Content-Format Registrations
10.3. CoAP Content-Format Registrations . . . . . . . . . . . 35 11. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 37 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines an architecture, a base set of extensible This document defines an architecture, a base set of extensible
message structures, and associated flows to make signed content message structures, and associated flows to make signed content
transparent via verifiable data structures maintained by transparent via verifiable data structures maintained by
corresponding transparency services. The goal of the transparency corresponding transparency services. The goal of the transparency
enabled by the Supply Chain Integrity, Transparency, and Trust enabled by the Supply Chain Integrity, Transparency, and Trust
(SCITT) architecture is to enhance auditability and accountability (SCITT) architecture is to enhance auditability and accountability
for single-issuer signed content (statements) that are about supply for single-issuer signed content (statements) that are about supply
chain commodities (artifacts). chain commodities (artifacts).
Registering signed statements with a transparency service is akin to Registering signed statements with a transparency service is akin to
a notarization procedure. Transparency services confirm a policy is a notarization procedure. Transparency Services (TSs) confirm a
met before recording the statement on the ledger. The SCITT ledger policy is met before recording the statement on the ledger. The
represents a linear and irrevocable history of statements made. Once SCITT ledger represents a linear and irrevocable history of
the signed statement is registered, the transparency service issues a statements made. Once the signed statement is registered, the
receipt. transparency service issues a receipt.
Similar approaches have been implemented for specific classes of Similar approaches have been implemented for specific classes of
artifacts, such as Certificate Transparency [RFC9162]. The SCITT artifacts, such as Certificate Transparency (CT) [RFC9162]. The
approach follows a more generic paradigm than previous approaches. SCITT approach follows a more generic paradigm than previous
This "content-agnostic" approach allows SCITT transparency services approaches. This "content-agnostic" approach allows SCITT
to be either integrated in existing solutions or to be an initial transparency services to be either integrated in existing solutions
part of new emerging systems. Extensibility is a vital feature of or an initial part of new emerging systems. Extensibility is a vital
the SCITT architecture, so that requirements from various feature of the SCITT architecture, so that requirements from various
applications can be accommodated while always ensuring applications can be accommodated while always ensuring
interoperability with respect to registration procedures and interoperability with respect to registration procedures and
corresponding auditability and accountability. For simplicity, the corresponding auditability and accountability. For simplicity, the
scope of this document is limited to use cases originating from the scope of this document is limited to use cases originating from the
software supply chain domain, but the specification defined is software supply chain domain. However, the specification defined is
applicable to any other type of supply chain statements (also applicable to any other type of supply chain statements (also
referred to as value-add graphs), for example, statements about referred to as "value-add graphs"), for example, statements about
hardware supply chains. hardware supply chains.
This document also defines message structures for signed statements This document also defines message structures for signed statements
and transparent statements, which embed COSE receipts and transparent statements, which embed CBOR Object Signing and
[I-D.draft-ietf-cose-merkle-tree-proofs], i.e., signed verifiable Encryption (COSE) receipts [RFC9942], i.e., signed verifiable data
data structure proofs). These message structures are based on the structure proofs). These message structures are based on the Concise
Concise Binary Object Representation Standard [STD94] and Binary Object Representation (CBOR) Standard [STD94] and
corresponding signing is facilitated via the CBOR Object Signing and corresponding signing is facilitated via the COSE Standard [STD96].
Encryption Standard [STD96]. The message structures are defined The message structures are defined using the Concise Data Definition
using the Concise Data Definition Language [RFC8610]. The signed Language (CDDL) [RFC8610]. The signed statements and receipts are,
statements and receipts are based respectively on the COSE_Sign1 respectively, based on the COSE_Sign1 specification in Section 4.2 of
specification in Section 4.2 of [STD96] and on COSE receipts RFC 9052 [STD96] and on COSE receipts [RFC9942]. The application-
[I-D.draft-ietf-cose-merkle-tree-proofs]. The application-domain- domain-agnostic nature of COSE_Sign1 and its extensibility through
agnostic nature of COSE_Sign1 and its extensibility through COSE COSE Header Parameters are prerequisites for implementing the
Header Parameters are prerequisites for implementing the
interoperable message layer defined in this document. interoperable message layer defined in this document.
In summary, this specification supports relying parties obtaining In summary, this specification supports relying parties obtaining
proof that signed statements were recorded and checked for their proof that signed statements were recorded and checked for their
validity at the time they were registered. How these statements are validity at the time they were registered. How these statements are
managed or stored, how participating entities discover and notify managed or stored as well as how participating entities discover and
each other of changes is out-of-scope of this document. notify each other of changes is out of scope of this document.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Software Supply Chain Scope 2. Software Supply Chain Scope
To illustrate the applicability of the SCITT architecture and its To illustrate the applicability of the SCITT architecture and its
messages, this section details the exemplary context of software messages, this section details the exemplary context of Software
supply chain (SSC) use cases. The building blocks provided by the Supply Chain (SSC) use cases. The building blocks provided by the
SCITT architecture are not restricted to software supply chain use SCITT architecture are not restricted to SSC use cases. SSCs serve
cases. Software supply chains serve as a useful application guidance as useful application guidance and first usage scenarios.
and first usage scenario.
2.1. Generic SSC Problem Statement 2.1. Generic SSC Problem Statement
Supply chain security is a prerequisite to protecting consumers and Supply chain security is a prerequisite to protecting consumers and
minimizing economic, public health, and safety threats. Supply chain minimizing economic, public health, and safety threats. Supply chain
security has historically focused on risk management practices to security has historically focused on risk management practices to
safeguard logistics, meet regulatory requirements, forecast demand, safeguard logistics, meet regulatory requirements, forecast demand,
and optimize inventory. While these elements are foundational to a and optimize inventory. While these elements are foundational to a
healthy supply chain, an integrated cyber-security-based perspective healthy supply chain, an integrated cyber-security-based perspective
of the software supply chains remains broadly undefined. Recently, of the SSCs remains broadly undefined. Recently, the global
the global community has experienced numerous supply chain attacks community has experienced numerous supply chain attacks targeting
targeting weaknesses in software supply chains. As illustrated in weaknesses in SSCs. As illustrated in Figure 1, an SSC attack may
Figure 1, a software supply chain attack may leverage one or more leverage one or more life-cycle stages and directly or indirectly
life-cycle stages and directly or indirectly target the component. target the component.
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 page 7, line 8 skipping to change at line 236
| | | |
| Deploy | Tamper with versioning and update process | Deploy | Tamper with versioning and update process
| | | |
+-----------+ +-----------+
Figure 1: Example SSC Life-Cycle Threats Figure 1: Example SSC Life-Cycle Threats
DevSecOps, as defined in [NIST.SP.800-204C], often depends on third- DevSecOps, as defined in [NIST.SP.800-204C], often depends on third-
party and open-source software. These dependencies can be quite party and open-source software. These dependencies can be quite
complex throughout the supply chain, so checking provenance and complex throughout the supply chain, so checking provenance and
traceability throughout their lifecycle is difficult. There is a traceability throughout their life cycle is difficult. There is a
need for manageable auditability and accountability of digital need for manageable auditability and accountability of digital
products. Typically, the range of types of statements about digital products. Typically, the range of types of statements about digital
products (and their dependencies) is vast, heterogeneous, and can products (and their dependencies) is vast, heterogeneous, and can
differ between community policy requirements. Taking the type and differ between community policy requirements. Taking the type and
structure of all statements about digital products into account might structure of all statements about digital products into account might
not be possible. Examples of statements may include commit not be possible. Examples of statements may include commit
signatures, build environment and parameters, software bill of signatures, build environment and parameters, Software Bill of
materials, static and dynamic application security testing results, Materials (SBOM), static and dynamic application security testing
fuzz testing results, release approvals, deployment records, results, fuzz testing results, release approvals, deployment records,
vulnerability scan results, and patch logs. In consequence, instead vulnerability scan results, and patch logs. Consequently, instead of
of trying to understand and describe the detailed syntax and trying to understand and describe the detailed syntax and semantics
semantics of every type of statement about digital products, the of every type of statement about digital products, the SCITT
SCITT architecture focuses on ensuring statement authenticity, architecture focuses on ensuring statement authenticity, ensuring
visibility/transparency, and intends to provide scalable visibility/transparency, and intends to provide scalable
accessibility. Threats and practical issues can also arise from accessibility. Threats and practical issues can also arise from
unintended side-effects of using security techniques outside their unintended side effects of using security techniques outside their
proper bounds. For instance digital signatures may fail to verify proper bounds. For instance, digital signatures may fail to verify
past their expiry date even though the signed item itself remains past their expiry date even though the signed item itself remains
completely valid. Or a signature may verify even though the completely valid. Or a signature may verify even though the
information it is securing is now found unreliable but fine-grained information it is securing is now found unreliable but fine-grained
revocation is too hard. revocation is too hard.
Lastly, where data exchange underpins serious business decision- Lastly, where data exchange underpins serious business decision-
making, it is important to hold the producers of those data to a making, it is important to hold the producers of those data to a
higher standard of auditability. The SCITT architecture provides higher standard of auditability. The SCITT architecture provides
mechanisms and structures for ensuring that the makers of mechanisms and structures for ensuring that the makers of
authoritative statements can be held accountable and not hide or authoritative statements can be held accountable and not hide or
skipping to change at page 8, line 10 skipping to change at line 287
complementary statements about its security properties. This gives complementary statements about its security properties. This gives
enough confidence to both producers and consumers that the released enough confidence to both producers and consumers that the released
software meets the expected security standards and is suitable to software meets the expected security standards and is suitable to
use. use.
Subsequently, multiple security researchers often run sophisticated Subsequently, multiple security researchers often run sophisticated
security analysis tools on the same product. The intention is to security analysis tools on the same product. The intention is to
identify any security weaknesses or vulnerabilities in the package. identify any security weaknesses or vulnerabilities in the package.
Initially, a particular analysis can identify a simple weakness in a Initially, a particular analysis can identify a simple weakness in a
software component. Over a period of time, a statement from a third- software component. Over a period of time, a statement from a third
party illustrates that the weakness is exposed in a way that party illustrates that the weakness is exposed in a way that
represents an exploitable vulnerability. The producer of the represents an exploitable vulnerability. The producer of the
software product provides a statement that confirms the linking of a software product provides a statement that confirms the linking of a
software component vulnerability with the software product by issuing software component vulnerability with the software product by issuing
a product vulnerability disclosure report and also issues an advisory a product vulnerability disclosure report and also issuing an
statement on how to mitigate the vulnerability. At first, the advisory statement on how to mitigate the vulnerability. At first,
producer provides an updated software product that still uses the the producer provides an updated software product that still uses the
vulnerable software component but shields the issue in a fashion that vulnerable software component but shields the issue in a fashion that
inhibits exploitation. Later, a second update of the software inhibits exploitation. Later, a second update of the software
product includes a security patch to the affected software component product includes a security patch to the affected software component
from the software producer. Finally, a third update includes a new from the software producer. Finally, a third update includes a new
release (updated version) of the formerly insecure software release (updated version) of the formerly insecure software
component. For this release, both the software product and the component. For this release, both the software product and the
affected software component are deemed secure by the producer and affected software component are deemed secure by the producer and
consumers. consumers.
A consumer of a released software wants to: A consumer of a released software wants to:
* know where to get these security statements from producers and * know where to get these security statements from producers and
third-parties related to the software product in a timely and third parties related to the software product in a timely and
unambiguous fashion unambiguous fashion
* attribute them to an authoritative issuer * attribute them to an authoritative issuer
* associate the statements in a meaningful manner via a set of well- * associate the statements in a meaningful manner via a set of well-
known semantic relationships known semantic relationships
* consistently, efficiently, and homogeneously check their * consistently, efficiently, and homogeneously check their
authenticity authenticity
skipping to change at page 9, line 12 skipping to change at line 337
* check that the statement comes from a source with authority to * check that the statement comes from a source with authority to
issue that statement issue that statement
* confirm that sources provide a complete history of statements * confirm that sources provide a complete history of statements
related to a given component related to a given component
2.2.2. Promotion of a Software Component by Multiple Entities 2.2.2. Promotion of a Software Component by Multiple Entities
A software component (e.g., a library or software product), open- A software component (e.g., a library or software product), open-
source or commercial, is often initially released by a single trusted source or commercial, is often initially released by a single trusted
producer, who can choose to attach a statement of authenticity to it. producer who can choose to attach a statement of authenticity to it.
As that component becomes used in a growing range of other products, As that component becomes used in a growing range of other products,
providers other than the original trusted producer often re- providers other than the original trusted producer often re-
distribute, or release their own version of that component. distribute or release their own version of that component.
Some providers include it as part of their release product/package Some providers include it as part of their release product or package
bundle and provide the package with proof of authenticity using their bundle and provide the package with proof of authenticity using their
issuer authority. Some packages include the original statement of issuer authority. Some packages include the original statement of
authenticity, and some do not. Over time, some providers no longer authenticity, and some do not. Over time, some providers no longer
offer the exact same software component source code but pre-compiled offer the exact same software component source code but pre-compiled
software component binaries. Some sources do not provide the exact software component binaries. Some sources do not provide the exact
same software component, but include patches and fixes produced by same software component but include patches and fixes produced by
third-parties, as these emerge faster than solutions from the third parties as these emerge faster than solutions from the original
original producer. Due to complex distribution and promotion life- producer. Due to complex distribution and promotion life-cycle
cycle scenarios, the original software component takes myriad forms. scenarios, the original software component takes myriad forms.
A consumer of a released software wants to: A consumer of a released software wants to:
* understand if a particular provider is a trusted originating * understand if a particular provider is a trusted originating
producer or an alternative party producer or an alternative party
* know if and how the source, or resulting binary, of a promoted * know if and how the source, or resulting binary, of a promoted
software component differs from the original software component software component differs from the original software component
* check the provenance and history of a software component's source * check the provenance and history of a software component's source
skipping to change at page 10, line 4 skipping to change at line 377
SCITT provides a standardized way to: SCITT provides a standardized way to:
* reliably discern if a provider is the original, trusted producer * reliably discern if a provider is the original, trusted producer
or is a trustworthy alternative provider or is an illegitimate or is a trustworthy alternative provider or is an illegitimate
provider provider
* track the provenance path from an original producer to a * track the provenance path from an original producer to a
particular provider particular provider
* check the trustworthiness of a provider * check the trustworthiness of a provider
* check the integrity of modifications or transformations applied by * check the integrity of modifications or transformations applied by
a provider a provider
2.2.3. Software Integrator Assembling a Software Product for a Vehicle 2.2.3. Software Integrator Assembling a Software Product for a Vehicle
Software Integration is a complex activity. This typically involves Software Integration is a complex activity. Typically, it involves
getting various software components from multiple suppliers, getting various software components from multiple suppliers and
producing an integrated package deployed as part of device assembly. producing an integrated package deployed as part of device assembly.
For example, car manufacturers source integrated software for their For example, car manufacturers source integrated software for their
vehicles from third parties that integrate software components from vehicles from third parties that integrate software components from
various sources. Integration complexity creates a higher risk of various sources. Integration complexity creates a higher risk of
security vulnerabilities to the delivered software. security vulnerabilities to the delivered software.
Consumers of integrated software want: Consumers of integrated software want:
* a list of all components present in a software product * a list of all components present in a software product
* the ability to identify and retrieve all components from a secure * the ability to identify and retrieve all components from a secure
and tamper-proof location and tamper-proof location
* verifiable proofs on build process and build environment with all * verifiable proofs on build process and build environment with all
supplier tiers to ensure end to end build quality and security supplier tiers to ensure end-to-end build quality and security
SCITT provides a standardized way to: SCITT provides a standardized way to:
* provide a tiered and transparent framework that allows for * provide a tiered and transparent framework that allows for
verification of integrity and authenticity of the integrated verification of integrity and authenticity of the integrated
software at both component and product level before installation software at both component and product level before installation
* provide valid annotations on build integrity to ensure conformance * provide valid annotations on build integrity to ensure conformance
3. Terminology 3. Terminology
The terms defined in this section have special meaning in the context The terms defined in this section have special meaning in the context
of Supply Chain Integrity, Transparency, and Trust, and are used of SCITT and are used throughout this document.
throughout this document.
This document has been developed in coordination with the COSE, OAUTH
and RATS WG and uses terminology common to these working groups as
much as possible.
When used in text, the corresponding terms are capitalized. To This document has been developed in coordination with the COSE,
ensure readability, only a core set of terms is included in this OAUTH, and RATS working groups (WGs) and uses terminology common to
section. these WGs as often as possible.
The terms "header", "payload", and "to-be-signed bytes" are defined The terms "header", "payload", and "to-be-signed bytes" are defined
in [STD96]. in [STD96].
The term "claim" is defined in [RFC8392]. The term "claim" is defined in [RFC8392].
When used in text, the following terms are capitalized. To ensure
readability, only a core set of terms is included in this section.
Append-only Log: a Statement Sequence comprising the entire Append-only Log: a Statement Sequence comprising the entire
registration history of the Transparency Service. To make the registration history of the Transparency Service. To make the
Append-only property verifiable and transparent, the Transparency Append-only property verifiable and transparent, the Transparency
Service defines how Signed Statements are made available to Service defines how Signed Statements are made available to
Auditors. Auditors.
Artifact: a physical or non-physical item that is moving along a Artifact: a physical or non-physical item that is moving along a
supply chain. supply chain.
Auditor: an entity that checks the correctness and consistency of Auditor: an entity that checks the correctness and consistency of
skipping to change at page 11, line 42 skipping to change at line 461
signature) and an unprotected header (not included in the Issuer's signature) and an unprotected header (not included in the Issuer's
signature). signature).
Equivocation: a state where a Transparency Service provides Equivocation: a state where a Transparency Service provides
inconsistent proofs to Relying Parties, containing conflicting inconsistent proofs to Relying Parties, containing conflicting
claims about the Signed Statement bound at a given position in the claims about the Signed Statement bound at a given position in the
Verifiable Data Structure. Verifiable Data Structure.
Issuer: an identifier representing an organization, device, user, or Issuer: an identifier representing an organization, device, user, or
entity securing Statements about supply chain Artifacts. An entity securing Statements about supply chain Artifacts. An
Issuer may be the owner or author of Artifacts, or an independent Issuer may be the owner or author of Artifacts or an independent
third party such as an Auditor, reviewer or an endorser. In SCITT third party such as an Auditor, reviewer, or endorser. In SCITT
Statements and Receipts, the iss Claim is a member of the COSE Statements and Receipts, the iss Claim is a member of the COSE
header parameter 15: CWT Claims defined in [RFC9597], which embeds header parameter 15: CWT Claims defined in [RFC9597], which embeds
a CWT Claim Set [RFC8392] within the protected header of a COSE a CBOR Web Token (CWT) Claim Set [RFC8392] within the protected
Envelope. This document uses the terms "Issuer", and "Subject" as header of a COSE Envelope. This document uses the terms "Issuer"
described in [RFC8392], however the usage is consistent with the and "Subject" as described in [RFC8392]; however, the usage is
broader interpretation of these terms in both JOSE and COSE, and consistent with the broader interpretation of these terms in both
the guidance in [RFC8725] generally applies the COSE equivalent JSON Object Signing and Encryption (JOSE) and COSE, and the
terms with consistent semantics. guidance in [RFC8725] generally applies the COSE equivalent terms
with consistent semantics.
Non-equivocation: a state where all proofs provided by the Non-equivocation: a state where all proofs provided by the
Transparency Service to Relying Parties are produced from a single Transparency Service to Relying Parties are produced from a single
Verifiable Data Structure describing a unique sequence of Signed Verifiable Data Structure describing a unique sequence of Signed
Statements and are therefore consistent [EQUIVOCATION]. Over Statements and are therefore consistent [EQUIVOCATION]. Over
time, an Issuer may register new Signed Statements about an time, an Issuer may register new Signed Statements about an
Artifact in a Transparency Service with new information. However, Artifact in a Transparency Service with new information. However,
the consistency of a collection of Signed Statements about the the consistency of a collection of Signed Statements about the
Artifact can be checked by all Relying Parties. Artifact can be checked by all Relying Parties.
Receipt: a cryptographic proof that a Signed Statement is included Receipt: a cryptographic proof that a Signed Statement is included
in the Verifiable Data Structure. See in the Verifiable Data Structure. See [RFC9942] for
[I-D.draft-ietf-cose-merkle-tree-proofs] for implementations. implementations. Receipts are signed proofs of verifiable data-
Receipts are signed proofs of verifiable data-structure structure properties. Receipt Profiles implemented by a
properties. Receipt Profiles implemented by a Transparency Transparency Service MUST support inclusion proofs and MAY support
Service MUST support inclusion proofs and MAY support other proof other proof types, such as consistency proofs.
types, such as consistency proofs.
Registration: the process of submitting a Signed Statement to a Registration: the process of submitting a Signed Statement to a
Transparency Service, applying the Transparency Service's Transparency Service, applying the Transparency Service's
Registration Policy, adding to the Verifiable Data Structure, and Registration Policy, adding to the Verifiable Data Structure, and
producing a Receipt. producing a Receipt.
Registration Policy: the pre-condition enforced by the Transparency Registration Policy: the precondition enforced by the Transparency
Service before registering a Signed Statement, based on Service before registering a Signed Statement, based on
information in the non-opaque header and metadata contained in its information in the non-opaque header and metadata contained in its
COSE Envelope. COSE Envelope.
Relying Party: Relying Parties consumes Transparent Statements, Relying Party: Relying Parties consume Transparent Statements,
verifying their proofs and inspecting the Statement payload, verifying their proofs and inspecting the Statement payload,
either before using corresponding Artifacts, or later to audit an either before using corresponding Artifacts or later to audit an
Artifact's provenance on the supply chain. Artifact's provenance on the supply chain.
Signed Statement: an identifiable and non-repudiable Statement about Signed Statement: an identifiable and non-repudiable Statement about
an Artifact signed by an Issuer. In SCITT, Signed Statements are an Artifact signed by an Issuer. In SCITT, Signed Statements are
encoded as COSE signed objects; the payload of the COSE structure encoded as COSE signed objects; the payload of the COSE structure
contains the issued Statement. contains the issued Statement.
Attestation: [NIST.SP.1800-19] defines "attestation" as "The process Attestation: [NIST.SP.1800-19] defines "attestation" as:
of providing a digital signature for a set of measurements
securely stored in hardware, and then having the requester | The process of providing a digital signature for a set of
validate the signature and the set of measurements." NIST | measurements securely stored in hardware, and then having the
guidance "Software Supply Chain Security Guidance EO 14028" uses | requester validate the signature and the set of measurements.
the definition from [NIST_EO14028], which states that an
"attestation" is "The issue of a statement, based on a decision, NIST guidance "Software Supply Chain Security Guidance EO 14028"
that fulfillment of specified requirements has been uses the definition from [NIST_EO14028], which states that an
demonstrated.". It is often useful for the intended audience to "attestation" is:
qualify the term "attestation" in their specific context to avoid
confusion and ambiguity. | The issue of a statement, based on a decision, that fulfillment
| of specified requirements has been demonstrated.
It is often useful for the intended audience to qualify the term
"attestation" in their specific context to avoid confusion and
ambiguity.
Statement: any serializable information about an Artifact. To help Statement: any serializable information about an Artifact. To help
interpretation of Statements, they must be tagged with a relevant interpret Statements, they must be tagged with a relevant media
media type (as specified in [RFC6838]). A Statement may represent type (as specified in [RFC6838]). A Statement may represent an
a Software Bill Of Materials (SBOM) that lists the ingredients of SBOM that lists the ingredients of a software Artifact, contains
a software Artifact, an endorsement or attestation about an an endorsement or attestation about an Artifact, indicates the End
Artifact, indicate the End of Life (EOL), redirection to a newer of Life (EOL), redirects to a newer version, or contains any
version, or any content an Issuer wishes to publish about an content an Issuer wishes to publish about an Artifact. Additional
Artifact. Additional Statements about an Artifact are correlated Statements about an Artifact are correlated by the Subject Claim
by the Subject Claim as defined in the IANA CWT [IANA.cwt] as defined in the IANA CWT registry [IANA.cwt] and used as a
registry and used as a protected header parameter as defined in protected header parameter as defined in [RFC9597]. The Statement
[RFC9597]. The Statement is considered opaque to Transparency is considered opaque to Transparency Service and MAY be encrypted.
Service, and MAY be encrypted.
Statement Sequence: a sequence of Signed Statements captured by a Statement Sequence: a sequence of Signed Statements captured by a
Verifiable Data Structure. See Verifiable Data Structure. Verifiable Data Structure. See Verifiable Data Structure.
Subject: an identifier, defined by the Issuer, which represents the Subject: an identifier, defined by the Issuer, that represents the
organization, device, user, entity, or Artifact about which organization, device, user, entity, or Artifact about which
Statements (and Receipts) are made and by which a logical Statements (and Receipts) are made and by which a logical
collection of Statements can be grouped. It is possible that collection of Statements can be grouped. It is possible that
there are multiple Statements about the same Artifact. In these there are multiple Statements about the same Artifact. In these
cases, distinct Issuers (iss) might agree to use the sub CWT cases, distinct Issuers (iss) might agree to use the sub CWT
Claim, defined in [RFC8392], to create a coherent sequence of Claim, defined in [RFC8392], to create a coherent sequence of
Signed Statements about the same Artifact and Relying Parties can Signed Statements about the same Artifact, and Relying Parties can
leverage sub to ensure completeness and Non-equivocation across leverage sub to ensure completeness and Non-equivocation across
Statements by identifying all Transparent Statements associated to Statements by identifying all Transparent Statements associated to
a specific Subject. a specific Subject.
Transparency Service: an entity that maintains and extends the Transparency Service: an entity that maintains and extends the
Verifiable Data Structure and endorses its state. The identity of Verifiable Data Structure and endorses its state. The identity of
a Transparency Service is captured by a public key that must be a Transparency Service is captured by a public key that must be
known by Relying Parties in order to validate Receipts. known by Relying Parties in order to validate Receipts.
Transparent Statement: a Signed Statement that is augmented with a Transparent Statement: a Signed Statement that is augmented with a
Receipt created via Registration in a Transparency Service. The Receipt created via Registration in a Transparency Service. The
Receipt is stored in the unprotected header of COSE Envelope of Receipt is stored in the unprotected header of COSE Envelope of
the Signed Statement. A Transparent Statement remains a valid the Signed Statement. A Transparent Statement remains a valid
Signed Statement and may be registered again in a different Signed Statement and may be registered again in a different
Transparency Service. Transparency Service.
Verifiable Data Structure: a data structure which supports one or Verifiable Data Structure: a data structure that supports one or
more proof types, such as "inclusion proofs" or "consistency more proof types, such as "inclusion proofs" or "consistency
proofs", for Signed Statements as they are Registered to a proofs", for Signed Statements as they are Registered to a
Transparency Service. SCITT supports multiple Verifiable Data Transparency Service. SCITT supports multiple Verifiable Data
Structures and Receipt formats as defined in Structures and Receipt formats as defined in [RFC9942],
[I-D.draft-ietf-cose-merkle-tree-proofs], accommodating different accommodating different Transparency Service implementations.
Transparency Service implementations.
4. Definition of Transparency 4. Definition of Transparency
In this document, the definition of transparency is intended to build In this document, the definition of transparency is intended to build
over abstract notions of Append-only Logs and Receipts. Existing over abstract notions of Append-only Logs and Receipts. Existing
transparency systems such as Certificate Transparency [RFC9162] are transparency systems such as CT [RFC9162] are instances of this
instances of this definition. SCITT supports multiple Verifiable definition. SCITT supports multiple Verifiable Data Structures, as
Data Structures, as defined in defined in [RFC9942].
[I-D.draft-ietf-cose-merkle-tree-proofs].
A Signed Statement is an identifiable and non-repudiable Statement A Signed Statement is an identifiable and non-repudiable Statement
made by an Issuer. The Issuer selects additional metadata and made by an Issuer. The Issuer selects additional metadata and
attaches a proof of endorsement (in most cases, a signature) using attaches a proof of endorsement (in most cases, a signature) using
the identity key of the Issuer that binds the Statement and its the identity key of the Issuer that binds the Statement and its
metadata. Signed Statements can be made transparent by attaching a metadata. Signed Statements can be made transparent by attaching a
proof of Registration by a Transparency Service, in the form of a proof of Registration by a Transparency Service in the form of a
Receipt. Receipts demonstrate inclusion of Signed Statements in the Receipt. Receipts demonstrate inclusion of Signed Statements in the
Verifiable Data Structure of a Transparency Service. By extension, Verifiable Data Structure of a Transparency Service. By extension,
the Signed Statement may say an Artifact (for example, a firmware the Signed Statement may say an Artifact (for example, a firmware
binary) is transparent if it comes with one or more Transparent binary) is transparent if it comes with one or more Transparent
Statements from its author or owner, though the context should make Statements from its author or owner, though the context should make
it clear what type of Signed Statements is expected for a given it clear what type of Signed Statement is expected for a given
Artifact. Artifact.
Transparency does not prevent dishonest or compromised Issuers, but Transparency does not prevent dishonest or compromised Issuers, but
it holds them accountable. Any Artifact that may be verified, is it holds them accountable. Any Artifact that may be verified is
subject to scrutiny and auditing by other parties. The Transparency subject to scrutiny and auditing by other parties. The Transparency
Service provides a history of Statements, which may be made by Service provides a history of Statements, which may be made by
multiple Issuers, enabling Relying Parties to make informed multiple Issuers, enabling Relying Parties to make informed
decisions. decisions.
Transparency is implemented by providing a consistent, append-only, Transparency is implemented by providing a consistent, append-only,
cryptographically verifiable, publicly available record of entries. cryptographically verifiable, publicly available record of entries.
Implementations of Transparency Services may protect their registered Implementations of Transparency Services may protect their registered
sequence of Signed Statements and Verifiable Data Structure using a sequence of Signed Statements and Verifiable Data Structure using a
combination of trusted hardware, consensus protocols, and combination of trusted hardware, consensus protocols, and
skipping to change at page 15, line 5 skipping to change at line 619
verifiable without online access to the TS. Requesting a Receipt can verifiable without online access to the TS. Requesting a Receipt can
result in the production of a new Receipt for the same Signed result in the production of a new Receipt for the same Signed
Statement. A Receipt's verification key, signing algorithm, validity Statement. A Receipt's verification key, signing algorithm, validity
period, header parameters or other claims MAY change each time a period, header parameters or other claims MAY change each time a
Receipt is produced. Receipt is produced.
Anyone with access to the Transparency Service can independently Anyone with access to the Transparency Service can independently
verify its consistency and review the complete list of Transparent verify its consistency and review the complete list of Transparent
Statements registered by each Issuer. Statements registered by each Issuer.
Reputable Issuers are thus incentivized to carefully review their Thus, reputable Issuers are incentivized to carefully review their
Statements before signing them to produce Signed Statements. Statements before signing them to produce Signed Statements.
Similarly, reputable Transparency Services are incentivized to secure Similarly, reputable Transparency Services are incentivized to secure
their Verifiable Data Structure, as any inconsistency can easily be their Verifiable Data Structure, as any inconsistency can easily be
pinpointed by any Auditor with read access to the Transparency pinpointed by any Auditor with read access to the Transparency
Service. Service.
The building blocks specified in this document enable the unequivocal The building blocks specified in this document enable the unequivocal
and auditable production of statements about software supply chain and auditable production of statements about software supply chain
artifacts. The extensible design of the SCITT architecture artifacts. The extensible design of the SCITT architecture
potentially allows future usage with other supply chains in different potentially allows future usage with other supply chains in different
domains, for example advanced manufacturing or food supply. domains, for example, advanced manufacturing or food supply.
SCITT is a generalization of Certificate Transparency (CT) [RFC9162], SCITT is a generalization of CT [RFC9162], which can be interpreted
which can be interpreted as a transparency architecture for the as a transparency architecture for the supply chain of X.509
supply chain of X.509 certificates. Considering CT in terms of certificates. Considering CT in terms of SCITT:
SCITT:
* CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure * Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER-encoded
to produce an X.509 certificate (Signed Statements) tbsCertificate structure to produce an X.509 certificate (Signed
Statements)
* CAs submit the certificates to one or more CT logs (Transparency * CAs submit the certificates to one or more CT logs (Transparency
Services) Services)
* CT logs produce Signed Certificate Timestamps (Transparent * CT logs produce Signed Certificate Timestamps (Transparent
Statements) Statements)
* Signed Certificate Timestamps, Signed Tree Heads, and their * Signed Certificate Timestamps, Signed Tree Heads, and their
respective consistency proofs are checked by Relying Parties respective consistency proofs are checked by Relying Parties
* The Verifiable Data Structure can be checked by Auditors * The Verifiable Data Structure can be checked by Auditors
5. Architecture Overview 5. Architecture Overview
The SCITT architecture enables Transparency Services in a given The SCITT architecture enables Transparency Services in a given
application domain to implement a collective baseline, by providing a application domain to implement a collective baseline by providing a
set of common formats and protocols for issuing and registering set of common formats and protocols for issuing and registering
Signed Statements and auditing Transparent Statements. Signed Statements and auditing Transparent Statements.
In order to accommodate as many Transparency Service implementations In order to accommodate as many Transparency Service implementations
as possible, this document only specifies the format of Signed as possible, this document only specifies the format of Signed
Statements (which must be used by all Issuers) and a very thin Statements (which must be used by all Issuers) and a very thin
wrapper format for Receipts, which specifies the Transparency Service wrapper format for Receipts, which specifies the Transparency Service
identity and the agility parameters for the Signed Inclusion Proofs. identity and the agility parameters for the Signed Inclusion Proofs.
The remaining details of the Receipt's contents are specified in The remaining details of the Receipt's contents are specified in
[I-D.draft-ietf-cose-merkle-tree-proofs]. [RFC9942].
Figure 2 illustrates the roles and processes that comprise a Figure 2 illustrates the roles and processes that comprise a
Transparency Service independent of any one use case: Transparency Service independent of any one use case:
* Issuers that use their credentials to create Signed Statements * Issuers that use their credentials to create Signed Statements
about Artifacts about Artifacts.
* Transparency Services that evaluate Signed Statements against * Transparency Services that evaluate Signed Statements against
Registration Policies, producing Receipts upon successful Registration Policies producing Receipts upon successful
Registration. The returned Receipt may be combined with the Registration. The returned Receipt may be combined with the
Signed Statement to create a Transparent Statement. Signed Statement to create a Transparent Statement.
* Relying Parties that: * Relying Parties that:
- collect Receipts of Signed Statements for subsequent - collect Receipts of Signed Statements for subsequent
registration of Transparent Statements; registration of Transparent Statements;
- retrieve Transparent Statements for analysis of Statements - retrieve Transparent Statements for analysis of Statements
about Artifacts themselves (e.g. verification); about Artifacts themselves (e.g., verification);
- or replay all the Transparent Statements to check for the - or replay all the Transparent Statements to check for the
consistency and correctness of the Transparency Service's consistency and correctness of the Transparency Service's
Verifiable Data Structure (e.g. auditing) Verifiable Data Structure (e.g., auditing).
In addition, Figure 2 illustrates multiple Transparency Services and In addition, Figure 2 illustrates multiple Transparency Services and
multiple Receipts as a single Signed Statement MAY be registered with multiple Receipts as a single Signed Statement MAY be registered with
one or more Transparency Service. Each Transparency Service produces one or more Transparency Service. Each Transparency Service produces
a Receipt, which may be aggregated in a single Transparent Statement, a Receipt, which may be aggregated in a single Transparent Statement,
demonstrating the Signed Statement was registered by multiple demonstrating the Signed Statement was registered by multiple
Transparency Services. Transparency Services.
The arrows indicate the flow of information. The arrows indicate the flow of information.
skipping to change at page 17, line 44 skipping to change at line 737
+---------------+ +---------------+
Figure 2: Relationship of Concepts in SCITT Figure 2: Relationship of Concepts in SCITT
The subsequent sections describe the main concepts, namely The subsequent sections describe the main concepts, namely
Transparency Service, Signed Statements, Registration, and Transparency Service, Signed Statements, Registration, and
Transparent Statements in more detail. Transparent Statements in more detail.
5.1. Transparency Service 5.1. Transparency Service
Transparency Services MUST produce COSE Receipts Transparency Services MUST produce COSE Receipts [RFC9942].
[I-D.draft-ietf-cose-merkle-tree-proofs].
Typically a Transparency Service has a single Issuer identity which Typically, a Transparency Service has a single Issuer identity that
is present in the iss Claim of Receipts for that service. is present in the iss Claim of Receipts for that service.
Multi-tenant support can be enabled through the use of identifiers in Multi-tenant support can be enabled through the use of identifiers in
the iss Claim, for example, ts.example. may have a distinct Issuer the iss Claim; for example, ts.example. may have a distinct Issuer
identity for each sub domain, such as tenant1.ts.example. and identity for each subdomain, such as tenant1.ts.example. and
tenant2.ts.example.. tenant2.ts.example..
5.1.1. Registration Policies 5.1.1. Registration Policies
Registration Policies refer to additional checks over and above the Registration Policies refer to additional checks over and above the
Mandatory Registration Checks that are performed before a Signed Mandatory Registration Checks that are performed before a Signed
Statement is registered to the Verifiable Data Structure. To enable Statement is registered to the Verifiable Data Structure. To enable
audit-ability, Transparency Services MUST maintain Registration auditability, Transparency Services MUST maintain Registration
Policies. The presence of an explicit transparent registration Policies. The presence of an explicit transparent registration
policy, even if it allows all authenticated submissions, facilitates policy, even if it allows all authenticated submissions, facilitates
service audit, and enables potential future changes to that policy. service audit, and enables potential future changes to that policy.
Beyond the mandatory Registration checks, the scope of additional Beyond the mandatory Registration checks, the scope of additional
checks, including no additional checks, is up to the implementation. checks, including no additional checks, is up to the implementation.
This specification leaves implementation, encoding and documentation This specification leaves implementation, encoding, and documentation
of Registration Policies and trust anchors to the operator of the of Registration Policies and trust anchors to the operator of the
Transparency Service. Transparency Service.
5.1.1.1. Mandatory Registration Checks 5.1.1.1. Mandatory Registration Checks
During Registration, a Transparency Service MUST syntactically check During Registration, a Transparency Service MUST syntactically check
the Issuer of the Signed Statement by cryptographically verifying the the Issuer of the Signed Statement by cryptographically verifying the
COSE signature according to [STD96]. The Issuer identity MUST be COSE signature according to [STD96]. The Issuer identity MUST be
bound to the Signed Statement by including an identifier in the bound to the Signed Statement by including an identifier in the
protected header. If the protected header includes multiple protected header. If the protected header includes multiple
identifiers, all those that are registered by the Transparency identifiers, all those that are registered by the Transparency
Service MUST be checked. Service MUST be checked.
Transparency Services MUST maintain a list of trust anchors (see Transparency Services MUST maintain a list of trust anchors (see
definition of trust anchor in [RFC4949]) in order to check the definition of trust anchor in [RFC4949]) in order to check the
signatures of Signed Statements, either separately, or inside signatures of Signed Statements either separately or inside
Registration Policies. Transparency Services MUST authenticate Registration Policies. Transparency Services MUST authenticate
Signed Statements as part of a Registration Policy. For instance, a Signed Statements as part of a Registration Policy. For instance, a
trust anchor could be an X.509 root certificate (directly or its trust anchor could be an X.509 root certificate (directly or its
thumbprint), a pointer to an OpenID Connect identity provider, or any thumbprint), a pointer to an OpenID Connect identity provider, or any
other trust anchor that can be referenced in a COSE header parameter. other trust anchor that can be referenced in a COSE header parameter.
When using X.509 Signed Statements, the Transparency Service MUST When using X.509 Signed Statements, the Transparency Service MUST
build and validate a complete certification path from an Issuer's build and validate a complete certification path from an Issuer's
certificate to one of the root certificates currently registered as a certificate to one of the root certificates currently registered as a
trust anchor by the Transparency Service. The protected header of trust anchor by the Transparency Service. The protected header of
skipping to change at page 19, line 44 skipping to change at line 822
collateral data required to perform their authentication, and the collateral data required to perform their authentication, and the
applicable Registration Policy at the time of Registration. applicable Registration Policy at the time of Registration.
5.1.2. Initialization and Bootstrapping 5.1.2. Initialization and Bootstrapping
Since the mandatory Registration checks rely on having registered Since the mandatory Registration checks rely on having registered
Signed Statements for the Registration Policy and trust anchors, Signed Statements for the Registration Policy and trust anchors,
Transparency Services MUST support at least one of the three Transparency Services MUST support at least one of the three
following bootstrapping mechanisms: following bootstrapping mechanisms:
* Pre-configured Registration Policy and trust anchors; * Preconfigured Registration Policy and trust anchors;
* Acceptance of a first Signed Statement whose payload is a valid * Acceptance of a first Signed Statement whose payload is a valid
Registration Policy, without performing Registration checks Registration Policy, without performing Registration checks; or
* An out-of-band authenticated management interface * An out-of-band authenticated management interface.
5.1.3. Verifiable Data Structure 5.1.3. Verifiable Data Structure
The security properties are determined by the choice of the The security properties are determined by the choice of the
Verifiable Data Structure ([I-D.draft-ietf-cose-merkle-tree-proofs]) Verifiable Data Structure (see [RFC9942]) used by the Transparency
used by the Transparency Service implementation. This verifiable Service implementation. This verifiable data structure MUST support
data structure MUST support the following security requirements: the following security requirements:
Append-Only: a property required for a verifiable data structure to Append-Only: a property required for a verifiable data structure to
be applicable to SCITT, ensuring that the Statement Sequence be applicable to SCITT, ensuring that the Statement Sequence
cannot be modified, deleted, or reordered. cannot be modified, deleted, or reordered.
Non-equivocation: there is no fork in the registered sequence of Non-equivocation: there is no fork in the registered sequence of
Signed Statements accepted by the Transparency Service and Signed Statements accepted by the Transparency Service and
committed to the Verifiable Data Structure. Everyone with access committed to the Verifiable Data Structure. Everyone with access
to its content sees the same ordered collection of Signed to its content sees the same ordered collection of Signed
Statements and can check that it is consistent with any Receipts Statements and can check that it is consistent with any Receipts
they have verified. they have verified.
Replayability: the Verifiable Data Structure includes sufficient Replayability: the Verifiable Data Structure includes sufficient
information to enable authorized actors with access to its content information to enable authorized actors with access to its content
to check that each data structure representing each Signed to check that each data structure representing each Signed
Statement has been correctly registered. Statement has been correctly registered.
In addition to Receipts, some verifiable data structures might In addition to Receipts, some verifiable data structures might
support additional proof types, such as proofs of consistency, or support additional proof types, such as proofs of consistency or
proofs of non-inclusion. proofs of non-inclusion.
Specific verifiable data structures, such those describes in Specific verifiable data structures, such those describes in
[RFC9162] and [I-D.draft-ietf-cose-merkle-tree-proofs], and the [RFC9162] and [RFC9942], and the review of their security
review of their security requirements for SCITT are out of scope for requirements for SCITT are out of scope for this document.
this document.
5.1.4. Adjacent Services 5.1.4. Adjacent Services
Transparency Services can be deployed along side other database or Transparency Services can be deployed alongside other database or
object storage technologies. For example, a Transparency Service object storage technologies. For example, a Transparency Service
that supports a software package management system, might be that supports a software package management system, might be
referenced from the APIs exposed for package management. It can also referenced from the APIs exposed for package management. It can also
provide the ability to request a fresh Receipt for a given software provide the ability to request a fresh Receipt for a given software
package, or a list of Signed Statements associated with that package. package or a list of Signed Statements associated with that package.
6. Signed Statements 6. Signed Statements
This specification prioritizes conformance to [STD96] and its This specification prioritizes conformance to [STD96] and its
required and optional properties. Signed Statements produced by required and optional properties. Signed Statements produced by
Issuers must be COSE_Sign1 messages, as defined by [STD96]. Profiles Issuers must be COSE_Sign1 messages, as defined by [STD96]. Profiles
and implementation specific choices should be used to determine and implementation-specific choices should be used to determine
admissibility of conforming messages. This specification is left admissibility of conforming messages. This specification is left
intentionally open to allow implementations to make Registration intentionally open to allow implementations to make Registration
restrictions that make the most sense for their operational use restrictions that make the most sense for their operational use
cases. cases.
There are many types of Statements (such as SBOMs, malware scans, There are many types of Statements (such as an SBOM, malware scans,
audit reports, policy definitions) that Issuers may want to turn into audit reports, policy definitions) that Issuers may want to turn into
Signed Statements. An Issuer must first decide on a suitable format Signed Statements. An Issuer must first decide on a suitable format
(3: payload type) to serialize the Statement payload. For a software (3: payload type) to serialize the Statement payload. For a software
supply chain, payloads describing the software Artifacts may include: supply chain, payloads describing the software Artifacts may include:
* [CoSWID] Concise Software Identification Tags format * [CoSWID] Concise Software Identification Tags format
* [CycloneDX] Bill of Materials format * [CycloneDX] Bill of Materials format
* [in-toto] Supply chain description metadata * [in-toto] Supply chain description metadata
skipping to change at page 21, line 41 skipping to change at line 905
* [SLSA] Supply-chain Levels for Software Artifacts * [SLSA] Supply-chain Levels for Software Artifacts
* [SWID] Software Identification Tag format * [SWID] Software Identification Tag format
Issuers can produce Signed Statements about different Artifacts under Issuers can produce Signed Statements about different Artifacts under
the same Identity. Issuers and Relying Parties must be able to the same Identity. Issuers and Relying Parties must be able to
recognize the Artifact to which the Statements pertain by looking at recognize the Artifact to which the Statements pertain by looking at
the Signed Statement. The iss and sub Claims, within the CWT Claims the Signed Statement. The iss and sub Claims, within the CWT Claims
protected header, are used to identify the Artifact the Statement protected header, are used to identify the Artifact the Statement
pertains to. (See Subject under Section 3 Terminology.) pertains to. (See Subject in Section 3.)
Issuers MAY use different signing keys (identified by kid in the Issuers MAY use different signing keys (identified by kid in the
[STD96] protected header) for different Artifacts or sign all Signed protected header from [STD96]) for different Artifacts or sign all
Statements under the same key. Signed Statements under the same key.
An Issuer can make multiple Statements about the same Artifact. For An Issuer can make multiple Statements about the same Artifact. For
example, an Issuer can make amended Statements about the same example, an Issuer can make amended Statements about the same
Artifact as their view changes over time. Artifact as their view changes over time.
Multiple Issuers can make different, even conflicting Statements, Multiple Issuers can make different, even conflicting, Statements
about the same Artifact. Relying Parties can choose which Issuers about the same Artifact. Relying Parties can choose which Issuers
they trust. they trust.
Multiple Issuers can make the same Statement about a single Artifact, Multiple Issuers can make the same Statement about a single Artifact,
affirming multiple Issuers agree. affirming multiple Issuers agree.
Additionally, x5chain that corresponds to either x5t or kid Additionally, an x5chain that corresponds to either x5t or kid
identifying the leaf certificate in the included certification path identifying the leaf certificate in the included certification path
MAY be included in the unprotected header of the COSE Envelope. MAY be included in the unprotected header of the COSE Envelope.
* When using x.509 certificates, support for either x5t or x5chain * When using x.509 certificates, support for either x5t or x5chain
in the protected header is REQUIRED to implement. in the protected header is REQUIRED to implement.
* Support for kid in the protected header and x5chain in the * Support for kid in the protected header and x5chain in the
unprotected header is OPTIONAL to implement. unprotected header is OPTIONAL to implement.
When x5t or x5chain is present in the protected header, iss MUST be a When x5t or x5chain is present in the protected header, iss MUST be a
string that meets URI requirements defined in [RFC8392]. The iss string that meets URI requirements defined in [RFC8392]. The iss
value's length MUST be between 1 and 8192 characters in length. value's length MUST be between 1 and 8192 characters in length.
The kid header parameter MUST be present when neither x5t nor x5chain The kid header parameter MUST be present when neither x5t nor x5chain
is present in the protected header. Key discovery protocols are out- is present in the protected header. Key discovery protocols are out
of-scope of this document. of scope of this document.
The protected header of a Signed Statement and a Receipt MUST include The protected header of a Signed Statement and a Receipt MUST include
the CWT Claims header parameter as specified in Section 2 of the CWT Claims header parameter as specified in Section 2 of
[RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim [RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim
label 1) and the Subject Claim (Claim label 2) [IANA.cwt]. label 1) and the Subject Claim (Claim label 2) [IANA.cwt].
A Receipt is a Signed Statement (COSE_Sign1) with additional Claims A Receipt is a Signed Statement (COSE_Sign1) with additional Claims
in its protected header related to verifying the inclusion proof in in its protected header related to verifying the inclusion proof in
its unprotected header. See its unprotected header. See [RFC9942].
[I-D.draft-ietf-cose-merkle-tree-proofs].
6.1. Signed Statement Examples 6.1. Signed Statement Examples
Figure 3 illustrates a normative CDDL definition [RFC8610] for the Figure 3 illustrates a normative CDDL definition [RFC8610] for the
protected header and unprotected header of Signed Statements and protected header and unprotected header of Signed Statements and
Receipts. Receipts.
The SCITT architecture specifies the minimal mandatory labels. The SCITT architecture specifies the minimal mandatory labels.
Implementation-specific Registration Policies may define additional Implementation-specific Registration Policies may define additional
mandatory labels. mandatory labels.
skipping to change at page 23, line 39 skipping to change at line 993
} }
Unprotected_Header = { Unprotected_Header = {
? &(x5chain: 33) => COSE_X509 ? &(x5chain: 33) => COSE_X509
? &(receipts: 394) => [+ Receipt] ? &(receipts: 394) => [+ Receipt]
* label => any * label => any
} }
label = int / tstr label = int / tstr
Figure 3: CDDL definition for Signed Statements and Receipts Figure 3: CDDL Definition for Signed Statements and Receipts
Figure 4 illustrates an instance of a Signed Statement in Extended Figure 4 illustrates an instance of a Signed Statement in Extended
Diagnostic Notation (EDN), with a payload that is detached. Detached Diagnostic Notation (EDN), with a payload that is detached. Detached
payloads support large Statements, and ensure Signed Statements can payloads support large Statements and ensure Signed Statements can
integrate with existing storage systems. integrate with existing storage systems.
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 /
] ]
) )
Figure 4: CBOR Extended Diagnostic Notation example of a Signed Figure 4: CBOR-Extended Diagnostic Notation Example of a Signed
Statement Statement
Figure 5 illustrates the decoded protected header of the Signed Figure 5 illustrates the decoded protected header of the Signed
Statement in Figure 4. It indicates the Signed Statement is securing Statement in Figure 4. It indicates the Signed Statement is securing
a JSON content type, and identifying the content with the sub Claim a JSON content type and identifying the content with the sub Claim
"vendor.product.example". "vendor.product.example".
{ / 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 /
} }
} }
Figure 5: CBOR Extended Diagnostic Notation example of a Signed Figure 5: CBOR-Extended Diagnostic Notation Example of a Signed
Statement's Protected Header Statement's Protected Header
6.2. Signing Large or Sensitive Statements 6.2. Signing Large or Sensitive Statements
Statements payloads might be too large or too sensitive to be sent to Statement payloads might be too large or too sensitive to be sent to
a remote Transparency Service. In these cases a Statement can be a remote Transparency Service. In these cases, a Statement can be
made over the hash of a payload, rather than the full payload bytes. made over the hash of a payload rather than the full payload bytes.
.----+-----. .----+-----.
| Artifact | | Artifact |
'+-+-------' '+-+-------'
| | | |
.-' v .-' v
| .--+-------. | .--+-------.
| | Hash +-+ | | Hash +-+
| '----------' | /\ | '----------' | /\
'-. | / \ .----------. '-. | / \ .----------.
skipping to change at page 26, line 10 skipping to change at line 1086
v v
.----+-------. .----+-------.
| COSE_Sign1 | | COSE_Sign1 |
'------------' '------------'
6.3. Registration of Signed Statements 6.3. Registration of Signed Statements
To register a Signed Statement, the Transparency Service performs the To register a Signed Statement, the Transparency Service performs the
following steps: following steps:
1. *Client authentication:* A Client authenticates with the 1. Client Authentication
Transparency Service before registering Signed Statements on
behalf of one or more Issuers. Authentication and authorization
are implementation-specific and out of scope of the SCITT
architecture.
2. *TS Signed Statement Verification and Validation:* The A Client authenticates with the Transparency Service before
Transparency Service MUST perform signature verification per registering Signed Statements on behalf of one or more Issuers.
Section 4.4 of [STD96] and MUST verify the signature of the Authentication and authorization are implementation specific and
Signed Statement with the signature algorithm and verification out of scope of the SCITT architecture.
key of the Issuer per [RFC9360]. The Transparency Service MUST
also check the Signed Statement includes the required protected
headers. The Transparency Service MAY validate the Signed
Statement payload in order to enforce domain specific
registration policies that apply to specific content types.
3. *Apply Registration Policy:* The Transparency Service MUST check 2. TS Signed Statement Verification and Validation
the attributes required by a Registration Policy are present in
the protected headers. Custom Signed Statements are evaluated
given the current Transparency Service state and the entire
Envelope and may use information contained in the attributes of
named policies.
4. *Register the Signed Statement* The Transparency Service MUST perform signature verification per
Section 4.4 of RFC 9052 [STD96] and MUST verify the signature of
the Signed Statement with the signature algorithm and
verification key of the Issuer per [RFC9360]. The Transparency
Service MUST also check that the Signed Statement includes the
required protected headers. The Transparency Service MAY
validate the Signed Statement payload in order to enforce domain-
specific registration policies that apply to specific content
types.
5. *Return the Receipt*, which MAY be asynchronous from 3. Apply Registration Policy
Registration. The Transparency Service MUST be able to provide a
Receipt for all registered Signed Statements. Details about The Transparency Service MUST check the attributes required by a
generating Receipts are described in Section 7. Registration Policy are present in the protected headers. Custom
Signed Statements are evaluated given the current Transparency
Service state and the entire Envelope and may use information
contained in the attributes of named policies.
4. Register the Signed Statement
5. Return the Receipt
This MAY be asynchronous from Registration. The Transparency
Service MUST be able to provide a Receipt for all registered
Signed Statements. Details about generating Receipts are
described in Section 7.
The last two steps may be shared between a batch of Signed Statements The last two steps may be shared between a batch of Signed Statements
registered in the Verifiable Data Structure. registered in the Verifiable Data Structure.
A Transparency Service MUST ensure that a Signed Statement is A Transparency Service MUST ensure that a Signed Statement is
registered before releasing its Receipt. registered before releasing its Receipt.
A Transparency Service MAY accept a Signed Statement with content in A Transparency Service MAY accept a Signed Statement with content in
its unprotected header, and MAY use values from that unprotected its unprotected header and MAY use values from that unprotected
header during verification and registration policy evaluation. header during verification and registration policy evaluation.
However, the unprotected header of a Signed Statement MUST be set to However, the unprotected header of a Signed Statement MUST be set to
an empty map before the Signed Statement can be included in a an empty map before the Signed Statement can be included in a
Statement Sequence. Statement Sequence.
The same Signed Statement may be independently registered in multiple The same Signed Statement may be independently registered in multiple
Transparency Services, producing multiple, independent Receipts. The Transparency Services, producing multiple independent Receipts. The
multiple Receipts may be attached to the unprotected header of the multiple Receipts may be attached to the unprotected header of the
Signed Statement, creating a Transparent Statement. Signed Statement creating a Transparent Statement.
An Issuer that knows of a changed state of quality for an Artifact, An Issuer that knows of a changed state of quality for an Artifact
SHOULD Register a new Signed Statement, using the same 15 CWT iss and SHOULD Register a new Signed Statement using the same 15 CWT iss and
sub Claims. sub Claims.
7. Transparent Statements 7. Transparent Statements
The Client (which is not necessarily the Issuer) that registers a The Client (which is not necessarily the Issuer) that registers a
Signed Statement and receives a Receipt can produce a Transparent Signed Statement and receives a Receipt can produce a Transparent
Statement by adding the Receipt to the unprotected header of the Statement by adding the Receipt to the unprotected header of the
Signed Statement. Client applications MAY register Signed Statements Signed Statement. Client applications MAY register Signed Statements
on behalf of one or more Issuers. Client applications MAY request on behalf of one or more Issuers. Client applications MAY request
Receipts regardless of the identity of the Issuer of the associated Receipts regardless of the identity of the Issuer of the associated
Signed Statement. Signed Statement.
When a Signed Statement is registered by a Transparency Service a When a Signed Statement is registered by a Transparency Service a
Receipt becomes available. When a Receipt is included in a Signed Receipt becomes available. When a Receipt is included in a Signed
Statement a Transparent Statement is produced. Statement, a Transparent Statement is produced.
Receipts are based on Signed Inclusion Proofs as described in COSE Receipts are based on Signed Inclusion Proofs as described in COSE
Receipts [I-D.draft-ietf-cose-merkle-tree-proofs] that also provides Receipts [RFC9942], which also provides the COSE header parameter
the COSE header parameter semantics for label 394. semantics for label 394.
The Registration time is recorded as the timestamp when the The Registration time is recorded as the timestamp when the
Transparency Service added the Signed Statement to its Verifiable Transparency Service added the Signed Statement to its Verifiable
Data Structure. Data Structure.
Figure 6 illustrates a normative CDDL definition of Transparent Figure 6 illustrates a normative CDDL definition of Transparent
Statements. See Figure 3 for the CDDL rule that defines 'COSE_Sign1' Statements. See Figure 3 for the CDDL rule that defines 'COSE_Sign1'
as specified in Section 4.2 of [STD96] as specified in Section 4.2 of RFC 9052 [STD96].
Transparent_Statement = #6.18(COSE_Sign1) Transparent_Statement = #6.18(COSE_Sign1)
Unprotected_Header = { Unprotected_Header = {
&(receipts: 394) => [+ Receipt] &(receipts: 394) => [+ Receipt]
} }
Figure 6: CDDL definition for a Transparent Statement Figure 6: CDDL Definition for a Transparent Statement
Figure 7 illustrates a Transparent Statement with a detached payload, Figure 7 illustrates a Transparent Statement with a detached payload
and two Receipts in its unprotected header. The type of label 394 and two Receipts in its unprotected header. The type of label 394
receipts in the unprotected header is a CBOR array that can contain receipts in the unprotected header is a CBOR array that can contain
one or more Receipts (each entry encoded as a .cbor encoded one or more Receipts (each entry encoded as a .cbor-encoded Receipt).
Receipts).
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 /
] ]
) )
Figure 7: CBOR Extended Diagnostic Notation example of a Figure 7: CBOR-Extended Diagnostic Notation Example of a
Transparent Statement Transparent Statement
Figure 8 one of the decoded Receipt from Figure 7. The Receipt Figure 8 illustrates one of the decoded Receipts from Figure 7. The
contains inclusion proofs for verifiable data structures. The Receipt contains inclusion proofs for verifiable data structures.
unprotected header contains verifiable data structure proofs. See The unprotected header contains verifiable data structure proofs.
the protected header for details regarding the specific verifiable See the protected header for details regarding the specific
data structure used. Per the COSE Verifiable Data Structure verifiable data structure used. Per the COSE Verifiable Data
Algorithms Registry documented in Structure Algorithms Registry documented in [RFC9942], the COSE key
[I-D.draft-ietf-cose-merkle-tree-proofs], the COSE key type type RFC9162_SHA256 is value 1. Labels identify inclusion proofs
RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and (-1) and consistency proofs (-2).
consistency proofs (-2).
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 /
] ]
) )
Figure 8: CBOR Extended Diagnostic Notation example of a Receipt Figure 8: CBOR-Extended Diagnostic Notation Example of a Receipt
Figure 9 illustrates the decoded protected header of the Transparent Figure 9 illustrates the decoded protected header of the Transparent
Statement in Figure 7. The verifiable data structure (-111) uses 1 Statement in Figure 7. The verifiable data structure (-111) uses 1
from (RFC9162_SHA256). from (RFC9162_SHA256).
{ / 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 /
} }
} }
Figure 9: CBOR Extended Diagnostic Notation example of a Figure 9: CBOR-Extended Diagnostic Notation Example of a
Receipt's Protected Header Receipt's Protected Header
Figure 10 illustrates the decoded inclusion proof from Figure 8. Figure 10 illustrates the decoded inclusion proof from Figure 8.
This inclusion proof indicates that the size of the Verifiable Data This inclusion proof indicates that the size of the Verifiable Data
Structure was 8 at the time the Receipt was issued. The structure of Structure was 8 at the time the Receipt was issued. The structure of
this inclusion proof is specific to the verifiable data structure this inclusion proof is specific to the verifiable data structure
used (RFC9162_SHA256). used (RFC9162_SHA256).
[ / 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 /
] ]
] ]
Figure 10: CBOR Extended Diagnostic Notation example of a Figure 10: CBOR-Extended Diagnostic Notation Example of a
Receipt's Inclusion Proof Receipt's Inclusion Proof
7.1. Validation 7.1. Validation
Relying Parties MUST apply the verification process as described in Relying Parties MUST apply the verification process as described in
Section 4.4 of [STD96], when checking the signature of Signed Section 4.4 of RFC 9052 [STD96] when checking the signature of Signed
Statements and Receipts. Statements and Receipts.
A Relying Party MUST trust the verification key or certificate and A Relying Party MUST trust the verification key or certificate and
the associated identity of at least one Issuer of a Receipt. the associated identity of at least one Issuer of a Receipt.
A Relying Party MAY decide to verify only a single Receipt that is A Relying Party MAY decide to verify only a single Receipt that is
acceptable to them and not check the signature on the Signed acceptable to them and not check the signature on the Signed
Statement or Receipts which rely on verifiable data structures which Statement or Receipts that rely on verifiable data structures they do
they do not understand. not understand.
APIs exposing verification logic for Transparent Statements may APIs exposing verification logic for Transparent Statements may
provide more details than a single boolean result. For example, an provide more details than a single boolean result. For example, an
API may indicate if the signature on the Receipt or Signed Statement API may indicate if the signature on the Receipt or Signed Statement
is valid, if Claims related to the validity period are valid, or if is valid, if Claims related to the validity period are valid, or if
the inclusion proof in the Receipt is valid. the inclusion proof in the Receipt is valid.
Relying Parties MAY be configured to re-verify the Issuer's Signed Relying Parties MAY be configured to re-verify the Issuer's Signed
Statement locally. Statement locally.
skipping to change at page 30, line 29 skipping to change at line 1301
8. Privacy Considerations 8. Privacy Considerations
Interactions with Transparency Services are expected to use Interactions with Transparency Services are expected to use
appropriately strong encryption and authorization technologies. appropriately strong encryption and authorization technologies.
The Transparency Service is trusted with the confidentiality of the The Transparency Service is trusted with the confidentiality of the
Signed Statements presented for Registration. Issuers and Clients Signed Statements presented for Registration. Issuers and Clients
are responsible for verifying that the Transparency Service's privacy are responsible for verifying that the Transparency Service's privacy
and security posture is suitable for the contents of the Signed and security posture is suitable for the contents of the Signed
Statements they submit prior to Registration. Issuers must carefully Statements they submit prior to Registration. Issuers must carefully
review the inclusion of private, confidential, or personally review the inclusion of private, confidential, or Personally
identifiable information (PII) in their Statements against the Identifiable Information (PII) in their Statements against the
Transparency Service's privacy posture. Transparency Service's privacy posture.
In some deployments a special role such as an Auditor might require In some deployments, a special role such as an Auditor might require
and be given access to both the Transparency Service and related and be given access to both the Transparency Service and related
Adjacent Services. Adjacent Services.
Transparency Services can leverage Verifiable Data Structures which Transparency Services can leverage Verifiable Data Structures that
only retain cryptographic metadata (e.g. a hash), rather than the only retain cryptographic metadata (e.g., a hash) rather than the
complete Signed Statement, as part of a defense in depth approach to complete Signed Statement as part of an in-depth defensive approach
maintaining confidentiality. By analyzing the relationship between to maintaining confidentiality. By analyzing the relationship
data stored in the Transparency Service and data stored in Adjacent between data stored in the Transparency Service and data stored in
Services, it is possible to perform metadata analysis, which could Adjacent Services, it is possible to perform metadata analysis, which
reveal the order in which artifacts were built, signed, and uploaded. could reveal the order in which artifacts were built, signed, and
uploaded.
9. Security Considerations 9. Security Considerations
SCITT provides the following security guarantees: SCITT provides the following security guarantees:
1. Statements made by Issuers about supply chain Artifacts are 1. Statements made by Issuers about supply chain Artifacts are
identifiable and can be authenticated identifiable and can be authenticated.
2. Statement provenance and history can be independently and 2. Statement provenance and history can be independently and
consistently audited consistently audited.
3. Issuers can efficiently prove that their Statement is logged by a 3. Issuers can efficiently prove that their Statement is logged by a
Transparency Service Transparency Service.
The first guarantee is achieved by requiring Issuers to sign their The first guarantee is achieved by requiring Issuers to sign their
Statements. The second guarantee is achieved by proving a Signed Statements. The second guarantee is achieved by proving a Signed
Statement is present in a Verifiable Data Structure. The third Statement is present in a Verifiable Data Structure. The third
guarantee is achieved by the combination of both of these steps. guarantee is achieved by the combination of both of these steps.
In addition to deciding whether to trust a Transparency Service, In addition to deciding whether to trust a Transparency Service,
Relying Parties can use the history of registered Signed Statements Relying Parties can use the history of registered Signed Statements
to decide which Issuers they choose to trust. This decision process to decide which Issuers they choose to trust. This decision process
is out of scope of this document. is out of scope of this document.
skipping to change at page 31, line 43 skipping to change at line 1363
by an Issuer. A registered Statement may be superseded by a by an Issuer. A registered Statement may be superseded by a
subsequently submitted Signed Statement from the same Issuer, with subsequently submitted Signed Statement from the same Issuer, with
the same subject in the CWT Claims protected header. Other Issuers the same subject in the CWT Claims protected header. Other Issuers
may make new Statements to reflect new or corrected information. may make new Statements to reflect new or corrected information.
Relying Parties may choose to include or exclude Statements from Relying Parties may choose to include or exclude Statements from
Issuers to determine the accuracy of a collection of Statements. Issuers to determine the accuracy of a collection of Statements.
9.3. Issuer Participation 9.3. Issuer Participation
Issuers can refuse to register their Statements with a Transparency Issuers can refuse to register their Statements with a Transparency
Service, or selectively submit some but not all the Statements they Service or selectively submit some but not all the Statements they
issue. It is important for Relying Parties not to accept Signed issue. It is important for Relying Parties not to accept Signed
Statements for which they cannot discover Receipts issued by a Statements for which they cannot discover Receipts issued by a
Transparency Service they trust. Transparency Service they trust.
9.4. Key Management 9.4. Key Management
Issuers and Transparency Services MUST: Issuers and Transparency Services MUST:
* carefully protect their private signing keys * carefully protect their private signing keys
* avoid using keys for more than one purpose * avoid using keys for more than one purpose
* rotate their keys at a cryptoperiod (defined in [RFC4949]) * rotate their keys at a cryptoperiod (defined in [RFC4949])
appropriate for the key algorithm and domain-specific regulations appropriate for the key-algorithm and domain-specific regulations
9.4.1. Verifiable Data Structure 9.4.1. Verifiable Data Structure
The security considerations for specific Verifiable Data Structures The security considerations for specific Verifiable Data Structures
are out of scope for this document. See are out of scope for this document. See [RFC9942] for the generic
[I-D.draft-ietf-cose-merkle-tree-proofs] for the generic security security considerations that apply to Verifiable Data Structure and
considerations that apply to Verifiable Data Structure and Receipts. Receipts.
9.4.2. Key Compromise 9.4.2. Key Compromise
It is important for Issuers and Transparency Services to clearly It is important for Issuers and Transparency Services to clearly
communicate when keys are compromised, so that Signed Statements can communicate when keys are compromised so that Signed Statements can
be rejected by Transparency Services or Receipts can be ignored by be rejected by Transparency Services or Receipts can be ignored by
Relying Parties. Transparency Services whose receipt signing keys Relying Parties. Transparency Services whose receipt signing keys
have been compromised can roll back their Statement Sequence to a have been compromised can roll back their Statement Sequence to a
point before compromise, establish new credentials, and use them to point before compromise, establish new credentials, and use the new
issue fresh Receipts going forward. Issuers are encouraged to follow credentials to issue fresh Receipts going forward. Issuers are
existing best practices if their credentials are compromised. encouraged to follow existing best practices if their credentials are
Revocation strategies for compromised keys are out of scope for this compromised. Revocation strategies for compromised keys are out of
document. scope for this document.
9.4.3. Bootstrapping 9.4.3. Bootstrapping
Bootstrapping mechanisms that solely rely on Statement registration Bootstrapping mechanisms that solely rely on Statement registration
to set and update registration policy can be audited without to set and update registration policy can be audited without
additional implementation-specific knowledge, and are therefore additional implementation-specific knowledge; therefore, they are
preferable. Mechanisms that rely on pre-configured values and do not preferable. Mechanisms that rely on preconfigured values and do not
allow updates are unsuitable for use in long-lived service allow updates are unsuitable for use in long-lived service
deployments, in which the ability to patch a potentially faulty deployments in which the ability to patch a potentially faulty policy
policy is essential. is essential.
9.5. Implications of Media-Type Usage 9.5. Implications of Media Type Usage
The Statement (scitt-statement+cose) and Receipt (scitt-receipt+cose) The Statement (scitt-statement+cose) and Receipt (scitt-receipt+cose)
media types describe the expected content of COSE envelope headers. media types describe the expected content of COSE envelope headers.
The payload media type ('content type') is included in the COSE The payload media type ('content type') is included in the COSE
envelope header. [STD96] describes the security implications of envelope header. [STD96] describes the security implications of
reliance on this header parameter. reliance on this header parameter.
Both media types describe COSE_Sign1 messages, which include a Both media types describe COSE_Sign1 messages, which include a
signature, and therefore provide integrity protection. signature and therefore provide integrity protection.
9.6. Cryptographic Agility 9.6. Cryptographic Agility
Because the SCITT Architecture leverages [STD96] for Statements and Because the SCITT Architecture leverages [STD96] for Statements and
Receipts, it benefits from the format's cryptographic agility. Receipts, it benefits from the format's cryptographic agility.
9.7. Threat Model 9.7. Threat Model
This section provides a generic threat model for SCITT, describing This section provides a generic threat model for SCITT, describing
its residual security properties when some of its actors (Issuers, its residual security properties when some of its actors (Issuers,
skipping to change at page 33, line 31 skipping to change at line 1446
The SCITT Architecture does not require trust in a single centralized The SCITT Architecture does not require trust in a single centralized
Transparency Service. Different actors may rely on different Transparency Service. Different actors may rely on different
Transparency Services, each registering a subset of Signed Statements Transparency Services, each registering a subset of Signed Statements
subject to their own policy. Running multiple, independent subject to their own policy. Running multiple, independent
Transparency Services provides different organizations to represent Transparency Services provides different organizations to represent
consistent or divergent opinions. It is the role of the relying consistent or divergent opinions. It is the role of the relying
party to decide which Transparency Services and Issuers they choose party to decide which Transparency Services and Issuers they choose
to trust for their scenario. to trust for their scenario.
In both cases, the SCITT architecture provides generic, universally- In both cases, the SCITT architecture provides generic, universally
verifiable cryptographic proofs to hold Issuers or Transparency verifiable cryptographic proofs to hold Issuers or Transparency
Services accountable. On one hand, this enables valid actors to Services accountable. On one hand, this enables valid actors to
detect and disambiguate malicious actors who employ Equivocation with detect and disambiguate malicious actors who employ Equivocation with
Signed Statements to different entities. On the other hand, their Signed Statements to different entities. On the other hand, their
liability and the resulting damage to their reputation are liability and the resulting damage to their reputation are
application specific, and out of scope of the SCITT architecture. application specific and out of scope of the SCITT architecture.
Relying Parties and Auditors need not be trusted by other actors. So Relying Parties and Auditors need not be trusted by other actors. So
long as actors maintain proper control of their signing keys and long as actors maintain proper control of their signing keys and
identity infrastructure they cannot "frame" an Issuer or a identity infrastructure they cannot "frame" an Issuer or a
Transparency Service for Signed Statements they did not issue or Transparency Service for Signed Statements they did not issue or
register. register.
10. IANA Considerations 10. IANA Considerations
IANA is requested to register: IANA has registered the following media types in the "application"
subregistry of the "Media Types" registry group [IANA.media-types]:
* the media type application/scitt-statement+cose in the "Media
Types" registry, see below.
* the media type application/scitt-receipt+cose in the "Media Types" * application/scitt-statement+cose (see Section 10.1)
registry, see below.
10.1. Media Type application/scitt-statement+cose Registration * application/scitt-receipt+cose (see Section 10.2)
IANA is requested to add the following Media-Type to the "Media 10.1. Registration of application/scitt-statement+cose
Types" registry [IANA.media-types].
+======================+======================+============+ +======================+======================+=============+
| Name | Template | Reference | | Name | Template | Reference |
+======================+======================+============+ +======================+======================+=============+
| scitt-statement+cose | application/scitt- | Section 6 | | scitt-statement+cose | application/scitt- | Section 6 |
| | statement+cose | of RFCthis | | | statement+cose | of RFC 9943 |
+----------------------+----------------------+------------+ +----------------------+----------------------+-------------+
Table 1: SCITT Signed Statement Media Type Registration Table 1: SCITT Signed Statement Media Type Registration
Type name: application Type name: application
Subtype name: statement+cose Subtype name: statement+cose
Required parameters: n/a
Optional parameters: n/a Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary (CBOR data item) Encoding considerations: binary (CBOR data item)
Security considerations: Section 9.5 of RFCthis
Security considerations: Section 9.5 of RFC 9943
Interoperability considerations: none Interoperability considerations: none
Published specification: RFCthis
Published specification: RFC 9943
Applications that use this media type: Used to provide an Applications that use this media type: Used to provide an
identifiable and non-repudiable Statement about an Artifact signed identifiable and non-repudiable Statement about an Artifact signed
by an Issuer. by an Issuer.
Fragment identifier considerations: n/a
Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Fragment identifier considerations: N/A
File extension(s): .scitt Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): .scitt
Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Macintosh file type code(s): N/A
Person and email address to contact for further information: iesg@ie
tf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
10.2. Media Type application/scitt-receipt+cose Registration 10.2. Registration of application/scitt-receipt+cose Registration
+====================+================================+============+ +====================+================================+=============+
| Name | Template | Reference | | Name | Template | Reference |
+====================+================================+============+ +====================+================================+=============+
| scitt-receipt+cose | application/scitt-receipt+cose | Section 7 | | scitt-receipt+cose | application/scitt- | Section 7 |
| | | of RFCthis | | | receipt+cose | of RFC 9943 |
+--------------------+--------------------------------+------------+ +--------------------+--------------------------------+-------------+
Table 2: SCITT Receipt Media Type Registration Table 2: SCITT Receipt Media Type Registration
Type name: application Type name: application
Subtype name: receipt+cose Subtype name: receipt+cose
Required parameters: n/a
Optional parameters: n/a Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary (CBOR data item) Encoding considerations: binary (CBOR data item)
Security considerations: Section 9.5 of RFCthis
Security considerations: Section 9.5 of RFC 9943
Interoperability considerations: none Interoperability considerations: none
Published specification: RFCthis
Published specification: RFC 9943
Applications that use this media type: Used to establish or verify Applications that use this media type: Used to establish or verify
transparency over Statements. Typically emitted by a Transparency transparency over Statements. Typically emitted by a Transparency
Service, for the benefit of Relying Parties wanting to ensure Non- Service for the benefit of Relying Parties wanting to ensure Non-
equivocation over all or part of a Statement Sequence. equivocation over all or part of a Statement Sequence.
Fragment identifier considerations: n/a
Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A Fragment identifier considerations: N/A
File extension(s): .receipt Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): .receipt
Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Macintosh file type code(s): N/A
Person and email address to contact for further information: iesg@ie
tf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
10.3. CoAP Content-Format Registrations 10.3. CoAP Content-Format Registrations
IANA is requested to register the following Content-Format numbers in IANA has registered the following Content-Format numbers in the "CoAP
the "CoAP Content-Formats" sub-registry, within the "Constrained Content-Formats" subregistry within the "Constrained RESTful
RESTful Environments (CoRE) Parameters" Registry Environments (CoRE) Parameters" registry group [IANA.core-parameters]
[IANA.core-parameters] in the 256-9999 Range: in the 256-9999 range:
+======================+================+=====+===========+ +======================+================+=====+===========+
| Content-Type | Content Coding | ID | Reference | | Content Type | Content Coding | ID | Reference |
+======================+================+=====+===========+ +======================+================+=====+===========+
| application/scitt- | - | 277 | RFCthis | | application/scitt- | - | 277 | RFC 9943 |
| statement+cose | | | | | statement+cose | | | |
+----------------------+----------------+-----+-----------+ +----------------------+----------------+-----+-----------+
| application/scitt- | - | 278 | RFCthis | | application/scitt- | - | 278 | RFC 9943 |
| receipt+cose | | | | | receipt+cose | | | |
+----------------------+----------------+-----+-----------+ +----------------------+----------------+-----+-----------+
Table 3: SCITT Content-Formats Registration Table 3: SCITT Content-Formats Registration
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.draft-ietf-cose-merkle-tree-proofs]
Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "COSE (CBOR Object Signing and Encryption)
Receipts", Work in Progress, Internet-Draft, draft-ietf-
cose-merkle-tree-proofs-17, 10 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
merkle-tree-proofs-17>.
[IANA.core-parameters] [IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE) IANA, "Constrained RESTful Environments (CoRE)
Parameters", Parameters",
<https://www.iana.org/assignments/core-parameters>. <https://www.iana.org/assignments/core-parameters>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt>. <https://www.iana.org/assignments/cwt>.
[IANA.media-types] [IANA.media-types]
IANA, "Media Types", IANA, "Media Types",
<https://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://doi.org/10.17487/RFC2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://doi.org/10.17487/RFC6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://doi.org/10.17487/RFC8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://doi.org/10.17487/RFC8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://doi.org/10.17487/RFC8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509 Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://doi.org/10.17487/RFC9360>. 2023, <https://www.rfc-editor.org/info/rfc9360>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in [RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
<https://doi.org/10.17487/RFC9597>. <https://www.rfc-editor.org/info/rfc9597>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, March 2026,
<https://www.rfc-editor.org/info/rfc9942>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://doi.org/10.17487/RFC8949>. <https://www.rfc-editor.org/info/rfc8949>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): [STD96] Internet Standard 96,
<https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://doi.org/10.17487/RFC9052>. <https://www.rfc-editor.org/info/rfc9052>.
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.
11.2. Informative References 11.2. Informative References
[CoSWID] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. [CoSWID] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags", Waltermire, "Concise Software Identification Tags",
RFC 9393, DOI 10.17487/RFC9393, June 2023, RFC 9393, DOI 10.17487/RFC9393, June 2023,
<https://doi.org/10.17487/RFC9393>. <https://www.rfc-editor.org/info/rfc9393>.
[CycloneDX] [CycloneDX]
"CycloneDX", n.d., "CycloneDX",
<https://cyclonedx.org/specification/overview/>. <https://cyclonedx.org/specification/overview/>.
[EQUIVOCATION] [EQUIVOCATION]
Chun, B., Maniatis, P., Shenker, S., and J. Kubiatowicz,
"Attested Append-Only Memory: Making Adversaries Stick to "Attested Append-Only Memory: Making Adversaries Stick to
their Word", DOI 10.1145/1323293.1294280, n.d., their Word", ACM SIGOPS Operating Systems Review, vol. 41,
<https://www.read.seas.harvard.edu/~kohler/class/08w-dsi/ no. 6, pp. 189-204, DOI 10.1145/1323293.1294280, 14
chun07attested.pdf>. October 2007, <https://www.read.seas.harvard.edu/~kohler/
class/08w-dsi/chun07attested.pdf>.
[in-toto] "in-toto", n.d., <https://in-toto.io/>. [in-toto] "in-toto", <https://in-toto.io/>.
[NIST.SP.1800-19] [NIST.SP.1800-19]
Bartock, M., Dodson, D., Souppaya, M., Carroll, D., Bartock, M., Dodson, D., Souppaya, M., Carroll, D.,
Masten, R., Scinta, G., Massis, P., Prafullchandra, H., Masten, R., Scinta, G., Massis, P., Prafullchandra, H.,
Malnar, J., Singh, H., Ghandi, R., Storey, L. E, Yeluri, Malnar, J., Singh, H., Ghandi, R., Storey, L. E, Yeluri,
R., Shea, T., Dalton, M., Weber, R., Scarfone, K., Dukes, R., Shea, T., Dalton, M., Weber, R., Scarfone, K., Dukes,
A., Haskins, J., Phoenix, C., Swarts, B., and National A., Haskins, J., Phoenix, C., and B. Swarts, "Trusted
Institute of Standards and Technology (U.S.), "Trusted cloud: Security Practice Guide for VMware Hybrid Cloud
cloud :security practice guide for VMware hybrid cloud Infrastructure as a Service (IaaS) Environments",
infrastructure as a service (IaaS) environments", DOI 10.6028/NIST.SP.1800-19, NIST SP 1800-19, 20 April
DOI 10.6028/NIST.SP.1800-19, NIST Special Publications 2022,
(General) 1800-19, 20 April 2022,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.1800-19.pdf>. NIST.SP.1800-19.pdf>.
[NIST.SP.800-204C] [NIST.SP.800-204C]
Chandramouli, R. and National Institute of Standards and Chandramouli, R., "Implementation of DevSecOps for a
Technology (U.S.), "Implementation of DevSecOps for a Microservices-based Application with Service Mesh",
microservices-based application with service mesh",
DOI 10.6028/NIST.SP.800-204C, NIST Special Publications DOI 10.6028/NIST.SP.800-204C, NIST Special Publications
(General) 800-204C, 8 March 2022, (General) 800-204C, NIST SP 800-204C,
DOI 10.6028/NIST.SP.800-204C, March 2022,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-204C.pdf>. NIST.SP.800-204C.pdf>.
[NIST_EO14028] [NIST_EO14028]
"Software Supply Chain Security Guidance Under Executive NIST, "Software Supply Chain Security Guidance Under
Order (EO) 14028 Section 4e", 4 February 2022, Executive Order (EO) 14028 Section 4e", 4 February 2022,
<https://www.nist.gov/system/files/documents/2022/02/04/ <https://www.nist.gov/system/files/documents/2022/02/04/
software-supply-chain-security-guidance-under-EO-14028- software-supply-chain-security-guidance-under-EO-14028-
section-4e.pdf>. section-4e.pdf>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://doi.org/10.17487/RFC4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725, Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020, DOI 10.17487/RFC8725, February 2020,
<https://doi.org/10.17487/RFC8725>. <https://www.rfc-editor.org/info/rfc8725>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://doi.org/10.17487/RFC9162>. December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[SLSA] "SLSA", n.d., <https://slsa.dev/>. [SLSA] "SLSA", <https://slsa.dev/>.
[SPDX-CBOR] [SPDX-CBOR]
"SPDX Specification", n.d., "SPDX Specification",
<https://spdx.dev/use/specifications/>. <https://spdx.dev/use/specifications/>.
[SPDX-JSON] [SPDX-JSON]
"SPDX Specification", n.d., "SPDX Specification",
<https://spdx.dev/use/specifications/>. <https://spdx.dev/use/specifications/>.
[SWID] "SWID Specification", n.d., [SWID] NIST, "SWID Specification",
<https://csrc.nist.gov/Projects/Software-Identification- <https://csrc.nist.gov/Projects/Software-Identification-
SWID/guidelines>. SWID/guidelines>.
Contributors Contributors
Orie Steele Orie Steele
Tradeverifyd Tradeverifyd
United States United States of America
Email: orie@or13.io Email: orie@or13.io
Orie contributed to improving the generalization of COSE building Orie contributed to improving the generalization of COSE building
blocks and document consistency. blocks and document consistency.
Amaury Chamayou Amaury Chamayou
Microsoft Microsoft
United Kingdom United Kingdom
Email: amaury.chamayou@microsoft.com Email: amaury.chamayou@microsoft.com
Amaury contributed elemental parts to finalize normative language on Amaury contributed elemental parts to finalize normative language on
registration behavior and the single-issuer design, as well as registration behavior and the single-issuer design, as well as
overall document consistency overall document consistency
Dick Brooks Dick Brooks
Business Cyber Guardian (TM) Business Cyber Guardian
United States United States of America
Email: dick@businesscyberguardian.com Email: dick@businesscyberguardian.com
Dick contributed to the software supply chain use cases. Dick contributed to the software supply chain use cases.
Brian Knight Brian Knight
Microsoft Microsoft
United States United States of America
Email: brianknight@microsoft.com Email: brianknight@microsoft.com
Brian contributed to the software supply chain use cases. Brian contributed to the software supply chain use cases.
Robert Martin Robert Martin
MITRE Corporation MITRE Corporation
United States United States of America
Email: ramartin@mitre.org Email: ramartin@mitre.org
Robert contributed to the software supply chain use cases. Robert contributed to the software supply chain use cases.
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
64295 Darmstadt 64295 Darmstadt
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@ietf.contact
Antoine Delignat-Lavaud Antoine Delignat-Lavaud
Microsoft Research Microsoft Research
21 Station Road 21 Station Road
Cambridge Cambridge
CB1 2FB CB1 2FB
United Kingdom United Kingdom
Email: antdl@microsoft.com Email: antdl@microsoft.com
Cedric Fournet Cedric Fournet
 End of changes. 198 change blocks. 
456 lines changed or deleted 471 lines changed or added

This html diff was produced by rfcdiff 1.48.