rfc9943v1.txt   rfc9943.txt 
Internet Engineering Task Force (IETF) H. Birkholz Internet Engineering Task Force (IETF) H. Birkholz
Request for Comments: 9943 Fraunhofer SIT Request for Comments: 9943 Fraunhofer SIT
Category: Standards Track A. Delignat-Lavaud Category: Standards Track A. Delignat-Lavaud
ISSN: 2070-1721 C. Fournet ISSN: 2070-1721 C. Fournet
Microsoft Research Microsoft
Y. Deshpande Y. Deshpande
ARM ARM
S. Lasker S. Lasker
March 2026 April 2026
An Architecture for Trustworthy and Transparent Digital Supply Chains An Architecture for Trustworthy and Transparent Digital Supply Chains
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 (VDSs) have addressed specific issues,
equivocation over digital certificates, they lack a universal such as 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 and interoperability between different ensures extensibility and interoperability between different
transparency services as well as compliance with various auditing transparency services as well as compliance with various auditing
procedures and regulatory requirements. procedures and regulatory requirements.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
skipping to change at line 106 skipping to change at line 106
11. References 11. References
11.1. Normative References 11.1. Normative References
11.2. Informative References 11.2. Informative References
Contributors Contributors
Authors' Addresses Authors' Addresses
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 VDSs maintained by corresponding transparency
corresponding transparency services. The goal of the transparency services. The goal of the transparency enabled by the Supply Chain
enabled by the Supply Chain Integrity, Transparency, and Trust Integrity, Transparency, and Trust (SCITT) architecture is to enhance
(SCITT) architecture is to enhance auditability and accountability auditability and accountability for single-issuer signed content
for single-issuer signed content (statements) that are about supply (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 (TS) is
a notarization procedure. Transparency Services (TSs) confirm a akin to a notarization procedure. TSs confirm a policy is met before
policy is met before recording the statement on the ledger. The recording the statement on the ledger. The SCITT ledger represents a
SCITT ledger represents a linear and irrevocable history of linear and irrevocable history of statements made. Once the signed
statements made. Once the signed statement is registered, the statement is registered, the TS issues a 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 (CT) [RFC9162]. The artifacts, such as Certificate Transparency (CT) [RFC9162]. The
SCITT approach follows a more generic paradigm than previous SCITT approach follows a more generic paradigm than previous
approaches. This "content-agnostic" approach allows SCITT approaches. This "content-agnostic" approach allows TSs to be either
transparency services to be either integrated in existing solutions integrated in existing solutions or an initial part of new emerging
or an initial part of new emerging systems. Extensibility is a vital systems. Extensibility is a vital feature of the SCITT architecture,
feature of the SCITT architecture, so that requirements from various so that requirements from various applications can be accommodated
applications can be accommodated while always ensuring while always ensuring interoperability with respect to registration
interoperability with respect to registration procedures and procedures and corresponding auditability and accountability. For
corresponding auditability and accountability. For simplicity, the simplicity, the scope of this document is limited to use cases
scope of this document is limited to use cases originating from the originating from the software supply chain domain. However, the
software supply chain domain. However, the specification defined is specification defined is applicable to any other type of supply chain
applicable to any other type of supply chain statements (also statements (also referred to as "value-add graphs"), for example,
referred to as "value-add graphs"), for example, statements about 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 CBOR Object Signing and and transparent statements, which embed CBOR Object Signing and
Encryption (COSE) receipts [RFC9942], i.e., signed verifiable data Encryption (COSE) receipts [RFC9942], i.e., signed Verifiable Data
structure proofs). These message structures are based on the Concise Structure Proofs (VDP). These message structures are based on the
Binary Object Representation (CBOR) Standard [STD94] and Concise Binary Object Representation (CBOR) Standard [STD94] and
corresponding signing is facilitated via the COSE Standard [STD96]. corresponding signing is facilitated via the COSE Standard [STD96].
The message structures are defined using the Concise Data Definition The message structures are defined using the Concise Data Definition
Language (CDDL) [RFC8610]. The signed statements and receipts are, Language (CDDL) [RFC8610]. The signed statements and receipts are,
respectively, based on the COSE_Sign1 specification in Section 4.2 of respectively, based on the COSE_Sign1 specification in Section 4.2 of
RFC 9052 [STD96] and on COSE receipts [RFC9942]. The application- RFC 9052 [STD96] and on COSE receipts [RFC9942]. The application-
domain-agnostic nature of COSE_Sign1 and its extensibility through domain-agnostic nature of COSE_Sign1 and its extensibility through
COSE Header Parameters are prerequisites for implementing the COSE 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 as well as how participating entities discover and managed or stored as well as how participating entities discover and
notify 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
skipping to change at line 383 skipping to change at line 380
* 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. Typically, it involves Software integration is a complex activity. Typically, it involves
getting various software components from multiple suppliers and 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
skipping to change at line 423 skipping to change at line 420
This document has been developed in coordination with the COSE, This document has been developed in coordination with the COSE,
OAUTH, and RATS working groups (WGs) and uses terminology common to OAUTH, and RATS working groups (WGs) and uses terminology common to
these WGs as often as possible. 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 When used in text in the sense defined, the following terms are
readability, only a core set of terms is included in this section. 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 TS. To make the append-only property
Append-only property verifiable and transparent, the Transparency verifiable and transparent, the TS defines how Signed Statements
Service defines how Signed Statements are made available to 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.
Attestation: [NIST.SP.1800-19] defines "attestation" as:
| The process of providing a digital signature for a set of
| measurements securely stored in hardware, and then having the
| requester validate the signature and the set of measurements.
NIST guidance "Software Supply Chain Security Guidance EO 14028"
[NIST_EO14028] uses the definition from [ISO_IEC_17000], which
states that an "attestation" is:
| 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.
Auditor: an entity that checks the correctness and consistency of Auditor: an entity that checks the correctness and consistency of
all Transparent Statements, or the transparent Statement Sequence, all Transparent Statements, or the transparent Statement Sequence,
issued by a Transparency Service. An Auditor is an example of a issued by a TS. An Auditor is an example of a specialized Relying
specialized Relying Party. Party.
Client: an application making protected Transparency Service Client: an application making protected TS resource requests on
resource requests on behalf of the resource owner and with its behalf of the resource owner and with its authorization.
authorization.
Envelope: metadata, created by the Issuer to produce a Signed Envelope: metadata, created by the Issuer to produce a Signed
Statement. The Envelope contains the identity of the Issuer and Statement. The Envelope contains the identity of the Issuer and
information about the Artifact, enabling Transparency Service information about the Artifact, enabling TS Registration Policies
Registration Policies to validate the Signed Statement. A Signed to validate the Signed Statement. A Signed Statement is a COSE
Statement is a COSE Envelope wrapped around a Statement, binding Envelope wrapped around a Statement, binding the metadata in the
the metadata in the Envelope to the Statement. In COSE, an Envelope to the Statement. In COSE, an Envelope consists of a
Envelope consists of a protected header (included in the Issuer's protected header (included in the Issuer's signature) and an
signature) and an unprotected header (not included in the Issuer's unprotected header (not included in the Issuer's signature).
signature).
Equivocation: a state where a Transparency Service provides Equivocation: a state where a TS provides inconsistent proofs to
inconsistent proofs to Relying Parties, containing conflicting Relying Parties, containing conflicting claims about the Signed
claims about the Signed Statement bound at a given position in the Statement bound at a given position in the VDS.
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 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 CBOR Web Token (CWT) Claim Set [RFC8392] within the protected a CBOR Web Token (CWT) Claims Set [RFC8392] within the protected
header of a COSE Envelope. This document uses the terms "Issuer" header of a COSE Envelope. This document uses the terms "Issuer"
and "Subject" as described in [RFC8392]; however, the usage is and "Subject" as described in [RFC8392]; however, the usage is
consistent with the broader interpretation of these terms in both consistent with the broader interpretation of these terms in both
JSON Object Signing and Encryption (JOSE) and COSE, and the JSON Object Signing and Encryption (JOSE) and COSE, and the
guidance in [RFC8725] generally applies the COSE equivalent terms guidance in [RFC8725] generally applies the COSE equivalent terms
with consistent semantics. with consistent semantics.
Non-equivocation: a state where all proofs provided by the Non-equivocation: a state where all proofs provided by the TS to
Transparency Service to Relying Parties are produced from a single Relying Parties are produced from a single VDS describing a unique
Verifiable Data Structure describing a unique sequence of Signed sequence of Signed Statements and are therefore consistent
Statements and are therefore consistent [EQUIVOCATION]. Over [EQUIVOCATION]. Over time, an Issuer may register new Signed
time, an Issuer may register new Signed Statements about an Statements about an Artifact in a TS with new information.
Artifact in a Transparency Service with new information. However, However, the consistency of a collection of Signed Statements
the consistency of a collection of Signed Statements about the 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 COSE Single Signer Data Object as defined in [RFC9942].
in the Verifiable Data Structure. See [RFC9942] for See [RFC9942] for implementations. Receipts are signed proofs of
implementations. Receipts are signed proofs of verifiable data- VDS properties. Receipt Profiles implemented by a TS MUST support
structure properties. Receipt Profiles implemented by a inclusion proofs and MAY support other Proof Types (see Section 3
Transparency Service MUST support inclusion proofs and MAY support of [RFC9942]), such as consistency proofs.
other proof 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 TS,
Transparency Service, applying the Transparency Service's applying the TS's Registration Policy, adding to the VDS, and
Registration Policy, adding to the Verifiable Data Structure, and
producing a Receipt. producing a Receipt.
Registration Policy: the precondition enforced by the Transparency Registration Policy: the precondition enforced by the TS before
Service before registering a Signed Statement, based on registering a Signed Statement, based on information in the non-
information in the non-opaque header and metadata contained in its opaque header and metadata contained in its COSE Envelope.
COSE Envelope.
Relying Party: Relying Parties consume 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 Enveloped COSE Structures; the payload of the COSE
contains the issued Statement. structure contains the issued Statement.
Attestation: [NIST.SP.1800-19] defines "attestation" as:
| The process of providing a digital signature for a set of
| measurements securely stored in hardware, and then having the
| requester validate the signature and the set of measurements.
NIST guidance "Software Supply Chain Security Guidance EO 14028"
uses the definition from [NIST_EO14028], which states that an
"attestation" is:
| The issue of a statement, based on a decision, that fulfillment
| of specified requirements has been demonstrated.
It 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
interpret Statements, they must be tagged with a relevant media interpret Statements, they must be tagged with a relevant media
type (as specified in [RFC6838]). A Statement may represent an type (as specified in [RFC6838]). A Statement may represent an
SBOM that lists the ingredients of a software Artifact, contains SBOM that lists the ingredients of a software Artifact, contains
an endorsement or attestation about an Artifact, indicates the End an endorsement or attestation about an Artifact, indicates the End
of Life (EOL), redirects to a newer version, or contains any of Life (EOL), redirects to a newer version, or contains any
content an Issuer wishes to publish about an Artifact. Additional content an Issuer wishes to publish about an Artifact. Additional
Statements about an Artifact are correlated by the Subject Claim Statements about an Artifact are correlated by the Subject Claim
as defined in the IANA CWT registry [IANA.cwt] and used as a as defined in the "CBOR Web Token (CWT) Claims" registry
protected header parameter as defined in [RFC9597]. The Statement [IANA.cwt] and used as a protected header parameter as defined in
is considered opaque to Transparency Service and MAY be encrypted. [RFC9597]. The Statement is considered opaque to TS 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. VDS. See Verifiable Data Structure.
Subject: an identifier, defined by the Issuer, that 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 VDS
Verifiable Data Structure and endorses its state. The identity of and endorses its state. The identity of a TS is captured by a
a Transparency Service is captured by a public key that must be public key that must be known by Relying Parties in order to
known by Relying Parties in order to validate Receipts. 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 TS. The Receipt is stored
Receipt is stored in the unprotected header of COSE Envelope of in the unprotected header of COSE Envelope of the Signed
the Signed Statement. A Transparent Statement remains a valid Statement. A Transparent Statement remains a valid Signed
Signed Statement and may be registered again in a different Statement and may be registered again in a different TS.
Transparency Service.
Verifiable Data Structure: a data structure that supports one or Verifiable Data Structure: a data structure defined in [RFC9942] in
more proof types, such as "inclusion proofs" or "consistency which Signed Statements can be inserted as they are Registered by
proofs", for Signed Statements as they are Registered to a a TS. SCITT supports multiple VDSs and Receipt formats as defined
Transparency Service. SCITT supports multiple Verifiable Data in [RFC9942], accommodating different TS implementations.
Structures and Receipt formats as defined in [RFC9942],
accommodating different 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 CT [RFC9162] are instances of this transparency systems such as CT [RFC9162] are instances of this
definition. SCITT supports multiple Verifiable Data Structures, as definition. SCITT supports multiple VDSs, as defined in [RFC9942].
defined in [RFC9942].
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 TS in the form of a Receipt. Receipts
Receipt. Receipts demonstrate inclusion of Signed Statements in the demonstrate inclusion of Signed Statements in the VDS of a TS. By
Verifiable Data Structure of a Transparency Service. By extension, extension, the Signed Statement may say an Artifact (for example, a
the Signed Statement may say an Artifact (for example, a firmware firmware binary) is transparent if it comes with one or more
binary) is transparent if it comes with one or more Transparent Transparent Statements from its author or owner, though the context
Statements from its author or owner, though the context should make should make it clear what type of Signed Statement is expected for a
it clear what type of Signed Statement is expected for a given 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 TS provides a
Service provides a history of Statements, which may be made by history of Statements, which may be made by multiple Issuers,
multiple Issuers, enabling Relying Parties to make informed 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 TSs may protect their registered sequence of
sequence of Signed Statements and Verifiable Data Structure using a Signed Statements and VDS using a combination of trusted hardware,
combination of trusted hardware, consensus protocols, and consensus protocols, and cryptographic evidence. A Receipt is a
cryptographic evidence. A Receipt is a signature over one or more signature over one or more VDP that a Signed Statement is registered
Verifiable Data Structure Proofs that a Signed Statement is in the VDS. It is universally verifiable without online access to
registered in the Verifiable Data Structure. It is universally the TS. Requesting a Receipt can result in the production of a new
verifiable without online access to the TS. Requesting a Receipt can Receipt for the same Signed Statement. A Receipt's verification key,
result in the production of a new Receipt for the same Signed signing algorithm, validity period, header parameters or other claims
Statement. A Receipt's verification key, signing algorithm, validity MAY change each time a Receipt is produced.
period, header parameters or other claims MAY change each time a
Receipt is produced.
Anyone with access to the Transparency Service can independently Anyone with access to the TS can independently verify its consistency
verify its consistency and review the complete list of Transparent and review the complete list of Transparent Statements registered by
Statements registered by each Issuer. each Issuer.
Thus, reputable Issuers are 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 TSs are incentivized to secure their VDS, as any
their Verifiable Data Structure, as any inconsistency can easily be inconsistency can easily be pinpointed by any Auditor with read
pinpointed by any Auditor with read access to the Transparency access to the TS.
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 CT [RFC9162], which can be interpreted SCITT is a generalization of CT [RFC9162], which can be interpreted
as a transparency architecture for the supply chain of X.509 as a transparency architecture for the supply chain of X.509
certificates. Considering CT in terms of SCITT: certificates. Considering CT in terms of SCITT:
* Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER-encoded * Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER-encoded
tbsCertificate structure to produce an X.509 certificate (Signed tbsCertificate structure to produce an X.509 certificate (Signed
Statements) Statements)
* CAs submit the certificates to one or more CT logs (Transparency * CAs submit the certificates to one or more CT logs (TSs)
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 VDS can be checked by Auditors
5. Architecture Overview 5. Architecture Overview
The SCITT architecture enables Transparency Services in a given The SCITT architecture enables TSs in a given application domain to
application domain to implement a collective baseline by providing a implement a collective baseline by providing a set of common formats
set of common formats and protocols for issuing and registering and protocols for issuing and registering Signed Statements and
Signed Statements and auditing Transparent Statements. auditing Transparent Statements.
In order to accommodate as many Transparency Service implementations In order to accommodate as many TS implementations as possible, this
as possible, this document only specifies the format of Signed document only specifies the format of Signed Statements (which must
Statements (which must be used by all Issuers) and a very thin be used by all Issuers) and a very thin wrapper format for Receipts,
wrapper format for Receipts, which specifies the Transparency Service which specifies the TS identity and the agility parameters for the
identity and the agility parameters for the Signed Inclusion Proofs. signed proofs. The remaining details of the Receipt's contents are
The remaining details of the Receipt's contents are specified in specified in [RFC9942].
[RFC9942].
Figure 2 illustrates the roles and processes that comprise a Figure 2 illustrates the roles and processes that comprise a TS
Transparency Service independent of any one use case: 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 * TSs that evaluate Signed Statements against Registration Policies
Registration Policies producing Receipts upon successful producing Receipts upon successful Registration. The returned
Registration. The returned Receipt may be combined with the Receipt may be combined with the Signed Statement to create a
Signed Statement to create a Transparent Statement. 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 TS's VDS (e.g., auditing).
Verifiable Data Structure (e.g., auditing).
In addition, Figure 2 illustrates multiple Transparency Services and In addition, Figure 2 illustrates multiple TSs and multiple Receipts
multiple Receipts as a single Signed Statement MAY be registered with as a single Signed Statement MAY be registered with one or more TS.
one or more Transparency Service. Each Transparency Service produces Each TS produces a Receipt, which may be aggregated in a single
a Receipt, which may be aggregated in a single Transparent Statement, Transparent Statement, demonstrating the Signed Statement was
demonstrating the Signed Statement was registered by multiple registered by multiple TSs.
Transparency Services.
The arrows indicate the flow of information. The arrows indicate the flow of information.
.----------. +--------------+ .----------. +--------------+
| Artifact | | Issuer | | Artifact | | Issuer |
'----+-----' +-+----------+-+ '----+-----' +-+----------+-+
v v v v v v
.----+----. .-----+----. .+---------. .----+----. .-----+----. .+---------.
| Statement | / sign / / verify / | Statement | / sign / / verify /
'----+----' '-----+----+ '-------+--+ '----+----' '-----+----+ '-------+--+
skipping to change at line 731 skipping to change at line 709
v v v v v v v v
.--------+---------. .--+--------------+--. .------+----------. .--------+---------. .--+--------------+--. .------+----------.
/ Collect Receipts / / Verify Transparent / / Replay Log / / Collect Receipts / / Verify Transparent / / Replay Log /
'--+---------------+ / Statement / '-+---------------+ '--+---------------+ / Statement / '-+---------------+
| Relying Party | '----+---------------+ | Relying Party | | Relying Party | '----+---------------+ | Relying Party |
+---------------+ | Relying Party | +---------------+ +---------------+ | Relying Party | +---------------+
+---------------+ +---------------+
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 TS, Signed
Transparency Service, Signed Statements, Registration, and 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 [RFC9942]. TSs MUST produce COSE Receipts [RFC9942].
Typically, a Transparency Service has a single Issuer identity that Typically, a TS has a single Issuer identity that is present in the
is present in the iss Claim of Receipts for that service. 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 subdomain, 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 VDS. To enable auditability, TSs MUST
auditability, Transparency Services MUST maintain Registration maintain Registration Policies. The presence of an explicit
Policies. The presence of an explicit transparent registration transparent registration policy, even if it allows all authenticated
policy, even if it allows all authenticated submissions, facilitates submissions, facilitates service audit, and enables potential future
service audit, and enables potential future changes to that policy. 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 TS.
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 TS MUST syntactically check the Issuer of the
the Issuer of the Signed Statement by cryptographically verifying the Signed Statement by cryptographically verifying the COSE signature
COSE signature according to [STD96]. The Issuer identity MUST be according to [STD96]. The Issuer identity MUST be bound to the
bound to the Signed Statement by including an identifier in the Signed Statement by including an identifier in the protected header.
protected header. If the protected header includes multiple If the protected header includes multiple identifiers, all those that
identifiers, all those that are registered by the Transparency are registered by the TS MUST be checked.
Service MUST be checked.
Transparency Services MUST maintain a list of trust anchors (see TSs MUST maintain a list of trust anchors (see definition of trust
definition of trust anchor in [RFC4949]) in order to check the anchor in [RFC4949]) in order to check the signatures of Signed
signatures of Signed Statements either separately or inside Statements either separately or inside Registration Policies. TSs
Registration Policies. Transparency Services MUST authenticate MUST authenticate Signed Statements as part of a Registration Policy.
Signed Statements as part of a Registration Policy. For instance, a For instance, a trust anchor could be an X.509 root certificate
trust anchor could be an X.509 root certificate (directly or its (directly or its thumbprint), a pointer to an OpenID Connect identity
thumbprint), a pointer to an OpenID Connect identity provider, or any provider, or any other trust anchor that can be referenced in a COSE
other trust anchor that can be referenced in a COSE header parameter. header parameter.
When using X.509 Signed Statements, the Transparency Service MUST When using X.509 Signed Statements, the TS MUST build and validate a
build and validate a complete certification path from an Issuer's complete certification path from an Issuer's certificate to one of
certificate to one of the root certificates currently registered as a the root certificates currently registered as a trust anchor by the
trust anchor by the Transparency Service. The protected header of TS. The protected header of the COSE_Sign1 Envelope MUST include
the COSE_Sign1 Envelope MUST include either the Issuer's certificate either the Issuer's certificate as x5t or the chain including the
as x5t or the chain including the Issuer's certificate as x5chain, as Issuer's certificate as x5chain, as defined in [RFC9360]. If x5t is
defined in [RFC9360]. If x5t is included in the protected header, an included in the protected header, an x5chain with a leaf certificate
x5chain with a leaf certificate corresponding to the x5t value MAY be corresponding to the x5t value MAY be included in the unprotected
included in the unprotected header. header.
Registration Policies and trust anchors MUST be made Transparent and Registration Policies and trust anchors MUST be made Transparent and
available to all Relying Parties of the Transparency Service by available to all Relying Parties of the TS by Registering them as
Registering them as Signed Statements on the Verifiable Data Signed Statements on the VDS.
Structure.
The Transparency Service MUST apply the Registration Policy that was The TS MUST apply the Registration Policy that was most recently
most recently committed to the Verifiable Data Structure at the time committed to the VDS at the time of Registration.
of Registration.
5.1.1.2. Auditability of Registration 5.1.1.2. Auditability of Registration
The operator of a Transparency Service MAY update the Registration The operator of a TS MAY update the Registration Policy or the trust
Policy or the trust anchors of a Transparency Service at any time. anchors of a TS at any time.
Transparency Services MUST ensure that for any Signed Statement they TSs MUST ensure that for any Signed Statement they register, enough
register, enough information is made available to Auditors to information is made available to Auditors to reproduce the
reproduce the Registration checks that were defined by the Registration checks that were defined by the Registration Policies at
Registration Policies at the time of Registration. At a minimum, the time of Registration. At a minimum, this consists of the Signed
this consists of the Signed Statements themselves, any additional Statements themselves, any additional collateral data required to
collateral data required to perform their authentication, and the perform their authentication, and the applicable Registration Policy
applicable Registration Policy at the time of Registration. 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, TSs
Transparency Services MUST support at least one of the three MUST support at least one of the three following bootstrapping
following bootstrapping mechanisms: mechanisms:
* Preconfigured 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; or 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 VDS (see
Verifiable Data Structure (see [RFC9942]) used by the Transparency [RFC9942]) used by the TS implementation. This VDS MUST support the
Service implementation. This verifiable data structure MUST support 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 VDS to be applicable to
be applicable to SCITT, ensuring that the Statement Sequence SCITT, ensuring that the Statement Sequence cannot be modified,
cannot be modified, deleted, or reordered. 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 TS and committed to the VDS.
committed to the Verifiable Data Structure. Everyone with access Everyone with access to its content sees the same ordered
to its content sees the same ordered collection of Signed collection of Signed Statements and can check that it is
Statements and can check that it is consistent with any Receipts consistent with any Receipts they have verified.
they have verified.
Replayability: the Verifiable Data Structure includes sufficient Replayability: the VDS includes sufficient information to enable
information to enable authorized actors with access to its content authorized actors with access to its content to check that each
to check that each data structure representing each Signed data structure representing each Signed Statement has been
Statement has been correctly registered. correctly registered.
In addition to Receipts, some verifiable data structures might In addition to Receipts, some VDSs might support additional Proof
support additional proof types, such as proofs of consistency or Types, such as proofs of consistency or proofs of non-inclusion.
proofs of non-inclusion.
Specific verifiable data structures, such those describes in Specific VDSs, such those describes in [RFC9162] and [RFC9942], and
[RFC9162] and [RFC9942], and the review of their security the review of their security requirements for SCITT are out of scope
requirements for SCITT are out of scope for this document. for this document.
5.1.4. Adjacent Services 5.1.4. Adjacent Services
Transparency Services can be deployed alongside other database or TSs can be deployed alongside other database or object storage
object storage technologies. For example, a Transparency Service technologies. For example, a TS that supports a software package
that supports a software package management system, might be management system, might be referenced from the APIs exposed for
referenced from the APIs exposed for package management. It can also package management. It can also provide the ability to request a
provide the ability to request a fresh Receipt for a given software fresh Receipt for a given software package or a list of Signed
package or a list of Signed Statements associated with that package. 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 an SBOM, 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 * Concise Software Identification Tags format [CoSWID]
* [CycloneDX] Bill of Materials format * Bill of Materials format [CycloneDX]
* [in-toto] Supply chain description metadata * Supply chain description metadata [in-toto]
* [SPDX-CBOR] Software component description format * Software component description format [SPDX-CBOR]
* [SPDX-JSON] Software component description format * Software component description format [SPDX-CBOR]
* [SLSA] Supply-chain Levels for Software Artifacts * Supply-chain Levels for Software Artifacts [SLSA]
* [SWID] Software Identification Tag format * Software Identification Tag format [SWID]
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 in Section 3.) 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
protected header from [STD96]) for different Artifacts or sign all protected header from [STD96]) for different Artifacts or sign all
skipping to change at line 926 skipping to change at line 896
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, an 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, the iss Claim
string that meets URI requirements defined in [RFC8392]. The iss value MUST be a string that meets URI requirements defined in
value's length MUST be between 1 and 8192 characters in length. [RFC8392]. The iss Claim 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].
skipping to change at line 959 skipping to change at line 930
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.
Signed_Statement = #6.18(COSE_Sign1) Signed_Statement = /6.18(COSE_Sign1)
Receipt = #6.18(COSE_Sign1) Receipt = /6.18(COSE_Sign1)
COSE_Sign1 = [ COSE_Sign1 = [
protected : bstr .cbor Protected_Header, protected : bstr .cbor Protected_Header,
unprotected : Unprotected_Header, unprotected : Unprotected_Header,
payload : bstr / nil, payload : bstr / nil,
signature : bstr signature : bstr
] ]
Protected_Header = { Protected_Header = {
&(CWT_Claims: 15) => CWT_Claims &(CWT_Claims: 15) => CWT_Claims
skipping to change at line 1033 skipping to change at line 1004
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
Statement 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 TS. In these cases, a Statement can be made over the hash
made over the hash of a payload rather than the full payload bytes. of a payload rather than the full payload bytes.
.----+-----. .----+-----.
| Artifact | | Artifact |
'+-+-------' '+-+-------'
| | | |
.-' v .-' v
| .--+-------. | .--+-------.
| | Hash +-+ | | Hash +-+
| '----------' | /\ | '----------' | /\
'-. | / \ .----------. '-. | / \ .----------.
skipping to change at line 1081 skipping to change at line 1052
.-+-----------. .------+------+--. .-+-----------. .------+------+--.
/ / / \ / / / \
/ Sign +<------+ To Be Signed Bytes | / Sign +<------+ To Be Signed Bytes |
/ / \ / / / \ /
'-----+-------' '----------------' '-----+-------' '----------------'
v v
.----+-------. .----+-------.
| COSE_Sign1 | | COSE_Sign1 |
'------------' '------------'
Figure 6: Workflow for Signing Large or Sensitive Statements
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 TS performs the following steps:
following steps:
1. Client Authentication 1. Client Authentication
A Client authenticates with the Transparency Service before A Client authenticates with the TS before registering Signed
registering Signed Statements on behalf of one or more Issuers. Statements on behalf of one or more Issuers. Authentication and
Authentication and authorization are implementation specific and authorization are implementation specific and out of scope of the
out of scope of the SCITT architecture. SCITT architecture.
2. TS Signed Statement Verification and Validation 2. TS Signed Statement Verification and Validation
The Transparency Service MUST perform signature verification per The TS MUST perform signature verification per Section 4.4 of RFC
Section 4.4 of RFC 9052 [STD96] and MUST verify the signature of 9052 [STD96] and MUST verify the signature of the Signed
the Signed Statement with the signature algorithm and Statement with the signature algorithm and verification key of
verification key of the Issuer per [RFC9360]. The Transparency the Issuer per [RFC9360]. The TS MUST also check that the Signed
Service MUST also check that the Signed Statement includes the Statement includes the required protected headers. The TS MAY
required protected headers. The Transparency Service MAY
validate the Signed Statement payload in order to enforce domain- validate the Signed Statement payload in order to enforce domain-
specific registration policies that apply to specific content specific registration policies that apply to specific content
types. types.
3. Apply Registration Policy 3. Apply Registration Policy
The Transparency Service MUST check the attributes required by a The TS MUST check the attributes required by a Registration
Registration Policy are present in the protected headers. Custom Policy are present in the protected headers. Custom Signed
Signed Statements are evaluated given the current Transparency Statements are evaluated given the current TS state and the
Service state and the entire Envelope and may use information entire Envelope and may use information contained in the
contained in the attributes of named policies. attributes of named policies.
4. Register the Signed Statement 4. Register the Signed Statement
5. Return the Receipt 5. Return the Receipt
This MAY be asynchronous from Registration. The Transparency This MAY be asynchronous from Registration. The TS MUST be able
Service MUST be able to provide a Receipt for all registered to provide a Receipt for all registered Signed Statements.
Signed Statements. Details about generating Receipts are Details about generating Receipts are described in Section 7.
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 VDS.
A Transparency Service MUST ensure that a Signed Statement is A TS MUST ensure that a Signed Statement is registered before
registered before releasing its Receipt. releasing its Receipt.
A Transparency Service MAY accept a Signed Statement with content in A TS MAY accept a Signed Statement with content in its unprotected
its unprotected header and MAY use values from that unprotected header and MAY use values from that unprotected header during
header during verification and registration policy evaluation. 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 TSs, producing multiple independent Receipts. The multiple Receipts
multiple Receipts may be attached to the unprotected header of the may be attached to the unprotected header of the Signed Statement
Signed Statement creating a Transparent 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 TS a Receipt becomes
Receipt becomes available. When a Receipt is included in a Signed available. When a Receipt is included in a Signed Statement, a
Statement, a Transparent Statement is produced. Transparent Statement is produced.
Receipts are based on Signed Inclusion Proofs as described in COSE Receipts are based on signed proofs as described in COSE Receipts
Receipts [RFC9942], which also provides the COSE header parameter [RFC9942], which also provides the COSE header parameter semantics
semantics for label 394. for label 394.
The Registration time is recorded as the timestamp when the The Registration time is recorded as the timestamp when the TS added
Transparency Service added the Signed Statement to its Verifiable the Signed Statement to its VDS.
Data Structure.
Figure 6 illustrates a normative CDDL definition of Transparent Figure 7 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 RFC 9052 [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 7: CDDL Definition for a Transparent Statement
Figure 7 illustrates a Transparent Statement with a detached payload Figure 8 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 Receipt). one or more Receipts (each entry encoded as a .cbor-encoded Receipt).
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 8: CBOR-Extended Diagnostic Notation Example of a
Transparent Statement Transparent Statement
Figure 8 illustrates one of the decoded Receipts from Figure 7. The Figure 9 illustrates one of the decoded Receipts from Figure 8. The
Receipt contains inclusion proofs for verifiable data structures. Receipt contains inclusion proofs for VDSs. The unprotected header
The unprotected header contains verifiable data structure proofs. contains VDP. See the protected header for details regarding the
See the protected header for details regarding the specific specific VDS used. Per the "COSE Verifiable Data Structure
verifiable data structure used. Per the COSE Verifiable Data Algorithms" registry documented in [RFC9942], the COSE Key Type
Structure Algorithms Registry documented in [RFC9942], the COSE key RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and
type RFC9162_SHA256 is value 1. Labels identify inclusion proofs consistency proofs (-2).
(-1) and 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 9: CBOR-Extended Diagnostic Notation Example of a Receipt
Figure 9 illustrates the decoded protected header of the Transparent Figure 10 illustrates the decoded protected header of the Transparent
Statement in Figure 7. The verifiable data structure (-111) uses 1 Statement in Figure 8. The VDS (-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 10: 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 11 illustrates the decoded inclusion proof from Figure 9.
This inclusion proof indicates that the size of the Verifiable Data This inclusion proof indicates that the size of the VDS was 8 at the
Structure was 8 at the time the Receipt was issued. The structure of time the Receipt was issued. The structure of this inclusion proof
this inclusion proof is specific to the verifiable data structure is specific to the VDS used by 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 11: 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 RFC 9052 [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 that rely on verifiable data structures they do Statement or Receipts that rely on VDSs 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.
In addition, Relying Parties MAY apply arbitrary validation policies In addition, Relying Parties MAY apply arbitrary validation policies
after the Transparent Statement has been verified and validated. after the Transparent Statement has been verified and validated.
Such policies may use as input all information in the Envelope, the Such policies may use as input all information in the Envelope, the
Receipt, and the Statement payload, as well as any local state. Receipt, and the Statement payload, as well as any local state.
8. Privacy Considerations 8. Privacy Considerations
Interactions with Transparency Services are expected to use Interactions with TSs are expected to use appropriately strong
appropriately strong encryption and authorization technologies. encryption and authorization technologies.
The Transparency Service is trusted with the confidentiality of the The TS is trusted with the confidentiality of the Signed Statements
Signed Statements presented for Registration. Issuers and Clients presented for Registration. Issuers and Clients are responsible for
are responsible for verifying that the Transparency Service's privacy verifying that the TS's privacy and security posture is suitable for
and security posture is suitable for the contents of the Signed the contents of the Signed Statements they submit prior to
Statements they submit prior to Registration. Issuers must carefully Registration. Issuers must carefully review the inclusion of
review the inclusion of private, confidential, or Personally private, confidential, or Personally Identifiable Information (PII)
Identifiable Information (PII) in their Statements against the in their Statements against the TS'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 TS and related Adjacent Services.
Adjacent Services.
Transparency Services can leverage Verifiable Data Structures that TSs can leverage VDSs that only retain cryptographic metadata (e.g.,
only retain cryptographic metadata (e.g., a hash) rather than the a hash) rather than the complete Signed Statement as part of an in-
complete Signed Statement as part of an in-depth defensive approach depth defensive approach to maintaining confidentiality. By
to maintaining confidentiality. By analyzing the relationship analyzing the relationship between data stored in the TS and data
between data stored in the Transparency Service and data stored in stored in Adjacent Services, it is possible to perform metadata
Adjacent Services, it is possible to perform metadata analysis, which analysis, which could reveal the order in which artifacts were built,
could reveal the order in which artifacts were built, signed, and signed, and uploaded.
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. TS.
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 VDS. The third guarantee is achieved by
guarantee is achieved by the combination of both of these steps. 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 TS, Relying Parties can
Relying Parties can use the history of registered Signed Statements use the history of registered Signed Statements to decide which
to decide which Issuers they choose to trust. This decision process Issuers they choose to trust. This decision process is out of scope
is out of scope of this document. of this document.
9.1. Ordering of Signed Statements 9.1. Ordering of Signed Statements
Statements are signed prior to submitting to a SCITT Transparency Statements are signed prior to submitting to a SCITT Transparency
service. Unless advertised in the Transparency Service Registration service. Unless advertised in the TS Registration Policy, the
Policy, the Relying Party cannot assume that the ordering of Signed Relying Party cannot assume that the ordering of Signed Statements in
Statements in the Verifiable Data Structure matches the ordering of the VDS matches the ordering of their issuance.
their issuance.
9.2. Accuracy of Statements 9.2. Accuracy of Statements
Issuers can make false Statements either intentionally or Issuers can make false Statements either intentionally or
unintentionally; registering a Statement only proves it was produced unintentionally; registering a Statement only proves it was produced
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 TS or
Service or selectively submit some but not all the Statements they selectively submit some but not all the Statements they issue. It is
issue. It is important for Relying Parties not to accept Signed important for Relying Parties not to accept Signed Statements for
Statements for which they cannot discover Receipts issued by a which they cannot discover Receipts issued by a TS they trust.
Transparency Service they trust.
9.4. Key Management 9.4. Key Management
Issuers and Transparency Services MUST: Issuers and TSs 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 VDSs are out of scope for
are out of scope for this document. See [RFC9942] for the generic this document. See [RFC9942] for the generic security considerations
security considerations that apply to Verifiable Data Structure and that apply to VDSs 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 TSs to clearly communicate when keys
communicate when keys are compromised so that Signed Statements can are compromised so that Signed Statements can be rejected by TSs or
be rejected by Transparency Services or Receipts can be ignored by Receipts can be ignored by Relying Parties. TSs whose receipt
Relying Parties. Transparency Services whose receipt signing keys signing keys have been compromised can roll back their Statement
have been compromised can roll back their Statement Sequence to a Sequence to a point before compromise, establish new credentials, and
point before compromise, establish new credentials, and use the new use the new credentials to issue fresh Receipts going forward.
credentials to issue fresh Receipts going forward. Issuers are Issuers are encouraged to follow existing best practices if their
encouraged to follow existing best practices if their credentials are credentials are compromised. Revocation strategies for compromised
compromised. Revocation strategies for compromised keys are out of keys are out of scope for this 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; therefore, they are additional implementation-specific knowledge; therefore, they are
preferable. Mechanisms that rely on preconfigured 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 policy deployments in which the ability to patch a potentially faulty 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,
Transparency Services, and Auditors) are either corrupt or TSs, and Auditors) are either corrupt or compromised.
compromised.
SCITT primarily supports checking of Signed Statement authenticity, SCITT primarily supports checking of Signed Statement authenticity,
both from the Issuer (authentication) and from the Transparency both from the Issuer (authentication) and from the TS (transparency).
Service (transparency). Issuers and Transparency Services can both Issuers and TSs can both be compromised.
be compromised.
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 TS. Different actors may rely on different TSs, each registering a
Transparency Services, each registering a subset of Signed Statements subset of Signed Statements subject to their own policy. Running
subject to their own policy. Running multiple, independent multiple, independent TSs provides different organizations to
Transparency Services provides different organizations to represent represent consistent or divergent opinions. It is the role of the
consistent or divergent opinions. It is the role of the relying relying party to decide which TSs and Issuers they choose to trust
party to decide which Transparency Services and Issuers they choose 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 TSs accountable.
Services accountable. On one hand, this enables valid actors to On one hand, this enables valid actors to detect and disambiguate
detect and disambiguate malicious actors who employ Equivocation with malicious actors who employ Equivocation with Signed Statements to
Signed Statements to different entities. On the other hand, their different entities. On the other hand, their liability and the
liability and the resulting damage to their reputation are resulting damage to their reputation are application specific and out
application specific and out of scope of the SCITT architecture. 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 TS for
Transparency Service for Signed Statements they did not issue or Signed Statements they did not issue or register.
register.
10. IANA Considerations 10. IANA Considerations
IANA has registered the following media types in the "application" IANA has registered the following media types in the "application"
subregistry of the "Media Types" registry group [IANA.media-types]: subregistry of the "Media Types" registry group [IANA.media-types]:
* application/scitt-statement+cose (see Section 10.1) * application/scitt-statement+cose (see Section 10.1)
* application/scitt-receipt+cose (see Section 10.2) * application/scitt-receipt+cose (see Section 10.2)
skipping to change at line 1546 skipping to change at line 1500
Encoding considerations: binary (CBOR data item) Encoding considerations: binary (CBOR data item)
Security considerations: Section 9.5 of RFC 9943 Security considerations: Section 9.5 of RFC 9943
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC 9943 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 TS for the
Service for the benefit of Relying Parties wanting to ensure Non- benefit of Relying Parties wanting to ensure Non-equivocation over
equivocation over all or part of a Statement Sequence. all or part of a Statement Sequence.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): .receipt File extension(s): .receipt
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
skipping to change at line 1638 skipping to change at line 1592
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://www.rfc-editor.org/info/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://www.rfc-editor.org/info/rfc9597>. <https://www.rfc-editor.org/info/rfc9597>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE) Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, March 2026, Receipts", RFC 9942, DOI 10.17487/RFC9942, April 2026,
<https://www.rfc-editor.org/info/rfc9942>. <https://www.rfc-editor.org/info/rfc9942>.
[STD94] Internet Standard 94, [STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>. <https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following: At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object 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://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
skipping to change at line 1685 skipping to change at line 1639
[EQUIVOCATION] [EQUIVOCATION]
Chun, B., Maniatis, P., Shenker, S., and J. Kubiatowicz, 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", ACM SIGOPS Operating Systems Review, vol. 41, their Word", ACM SIGOPS Operating Systems Review, vol. 41,
no. 6, pp. 189-204, DOI 10.1145/1323293.1294280, 14 no. 6, pp. 189-204, DOI 10.1145/1323293.1294280, 14
October 2007, <https://www.read.seas.harvard.edu/~kohler/ October 2007, <https://www.read.seas.harvard.edu/~kohler/
class/08w-dsi/chun07attested.pdf>. class/08w-dsi/chun07attested.pdf>.
[in-toto] "in-toto", <https://in-toto.io/>. [in-toto] "in-toto", <https://in-toto.io/>.
[ISO_IEC_17000]
ISO/IEC, "Conformity assessment — Vocabulary and general
principles", ISO/IEC 17000:2020, December 2020,
<https://www.iso.org/standard/73029.html>.
[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., and B. Swarts, "Trusted A., Haskins, J., Phoenix, C., and B. Swarts, "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 SP 1800-19, 20 April
2022, 2022,
skipping to change at line 1733 skipping to change at line 1692
[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://www.rfc-editor.org/info/rfc9162>. December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[SLSA] "SLSA", <https://slsa.dev/>. [SLSA] "SLSA", <https://slsa.dev/>.
[SPDX-CBOR] [SPDX-CBOR]
"SPDX Specification", "SPDX Specification",
<https://spdx.dev/use/specifications/>. <https://spdx.dev/use/specifications/>.
[SPDX-JSON]
"SPDX Specification",
<https://spdx.dev/use/specifications/>.
[SWID] NIST, "SWID Specification", [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 of America United States of America
Email: orie@or13.io Email: orie@or13.io
skipping to change at line 1791 skipping to change at line 1746
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@ietf.contact Email: henk.birkholz@ietf.contact
Antoine Delignat-Lavaud Antoine Delignat-Lavaud
Microsoft Research Microsoft
21 Station Road
Cambridge
CB1 2FB
United Kingdom United Kingdom
Email: antdl@microsoft.com Email: antdl@microsoft.com
Cedric Fournet Cédric Fournet
Microsoft Research Microsoft
21 Station Road
Cambridge
CB1 2FB
United Kingdom United Kingdom
Email: fournet@microsoft.com Email: fournet@microsoft.com
Yogesh Deshpande Yogesh Deshpande
ARM ARM
110 Fulbourn Road 110 Fulbourn Road
Cambridge Cambridge
CB1 9NJ CB1 9NJ
United Kingdom United Kingdom
Email: yogesh.deshpande@arm.com Email: yogesh.deshpande@arm.com
 End of changes. 124 change blocks. 
435 lines changed or deleted 384 lines changed or added

This html diff was produced by rfcdiff 1.48.