Microsoft's Signing Transparency Ledger concepts

This article explains the technical concepts and prerequisites for understanding and working with Microsoft's Signing Transparency Ledger. For an overview of the service and its benefits, see About Microsoft's Signing Transparency Ledger.

SCITT standards and COSE envelope

Microsoft's Signing Transparency Ledger uses COSE (CBOR Object Signing and Encryption) envelopes that comply with the SCITT standard for receipts.

When a developer or automated build system signs code, the signing service generates a COSE_Sign1 signature envelope conforming to RFC 9052. COSE_Sign1 is a compact binary signing format designed for efficient transmission and storage. The envelope contains the cryptographic signature, signing metadata (algorithm, key identifiers, timestamps), and the signed payload (or a reference to it).

COSE envelope structure

The COSE_Sign1 envelope contains:

• Protected headers: Include algorithm information and key identifiers.
• Unprotected headers: Contain additional metadata not covered by the signature.
• Payload: The signed content (which can be detached for efficiency).
• Signature: Cryptographic signature computed over the protected headers and payload.

Signed statements

Signed statements are cryptographically signed payloads that describe an artifact, such as a software build, SBOM, or compliance claim. They:

• Capture verifiable metadata about an artifact.
• Are signed by the issuer to ensure authenticity.
• Can be validated independently by any consumer.
• Serve as the primary input to the transparency service.

Any modification to the statement invalidates its signature, ensuring the claim can't be altered without detection.

Registration and transparency logging

Registration is the process of submitting a signed statement to the transparency service, where it's recorded in an append-only log. This process:

• Ensures the statement is immutably recorded.
• Assigns a unique identifier to the submission.
• Enables independent audit and traceability.
• Prevents deletion or retroactive modification.

Once registered, the statement becomes part of a tamper-evident ledger that any party can verify.

Receipts and inclusion proofs

A receipt is generated by the transparency service after a statement is registered, providing proof of inclusion in the ledger. The receipt:

• Confirms the statement was accepted by the service.
• Includes cryptographic proof of inclusion in the log.
• Can be verified independently without trusting the service.
• Links the statement to a specific point in the ledger.

Any change to the statement or the receipt invalidates the proof, making tampering immediately detectable. For the receipt's wire format and how a verifier walks the inclusion proof, see Receipt composition.

Transparent statements

A transparent statement combines a signed statement with its corresponding receipt to create a fully verifiable artifact. This combination:

• Bundles both the claim and its proof of registration.
• Enables end-to-end verification by external parties.
• Supports sharing across systems and organizations.
• Provides a durable, audit-ready record of integrity.

Any inconsistency between the statement and receipt invalidates the transparency guarantees.

Issuers and identity

Issuers are the entities that create and sign statements, such as build systems, services, or organizations. Their role:

• Establishes the origin of a claim.
• Provides cryptographic identity through signing keys.
• Enables trust decisions by consumers.
• Supports traceability across supply chain events.

If an issuer's identity can't be verified, the associated statements can't be trusted.

Verification keys and trust discovery

Verification keys are used to validate signatures on statements and receipts, and they're retrieved through discovery mechanisms. These keys:

• Allow independent validation of issuer signatures.
• Enable automated trust establishment.
• Support key rotation and lifecycle management.
• Are exposed via standardized service endpoints.

Without access to trusted verification keys, consumers can't reliably verify integrity or origin.

Receipt composition

The transparency service generates a cryptographic receipt for each recorded signing event. The receipt enables anyone to independently verify that:

• The signing event was logged at a specific position.
• The entry hasn't been modified since recording.
• The transparency service attests to the signing event.
• The artifact passed the service's trust policy checks.

This receipt serves as a verifiable proof and contains:

• Merkle tree root: The root hash at the time the entry was added.
• Inclusion proof: The path of hashes proving the entry exists in the tree.
• Position: The entry's location in the ledger (transaction ID).
• Service signature: Cryptographic signature from the transparency service.
• Timestamp: When the signing service added a timestamp (optional).

The receipt is a COSE_Sign1 signature whose payload is detached. The detached payload is the Merkle root, which the verifier reconstructs from the inclusion-proof path before validating the signature. Forcing reconstruction prevents a class of implementation bugs where a verifier trusts a payload value the service supplied directly instead of recomputing it from the proof.

Conceptually, verification proceeds in three steps:

1. Hash the leaf's three components (internal-transaction-hash, internal-evidence, data-hash) to produce a leaf hash.
2. Walk the proof path, combining the running hash with each sibling using the path's left/right bit, to recompute the Merkle root.
3. Verify the COSE signature over the recomputed root by using the service's published verification key.

For the formal algorithm, see Section 3.2 of draft-ietf-scitt-receipts-ccf-profile and the CCF receipt verification reference.

Registration policies

Registration policies define the rules that govern which statements can be accepted by the transparency service. These policies:

• Enforce schema and format requirements.
• Restrict which issuers are allowed to submit.
• Ensure compliance with organizational or regulatory constraints.
• Maintain consistency and quality of recorded data.

Statements that don't meet policy requirements are rejected, preventing invalid or malicious entries. Audit the policy configurations to confirm transparent statements. For the SCITT application's policy configuration format, see scitt-ccf-ledger configuration documentation.

Registration policies are evaluated inside the Trusted Execution Environment that runs the transparency service. Because the policy code itself runs in the TEE alongside the receipt-signing keys, an operator can't bypass policy checks for individual submissions without compromising the TEE platform — and any such compromise is detectable through TEE attestation. Auditors can confirm which policy was applied to a given submission by inspecting the corresponding registration event in the ledger.

Merkle tree and ledger structure

The transparency ledger uses a Merkle tree, which provides:

• Append-only structure: New signing events become leaves in the tree.
• Cryptographic updates: The tree's root hash cryptographically updates with each entry.
• Compact proofs: Merkle structure provides verifiable proof of inclusion for each entry.
• Immutability: No entry can be altered or removed without breaking cryptographic links.

When you add a new entry, the system computes a new Merkle root. The service cryptographically signs this root and packages it with the path of hashes that prove the entry's inclusion. The service returns this package as a receipt to the user. This process is similar to how Azure confidential ledger write transaction receipts work.

Verifiable data structure profile

The Signing Transparency ledger is a verifiable data structure (VDS) as defined by the IETF SCITT working group. Specifically, it uses the CCF_LEDGER_SHA256 profile from CCF Profile for COSE Receipts (draft-ietf-scitt-receipts-ccf-profile), which extends the generic COSE Receipts tree-algorithm registry with a CCF-specific entry.

CCF requires its own VDS profile (rather than reusing the RFC 9162 Certificate Transparency profile) for two reasons:

• Detailed system audit: Each leaf binds the full CCF transaction record, not just the signed statement. This binding lets auditors verify the entire tree contents, including CCF-internal state changes, while leaving normal verifiers unaffected.
• TEE-aware early persistence: CCF nodes run inside Trusted Execution Environments with limited memory. The leaf format lets nodes persist signatures to storage before distributed consensus completes, while still gating receipt issuance on full commit.

CCF leaf components

Each leaf in the CCF Merkle tree contains three components:

• data-hash: SHA-256 hash of the application data — that is, the signed statement submitted to the service. This is the value that ordinary verifiers care about.
• internal-transaction-hash: Hash of the full CCF ledger entry (KV writes, governance state, and so on). It commits the service to the entire tree contents and supports CCF-specific deep audit. Normal verifiers can safely ignore it.
• internal-evidence: A revealable commit-evidence value (≤ 1024 bytes). It lets a TEE node persist the leaf to disk before the distributed consensus protocol has confirmed the transaction, then reveal the evidence once commit is established.

Azure confidential ledger and CCF backing

Under the hood, the Signing Transparency ledger uses:

• Azure confidential ledger platform: Provides tamper-evident storage by using Azure Confidential Computing.
• Confidential Consortium Framework (CCF): Runs in a Trusted Execution Environment (TEE).
• Secure enclaves: Keys are created in secure confidential computing enclaves (AMD SEV-SNP) and never leave them.

Each ledger entry contains details about the signing event:

• Service submitted build information: Build context submitted by the owning service.
• Measurements of the service being run in production: Enclave or workload measurements captured at signing time.
• Original signature: The initial signature from the code signing operation.
• Signer identity: Information about who performed the signing.
• Countersignature (actually a receipt): Signature applied by the transparency service.
• Timestamp: When the signing service added a timestamp (optional).
• Service ID: A service's identifier.

Because the ledger uses confidential computing, the owning service is transparent, and users can attempt to reproduce what runs in production. This transparency builds trust in the verification process and the registration policies the ledger enforces. Auditors can review registration events to confirm that each entry was processed under a specific policy and that the Microsoft owning service can't conceal or subvert that process.

Asynchronous processing and status tracking

Some operations, such as statement registration, might be processed asynchronously by the service. This model:

• Allows the service to scale for high-volume submissions.
• Returns an acceptance response before completion.
• Requires clients to query status or retrieve results later.
• Decouples submission from final verification artifacts.

If processing hasn't completed, a receipt might not yet be available until the operation finishes.

Transparency service endpoints

The transparency service exposes REST APIs that enable interaction with the system. These endpoints:

• Allow submission of signed statements for registration.
• Support retrieval of receipts and verification data.
• Provide access to issuer verification keys.
• Enable querying of registration status.

Incorrect usage of endpoints results in standardized HTTP errors, ensuring predictable client behavior.

SCITT SCRAPI status codes

The transparency service returns standard HTTP status codes in response to SCRAPI (SCITT Reference APIs) requests, as defined in draft-ietf-scitt-scrapi. Use this table to interpret responses when calling the service directly or when the ledger explorer surfaces an HTTP error.

Tamper detection and auditability

The system is designed to detect any unauthorized modification to statements or proofs. This capability:

• Relies on cryptographic signatures and inclusion proofs.
• Ensures all records are immutable once logged.
• Enables independent verification by any party.
• Supports forensic auditing and compliance scenarios.

Any attempt to alter data breaks the cryptographic chain of trust, making tampering immediately visible.

TEE attestation is the second pillar of tamper detection. The service publishes attestation evidence for every node in the ledger and from the network itself. Clients should periodically:

• Fetch attestation evidence and confirm nodes are running trusted, up-to-date platform components.
• Audit the ledger for consistency between successive receipts you've collected.

A compromise of the TEE platform could in principle let an attacker produce divergent ledger branches; consistent attestation plus regular consistency audits make any such divergence detectable.

Service continuity and successor networks

CCF supports recovering a network after catastrophic node failure by starting a successor network that endorses the prior ledger state. The successor has its own service identity but preserves continuity of the recorded history.

This recovery mechanism creates one residual risk worth understanding: a malicious operator could initialize a successor network from an earlier prefix of the ledger, effectively truncating later entries. The IETF CCF profile recommends two client-side mitigations:

• Audit successor ledgers when the service identity changes. Verify that receipts you previously obtained from the prior service are still included in the successor's ledger.
• Track service identity transitions through the ledger's governance entries so any unannounced or unexplained successor is immediately visible.

Together with TEE attestation, these mitigations preserve tamper-evidence across recovery events.

Trust establishment mechanisms

For services like Microsoft Azure Attestation (MAA), consumers can establish trust through multiple mechanisms:

1. Verify token generation: Confirm Azure Attestation generates the attestation token.
2. Verify enclave execution: Confirm the service runs inside a secure SGX enclave or SEV-SNP container.
3. Validate TEE binding: Validate binding of the TEE report with the key that signed the attestation token.
4. Validate code measurements: Confirm code measurements match Azure published values.
5. Verify transparency record: Use Signing Transparency to verify the build and release payload to match it to the service's secure enclave measurements running in production (for example, embedded in the MAA signing certificate).

Prerequisites for verification

To verify signatures in the Signing Transparency ledger, services must meet these prerequisites:

• Dedicated key: The Azure service must have a dedicated signing key for ESRP signing (no key sharing).
• Transparent signing: Payloads must be transparently signed in production build pipelines by using the dedicated key.
• Production MST instance: The service must be registered with an existing production MST instance managed by ESRP.
• Documentation: Each integrating service must provide details for verifiers to locate their entries:
  • Issuer details such as the EKU (Extended Key Usage) used in the signing key.
  • The Subject value(s) used during signing.

EKU and Subject identifiers

Extended Key Usage (EKU): Used in the signing key and present in the transparent statement as part of the issuer string. You can retrieve the value by inspecting the signing certificate.

Subject: Used by the service when transparently signing. A single service might have multiple subject values.

You can retrieve these values by parsing the transparent statement with tools such as COSE Viewer or CBOR Viewer.

Service identifiers for supported services

Use the identifiers for the service you want to search when filtering entries in the ledger explorer or CCF scripts.

For step-by-step instructions on how to verify signatures using the ledger explorer or CCF scripts, see Verify ledger integrity and inspect entries.

Glossary

Next steps

• About Microsoft's Signing Transparency Ledger
• Usage: payloads, claims, and auditing
• Verify ledger integrity and inspect entries
• Troubleshoot Microsoft's Signing Transparency Ledger
• Learn about Azure confidential ledger
• Learn about Confidential Consortium Framework
• SCITT application source code (microsoft/scitt-ccf-ledger)
• SCITT Architecture (draft-ietf-scitt-architecture)
• COSE Receipts (draft-ietf-cose-merkle-tree-proofs)
• CCF Profile for COSE Receipts (draft-ietf-scitt-receipts-ccf-profile)
• SCITT Reference APIs (draft-ietf-scitt-scrapi)