[pkg-gnupg-maint] Bug#1013288: Bug#1013288: gnupg: Doesn't show uid expiry

[Daniel Kahn Gillmor]

Hi Uwe--

Thanks for the report.

On Mon 2022-06-20 23:37:13 +0200, Uwe Kleine-König wrote:
> 	uwe at taurus:~$ curl -s https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys/6637D326999B862C.asc | gpg --import

I'm closing this bug report because i think GnuPG is "functioning as
intended" due to how OpenPGP works, but i completely understand how this
is perplexing.

The reason you're seeing this is not a User ID expiration at all -- it's
a key expiration, even though the place you're noticing it is the uid
expiration.

Let me explain in a bit more detail:

When you use the certificate with only the pengutronix.de user ID in it,
the self-sig's key expiry time subpacket says that the primary key is
expired.  If the primary key is expired, the user ID is expired as well.

When you bring in one of the other user IDs and its self-sig, the
primary key now gets its expiration date from the later key expiration
in that self-sig. So the primary key isn't expired any longer, and
therefore all of its user IDs (including the pengutronix one!) are
potentially valid.

> so the key seems to have three valid uids. However the pengutronix.de
> uid isn't valid any more according to hokey (marked with an arrow):

hokey lint isn't saying that the user ID is expired -- it's complaining
that the *primary key* is marked for expiration by this self-sig, so if
this user ID alone was present, the whole cert ends up expired.  Note
that it says "Key expiration time" here:

> 	uwe at taurus:~$ gpg --export 6637D326999B862C | hokey lint
 […]
> 	Checking user-ID- and user-attribute-related items:
> 	  Philipp Zabel <p.zabel at pengutronix.de>:
> 	    Self-sig hash algorithms: [SHA-256]
> 	    Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224]
>   -->	    Key expiration times: [7y2m18d25991s = Thu Sep  2 08:10:36 UTC 2021]



Note that the primary key *also* changed its status, from:

        pub:-:4096:1:6637D326999B862C:1402826245:1664799531::-:::scESC::::::23::0:

to:

        pub:e:4096:1:6637D326999B862C:1402826245:1630570236::-:::sc::::::23::0:

This is because the primary key's status is derived from a combination
of key expiration times from all present uid self-sigs.

I note that OpenPGP also allows for a "signature expiration time"
subpacket.  If some self-sig contained that subpacket that pointed to
the past, i'd expect that user ID to be able to expire independently of
whatever is contained in the self-sigs of the other user IDs present in
certificate.

Thinking about this today, I tried hard to come up with a better way
that GnuPG could signal this more clearly, but my conclusion is that the
main source of confusion here is in the OpenPGP standard itself, not in
GnuPG's implementation.

One option would be for GnuPG to have a different status indication for
an expired User ID (due to sig expiration) than for a user ID that
happens to belong to an expired primary key.

I could imagine advocating for this outcome, but i don't know how
receptive GnuPG upstream would be to it.  If you think that would be a
satisfying resolution to the weird situation you found yourself in, feel
free to note the suggestion in the upstream bugtracker
(https://dev.gnupg.org) and reopen this issue in the debian BTS and
point it to the upstream bug report.

Thanks for reporting this!  Sorry to not have a simpler answer.

fwiw, i think that "hokey lint" is right to mark this situation as
problematic, because it is definitely a surprising and subtle situation
for a composable certificate format like OpenPGP.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220630/7189d155/attachment.sig>