]> Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Microsoft Research

21 Station Road Cambridge CB1 2FB UK antdl@microsoft.com

Microsoft Research

21 Station Road Cambridge CB1 2FB UK fournet@microsoft.com

ARM

110 Fulbourn Road Cambridge CB1 9NJ UK yogesh.deshpande@arm.com

DataTrails

Seattle WA 98199 United States steve.lasker@datatrails.ai

Security SCITT Internet-Draft Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates) but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on one or more Transparency Services, with the guarantee that any Relying Parties will be able to verify them. About This Document Status information for this document may be found at . Discussion of this document takes place on the SCITT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document describes the generic, interoperable, and scalable SCITT architecture. Its goal is to enhance auditability and accountability across supply chains. In supply chains, downstream Artifacts are built upon upstream Artifacts. The complexity of traceability and quality control for these supply chains increases with the number of Artifacts and parties contributing to them. There are many parties who publish information about Artifacts: For example, the original manufacturer may provide information about the state of the Artifact when it left the factory. The shipping company may add information about the transport environment of the Artifact. Compliance Auditors may provide information about their compliance assessment of the Artifact. Security companies may publish vulnerability information about an Artifact. The original manufacturer may subsequently provide additional information about the manufacturing process they discovered after the Artifact left the factory. Some of these parties may publish information about their analysis or use of an Artifact. SCITT provides a way for Relying Parties to obtain this information in a way that is "transparent", that is, parties cannot lie about the information that they publish without it being detected. SCITT achieves this by having producers publish information in a Transparency Service, where Relying Parties can check the information.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Exemplary Software Supply Chain (SSC) Use Cases To illustrate the applicability of the SCITT architecture and its messages this section details the exemplary context of software supply chain (SSC) use cases. The building blocks provided by the SCITT architecture and related documents (e.g., ) are not restricted to software supply chain use cases. Software supply chains serve as a useful application guidance and first usage scenario.

Generic SSC Problem Statement Supply chain security is a prerequisite to protecting consumers and minimizing economic, public health, and safety threats. Supply chain security has historically focused on risk management practices to safeguard logistics, meet compliance regulations, forecast demand, and optimize inventory. While these elements are foundational to a healthy supply chain, an integrated cyber security-based perspective of the software supply chains remains broadly undefined. Recently, the global community has experienced numerous supply chain attacks targeting weaknesses in software supply chains. As illustrated in , a software supply chain attack may leverage one or more life-cycle stages and directly or indirectly target the component.

Example SSC Life-Cycle Threats

DevSecOps often depends on third-party and open-source software. These dependencies can be quite complex throughout the supply chain and render the checking of lifecycle compliance difficult. There is a need for manageable auditability and accountability of digital products. Typically, the range of types of statements about digital products (and their dependencies) is vast, heterogeneous, and can differ between community policy requirements. Taking the type and structure of all statements about digital and products into account might not be possible. Examples of statements may include commit signatures, build environment and parameters, software bill of materials, static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs. In consequence, instead of trying to understand and describe the detailed syntax and semantics of every type of statement about digital products, the SCITT architecture focuses on ensuring statement authenticity, visibility/transparency, and intends to provide scalable accessibility. Threats and practical issues can also arise from unintended side-effects of using security techniques outside their proper bounds. For instance digital signatures may fail to verify past their expiry date even though the signed item itself remains completely valid. Or a signature may verify even though the information it is securing is now found unreliable but fine-grained revocation is too hard. Lastly, where data exchange underpins serious business decision-making, it is important to hold the producers of those data to a higher standard of accountability. The SCITT architecture provides mechanisms and structures for ensuring that the makers of authoritative statements can be held accountable and not hide or shred the evidence when it becomes inconvenient later. The following use cases illustrate the scope of SCITT and elaborate on the generic problem statement above.

Eclectic SSC Use Cases The three following use cases are a specialization derived from the generic problem statement above.

Security Analysis of a Software Product A released software product is often accompanied by a set of complementary statements about its security compliance. This gives enough confidence to both producers and consumers that the released software meets the expected security standards and is suitable to use. Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product. The intention is to identify any security weaknesses or vulnerabilities in the package. Initially, a particular analysis can identify a simple weakness in a software component. Over a period of time, a statement from a third-party illustrates that the weakness is exposed in a way that represents an exploitable vulnerability. The producer of the software product provides a statement that confirms the linking of a software component vulnerability with the software product by issuing a product vulnerability disclosure report and also issues an advisory statement on how to mitigate the vulnerability. At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that inhibits exploitation. Later, a second update of the software product includes a security patch to the affected software component from the software producer. Finally, a third update includes a new release (updated version) of the formerly insecure software component. For this release, both the software product and the affected software component are deemed secure by the producer and consumers. A consumer of a released software wants to:

• know where to get these security statements from producers and third-parties related to the software product in a timely and unambiguous fashion
• attribute them to an authoritative issuer
• associate the statements in a meaningful manner via a set of well-known semantic relationships
• consistently, efficiently, and homogeneously check their authenticity

SCITT provides a standardized way to:

• know the various sources of statements
• express the provenance and historicity of statements
• relate and link various heterogeneous statements in a simple fashion
• check that the statement comes from a source with authority to issue that statement
• confirm that sources provide a complete history of statements related to a given component

Promotion of a Software Component by Multiple Entities A software component (e.g., a library or software product) released by a trusted producer is common practice for both open-source and commercial offerings. The released software component is accompanied by a statement of authenticity. Over time, due to its enhanced applicability to various products, there has been an increasing number of multiple providers of the same software component version on the internet. Some providers include this particular software component as part of their release product/package bundle and provide the package with proof of authenticity using their issuer authority. Some packages include the original statement of authenticity, and some do not. Over time, some providers no longer offer the exact same software component source code but pre-compiled software component binaries. Some sources do not provide the exact same software component, but include patches and fixes produced by third-parties, as these emerge faster than solutions from the original producer. Due to complex distribution and promotion life-cycle scenarios, the original software component takes myriad forms. A consumer of a released software wants to:

• understand if a particular provider is a trusted originating producer or an alternative party
• know if and how the source, or resulting binary, of a promoted software component differs from the original software component
• check the provenance and history of a software component's source back to its origin
• assess whether to trust a component or product based on a downloaded package location and source supplier

SCITT provides a standardized way to:

• reliably discern if a provider is the original, trusted producer or is a trustworthy alternative provider or is an illegitimate provider
• track the provenance path from an original producer to a particular provider
• check the trustworthiness of a provider
• check the integrity of modifications or transformations applied by a provider

Software Integrator Assembling a Software Product for an Autonomous Vehicle Software Integration is a complex activity. This typically involves getting various software components from multiple suppliers, producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrate software components from various sources. Integration complexity creates a higher risk of security vulnerabilities to the delivered software. Consumers of integrated software want:

• all components presents in a software product listed
• the ability to identify and retrieve all components from a secure and tamper-proof location
• to receive an alert when a vulnerability scan detects a known security issue on a running software component
• verifiable proofs on build process and build environment with all supplier tiers to ensure end to end build quality and security

SCITT provides a standardized way to:

• provide a tiered and transparent framework that allows for verification of integrity and authenticity of the integrated software at both component and product level before installation
• notify software integrators of vulnerabilities identified during security scans of running software
• provide valid annotations on build integrity to ensure conformance

Terminology The terms defined in this section have special meaning in the context of Supply Chain Integrity, Transparency, and Trust, which are used throughout this document. When used in text, the corresponding terms are capitalized. To ensure readability, only a core set of terms is included in this section. The terms "header", "payload", and "to-be-signed bytes" are defined in . The term "claim" is defined in .

Statement Sequence:

a sequence of Signed Statements captured by a Verifiable Data Structure. see Verifiable Data Structure

Append-only Log:

a Statement Sequence comprising the entire registration history of the Transparency Service. To make the Append-only property verifiable and transparent, the Transparency Service defines how Signed Statements are made available to Auditors.

Artifact:

a physical or non-physical item that is moving along a supply chain.

Auditor:

an entity that checks the correctness and consistency of all Transparent Statements, or the transparent Statement Sequence, issued by a Transparency Service. An Auditor is an example of a specialized Relying Party.

Client:

an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization.

Envelope:

metadata, created by the Issuer to produce a Signed Statement. The Envelope contains the identity of the Issuer and information about the Artifact, enabling Transparency Service Registration Policies to validate the Signed Statement. A Signed Statement is a COSE Envelope wrapped around a Statement, binding the metadata in the Envelope to the Statement. In COSE, an Envelope consists of a protected header (included in the Issuer's signature) and an unprotected header (not included in the Issuer's signature).

Equivocation:

a state where a Transparency Service provides inconsistent proofs to Relying Parties, containing conflicting claims about the Signed Statement bound at a given position in the Verifiable Data Structure .

Issuer:

an identifier representing an organization, device, user, or entity securing Statements about supply chain Artifacts. An Issuer may be the owner or author of Artifacts, or an independent third party such as an Auditor, reviewer or an endorser. In SCITT Statements and Receipts, the iss CWT Claim is a member of the COSE header parameter 15: CWT_Claims within the protected header of a COSE Envelope.

Non-equivocation:

a state where all proofs provided by the Transparency Service to Relying Parties are produced from a Single Verifiable Data Structure describing a unique sequence of Signed Statements and are therefore consistent. Over time, an Issuer may register new Signed Statements about an Artifact in a Transparency Service with new information. However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.

Receipt:

a cryptographic proof that a Signed Statement is included in the Verifiable Data Structure. See for implementations Receipts are signed proofs of verifiable data-structure properties. The types of Receipts MUST support inclusion proofs and MAY support other proof types, such as consistency proofs.

Registration:

the process of submitting a Signed Statement to a Transparency Service, applying the Transparency Service's Registration Policy, adding to the Verifiable Data Structure, and producing a Receipt.

Registration Policy:

the pre-condition enforced by the Transparency Service before registering a Signed Statement, based on information in the non-opaque header and metadata contained in its COSE Envelope.

Relying Party:

a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain.

Signed Statement:

an identifiable and non-repudiable Statement about an Artifact signed by an Issuer. In SCITT, Signed Statements are encoded as COSE signed objects; the payload of the COSE structure contains the issued Statement.

Statement:

any serializable information about an Artifact. To help interpretation of Statements, they must be tagged with a media type (as specified in ). A Statement may represent a Software Bill Of Materials (SBOM) that lists the ingredients of a software Artifact, an endorsement or attestation about an Artifact, indicate the End of Life (EOL), redirection to a newer version, or any content an Issuer wishes to publish about an Artifact. The additional Statements about an Artifact are correlated by the Subject defined in the protected header. The Statement is considered opaque to Transparency Service, and MAY be encrypted.

Subject:

an identifier, defined by the Issuer, which represents the organization, device, user, entity, or Artifact about which Statements (and Receipts) are made and by which a logical collection of Statements can be grouped. It is possible that there are multiple Statements about the same Artifact. In these cases, distinct Issuers (iss) might agree to use the sub CWT Claim to create a coherent sequence of Signed Statements about the same Artifact and Relying Parties can leverage sub to ensure completeness and Non-equivocation across Statements by identifying all Transparent Statements associated to a specific Subject.

Transparency Service:

an entity that maintains and extends the Verifiable Data Structure and endorses its state. The identity of a Transparency Service is captured by a public key that must be known by Relying Parties in order to validate Receipts.

Transparent Statement:

a Signed Statement that is augmented with a Receipt created via Registration in a Transparency Service. The Receipt is stored in the unprotected header of COSE Envelope of the Signed Statement. A Transparent Statement remains a valid Signed Statement and may be registered again in a different Transparency Service.

Verifiable Data Structure:

a data structure which supports one or more proof types, such as "inclusion proofs" or "consistency proofs", for Signed Statements as they are Registered to a Transparency Service. SCITT supports multiple Verifiable Data Structures and Receipt formats as defined in , accommodating different Transparency Service implementations.

Definition of Transparency In this document, the definition of transparency is intended to build over abstract notions of Append-only Logs and Receipts. Existing transparency systems such as Certificate Transparency are instances of this definition. SCITT supports multiple Verifiable Data Structures, as defined in . A Signed Statement is an identifiable and non-repudiable Statement made by an Issuer. The Issuer selects additional metadata and attaches a proof of endorsement (in most cases, a signature) using the identity key of the Issuer that binds the Statement and its metadata. Signed Statements can be made transparent by attaching a proof of Registration by a Transparency Service, in the form of a Receipt. Receipts demonstrate inclusion of Signed Statements in the Verifiable Data Structure of a Transparency Service. By extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact. Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable. Any Artifact that may be verified, is subject to scrutiny and auditing by other parties. The Transparency Service provides a history of Statements, which may be made by multiple Issuers, enabling Relying Parties to make informed decisions. Transparency is implemented by providing a consistent, append-only, cryptographically verifiable, publicly available record of entries. A SCITT instance is referred to as a Transparency Service. Implementations of Transparency Services may protect their registered sequence of Signed Statements and Verifiable Data Structure using a combination of trusted hardware, consensus protocols, and cryptographic evidence. A Receipt is a signature over one or more Verifiable Data Structure Proofs that a Signed Statement is registered in the Verifiable Data Structure. It is universally verifiable without online access to the TS. Requesting a Receipt can result in the production of a new Receipt for the same Signed Statement. A Receipt's verification key, signing algorithm, validity period, header parameters or other claims MAY change each time a Receipt is produced. Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent Statements registered by each Issuer. Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements. Similarly, reputable Transparency Services are incentivized to secure their Verifiable Data Structure, as any inconsistency can easily be pinpointed by any Auditor with read access to the Transparency Service. The building blocks defined in SCITT are intended to support applications in any supply chain that produces or relies upon digital Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply. SCITT is a generalization of Certificate Transparency (CT) , which can be interpreted as a transparency architecture for the supply chain of X.509 certificates. Considering CT in terms of SCITT:

• CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements)
• CAs submit the certificates to one or more CT logs (Transparency Services)
• CT logs produce Signed Certificate Timestamps (Transparent Statements)
• Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties
• The Verifiable Data Structure can be checked by Auditors

Architecture Overview The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for issuing and registering Signed Statements and auditing Transparent Statements. In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. The remaining details of the Receipt's contents are specified in . illustrates the roles and processes that comprise a Transparency Service independent of any one use case:

• Issuers that use their credentials to create Signed Statements about Artifacts
• Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration. The returned Receipt may be combined with the Signed Statement to create a Transparent Statement.
• Relying Parties that:
  • collect Receipts of Signed Statements for subsequent registration of Transparent Statements;
  • retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification);
  • or replay all the Transparent Statements to check for the consistency and correctness of the Transparency Service's Verifiable Data Structure (e.g. auditing)

In addition, illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement MAY be registered with one or more Transparency Service. Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services. The arrows indicate the flow of information.

Relationship of Concepts in SCITT + Transparency | | | Statement | .+ | | '------+-----' .-------. | | Service +-+ | | .---------+ Receipt +<--' +--+------------+ | | | |.-----. | +. | Transparency | | | | | '+------' | | | | v v '---+ Receipt +<------+ Service | | .--+-----+--. '-------' +--------+-----+ | | Transparent | | | | Statement +-------. .----------)------' '-----+-----' | | | v v v v .--------+---------. .--+--------------+--. .------+----------. / Collect Receipts / / Verify Transparent / / Replay Log / '--+---------------+ / Statement / '-+---------------+ | Relying Party | '----+---------------+ | Relying Party | +---------------+ | Relying Party | +---------------+ +---------------+ ]]>

The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.

Transparency Service Transparency Services MUST feature a Verifiable Data Structure. The Verifiable Data Structure records registered Signed Statements and supports the production of Receipts. All Transparency Services MUST expose APIs ( for the Registration of Signed Statements and issuance of Receipts. Transparency Services MAY support additional APIs for auditing, for instance querying the history of Signed Statements. Typically a Transparency Service has a single Issuer identity which is present in the iss Claim of Receipts for that service. Multi-tenant support can be enabled through the use of identifiers in the iss Claim, for example, ts.example may have a distinct Issuer identity for each sub domain, such as customer1.ts.example and customer2.ts.example.

Registration Policies Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is accepted to be registered to the Verifiable Data Structure. Transparency Services MUST maintain Registration Policies. Transparency Services MUST maintain a list of trust anchors (see definition of trust anchor in ) in order to check the signatures of Signed Statements, either separately, or inside Registration Policies. Transparency Services MUST authenticate Signed Statements as part of a Registration Policy. For instance, a trust anchor could be an X.509 root certificate (directly or its thumbprint), a pointer to an OpenID Connect identity provider, or any other COSE-compatible trust anchor. Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by registering them as Signed Statements on the Verifiable Data Structure and distributing the associated Receipts. This specification leaves implementation, encoding and documentation of Registration Policies and trust anchors to the operator of the Transparency Service.

Mandatory Registration Checks During Registration, a Transparency Service MUST, at a minimum, syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to . The Issuer identity MUST be bound to the Signed Statement by including an identifier in the protected header. If the protected header includes multiple identifiers, all those that are registered by the Transparency Service MUST be checked. When using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates currently registered as a trust anchor by the Transparency Service. The protected header of the COSE_Sign1 Envelope MUST include either the Issuer's certificate as x5t or the chain including the Issuer's certificate as x5chain. If x5t is included in the protected header, an x5chain with a leaf certificate corresponding to the x5t value MAY be included in the unprotected header. The Transparency Service MUST apply the Registration Policy that was most recently committed to the Verifiable Data Structure at the time of Registration.

Auditability of Registration The operator of a Transparency Service MAY update the Registration Policy or the trust anchors of a Transparency Service at any time. Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration.

Initialization and Bootstrapping Since the mandatory Registration checks rely on having registered Signed Statements for the Registration Policy and trust anchors, Transparency Services MUST support at least one of the three following bootstrapping mechanisms:

• Pre-configured Registration Policy and trust anchors;
• Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing Registration checks
• An out-of-band authenticated management interface

Verifiable Data Structure The security properties are determined by the choice of the Verifiable Data Structure () used by the Transparency Service implementation. This verifiable data structure MUST support the following security requirements:

Append-Only:

a property required for a verifiable data structure to be applicable to SCITT, ensuring that the Statement Sequence cannot be modified, deleted, or reordered.

Non-equivocation:

there is no fork in the registered sequence of Signed Statements accepted by the Transparency Service and committed to the Verifiable Data Structure. Everyone with access to its content sees the same ordered collection of Signed Statements and can check that it is consistent with any Receipts they have verified.

Replayability:

the Verifiable Data Structure includes sufficient information to enable authorized actors with access to its content to check that each data structure representing each Signed Statement has been correctly registered.

In addition to Receipts, some verifiable data structures might support additional proof types, such as proofs of consistency, or proofs of non-inclusion. Specific verifiable data structures, such those describes in and , and the review of their security requirements for SCITT are out of scope for this document.

Adjacent Services Transparency Services can be deployed along side other database or object storage technologies. For example, a Transparency Service that supports a software package management system, might be referenced from the APIs exposed for package management. Providing an ability to request a fresh Receipt for a given software package, or to request a list of Signed Statements associated with the software package.

Signed Statements This specification prioritizes conformance to and its required and optional properties. Profiles and implementation specific choices should be used to determine admissibility of conforming messages. This specification is left intentionally open to allow implementations to make Registration restrictions that make the most sense for their operational use cases. There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Signed Statements. An Issuer must first decide on a suitable format (3: payload type) to serialize the Statement payload. For a software supply chain, payloads describing the software Artifacts may include:

Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement. Issuers can produce Signed Statements about different Artifacts under the same Identity. Issuers and Relying Parties must be able to recognize the Artifact to which the Statements pertain by looking at the Signed Statement. The iss and sub Claims, within the CWT_Claims protected header, are used to identify the Artifact the Statement pertains to. (See Subject under Terminology.) Issuers MAY use different signing keys (identified by kid in the protected header) for different Artifacts or sign all Signed Statements under the same key. An Issuer can make multiple Statements about the same Artifact. For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting Statements, about the same Artifact. Relying Parties can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. Additionally, x5chain that corresponds to either x5t or kid identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope.

• When using x.509 certificates, support for either x5t or x5chain in the protected header is REQUIRED to implement.
• Support for kid in the protected header and x5chain in the unprotected header is OPTIONAL to implement.

When x5t or x5chain is present in the protected header, iss MUST be a string that meets URI requirements defined in . The iss value's length MUST be between 1 and 8192 characters in length. The kid header parameter MUST be present when neither x5t nor x5chain is present in the protected header. Key discovery protocols are out-of-scope of this document. The protected header of a Signed Statement and a Receipt MUST include the CWT Claims header parameter as specified in . The CWT Claims value MUST include the Issuer Claim (Claim label 1) and the Subject Claim (Claim label 2) . A Receipt is a Signed Statement, (COSE_Sign1), with additional Claims in its protected header related to verifying the inclusion proof in its unprotected header. See .

Signed Statement Examples illustrates a normative CDDL definition for the protected header and unprotected header of Signed Statements and Receipts. The SCITT architecture specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels.

CDDL definition for Signed Statements and Receipts CWT_Claims ? &(alg: 1) => int ? &(content_type: 3) => tstr / uint ? &(kid: 4) => bstr ? &(x5t: 34) => COSE_CertHash * int => any } CWT_Claims = { &(iss: 1) => tstr &(sub: 2) => tstr * int => any } Unprotected_Header = { ? &(x5chain: 33) => COSE_X509 ? &(receipts: TBD_0) => [+ Receipt] * int => any } ]]>

illustrates an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that is detached. Detached payloads support large Statements, and ensure Signed Statements can integrate with existing storage systems.

CBOR Extended Diagnostic Notation example of a Signed Statement

illustrates the decoded protected header of the Signed Statement in . It indicates the Signed Statement is securing a JSON content type, and identifying the content with the sub Claim "vendor.product.example".

CBOR Extended Diagnostic Notation example of a Signed Statement's Protected Header

Registration of Signed Statements To register a Signed Statement, the Transparency Service performs the following steps:

1. Client authentication: A Client authenticates with the Transparency Service before registering Signed Statements on behalf of one or more Issuers. Authentication and authorization are implementation-specific and out of scope of the SCITT architecture.
2. TS Signed Statement Verification and Validation: The Transparency Service MUST perform signature verification per and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per . The Transparency Service MUST also check the Signed Statement includes the required protected headers. The Transparency Service MAY validate the Signed Statement payload in order to enforce domain specific registration policies that apply to specific content types.
3. Apply Registration Policy: The Transparency Service MUST check the attributes required by a Registration Policy are present in the protected headers. Custom Signed Statements are evaluated given the current Transparency Service state and the entire Envelope and may use information contained in the attributes of named policies.
4. Register the Signed Statement
5. Return the Receipt, which MAY be asynchronous from Registration. The Transparency Service MUST be able to provide a Receipt for all registered Signed Statements. Details about generating Receipts are described in .

The last two steps may be shared between a batch of Signed Statements registered in the Verifiable Data Structure. A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt. A Transparency Service MAY accept a Signed Statement with content in its unprotected header, and MAY use values from that unprotected header during verification and registration policy evaluation. However, the unprotected header of a Signed Statement MUST be set to an empty map before the Signed Statement can be included in a Statement Sequence. The same Signed Statement may be independently registered in multiple Transparency Services, producing multiple, independent Receipts. The multiple Receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement.

Transparent Statements The Client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the unprotected header of the Signed Statement. Client applications MAY register Signed Statements on behalf of one or more Issuers. Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement. When a Signed Statement is registered by a Transparency Service a Receipt becomes available. When a Receipt is included in a Signed Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE Receipts that also provides the COSE header parameter semantics for label TBD_0. The Registration time is recorded as the timestamp when the Transparency Service added the Signed Statement to its Verifiable Data Structure. illustrates a normative CDDL definition of Transparent Statements. See for the CDDL rule that defines 'COSE_Sign1' as specified in

CDDL definition for a Transparent Statement [+ Receipt] } ]]>

illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header. The type of label TBD_0 receipts in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts).

CBOR Extended Diagnostic Notation example of a Transparent Statement

one of the decoded Receipt from . The Receipt contains inclusion proofs for verifiable data structures. The unprotected header contains verifiable data structure proofs. See the protected header for details regarding the specific verifiable data structure used. Per the COSE Verifiable Data Structure Registry documented in , the COSE key type RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and consistency proofs (-2).

CBOR Extended Diagnostic Notation example of a Receipt

illustrates the decoded protected header of the Transparent Statement in . The verifiable data structure (-111) uses 1 from (RFC9162_SHA256).

CBOR Extended Diagnostic Notation example of a Receipt's Protected Header

illustrates the decoded inclusion proof from . This inclusion proof indicates that the size of the Verifiable Data Structure was 8 at the time the Receipt was issued. The structure of this inclusion proof is specific to the verifiable data structure used (RFC9162_SHA256).

CBOR Extended Diagnostic Notation example of a Receipt's Inclusion Proof

Validation Relying Parties MUST apply the verification process as described in Section 4.4 of RFC9052, when checking the signature of Signed Statements and Receipts. A Relying Party MUST trust the verification key or certificate and the associated identity of at least one Issuer of a Receipt. A Relying Party MAY decide to verify only a single Receipt that is acceptable to them and not check the signature on the Signed Statement or Receipts which rely on verifiable data structures which they do not understand. APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result. For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if Claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. Relying Parties MAY be configured to re-verify the Issuer's Signed Statement locally. In addition, Relying Parties MAY apply arbitrary validation policies after the Transparent Statement has been verified and validated. Such policies may use as input all information in the Envelope, the Receipt, and the Statement payload, as well as any local state.

Privacy Considerations Interactions with Transparency Services are expected to use appropriately strong encryption and authorization technologies. The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration. Issuers and Clients are responsible for verifying that the Transparency Service's privacy and security posture is suitable for the contents of the Signed Statements they submit prior to Registration. Issuers must carefully review the inclusion of private, confidential, or personally identifiable information (PII) in their Statements against the Transparency Service's privacy posture. In some deployments a special role such as an Auditor might require and be given access to both the Transparency Service and related Adjacent Services. Transparency Services can leverage Verifiable Data Structures which only retain cryptographic metadata (e.g. a hash), rather than the complete Signed Statement, as part of a defense in depth approach to maintaining confidentiality. By analyzing the relationship between data stored in the Transparency Service and data stored in Adjacent Services, it is possible to perform metadata analysis, which could reveal the order in which artifacts were built, signed, and uploaded.

Security Considerations On its own, verifying a Transparent Statement does not guarantee that its Envelope or contents are trustworthy. Just that they have been signed by the apparent Issuer and counter-signed by the Transparency Service. If the Relying Party trusts the Issuer, after validation of the Issuer identity, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose. If the Relying Party trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Verifiable Data Structure. Unless advertised in the Transparency Service Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the Verifiable Data Structure matches the ordering of their issuance. Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or remediation mechanism in case one of these Transparent Statements turned out to be misleading or malicious. Just that signed evidence will be available to support them. 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 sub Claims. Issuers MUST ensure that the Statement payloads in their Signed Statements are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause Relying Parties to interpret the Signed Statement as valid for some other purpose. Issuers and Transparency Services MUST carefully protect their private signing keys and avoid these keys being used for any purpose not described in this architecture document. In cases where key re-use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE). The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. Issuers and Transparency Services MUST rotate their keys in well-defined cryptoperiods, see . A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote attestation of the hardware platforms and/or software Trusted Computing Bases (TCB) that run the Transparency Service. If present, these additional authenticity assurances MUST be registered in the Verifiable Data Structure and MUST always be exposed by the Transparency Services' APIs. An example of Signed Statement's payloads that can improve authenticity assurances are trustworthiness assessments that are RATS Conceptual Messages, such as Evidence, Endorsements, or corresponding Attestation Results (see ). For example, if a Transparency Service is implemented using a set of redundant replicas, each running within its own hardware-protected trusted execution environments (TEEs), then each replica can provide fresh Evidence or fresh Attestation Results about its TEEs. The respective Evidence can show, for example, the binding of the hardware platform to the software that runs the Transparency Service, the long-term public key of the service, or the key used by the replica for signing Receipts. The respective Attestation Result, for example, can show that the remote attestation Evidence was appraised by a Relying Party and complies with well-known Reference Values and Endorsements. Auditors should be aware that the certification path information included in an unprotected x5chain header of a to-be-registered Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately connect to an unexpected root. This modification helps protect against person-in-the-middle attacks, but not denial-of-service. Auditors MUST perform certification path validation in accordance with PKIX rules specified in . Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates).

Security Guarantees SCITT provides the following security guarantees:

1. Statements made by Issuers about supply chain Artifacts are identifiable, can be authenticated, and once authenticated, are non-repudiable
2. Statement provenance and history can be independently and consistently audited
3. Issuers can efficiently prove that their Statement is logged by a Transparency Service

The first guarantee is achieved by requiring Issuers to sign their Statements and associated metadata using a distributed public key infrastructure. The second guarantee is achieved by committing the Signed Statement to a Verifiable Data Structure. The third guarantee is achieved by the combination of both of these acts.

Threat Model This section provides a generic threat model for SCITT, describing its residual security properties when some of its actors (Issuers, Transparency Services, and Auditors) are corrupt or compromised. This threat model may need to be refined to account for specific supply chain use cases. SCITT primarily supports checking of Signed Statement authenticity, both from the Issuer (authentication) and from the Transparency Service (transparency). These guarantees are meant to hold for extensive periods of time, possibly decades. It can never be assumed that some Issuers and some Transparency Services will not be corrupt. SCITT entities explicitly trust one another on the basis of their long-term identity, which maps to shorter-lived cryptographic credentials. A Relying Party SHOULD validate a Transparent Statement originating from a given Issuer, registered at a given Transparency Service (both identified in the Relying Party's local authorization policy) and would not depend on any other Issuer or Transparency Services. Issuers cannot be stopped from producing Signed Statements including false assertions in their Statement payload (either by mistake or by corruption), but these Issuers can made accountable by ensuring their Signed Statements are systematically registered at a Transparency Service. Similarly, providing strong residual guarantees against faulty/corrupt Transparency Services is a SCITT design goal. Preventing a Transparency Service from registering Signed Statements that do not meet its stated Registration Policy, or to issue Receipts that are not consistent with their Verifiable Data Structure is not possible. In contrast, Transparency Services can be held accountable and blamed by an Auditor that replays the Sequence of Signed Statements captured in their Verifiable Data Structure to confirm that a contested Receipt is valid and was correctly registered. Transparency Services can provide consistency proofs allowing Auditors to check if a set of Receipts were issued from a single Verifiable Data Structure, without replaying individual Signed Statements. Certain Verifiable Data Structures enable a Transparency Service to prove the properties of its Statement Sequence. For example, proving a specific Signed Statement is included in the sequence, or that the sequence has only been extended (Append-only property) since the last time such a proof was created. Note that the SCITT Architecture does not require trust in a single centralized Transparency Service. Different actors may rely on different Transparency Services, each registering a subset of Signed Statements subject to their own policy. In both cases, the SCITT architecture provides generic, universally-verifiable cryptographic proofs to individually blame Issuers or the Transparency Service. On one hand, this enables valid actors to detect and disambiguate malicious actors who employ Equivocation with Signed Statements to different entities. On the other hand, their liability and the resulting damage to their reputation are application specific, and out of scope of the SCITT architecture. Relying Parties and Auditors need not be trusted by other actors. So long as actors maintain proper control of their signing keys and identity infrastructure they cannot "frame" an Issuer or a Transparency Service for Signed Statements they did not issue or register.

Verifiable Data Structure If a Transparency Service is honest, then a Transparent Statement including a correct Receipt ensures that the associated Signed Statement passed its Registration Policy and was registered appropriately. Conversely, a corrupt Transparency Service may:

1. refuse or delay the Registration of Signed Statements
2. register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify)
3. issue verifiable Receipts for Signed Statements that do not match its Verifiable Data Structure
4. refuse access to its Transparency Service (e.g., to Auditors, possibly after storage loss)

An Auditor granted (partial) access to a Transparency Service and to a collection of disputed Receipts will be able to replay it, detect any invalid Registration (2) or incorrect Receipt in this collection (3), and blame the Transparency Service for them. This ensures any Relying Party that trusts at least one such Auditor that (2, 3) will be blamed to the Transparency Service. Due to the operational challenge of maintaining a globally consistent Verifiable Data Structure, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered and accept the risk of being blamed for inconsistent Registration or Issuer Equivocation. Relying Parties and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.

Availability of Receipts Networking and Storage are trusted only for availability. Auditing may involve access to data beyond what is persisted in the Transparency Services. For example, the registered Transparency Service may include only the hash of a detailed SBOM, which may limit the scope of auditing. Resistance to denial-of-service is implementation specific. Actors may want to independently keep their own record of the Signed Statements they issue, endorse, verify, or audit.

Cryptographic Agility The SCITT Architecture supports cryptographic agility. The actors depend only on the subset of signing and Receipt schemes they trust. This enables the gradual transition to stronger algorithms, including e.g. post-quantum signature algorithms.

Transparency Service Client Applications Authentication of Client applications is out of scope for this document. Transparency Services MUST authenticate both Client applications and the Issuer of Signed Statements in order to ensure that implementation of specific authentication and authorization policies are enforced. The specification of authentication and authorization policies is out of scope for this document.

Impersonation The identity resolution mechanism is trusted to associate long-term identifiers with their public signature-verification keys. Transparency Services and other parties may record identity-resolution evidence to facilitate its auditing. If one of the credentials of an Issuer gets compromised, the SCITT Architecture still guarantees the authenticity of all Signed Statements signed with this credential that have been registered on a Transparency Service before the compromise. It is up to the Issuer to notify Transparency Services of credential revocation to stop Relying Parties from accepting Signed Statements signed with compromised credentials.

IANA Considerations

COSE Receipts Header Parameter TBD_0 is requested in .

Media Type Registration Pending WG discussion.

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Transmute Fraunhofer SIT Microsoft Microsoft COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. Fraunhofer SIT DataTrails Inc. This document describes a REST API that supports the normative requirements of the SCITT Architecture. Optional key discovery and query interfaces are provided to support interoperability with X.509 Certificates, alternative methods commonly used to support public key discovery and Artifact Repositories. Mattr Self-Issued Consulting This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory National Institute of Standards and Technology (U.S.)

US Gaithersburg

A cloud workload is an abstraction of the actual instance of a functional application that is virtualized or containerized to include compute, storage, and network resources. Organizations need to be able to monitor, track, apply, and enforce their security and privacy policies on their cloud workloads, based on business requirements, in a consistent, repeatable, and automated way. The goal of this project is to develop a trusted cloud solution that will demonstrate how trusted compute pools leveraging hardware roots of trust can provide the necessary security capabilities. These capabilities not only provide assurance that cloud workloads are running on trusted hardware and in a trusted geolocation or logical boundary, but also improve the protections for the data in the workloads and in the data flows between workloads. The example solution leverages modern commercial off-the-shelf technology and cloud services to address lifting and shifting a typical multi-tier application between an organization-controlled private cloud and a hybrid/public cloud over the internet. Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology (U.S.) This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. n.d. n.d. UC Berkeley, Berkeley Intel Research Berkeley, Berkeley UC Berkeley, Berkeley UC Berkeley, Berkeley Association for Computing Machinery (ACM) n.d. Microsoft Research MIT Laboratory for Computer Science Association for Computing Machinery (ACM) n.d. n.d. n.d. n.d. National Institute of Standards and Technology

Common Terminology Disambiguation This document has been developed in coordination with the COSE, OAUTH and RATS WG and uses terminology common to these working groups. This document uses the terms "Issuer", and "Subject" as described in , however the usage is consistent with the broader interpretation of these terms in both JOSE and COSE, and the guidance in generally applies the COSE equivalent terms with consistent semantics. The terms "verifier" and "Relying Party" are used interchangeably through the document. While these terms are related to "Verifier" and "Relying Party" as used in , they do not imply the processing of RATS conceptual messages, such as Evidence or Attestation Results that are specific to remote attestation. A SCITT "verifier" and "Relying Party" and "Issuer" of Receipts or Statements might take on the role of a RATS "Attester". Correspondingly, all RATS conceptual messages, such as Evidence and Attestation Results, can be the content of SCITT Statements and a SCITT "verifier" can also take on the role of a RATS "Verifier" to, for example, conduct the procedure of Appraisal of Evidence as a part of a SCITT "verifier"'s verification capabilities. The terms "Claim" and "Statement" are used throughout this document, where Claim is consistent with the usage in and , and Statement is reserved for any arbitrary bytes, possibly identified with a media type, about which the Claims are made. The term "Subject" provides an identifier of the Issuer's choosing to refer to a given Artifact and ensures that all associated Statements can be attributed to the identifier chosen by the Issuer. In simpler language, a SCITT Statement could be some vendor-specific software bill of materials (SBOM), results from a model checker, static analyzer, or RATS Evidence about the authenticity of an SBOM creation process, where the Issuer identifies themselves using the iss Claim, and the specific software that was analyzed as the Subject using the sub Claim. In , the Authorization Server (AS) verifies Private Key JWT client authentication requests, and issues access tokens to clients configured to use "urn:ietf:params:oauth:client-assertion-type:jwt-bearer". This means the AS initially acts as a "verifier" of the authentication credentials in form of a JWT, and then later as an "Issuer" of access and refresh tokens. This mirrors how Signed Statements are verified before Receipts are issued by a Transparency Service. Note that the use of is only one possible approach for client authentication in OAuth. defines "assertion" as "A verifiable statement from an IdP to an RP that contains information about an end user". defines "assertion" as "A statement from a verifier to an RP that contains information about a subscriber. Assertions may also contain verified attributes." This document uses the term Statement to refer to potentially unsecured data and associated Claims, and Signed Statement and Receipt to refer to assertions from an Issuer, or the Transparency Service. 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 , which states that an "attestation" is "The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.". In the RATS context, a "NIST attestation" is similar to a RATS "Endorsement". Occasionally, RATS Evidence and RATS Attestation Results or the procedures of creating these conceptual messages are referred to as "attestation" or (in cases of the use as a verb) "to attest". The stand-alone use of "attestation" and "to attest" is discouraged outside a well-defined context, such as specification text that highlights the application of terminology, explicitly. Correspondingly, it is often useful for the intended audience to qualify the term "attestation" to avoid confusion and ambiguity.

Signing Statements Remotely Statements about digital Artifacts, containing digital Artifacts, or structured data regarding any type of Artifacts, can be too large or too sensitive to be send to a remote Transparency Services over the Internet. In these cases a Statement can also be hash, which becomes the payload included in COSE to-be-signed bytes. A Signed Statement (COSE_Sign1) MUST be produced from the to-be-signed bytes according to . + OR +-->+ Payload | v | \ / '--------+-' .+--------. | \/ | | Statement +--+ | '---------' | | | ... Producer Network ... | ... ... Issuer Network ... | | | .---------. | | Identity | (iss, x5t) | | Document +--------------------+ | `----+----` | | ^ | | .----+-------. | | | Private Key | | | '----+-------' v | | .----+---. | | | Header | | | '----+---' | v v v .-+-----------. .------+------+--. / / / \ / Sign +<------+ To Be Signed Bytes | / / \ / '-----+-------' '----------------' v .----+-------. | COSE Sign 1 | '------------' ]]>

Contributors Transmute

United States orie@transmute.industries

Orie contributed to improving the generalization of COSE building blocks and document consistency. Business Cyber Guardian (TM)

United States dick@businesscyberguardian.com

Dick contributed to the software supply chain use cases. Microsoft

United States brianknight@microsoft.com

Brian contributed to the software supply chain use cases. MITRE Corporation

United States ramartin@mitre.org

Robert contributed to the software supply chain use cases.