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

[Michael Richardson <[e-mail]>]

Simon Josefsson <simon=[e-mail]> wrote:
    >> If i had to make two bins, it'd probably be something like:
    >>
    >> # Lightweight sigs (frequent, informal, maybe EdDSA?)
    >>
    >> - daily e-mails
    >> - git commits
    >>
    >> # Heavyweight sigs (infrequent, formal, maybe SLH-DSA?)
    >>
    >> - tarballs
    >> - release announcement e-mails
    >> - git tags

    > This roughly matches my use-cases too, but I don't feel confident using
    > EdDSA for the first use-case forever, in case a quantum computers can
    > attack it in the future.  A hybrid EdDSA + ML-DSA-87 could work.

In the case of git commits, subsequent signatures coroborate (or do I mean
endorse?) the earlier ones.  And the release/tag commit signature effectively
signs everything that was before.

(Not the same for release announcement e-mails signing daily e-mails, but
maybe that's something we should think about: a heavyweight signature that
endorse many earlier signatures)

    > I think what you are looking for here goes beyond what we'll be able to
    > provide.  If I understand you correctly, the normal solution to this
    > problem today is to create a "release-only" key using a separate key id,
    > and publish human language statements explaining the relationship
    > between the two keys.  I think this is a fairly successful pattern used
    > by many projects, including GnuPG --

Yes, and generally one wants to share (or secret-split perhaps) the release
signing key so across many people.  Okay, some projects are single
developers, but perhaps they should always form a collective with other
single authors.

DKG has been trying to teach me to merge my travel keys a subkeys for my main
key so that I don't have multiple identities.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*