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

Hi Falko and Andrew--

thanks for your considered and thoughtful replies.

Falko, your description of an out-of-band ("verbal") signal for
"encryption required" is pretty interesting regardless of PQC, and makes
me wonder whether we want to think about formalizing such a signal.  I
can't tell in your description whether you're imagining that signal as a
one-off ("please just send this one message encrypted") or as a uniform
policy from the keyholder.

The closest i've seen to a uniform policy from the keyholder is
Autocrypt's "prefer-encrypt=mutual" setting [0], which has semantics of
"as long as the other person also has this setting, messages between us
should default to being encrypted."  But that's still pretty far from
"you must not send cleartext to this address".

[0] https://autocrypt.org/level1.html

Is anyone interested in publishing such a strong uniform policy signal
for any e-mail address they control?  If so, this seems like an
orthogonal issue to PQC, and worthy of a separate thread.

If we're talking about a one-off request for a must-be-encrypted
message, and the recipient's tooling is able to detect the capability
for and make use of a hybrid scheme, then it seems like the capability
signalling is all that is necessary. (i guess i'm imagining encouraging
any implementation that can detect the capability and use it to prefer
the hybrid scheme over either scheme individually or in parallel)

So the only use case left for "requirement" signalling is the case where
the recipient's tooling can't understand or make use of the hybrid
scheme, *can* encrypt to the ECDH subkey, but would rather that their mailer
refuses to send at all, rather than just sending encrypted with ECDH.
Seems pretty niche!

I agree with Andrew that one straightforward way to enforce the use of a
hybrid scheme would be with a dedicated public key ID.  The only risk
there is that we might then end up allocating some kind of combinatorial
explosion of codepoints in the pubkey id table if there are multiple
schemes of each type that might want to hybridize.

Another approach that doesn't overallocate those codepoints would be to
add a subpacket to the ECDH subkey binding signature that says "you can
encrypt to this subkey in hybrid combination with this other subkey".
That handles "capability" -- and you could include a field in the
subpacket that means "don't encrypt to this without using hybrid scheme
X".  To make that requirement stick even for implementations that don't
understand the hybrid scheme, you could set the critical bit on such a
subpacket.

Most implementations are pretty good about rejecting subkeys that have
an unknown critical subpacket in their binding signature, at least when
verifying signatures from the subkey:

   https://tests.sequoia-pgp.org/#Binding_signature_subpackets

But the interop test suite doesn't have any test yet for how well
implementations respect critical subpackets in the subkey binding
signatures for encryption:

  https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/28

If either of y'all (or anyone else) wants to try to contribute to the
test suite, maybe try to write that test?

This would be a great bit of data to have available when we get around
to discussing how the hybrid scheme should be signalled in the
certificate.

        --dkg

signature.asc
Description: PGP signature

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