An Architecture for Trustworthy and Transparent Digital Supply Chains Fraunhofer SIT
Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact
Microsoft
United Kingdom antdl@microsoft.com
Microsoft
United Kingdom fournet@microsoft.com
ARM
110 Fulbourn Road Cambridge CB1 9NJ United Kingdom yogesh.deshpande@arm.com
stevenlasker@hotmail.com
SEC scitt COSE Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements.
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
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 () 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
  • .  Introduction
    • .  Requirements Notation
  • .  Software Supply Chain Scope
    • .  Generic SSC Problem Statement
    • .  Eclectic SSC Use Cases
      • .  Security Analysis of a Software Product
      • .  Promotion of a Software Component by Multiple Entities
      • .  Software Integrator Assembling a Software Product for a Vehicle
  • .  Terminology
  • .  Definition of Transparency
  • .  Architecture Overview
    • .  Transparency Service
      • .  Registration Policies
      • .  Initialization and Bootstrapping
      • .  Verifiable Data Structure
      • .  Adjacent Services
  • .  Signed Statements
    • .  Signed Statement Examples
    • .  Signing Large or Sensitive Statements
    • .  Registration of Signed Statements
  • .  Transparent Statements
    • .  Validation
  • .  Privacy Considerations
  • .  Security Considerations
    • .  Ordering of Signed Statements
    • .  Accuracy of Statements
    • .  Issuer Participation
    • .  Key Management
      • .  Verifiable Data Structure
      • .  Key Compromise
      • .  Bootstrapping
    • .  Implications of Media Type Usage
    • .  Cryptographic Agility
    • .  Threat Model
  • . IANA Considerations
    • .  Registration of application/scitt-statement+cose
    • .  Registration of application/scitt-receipt+cose
    • .  CoAP Content-Format Registrations
  • . References
    • .  Normative References
    • .  Informative References
  • Contributors
  • Authors' Addresses
Introduction This document defines an architecture, a base set of extensible message structures, and associated flows to make signed content transparent via VDSs maintained by corresponding transparency services. The goal of the transparency enabled by the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture is to enhance auditability and accountability for single-issuer signed content (statements) that are about supply chain commodities (artifacts). Registering signed statements with a Transparency Service (TS) is akin to a notarization procedure. TSs confirm a policy is met before recording the statement on the ledger. The SCITT ledger represents a linear and irrevocable history of statements made. Once the signed statement is registered, the TS issues a receipt. Similar approaches have been implemented for specific classes of artifacts, such as Certificate Transparency (CT) . The SCITT approach follows a more generic paradigm than previous approaches. This "content-agnostic" approach allows TSs to be either integrated in existing solutions or an initial part of new emerging systems. Extensibility is a vital feature of the SCITT architecture, so that requirements from various applications can be accommodated while always ensuring interoperability with respect to registration procedures and corresponding auditability and accountability. For simplicity, the scope of this document is limited to use cases originating from the software supply chain domain. However, the specification defined is applicable to any other type of supply chain statements (also referred to as "value-add graphs"), for example, statements about hardware supply chains. This document also defines message structures for signed statements and transparent statements, which embed CBOR Object Signing and Encryption (COSE) receipts , i.e., signed Verifiable Data Structure Proofs (VDP). These message structures are based on the Concise Binary Object Representation (CBOR) Standard and corresponding signing is facilitated via the COSE Standard . The message structures are defined using the Concise Data Definition Language (CDDL) . The signed statements and receipts are, respectively, based on the COSE_Sign1 specification in Section of RFC 9052 and on COSE receipts . The application-domain-agnostic nature of COSE_Sign1 and its extensibility through COSE header parameters are prerequisites for implementing the interoperable message layer defined in this document. In summary, this specification supports relying parties obtaining proof that signed statements were recorded and checked for their validity at the time they were registered. How these statements are managed or stored as well as how participating entities discover and notify each other of changes is out of scope of this document.
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 when, and only when, they appear in all capitals, as shown here.
Software Supply Chain Scope To illustrate the applicability of the SCITT architecture and its messages, this section details the exemplary context of Software Supply Chain (SSC) use cases. The building blocks provided by the SCITT architecture are not restricted to SSC use cases. SSCs serve as useful application guidance and first usage scenarios.
Generic SSC Problem Statement Supply chain security is a prerequisite to protecting consumers and minimizing economic, public health, and safety threats. Supply chain security has historically focused on risk management practices to safeguard logistics, meet regulatory requirements, forecast demand, and optimize inventory. While these elements are foundational to a healthy supply chain, an integrated cyber-security-based perspective of the SSCs remains broadly undefined. Recently, the global community has experienced numerous supply chain attacks targeting weaknesses in SSCs. As illustrated in , an SSC attack may leverage one or more life-cycle stages and directly or indirectly target the component.
Example SSC Life-Cycle Threats 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 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 | | +-----------+
DevSecOps, as defined in , often depends on third-party and open-source software. These dependencies can be quite complex throughout the supply chain, so checking provenance and traceability throughout their life cycle is difficult. There is a need for manageable auditability and accountability of digital products. Typically, the range of types of statements about digital products (and their dependencies) is vast, heterogeneous, and can differ between community policy requirements. Taking the type and structure of all statements about digital products into account might not be possible. Examples of statements may include 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. Consequently, instead of trying to understand and describe the detailed syntax and semantics of every type of statement about digital products, the SCITT architecture focuses on ensuring statement authenticity, ensuring visibility/transparency, and intends to provide scalable accessibility. Threats and practical issues can also arise from unintended side effects of using security techniques outside their proper bounds. For instance, digital signatures may fail to verify past their expiry date even though the signed item itself remains completely valid. Or a signature may verify even though the information it is securing is now found unreliable but fine-grained revocation is too hard. Lastly, where data exchange underpins serious business decision-making, it is important to hold the producers of those data to a higher standard of auditability. The SCITT architecture provides mechanisms and structures for ensuring that the makers of authoritative statements can be held accountable and not hide or shred the evidence when it becomes inconvenient later. The following use cases illustrate the scope of SCITT and elaborate on the generic problem statement above.
Eclectic SSC Use Cases The three following use cases are a specialization derived from the generic problem statement above.
Security Analysis of a Software Product A released software product is often accompanied by a set of complementary statements about its security properties. This gives enough confidence to both producers and consumers that the released software meets the expected security standards and is suitable to use. Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product. The intention is to identify any security weaknesses or vulnerabilities in the package. Initially, a particular analysis can identify a simple weakness in a software component. Over a period of time, a statement from a third party illustrates that the weakness is exposed in a way that represents an exploitable vulnerability. The producer of the software product provides a statement that confirms the linking of a software component vulnerability with the software product by issuing a product vulnerability disclosure report and also issuing an advisory statement on how to mitigate the vulnerability. At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that inhibits exploitation. Later, a second update of the software product includes a security patch to the affected software component from the software producer. Finally, a third update includes a new release (updated version) of the formerly insecure software component. For this release, both the software product and the affected software component are deemed secure by the producer and consumers. 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
Promotion of a Software Component by Multiple Entities A software component (e.g., a library or software product), open-source or commercial, is often initially released by a single trusted producer who can choose to attach a statement of authenticity to it. As that component becomes used in a growing range of other products, providers other than the original trusted producer often re-distribute or release their own version of that component. Some providers include it as part of their release product or package bundle and provide the package with proof of authenticity using their issuer authority. Some packages include the original statement of authenticity, and some do not. Over time, some providers no longer offer the exact same software component source code but pre-compiled software component binaries. Some sources do not provide the exact same software component but include patches and fixes produced by third parties as these emerge faster than solutions from the original producer. Due to complex distribution and promotion life-cycle scenarios, the original software component takes 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
Software Integrator Assembling a Software Product for a Vehicle Software integration is a complex activity. Typically, it involves getting various software components from multiple suppliers and producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their vehicles from third parties that integrate software components from various sources. Integration complexity creates a higher risk of security vulnerabilities to 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
Terminology The terms defined in this section have special meaning in the context of SCITT and are used throughout this document. This document has been 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 . The term "claim" is defined in . When used in text in the sense defined, the following terms are capitalized. To ensure readability, only a core set of terms is included 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:
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 , 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.
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 iss Claim is a member of the COSE header parameter 15: CWT Claims defined in , which embeds a CBOR Web Token (CWT) Claims Set within the protected header of a COSE Envelope. This document uses the terms "Issuer" and "Subject" as described in ; 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 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 . 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 . See 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 ), 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 ). 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 and used as a protected header parameter as defined in . 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 the sub CWT Claim, defined in , 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 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 in which Signed Statements can be inserted as they are Registered by a TS. SCITT supports multiple VDSs and Receipt formats as defined in , accommodating different TS implementations.
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 CT are instances of this definition. SCITT supports multiple VDSs, as defined in . 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 , 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 tbsCertificate structure 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
Architecture Overview The SCITT architecture enables TSs in a given application domain to implement a collective baseline by providing a set of common formats and protocols for issuing and registering Signed Statements and auditing Transparent Statements. In order to accommodate 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, which specifies the TS identity and the agility parameters for the signed proofs. The remaining details of the Receipt's contents are specified in . illustrates the roles and processes that comprise a TS independent of any one 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).
In addition, illustrates multiple TSs and multiple Receipts as a single Signed Statement MAY be registered with one or more TS. Each TS produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple TSs. The arrows indicate the flow of information.
Relationship of Concepts in SCITT Artifact Issuer Statement sign verify Signed Statement Transparency Service Receipt Transparency Service Receipt Transparent Statement Collect Receipts Verify Transparent Statement Replay Log Relying Party Relying Party Relying Party .----------. +--------------+ | 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 | +---------------+ +---------------+
The subsequent sections describe the main concepts, namely TS, Signed Statements, Registration, and Transparent Statements in more detail.
Transparency Service TSs MUST produce COSE Receipts . 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.".
Registration Policies Registration Policies refer to additional checks over and above the mandatory Registration checks that are performed before a Signed Statement is registered to the VDS. To enable auditability, TSs MUST maintain Registration Policies. The presence of an explicit transparent registration policy, even if it allows all authenticated submissions, facilitates service audit, and enables potential future changes to that policy. Beyond the mandatory Registration checks, the scope of additional checks, including no additional checks, is up to the implementation. This specification leaves implementation, encoding, and documentation of Registration Policies and trust anchors to the operator of the TS.
Mandatory Registration Checks During Registration, a TS MUST syntactically check the Issuer of the Signed Statement by cryptographically verifying the COSE signature according to . 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 definition of trust anchor in ) in order to 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 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 . 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.
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.
Initialization and Bootstrapping Since the mandatory Registration checks rely on having registered Signed Statements for the Registration Policy and trust anchors, 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.
Verifiable Data Structure The security properties are determined by the choice of the VDS (see ) 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 and , and the review of their security requirements for SCITT are out of scope for this document.
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.
Signed Statements This specification prioritizes conformance to and its required and optional properties. Signed Statements produced by Issuers must be COSE_Sign1 messages, as defined by . Profiles and implementation-specific choices should be used to determine admissibility of conforming messages. This specification is left intentionally open to allow implementations to make Registration restrictions that make the most sense for their operational use cases. There are many types of Statements (such as an SBOM, 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:
  • Concise Software Identification Tags format
  • Bill of Materials format
  • Supply chain description metadata
  • Software component description format
  • Supply-chain Levels for Software Artifacts
  • Software Identification Tag format
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 in .) Issuers MAY use different signing keys (identified by kid in the protected header from ) for different Artifacts or sign all Signed Statements under the same key. An Issuer can make multiple Statements about the same Artifact. For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting, Statements about the same Artifact. Relying Parties can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. 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.
  • 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 . The iss Claim 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 . The CWT Claims value MUST include the Issuer Claim (Claim label 1) and the Subject Claim (Claim label 2) . 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 .
Signed Statement Examples illustrates a normative CDDL definition for the protected header and unprotected header of Signed Statements and Receipts. The SCITT architecture specifies the minimal mandatory labels. Implementation-specific Registration Policies may define additional mandatory labels.
CDDL Definition for Signed Statements and Receipts 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
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.
CBOR-Extended Diagnostic Notation Example of a Signed Statement 18( / COSE_Sign1 / [ h'a4012603...6d706c65', / Protected / {}, / Unprotected / nil, / Detached payload / h'79ada558...3a28bae4' / Signature / ] )
illustrates the decoded protected header of the Signed Statement in . It indicates the Signed Statement is securing a JSON content type and identifying the content with the sub Claim "vendor.product.example".
CBOR-Extended Diagnostic Notation Example of a Signed Statement's Protected Header { / 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 / } }
Signing Large or Sensitive Statements Statement payloads might be too large or too sensitive to be sent to a remote TS. In these cases, a Statement can be made over the hash of a payload rather than the full payload bytes.
Signing Large or Sensitive Statements Artifact Hash OR Payload Statement ... Producer Network ... ... ... Issuer Network ... Identity Document (iss, x5t) Private Key Header Sign To-Be-Signed-Bytes COSE_Sign1 .----+-----. | 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 | '------------'
Registration of Signed Statements To register a Signed Statement, the TS performs the following steps:
  1. 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.
  2. TS Signed Statement Verification and Validation The TS MUST perform signature verification per Section of RFC 9052 and MUST verify the signature of the Signed Statement with the signature algorithm and verification key of the Issuer per . 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.
  3. 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.
  4. Register the Signed Statement
  5. 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 .
The last two steps may be shared between a batch of Signed Statements registered in the VDS. A TS MUST ensure that a Signed Statement is registered before releasing its Receipt. 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. 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. 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. 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.
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 TS a Receipt becomes available. When a Receipt is included in a Signed Statement, a Transparent Statement is produced. Receipts are based on signed proofs as described in COSE Receipts , which also provides the COSE header parameter semantics for label 394. The Registration time is recorded as the timestamp when the TS added the Signed Statement to its VDS. illustrates a normative CDDL definition of Transparent Statements. See for the CDDL rule that defines COSE_Sign1 as specified in Section of RFC 9052 .
CDDL Definition for a Transparent Statement Transparent_Statement = #6.18(COSE_Sign1) Unprotected_Header = { &(receipts: 394) => [+ bstr .cbor Receipt] }
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 Receipt).
CBOR-Extended Diagnostic Notation Example of a Transparent Statement 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 / ] )
illustrates one of the decoded Receipts from . The Receipt contains inclusion proofs for VDSs. The unprotected header contains VDP. See the protected header for details regarding the specific VDS used. Per the "COSE Verifiable Data Structure Algorithms" registry documented in , the Verifiable Data Structure algorithm RFC9162_SHA256 is value 1. Labels identify inclusion proofs (-1) and consistency proofs (-2).
CBOR-Extended Diagnostic Notation Example of a Receipt 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 / ] )
illustrates the decoded protected header of the Transparent Statement in . The VDS (395) uses 1 from RFC9162_SHA256.
CBOR-Extended Diagnostic Notation Example of a Receipt's Protected Header { / 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 / } }
illustrates the decoded inclusion proof from . This inclusion proof indicates that 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.
CBOR-Extended Diagnostic Notation Example of a Receipt's Inclusion Proof [ / 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 / ] ]
Validation Relying Parties MUST apply the verification process as described in Section of RFC 9052 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 that rely on VDSs 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.
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 verifying that the TS's privacy and security posture is suitable for the contents of the Signed Statements they submit prior to Registration. Issuers must carefully review the inclusion of private, confidential, or Personally Identifiable Information (PII) in their Statements against the TS's privacy posture. In some deployments, a special role such as an Auditor might require and be given access to both the TS and related Adjacent Services. TSs can leverage VDSs that only retain cryptographic metadata (e.g., a hash) rather than the complete Signed Statement as part of an in-depth defensive approach to maintaining confidentiality. By analyzing the relationship between data stored in the TS and data stored in Adjacent Services, it is possible to perform metadata analysis, which could reveal the order in which artifacts were built, signed, and uploaded.
Security Considerations SCITT provides the following security guarantees:
  1. Statements made by Issuers about supply chain Artifacts are identifiable and can be authenticated.
  2. Statement provenance and history can be independently and consistently audited.
  3. Issuers can efficiently prove that their Statement is logged by a TS.
The first guarantee is achieved by requiring Issuers to sign their Statements. The second guarantee is achieved by proving a Signed Statement is present in a VDS. The third guarantee is achieved by the combination of both of these steps. In addition to deciding whether to trust a TS, Relying Parties can use the history of registered Signed Statements to decide which Issuers they choose to trust. This decision process is out of scope of this document.
Ordering of Signed Statements Statements are signed prior to submitting to a SCITT Transparency service. Unless advertised in the TS Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the VDS matches the ordering of their issuance.
Accuracy of Statements Issuers can make false Statements either intentionally or unintentionally; registering a Statement only proves it was produced by an Issuer. A registered Statement may be superseded by a subsequently submitted Signed Statement from the same Issuer, with 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 Issuers to determine the accuracy of a collection of Statements.
Issuer Participation Issuers can refuse to register their Statements with a TS or selectively submit some but not all the Statements they issue. It is important for Relying Parties not to accept Signed Statements for which they cannot discover Receipts issued by a TS they trust.
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 ) appropriate for the key-algorithm and domain-specific regulations
Verifiable Data Structure The security considerations for specific VDSs are out of scope for this document. See for the generic security considerations that apply to VDSs and Receipts.
Key Compromise It is important for Issuers and TSs to clearly communicate when keys are compromised so that Signed Statements can be rejected by TSs or Receipts can be ignored by Relying Parties. TSs whose receipt signing keys have been compromised can roll back their Statement Sequence to a point before compromise, establish new credentials, and use the new 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.
Bootstrapping Bootstrapping mechanisms that solely rely on Statement registration to set and update registration policy can be audited without additional implementation-specific knowledge; therefore, they are preferable. Mechanisms that rely on preconfigured values and do not allow updates are unsuitable for use in long-lived service deployments in which the ability to patch a potentially faulty policy is essential.
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. describes the security implications of reliance on this header parameter. Both media types describe COSE_Sign1 messages, which include a signature and therefore provide integrity protection.
Cryptographic Agility Because the SCITT architecture leverages for Statements and Receipts, it benefits from the format's cryptographic agility.
Threat Model This section provides a generic threat model for SCITT, describing its residual security properties when some of its actors (Issuers, TSs, and Auditors) are either corrupt or compromised. SCITT primarily supports checking of Signed Statement authenticity, both from the Issuer (authentication) and from the TS (transparency). Issuers and TSs can both be compromised. The SCITT architecture does not require trust in a single centralized TS. Different actors may rely on different TSs, each registering a subset of Signed Statements subject to their own policy. Running multiple, independent TSs provides different organizations to represent consistent or divergent opinions. It is the role of the relying party to decide which TSs and Issuers they choose to trust for their scenario. In both cases, the SCITT architecture provides generic, universally verifiable cryptographic proofs to hold Issuers or TSs accountable. 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. So long as actors maintain proper control of their signing keys and identity infrastructure they cannot "frame" an Issuer or a TS for Signed Statements they did not issue or register.
IANA Considerations IANA has registered the following media types in the "application" subregistry of the "Media Types" registry group :
  • application/scitt-statement+cose (see )
  • application/scitt-receipt+cose (see )
Registration of application/scitt-statement+cose SCITT Signed Statement Media Type Registration
Name Template Reference
scitt-statement+cose application/scitt-statement+cose of RFC 9943
Type name:
application
Subtype name:
scitt-statement+cose
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary (CBOR data item)
Security considerations:
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
Registration of application/scitt-receipt+cose SCITT Receipt Media Type Registration
Name Template Reference
scitt-receipt+cose application/scitt-receipt+cose of RFC 9943
Type name:
application
Subtype name:
scitt-receipt+cose
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
binary (CBOR data item)
Security considerations:
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
CoAP Content-Format Registrations IANA has registered the following Content-Format numbers in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry group in the 256-9999 range: SCITT Content-Formats Registration
Content Type Content Coding ID Reference
application/scitt-statement+cose - 277 RFC 9943
application/scitt-receipt+cose - 278 RFC 9943
References Normative References Constrained RESTful Environments (CoRE) Parameters IANA CBOR Web Token (CWT) Claims IANA Media Types IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. CBOR Web Token (CWT) CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. CBOR Web Token (CWT) Claims in COSE Headers This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. CBOR Object Signing and Encryption (COSE) Receipts Tradeverifyd Fraunhofer SIT Microsoft Microsoft Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE): Countersignatures Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. Informative References Concise Software Identification Tags ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. CycloneDX Attested Append-Only Memory: Making Adversaries Stick to their Word ACM SIGOPS Operating Systems Review, vol. 41, no. 6, pp. 189-204 in-toto Conformity assessment - Vocabulary and general principles ISO/IEC Trusted cloud: Security Practice Guide for VMware Hybrid Cloud Infrastructure as a Service (IaaS) Environments Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Information Technology Laboratory Implementation of DevSecOps for a Microservices-based Application with Service Mesh Information Technology Laboratory Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e NIST Internet Security Glossary, Version 2 This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. JSON Web Token Best Current Practices JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Certificate Transparency Version 2.0 This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. SLSA SPDX Specification SWID Specification NIST
Contributors Tradeverifyd
United States of America orie@or13.io
Orie contributed to improving the generalization of COSE building blocks and document consistency. Microsoft
United Kingdom amaury.chamayou@microsoft.com
Amaury contributed elemental parts to finalize normative language on registration behavior and the single-issuer design, as well as overall document consistency. Business Cyber Guardian
United States of America dick@businesscyberguardian.com
Dick contributed to the software supply chain use cases. Microsoft
United States of America brianknight@microsoft.com
Brian contributed to the software supply chain use cases. MITRE Corporation
United States of America ramartin@mitre.org
Robert contributed to the software supply chain use cases.
Authors' Addresses Fraunhofer SIT
Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact
Microsoft
United Kingdom antdl@microsoft.com
Microsoft
United Kingdom fournet@microsoft.com
ARM
110 Fulbourn Road Cambridge CB1 9NJ United Kingdom yogesh.deshpande@arm.com
stevenlasker@hotmail.com