rnp
rnp copied to clipboard
Add logic to determine symmetric encryption mode based on recipient keys?
Currently, the decision whether to encrypt using v5 AEAD packets is, according to our knowledge, only based on caller parameters. The recipients keys, specifically the Features Subpacket are not evaluated for this purpose.
For the v2 SEIPD packets introduced in the crypto-refresh (currently only supported as experimentally by RNP), the current logic is to encrypt using v2 SEIPD to a v6 key by default. Also here the Features Subpacket, which can indicated support for v2 SEIPD / v6 PKESK independently of the key version, is not evaluated.
Is it of interest that we add such a logic for the evaluation of the recipient keys for the decision which encryption to use to RNP? Or is it the intention to leave that to the caller?
@ni4 @TJ-91 @kaie