Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Btw, I plan to use my OpenPGP authentication key (i.e., not the signature key) from my Gnuk hardware dongle, exported via GnuPG's SSH agent, for use by sigsum-submit --signing-key to create *.proof. Does anyone see a problem with this? I don't know how to make my OpenPGP signature key from the Gnuk available via the SSH agent easily, has anyone done that? I haven't thought through the flow here. The threat I'm worried about is if some remote SSH server abuse my setup to make me sign some blob that may later be submitted to the Sigsum transparency log as a release signature? Is there sufficient domain context separation happening here? It doesn't feel intuitively safe.
To answer domain separation: I think there's domain separation between sigsum leaf signatures and signatures involved in *proper* ssh public key user authentication. But the ssh-agent protocol lets the client sign arbitrary data, so if you expose the signing key via ssh-agent (and it sounds like you also do agent forwarding?) to an attacker, the attacker could sign and sigsum log anything on your behalf.
For that reason, it would be preferable to use separate keys for signing, and not expose that key via ssh-agent forwarding to remote machines.
The only good thing is that by monitoring the relevant sigsum logs, you can still discover such key misuse.
Ok great!
This makes me wonder a bit. How big is the benefit to use the same Sigsum private/public key for multiple continous releases?
Could I just generate a fresh key, sign, and then throw it away after posting the release announcement?
Should I do a Sigsum key rollover at the same frequency of PGP key rollover? Are there any recommendations about Sigsum key lifecycle management?
The only trustworthy way to discover the Sigsum public key used to sign my releases will be via PGP signed announcement e-mail. So the sigsum-related trust chains back to verifying a PGP e-mail. Sigsum can't really protect against someone stealing my PGP private key and fabricating hidden signed release announcements for a malicious version that is signed using a different Sigsum key, right? So I might as well use a different Sigsum private key for every release.
Maybe there is some low value in having "advanced" users be able to visually (or through 'cmp') compare the Sigsum public key fingerprint against a two year old release announcement to see if the same PGP key was used but the Sigsum key is different, to avoid being caught by the transparency log. I have a hard time imaging anyone going through that process regulary though.
I normally don't use the ssh-agent, and consider that threat as low, so I will probably use the SSH agent exported authentication key for my releases though.
BTW, how do you get the auxilliary .proof files onto the GNU ftp servers? I've only used the ftp-upload machinery with triplets foo, foo.sig, foo.directive.asc, and additional signature-like files doesn't quite fit there? Do you upload an additional triplet foo.proof, foo.proof.sig, foo.proof.directive.asc, and then ignore (or delete) the foo.proof.sig file, or is there some easier way?
I haven't tried this yet, but I'm hoping 'gnupload' will allow me to upload arbitrary files, or at least offer a way to remove any spurious *.proof.sig files.
/Simon
Regards, /Niels _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org