Rasmus Dahlberg rasmus.dahlberg@glasklarteknik.se writes:

...

I see one problem with this, though. The monitor can't simply use the ssh-keygen command to verify the signature, since that command expects to get the *message* as input, not the hash thereof. Which kind-of defeats the idea of piggybacking on ssh tools.

I disagree. The value of piggy-backing on SSH tooling is for the signer who can access their private key with good solutions that already exist.

I don't have a very strong opinion, maybe it's "only" a matter of documentation. If we say "sigsum uses the ssh signature format", I would expect that to mean that we use it as a black box with inputs and output according to the spec, but that's not quite what we do.

We could say that we have

checksum = H(message)

and that the essence of the signature is to sign checksum, so that signature can be verified given only the public key and checksum (i.e., without knowing message). And that we do signatures in a way that produces an identical signature as if feeding message as the input of ssh-keygen -Y sign --hashalg=sha256, or M = message in its spec.

...

message=SHA3(data) ; application layer

Note that message must be exactly 32 bytes in Sigsum. So, you wouldn't be able to use SHA3 here

Side note: SHA3_256 is part of the SHA3 standard.

I see your point if it is a desired property to verify leaf signatures in isolation with ssh-keygen. Would you say that the complexity is decreased, about the same, or increased if this change was proposed?

I think conceptual complexity would be decreased slightly, by which I mean roughly that it will be slightly easier to document and explain. For implementation complexity, not much difference (assuming that the only value we see in actually using the ssh-keygen tool for handling signatures is for the private key operations).

Regards, /Niels