New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
abarisani opened this Issue Apr 18, 2016 · 1 comment

Comments

Projects
None yet
3 participants
@abarisani
Copy link

abarisani commented Apr 18, 2016

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

@abarisani abarisani changed the title golang.org/x/crypto/openpgp fails to handle expired subkeys correctly x/crypto/openpgp fails to handle expired subkeys correctly Apr 18, 2016

@bradfitz bradfitz changed the title x/crypto/openpgp fails to handle expired subkeys correctly x/crypto/openpgp: fails to handle expired subkeys correctly Apr 18, 2016

@bradfitz bradfitz added this to the Unreleased milestone Apr 18, 2016

abarisani added a commit to inversepath/interlock that referenced this issue Apr 20, 2016

abarisani added a commit to inversepath/interlock that referenced this issue Jun 8, 2016

@paulfurley

This comment has been minimized.

Copy link

paulfurley commented Sep 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment