It's not entirely obvious what info should be provided to users that want to enforce an application's sigsum logging. This was discussed previously in the context of age releases, see https://github.com/FiloSottile/age?tab=readme-ov-file#verifying-the-release-....

Here, I'm trying to lay out which information should be there, and why. My angle is to ensure consistency between users (sigsum verifiers) and monitors: if any item accepted by a verifier doesn't live up to expectations, monitors should be able to alert.

1. Submitter pubkey(s), i.e., the keys used for the sigsum leaf signatures.

2. The pubkeys of logs used.

It's essential that users and monitors agree on these keys; or more precisely, monitors must be aware of all submitter keys and all log keys that verifiers are willing to accept.

Previously, I think I've asked if there's a good reason for a sigsum verifier to check the log's signature on a tree head; if we say trust is in the witnesses, why isn't it enough to only verify the cosignatures? I think assurance of monitoring is a good reason. That the item appears logged and properly cosigned by well known and perfectly honest witnesses in some *arbitrary* log is not enough. The verifier really needs a proof of logging in a log with relevant *monitoring* for this application.

3. Suggested witnesses and policy. I think this should be a pretty strong recommendation, because for effective monitoring, the monitor must be aware of the witness policy.

E.g., if a single witness disappears from the monitor's view, that witness could potentially be cosigning a different version of the tree. And whether or not that is a reason for alert depends on the verifier's policy. (See https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202... for details).

A user or organization can of course tweak the policy they use any way they like, but if they do, they ought to also think about operating their own monitoring.

4. The claims implied by a logged item. It aids monitoring if claims can be represented in machine friendly form. E.g., provide a way to download relevant data and metadata for each logged checksum, for archival as well as immediate or future analysis. And specify the expected properties of that data and metadata.

E.g., when doing a binary releases by logging the checksums of executables, the data would be the executable file itself, and metadata could include everything needed to be able to reproducibly recreate that executable from sources. An extended claim could also say that corresponding sources must be properly signed, or even sigsum-logged in turn.

At some point, we should document this properly. Any feedback on this analysis highly appreciated.

/Niels