Hi all,
In WEBCAT we're adding support for multiple signatures over the same artifact (a manifest). How we log that depends on the monitoring story.
One (probably not great) option would be to sign the artifact once with a known key (which one, though?) and log that artifact that includes the N signatures once in Sigsum. The downside is that the Sigsum leaf would then be discoverable only via the submitting key, not by the individual signer keys.
If we want per-key transparency, we should instead submit each signature over the artifact to Sigsum and get a proof for each. That seems best for monitoring and seems to be the least hacky design.
Assuming all signatures (and proofs) need to adhere to the same trust policy, there's a lot of duplication when gathering individual proofs. My understanding is that we can wait until all leaves are included in the same tree, collect a single cosigned tree head (STH), and verify the log signature and cosignatures once. Each leaf will have its own inclusion path, but many hashes will overlap. This reduces verification work (one STH validation instead of N) and total size on the wire.
Does this usage make sense? For a first step, I'd like to just fetch per-leaf proofs for the same tree size so I can reuse the same STH, without trying to merge paths yet. If that sounds reasonable, is this a mode of operation Sigsum would be interested in supporting in the client (i.e., worth a PR), or should I implement it on top using the log APIs directly?
Thanks! Giulio
Giulio via Sigsum-general sigsum-general@lists.sigsum.org writes:
If we want per-key transparency, we should instead submit each signature over the artifact to Sigsum and get a proof for each. That seems best for monitoring and seems to be the least hacky design.
If each key-holder wants key usage transparency for their key, I think that's the way you have to do it.
When submitting the same item using different signing keys, you could also think about monitoring the log for other entries with the same checksum. I don't know if there's anything useful that could come from that; I think you'd still need to know all relevant key hashes, to be able to ignore entries from other people submitting the same item.
Does this usage make sense? For a first step, I'd like to just fetch per-leaf proofs for the same tree size so I can reuse the same STH, without trying to merge paths yet. If that sounds reasonable, is this a mode of operation Sigsum would be interested in supporting in the client (i.e., worth a PR), or should I implement it on top using the log APIs directly?
I think generating proofs corresponding to a shared tree head is generally useful. I haven't though about ways to also compact the inclusion proofs.
For the same tree head, this could be a feature of sigsum-submit (which already is rather complex). Or you could use sigsum-submit to get the entries into the log(s), and then have a separate tool that collects new proofs. For a separate tool, one could consider a sigsum-submit mode that submits items and waits for a 200 response to each leaf request, and for each item only outputs the log that it was committed to.
Keep in mind that a policy can specify multiple logs, so when you submit a bunch of entries, they can be spread out between logs. Not sure if it would work for you to have a "merged proof" with one tree head per log, and then a number of inclusion proofs for each of those tree heads.
Regards, /Niels
Thanks for your response.
On 23/10/25 10:43, Niels Möller via Sigsum-general wrote:
I think generating proofs corresponding to a shared tree head is generally useful. I haven't though about ways to also compact the inclusion proofs.
For the same tree head, this could be a feature of sigsum-submit (which already is rather complex). Or you could use sigsum-submit to get the entries into the log(s), and then have a separate tool that collects new proofs. For a separate tool, one could consider a sigsum-submit mode that submits items and waits for a 200 response to each leaf request, and for each item only outputs the log that it was committed to.
Thanks, it makes sense. I think here's what I'll do. Given what you say about sigsum-submit, I’d rather write a separate tool that mainly interacts with the log. Since we also need to fetch STHs programmatically for the "timestamping" use case, it could also handle fetching newer proofs for older entries, and collecting multiple proofs for either the most recent STH or a specified one.
I'll prototype it in Go using the existing components, so that later it can be decided whether it makes sense to merge it as an additional utility or keep it elsewhere.
Cheers, Giulio
Giulio giulio@anche.no writes:
and collecting multiple proofs for either the most recent STH or a specified one.
Note that you can't ask the log server for anything but the most recent treehead, and signature and cosignatures for previous treeheads are not archived by the system. So if you want to use a specific signed treehead, you'd need to archive it yourself.
I'll prototype it in Go using the existing components, so that later it can be decided whether it makes sense to merge it as an additional utility or keep it elsewhere.
Sounds good to get some practical experience before considering if and how to integrate it in the existing tools.
Regards, /Niels
sigsum-general@lists.sigsum.org
-
Giulio -
Niels Möller