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