An Architecture for Trustworthy and Transparent Digital Supply Chains

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 April 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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

In supply chains, downstream Artifacts are built upon upstream Artifacts. The complexity of traceability and quality control for these supply chains increases with the number of Artifacts and parties contributing to them. There are many parties who publish information about Artifacts: For example, the original manufacturer may provide information about the state of the Artifact when it left the factory. The shipping company may add information about the transport environment of the Artifact. Compliance Auditors may provide information about their compliance assessment of the Artifact. Security companies may publish vulnerability information about an Artifact. Some of these parties may publish information about their analysis or use of an Artifact.¶

SCITT provides a way for Relying Parties to obtain this information in a way that is "transparent", that is, parties cannot lie about the information that they publish without it being detected. SCITT achieves this by having producers publish information in a Transparency Service, where Relying Parties can check the information.¶

2. Terminology

The terms defined in this section have special meaning in the context of Supply Chain Integrity, Transparency, and Trust, which are used throughout this document. When used in text, the corresponding terms are capitalized. To ensure readability, only a core set of terms is included in this section.¶

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

The term "claim" is defined in [RFC8392].¶

Append-only Log (Ledger):

the verifiable append-only data structure that stores Signed Statements in a Transparency Service, often referred to by the synonym Ledger. SCITT supports multiple Ledger and Receipt formats to accommodate different Transparency Service implementations, and the proof types associated with different types of Append-only Logs.¶

Artifact:

a physical or non-physical item that is moving along a supply chain.¶

Auditor:

an entity that checks the correctness and consistency of all Transparent Statements issued by a Transparency Service. An Auditor is an example of a specialized Relying Party.¶

Client:

an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization.¶

Envelope:

metadata, created by the Issuer to produce a Signed Statement. The Envelope contains the identity of the Issuer and information about the Artifact, enabling Transparency Service Registration Policies to validate the Signed Statement. A Signed Statement is a COSE Envelope wrapped around a Statement, binding the metadata in the Envelope to the Statement. In COSE, an Envelope consists of a protected header (included in the Issuer's signature) and an unprotected header (not included in the Issuer's signature).¶

Equivocation:

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

Issuer:

an identifier representing an organization, device, user, or entity securing Statements about supply chain Artifacts. An Issuer may be the owner or author of Artifacts, or an independent third party such as an Auditor, reviewer or an endorser. In SCITT Statements and Receipts, the iss CWT Claim is a member of the COSE header parameter 15: CWT_Claims within the protected header of a COSE Envelope.¶

Non-equivocation:

a state where it is impossible for a Transparency Service to provide different views of its Append-only Log to Relying Parties about the same Artifact. Over time, an Issuer may register new Signed Statements about an Artifact in a Transparency Service with new information. However, the consistency of a collection of Signed Statements about the Artifact can be checked by all Relying Parties.¶

Receipt:

a cryptographic proof that a Signed Statement is included in the Append-only Log. Receipts are signed proofs of verifiable data-structure properties. The types of Receipts MUST support inclusion proofs and MAY support other proof types, such as consistency proofs.¶

Registration:

the process of submitting a Signed Statement to a Transparency Service, applying the Transparency Service's Registration Policy, adding to the Append-only Log, and producing a Receipt.¶

Registration Policy:

the pre-condition enforced by the Transparency Service before registering a Signed Statement, based on information in the non-opaque header and metadata contained in its COSE Envelope.¶

Relying Party:

a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain.¶

Signed Statement:

an identifiable and non-repudiable Statement about an Artifact signed by an Issuer. In SCITT, Signed Statements are encoded as COSE signed objects; the payload of the COSE structure contains the issued Statement.¶

Statement:

any serializable information about an Artifact. To help interpretation of Statements, they must be tagged with a media type (as specified in [RFC6838]). A Statement may represent a Software Bill Of Materials (SBOM) that lists the ingredients of a software Artifact, an endorsement or attestation about an Artifact, indicate the End of Life (EOL), redirection to a newer version, or any content an Issuer wishes to publish about an Artifact. The additional Statements about an Artifact are correlated by the Subject defined in the [CWT_CLAIMS] protected header. The Statement is considered opaque to Transparency Service, and MAY be encrypted.¶

Subject:

an identifier, defined by the Issuer, that represents the organization, device, user, entity, or Artifact about which Statements (and Receipts) are made and by which a logical collection of Statements can be grouped. It is possible that there are multiple Statements about the same Artifact. In these cases, distinct Issuers (iss) might agree to use the sub CWT Claim to create a coherent sequence of Signed Statements about the same Artifact and Relying Parties can leverage sub to ensure completeness and Non-equivocation across Statements by identifying all Transparent Statements associated to a specific Subject.¶

Transparency Service:

an entity that maintains and extends the Append-only Log, and endorses its state. A Transparency Service can be a complex system, requiring the Transparency Service to provide many security guarantees about its Append-only Log. The identity of a Transparency Service is captured by a public key that must be known by Relying Parties in order to validate Receipts.¶

Transparent Statement:

a Signed Statement that is augmented with a Receipt created via Registration in a Transparency Service. The Receipt is stored in the unprotected header of COSE Envelope of the Signed Statement. A Transparent Statement remains a valid Signed Statement, and may be registered again in a different Transparency Service.¶

Verifiable Data Structure:

a data structure which supports one or more proof types, such as "inclusion proofs" or "consistency proofs" (as defined in [I-D.draft-ietf-cose-merkle-tree-proofs]).¶

3. Definition of Transparency

In this document, the definition of transparency is intended to build over abstract notions of Append-only Logs and Receipts. Existing transparency systems such as Certificate Transparency are instances of this definition.¶

A Signed Statement is an identifiable and non-repudiable Statement made by an Issuer. The Issuer selects additional metadata and attaches a proof of endorsement (in most cases, a signature) using the identity key of the Issuer that binds the Statement and its metadata. Signed Statements can be made transparent by attaching a proof of Registration by a Transparency Service, in the form of a Receipt. Receipts demonstrate inclusion of Signed Statements in the Append-only Log of a Transparency Service. By extension, the Signed Statement may say an Artifact (for example, a firmware binary) is transparent if it comes with one or more Transparent Statements from its author or owner, though the context should make it clear what type of Signed Statements is expected for a given Artifact.¶

Transparency does not prevent dishonest or compromised Issuers, but it holds them accountable. Any Artifact that may be verified, is subject to scrutiny and auditing by other parties. The Transparency Service provides a history of Statements, which may be made by multiple Issuers, enabling Relying Parties to make informed decisions.¶

Transparency is implemented by providing a consistent, append-only, cryptographically verifiable, publicly available record of entries. A SCITT instance is referred to as a Transparency Service. Implementations of Transparency Services may protect their Append-only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence. A Receipt is an offline, universally-verifiable proof that an entry is registered in the Append-only Log. Requesting a receipt can result in the production of a new receipt for the same signed statement. A Receipt's verification key, signing algorithm, validity period, header parameters or other claims MAY change each time a Receipt is produced.¶

Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent Statements registered by each Issuer. However, the Registrations on a separate Transparency Service is generally disjoint, though it is possible to take a Transparent Statement (i.e. a Signed Statement with a Receipt in its unprotected header, from a from the first Transparency Service) and register it on another Transparency Service, where the second Receipt will be over the first Receipt in the unprotected header.¶

Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements. Similarly, reputable Transparency Services are incentivized to secure their Append-only Log, as any inconsistency can easily be pinpointed by any Auditor with read access to the Transparency Service.¶

The building blocks defined in SCITT are intended to support applications in any supply chain that produces or relies upon digital Artifacts, from the build and supply of software and IoT devices to advanced manufacturing and food supply.¶

SCITT is a generalization of Certificate Transparency (CT) [RFC9162], which can be interpreted as a transparency architecture for the supply chain of X.509 certificates. Considering CT in terms of SCITT:¶

• CAs (Issuers) sign the ASN.1 DER encoded tbsCertificate structure to produce an X.509 certificate (Signed Statements)¶

• CAs submit the certificates to one or more CT logs (Transparency Services)¶

• CT logs produce Signed Certificate Timestamps (Transparent Statements)¶

• Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties¶

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

4. Architecture Overview

The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for issuing and registering Signed Statements, and auditing Transparent Statements.¶

In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document [I-D.draft-ietf-cose-merkle-tree-proofs].¶

Figure 1 illustrates the roles and processes that comprise a Transparency Service independent of any one use case.¶

This section describes the three main roles and associated processes in SCITT:¶

• Issuers that use their credentials to create Signed Statements about Artifacts¶

• Transparency Services that evaluate Signed Statements against Registration Policies, producing Receipts upon successful Registration. The returned Receipt may be combined with the Signed Statement to create a Transparent Statement.¶

• Relying Parties that:¶

  • collect Receipts of Signed Statements for subsequent registration of Transparent Statements;¶

  • retrieve Transparent Statements for analysis of Statements about Artifacts themselves (e.g. verification);¶

  • or replay all the Transparent Statements to check for the consistency of the Transparency Service's Append-only Log (e.g. auditing)¶

In addition, Figure 1 illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement MAY be registered with one or more Transparency Service. Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services.¶

The arrows indicate the flow of information.¶

The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and Transparent Statements in more detail.¶

Signed_Statement = #6.18(COSE_Sign1)
Receipt = #6.18(COSE_Sign1)

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

Protected_Header = {
  &(CWT_Claims: 15) => CWT_Claims
  ? &(alg: 1) => int
  ? &(content_type: 3) => tstr / uint
  ? &(kid: 4) => bstr
  ? &(x5t: 34) => COSE_CertHash
  * int => any
}

CWT_Claims = {
  &(iss: 1) => tstr
  &(sub: 2) => tstr
  * int => any
}

Unprotected_Header = {
  ? &(x5chain: 33) => COSE_X509
  ? &(receipts: 394)  => [+ Receipt]
  * int => any
}

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

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

Transparent_Statement = #6.18(COSE_Sign1)

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

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

18(                                 / COSE Sign 1                   /
    [
      h'a4012604...6d706c65',       / Protected                     /
      {                             / Unprotected                   /
        -222: {                     / Proofs                        /
          -1: [                     / Inclusion proofs (1)          /
            h'83080783...32568964', / Inclusion proof 1             /
          ]
        },
      },
      nil,                          / Detached payload              /
      h'10f6b12a...4191f9d2'        / Signature                     /
    ]
)

{                                   / Protected                     /
  1: -7,                            / Algorithm                     /
  4: h'50685f55...50523255',        / Key identifier                /
  -111: 1,                          / Verifiable Data Structure     /
  15: {                             / CWT Claims                    /
    1: transparency.vendor.example, / Issuer                        /
    2: vendor.product.example,      / Subject                       /
  }
}

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

5. Privacy Considerations

Transparency Services MAY support anonymous access. Issuers SHOULD ensure Signed Statements submitted to public access services are acceptable for public disclosure. Publicly accessible Signed Statements MUST NOT carry confidential information. Once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. In some deployments, a special role, such as an Auditor, might require access to Signed Statements.¶

6. Security Considerations

On its own, verifying a Transparent Statement does not guarantee that its Envelope or contents are trustworthy. Just that they have been signed by the apparent Issuer and counter-signed by the Transparency Service. If the Relying Party trusts the Issuer, after validation of the Issuer identity, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose. If the Relying Party trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log. Unless advertised in the Transparency Service Registration Policy, the Relying Party cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance.¶

Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or remediation mechanism in case one of these Transparent Statements turned out to be misleading or malicious. Just that signed evidence will be available to support them.¶

An Issuer that knows of a changed state of quality for an Artifact, SHOULD Register a new Signed Statement, using the same 15 CWT iss and sub Claims.¶

Issuers MUST ensure that the Statement payloads in their Signed Statements are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause Relying Parties to interpret the Signed Statement as valid for some other purpose.¶

Issuers and Transparency Services MUST carefully protect their private signing keys and avoid these keys being used for any purpose not described in this architecture document. In cases where key re-use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement.¶

For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).¶

The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance [PBFT] and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc.¶

Issuers and Transparency Services MUST rotate their keys in well-defined cryptoperiods, see [KEY-MANAGEMENT].¶

A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote attestation of the hardware platforms and/or software Trusted Computing Bases (TCB) that run the Transparency Service. If present, these additional authenticity assurances MUST be registered in the Append-only Log and MUST always be exposed by the Transparency Services' APIs. An example of Signed Statement's payloads that can improve authenticity assurances are trustworthiness assessments that are RATS Conceptual Messages, such as Evidence, Endorsements, or corresponding Attestation Results (see [RFC9334]).¶

For example, if a Transparency Service is implemented using a set of redundant replicas, each running within its own hardware-protected trusted execution environments (TEEs), then each replica can provide fresh Evidence or fresh Attestation Results about its TEEs. The respective Evidence can show, for example, the binding of the hardware platform to the software that runs the Transparency Service, the long-term public key of the service, or the key used by the replica for signing Receipts. The respective Attestation Result, for example, can show that the remote attestation Evidence was appraised by a Relying Party and complies with well-known Reference Values and Endorsements.¶

Auditors should be aware that the certification path information included in an unprotected x5chain header of a to-be-registered Signed Statement can be tampered with by a malicious Transparency Service (e.g., one that does not incorporate remote attestation), which may replace the intermediate certificates and ultimately connect to an unexpected root. This modification helps protect against person-in-the-middle attacks, but not denial-of-service. Auditors MUST perform certification path validation in accordance with PKIX rules specified in [RFC5280]. In particular, Auditors MUST verify that certification paths chain to one or more trust anchors (often represented as root certificates).¶

7. IANA Considerations

8. References

Appendix A. Common Terminology Disambiguation

This document has been developed in coordination with the COSE, OAUTH and RATS WG and uses terminology common to these working groups.¶

This document uses the terms "Issuer", and "Subject" as described in [RFC8392], however the usage is consistent with the broader interpretation of these terms in both JOSE and COSE, and in particular, the guidance in [RFC8725] generally applies the COSE equivalent terms with consistent semantics.¶

The terms "verifier" and "Relying Party" are used interchangeably through the document. While these terms are related to "Verifier" and "Relying Party" as used in [RFC9334], they do not imply the processing of RATS conceptual messages, such as Evidence or Attestation Results that are specific to remote attestation. A SCITT "verifier" and "Relying Party" and "Issuer" of Receipts or Statements might take on the role of a RATS "Attester". Correspondingly, all RATS conceptual messages, such as Evidence and Attestation Results, can be the content of SCITT Statements and a SCITT "verifier" can also take on the role of a RATS "Verifier" to, for example, conduct the procedure of Appraisal of Evidence as a part of a SCITT "verifier"'s verification capabilities.¶

The terms "Claim" and "Statement" are used throughout this document, where Claim is consistent with the usage in [I-D.draft-ietf-rats-eat] and [RFC7523], and Statement is reserved for any arbitrary bytes, possibly identified with a media type, about which the Claims are made.¶

The term "Subject" provides an identifier of the Issuer's choosing to refer to a given Artifact, and ensures that all associated Statements can be attributed to the identifier chosen by the Issuer.¶

In simpler language, a SCITT Statement could be some vendor-specific software bill of materials (SBOM), results from a model checker, static analyzer, or RATS Evidence about the authenticity of an SBOM creation process, where the Issuer identifies themselves using the iss Claim, and the specific software that was analyzed as the Subject using the sub Claim.¶

In [RFC7523], the Authorization Server (AS) verifies Private Key JWT client authentication requests, and issues access tokens to clients configured to use "urn:ietf:params:oauth:client-assertion-type:jwt-bearer". This means the AS initially acts as a "verifier" of the authentication credentials in form of a JWT, and then later as an "Issuer" of access and refresh tokens. This mirrors how Signed Statements are verified before Receipts are issued by a Transparency Service. Note that the use of [RFC7523] is only one possible approach for client authentication in OAuth.¶

[FIPS.201] defines "assertion" as "A verifiable statement from an IdP to an RP that contains information about an end user".¶

[NIST.SP.800-63-3] defines "assertion" as "A statement from a verifier to an RP that contains information about a subscriber. Assertions may also contain verified attributes."¶

This document uses the term Statement to refer to potentially unsecured data and associated Claims, and Signed Statement and Receipt to refer to assertions from an Issuer, or the Transparency Service.¶

[NIST.SP.1800-19] defines "attestation" as "The process of providing a digital signature for a set of measurements securely stored in hardware, and then having the requester validate the signature and the set of measurements."¶

NIST guidance "Software Supply Chain Security Guidance EO 14028" uses the definition from [ISO.17000.2020], which states that an "attestation" is "The issue of a statement, based on a decision, that fulfillment of specified requirements has been demonstrated.". In the RATS context, a "NIST attestation" is similar to a RATS "Endorsement". Occasionally, RATS Evidence and RATS Attestation Results or the procedures of creating these conceptual messages are referred to as "attestation" or (in cases of the use as a verb) "to attest". The stand-alone use of "attestation" and "to attest" is discouraged outside a well-defined context, such as specification text that highlights the application of terminology, explicitly. Correspondingly, it is often useful for the intended audience to qualify the term "attestation" to avoid confusion and ambiguity.¶

Appendix B. Identifiers

This section provides informative examples of identifiers for Statements, Signed Statements, and Receipts.¶

SCITT Identifiers are primarily meant to be understood by humans and secondarily meant to be understood by machines, as such we define text encodings for message identifiers first, and then provide binary translations according to standard transformations for URLs and URNs to binary formats.¶

SCITT Identifiers for URLs and URNs that are not Data URLs MUST be represented in binary using [I-D.draft-ietf-core-href].¶

For each SCITT conceptual message, we define a Data URL format according to [RFC2397], a URN format according to [RFC8141] and a URL format according to [URLs].¶

Note that Data URLs require base64 encoding, but the URN definitions require base64url encoding.¶

Resolution and dereferencing of these identifiers is out of scope for this document, and can be implemented by any concrete api implementing the abstract interface defined as follows:¶

resource: content-type = dereference(identifier: identifier-type)

These identifiers MAY be present in a tstr field that does not otherwise restrict the string in ways that prevent a URN or URL from being present.¶

This includes iss, and sub which are used to express the Issuer and Subject of a Signed Statement or Receipt.¶

This also includes kid which is used to express a hint for which public key should be used to verify a signature.¶

All SCITT identifiers share common parameters to promote interoperability:¶

Let hash-name be an algorithm name registered in [IANA.named-information].¶

To promote interoperability, the hash-name MUST be "sha-256".¶

Let base-encoding, be a base encoding defined in [RFC4648].¶

To promote interoperability, the base encoding MUST be "base64url".¶

In the blocks and examples that follow, note '' line wrapping per RFC 8792.¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Appendix C. Signing Statements Remotely

Statements about digital Artifacts, containing digital Artifacts, or structured data regarding any type of Artifacts, can be too large or too sensitive to be send to a remote Transparency Services over the Internet. In these cases a Statement can also be hash, which becomes the payload included in COSE to-be-signed bytes. A Signed Statement (cose-sign1) MUST be produced from the to-be-signed bytes according to Section 4.4 of [RFC9052].¶

Contributors

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

Authors' Addresses