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 13 August 2024.¶

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

This document describes the scalable, flexible, and decentralized SCITT architecture. Its goal is to enhance auditability and accountability across supply chains.¶

In supply chains, artifacts travel down the chain until they are eventually consumed by someone. Consumers like to have information about the artifacts that they consume. 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. Consumers may even publish the fact that they consume an artifact.¶

SCITT provides a way for consumers 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 consumers (also called Verifiers) can check the information.¶

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

Editor's Note:: The label "394" is expected to be reserved by this document, in the COSE Header Parameters Registry.¶

The terms "header", "payload", and "to-be-signed bytes" are defined in [RFC9052].¶

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

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

Equivocation:

a state where it is possible for a Transparency Service to provide different views of its Append-only log to Verifiers about the same Artifact [EQUIVOCATION].¶

Feed:

A collection of Receipts, as recorded by the Transparency Service, based on filtering of properties from the envelope including, but not limited to the sub field of the CWT_Claims. Verifiers may use the Feed to ensure completeness and Non-equivocation in supply chain evidence by identifying all Transparent Statements linked to the Artifact they are evaluating.¶

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

Non-equivocation:

a state where it is impossible for a Transparency Service to provide different views of its append-only log to Verifiers 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 Verifiers.¶

Receipt:

a Receipt is a cryptographic proof that a Signed Statement is recorded in the Append-only Log. Receipts are based on Signed Inclusion Proofs as described in COSE Signed Merkle Tree Proofs [I-D.draft-steele-cose-merkle-tree-proofs]. Receipts can be built on different verifiable data structures, not just binary merkle trees. 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.¶

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:

This term has the same definition as in RFC8392, which relies on the definition in RFC7519. The sub (subject) claim identifies the principal that is the subject of the CWT. The claims in a CWT are normally statements about the subject. In SCITT, sub identifies the entity about which statements, and receipts are made. The subject value MUST either be scoped to be locally unique in the context of the Issuer or be globally unique. The processing of this claim is generally application specific. The sub value is a case-sensitive string containing a StringOrURI value. Issuer's use sub to identify the entity about which they are making Signed Statements. Transparency Services use sub to identify the entity about which they are issuing a Receipt.¶

Transparency Service:

an entity that maintains and extends the Append-only Log, and endorses its state. 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.¶

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 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 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 [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 X.509 TBSCertificates (Artifacts) to produce X.509 certificates (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 Verifiers¶

• The Append-only Log can be checked by Auditors¶

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-steele-cose-merkle-tree-proofs].¶

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

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 = {
  ? &(receipts: 394)  => [+ Receipt]
}

{                                   / 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                       /
  }
}

18(                                 / COSE Sign 1                   /
    [
      h'a4012603...6d706c65',       / Protected                     /
      {},                           / Unprotected                   /
      nil,                          / Detached payload              /
      h'79ada558...3a28bae4'        / Signature                     /
    ]
)

Transparent_Statement = #6.18(COSE_Sign1)

Unprotected_Header = {
  &(receipts: 394)  => [+ Receipt]
}

18(                                 / COSE Sign 1                   /
    [
      h'a4012603...6d706c65',       / Protected                     /
      {                             / Unprotected                   /
        394: [                      / Receipts (1)                  /
          h'd284586c...4191f9d2'    / Receipt 1                     /
        ]
      },
      nil,                          / Detached payload              /
      h'79ada558...3a28bae4'        / Signature                     /
    ]
)

{                                   / 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                       /
  }
}

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                     /
    ]
)

[                                   / 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           /
  ]
]

let verify_transparent_statement(t) =
  let receipt = t.unprotected.scitt-receipt
  let version = receipt.protected.scitt-version or fail "Missing SCITT Receipt version"
  assert(version == 1)

  let leaf = COSE.serialize(t with .unprotected = {
    334 => receipt.unprotected.statement-registration-info
  })

  let vds = receipt.protected.verifiable-data-structure of fail "Missing verifiable data structure"
  let root = verify_inclusion_proof(vds, receipt.unprotected.scitt-inclusion-proof, leaf)
    or fail "Failed to verify inclusion proof"

  // Statement registration info has been authenticated by the inclusion proof
  receipt.protected.statement-registration-info = receipt.unprotected.statement-registration-info
  return COSE.verify(receipt, detached_payload=root)

5. Federation

Editor's 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.¶

For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts. Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts.¶

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

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

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

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 trusted Verifier and complies with well-known Reference Values and Endorsements.¶

8. IANA Considerations

TBD; Section 3.¶

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

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

urn:ietf:params:scitt:\
{message-type}:\
{hash-name}:{base-encoding}:\
{base64url-encoded-bytes-digest}

urn:ietf:params:scitt:\
{message-type}:\
{hash-name}:{base-encoding}:\
{base64url-encoded-to-be-signed-bytes-digest}

urn:ietf:params:scitt:\
{message-type}:\
{hash-name}:{base-encoding}:\
{base64url-encoded-bytes-digest}

urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

data:application/json;base64,SGVsb...xkIQ==

urn:ietf:params:scitt:\
signed-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:\
signed-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

data:application/cose;base64,SGVsb...xkIQ==

urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeRzg1...qnGmr1o

https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeRzg1...qnGmr1o

data:application/cose;base64,SGVsb...xkIQ==

urn:ietf:params:scitt:\
transparent-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:\
transparent-statement:sha-256:base64url:5i6UeRzg1...qnGmr1o

data:application/cose;base64,SGVsb...xkIQ==

Appendix B. Signing Statements Remotely

Statements, such as digital artifacts or structured data regarding 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].¶

Contributors

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

Authors' Addresses