inclusion of Features Subpacket in v4 keys according to crypto-refresh?

[falko-strenzke]

The crypto-refresh specifies:

If all recipient keys indicate support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet in their Features subpacket (Section 5.2.3.32), or are v6 keys without a Features subpacket, or the implementation can otherwise infer that all recipients support v2 SEIPD packets, the implementation SHOULD encrypt using a v2 SEIPD packet.

Currently, even when compiling RNP with crypto-refresh support, when generating v4 keys, the Features Subpacket is absent. This is for instance also the case for a backwards compatible traditional v4 key with a v4 PQC encryption subkey.

So the question arises whether, when crypto-refresh-support is compiled in, a Features Subpacket with support for v2 SEIPD should be included in the certificate.

@TJ-91
@ni4

[TJ-91]

I think it makes sense. I implemented it in feature-subpkt-v4-cert (we can still decide whether to use it or not)

[falko-strenzke]

Thinking about it again, I see more the problem more complex. GnuPG got its v5 AEAD feature announcement patched out by one Linux distribution recently. I dont' t remember which distro. Some applications processing OpenPGP keys remove the Feature. The discussion was on one GnuPG mailing list, I think the "users" one. So the same situation could arise for the v6 Features. If that is what we must anticipate, then maybe it makes sense to introduce further compile time switches. For instance it could look like this:

• Replace the current switch for crypto-refresh support with these more refined switches:
• (I): Entirely passive support for crypto-refresh: can process incoming c-r packets, but doesn't announce c-r features in generated v4 keys. Never generates any c-r packets (in keys, signatures, or encryption).
• (II): Passive but announcing support for c-r: Like (I), but also creates a Feature subpacket in the generated keys which announces v2 SEIPD support.
• (III): Active support for c-r: Like (II) but also generates c-r packets (in keys, signatures, or encryption).

@kaie

[TJ-91]

I think your proposal makes sense for an additional reason: Passive support can be activated with more confidence and therefore done sooner, and thus possibly speed up adoption. In addition, it can make sense to replace the compile-time switches with runtime switches (i.e. FFI API calls) when enabling one of the steps (I), (II), or (III) in the default build.

There is the possibility that introducing "passive but announcing support" will be less controversial for the Crypto Refresh since it's the official successor in the IETF.