Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
In principle, you need a way to identify and verify the claim the signature is supposed to express. If you're happy with a general claim "this is some software package released by Simon", then you can use the same key. A monitor like the one Rasmus is describing then needs a way to locate all your releases, regardless of project.
But maybe you'd want to make a more precise claim like "this is the authentic version X release of project Y". You could still use a single signing key, if X and Y are included in the signed data (which they typically are, in a somewhat implicit way, embedded in the file name of the top-level directory in the signed tar file).
For the general case, I think it may be beneficial with one level of indirection: Make the claim explicit as some kind of manifest (including hashes and urls for the data relevant to the claim), sign and log that manifest, and provide a service that lets monitors and others look up manifest by the logged checksum. Probably not something you want to design at the moment, though.
But the important thing is that a monitor for your releases needs to know (i) the public key(s) you use when logging, and (ii) how to verify the claim that is implied by a logged entry, starting only from the keyhash and checksum in the entry itself.
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
Using separate keys makes it easier to separate different types of claims. But if the set of projects is small (or rather, the various rules for how to locate corresponding data is small), I think it should work with a single key too.
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Cool! You may want to log reproducibility statements as well, separately from the releases themselves. I wrote down some thoughts about that on https://lists.system-transparency.org/mailman3/hyperkitty/list/st-discuss@li...
It's really nice that you are working out how to assemble our pieces into something working in pratice :-)
Regards, /Niels