RFC 9943
An Architecture for Trustworthy and Transparent Digital Supply Chains
RFC 9943 ✨ An Architecture for Trustworthy and Transparent Digital Supply Chains
📜 RFC 9943 is an Internet Standards Track document from the IETF, dated June 2026 (ISSN 2070-1721). It's written by H. Birkholz (Fraunhofer SIT), A. Delignat-Lavaud, C. Fournet (listed with Microsoft), Y. Deshpande (ARM), and S. Lasker. Its header doesn't list any RFCs it obsoletes or updates. 🧚
Abstract
Okay so traceability in supply chains is becoming a big security concern 😭 Verifiable Data Structures (VDSs) have already handled specific problems, like equivocation over digital certificates, but there's no universal architecture that works for all supply chains. This document sets one up for single-issuer signed statement transparency 🔥 The goal is extensibility and interoperability between different transparency services, plus compliance with various auditing procedures and regulatory requirements. Main character energy 💅
Status of This Memo
This is an Internet Standards Track document 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841 ✨
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9943 🦋
Copyright Notice
Copyright (c) 2026 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. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Revised BSD License 🫶
Table of Contents
1. Introduction
1.1. Requirements Notation
2. Software Supply Chain Scope
2.1. Generic SSC Problem Statement
2.2. Eclectic SSC Use Cases
2.2.1. Security Analysis of a Software Product
2.2.2. Promotion of a Software Component by Multiple Entities
2.2.3. Software Integrator Assembling a Software Product for a
Vehicle
3. Terminology
4. Definition of Transparency
5. Architecture Overview
5.1. Transparency Service
5.1.1. Registration Policies
5.1.2. Initialization and Bootstrapping
5.1.3. Verifiable Data Structure
5.1.4. Adjacent Services
6. Signed Statements
6.1. Signed Statement Examples
6.2. Signing Large or Sensitive Statements
6.3. Registration of Signed Statements
7. Transparent Statements
7.1. Validation
8. Privacy Considerations
9. Security Considerations
9.1. Ordering of Signed Statements
9.2. Accuracy of Statements
9.3. Issuer Participation
9.4. Key Management
9.4.1. Verifiable Data Structure
9.4.2. Key Compromise
9.4.3. Bootstrapping
9.5. Implications of Media Type Usage
9.6. Cryptographic Agility
9.7. Threat Model
10. IANA Considerations
10.1. Registration of application/scitt-statement+cose
10.2. Registration of application/scitt-receipt+cose
10.3. CoAP Content-Format Registrations
11. References
11.1. Normative References
11.2. Informative References
Contributors
Authors' Addresses1. Introduction ✨
This document defines an architecture, a base set of extensible message structures, and the flows that go with them, all so signed content can be made transparent through VDSs run by matching transparency services 🧚 The whole point of the transparency that the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture enables is to boost auditability and accountability for single-issuer signed content (statements) about supply chain commodities (artifacts) 💜
Registering a signed statement with a Transparency Service (TS) is basically a notarization procedure 📜 The TS confirms that a policy is met before it records the statement on the ledger. The SCITT ledger is a linear and irrevocable history of the statements made, so once a signed statement is registered, the TS issues a receipt 🔥
Similar approaches already exist for specific kinds of artifacts, like Certificate Transparency (CT) [RFC9162]. SCITT takes a more generic route. This "content-agnostic" approach means a TS can either plug into existing solutions or form the starting piece of brand-new systems 🌈 Extensibility is a vital part of the SCITT architecture, so requirements from all sorts of applications can fit in while interoperability is still guaranteed for registration procedures, plus the auditability and accountability that come with them 💅 To keep things simple, this document only covers use cases from the software supply chain domain. That said, the spec applies to any other kind of supply chain statement (also called "value-add graphs"), like statements about hardware supply chains 🦋
This document also defines message structures for signed statements and transparent statements. These embed CBOR Object Signing and Encryption (COSE) receipts [RFC9942], which are signed Verifiable Data Structure Proofs (VDP) 🎀 The message structures are based on the Concise Binary Object Representation (CBOR) Standard [STD94], and signing runs through the COSE Standard [STD96]. They're defined using the Concise Data Definition Language (CDDL) [RFC8610]. The signed statements are based on the COSE_Sign1 specification in Section 4.2 of RFC 9052 [STD96], and the receipts are based on COSE receipts [RFC9942]. Two things make the message layer interoperable: COSE_Sign1 doesn't depend on any application domain, and it can be extended with COSE header parameters 🫶
Put simply, this spec lets relying parties get proof that signed statements were recorded and checked for validity when they were registered ✨ How those statements get managed or stored, and how the participating entities discover and notify each other about changes, is out of scope for this document 🌸
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. Software Supply Chain Scope 🍓
To show how the SCITT architecture and its messages apply in practice, this section walks through the example context of Software Supply Chain (SSC) use cases 💅 The building blocks SCITT provides aren't limited to SSC use cases. SSCs are just a useful application guide and the first usage scenarios 👑
2.1. Generic SSC Problem Statement ✨
okay so supply chain security is basically a prerequisite 💅 if we don't have it, consumers get hurt and we get economic, public health, and safety threats, and nobody wants that bestie 😭 Historically, supply chain security has been all about risk management: keeping logistics safe, meeting regulations, forecasting demand, and optimizing inventory 📦 Those things are foundational and honestly iconic, but an integrated cyber-security perspective on SSCs is still pretty much undefined 🙈 Meanwhile the world has been hit by a bunch of supply chain attacks that went straight for weak spots in SSCs, and it's giving chaos 💀 As Figure 1 shows, an SSC attack can use one or more life-cycle stages and can hit the component directly or indirectly 🎯
Dependencies Malicious third-party package or version
|
|
+-----+-----+
| |
| Code | Compromise source control
| |
+-----+-----+
|
+-----+-----+
| | Malicious plug-ins
| Commit | Malicious commit
| |
+-----+-----+
|
+-----+-----+
| | Modify build tasks or the build environment
| Build | Poison the build agent/compiler
| | Tamper with build cache
+-----+-----+
|
+-----+-----+
| | Compromise test tools
| Test | Falsification of test results
| |
+-----+-----+
|
+-----+-----+
| | Use bad packages
| Package | Compromise package repository
| |
+-----+-----+
|
+-----+-----+
| | Modify release tasks
| Release | Modify build drop prior to release
| |
+-----+-----+
|
+-----+-----+
| |
| Deploy | Tamper with versioning and update process
| |
+-----------+
Figure 1: Example SSC Life-Cycle ThreatsDevSecOps, as defined in [NIST.SP.800-204C], often leans heavily on third-party and open-source software 🧩 Those dependencies can get really complicated across the whole supply chain, which makes checking provenance and traceability across their life cycle pretty difficult 😩 So there's a real need for auditability and accountability of digital products that's actually manageable 🦋 The kinds of statements people make about digital products (and their dependencies) are super varied and messy, and they can differ depending on community policy requirements 🌈 Taking the type and structure of every single statement into account might not be possible, honestly 🫠 Some examples of these statements are commit signatures, build environment and parameters, Software Bill of Materials (SBOM), static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs 📝 So instead of trying to pin down the detailed syntax and semantics of every type of statement, the SCITT architecture focuses on ensuring statement authenticity, ensuring visibility/transparency, and intending to provide scalable accessibility 💜 Security techniques can also cause problems when they get used outside their proper bounds, which is an unintended side effect that's lowkey wild ⚠️ For example, a digital signature may fail to verify once it's past its expiry date even though the signed item is still completely valid 🥲 Or a signature may still verify even though the information it's protecting has become unreliable, but fine-grained revocation is too hard to do 😵💫
Lastly, when data exchange is what underpins serious business decision-making, the producers of that data need to be held to a higher standard of auditability 👑 The SCITT architecture gives us mechanisms and structures so that the makers of authoritative statements can be held accountable and can't hide or shred the evidence when it gets inconvenient later 🔥
The following use cases show what SCITT is all about and expand on the generic problem statement above 🎀
2.2. Eclectic SSC Use Cases 🌸
The three use cases below are a specialization of the generic problem statement above 💖
2.2.1. Security Analysis of a Software Product
A released software product usually comes with a set of complementary statements about its security properties 🛡️ That gives producers and consumers enough confidence that the released software meets the expected security standards and is suitable to use ✨
Then, multiple security researchers often run sophisticated security analysis tools on the same product 🔍 The goal is to find any security weaknesses or vulnerabilities in the package, no cap 🧐
At first, a particular analysis might identify a simple weakness in a software component 🫤 Over time, a statement from a third party shows that the weakness is exposed in a way that counts as an exploitable vulnerability 😬 The producer of the software product then issues a statement confirming that the software component vulnerability is linked to the product, by putting out a product vulnerability disclosure report and an advisory statement on how to mitigate it 📣 At first, the producer ships an updated product that still uses the vulnerable component but shields the issue in a way that stops it from being exploited 🛡️ Later, a second update includes a security patch to the affected component from the producer 🩹 Finally, a third update includes a new release (an updated version) of the formerly insecure component 🦋 At that point, both the software product and the affected component are deemed secure by the producer and consumers alike 🥹💅
A consumer of a released software wants to:
- know where to get these security statements from producers and third parties related to the software product in a timely and unambiguous fashion
- attribute them to an authoritative issuer
- associate the statements in a meaningful manner via a set of well-known semantic relationships
- consistently, efficiently, and homogeneously check their authenticity
SCITT provides a standardized way to:
- know the various sources of statements
- express the provenance and historicity of statements
- relate and link various heterogeneous statements in a simple fashion
- check that the statement comes from a source with authority to issue that statement
- confirm that sources provide a complete history of statements related to a given component
2.2.2. Promotion of a Software Component by Multiple Entities
A software component (e.g., a library or software product), open-source or commercial, is often first released by a single trusted producer who can choose to attach a statement of authenticity to it 🌟 As that component gets used in a growing range of other products, providers other than the original trusted producer often re-distribute or release their own version of it 🌍
Some providers bundle it into their release product or package and give the package proof of authenticity using their issuer authority 🎁 Some packages include the original statement of authenticity, and some don't 🤷♀️ Over time, some providers stop offering the exact same component source code and offer pre-compiled component binaries instead 🧱 Some sources don't provide the exact same component but include patches and fixes made by third parties, because those show up faster than solutions from the original producer 🏃♀️💨 With complex distribution and promotion life cycles, the original component ends up taking on myriad forms 🌀
A consumer of a released software wants to:
- understand if a particular provider is a trusted originating producer or an alternative party
- know if and how the source, or resulting binary, of a promoted software component differs from the original software component
- check the provenance and history of a software component's source back to its origin
- assess whether to trust a component or product based on a downloaded package location and source supplier
SCITT provides a standardized way to:
- reliably discern if a provider is the original, trusted producer or is a trustworthy alternative provider or is an illegitimate provider
- track the provenance path from an original producer to a particular provider
- check the trustworthiness of a provider
- check the integrity of modifications or transformations applied by a provider
2.2.3. Software Integrator Assembling a Software Product for a Vehicle
Software integration is a seriously complex activity 🧠 It usually means getting various software components from multiple suppliers and producing an integrated package that gets deployed as part of device assembly 🔧 For example, car manufacturers source integrated software for their vehicles from third parties, and those third parties integrate software components from all sorts of sources 🚗 That integration complexity raises the risk of security vulnerabilities in the delivered software 😰
Consumers of integrated software want:
- a list of all components present in a software product
- the ability to identify and retrieve all components from a secure and tamper-proof location
- verifiable proofs on build process and build environment with all supplier tiers to ensure end-to-end build quality and security
SCITT provides a standardized way to:
- provide a tiered and transparent framework that allows for verification of integrity and authenticity of the integrated software at both component and product level before installation
- provide valid annotations on build integrity to ensure conformance 🌈
3. Terminology ✨
okay bestie, this is the glossary section, and these are the SCITT words we use everywhere else in the doc 💅 they have special meanings here, so don't just vibe off the everyday definitions 🙈
This document was developed in coordination with the COSE, OAUTH, and RATS working groups (WGs) and uses terminology common to these WGs as often as possible 🫶
The terms "header", "payload", and "to-be-signed bytes" are defined in [STD96]. The term "claim" is defined in [RFC8392].
When a term is used in the sense defined here, it gets capitalized. To keep things readable, we only include a core set of terms in this section 🌸
- Append-only Log: a Statement Sequence comprising the entire registration history of the TS. To make the append-only property verifiable and transparent, the TS defines how Signed Statements are made available to Auditors. 📜
- Artifact: a physical or non-physical item that is moving along a supply chain. 📦
- Attestation: [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" [NIST_EO14028] uses the definition from [ISO_IEC_17000], which states that an "attestation" is:
The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.
It is often useful for the intended audience to qualify the term "attestation" in their specific context to avoid confusion and ambiguity. 🙃
- Auditor: an entity that checks the correctness and consistency of all Transparent Statements, or the transparent Statement Sequence, issued by a TS. An Auditor is an example of a specialized Relying Party. 🕵️♀️
- Client: an application making protected TS 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 TS Registration Policies to validate the Signed Statement. A Signed Statement is a COSE Envelope wrapped around a Statement, binding the metadata in the Envelope to the Statement. In COSE, an Envelope consists of a protected header (included in the Issuer's signature) and an unprotected header (not included in the Issuer's signature). 💌
- Equivocation: a state where a TS provides inconsistent proofs to Relying Parties, containing conflicting claims about the Signed Statement bound at a given position in the VDS. 🚩 [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 endorser. In SCITT Statements and Receipts, the
issClaim is a member of the COSE header parameter 15: CWT Claims defined in [RFC9597], which embeds a CBOR Web Token (CWT) Claims Set [RFC8392] within the protected header of a COSE Envelope. 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 JSON Object Signing and Encryption (JOSE) and COSE, and the guidance in [RFC8725] generally applies the COSE equivalent terms with consistent semantics. 👑 - Non-equivocation: a state where all proofs provided by the TS to Relying Parties are produced from a single VDS describing a unique sequence of Signed Statements and are therefore consistent [EQUIVOCATION]. Over time, an Issuer may register new Signed Statements about an Artifact in a TS with new information. However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties. ✅
- Receipt: a COSE Single Signer Data Object as defined in [RFC9942]. See [RFC9942] for implementations. Receipts are signed proofs of VDS properties. Receipt Profiles implemented by a TS MUST support inclusion proofs and MAY support other Proof Types (see Section 3 of [RFC9942]), such as consistency proofs. 🧾
- Registration: the process of submitting a Signed Statement to a TS, applying the TS's Registration Policy, adding to the VDS, and producing a Receipt. 📝
- Registration Policy: the precondition enforced by the TS before registering a Signed Statement, based on information in the non-opaque header and metadata contained in its COSE Envelope. 🛂
- Relying Party: Relying Parties 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. 🔍
- Signed Statement: an identifiable and non-repudiable Statement about an Artifact signed by an Issuer. In SCITT, Signed Statements are encoded as Enveloped COSE Structures; the payload of the COSE structure contains the issued Statement. ✍️
- Statement: any serializable information about an Artifact. To help interpret Statements, they must be tagged with a relevant media type (as specified in [RFC6838]). A Statement may represent an SBOM that lists the ingredients of a software Artifact, contains an endorsement or attestation about an Artifact, indicates the End of Life (EOL), redirects to a newer version, or contains any content an Issuer wishes to publish about an Artifact. Additional Statements about an Artifact are correlated by the Subject Claim as defined in the "CBOR Web Token (CWT) Claims" registry [IANA.cwt] and used as a protected header parameter as defined in [RFC9597]. The Statement is considered opaque to TS and MAY be encrypted. 🎁
- Statement Sequence: a sequence of Signed Statements captured by a VDS. See Verifiable Data Structure. 🧵
- 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 thesubCWT Claim, defined in [RFC8392], to create a coherent sequence of Signed Statements about the same Artifact, and Relying Parties can leveragesubto ensure completeness and Non-equivocation across Statements by identifying all Transparent Statements associated with a specific Subject. 🧩 - Transparency Service: an entity that maintains and extends the VDS and endorses its state. The identity of a TS 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 TS. 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 TS. 🌈
- Verifiable Data Structure: a data structure defined in [RFC9942] in which Signed Statements can be inserted as they are Registered by a TS. SCITT supports multiple VDSs and Receipt formats as defined in [RFC9942], accommodating different TS implementations. 🏗️
4. Definition of Transparency 🔮
okay so this is where the "transparency" idea gets built up 🦋 it's based on abstract notions of append-only Logs and Receipts, and existing systems like CT [RFC9162] are instances of this definition. SCITT supports multiple VDSs, as defined in [RFC9942] ✨
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 TS in the form of a Receipt. Receipts demonstrate inclusion of Signed Statements in the VDS of a TS. 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 Statement 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 TS 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. Implementations of TSs may protect their registered sequence of Signed Statements and VDS using a combination of trusted hardware, consensus protocols, and cryptographic evidence. A Receipt is a signature over one or more VDP that a Signed Statement is registered in the VDS. It is universally verifiable without online access to the TS. Requesting a Receipt can result in the production of a new Receipt for the same Signed Statement. A Receipt's verification key, signing algorithm, validity period, header parameters or other claims MAY change each time a Receipt is produced. 🔁
Anyone with access to the TS can independently verify its consistency and review the complete list of Transparent Statements registered by each Issuer. 🔎
Thus, reputable Issuers are incentivized to carefully review their Statements before signing them to produce Signed Statements. Similarly, reputable TSs are incentivized to secure their VDS, as any inconsistency can easily be pinpointed by any Auditor with read access to the TS. 💅
The building blocks specified in this document enable the unequivocal and auditable production of statements about software supply chain artifacts. The extensible design of the SCITT architecture potentially allows future usage with other supply chains in different domains, for example, advanced manufacturing or food supply. 🌍
SCITT is a generalization of CT [RFC9162], which can be interpreted as a transparency architecture for the supply chain of X.509 certificates. Considering CT in terms of SCITT:
- Certificate Authorities (CAs) (Issuers) sign the ASN.1 DER-encoded
tbsCertificatestructure to produce an X.509 certificate (Signed Statements) 📜 - CAs submit the certificates to one or more CT logs (TSs) 📮
- CT logs produce Signed Certificate Timestamps (Transparent Statements) ⏱️
- Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties 🫶
- The VDS can be checked by Auditors 🕵️♀️
5. Architecture Overview ✨
okay so the SCITT architecture is giving "let's all agree on one baseline" 🫶 It gives every TS in a given application domain a shared set of common formats and protocols for issuing and registering Signed Statements and auditing Transparent Statements. 💅
To fit as many TS 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. That wrapper says who the TS is and which agility parameters apply to the signed proofs. The rest of the Receipt's contents are specified in [RFC9942]. ✨
Figure 2 shows the roles and processes that make up a TS, no matter the use case:
- Issuers that use their credentials to create Signed Statements about Artifacts.
- TSs that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration. The returned Receipt may be combined with the Signed Statement to create a Transparent Statement.
- Relying Parties that:
- collect Receipts of Signed Statements for subsequent registration of Transparent Statements;
- retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g., verification);
- or replay all the Transparent Statements to check for the consistency and correctness of the TS's VDS (e.g., auditing).
Figure 2 also shows multiple TSs and multiple Receipts, because a single Signed Statement MAY be registered with one or more TS. Each TS produces a Receipt, and those Receipts may be aggregated in a single Transparent Statement, which proves the Signed Statement was registered by multiple TSs. 🦋
The arrows show the flow of information. 🌈
.----------. +--------------+
| Artifact | | Issuer |
'----+-----' +-+----------+-+
v v v
.----+----. .-----+----. .+---------.
| Statement | / sign / / verify /
'----+----' '-----+----+ '-------+--+
| | '-------.
| .----------------------' '---------. |
| | | |
v v v |
.----+---+---. +----+----+-----+ |
| Signed +------------------------->+ Transparency | |
| Statement | .+ | |
'------+-----' .-------. | | Service +-+ |
| .---------+ Receipt +<--' +--+------------+ | |
| |.-----. | +. | Transparency | |
| | | '+------' | | | |
v v '---+ Receipt +<------+ Service | |
.--+-----+--. '-------' +--------+-----+ |
| Transparent | | |
| Statement +-------. .----------)------'
'-----+-----' | | |
v v v v
.--------+---------. .--+--------------+--. .------+----------.
/ Collect Receipts / / Verify Transparent / / Replay Log /
'--+---------------+ / Statement / '-+---------------+
| Relying Party | '----+---------------+ | Relying Party |
+---------------+ | Relying Party | +---------------+
+---------------+
Figure 2: Relationship of Concepts in SCITTThe next sections dig into the main concepts (TS, Signed Statements, Registration, and Transparent Statements) in more detail. 💜
5.1. Transparency Service
TSs MUST produce COSE Receipts [RFC9942]. 🎀
Typically, a TS has a single Issuer identity that 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 subdomain, such as "tenant1.ts.example." and "tenant2.ts.example.". 👑
5.1.1. Registration Policies
Registration Policies are the additional checks that sit on top of the mandatory Registration checks, which run before a Signed Statement is registered to the VDS. To make things auditable, TSs MUST maintain Registration Policies. Even a transparent registration policy that allows all authenticated submissions counts, because having one explicit policy makes service audits possible and makes future policy changes possible too. 🔍
Beyond the mandatory Registration checks, the scope of any additional checks is up to the implementation, and that includes having no additional checks at all. 🧚
This specification leaves the implementation, encoding, and documentation of Registration Policies and trust anchors to the operator of the TS. 💅
5.1.1.1. Mandatory Registration Checks
During Registration, a TS MUST syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to [STD96]. 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 TS MUST be checked. 🫶
TSs MUST maintain a list of trust anchors (see the definition of trust anchor in [RFC4949]) so they can check the signatures of Signed Statements, either separately or inside Registration Policies. TSs MUST authenticate Signed Statements as part of a Registration Policy. For instance, a trust anchor could be an X.509 root certificate (directly or as its thumbprint), a pointer to an OpenID Connect identity provider, or any other trust anchor that can be referenced in a COSE header parameter. 🔐
When using X.509 Signed Statements, the TS MUST build and validate a complete certification path from an Issuer's certificate to one of the root certificates currently registered as a trust anchor by the TS. 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, as defined in [RFC9360]. 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. 🌈
Registration Policies and trust anchors MUST be made Transparent and available to all Relying Parties of the TS, by Registering them as Signed Statements on the VDS. 📣
The TS MUST apply the Registration Policy that was most recently committed to the VDS at the time of Registration. ⭐
5.1.1.2. Auditability of Registration
The operator of a TS MAY update the Registration Policy or the trust anchors of a TS at any time. 🦋
TSs MUST ensure that for any Signed Statement they register, enough information is made available to Auditors to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. At a minimum, this consists of the Signed Statements themselves, any additional collateral data required to perform their authentication, and the applicable Registration Policy at the time of Registration. 🔍
5.1.2. Initialization and Bootstrapping
The mandatory Registration checks rely on having registered Signed Statements for the Registration Policy and trust anchors, so it's a bit of a chicken-and-egg situation 🐣 That's why TSs MUST support at least one of the three following bootstrapping mechanisms:
- Preconfigured Registration Policy and trust anchors;
- Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing Registration checks; or
- An out-of-band authenticated management interface.
5.1.3. Verifiable Data Structure
The security properties are determined by the choice of the VDS (see [RFC9942]) used by the TS implementation. This VDS MUST support the following security requirements: 🛡️
- Append-only: a property required for a VDS to be applicable to SCITT, ensuring that the Statement Sequence cannot be modified, deleted, or reordered.
- Non-equivocation: there is no fork in the registered sequence of Signed Statements accepted by the TS and committed to the VDS. Everyone with access to its content sees the same ordered collection of Signed Statements and can check that it is consistent with any Receipts they have verified.
- Replayability: the VDS includes sufficient information to enable authorized actors with access to its content to check that each data structure representing each Signed Statement has been correctly registered.
In addition to Receipts, some VDSs might support additional Proof Types, such as proofs of consistency or proofs of non-inclusion. 🧩
Specific VDSs, such as those described in [RFC9162] and [RFC9942], and the review of their security requirements for SCITT are out of scope for this document. 🙈
5.1.4. Adjacent Services
TSs can be deployed alongside other database or object storage technologies. For example, a TS that supports a software package management system might be referenced from the APIs exposed for package management. It can also provide the ability to request a fresh Receipt for a given software package, or a list of Signed Statements associated with that package. 📦✨
6. Signed Statements ✨
okay so this section is where Signed Statements get their whole vibe 💅 we're staying super close to [STD96] and all its required and optional properties 🫶 Signed Statements produced by Issuers must be COSE_Sign1 messages, as defined by [STD96]. Profiles and implementation-specific choices are what you use to figure out admissibility of conforming messages 🎀 and this spec is intentionally left open so implementations can make Registration restrictions that actually fit their operational use cases 🦋
There are so many kinds of Statements (an SBOM, malware scans, audit reports, policy definitions) that Issuers might wanna 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 might look like:
- Concise Software Identification Tags format [CoSWID] 💜
- Bill of Materials format [CycloneDX] 🍓
- Supply chain description metadata [in-toto] ✨
- Software component description format [SPDX] 🌸
- Supply-chain Levels for Software Artifacts [SLSA] 👑
- Software Identification Tag format [SWID] 🧚
Issuers can produce Signed Statements about different Artifacts under the same Identity 🦋 and Issuers and Relying Parties must be able to recognize which Artifact a Statement is about just by looking at the Signed Statement 👀 The iss and sub Claims, within the CWT Claims protected header, are what identify the Artifact the Statement pertains to. (See Subject in Section 3.)
Issuers MAY use different signing keys (identified by kid in the protected header from [STD96]) for different Artifacts, or sign all Signed Statements under the same key. Totally your call bestie 🔑
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. Growth arc unlocked 📈
Multiple Issuers can make different, even conflicting, Statements about the same Artifact 😭 Relying Parties get to choose which Issuers they trust. Main character decision 💅
Multiple Issuers can also make the same Statement about a single Artifact, which basically says "yep, we all agree" 🤝
Additionally, an 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. Two things here, both lowkey important:
- 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, the iss Claim value MUST be a string that meets URI requirements defined in [RFC8392]. The iss Claim value's length MUST be between 1 and 8192 characters in length. Strict but fair 🙈
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, so we're not touching that drama 🫠
The protected header of a Signed Statement and a Receipt MUST include the CWT Claims header parameter as specified in Section 2 of [RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim label 1) and the Subject Claim (Claim label 2) [IANA.cwt]. Non-negotiable energy ✨
A Receipt is a Signed Statement (COSE_Sign1) with additional Claims in its protected header related to verifying the inclusion proof in its unprotected header. See [RFC9942]. Receipts really are just Signed Statements with a little extra flair 🎀
6.1. Signed Statement Examples 🌷
Figure 3 illustrates a normative CDDL definition [RFC8610] for the protected header and unprotected header of Signed Statements and Receipts. Let's look at the blueprint 🧚
The SCITT architecture specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels, so check your policy's vibes 🫶
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
? &(x5chain: 33) => COSE_X509
* label => any
}
CWT_Claims = {
&(iss: 1) => tstr
&(sub: 2) => tstr
* label => any
}
Unprotected_Header = {
? &(x5chain: 33) => COSE_X509
? &(receipts: 394) => [+ bstr .cbor Receipt]
* label => any
}
label = int / tstr
Figure 3: CDDL Definition for Signed Statements and ReceiptsFigure 4 shows an instance of a Signed Statement in Extended Diagnostic Notation (EDN), with a payload that is detached. Detached payloads are the move for large Statements 🍓 and they let Signed Statements play nicely with existing storage systems 💖
18( / COSE_Sign1 /
[
h'a4012603...6d706c65', / Protected /
{}, / Unprotected /
nil, / Detached payload /
h'79ada558...3a28bae4' / Signature /
]
)
Figure 4: CBOR-Extended Diagnostic Notation Example of a Signed
StatementFigure 5 shows the decoded protected header of the Signed Statement in Figure 4. It's signaling that 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 5: CBOR-Extended Diagnostic Notation Example of a Signed
Statement's Protected Header6.2. Signing Large or Sensitive Statements 🔐
Statement payloads might be too large or too sensitive to send to a remote TS 😳 In these cases, a Statement can be made over the hash of a payload rather than the full payload bytes. Privacy queen behavior 👑
.----+-----.
| 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_Sign1 |
'------------'
Figure 6: Signing Large or Sensitive Statements6.3. Registration of Signed Statements 📥
To register a Signed Statement, the TS performs the following steps. It's giving checklist energy ✅
- Client Authentication
A Client authenticates with the TS 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, so that's a whole other story 🙈
- TS Signed Statement Verification and Validation
The TS MUST perform signature verification per Section 4.4 of RFC 9052 [STD96] and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per [RFC9360]. The TS MUST also check that the Signed Statement includes the required protected headers. The TS MAY validate the Signed Statement payload in order to enforce domain-specific registration policies that apply to specific content types. Double-checking, but make it iconic 💅
- Apply Registration Policy
The TS MUST check the attributes required by a Registration Policy are present in the protected headers. Custom Signed Statements are evaluated given the current TS state and the entire Envelope, and may use information contained in the attributes of named policies. Context is everything 🧠
- Register the Signed Statement
- Return the Receipt
This MAY be asynchronous from Registration. The TS MUST be able to provide a Receipt for all registered Signed Statements. Details about generating Receipts are described in Section 7. Receipt slay 🧾
The last two steps may be shared between a batch of Signed Statements registered in the VDS. Batch mode, it's giving efficiency 🚀
A TS MUST ensure that a Signed Statement is registered before releasing its Receipt. No receipt before registration, bestie 🫶
A TS MAY accept a Signed Statement with content in its unprotected header and MAY use values from that unprotected header during verification and registration policy evaluation. Flexible, but still careful 🦋
However, the unprotected header of a Signed Statement MUST be set to an empty map before the Signed Statement can be included in a Statement Sequence. Clean slate or it's not getting in the sequence 💀
The same Signed Statement may be independently registered in multiple TSs, producing multiple independent Receipts. The multiple Receipts may be attached to the unprotected header of the Signed Statement, creating a Transparent Statement. Multi-receipt glow up ✨🌈
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. Updates are a love language 💜
7. Transparent Statements ✨
Okay so bestie, here's the glow-up 🦋. A Client (not always the Issuer, fr) registers a Signed Statement and gets a Receipt back. Tuck that Receipt into the unprotected header of the Signed Statement and boom, you've got a Transparent Statement 💖. Client applications MAY register Signed Statements on behalf of one or more Issuers 🎀. They also MAY request Receipts no matter who the Issuer is 💅.
Once a TS registers a Signed Statement, a Receipt becomes available 🌸. And when a Receipt gets included in a Signed Statement, that's your Transparent Statement, periodt 💅.
Receipts are built on signed proofs from COSE Receipts [RFC9942] 📜. That same spec also defines the COSE header parameter semantics for label 394, so go check it out if you're curious 🧚.
The Registration time is the timestamp recorded when the TS added the Signed Statement to its VDS ⏰.
Figure 7 is the normative CDDL definition of Transparent Statements. For the CDDL rule that defines COSE_Sign1 as specified in Section 4.2 of RFC 9052 [STD96], look at Figure 3 🌈.
Transparent_Statement = #6.18(COSE_Sign1)
Unprotected_Header = {
&(receipts: 394) => [+ bstr .cbor Receipt]
}Figure 7: CDDL Definition for a Transparent Statement
Figure 8 shows a Transparent Statement with a detached payload and two Receipts in its unprotected header 🍓. The label 394 receipts field is a CBOR array that can hold one or more Receipts, and each entry is a .cbor-encoded Receipt 💜.
18( / COSE_Sign1 /
[
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 8: CBOR-Extended Diagnostic Notation Example of a Transparent Statement
Figure 9 decodes one of the Receipts from Figure 8 🔍. This Receipt has inclusion proofs for VDSs, and the unprotected header carries VDP. Check the protected header for details on the specific VDS used. Per the "COSE Verifiable Data Structure Algorithms" registry documented in [RFC9942], the Verifiable Data Structure algorithm RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and consistency proofs (-2) 🦋.
18( / COSE_Sign1 /
[
h'a4012604...6d706c65', / Protected /
{ / Unprotected /
396: { / Proofs /
-1: [ / Inclusion proofs (1) /
h'83080783...32568964', / Inclusion proof 1 /
]
},
},
nil, / Detached payload /
h'10f6b12a...4191f9d2' / Signature /
]
)Figure 9: CBOR-Extended Diagnostic Notation Example of a Receipt
Figure 10 decodes the protected header of the Transparent Statement in Figure 8 💎. The VDS (395) uses 1 from RFC9162_SHA256.
{ / Protected /
1: -7, / Algorithm /
4: h'50685f55...50523255', / Key identifier /
395: 1, / Verifiable Data Structure /
15: { / CWT Claims /
1: transparency.vendor.example, / Issuer /
2: vendor.product.example, / Subject /
}
}Figure 10: CBOR-Extended Diagnostic Notation Example of a Receipt's Protected Header
Figure 11 decodes the inclusion proof from Figure 9 🌟. It tells you the size of the VDS was 8 at the time the Receipt was issued. The structure of this inclusion proof is specific to the VDS used by RFC9162_SHA256 🫶.
[ / 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 11: CBOR-Extended Diagnostic Notation Example of a Receipt's Inclusion Proof
7.1. Validation 🧐
Relying Parties MUST apply the verification process described in Section 4.4 of RFC 9052 [STD96] whenever they check the signature on Signed Statements and Receipts 🔐.
A Relying Party MUST trust the verification key or certificate, plus the associated identity, of at least one Issuer of a Receipt 🫡.
A Relying Party MAY decide to verify only a single Receipt that works for them, and skip checking the signature on the Signed Statement or on Receipts that rely on VDSs they don't understand 🤷♀️.
APIs that expose verification logic for Transparent Statements may give you more details than a single yes-or-no. For example, an API may tell you if the signature on the Receipt or Signed Statement is valid, if the Claims about 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, plus any local state 🧠.
8. Privacy Considerations 🙈
Interactions with TSs are expected to use appropriately strong encryption and authorization technologies 🔒.
The TS is trusted with the confidentiality of the Signed Statements presented for Registration 🤫. Issuers and Clients are responsible for checking that the TS's privacy and security posture suits the contents of the Signed Statements they submit before Registration. Issuers must carefully review whether their Statements include private, confidential, or Personally Identifiable Information (PII), and check that against the TS's privacy posture 👀.
In some deployments, a special role such as an Auditor might require access to both the TS and related Adjacent Services, and be given that access 🕵️♀️.
TSs can use VDSs that only keep cryptographic metadata (for example, a hash) instead of the complete Signed Statement. That's a solid layer of defense for keeping things confidential 🛡️. But here's the tea: by analyzing the relationship between data stored in the TS and data stored in Adjacent Services, you can do metadata analysis. That could reveal the order in which artifacts were built, signed, and uploaded 😬.
9. Security Considerations 🔐
SCITT gives you these security guarantees, and they're iconic 👑:
- Statements made by Issuers about supply chain Artifacts are identifiable and can be authenticated.
- Statement provenance and history can be independently and consistently audited.
- Issuers can efficiently prove that their Statement is logged by a TS.
The first guarantee comes from requiring Issuers to sign their Statements ✍️. The second comes from proving a Signed Statement is present in a VDS 📍. The third comes from combining both of those steps 🫶.
Besides deciding whether to trust a TS, Relying Parties can use the history of registered Signed Statements to decide which Issuers they trust 🧐. That decision process is out of scope for this document 🙅♀️.
9.1. Ordering of Signed Statements ⏳
Statements get signed before they're submitted to a SCITT Transparency service. Unless the TS Registration Policy advertises it, the Relying Party cannot assume that the ordering of Signed Statements in the VDS matches the ordering of their issuance. So don't assume it, bestie 🙃.
9.2. Accuracy of Statements 📝
Issuers can make false Statements, either on purpose or by accident. Registering a Statement only proves it was produced by an Issuer, not that it's true 💀. A registered Statement may be superseded by a later Signed Statement from the same Issuer, as long as it has the same subject in the CWT Claims protected header 🔄. Other Issuers may make new Statements to reflect new or corrected information 🌈. Relying Parties may choose to include or exclude Statements from certain Issuers, to figure out how accurate a collection of Statements is 🔍.
9.3. Issuer Participation 🎀
Issuers can refuse to register their Statements with a TS, or selectively submit some of the Statements they issue and keep the rest to themselves 🙊. It's important for Relying Parties not to accept Signed Statements for which they can't discover Receipts issued by a TS they trust 🚩.
9.4. Key Management 🗝️
Issuers and TSs MUST:
- carefully protect their private signing keys
- avoid using keys for more than one purpose
- rotate their keys at a cryptoperiod (defined in [RFC4949]) appropriate for the key-algorithm and domain-specific regulations
9.4.1. Verifiable Data Structure 🧱
The security considerations for specific VDSs are out of scope for this document. For the generic security considerations that apply to VDSs and Receipts, see [RFC9942] 📚.
9.4.2. Key Compromise 🚨
It's important for Issuers and TSs to clearly communicate when keys are compromised, so that TSs can reject Signed Statements or Relying Parties can ignore Receipts 🙅♀️. A TS whose receipt signing keys have been compromised can roll back its Statement Sequence to a point before the compromise, establish new credentials, and use those credentials to issue fresh Receipts going forward 🔁. Issuers are encouraged to follow existing best practices if their credentials are compromised 💪. Revocation strategies for compromised keys are out of scope for this document 🙌.
9.4.3. Bootstrapping 🥾
Bootstrapping mechanisms that rely solely on Statement registration to set and update registration policy can be audited without any extra implementation-specific knowledge, so they're preferable 🏆. Mechanisms that rely on preconfigured values and don't allow updates are unsuitable for long-lived service deployments, where being able to patch a potentially faulty policy is essential 🩹.
9.5. Implications of Media Type Usage 🎞️
The Statement (scitt-statement+cose) and Receipt (scitt-receipt+cose) media types describe the expected content of COSE envelope headers. The payload media type (content type) is included in the COSE envelope header. [STD96] describes the security implications of relying on this header parameter ⚠️.
Both media types describe COSE_Sign1 messages, which include a signature and therefore provide integrity protection 🛡️.
9.6. Cryptographic Agility 🔄
Because the SCITT architecture leverages [STD96] for Statements and Receipts, it benefits from the format's cryptographic agility 🦋.
9.7. Threat Model 🕵️♀️💅
okay so this part is the threat model, and it's giving "what happens when the bad guys show up, and what's still safe?" 😭🔥 It describes the residual security properties of SCITT when some of its actors (Issuers, TSs, and Auditors) are either corrupt or compromised. bestie, that's a LOT of chaos to plan for, and the architecture still holds up. 🫶
SCITT mainly helps you check that a Signed Statement is authentic, both from the Issuer (authentication) and from the TS (transparency) 🔍✨. And yes, Issuers and TSs can both get compromised, so it has to be ready for that. 💀
The SCITT architecture does NOT need you to trust one single centralized TS 🙅♀️. Different actors can rely on different TSs, and each TS registers a subset of Signed Statements based on its own policy. Running multiple independent TSs gives different organizations room to hold consistent or divergent opinions 🌈. It's the job of the relying party to decide which TSs and Issuers they trust for their situation 👑.
In both cases, the SCITT architecture gives generic, universally verifiable cryptographic proofs so Issuers or TSs can be held accountable 🧾. On one hand, this lets valid actors spot and sort out malicious actors who use Equivocation with Signed Statements, showing different versions to different entities 👀. On the other hand, their liability and the damage to their reputation are application specific and out of scope for the SCITT architecture, so that part is on the application, not SCITT 🙈.
Relying Parties and Auditors don't need to be trusted by other actors 💜. As long as actors properly control their signing keys and identity infrastructure, nobody can "frame" an Issuer or a TS for Signed Statements they never issued or registered 🦋. Main character energy for keeping your keys safe, periodt! 🔐
10. IANA Considerations 📋🎀
okay so IANA is the registry keeper of the internet, and this section is where SCITT's new stuff gets officially added to the lists 🗂️. IANA has registered the following media types in the "application" subregistry of the "Media Types" registry group [IANA.media-types]:
application/scitt-statement+cose(see Section 10.1)application/scitt-receipt+cose(see Section 10.2)
10.1. Registration of application/scitt-statement+cose 🧾
This is the registration for the Signed Statement media type, and it's literally the official ID card for the thing 🪪.
+======================+======================+=============+
| Name | Template | Reference |
+======================+======================+=============+
| scitt-statement+cose | application/scitt- | Section 6 |
| | statement+cose | of RFC 9943 |
+----------------------+----------------------+-------------+
Table 1: SCITT Signed Statement Media Type RegistrationType name: application 🌸
Subtype name: scitt-statement+cose 🌸
Required parameters: N/A 🌸
Optional parameters: N/A 🌸
Encoding considerations: binary (CBOR data item) 🌸
Security considerations: Section 9.5 of RFC 9943 🌸
Interoperability considerations: none 🌸
Published specification: RFC 9943 🌸
Applications that use this media type: Used to provide an identifiable and non-repudiable Statement about an Artifact signed by an Issuer 🫶
Fragment identifier considerations: N/A 🌸
Additional information:
- Deprecated alias names for this type:
N/A - Magic number(s):
N/A - File extension(s):
.scitt - Macintosh file type code(s):
N/A
Person & email address to contact for further information: iesg@ietf.org 📬
Intended usage: COMMON ✨
Restrictions on usage: none ✨
Author/Change controller: IETF 👑
10.2. Registration of application/scitt-receipt+cose 🧾
This is the sibling registration, for the Receipt media type 🦋. Receipts are how you verify transparency, so they get their own entry 💖.
+====================+================================+=============+
| Name | Template | Reference |
+====================+================================+=============+
| scitt-receipt+cose | application/scitt- | Section 7 |
| | receipt+cose | of RFC 9943 |
+--------------------+--------------------------------+-------------+
Table 2: SCITT Receipt Media Type RegistrationType name: application 🌸
Subtype name: scitt-receipt+cose 🌸
Required parameters: N/A 🌸
Optional parameters: N/A 🌸
Encoding considerations: binary (CBOR data item) 🌸
Security considerations: Section 9.5 of RFC 9943 🌸
Interoperability considerations: none 🌸
Published specification: RFC 9943 🌸
Applications that use this media type: Used to establish or verify transparency over Statements. Typically emitted by a TS for the benefit of Relying Parties wanting to ensure Non-equivocation over all or part of a Statement Sequence 🔁
Fragment identifier considerations: N/A 🌸
Additional information:
- Deprecated alias names for this type:
N/A - Magic number(s):
N/A - File extension(s):
.receipt - Macintosh file type code(s):
N/A
Person & email address to contact for further information: iesg@ietf.org 📬
Intended usage: COMMON ✨
Restrictions on usage: none ✨
Author/Change controller: IETF 👑
10.3. CoAP Content-Format Registrations 🌈
okay so CoAP is the lightweight cousin of HTTP for tiny devices 🧚, and it uses numbered Content-Formats instead of names. IANA has registered the following Content-Format numbers in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters] in the 256-9999 range:
+======================+================+=====+===========+
| Content Type | Content Coding | ID | Reference |
+======================+================+=====+===========+
| application/scitt- | - | 277 | RFC 9943 |
| statement+cose | | | |
+----------------------+----------------+-----+-----------+
| application/scitt- | - | 278 | RFC 9943 |
| receipt+cose | | | |
+----------------------+----------------+-----+-----------+
Table 3: SCITT Content-Formats Registration11. References 📚🌸
okay so references are the bibliography, aka where all the receipts for the claims live 🧾✨. They come in two flavors: normative (you NEED these to implement) and informative 💅.
11.1. Normative References 🫶
[IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt>.
[IANA.media-types] IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[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/info/rfc2119>.
[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/info/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/info/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/info/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/info/rfc8610>.
[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/info/rfc9360>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/info/rfc9597>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/info/rfc9942>.
[STD94] Internet Standard 94, <https://www.rfc-editor.org/info/std94>. At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[STD96] Internet Standard 96, <https://www.rfc-editor.org/info/std96>. At the time of writing, this STD comprises the following:
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/info/rfc9052>.
Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/info/rfc9338>.
11.2. Informative References ✨
okay so these are the informative refs, which means the doc points at them for background and context, not as required reading 📚 bestie, here's the whole list:
[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/info/rfc9393.
[CycloneDX] "CycloneDX", 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", ACM SIGOPS Operating Systems Review, vol. 41, no. 6, pp. 189-204, DOI 10.1145/1323293.1294280, 14 October 2007, https://www.read.seas.harvard.edu/~kohler/class/08w-dsi/chun07attested.pdf. 🦋
[in-toto] "in-toto", https://in-toto.io/.
[ISO_IEC_17000] ISO/IEC, "Conformity assessment - Vocabulary and general principles", ISO/IEC 17000:2020, December 2020, https://www.iso.org/standard/73029.html.
[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., and B. Swarts, "Trusted cloud: Security Practice Guide for VMware Hybrid Cloud Infrastructure as a Service (IaaS) Environments", DOI 10.6028/NIST.SP.1800-19, NIST SP 1800-19, 20 April 2022, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-19.pdf. 🌸
[NIST.SP.800-204C] Chandramouli, R., "Implementation of DevSecOps for a Microservices-based Application with Service Mesh", DOI 10.6028/NIST.SP.800-204C, NIST Special Publications (General) 800-204C, NIST SP 800-204C, DOI 10.6028/NIST.SP.800-204C, March 2022, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204C.pdf.
[NIST_EO14028] NIST, "Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e", 4 February 2022, https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-section-4e.pdf.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, https://www.rfc-editor.org/info/rfc4949. 💅
[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/info/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/info/rfc9162.
[SLSA] "SLSA", https://slsa.dev/.
[SPDX] "SPDX Specification", https://spdx.dev/use/specifications/.
[SWID] NIST, "SWID Specification", https://csrc.nist.gov/Projects/Software-Identification-SWID/guidelines.
Contributors 🫶
Orie Steele (Tradeverifyd, United States of America, Email: orie@or13.io) Orie helped make the COSE building blocks more generalized and kept the whole document consistent. Iconic work 👑
Amaury Chamayou (Microsoft, United Kingdom, Email: amaury.chamayou@microsoft.com) Amaury helped finalize the normative language on registration behavior and the single-issuer design, plus overall document consistency. Such a precise queen 💜
Dick Brooks (Business Cyber Guardian, United States of America, Email: dick@businesscyberguardian.com) Dick contributed to the software supply chain use cases. 🍓
Brian Knight (Microsoft, United States of America, Email: brianknight@microsoft.com) Brian also contributed to the software supply chain use cases. 🧚
Robert Martin (MITRE Corporation, United States of America, Email: ramartin@mitre.org) Robert contributed to the software supply chain use cases too. ⭐
Authors' Addresses 🎀
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contactAntoine Delignat-Lavaud
Microsoft
United Kingdom
Email: antdl@microsoft.comCédric Fournet
Microsoft
United Kingdom
Email: fournet@microsoft.comYogesh Deshpande
ARM
110 Fulbourn Road
Cambridge
CB1 9NJ
United Kingdom
Email: yogesh.deshpande@arm.comSteve Lasker
Email: stevenlasker@hotmail.comThat's the whole doc, bestie! 🦋✨ Every author and contributor is credited, and every reference is still exactly where it belongs. Periodt 💖
📦 where this page comes from
- ietf: rfc9943 2026-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms