Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
This is designed on a per-user/key perspective rather than per-project perspective. I'm not sure how a monitor for a single project with releases signed by multiple people would look like, since those people could also sign other unrelated artifacts.
There may be other ways, but I think this case needs an additional level of indirection.
The key owner would need to sign and publish claims, where at a minimum a claim is some machine-readable statement like "the artifact with sha256 hash xxx is an official artifact of the foo project". The key owner would sign such claims, and submit them to the log. And in addition, publish then in a way so that they can be retrieved by hash.
A monitor enumerates signatures of interest, retrieves each corresponding claim, and can then do further verification of claims about projects of interest to the monitor.
On the verifier side, one would need the artifact itself, the claim, and the sigsum proof for that claim. Which gets a bit more unwieldy. If we want to stick to the verifier story that it's an artifact with a "spicy signature", that means that we need to start thinking about bundling claim + proof. Defining a machine-readable claim format might be a can of worms, but I think it can be an important improvement over the current state where the closest thing we have to a claim is the filename of the signed artifact, for which the authenticity story is rather weak.
How do that approach protect against hidden releases?
Can't the key owner just sign a separate "hidden" claim that "artifact with SHA256 hash yyy is an official artifact of the foo project" and give that to a targeted user?
Since presumably in this situation the key owner is adding a lot of other unrelated signatures to the log, the problem seems to be that there is no way to enumerate and inspect all claims from the key owner. The key owner can deny things like "oh that was a signature for our private internal project bar that I cannot share any details on, but I assure you it is not related to foo".
Sigstore kind of "solves" this by allowing storing the data that is signed in the log too. I'm told they will stop support that though, so we need some better mechanism.
For me, the "no hidden releases" feature is the only feature of a transparency log that I'm able to explain to a user.
I can't seem to be able to get around the need for being able to somehow be able to download the checksumed content corresponding to ALL signatures from a particular key. If you cannot access the content for ALL signatures in the log, there is no way to protect against hidden releases, is there? The moment you upload a signature to the log for a checksum on some content that you later forget, all good properties seems lost. This means I have to very careful what I sign going forward, since any mistake will essentially make my current key untrustworthy.
It is okay if I make a mistake and sign some corrupt tarball: I can explain this situation if I still have the corrupt tarball. But if I run a set of commands to sign some artifact that I accidentally remove, then things are really bad for that key.
/Simon