Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
I think anything you submit to a sigsum log ought to be made available to third-party monitors (via a release page, or a service mapping checksum to data, or any other means) more or less forever.
Then it may still be somewhat reasonable to use the same key for signing other non-logged stuff; there's some domain separation by the sigsum signatures always signing the data "sigsum.org/v1/tree-leaf" NUL <checksum>.
So maybe I have to generate a new personal private key used for Sigsum-based release signing, and only use it when I really want to commit to a particular release forever. That seems to match the semantics that your tool would be testing for.
I think there should be some clear distinction between "test" releases and advertised releases. That could be in the signed data, e.g., name of the top-level directory in the tar file looking like "rcX or "test", or it could be a separate signing key. But preferably well documented and machine processable.
It could make sense to sigsum log all test releases and keep them available, to be able to detect if an attacker who has compromised your key sends users rogue "test" release. But you probably do not want an attacker to be able to substitute a test release when they expect an official advertised release? (Related to the general problem of downgrade attacks).
Regards, /Niels