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

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

On Wed 2024-03-27 11:58:30 +0000, Daniel Huigens wrote:
> Or, we could provide some kind of suggestion for the tables in the SOP
> spec. But obviously we can't unilaterally force SOP implementations to
> update the set of algorithms immediately upon new research coming out,
> so even if we do that, there would still likely be some discrepancies
> between implementations eventually.

I don't think that including any sort of explicit wire format guidelines
in the SOP spec align with the level of abstraction that SOP is aiming
at.  The "Semantics vs. Wire Format" section of the SOP specification
reads:

>> The semantics of `sop` are deliberately simple and very high-level
>> compared to the vast complexity and nuance available within the OpenPGP
>> specification.  This reflects the perspective of nearly every piece of
>> tooling that relies on OpenPGP to accomplish its task: most toolchains
>> don't care about the specifics, they just want the high-level object
>> security properties.
>> 
>> Given this framing, this document generally tries to avoid
>> overconstraining the details of the wire format objects emitted, or what
>> kinds of wire format structures should be acceptable or unacceptable.
>> This allows a test suite to evaluate and contrast the wire format
>> choices made by different implementations in as close to their native
>> configuration as possible.  It also makes it easier to promote
>> interoperability by ensuring that the native wire formats emitted by one
>> implementation can be consumed by another, without relying on their
>> choices of wire format being constrained by this draft.
>> 
>> Where this draft does identify specific wire format requirements, that
>> might be due to an ambiguity in the existing specifications (which maybe
>> needs fixing elsewhere), or to a bug in this specification that could be
>> improved.


I am particularly resistant to adding any `--longevity` option to `sop
generate-key`, which i think would be a mistake.  SOP implementers
provide up to 4 profiles for `generate-key` already, with one of them
being the implementer's default, and there is room for an impementer to
describe (in a single line of text) what they think would help a user to
choose one over another.

We have a similar `--profile` option for `sop encrypt` at the moment,
which can be used by implementers to offer up to four different
preferences for encryption behavior.

If a bunch of different implementations all coalesce around the same
narrowly-chosen set of profile behaviors for key generation and
encryption, that would be an interesting outcome.  If there is broad
consensus around a particular profile, perhaps the working group would
want to write it down in a WG-owned internet draft directly.

I think what i'm taking away from this discussion is that there might be
some implementer interest in a complementary `--profile` option for `sop
sign` and `sop inline-sign`, which could allow for similarly
narrowly-scoped user control over "what flavor" of signature should be
made, in the event that there are multiple possible ways that an OpenPGP
Transferable Secret Key can make a signature.

But i wouldn't want to overdetermine the outcome about the range of
desired tradeoffs before we see some implementation choices.  The best
option for most users, and for most applications that use sop, is "do
the default thing".  I wouldn't want to encourage the application layer
to require users to hunt around amid a multidimensional array of subtle
nuance.

        --dkg