Concerns regarding section 4.2, restrictions on T and PQ/T encryption to the same recipient

teythoon commented 10 months ago

Curerntly, the spec states:

4.2. Parallel Public-Key Encryption

As explained in Section 1.4.2, the OpenPGP protocol inherently supports parallel encryption to different keys of the same recipient. Implementations MUST NOT encrypt a message with a purely traditional public-key encryption key of a recipient if it is encrypted with a PQ/T key of the same recipient.

It is not quite clear to me what that means, and how implementations should enforce that restriction. To be clear, I get the intention and I think it is a valid concern.

Does that mean that if there is an OpenPGP certificate that has both a T and a PQ/T encryption subkey, an implementation MUST NOT encrypt to both subkeys?
Does that mean that if an implementation has two OpenPGP certificates with the same user ID (or aliasing user ID, whatever that exactly means), where one has a T encryption subkey, and the other one has a PQ/T encryption subkey, an implementation MUST NOT encrypt to both subkeys?
Does that mean that if an implementation has two OpenPGP certificates with different, non-aliasing user IDs, but the implementation or application knows somehow that the certificates belong to the same recipient, where one has a T encryption subkey, and the other one has a PQ/T encryption subkey, an implementation MUST NOT encrypt to both subkeys?

wussler commented 7 months ago

We tried to tackle this in https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/20, but so far without success. We'll bring this to the list once we're clear on the larger topics

wussler commented 7 months ago

Also duplicate of https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/2

wussler commented 2 weeks ago

Addressed in #120

openpgp-pqc / draft-openpgp-pqc

Concerns regarding section 4.2, restrictions on T and PQ/T encryption to the same recipient #67