iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A public key packaged inside a receipt bundle can show that a signature matches that key. It cannot show that the key belongs to a signer you should trust. The bundle is unauthenticated input until something outside it establishes trust: a root certificate you accept, a key your policy pins, a verification key a transparency service publishes, or a configured identity. RFC 9943 states the requirement directly: a Relying Party MUST trust the verification key or certificate and the associated identity of at least one Issuer of a Receipt (RFC 9943). For X.509 signed statements, the same standard requires a complete certification path to a root that the transparency service has registered as a trust anchor.
Three separate questions a verifier must answer
A receipt review mixes up three different results that tools often report as one “valid” status. Keep them apart, because each one is answered by different evidence.
1. Does the signature verify under this key?
This is a cryptographic check. The verifier rebuilds the signed input exactly as the format defines it, then checks the signature against the candidate public key. A pass means the signature matches that key and the signed bytes are unchanged. It says nothing about who holds the private key.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →2. Is this key tied to an identity that is trusted for this purpose?
This is a trust-establishment check. The verifier needs a path from the key to something it already accepts: a certificate chain to a configured root, a pinned key, an identity provider, or a local allowlist. It then checks the identity, the role, any constraints on the certificate, validity periods, and the policy that governs this use case. A key that arrives inside the same bundle as the signature is the thing being evaluated, so it cannot also be the evidence that vouches for itself.
#1 Best Overall
3. What does the receipt prove?
A transparency receipt is a separate signed object. Its signature and inclusion proof must be checked against the expected transparency service and data structure. A valid receipt establishes the property the log is specified to provide, such as that a statement was registered at a given position. It does not establish that the statement is true, that the issuer is honest, or that the issuer is authorized for your purpose. RFC 9943 says that transparency does not prevent dishonest or compromised Issuers, but it holds them accountable.
Where the key comes from in each format
The same-looking field can mean different things depending on how the format delivers verification material. The table below compares the four cases covered by the standards and official documentation reviewed for this article, as of October 2026.
| Format or profile | Form of key material in the bundle | What makes the key acceptable | Object the key checks | Proof checked beyond the signature |
|---|---|---|---|---|
| SCITT (RFC 9943) | Receipt issuer verification key or certificate, plus the associated issuer identity | The relying party must trust it. For X.509 statements, a complete certification path to a root registered as a transparency service trust anchor. | Signed statements and receipts | Receipt validation against the transparency service; the standard does not fix one proof structure for all services |
| Sigstore bundle | Either a certificate, or a public-key identifier that is only a hint to a key delivered out of band | For certificates, a chain to a root the verifier accepts. For a public-key identifier, a key obtained through an agreed out-of-band source. | The signature over the artifact | Transparency-log entries are encouraged for public use but are not required by the bundle specification; timestamp evidence is required for short-lived certificates verified after expiry |
| Microsoft Signing Transparency Ledger receipt (COSE) | Receipt contains a Merkle root, inclusion proof, position, service signature, and optional timestamp | The service’s published verification key, which the verifier must discover and trust independently | The receipt signature, after the leaf is recomputed | Inclusion proof, recomputed from the leaf to a root |
| Apple app receipt (PKCS #7) | Signing certificate inside the PKCS #7 container | A signature chain that traces to the Apple root certificate | The receipt payload | Receipt-specific fields checked after the chain is validated |
How each format handles the key
SCITT: the statement, the receipt, and the trust anchor
In SCITT, the signed statement is the issuer’s claim about an artifact. A receipt is a signed proof of a property of the transparency service’s verifiable data structure. The service maintains trust anchors and authenticates statements through its registration policy. For X.509 statements, validation must reach a root the service has registered. Relying parties must validate the receipt and also trust the verification identity of the receipt issuer. One statement can be registered with more than one service, which produces independent receipts, and each receipt has to be judged against its own service’s keys.
Recommended Free Tools
Sigstore: a key identifier is a pointer, not a key
A Sigstore bundle packages the signature, its verification material, and optional transparency evidence. Verification material can take several forms. A certificate can be embedded, and a short-lived certificate bundle must carry a signed entry timestamp or an RFC 3161 timestamp so that a verifier can show signing happened during the certificate’s validity window, even when verification happens after expiry. A public-key identifier is different. The Sigstore documentation describes it as a hint to identify an out-of-band delivered key to verify a signature. The key itself is not in the bundle, so a verifier who sees only the identifier has no trusted key until it obtains one from an agreed source.
Microsoft’s ledger profile: a receipt key must be discovered separately
Microsoft’s Signing Transparency Ledger documentation shows a concrete receipt flow. The verifier hashes the leaf components, walks the inclusion proof path to reconstruct the Merkle root, and then validates the COSE signature using the service’s published verification key. This shows why the receipt key has to be found and trusted independently: the proof reconstructs a root, but the root is only meaningful once the service signature over it is checked with a key you trust. This is Microsoft’s profile of a receipt, not a universal bundle format, and other transparency services may structure receipts differently.
Apple app receipts: a familiar example of chain-to-root
Apple’s documentation on validating receipts on the device shows the same logic in a familiar setting. The developer decodes the PKCS #7 container and verifies that its signature chain traces to the Apple root certificate. Only after that does the developer check receipt-specific fields. The certificate embedded in the container is therefore checked against a root the developer already trusts, not accepted as its own basis of trust.
A practical review sequence
Apply the following steps in order. Each one depends on the output of the previous one, and a failure at any step means the later results should not be used for a trust decision.
- Identify the signed object and the receipt separately. Record which bytes are the artifact statement, which are the receipt, and which format rules apply to each.
- Verify each required signature. Recompute the signed input as the format specifies and check it against the candidate key. Do this for the statement and, where the format requires it, for the receipt.
- Establish the signer’s trust source before reading the bundle’s claims. For a certificate, build the chain to a root from your own configured trust store or the transparency service’s registered trust anchors. For a key identifier, obtain the key from your agreed out-of-band source. For a receipt, obtain the service’s verification key from its published or configured location.
- Check the identity and constraints. Confirm the identity or role matches what your policy requires, and check certificate validity and any constraints. For short-lived certificates verified after expiry, confirm the timestamp evidence places signing inside the validity window.
- Recompute the inclusion proof. Rebuild the root from the leaf and the proof path. Do not accept a root or proof value the bundle claims without recomputing it.
- Apply local policy. Decide whether this issuer, this artifact type, and this use case are acceptable. Record the decision with the evidence used.
What a successful check does and does not establish
When every step above passes, the result supports a narrow set of conclusions. Treat them as separate claims:
Best Value
- The signature matches the key you checked, and the signed bytes were not altered after signing.
- The key is tied to an identity or role through a trust source you chose, under the constraints you checked.
- The statement was registered with the transparency service at a recorded position, and the service’s receipt signature covers that position.
- The statement is not proven true, the issuer is not proven honest, and the artifact is not proven safe. A specific validation policy can support a narrower claim, but the receipt alone does not.
Failure patterns to recognize
- The key only verifies the bundle’s own signature. This passes the cryptographic step and tells you nothing about trust. Stop before the trust step.
- The identifier resolves to nothing you have configured. A Sigstore public-key identifier with no out-of-band key source leaves the signature unverifiable in a trust sense, even if the identifier looks well formed.
- The chain does not reach a configured root. A self-signed or unknown root inside the bundle is not a trust anchor, regardless of how well the chain is built.
- The receipt is valid but for a different service. A receipt from one transparency service cannot establish trust in a statement registered with another. Check the service identity against your policy.
- The short-lived certificate has expired and no timestamp is present. Without signed timestamp evidence, the verifier cannot show the signature was made during the validity window.
Formats and policies differ. A rule that holds for a Sigstore bundle, an RFC 9943 receipt, or a Microsoft ledger receipt does not transfer automatically to the others, so confirm the format’s own requirements before applying the sequence above.
Primary sources used for the requirements in this article: RFC 9943, An Architecture for Trustworthy and Transparent Digital Supply Chains; Sigstore Bundle Format; Microsoft’s Signing Transparency Ledger concepts; and the Apple developer documentation linked above.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
