Intended usage of rekor

[arewm]

Question

I have recently talked with multiple maintainers of Sigstore about uses of Rekor, but I was wondering if it would be possible to provide concrete guidance on pattern/anti-pattern uses.

One potential use case that I have brought up is searching for available attestations for an artifact. We had wanted to be able to query Rekor for all attestations, but Rekor doesn't guarantee completeness of responses. Therefore, this is presumably an anti-pattern. Can we provide more rationale behind this?

What are the anticipated use cases for Rekor? Is it more intended to provide an existence proof? If I have an attestation, I can look it up in Rekor to see if it exists, its timestamp, etc?

[haydentherapper]

Sorry for the delay in a response. This is a great question, and I'll try to answer this as precisely as possible for future readers as well. Extra thoughts are in footnotes.

I'll split out "Rekor as a transparency log" from "Rekor as a service", as each brings different value.

For "Rekor as a transparency log", the most precise answer I can give is in the claimant model (definition of a claimant model) which describes what each entry in the log means. An entry in Rekor denotes a signing event, a commitment to the usage of an identity or key to generate a signature over an artifact digest. A Verifier (one who can verify the truthfulness of a Claim) can monitor¹ entries in the log that use their own identity/key to discover misuse of an identity/key. A Believer (e.g. an artifact user) verifies an inclusion proof for an artifact and its signature, so that the Believer knows that the Claim can be verified by a Verifier. A Believer will not trust an artifact without a proof or an invalid proof because that means a Verifier couldn't monitor for that entry, so it might have been maliciously generated.

Said simply, "Rekor as a transparency log"'s sole purpose is to discover signature generation².

What about "Rekor as a service"? What I mean by this is that Rekor offers a number of features, namely 1) Attestation storage, 2) Timestamping, and 3) Search index. All of these muddy the primary purpose of Rekor, to be a log of claims. Discussing each:

• Attestation storage: For intoto-v001 and intoto-v002 entries, provided attestations are stored in an attached bucket and returned when entries are requested. An obvious concern is spam, that we're offering free public storage. We'd rather see attestations stored alongside artifacts. The other issue is this frequently gets used as part of online, rather than offline, verification. Offline verification is something we strive for, and that is possible when a client is given an inclusion proof alongside an artifact - verifying a proof is entirely offline and doesn't require requesting a proof from the log, which is a win for privacy and reliability. If a client is relying on Rekor for storage, now Rekor becomes critical path for verification.
• Timestamping: We need timestamps to verify short-lived certificates. Rekor entry "integration time" has been used as a timestamp. Again, this muddies the primary purpose of Rekor (discoverability). The timestamping mechanism is also not independently verifiable, because it relies on an internal clock and it could lie, presenting timestamps for the future or past³. We'd like to move towards RFC3161 timestamp authorities as the providers of timestamps, which is a standardized approach to signed timestamping.
• Search index: This is the service that I am least familiar with how it's currently used, to help decide how we want to evolve this service. Right now, for every uploaded entry, we pull out relevant metadata (e.g. identity, artifact digest, subject value) and upload it to a backend database (MySQL or Redis). As part of Rekor v2 (linked below), we would like to split the search index into its own service, but we would like more information on what users would like from such a service. Do we just need to support lookups by email/identity? Lookups by attestation subject? Is this just a service for curious consumers (meaning we'd offer a far lower SLO)?

The Rekor v2 proposal doc (access granted by being in the sigstore-dev Google group) goes into more detail on splitting these features into their own services. For Rekor v2, we are solely focused on "Rekor as a transparency log", and would like to move each of these service features into dedicated services, for reliability, verifiability, and modularity.

Footnotes

1. Note that "monitoring" is an overloaded term, and can either refer to a Verifier searching for entries in the log, or a "witness" that verifiers the consistency (append-only property) of a log. The latter is critical to the security of an transparency log to prevent split-view attacks, and the transparency ecosystem is working towards having a public witness network. For this post, if I say "monitor", I'm only referring to entry verification. ↩

2. I could have said "publicize signature generation", but this isn't entirely accurate, because Rekor could be deployed within a private organization. This also ignores the primary purpose of a log, which is discoverability/auditability by a monitoring party. ↩

3. We want Rekor to be entirely verifiable - Rekor theoretically could be deployed by a completely untrustworthy party, and as long as a witness verifies consistency, the log would be usable. ↩