Direct key signatures are rarely used. IIRC, we implemented that the same way PGP did it.

May I turn this report into a feature request to

• Add a feature to edit a Direct Key Signature
• Show that the expiration time comes from such a signature.

Thanks for looking into this!

My main concern is that it's confusing to users (and possibly dangerous) if there are multiple values for Expiration Time in a key, but GnuPG implicitly edits only a subset of those.

Seems to me that the safest approach would be to always adjust all Expiration Time values in unison when a user performs gpg --edit-key -> expire.

I'm unsure if your suggestion is to implement that, or if you're considering adding a separate command to specifically edit metadata in a Direct Key Signature?

My suggestion is to clearly state that there is a direct Key Signature with an expiration date. Another feature would be to add a separate command to modify Direct Key Signatures. However, the latter has the problem that it help with proliferation of such signatures and other OpenPGP implementation will run into other problems. Thus for the whole ecosystem such an option is might not be a good idea.

It seems to me there are two separate concerns here:

1. how can GnuPG handle changing of expiration time on this type of key in a robust manner, and
2. should GnuPG inform its users that this type of key is discouraged by GnuPG.

On 1): I think it is important that GnuPG's output of gpg --edit-key -> expire is internally consistent. Producing keys with contradictory Expiration Time values seems obviously wrong to me.
I think the most straightforward way to do is to update all occurrences of Expiration Time on keys.

An alternative approach might be that GnuPG could normalize such a key, by removing the Direct Key Signature. I suppose this would necessitate folding whatever metadata is on that Signature into the primary User ID binding signature. That seems both harder and possibly more error prone. I don't prefer this approach.

Independent of this, regarding 2): GnuPG could of course choose to print warning messages while editing this type of key. The message could explain why GnuPG considers this type of Packet structure suboptimal.

However, I think it would be a disservice to GnuPG's users and the entire OpenPGP ecosystem if GnuPG's edit-key function continues to produce keys with internally inconsistent Expiration Times values.