Subject: [Openpgp-dt] bit 0x04 of Features subpacket: move back to "Reserved"?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 14 Oct 2021 19:10:04 -0400

Hi all--

no hats on here, i've opened this issue as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/50:

The current draft states that if bit 0x04 of the Features subpacket is set, it indicates: "Version 5 Public-Key Packet format and corresponding new fingerprint format"

How is this actionable?  If it is not actionable, is it worth including in the spec?

My conclusion is that it is more likely to cause trouble than to be useful, and i recommend removing it from the spec.

My baseline assumptions:

- The Features subpacket is included in an OpenPGP certificate -- the spec says it only appears in a self-sig.
- If Alice has Bob's OpenPGP certificate, presumably the idea is that Alice might behave differently when interacting with Bob if she knows that Bob's OpenPGP implementation supports this feature or not.
- To the extent that Alice can interact with Bob via his OpenPGP certificate, she can do a limited number of things:
  - encrypt data with the expectation that Bob will decrypt it
  - verify signatures made by Bob
  - sign data with the expectation that Bob will verify the signature

Of these actions, only the last seems like it might be relevant for the features flag at all.  If Alice is encrypting or verifying, she's doing those things based on Bob's certificate, which itself is either comprised of v5 or v4 key material (or a mix) and Alice can either interact with it or not (she doesn't care about Bob's stated feature).  For signing data, this would only be potentially useful if (a) Alice is signing the message only for Bob to verify, and (b) Alice happens to have both a v4 and a v5 key available, and can choose which one to use to make the signature.

This seems like a pretty weird corner case to facilitate: if Alice does have both v4 and v5 keys, and she signs anything publicly (e.g. a message to a mailing list, not just for Bob), she'll still have to make a decision about which key to use for signing without the benefit of this features flag.  Even if she does have a v5 key, maybe it's using a pubkey algorithm or a specific elliptic curve that Bob doesn't know about -- we don't have any feature indicators for those options.

Moreover, what should Alice do if that feature bit is *not* set in Bob's self-sig, and she has only a v5 key, and she is sending Bob an encrypted+signed message?  Should she not sign at all (since she'd be signing with a v5 key) or should she go ahead and sign?  I think she clearly should go ahead and sign, ignoring the feature flag.  If Bob can't verify the signature, he'll have to handle just like any other broken signature.

So i don't think this feature flag is really actionable by anyone directly interacting with the public key.

If, instead, the goal of the feature flag is to be some sort of counter/aggregator that indicates when a sufficient number of implementations have implemented v5, then this seems like an inefficient way to go about it.  People's implementations don't necessarily update their certificate's feature flags (re-issuing the self-sigs) upon growing a new capability -- so there'd likely be an undercount if we just look at some set of published keys (which set would we look at anyway?).  Seems like using the interop test suite and published versions of widely-distributed software would be a more useful way to estimate when the capability is widespread.

So i'm inclined to suggest that we drop this feature flag and revert to 0x04 being "reserved".

   --dkg