Re: [openpgp] Code-signing in OpenPGP [was: Re: SLH-DSA code points]

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2024-03-22 20:37:36 +0000, Daniel Huigens wrote:
> This sounds like a useful distinction to me, but to me the most
> important difference seems to be not how secure they need to be today,
> but rather how long they need to be secure for. E.g. emails that are
> read once might not need a signature that will verify successfully in
> 10 years, but a tarball might.

Thanks for this way of looking at the problem, i find it a useful
re-framing, and i think i've changed my perspective on the issue now.

> So, perhaps, to serve this use case, you could have an SLH-DSA primary
> key with an EdDSA subkey, and indicate when signing, how long you want
> the signature to be used/trustworthy? (Obviously that's a rather
> advanced option and I'm not sure what a good UI would be.)

right, i don't think there's a good UI for this either -- "make
signature likely to be invalidated sooner" is not an option most users
will reasonably want to check.  At best i can imagine a "don't bother
trying to sign with keys that i don't have available", but 

> I'd argue, if someone accepts an EdDSA signature today, even if you
> normally make an SLH-DSA signature, that's perfectly fine, only once
> EdDSA is (expected to shortly be) broken should the validity of such a
> signature change. So the incentive for you to sign with SLH-DSA should
> be to make a longer-lived signature, not a more trusted one.

I think this is the right answer.  It's simple, and it's
straightforward and clear.

And the corollary seems to be that if there are multiple secret keys,
just sign with each of them.  I'm proposing to make this the default for
`sop`, since sop was previously ambiguous about that.

If anyone is interested, please see:

  https://gitlab.com/dkg/openpgp-stateless-cli/-/merge_requests/29

Where i'm contemplating how to specify this behavior clearly in `sop`
without making it too messy.

Regards,

        --dkg