SCITT H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Standards Track A. Delignat-Lavaud Expires: 23 January 2025 C. Fournet Microsoft Research Y. Deshpande ARM S. Lasker DataTrails 22 July 2024 An Architecture for Trustworthy and Transparent Digital Supply Chains draft-ietf-scitt-architecture-08 Abstract 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 any Transparency Service, with the guarantee that any Relying Parties will be able to verify them. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/. Discussion of this document takes place on the SCITT Working Group mailing list (mailto:scitt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at https://www.ietf.org/mailman/listinfo/scitt/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture. Birkholz, et al. Expires 23 January 2025 [Page 1] Internet-Draft SCITT Architecture July 2024 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Transparency . . . . . . . . . . . . . . . . . 7 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 4.1. Transparency Service . . . . . . . . . . . . . . . . . . 11 4.1.1. Registration Policies . . . . . . . . . . . . . . . . 11 4.1.2. Initialization and Bootstrapping . . . . . . . . . . 12 4.1.3. Append-only Log . . . . . . . . . . . . . . . . . . . 13 4.1.4. Adjacent Services . . . . . . . . . . . . . . . . . . 13 4.2. Signed Statements . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Signed Statement Examples . . . . . . . . . . . . . . 15 4.3. Registration . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Transparent Statements . . . . . . . . . . . . . . . . . 18 4.4.1. Validation . . . . . . . . . . . . . . . . . . . . . 21 Birkholz, et al. Expires 23 January 2025 [Page 2] Internet-Draft SCITT Architecture July 2024 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 24 6.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Append-only Log . . . . . . . . . . . . . . . . . . . 25 6.2.2. Availability of Receipts . . . . . . . . . . . . . . 26 6.2.3. Confidentiality and Privacy . . . . . . . . . . . . . 27 6.2.4. Cryptographic Agility . . . . . . . . . . . . . . . . 27 6.2.5. Transparency Service Client Applications . . . . . . 27 6.2.6. Impersonation . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Common Terminology Disambiguation . . . . . . . . . 32 Appendix B. Identifiers . . . . . . . . . . . . . . . . . . . . 34 B.1. Identifiers For Binary Content . . . . . . . . . . . . . 35 B.2. Identifiers For SCITT Messages . . . . . . . . . . . . . 36 B.3. Identifiers For Transparent Statements . . . . . . . . . 36 B.4. Statements . . . . . . . . . . . . . . . . . . . . . . . 37 B.4.1. Statement URN . . . . . . . . . . . . . . . . . . . . 37 B.4.2. Statement URL . . . . . . . . . . . . . . . . . . . . 37 B.4.3. Statement Data URL . . . . . . . . . . . . . . . . . 37 B.5. Signed Statements . . . . . . . . . . . . . . . . . . . . 37 B.5.1. Signed Statement URN . . . . . . . . . . . . . . . . 37 B.5.2. Signed Statement URL . . . . . . . . . . . . . . . . 37 B.5.3. Signed Statement Data URL . . . . . . . . . . . . . . 38 B.6. Receipts . . . . . . . . . . . . . . . . . . . . . . . . 38 B.6.1. Receipt URN . . . . . . . . . . . . . . . . . . . . . 38 B.6.2. Receipt URL . . . . . . . . . . . . . . . . . . . . . 38 B.6.3. Receipt Data URL . . . . . . . . . . . . . . . . . . 38 B.7. Transparent Statements . . . . . . . . . . . . . . . . . 38 B.7.1. Transparent Statement URN . . . . . . . . . . . . . . 38 B.7.2. Transparent Statement URL . . . . . . . . . . . . . . 38 B.7.3. Transparent Statement Data URL . . . . . . . . . . . 38 Appendix C. Signing Statements Remotely . . . . . . . . . . . . 39 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction This document describes the generic, interoperable, and scalable SCITT architecture. Its goal is to enhance auditability and accountability across supply chains. Birkholz, et al. Expires 23 January 2025 [Page 3] Internet-Draft SCITT Architecture July 2024 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. 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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 [RFC9052]. The term "claim" is defined in [RFC8392]. Append-only Log (Ledger): the verifiable append-only data structure that stores Signed Statements in a Transparency Service, often referred to by the synonym Ledger. SCITT supports multiple Ledger and Receipt formats to accommodate different Transparency Service implementations, and the proof types associated with different types of Append-only Logs. Birkholz, et al. Expires 23 January 2025 [Page 4] Internet-Draft SCITT Architecture July 2024 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 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 it is possible for a Transparency Service to provide different views of its Append-only log to Relying Parties about the same Artifact [EQUIVOCATION]. 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 it is impossible for a Transparency Service to provide different views of its Append-only Log to Relying Parties about the same Artifact. 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 Append-only Log. Receipts are based on Signed Inclusion Proofs, such as those as described in COSE Signed Merkle Tree Proofs [I-D.draft-ietf-cose-merkle-tree-proofs]; they can be built on different verifiable data structures, not just binary merkle trees. A Receipt consists of a Transparency Service-specific inclusion proof for the Signed Statement, a signature by the Birkholz, et al. Expires 23 January 2025 [Page 5] Internet-Draft SCITT Architecture July 2024 Transparency Service of the state of the Append-only Log after the inclusion, and additional metadata (contained in the signature's protected headers) to assist in auditing. Registration: the process of submitting a Signed Statement to a Transparency Service, applying the Transparency Service's Registration Policy, adding to the Append-only Log, 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 [RFC6838]). 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 [CWT_CLAIMS] protected header. The Statement is considered opaque to Transparency Service, and MAY be encrypted. Subject: an identifier, defined by the Issuer, that represents the organization, device, user, entity, or Artifact about which Statements (and Receipts) are made and by which a logical collection of Statements can be grouped. It is possible that there are multiple Statements about the same Artifact. In these cases, distinct Issuers (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 Birkholz, et al. Expires 23 January 2025 [Page 6] Internet-Draft SCITT Architecture July 2024 Append-only Log, and endorses its state. A Transparency Service can be a complex system, requiring the Transparency Service to provide many security guarantees about its Append-only Log. 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" (as defined in [I-D.draft-ietf-cose-merkle-tree-proofs]). 3. 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. 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 Append-only Log 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. Birkholz, et al. Expires 23 January 2025 [Page 7] Internet-Draft SCITT Architecture July 2024 Implementations of Transparency Services may protect their Append- only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence. A Receipt is an offline, universally-verifiable proof that an entry is recorded in the Append-only Log. 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. However, the Registrations on a separate Transparency Service is generally disjoint, though it is possible to take a Transparent Statement (i.e. a Signed Statement with a Receipt in its unprotected header, from a from the first Transparency Service) and register it on another Transparency Service, where the second Receipt will be over the first Receipt in the unprotected header. 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 Append-only Log, 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) [RFC9162], 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 are checked by Relying Parties * The Append-only Log can be checked by Auditors Birkholz, et al. Expires 23 January 2025 [Page 8] Internet-Draft SCITT Architecture July 2024 4. 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. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document [I-D.draft-ietf-cose-merkle-tree-proofs]. Birkholz, et al. Expires 23 January 2025 [Page 9] Internet-Draft SCITT Architecture July 2024 .----------. | Artifact | '-----+----' .-------------. v | Credentials | .----+----. | | | Statement | '----+--+-----' '----+----' cose sign | | cose verify | .----------------'| | | | | | v v | |'----------. .----+---+---. | | | | Signed | | | | | Statement | | | | | (COSE_Sign1) | | | | '------+-----' v v | | +---+--+--------+ | .--' '-------------->+ Transparency | | | .--------. | | | | | Receipt +<------+ Service +-+ | | | +. +--+------------+ | | | '-+------' | | Transparency | | | | Receipt +<-------+ | | | '------+' | Service | | '-------. .-' +------------+-+ | | | | v | | .-----+-----. | | | Transparent | | | | Statement | | | '-----+-----' | | | | | |'-----------. .----------)--' | | | | | v v | | .--------+-+---------. | | / Verify Transparent / | | / Statement / | | '--------------------' | v v .--------+---------. .----------+-----. / Collect Receipts / / Replay Log / '------------------' '----------------' The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail. Birkholz, et al. Expires 23 January 2025 [Page 10] Internet-Draft SCITT Architecture July 2024 4.1. Transparency Service Transparency Services MUST feature an Append-only Log. The Append- only Log is the verifiable data structure that records 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, to query 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. 4.1.1. 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 Append-only Log. Transparency Services MUST maintain Registration Policies. Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement. For instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI 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 Append-only Log, 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. Birkholz, et al. Expires 23 January 2025 [Page 11] Internet-Draft SCITT Architecture July 2024 4.1.1.1. 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 [RFC9052]. 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. In essence, when using X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by x5t located in the protected header of the COSE_Sign1 Envelope, to one of the root certificates most recently registered as a trust anchor of the Transparency Service. An x5chain with a leaf certificate that corresponds to the x5t value MAY be included in the unprotected header in support of certain supply chain scenarios. The Transparency Service MUST apply the Registration Policy that was most recently added to the Append-only Log at the time of Registration. 4.1.1.2. 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 (either in the Append-only Log and retrievable through audit APIs, or included in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. 4.1.2. 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 Birkholz, et al. Expires 23 January 2025 [Page 12] Internet-Draft SCITT Architecture July 2024 4.1.3. Append-only Log The security properties of the Append-only Log are determined by the choice of the verifiable data structure used by the Transparency Service to implement the Log. This verifiable data structure MUST support the following security requirements: Append-Only: once included in the verifiable data structure, a Signed Statement cannot be modified, deleted, or reordered; hence its Receipt provides an offline verifiable proof of Registration. Non-equivocation: there is no fork in the Append-only Log. Everyone with access to its content sees the same collection of Signed Statements and can check that it is consistent with any Receipts they have verified. Replayability: the Append-only Log includes sufficient information to enable authorized actors with access to its content to check that each included 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 [RFC9162] and [I-D.draft-ietf-cose-merkle-tree-proofs], and the review of their security requirements for SCITT are out of scope for this document. 4.1.4. Adjacent Services Transparency Services can be deployed along side other database or object storage technologies. For example, a Transparency Service that is supporting 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. 4.2. Signed Statements This specification prioritizes conformance to [RFC9052] and its required and optional properties. Profiles and implementation specific choices should be used to determine admissability of conforming messages. This specification is left intentionally open to allow implementations to make the restrictions that make the most sense for their operational use cases. Birkholz, et al. Expires 23 January 2025 [Page 13] Internet-Draft SCITT Architecture July 2024 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: * [COSWID] * [CycloneDX] * [in-toto] * [SPDX-CBOR] * [SPDX-JSON] * [SLSA] * [SWID] Once all the Envelope headers are set, an Issuer MUST use a standard COSE implementation to produce an appropriately serialized Signed Statement. The SCITT tag COSE_Sign1_Tagged is outside the scope of COSE, and used to indicate that a signed object is a 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 Section 2 Terminology.) Issuers MAY use different signing keys (identified by kid in the resolved key manifest) 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. Birkholz, et al. Expires 23 January 2025 [Page 14] Internet-Draft SCITT Architecture July 2024 At least one identifier representing one credential MUST be included in the protected header of the COSE Envelope, as one of x5t or kid. 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 x5t is REQUIRED to implement. * Support for kid in the protected header and x5chain in the unprotected header is OPTIONAL to implement. When x5t is present, iss MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. The kid header parameter MUST be present when x5t is not present. 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 Section 2 of [CWT_CLAIMS_COSE]. The CWT Claims value MUST include the Issuer Claim (Claim label 1) and the Subject Claim (Claim label 2) [IANA.cwt]. A Receipt is a Signed Statement, (cose-sign1), with addition Claims in its protected header related to verifying the inclusion proof in its unprotected header. See [I-D.draft-ietf-cose-merkle-tree-proofs]. 4.2.1. Signed Statement Examples Figure 1 illustrates a normative CDDL definition (see [RFC8610]) for of the protected header and unprotected header of Signed Statements and Receipts. Everything that is optional in the following CDDL definition can potentially be discovered out of band and Registration Policies are not assured on the presence of these optional fields. A Registration Policy that requires an optional field to be present MUST reject any Signed Statements or Receipts that are invalid according to the Registration Policy. Birkholz, et al. Expires 23 January 2025 [Page 15] Internet-Draft SCITT Architecture July 2024 Signed_Statement = #6.18(COSE_Sign1) Receipt = #6.18(COSE_Sign1) COSE_Sign1 = [ protected : bstr .cbor Protected_Header, unprotected : Unprotected_Header, payload : bstr / nil, signature : bstr ] Protected_Header = { &(CWT_Claims: 15) => 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: 394) => [+ Receipt] * int => any } Figure 1: CDDL definition for Signed Statements and Receipts Figure 2 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. 18( / COSE Sign 1 / [ h'a4012603...6d706c65', / Protected / {}, / Unprotected / nil, / Detached payload / h'79ada558...3a28bae4' / Signature / ] ) Birkholz, et al. Expires 23 January 2025 [Page 16] Internet-Draft SCITT Architecture July 2024 Figure 2: CBOR Extended Diagnostic Notation example of a Signed Statement Figure 3 illustrates the decoded protected header of the Signed Statement in Figure 2. It indicates the Signed Statement is securing a JSON content type, and identifying the content with the sub Claim "vendor.product.example". { / Protected / 1: -7, / Algorithm / 3: application/example+json, / Content type / 4: h'50685f55...50523255', / Key identifier / 15: { / CWT Claims / 1: software.vendor.example, / Issuer / 2: vendor.product.example, / Subject / } } Figure 3: CBOR Extended Diagnostic Notation example of a Signed Statement's Protected Header 4.3. Registration To register a Signed Statement, the Transparency Service performs the following steps: 1. *Client authentication:* A Client authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more Issuers. Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. 2. *Issuer Verification:* The Transparency Service MUST syntactically validate the Issuer's identity Claims, which may be different than the Client identity. 3. *Signature verification:* The Transparency Service MUST verify the signature of the Signed Statement, as described in [RFC9360], using the signature algorithm and verification key of the Issuer. 4. *Signed Statement validation:* The Transparency Service MUST check that the Signed Statement includes the required protected headers listed above. The Transparency Service MAY verify the Statement payload format, content and other optional properties. 5. *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 Birkholz, et al. Expires 23 January 2025 [Page 17] Internet-Draft SCITT Architecture July 2024 given the current Transparency Service state and the entire Envelope, and may use information contained in the attributes of named policies. 6. *Register the Signed Statement* to the Append-only Log. 7. *Return the Receipt*, which MAY be asynchronous from Registration. The Transparency Service MUST be able to provide a Receipt for all registered Statements. A Receipt for a Signed Statement MAY be provided asynchronously. Details about generating Receipts are described in Section 4.4. The last two steps may be shared between a batch of Signed Statements recorded in the Append-only Log. A Transparency Service MUST ensure that a Signed Statement is registered before releasing its Receipt. 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. 4.4. 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 Signed Merkle Tree Proofs ([I-D.draft-ietf-cose-merkle-tree-proofs]) that also provides the COSE header parameter semantics for label 394. The Registration time is recorded as the timestamp when the Transparency Service added this Signed Statement to its Append-only Log. Figure 4 illustrates a normative CDDL definition of Transparent Statements. Birkholz, et al. Expires 23 January 2025 [Page 18] Internet-Draft SCITT Architecture July 2024 Transparent_Statement = #6.18(COSE_Sign1) Unprotected_Header = { &(receipts: 394) => [+ Receipt] } Figure 4: CDDL definition for a Transparent Statement Figure 5 illustrates a Transparent Statement with a detached payload, and two Receipts in its unprotected header. The type of label 394 receipts in the unprotected header is a CBOR array that can contain one or more Receipts (each entry encoded as a .cbor encoded Receipts). 18( / COSE Sign 1 / [ h'a4012603...6d706c65', / Protected / { / Unprotected / 394: [ / Receipts (2) / h'd284586c...4191f9d2' / Receipt 1 / h'c624586c...8f4af97e' / Receipt 2 / ] }, nil, / Detached payload / h'79ada558...3a28bae4' / Signature / ] ) Figure 5: CBOR Extended Diagnostic Notation example of a Transparent Statement Figure 6 one of the decoded Receipt from Figure 5. 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. Referencing the COSE Verifiable Data Structure Registry, RFC9162_SHA256 is value 1, which supports -1 (inclusion proofs) and -2 (consistency proofs). Birkholz, et al. Expires 23 January 2025 [Page 19] Internet-Draft SCITT Architecture July 2024 18( / COSE Sign 1 / [ h'a4012604...6d706c65', / Protected / { / Unprotected / -222: { / Proofs / -1: [ / Inclusion proofs (1) / h'83080783...32568964', / Inclusion proof 1 / ] }, }, nil, / Detached payload / h'10f6b12a...4191f9d2' / Signature / ] ) Figure 6: CBOR Extended Diagnostic Notation example of a Receipt Figure 7 illustrates the decoded protected header of the Transparent Statement in Figure 5. The verifiable data structure (-111) uses 1 from (RFC9162_SHA256). { / Protected / 1: -7, / Algorithm / 4: h'50685f55...50523255', / Key identifier / -111: 1, / Verifiable Data Structure / 15: { / CWT Claims / 1: transparency.vendor.example, / Issuer / 2: vendor.product.example, / Subject / } } Figure 7: CBOR Extended Diagnostic Notation example of a Receipt's Protected Header Figure 8 illustrates the decoded inclusion proof from Figure 6. This inclusion proof indicates that the size of the Append-only Log 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). Birkholz, et al. Expires 23 January 2025 [Page 20] Internet-Draft SCITT Architecture July 2024 [ / Inclusion proof 1 / 8, / Tree size / 7, / Leaf index / [ / Inclusion hashes (3) / h'c561d333...f9850597' / Intermediate hash 1 / h'75f177fd...2e73a8ab' / Intermediate hash 2 / h'0bdaaed3...32568964' / Intermediate hash 3 / ] ] Figure 8: CBOR Extended Diagnostic Notation example of a Receipt's Inclusion Proof 4.4.1. 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. 5. Privacy Considerations Transparency Services are often publicly accessible. Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible. In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. Birkholz, et al. Expires 23 January 2025 [Page 21] Internet-Draft SCITT Architecture July 2024 Transparency Services can have an authorization policy controlling who can access the Append-only Log. While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten. However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. 6. 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 Append-only Log. Unless advertised in the Transparency Service Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the Append-only Log 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. Birkholz, et al. Expires 23 January 2025 [Page 22] Internet-Draft SCITT Architecture July 2024 Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. 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 [PBFT] 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 verification keys for signature checking in well-defined cryptoperiods (see [KEY-MANAGEMENT]). 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 Append-only Log 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 [RFC9334]). 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 Birkholz, et al. Expires 23 January 2025 [Page 23] Internet-Draft SCITT Architecture July 2024 with PKIX rules specified in [RFC5280]. In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates). 6.1. 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 storing the Signed Statement on an Append-only Log. The third guarantee is achieved by implementing the Append-only Log using a verifiable data structure (such as a Merkle Tree [MERKLE]). 6.2. 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. Birkholz, et al. Expires 23 January 2025 [Page 24] Internet-Draft SCITT Architecture July 2024 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 Append-only Log is not possible. In contrast Transparency Services can be held accountable and they can be called out by any Auditor that replays their Append-only Log against any contested Receipt. 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. In particular, 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. 6.2.1. Append-only Log 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 recorded appropriately. Birkholz, et al. Expires 23 January 2025 [Page 25] Internet-Draft SCITT Architecture July 2024 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 Append-only Log 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 Append-only Log, 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. 6.2.2. 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. Birkholz, et al. Expires 23 January 2025 [Page 26] Internet-Draft SCITT Architecture July 2024 6.2.3. Confidentiality and Privacy All contents exchanged between actors is protected using secure authenticated channels (e.g., TLS) but may not exclude network traffic analysis. The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration. Some Transparency Services may publish every Signed Statement in their logs, to facilitate their dissemination and auditing. Transparency Services MAY return Receipts to Client applications synchronously or asynchronously. A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency Service. Issuers must carefully review the inclusion of private/confidential materials in their Statements. For example, Issuers must remove Personally Identifiable Information (PII) as clear text in the Statement. Alternatively, Issuers may include opaque cryptographic Statements, such as hashes. The confidentiality of queries is implementation-specific, and generally not guaranteed. For example, while offline Envelope validation of Signed Statements is private, a Transparency Service may monitor which of its Transparent Statements are being verified from lookups to ensure their freshness. 6.2.4. 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. 6.2.5. 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 specific authentication and authorization policies are enforced. The specification of authentication and authorization policies is out of scope for this document. Birkholz, et al. Expires 23 January 2025 [Page 27] Internet-Draft SCITT Architecture July 2024 6.2.6. 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. 7. IANA Considerations 7.1. Media Type Registration Pending WG discussion. 8. References 8.1. Normative References [COSWID] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, June 2023, . [CWT_CLAIMS_COSE] Looker, T. and M. B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", Work in Progress, Internet-Draft, draft- ietf-cose-cwt-claims-in-headers-10, 29 November 2023, . [I-D.draft-ietf-cose-merkle-tree-proofs] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "COSE Receipts", Work in Progress, Internet- Draft, draft-ietf-cose-merkle-tree-proofs-05, 18 June 2024, . [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", 22 March 2018, . Birkholz, et al. Expires 23 January 2025 [Page 28] Internet-Draft SCITT Architecture July 2024 [IANA.named-information] IANA, "Named Information", 14 August 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Birkholz, et al. Expires 23 January 2025 [Page 29] Internet-Draft SCITT Architecture July 2024 [RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, . 8.2. Informative References [CWT_CLAIMS] "CBOR Web Token (CWT) Claims", n.d., . [CycloneDX] "CycloneDX", n.d., . [EQUIVOCATION] Chun, B., Maniatis, P., Shenker, S., and J. Kubiatowicz, "Attested append-only memory: making adversaries stick to their word", Association for Computing Machinery (ACM), ACM SIGOPS Operating Systems Review vol. 41, no. 6, pp. 189-204, DOI 10.1145/1323293.1294280, October 2007, . [FIPS.201] Romine, C., "Personal identity verification (PIV) of federal employees and contractors", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.201-3, January 2022, . [I-D.draft-ietf-core-href] Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft- ietf-core-href-15, 21 April 2024, . [I-D.draft-ietf-rats-eat] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-29, 8 July 2024, . [in-toto] "in-toto", n.d., . [ISO.17000.2020] "ISO/IEC 17000:2020", n.d., . Birkholz, et al. Expires 23 January 2025 [Page 30] Internet-Draft SCITT Architecture July 2024 [KEY-MANAGEMENT] Barker, E. and W. Barker, "Recommendation for key management:: part 2 -- best practices for key management organizations", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-57pt2r1, May 2019, . [MERKLE] Merkle, R., "A Digital Signature Based on a Conventional Encryption Function", Springer Berlin Heidelberg, Advances in Cryptology — CRYPTO ’87 pp. 369-378, DOI 10.1007/3-540-48184-2_32, ISBN ["9783540187967", "9783540481843"], 1988, . [NIST.SP.1800-19] Bartock, M., Dodson, D., Souppaya, M., Carroll, D., Masten, R., Scinta, G., Massis, P., Prafullchandra, H., Malnar, J., Singh, H., Ghandi, R., Storey, L. E., Yeluri, R., Shea, T., Dalton, M., Weber, R., Scarfone, K., Dukes, A., Haskins, J., Phoenix, C., Swarts, B., and National Institute of Standards and Technology (U.S.), "Trusted cloud :security practice guide for VMware hybrid cloud infrastructure as a service (IaaS) environments", NIST Special Publications (General) 1800-19, DOI 10.6028/NIST.SP.1800-19, 20 April 2022, . [NIST.SP.800-63-3] Grassi, P. A., Garcia, M. E., Fenton, J. L., and NIST, "Digital identity guidelines: revision 3", NIST Special Publications (General) 800-63-3, DOI 10.6028/NIST.SP.800-63-3, 22 June 2017, . [PBFT] Castro, M. and B. Liskov, "Practical byzantine fault tolerance and proactive recovery", Association for Computing Machinery (ACM), ACM Transactions on Computer Systems vol. 20, no. 4, pp. 398-461, DOI 10.1145/571637.571640, November 2002, . [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, . Birkholz, et al. Expires 23 January 2025 [Page 31] Internet-Draft SCITT Architecture July 2024 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [SLSA] "SLSA", n.d., . [SPDX-CBOR] "SPDX Specification", n.d., . [SPDX-JSON] "SPDX Specification", n.d., . [SWID] "SWID Specification", n.d., . [URLs] "URL Living Standard", n.d., . Appendix A. 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. Birkholz, et al. Expires 23 January 2025 [Page 32] Internet-Draft SCITT Architecture July 2024 This document uses the terms "Issuer", and "Subject" as described in [RFC8392], however the usage is consistent with the broader interpretation of these terms in both JOSE and COSE, and in particular, the guidance in [RFC8725] 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 [RFC9334], 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 [I-D.draft-ietf-rats-eat] and [RFC7523], 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 [RFC7523], 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 [RFC7523] is only one possible approach for client authentication in OAuth. [FIPS.201] defines "assertion" as "A verifiable statement from an IdP to an RP that contains information about an end user". Birkholz, et al. Expires 23 January 2025 [Page 33] Internet-Draft SCITT Architecture July 2024 [NIST.SP.800-63-3] 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. [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 [ISO.17000.2020], 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. Appendix B. Identifiers This section provides informative examples of identifiers for Statements, Signed Statements, and Receipts. SCITT Identifiers are primarily meant to be understood by humans and secondarily meant to be understood by machines, as such we define text encodings for message identifiers first, and then provide binary translations according to standard transformations for URLs and URNs to binary formats. SCITT Identifiers for URLs and URNs that are not Data URLs MUST be represented in binary using [I-D.draft-ietf-core-href]. For each SCITT conceptual message, we define a Data URL format according to [RFC2397], a URN format according to [RFC8141] and a URL format according to [URLs]. Note that Data URLs require base64 encoding, but the URN definitions require base64url encoding. Birkholz, et al. Expires 23 January 2025 [Page 34] Internet-Draft SCITT Architecture July 2024 Resolution and dereferencing of these identifiers is out of scope for this document, and can be implemented by any concrete api implementing the abstract interface defined as follows: resource: content-type = dereference(identifier: identifier-type) These identifiers MAY be present in a tstr field that does not otherwise restrict the string in ways that prevent a URN or URL from being present. This includes iss, and sub which are used to express the Issuer and Subject of a Signed Statement or Receipt. This also includes kid which is used to express a hint for which public key should be used to verify a signature. All SCITT identifiers share common parameters to promote interoperability: Let hash-name be an algorithm name registered in [IANA.named-information]. To promote interoperability, the hash-name MUST be "sha-256". Let base-encoding, be a base encoding defined in [RFC4648]. To promote interoperability, the base encoding MUST be "base64url". In the blocks and examples that follow, note '' line wrapping per RFC 8792. B.1. Identifiers For Binary Content Identifiers for binary content, such as Statements, or even Artifacts themselves are computed as follows: Let the base64url-encoded-bytes-digest for the message be the base64url encoded digest with the chosen hash algorithm of bytes / octets. Let the SCITT name for the message be the URN constructed from the following URI template, according to [RFC6570]: Let the message-type, be "statement" for Statements about Artifacts. Birkholz, et al. Expires 23 January 2025 [Page 35] Internet-Draft SCITT Architecture July 2024 urn:ietf:params:scitt:\ {message-type}:\ {hash-name}:{base-encoding}:\ {base64url-encoded-bytes-digest} B.2. Identifiers For SCITT Messages Identifiers for COSE Sign 1 based messages, such as identifiers for Signed Statements and Receipts are computed as follows: Let the base64url-encoded-to-be-signed-bytes-digest for the message be the base64url encoded digest with the chosen hash algorithm of the "to-be-signed bytes", according to Section 8.1 of [RFC9052]. Let the SCITT name for the message be the URN constructed from the following URI template, according to [RFC6570]: Let the message-type, be "signed-statement" for Signed Statements, and "receipt" for Receipts. urn:ietf:params:scitt:\ {message-type}:\ {hash-name}:{base-encoding}:\ {base64url-encoded-to-be-signed-bytes-digest} Note that this means the content of the signature is not included in the identifier, even though signature related Claims, such as activation or expiration information in protected headers are included. As a result, an attacker may construct a new Signed Statement that has the same identifier as a previous Signed Statement, but has a different signature. B.3. Identifiers For Transparent Statements Identifiers for Transparent Statements are defined as identifiers for binary content, but with "transparent-statement" as the message-type. urn:ietf:params:scitt:\ {message-type}:\ {hash-name}:{base-encoding}:\ {base64url-encoded-bytes-digest} Birkholz, et al. Expires 23 January 2025 [Page 36] Internet-Draft SCITT Architecture July 2024 Note that because this identifier is computed over the unprotected header of the Signed Statement, any changes to the unprotected header, such as changing the order of the unprotected header map key value pairs, adding additional Receipts, or adding additional proofs to a Receipt, will change the identifier of a Transparent Statement. Note that because this identifier is computed over the signatures of the Signed Statement and signatures in each Receipt, any canonicalization of the signatures after the fact will produce a distinct identifier. B.4. Statements B.4.1. Statement URN urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 9: Example Statement URN B.4.2. Statement URL https://transparency.example/api/identifiers\ /urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 10: Example Statement URL B.4.3. Statement Data URL data:application/json;base64,SGVsb...xkIQ== Figure 11: Example Statement Data URL B.5. Signed Statements B.5.1. Signed Statement URN urn:ietf:params:scitt:\ signed-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 12: Example Signed Statement URN B.5.2. Signed Statement URL https://transparency.example/api/identifiers\ /urn:ietf:params:scitt:\ signed-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 13: Example Signed Statement URL Birkholz, et al. Expires 23 January 2025 [Page 37] Internet-Draft SCITT Architecture July 2024 B.5.3. Signed Statement Data URL data:application/cose;base64,SGVsb...xkIQ== Figure 14: Example Signed Statement Data URL B.6. Receipts B.6.1. Receipt URN urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 15: Example Receipt URN B.6.2. Receipt URL https://transparency.example/api/identifiers\ /urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 16: Example Receipt URL B.6.3. Receipt Data URL data:application/cose;base64,SGVsb...xkIQ== Figure 17: Example Receipt Data URL B.7. Transparent Statements B.7.1. Transparent Statement URN urn:ietf:params:scitt:\ transparent-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 18: Example Transparent Statement URN B.7.2. Transparent Statement URL https://transparency.example/api/identifiers\ /urn:ietf:params:scitt:\ transparent-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o Figure 19: Example Transparent Statement URL B.7.3. Transparent Statement Data URL data:application/cose;base64,SGVsb...xkIQ== Birkholz, et al. Expires 23 January 2025 [Page 38] Internet-Draft SCITT Architecture July 2024 Figure 20: Example Transparent Statement Data URL Appendix C. 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 Section 4.4 of [RFC9052]. Birkholz, et al. Expires 23 January 2025 [Page 39] Internet-Draft SCITT Architecture July 2024 .----+-----. | Artifact | '+-+-------' | | .-' v | .--+-------. | | Hash +-+ | '----------' | /\ '-. | / \ .----------. | +-->+ OR +-->+ Payload | v | \ / '--------+-' .+--------. | \/ | | Statement +--+ | '---------' | | | ... Producer Network ... | ... ... Issuer Network ... | | | .---------. | | Identity | (iss, x5t) | | Document +--------------------+ | `----+----` | | ^ | | .----+-------. | | | Private Key | | | '----+-------' v | | .----+---. | | | Header | | | '----+---' | v v v .-+-----------. .------+------+--. / / / \ / Sign +<------+ To Be Signed Bytes | / / \ / '-----+-------' '----------------' v .----+-------. | COSE Sign 1 | '------------' Contributors Birkholz, et al. Expires 23 January 2025 [Page 40] Internet-Draft SCITT Architecture July 2024 Orie Steele Transmute United States Email: orie@transmute.industries Orie contributed to improving the generalization of COSE building blocks and document consistency. Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Antoine Delignat-Lavaud Microsoft Research 21 Station Road Cambridge CB1 2FB United Kingdom Email: antdl@microsoft.com Cedric Fournet Microsoft Research 21 Station Road Cambridge CB1 2FB United Kingdom Email: fournet@microsoft.com Yogesh Deshpande ARM 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom Email: yogesh.deshpande@arm.com Birkholz, et al. Expires 23 January 2025 [Page 41] Internet-Draft SCITT Architecture July 2024 Steve Lasker DataTrails Seattle, WA 98199 United States Email: steve.lasker@datatrails.ai Birkholz, et al. Expires 23 January 2025 [Page 42]