Re: [openpgp] Discussion regarding signalling of preferences for multipl

Hi Falko--

On Thu 2022-04-14 15:06:16 +0200, Falko Strenzke wrote:
> Regarding the discussion around multiple encryption-capable subkeys, I 
> would like to make the following remarks on behalf of the project 
> PQC@Thunderbird.
Thanks for this note, you're making it in the right forum :)

I agree with you that the semantics for PQC hybrid encryption schemes
are likely to be similar to (but subtly different from) the semantics
for parallel encryption schemes.  Their signalling probably does belong
in the same sort of spot in the spec, however that gets worked out.

I'm currently imagining that it's either a bit in the key usage flags
subpacket, or it's an entirely new subpacket (possibly marked critical,
i'm not sure).  Either way, i'd imagine that the subpacket with this
indicator probably belongs in the subkey binding signature.

> * how to signal to the sender that a certain encryption subkey must only 
> be used in a multi-algorithm combination with another (specific) subkey 
> from the same keyring (e.g. to indicate: "use this PQC key only in 
> multi-algorithm encryption together with ECDH")?
right, there are two distinct things a keyholder might want to signal:

- the *capability*: that they can accept a hybrid scheme, and
- the *requirement*: that they *require* a hybrid scheme.

But, i'm not sure how much the keyholder's preference really matters for
the requirement part -- when encrypting, it's really the sender's policy
that ultimately governs, right?

For example, the sender can always send cleartext, which is arguably
worse than single ECDH.  And if the sender ignores the keyholder's
stated requirement for hybrid encryption, and chooses to just use ECDH
to encrypt a message to a single key that the recipient has, would the
recipient really refuse to decrypt it?  I mean, maybe some would, but
it's pretty hard to convince (for example) a MUA that they shouldn't at
least try to decrypt a ciphertext if they have the key available, even
if it's not their preferred algorithm.

The end user wants to see the cleartext!

What would you think about starting with a definition of just the
*capability* signal as you ramp up this work?  the semantics of the
*requirement* signal seem pretty ambiguous to me.

        --dkg

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp