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/20…
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
