An Architecture for Trustworthy and Transparent Digital Supply Chains

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 25 April 2024.¶

Copyright Notice

Copyright (c) 2023 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

This document describes a scalable and flexible, decentralized architecture to enhance auditability and accountability across various existing and emerging supply chains. It achieves this goal by enforcing the following complementary security guarantees:¶

1. Statements made by Issuers about supply chain Artifacts must be identifiable, authentic, and non-repudiable¶

2. Such Statements must be registered on a secure Append-only Log, enabling provenance and history to be independently and consistently audited¶

3. Issuers can efficiently prove to any other party the Registration of their Signed Statements; verifying this proof ensures that the Issuer is consistent and non-equivocal when producing Signed Statements¶

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 immutable, Append-only Log. The next guarantee is achieved by implementing the Append-only Log using a verifiable data structure (such as a Merkle Tree [MERKLE]). Lastly, the Transparency Service verifies the identity of the Issuer, and conformance to a Registration Policy associated with the instance of the Transparency Service. As the Issuer of the Signed Statement and conformance to the Registration Policy are confirmed, an endorsement is made as the Signed Statement is added to the Append-only Log.¶

The guarantees and techniques used in this document generalize those of Certificate Transparency [RFC9162], which can be re-interpreted as an instance of this architecture for the supply chain of X.509 certificates. However, the range of use cases and applications in this document is broader, which requires more flexibility in how each Transparency Service is implemented and operates.¶

Each service MAY enforce its own Registration Policies for authorizing entities to register their Signed Statements to the Append-only Log. Some Transparency Services may also enforce authorization policies limiting who can write, read and audit the Append-only Log. It is critical to provide interoperability for all Transparency Services instances as the composition of supply chain entities is ever-changing. It is implausible to expect all participants to choose a single vendor or Append-only Log.¶

A Transparency Service provides visibility into Signed Statements associated with various supply chains and their sub-systems. The Signed Statements (and inner payload) make claims about the Artifacts produced by a supply chain. A Transparency Service endorses specific and well-defined metadata about Artifacts which are captured in the envelope of the Statements. Some metadata is selected (and signed) by the Issuer ("who issued the Statement", "what type of Artifact is described", "what is the Artifact's version"). Whereas additional metadata is selected (and countersigned) by the Transparency Services ("when was the Signed Statement about an Artifact registered in the Transparency Service", "which registration policy was used"). Evaluating and Registering a Signed Statement, adding it to the Append-only Log, and producing a Transparent Statement is considered a form of counter-signed notarization.¶

A Statements payload content is always opaque and MAY be encrypted when submitted to the Transparency Services. However the header metadata MUST be transparent in order to warrant trust for later processing.¶

Transparent Statements provide a common basis for holding Issuers accountable for the Statement payload about Artifacts they release. Multiple Issuers may Register additional Signed Statements about the same Artifact, but they cannot delete or alter Signed Statements previously added to the Append-only Log. The ability for the original Issuer to make additional Statements about an Artifact provides for updated information to be shared, such as new positive or negative validations of quality. The ability of other Issuers to make Statements about an Artifact, produced from another Issuer, provides for third party validations. A Transparency Service may restrict access to Signed Statements through access control or Registration policies. However, third parties (such as Auditors) would be granted access as needed to attest to the validity of the Artifact, Subject or the entirety of the Transparency Service. Independent third parties may also make Statements about an Artifact, published on other Transparency Services.¶

Trust in the Transparency Service itself is supported both by protecting their implementation (using replication, trusted hardware, and remote attestation of a system's operational state) and by enabling independent audits of the correctness and consistency of its Append-only Log, thereby holding the organization that operates it accountable. Unlike CT, where independent Auditors are responsible for enforcing the consistency of multiple independent instances of the same global Transparency Service, each Transparency Service is required to guarantee the consistency of its own Append-only Log (through the use of a consensus algorithm between replicas of the Transparency Service), but assume no consistency between different Transparency Services.¶

Breadth of verifier access is critical. As a result, the Transparency Service specified in this architecture caters to two types of audiences:¶

1. Issuers: organizations, stakeholders, and users involved in creating or attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers¶

2. Verifiers: organizations, stakeholders, consumers, and users involved in validating supply chain artifacts, but can only do so if the Statements are known to be authentic. Verifiers MAY be Issuers, providing additional Signed Statements, attesting to conformance of various compliance requirements.¶

The Issuer of a Signed Statement must be authenticated and authorized according to the Registration Policy of the Transparency Service. Analogously, Transparent Statement Verifiers rely on verifiable trustworthiness assertions associated with Transparent Statements and their processing provenance in a believable manner. If trust can be put into the operations that record Signed Statements in a secure, Append-only Log via online operations, the same trust can be put into the resulting Transparent Statement, issued by the Transparency Services and that can be validated in offline operations.¶

The Transparency Services specified in this architecture are language independent and can be implemented alongside or within existing services.¶

The interoperability guaranteed by the Transparency Services is enabled via core components (architectural constituents). Many of the data elements processed by the core components are based on the CBOR Signing and Encryption (COSE) standard specified in [RFC9052], which is used to produce Signed Statements about Artifacts and to build and maintain a Merkle tree that functions as an Append-only Log for corresponding Signed Statements.¶

2. Use Cases

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.¶

Detailed use cases are maintained in a separate document [I-D.ietf-scitt-software-use-cases].¶

3. 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.¶

Append-only Log (converges Ledger and Registry):

the verifiable append-only data structure that stores Signed Statements in a Transparency Service often referred to by the synonym, Registry, Log or Ledger. SCITT supports multiple Log and Receipt formats to accommodate different Transparency Service implementations, such as historical Merkle Trees and sparse Merkle Trees.¶

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.¶

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).¶

Feed:

see Subject¶

Issuer:

organizations, stakeholders, and users involved in creating or attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers. An Issuer may be the owner or author of Artifacts, or an independent third party such as an auditor, reviewer or an endorser.¶

Receipt:

a Receipt is a cryptographic proof that a Signed Statement is recorded in the Append-only Log. Receipts are based on COSE Signed Merkle Tree Proofs [I-D.draft-steele-cose-merkle-tree-proofs]. Receipts consist of Transparency Service-specific inclusion proofs, a signature by the Transparency Service of the state of the Append-only Log, 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. A Transparency Service MAY implement any range of policies that meets their needs. However a Transparency Service can not alter the contents of the Signed Statements.¶

Registry:

See Append-only Log¶

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:

(Previously named Feed) a logical collection of Statements about the same Artifact. For any step or set of steps in a supply chain there may be multiple statements made about the same Artifact. Issuers use Subject to create a coherent sequence of Signed Statements about the same Artifact and Verifiers use the Subject to ensure completeness and non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the one(s) they are evaluating. In SCITT, Subject is a property of the dedicated, protected header attribute 13: CWT_Claims within the protected header of the COSE envelope.¶

Transparency Service:

an entity that maintains and extends the Append-only Log, and endorses its state. A Transparency Service MAY implement a Registration Policy, often referred to by its synonym Notary. A Transparency Service can be a complex distributed system, and SCITT requires 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 Verifiers 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.¶

Verifier:

organizations, stakeholders, and users involved in validating supply chain Artifacts. Verifiers consume 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.¶

4. 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 that countersigns the Signed Statement and witnesses its inclusion in the Append-only Log of a Transparency Service. By extension, the document may say an Artifact (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 Verifiers 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 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. Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements).¶

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 of separate Transparency Services are generally disjoint, though it is possible to take a Transparent Statement from one Transparency Service and register it again on another (if its policy allows), so the authorization of the Issuer and of the Transparency Service by the Verifier of the Receipt are generally independent.¶

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. Some Append-only Log formats may also support consistency auditing (Section 5.2.3.2) through Receipts, that is, given two valid Receipts the Transparency Service may be asked to produce a cryptographic proof that they are consistent. Failure to produce this proof can indicate that the Transparency Services operator misbehaved.¶

5. 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 Merkle Tree Proof. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document [I-D.draft-steele-cose-merkle-tree-proofs].¶

This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement issuance process, Transparency Service and the Signed Statement Registration process, as well as Verifiers of the Transparent Statements and the Receipt validation process.¶

CWT_Claims = {
  1 => tstr; iss, the issuer making statements,
  2 => tstr; sub, the subject of the statements,
  * tstr => any
}

Protected_Header = {
  1   => int             ; algorithm identifier,
  4   => bstr            ; Key ID (kid),
  13  => CWT_Claims      ; CBOR Web Token Claims,
  393 => Reg_Info        ; Registration Policy info,
  3   => tstr            ; payload type
}

resolve = (id: string, accept: \
  content_type = 'application/did+json') =>
  idDocument (of content type application/did+json)

did:example:123

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "#key-42",
    "type": "JsonWebkey",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "LCeAt2sW36j94wuFP0gN...Ler3cKFBCaAHY1svmbPV69bP3RH",
      "y": "zz2SkcOGYM6PbYlw19tc...rd8QWykAprstPdxx4U0uScvDcYd"
    }
  }]
}

{
  "keys": [
    {
      "alg": "RS256",
      "kty": "RSA",
      "use": "sig",
      "n": "wW9TkSbcn5FV3iUJ-812sqTvwT...YzXrnMZ7WgbMPXmHU8i4z04zw",
      "e": "AQAB",
      "kid": "NTBGNTJEMDc3RUE3RUVEOTM4NDcEFDNzEyOTY5NDNGOUQ4OEU5OA",
      "x5t": "NTBGNTJEMDc3RUE3RUVEOTM4NDcEFDNzEyOTY5NDNGOUQ4OEU5OA",
      "x5c": [
        "MIIDCzCCAfOgAwIBAgIPng0XRWwsd...f5GOGwJS+u/nSYvqCFt57+g3R+"
      ]
    },
    {
      "alg": "RS256",
      "kty": "RSA",
      "use": "sig",
      "n": "ylgVZbNR4nlsU_AbU8Zd7ZhVfm...fo5BLa3_YLWazqcpWRXn9QEDWw",
      "e": "AQAB",
      "kid": "aMIKy_brQk3nLd0PKd9ln",
      "x5t": "-xcTyx47q3ddycG7LtE6QCcETbs",
      "x5c": [
        "MIIC/TCCAeWgAwIBAgIJH62ygzAPG...xCxmHAbK+KdTka/Yg2MadFZdA=="
      ]
    }
  ]
}

dereference = (id: string, accept: \
  content_type = 'application/jwk+json') =>
  publicKeyJwk (of content type application/jwk+json)

did:example:123#key-42

{
  "kty": "EC",
  "crv": "P-384",
  "alg": "ES384",
  "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh...er3cKFBCaAHY1svmbPV69bP3RH",
  "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYH...d8QWykAprstPdxx4U0uScvDcYd"
}

6. Signed Statement Issuance, Registration, and Verification

This section details the interoperability requirements for implementers of Signed Statements issuance and validation libraries, and of Transparency Services.¶

Signed_Statement = COSE_Sign1_Tagged

COSE_Sign1_Tagged = #6.18(COSE_Sign1)

COSE_Sign1 = [
  protected   : bstr .cbor Protected_Header,
  unprotected : Unprotected_Header,
  payload     : bstr,
  signature   : bstr
]

CWT_Claims = {
  1 => tstr; iss, the issuer making statements,
  2 => tstr; sub, the subject of the statements,
  * tstr => any
}

Reg_Info = {
  ? "register_by": uint .within (~time),
  ? "sequence_no": uint,
  ? "issuance_ts": uint .within (~time),
  ? "no_replay": null,
  * tstr => any
}

Protected_Header = {
  1   => int             ; algorithm identifier,
  4   => bstr            ; Key ID,
  13  => CWT_Claims      ; CBOR Web Token Claims,
  393 => Reg_Info        ; Registration Policy info,
  3   => tstr            ; payload type
}

Unprotected_Header = {
  ; TBD, Labels are temporary,
  ? 394 => [+ Receipt]
}

Receipt = [
    version: int,
    ts_identifier: tstr,
    proof: SignedMerkleTreeProof
]

; Additional protected headers
; in the COSE signed_tree_root of the SignedMerkleTreeProof
Protected_Header = {
  390 => int         ; SCITT Receipt Version
  394 => tstr        ; DID of Transparency Service (required)
  ? 393 => Reg_info  ; Registration policy information (optional)

  ; Other COSE Signed Merkle Tree headers
  ; (e.g. tree algorithm, tree size)

  ; Additional standard COSE headers
  2 => [+ label]     ; Critical headers
  ? 4 => bstr        ; Key ID (optional)
  ? 33 => COSE_X509  ; X.509 chain (optional)
}

; Details of the registration info, as provided by the TS
RegistrationInfo = {
  ? "registration_time": uint .within (~time),
  * tstr => any
}

7. Federation

Note: This topic is still under discussion, see issue 79¶

Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single, centralized service trusted by all parties. For example, multiple Transparency Service instances may be governed and operated by different organizations that are either unaware of the other or do not trust one another.¶

This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration Policy. This may also involve attaching multiple Receipts to the same Signed Statements, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each Transparency Service verifying prior Receipts as part of their Registration Policy.¶

For example, a supplier may provide a complete, authoritative Transparency Service for its Signed Statements, whereas a Verifiers's Transparency Service may collect different kinds of Signed Statements to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these Signed Statements.¶

An independent entities (security companies) may Issue statements of quality about different artifacts on their own Transparency Service. Verifiers choose which independent entities they trust, just as entities choose different security companies today.¶

8. Transparency Service API

{
  "type": "urn:ietf:params:scitt:error:badSignatureAlgorithm",
  "detail": "The Statement was signed with an unsupported algorithm"
}

POST <Base URL>/entries

GET <Base URL>/operations/<Operation ID>

GET <Base URL>/entries/<Entry ID>

GET <Base URL>/entries/<Entry ID>/receipt

9. Privacy Considerations

Unless advertised by a Transparency Service, every Issuer must treat Signed Statements it registered (rendering them as Transparent Statements) as public. In particular, a Signed Statement Envelope and Statement payload MUST NOT carry any private information in plaintext.¶

10. 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 Verifier trusts the Issuer, 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 Verifier 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 Verifier 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 13 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 Verifiers 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.¶

11. IANA Considerations

TBD; Section 4.¶

   Registry name:  scitt

   Specification:  [RFCthis]

   Repository:  http://www.iana.org/assignments/scitt

   Index value:  No transformation needed.

Contributors

Orie contributed to improving the generalization of COSE building blocks and document consistency.¶

Authors' Addresses