x/crypto/openpgp: fails to handle expired subkeys correctly

[abarisani]

Hello,

importing OpenPGP keys with expired signature subkeys, but a valid non-expired signature subkey, is not being handled correctly by golang.org/x/crypto/openpgp functions such as ReadEntity.

What I am experiencing is that when the imported public key has a single non-expired signature subkey then there are no issues.

However if the imported key has one or more expired signature subkeys, and a valid one as the last packet, only the first expired subkey is considered when creating the PublicKey object, making it invalid for encryption.

I am attaching a public key that exhibits these properties, the key was parsed as follows:

keyBlock, _ := armor.Decode(keyFile)
reader := packet.NewReader(keyBlock.Body)
entity, _ := openpgp.ReadEntity(reader)

and later used with openpgp.Encrypt().

Currently gpg --export, even with --export-options export-minimal, always carry expired signature subkeys (despite gpg documentation suggesting the contrary). This means that I have no easy way of exporting the public key in a way which is friendly to golang.org/x/crypto/openpgp, unless I am missing something.

Let me know if you need further information to debug this.

Thanks!

test_key.txt

[fawkesley]

I also have this problem as my key contains multiple subkey binding signatures, but only the first (expired) one is processed. Later packets are ignored, so entity.Subkeys[...].Sig.KeyExpired(time.Now()) are always true

Thanks so much @abarisani for your workaround

This very recent commit (which fixed #26449) nearly fixed this but not quite.

In a follow-up patch, we can improve this further by keeping the
most recent signature, as suggested by RFC4880:

An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent self-
signature.

I've written and tested a patch on our fork which is working for us.

Regarding GnuPG, yes export-minimal,export-clean should strip older signatures, and this is apparently fixed as of 2.2.9

[FiloSottile]

Per the accepted #44226 proposal and due to lack of maintenance, the golang.org/x/crypto/openpgp package is now frozen and deprecated. No new changes will be accepted except for security fixes. The package will not be removed.

If this is a security issue, please email security@golang.org and we will assess it and provide a fix.

If you're looking for alternatives, consider the crypto/ed25519 package for simple signatures, golang.org/x/mod/sumdb/note for inline signatures, or filippo.io/age for encryption. You can read a summary of OpenPGP issues and alternatives here.

If you are required to interoperate with OpenPGP systems and need a maintained package, we suggest considering one of multiple community forks of golang.org/x/crypto/openpgp. We don't endorse any specific one.