On 15/04/2022 09:44, Falko Strenzke wrote:
In the PQC setting the situation changes, the verbal signal "send it
encrypted" just doesn't seem to suffice as it implies too many
alternatives the security implications of which the average user will
not be able to oversee (he only understands the difference "encrypted /
unencrypted") – that is, if he is given any control over these
alternatives by his MUA at all. This is specifically relevant if Bob
uses a legacy MUA that does not even have a chance to interpret the
signalled capability for multi-algorithm encryption at all.
If Bob is using legacy software that doesn't understand the new flags,
then all bets are off. He may be using software that doesn't understand
PQC at all. There is also the issue of how to order the encryption
stages - flags are too inflexible to be useful in definind complex
workflows. Must we then define an ordering in the standard? For all
possible combinations?
The most reliable method IMO to protect against misinterpretation by
legacy software is to define a novel subkey type for multi-algo
encryption keys. Legacy software will then see an unknown key type and
should always throw "no usable keys". The multi-algo subkey type would
contain a list of keys in the order they should be applied. If we want
to make use of multi-algo encryption optional, then we can bind another
subkey.
--
Andrew Gallagher
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp