`KeylessVerifier` cannot verify bundles that use an RFC 3161 timestamp and no transparency-log entry

[anthonydahanne]

I used help from AI to create this issue, but I humanly read it and reviewed/corrected it before submitting it

Why did I create this issue

The concrete case that surfaced this: GitHub artifact attestations produced for a private repository. Those are signed by GitHub's own (non–public-good) Sigstore instance, which does not write to a public transparency log — the bundle carries a TSA timestamp instead. gh attestation verify and cosign (with --use-signed-timestamps --insecure-ignore-tlog) both verify these bundles; sigstore-java cannot.

Summary

KeylessVerifier.verify(...) unconditionally requires at least one Rekor transparency-log entry in the bundle. Sigstore bundles whose verification material contains only an RFC 3161 signed timestamp timestampVerificationData) and no tlogEntries are valid per the bundle spec, but verification fails before the timestamp or signature is ever checked.

Related issues (this is not a duplicate)

• Support validation based on rfc3161 from TSA (vs SET from rekor) #699 added RFC 3161 TSA validation, but only as the source of trusted time; the Rekor entry is still mandatory (KeylessVerifier calls bundle.getEntries().get(0)).
  This issue is about verifying bundles that carry no tlogEntries at all — only a TSA timestamp.
• Add validation error for bundles with zero timestamps (SETs or RFC 3161) #980 requires at least one timestamp (SET or RFC 3161) but still assumes a tlog entry is present (Rekor v1 SET vs Rekor v2 + RFC 3161). The private-instance bundles here
  have zero tlog entries.
• Comparability with GitHub Attestations using DSSE #813 concerns uploading attestations to GitHub (DSSE), not verifying tlog-less bundles.
• Provide more info when rekor entries are not found  #374 is error-messaging when rekor entries are absent, not support for verifying without them.

Steps to reproduce

1. Obtain a bundle with timestampVerificationData and no tlogEntries — e.g. an actions/attest-build-provenance attestation from a private GitHub repo (gh attestation download …), plus the matching trust root (gh attestation trusted-root).
2. sigstore-cli verify <artifact> --bundle <bundle> --trusted-root <root> --certificate-identity <san> --certificate-oidc-issuer https://token.actions.githubusercontent.com

Actual behavior

Verification throws while fetching the (absent) Rekor entry — bundle.getEntries().get(0) on an empty list — so it never reaches signature/timestamp verification.

Root cause

In sigstore-java/src/main/java/dev/sigstore/KeylessVerifier.java, the Rekor entry is treated as mandatory:

// findHashAlgorithm(...)
var rekorEntry = bundle.getEntries().get(0);
...
// verify(...)
var rekorEntry = bundle.getEntries().get(0);
...
rekorVerifier.verifyEntry(rekorEntry);   // "Transparency log entry could not be verified"

verifyTimestamps(...) already knows how to verify RFC 3161 timestamps and even guards if (timestamps.isEmpty() && entryTime == null), but it is only reached after the
mandatory Rekor entry has been obtained and verified — so a TSA-only bundle can never get there.

Expected behavior

When a bundle has no tlogEntries but does carry a valid timestampVerificationData (RFC 3161 timestamp from a TSA in the trusted root), KeylessVerifier should verify the Fulcio chain + DSSE/message signature and establish signing time from the TSA timestamp — i.e. treat the transparency-log entry as optional when signed timestamps are present, rather than requiring one. This matches the Sigstore bundle spec, whose verification material permits tlog entries and/or signed timestamps.

Suggested fix

• Make findHashAlgorithm / verify tolerate an empty bundle.getEntries():
• derive the hash algorithm without a Rekor entry when none is present (e.g. from the DSSE payload / message-signature algorithm), and
• skip rekorVerifier.verifyEntry(...) when there is no entry, relying on verifyTimestamps(...) (TSA) for the trusted signing time.
• Keep requiring at least one source of trusted time (tlog SET or RFC 3161 timestamp), which verifyTimestamps already enforces.

References / prior art

• Sigstore bundle spec: verification material may be a transparency-log entry, a signed timestamp, or both.
• cosign verify-blob-attestation verifies the same bundles with --use-signed-timestamps --insecure-ignore-tlog (+ --trusted-root); gh attestation verify verifies them natively.

[anthonydahanne]

I can provide examples, and even a PR if you think sigstore-java should be able to verify non public attestations

[loosebazooka]

I mean depends on how you're using it. This was designed around the public instance. However there is scope to allow "VerificationOptions" to be more configurable.

[loosebazooka]

Also as far as attestations go, sigstore-java can only verify the signature and is not designed to interpret the content of the underlying attestation.

[anthonydahanne]

Hello @loosebazooka !
Thanks for your quick answers!

Also as far as attestations go, sigstore-java can only verify the signature and is not designed to interpret the content of the underlying attestation.

Yes, agreed

I mean depends on how you're using it. This was designed around the public instance. However there is scope to allow "VerificationOptions" to be more configurable.

Right, I understand that (designed around "public-good" instance).
So adding the possibility for sigstore-java to verify "others" would, I think, make it even greater:

• there are many (big) organizations (Broadcom, ChainGuard) signing attestations using Github private log
• cosign supports it!

cosign verify-blob-attestation \                                                               
    --bundle dom4j-1.6.1-dom4j-1.6.4.sigstore.json \
    --trusted-root root-ab \
    --use-signed-timestamps \
    --insecure-ignore-tlog \
    --insecure-ignore-sct \
    --type slsaprovenance1 \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --certificate-identity-regexp '^https://github.com/xxx/' \
    dom4j-1.6.1-dom4j-1.6.4.jar
WARNING: Skipping tlog verification is an insecure practice that lacks transparency and auditability verification for the blob attestation.
Verified OK

[anthonydahanne]

Let me draft a PR with a sample private GH build, I'll make it so that it integrates well with the existing codebase

[loosebazooka]

yeah, I think you want to:

1. Add an option to VerificationOptions to set the int threshold of tlog entries we expect.
   • alternatively, VerificationOptions.TlogOptions could just have boolean enabled. Then we don't have to deal with the multi log case yet. Might ease the coding burden
2. Plumb that through keyless verifier (I haven't looked into how much we expect a tlog entry to exist, but I think it's concentrated to a few places).
3. Add some tests

[loosebazooka]

Actually the code extracts quite a bit of information from the rekor entry. It need some restructuring.

[anthonydahanne]

thanks @loosebazooka for your comments!

I've created a draft PR there: #1252

I'll add tests before removing draft status; at least one integration test with attestation from GH private log

Meanwhile, please have a look, and tell me if I'm on the right track!