Hi,
this is a question that I hope is convered in the literature on
transparency logs, but what meaning do we assign to a single, isolated,
cosignature?
If we have a *sequence* of cosigned tree heads (signed by a particular
witness, ordered by increasing tree size), then each cosignature says that
all tree leafs in previous cosigned trees are present in later
trees. But a sigsum client only sees a single cosigned tree head, not
the sequence. In particular, consider the case of the first cosignature
of a particular witness, with no history.
So what exactly does that signature mean?
I suspect there are maybe some underlying assumptions or policys that
should be spelled out somewhere.
Is this an reasonably accurate description? When I see a leaf node
accompanied by a cosigned treehead and an inclusion proof leading up to
that head, then I expect that the witness will raise some alarm if,
sometime in the future, the log attempts to publish a tree head where
the leaf no longer is present?
In this case, a single cosignature doesn't make any claim about the
state of the log, it just states that the witness has observed this
state, and hence that the witness has the information needed to detect
future inconsistencies. More concisely: An isolated cosignature
(without history) does not make a claim about the state of the log, it
makes a claim about the state of the witness.
Does that make sense?
Regards,
/Niels
Rasmus Dahlberg <rasmus.dahlberg(a)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
