Page MenuHome GnuPG

GnuPG fails to parse algorithm preferences (and presumably features) from direct key signatures
Closed, WontfixPublic


While GnuPG correctly constrains the lifetime and keyflags of the primary key using subpackets found in direct signatures, it fails to parse algorithm preferences (and presumably features) from direct key signatures.

$ gpg --edit-key 23F81D59CF68F720             
gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  ed25519/23F81D59CF68F720
     created: 2019-02-11  expired: 2019-02-25  usage: SCA 
     trust: unknown       validity: expired
[ expired] (1). Joe Sixpack <>

gpg> showpref
[ expired] (1). Joe Sixpack <>
     Cipher: 3DES
     Digest: SHA1
     Compression: ZIP, Uncompressed


This is the TPK I tried:





Event Timeline

werner added a subscriber: werner.

That is correct according to the specs:

Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible.  For example, suppose a key has
two user names, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm AES-256, and Bob prefers Camellia-256 or AES-128.
If the software locates this key via Alice's name, then the preferred
algorithm is AES-256; if software locates the key via Bob's name,
then the preferred algorithm is Camellia-256.  If the key is located
by Key ID, the algorithm of the primary User ID of the key provides
the preferred symmetric algorithm.

Given that user ids with self-signatures are mandatory in gpg there is no reason to consult direct key signatures.

dkg added a subscriber: dkg.

I agree with @werner that when presented with a User ID with self-sig with preference, the preferences subpackets from the self-sig should take precedence.

However, there are two cases that are not covered by this explanation, and i think those at least are cases where GnuPG should reasonably rely on preferences found in a direct key signature:

  • If the certificate is selected by primary key fingerprint (not by user ID) and it has multiple user IDs all self-signed at the same timestamp, but none of them are marked primary, then there is no well-defined way to choose which preferences subpacket to use. In this (admittedly unusual) case, a direct key signature could be used to break the tie.
  • If the certificate is selected by user ID, but the self-sig for the user ID has *no* preferences subpacket at all, a preferences subpacket in a direct key signature could be used.

Additionally, we are moving toward a world where user IDs are not mandatory for OpenPGP certificates (see for example the work in rfc4880bis). In that situation, i would expect preferences subpackets found in a direct key signature to be respected.

werner claimed this task.

UserIDs are mandatory and do not see any reason to change this except maybe by specialized application in the embedded field.