An Architecture for Trustworthy and Transparent Digital Supply Chains
draft-ietf-scitt-architecture-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Henk Birkholz , Antoine Delignat-Lavaud , Cedric Fournet , Yogesh Deshpande , Steve Lasker | ||
| Last updated | 2024-11-13 (Latest revision 2024-10-15) | ||
| Replaces | draft-birkholz-scitt-architecture | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
IOTDIR Telechat review
(of
-20)
by Jason Livingood
Ready w/nits
GENART IETF Last Call review
(of
-18)
by Roni Even
Ready w/nits
HTTPDIR Early review
(of
-01)
by Darrel Miller
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-scitt-architecture-10
SCITT H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track A. Delignat-Lavaud
Expires: 17 May 2025 C. Fournet
Microsoft Research
Y. Deshpande
ARM
S. Lasker
DataTrails
13 November 2024
An Architecture for Trustworthy and Transparent Digital Supply Chains
draft-ietf-scitt-architecture-10
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 17 May 2025 [Page 1]
Internet-Draft SCITT Architecture November 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 17 May 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 . . . . . . . . . . . . . . . . . . 12
4.1.1. Registration Policies . . . . . . . . . . . . . . . . 12
4.1.2. Initialization and Bootstrapping . . . . . . . . . . 13
4.1.3. Append-only Log . . . . . . . . . . . . . . . . . . . 14
4.1.4. Adjacent Services . . . . . . . . . . . . . . . . . . 14
4.2. Signed Statements . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Signed Statement Examples . . . . . . . . . . . . . . 16
4.3. Registration . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Transparent Statements . . . . . . . . . . . . . . . . . 19
4.4.1. Validation . . . . . . . . . . . . . . . . . . . . . 22
Birkholz, et al. Expires 17 May 2025 [Page 2]
Internet-Draft SCITT Architecture November 2024
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 25
6.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 25
6.2.1. Append-only Log . . . . . . . . . . . . . . . . . . . 26
6.2.2. Availability of Receipts . . . . . . . . . . . . . . 27
6.2.3. Confidentiality and Privacy . . . . . . . . . . . . . 27
6.2.4. Cryptographic Agility . . . . . . . . . . . . . . . . 28
6.2.5. Transparency Service Client Applications . . . . . . 28
6.2.6. Impersonation . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Common Terminology Disambiguation . . . . . . . . . 33
Appendix B. Identifiers . . . . . . . . . . . . . . . . . . . . 35
B.1. Identifiers For Binary Content . . . . . . . . . . . . . 36
B.2. Identifiers For SCITT Messages . . . . . . . . . . . . . 37
B.3. Identifiers For Transparent Statements . . . . . . . . . 37
B.4. Statements . . . . . . . . . . . . . . . . . . . . . . . 38
B.4.1. Statement URN . . . . . . . . . . . . . . . . . . . . 38
B.4.2. Statement URL . . . . . . . . . . . . . . . . . . . . 38
B.4.3. Statement Data URL . . . . . . . . . . . . . . . . . 38
B.5. Signed Statements . . . . . . . . . . . . . . . . . . . . 38
B.5.1. Signed Statement URN . . . . . . . . . . . . . . . . 38
B.5.2. Signed Statement URL . . . . . . . . . . . . . . . . 38
B.5.3. Signed Statement Data URL . . . . . . . . . . . . . . 38
B.6. Receipts . . . . . . . . . . . . . . . . . . . . . . . . 39
B.6.1. Receipt URN . . . . . . . . . . . . . . . . . . . . . 39
B.6.2. Receipt URL . . . . . . . . . . . . . . . . . . . . . 39
B.6.3. Receipt Data URL . . . . . . . . . . . . . . . . . . 39
B.7. Transparent Statements . . . . . . . . . . . . . . . . . 39
B.7.1. Transparent Statement URN . . . . . . . . . . . . . . 39
B.7.2. Transparent Statement URL . . . . . . . . . . . . . . 39
B.7.3. Transparent Statement Data URL . . . . . . . . . . . 39
Appendix C. Signing Statements Remotely . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 17 May 2025 [Page 3]
Internet-Draft SCITT Architecture November 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 17 May 2025 [Page 4]
Internet-Draft SCITT Architecture November 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 signed proofs of verifiable
data-structure properties. The types of Receipts MUST support
inclusion proofs and MAY support other proof types, such as
consistency proofs.
Registration: the process of submitting a Signed Statement to a
Birkholz, et al. Expires 17 May 2025 [Page 5]
Internet-Draft SCITT Architecture November 2024
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 17 May 2025 [Page 6]
Internet-Draft SCITT Architecture November 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 17 May 2025 [Page 7]
Internet-Draft SCITT Architecture November 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 registered 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, Signed Tree Heads, and their
respective consistency proofs are checked by Relying Parties
Birkholz, et al. Expires 17 May 2025 [Page 8]
Internet-Draft SCITT Architecture November 2024
* 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-ietf-cose-merkle-tree-proofs].
Figure 1 illustrates the roles and processes that comprise a
Transparency Service independent of any one use case.
This section describes the three main roles and associated processes
in SCITT:
* Issuers that use their credentials to create Signed Statements
about Artifacts
* Transparency Services that evaluate Signed Statements against
Registration Policies, producing Receipts upon successful
Registration. The returned Receipt may be combined with the
Signed Statement to create a Transparent Statement.
* Relying Parties that:
- collect Receipts of Signed Statements for subsequent
registration of Transparent Statements;
- retrieve Transparent Statements for analysis of Statements
about Artifacts themselves (e.g. verification);
- or replay all the Transparent Statements to check for the
consistency of the Transparency Service's Append-only Log (e.g.
auditing)
Birkholz, et al. Expires 17 May 2025 [Page 9]
Internet-Draft SCITT Architecture November 2024
In addition, Figure 1 illustrates multiple Transparency Services and
multiple Receipts as a single Signed Statement MAY be registered with
one or more Transparency Service. Each Transparency Service produces
a Receipt, which may be aggregated in a single Transparent Statement,
demonstrating the Signed Statement was registered by multiple
Transparency Services.
The arrows indicate the flow of information.
Birkholz, et al. Expires 17 May 2025 [Page 10]
Internet-Draft SCITT Architecture November 2024
+------------+
.----------. | Issuer |
| Artifact | +-+--------+-+
'----+-----' v v
v .--------+-. .-+--------.
.----+----. / sign / / verify /
| Statement | '-----+----+ '------+---+
'----+----' | |
| .--------' '--. |
| | | |
v v | .-' '-.
.----+---+---. | | |
| Signed | | | |
| Statement | | | |
'------+-----' v v |
| +---+-------+---+ |
.--' '----------->+ Transparency | |
| .--------. | | |
| | Receipt +<---+ Service +-+ |
| | +. +--+------------+ | |
| '-+------' | | Transparency | |
| | Receipt +<----+ | |
| '------+' | Service | |
'-------. .-' +------------+-+ |
| | |
v | |
.-----+-----. | |
| Transparent | | |
| Statement | | |
'--+--------' | |
| | |
|'-----------. .----------)--'
| | | |
| v v |
| .--------+-+---------. |
| / Verify Transparent / |
| / Statement / |
| '----+---------------+ |
| | Relying Party | |
| +---------------+ |
v v
.-------+-------------. .----------+------.
/ Collecting Receipts / / Replay Log /
'-----+---------------+ '-+---------------+
| Relying Party | | Relying Party |
+---------------+ +---------------+
Figure 1: Relationship of Concepts in SCITT
Birkholz, et al. Expires 17 May 2025 [Page 11]
Internet-Draft SCITT Architecture November 2024
The subsequent sections describe the main concepts, namely
Transparency Service, Signed Statements, Registration, and
Transparent Statements in more detail.
4.1. Transparency Service
Transparency Services MUST feature an Append-only Log. The Append-
only Log is the verifiable data structure that records registered
Signed Statements and supports the production of Receipts.
All Transparency Services MUST expose APIs for the Registration of
Signed Statements and issuance of Receipts.
Transparency Services MAY support additional APIs for auditing, for
instance, 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 maintain a list of trust anchors (see
definition of trust anchor in [RFC4949]). Transparency Services MUST
authenticate signed statements as part of a Registration Policy. For
instance, a trust anchor could be an X.509 root certificate, a
pointer to an OpenID Connect identity provider, or any other COSE-
compatible trust anchor.
Registration Policies and trust anchors MUST be made transparent and
available to all Relying Parties of the Transparency Service by
registering them as Signed Statements on the 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 17 May 2025 [Page 12]
Internet-Draft SCITT Architecture November 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 certification path from an
Issuer's certificate to one of the root certificates most recently
registered as a trust anchor by the Transparency Service.
The protected header of the COSE_Sign1 Envelope MUST include either
the Issuer's certificate as x5t or the chain including the Issuer's
certificate as x5chain. If x5t is included in the protected header,
an x5chain with a leaf certificate corresponding to the x5t value MAY
be included in the unprotected header.
The Transparency Service MUST apply the Registration Policy that was
most recently 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
Birkholz, et al. Expires 17 May 2025 [Page 13]
Internet-Draft SCITT Architecture November 2024
* An out-of-band authenticated management interface
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.
Birkholz, et al. Expires 17 May 2025 [Page 14]
Internet-Draft SCITT Architecture November 2024
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.
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
protected header) for different Artifacts, or sign all Signed
Statements under the same key.
Birkholz, et al. Expires 17 May 2025 [Page 15]
Internet-Draft SCITT Architecture November 2024
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.
At least one identifier representing one credential MUST be included
in the protected header of the COSE Envelope, as one of x5t, x5chain
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 either x5t or x5chain
in the protected header is REQUIRED to implement.
* Support for kid in the protected header and x5chain in the
unprotected header is OPTIONAL to implement.
When x5t or x5chain is present in the protected header, iss MUST be a
string that meets URI requirements defined in [RFC8392]. The iss
value's length MUST be between 1 and 8192 characters in length.
The kid header parameter MUST be present when neither x5t nor x5chain
is present in the protected header. Key discovery protocols are out-
of-scope of this document.
The protected header of a Signed Statement and a Receipt MUST include
the CWT Claims header parameter as specified in 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 2 illustrates a normative CDDL definition (see [RFC8610]) for
of the protected header and unprotected header of Signed Statements
and Receipts.
Birkholz, et al. Expires 17 May 2025 [Page 16]
Internet-Draft SCITT Architecture November 2024
This definition specifies the minimal mandatory labels.
Implementation-specific Registration Policies may define additional
mandatory labels. A Transparency Service implementation MUST reject
registering Signed Statements that do not meet their current
Registration Policy requirements. Each implementation SHOULD provide
details for their registration policies through documentation or
discovery APIs.
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 2: CDDL definition for Signed Statements and Receipts
Figure 3 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.
Birkholz, et al. Expires 17 May 2025 [Page 17]
Internet-Draft SCITT Architecture November 2024
18( / COSE Sign 1 /
[
h'a4012603...6d706c65', / Protected /
{}, / Unprotected /
nil, / Detached payload /
h'79ada558...3a28bae4' / Signature /
]
)
Figure 3: CBOR Extended Diagnostic Notation example of a Signed
Statement
Figure 4 illustrates the decoded protected header of the Signed
Statement in Figure 3. 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 4: 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 before registering Signed Statements on
behalf of one or more Issuers. Authentication and authorization
are implementation-specific and out of scope of the SCITT
architecture.
Birkholz, et al. Expires 17 May 2025 [Page 18]
Internet-Draft SCITT Architecture November 2024
2. *TS Signed Statement Verification and Validation:* The
Transparency Service MUST perform signature verification per
Section 4.4 of [RFC9052] and MUST verify the signature of the
Signed Statement with the signature algorithm and verification
key of the Issuer per [RFC9360]. The Transparency Service MUST
also check the Signed Statement includes the required protected
headers. The Transparency Service MAY validate the Signed
Statement payload in order to enforce domain specific
registration policies that apply to specific content types.
3. *Apply Registration Policy:* The Transparency Service MUST check
the attributes required by a Registration Policy are present in
the protected headers. Custom Signed Statements are evaluated
given the current Transparency Service state and the entire
Envelope, and may use information contained in the attributes of
named policies.
4. *Register the Signed Statement* to the Append-only Log.
5. *Return the Receipt*, which MAY be asynchronous from
Registration. The Transparency Service MUST be able to provide a
Receipt for all registered Signed Statements. Details about
generating Receipts are described in Section 4.4.
The last two steps may be shared between a batch of Signed Statements
registered 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.
Birkholz, et al. Expires 17 May 2025 [Page 19]
Internet-Draft SCITT Architecture November 2024
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 5 illustrates a normative CDDL definition of Transparent
Statements.
Transparent_Statement = #6.18(COSE_Sign1)
Unprotected_Header = {
&(receipts: 394) => [+ Receipt]
}
Figure 5: CDDL definition for a Transparent Statement
Figure 6 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 6: CBOR Extended Diagnostic Notation example of a
Transparent Statement
Birkholz, et al. Expires 17 May 2025 [Page 20]
Internet-Draft SCITT Architecture November 2024
Figure 7 one of the decoded Receipt from Figure 6. The Receipt
contains inclusion proofs for verifiable data structures. The
unprotected header contains verifiable data structure proofs. See
the protected header for details regarding the specific verifiable
data structure used. Per the COSE Verifiable Data Structure Registry
documented in [I-D.draft-ietf-cose-merkle-tree-proofs], the COSE key
type RFC9162_SHA256 is value 1. Labels identify inclusion proofs
(-1) and consistency proofs (-2).
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 7: CBOR Extended Diagnostic Notation example of a Receipt
Figure 8 illustrates the decoded protected header of the Transparent
Statement in Figure 6. 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 8: CBOR Extended Diagnostic Notation example of a
Receipt's Protected Header
Figure 9 illustrates the decoded inclusion proof from Figure 7. 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 17 May 2025 [Page 21]
Internet-Draft SCITT Architecture November 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 9: 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.
Birkholz, et al. Expires 17 May 2025 [Page 22]
Internet-Draft SCITT Architecture November 2024
5. Privacy Considerations
Transparency Services MAY support anonymous access. Issuers SHOULD
ensure Signed Statements submitted to public access services are
acceptable for public disclosure. Publicly accessible Signed
Statements MUST NOT carry confidential information. Once a Signed
Statement is inserted into the Append-only Log maintained by a
Transparency Service, it cannot be removed from the Log. In some
deployments, a special role, such as an Auditor, might require access
to Signed Statements.
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 17 May 2025 [Page 23]
Internet-Draft SCITT Architecture November 2024
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 their keys 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
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).
Birkholz, et al. Expires 17 May 2025 [Page 24]
Internet-Draft SCITT Architecture November 2024
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.
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.
Birkholz, et al. Expires 17 May 2025 [Page 25]
Internet-Draft SCITT Architecture November 2024
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 registered
appropriately.
Conversely, a corrupt Transparency Service may:
1. refuse or delay the Registration of Signed Statements
2. register Signed Statements that do not pass its Registration
Policy (e.g., Signed Statement with Issuer identities and
signatures that do not verify)
Birkholz, et al. Expires 17 May 2025 [Page 26]
Internet-Draft SCITT Architecture November 2024
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.
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.
Birkholz, et al. Expires 17 May 2025 [Page 27]
Internet-Draft SCITT Architecture November 2024
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.
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.
Birkholz, et al. Expires 17 May 2025 [Page 28]
Internet-Draft SCITT Architecture November 2024
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,
<https://www.rfc-editor.org/rfc/rfc9393>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cwt-claims-in-headers-10>.
[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-07, 17 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
cose-merkle-tree-proofs-07>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt>.
[IANA.named-information]
IANA, "Named Information",
<https://www.iana.org/assignments/named-information>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
Birkholz, et al. Expires 17 May 2025 [Page 29]
Internet-Draft SCITT Architecture November 2024
[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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[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, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[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, <https://www.rfc-editor.org/rfc/rfc9360>.
8.2. Informative References
[CWT_CLAIMS]
"CBOR Web Token (CWT) Claims", n.d.,
<https://www.iana.org/assignments/cwt/cwt.xhtml>.
Birkholz, et al. Expires 17 May 2025 [Page 30]
Internet-Draft SCITT Architecture November 2024
[CycloneDX]
"CycloneDX", n.d.,
<https://cyclonedx.org/specification/overview/>.
[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,
<https://doi.org/10.1145/1323293.1294280>.
[FIPS.201] "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, <https://doi.org/10.6028/nist.fips.201-3>.
[I-D.draft-ietf-core-href]
Bormann, C. and H. Birkholz, "Constrained Resource
Identifiers", Work in Progress, Internet-Draft, draft-
ietf-core-href-16, 24 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
href-16>.
[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-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[in-toto] "in-toto", n.d., <https://in-toto.io/>.
[ISO.17000.2020]
"ISO/IEC 17000:2020", n.d.,
<https://www.iso.org/standard/73029.html>.
[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,
<https://doi.org/10.6028/nist.sp.800-57pt2r1>.
Birkholz, et al. Expires 17 May 2025 [Page 31]
Internet-Draft SCITT Architecture November 2024
[MERKLE] Merkle, R., "A Digital Signature Based on a Conventional
Encryption Function", Springer Berlin Heidelberg, Lecture
Notes in Computer Science pp. 369-378,
DOI 10.1007/3-540-48184-2_32, ISBN ["9783540187967",
"9783540481843"], 1988,
<https://doi.org/10.1007/3-540-48184-2_32>.
[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,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.1800-19.pdf>.
[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,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-3.pdf>.
[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,
<https://doi.org/10.1145/571637.571640>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/rfc/rfc2397>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>.
[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, <https://www.rfc-editor.org/rfc/rfc7523>.
Birkholz, et al. Expires 17 May 2025 [Page 32]
Internet-Draft SCITT Architecture November 2024
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/rfc/rfc8141>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/rfc/rfc8725>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
[SLSA] "SLSA", n.d., <https://slsa.dev/>.
[SPDX-CBOR]
"SPDX Specification", n.d.,
<https://spdx.dev/use/specifications/>.
[SPDX-JSON]
"SPDX Specification", n.d.,
<https://spdx.dev/use/specifications/>.
[SWID] "SWID Specification", n.d.,
<https://csrc.nist.gov/Projects/Software-Identification-
SWID/guidelines>.
[URLs] "URL Living Standard", n.d.,
<https://url.spec.whatwg.org/>.
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.
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.
Birkholz, et al. Expires 17 May 2025 [Page 33]
Internet-Draft SCITT Architecture November 2024
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".
[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."
Birkholz, et al. Expires 17 May 2025 [Page 34]
Internet-Draft SCITT Architecture November 2024
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.
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:
Birkholz, et al. Expires 17 May 2025 [Page 35]
Internet-Draft SCITT Architecture November 2024
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.
urn:ietf:params:scitt:\
{message-type}:\
{hash-name}:{base-encoding}:\
{base64url-encoded-bytes-digest}
Birkholz, et al. Expires 17 May 2025 [Page 36]
Internet-Draft SCITT Architecture November 2024
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}
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.
Birkholz, et al. Expires 17 May 2025 [Page 37]
Internet-Draft SCITT Architecture November 2024
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:5i6UeR...qnGmr1o
Figure 10: Example Statement URN
B.4.2. Statement URL
https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:statement:sha-256:base64url:5i6UeR...qnGmr1o
Figure 11: Example Statement URL
B.4.3. Statement Data URL
data:application/json;base64,SGVsb...xkIQ==
Figure 12: Example Statement Data URL
B.5. Signed Statements
B.5.1. Signed Statement URN
urn:ietf:params:scitt:\
signed-statement:sha-256:base64url:5i6UeR...qnGmr1o
Figure 13: Example Signed Statement URN
B.5.2. Signed Statement URL
https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:\
signed-statement:sha-256:base64url:5i6...r1o
Figure 14: Example Signed Statement URL
B.5.3. Signed Statement Data URL
data:application/cose;base64,SGVsb...xkIQ==
Figure 15: Example Signed Statement Data URL
Birkholz, et al. Expires 17 May 2025 [Page 38]
Internet-Draft SCITT Architecture November 2024
B.6. Receipts
B.6.1. Receipt URN
urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeR...qnGmr1o
Figure 16: Example Receipt URN
B.6.2. Receipt URL
https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:receipt:sha-256:base64url:5i6UeR...qnGmr1o
Figure 17: Example Receipt URL
B.6.3. Receipt Data URL
data:application/cose;base64,SGVsb...xkIQ==
Figure 18: Example Receipt Data URL
B.7. Transparent Statements
B.7.1. Transparent Statement URN
urn:ietf:params:scitt:\
transparent-statement:sha-256:base64url:5i6UeR...qnGmr1o
Figure 19: Example Transparent Statement URN
B.7.2. Transparent Statement URL
https://transparency.example/api/identifiers\
/urn:ietf:params:scitt:\
transparent-statement:sha-256:base64url:5i6UeR...qnGmr1o
Figure 20: Example Transparent Statement URL
B.7.3. Transparent Statement Data URL
data:application/cose;base64,SGVsb...xkIQ==
Figure 21: Example Transparent Statement Data URL
Birkholz, et al. Expires 17 May 2025 [Page 39]
Internet-Draft SCITT Architecture November 2024
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 17 May 2025 [Page 40]
Internet-Draft SCITT Architecture November 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 17 May 2025 [Page 41]
Internet-Draft SCITT Architecture November 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 17 May 2025 [Page 42]
Internet-Draft SCITT Architecture November 2024
Steve Lasker
DataTrails
Seattle, WA 98199
United States
Email: steve.lasker@datatrails.ai
Birkholz, et al. Expires 17 May 2025 [Page 43]