Your message dated Thu, 30 Jun 2022 17:39:32 -0400
with message-id <[email protected]>
and subject line Re: [pkg-gnupg-maint] Bug#1013288: gnupg: Doesn't show uid 
expiry
has caused the Debian Bug report #1013288,
regarding gnupg: Doesn't show uid expiry
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1013288: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013288
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gnupg
Version: 2.2.35-2
Severity: normal
X-Debbugs-Cc: [email protected]

Hello,

        uwe@taurus:~$ export GNUPGHOME=$(mktemp -d)
        uwe@taurus:~$ curl -s 
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/plain/keys/6637D326999B862C.asc
 | gpg --import
        gpg: keybox '/tmp/tmp.S4Xeh1pmja/pubring.kbx' created
        gpg: key 6637D326999B862C: 3 signatures not checked due to missing keys
        gpg: /tmp/tmp.S4Xeh1pmja/trustdb.gpg: trustdb created
        gpg: key 6637D326999B862C: public key "Philipp Zabel <[email protected]>" 
imported
        gpg: Total number processed: 1
        gpg:               imported: 1
        gpg: no ultimately trusted keys found
        uwe@taurus:~$ gpg --with-colons --check-sigs 6637D326999B862C
        tru::1:1655760525:0:3:1:5
        
pub:-:4096:1:6637D326999B862C:1402826245:1664799531::-:::scESC::::::23::0:
        fpr:::::::::27C6398DC5B132E22A8D2B516637D326999B862C:
        uid:-::::1633263532::645CAC3041C5B2B3F7D7169DC0216C1B2ACB8711::Philipp 
Zabel <[email protected]>::::::::::0:
        sig:?::1:0BE9E3157A1E2C64:1403019369:::::10x:::::2:
        sig:!::1:6637D326999B862C:1633263532::::Philipp Zabel 
<[email protected]>:13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        uid:-::::1599034236::834E8111DE69C80CC6C776EEBD2DD3BB50DCD452::Philipp 
Zabel <[email protected]>::::::::::0:
        sig:?::1:0BE9E3157A1E2C64:1403019369:::::10x:::::2:
        sig:!::1:6637D326999B862C:1599034236::::Philipp Zabel 
<[email protected]>:13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        uid:-::::1633263531::46A0A420CBEFD71A9CE3EFCCDC59B187D056C137::Philipp 
Zabel <[email protected]>::::::::::0:
        sig:?::1:0BE9E3157A1E2C64:1403019369:::::10x:::::2:
        sig:!::1:6637D326999B862C:1633263531::::Philipp Zabel 
<[email protected]>:13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:-:4096:1:8FCC408DE8F7F370:1402826245:1664799540:::::e::::::23:
        fpr:::::::::40ACEFA243542A5ADBFA706C8FCC408DE8F7F370:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:-:4096:1:50C2881C709E60EB:1402828631:1664799540:::::s::::::23:
        fpr:::::::::06C071855D4568AC17B8238150C2881C709E60EB:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:-:255:22:D585A725183762C0:1526278694:1664799540:::::s:::::ed25519::
        fpr:::::::::513BA17A59DA47D51D2F1A26D585A725183762C0:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:

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):

        uwe@taurus:~$ gpg --export 6637D326999B862C | hokey lint
        hokey (hopenpgp-tools) 0.23.6
        Copyright (C) 2012-2021  Clint Adams
        hokey comes with ABSOLUTELY NO WARRANTY. This is free software, and you 
are welcome to redistribute it under certain conditions.

        Key has potential validity: good
        Key has fingerprint: 27C6 398D C5B1 32E2 2A8D  2B51 6637 D326 999B 862C
        Checking to see if key is OpenPGPv4: V4
        Checking the strength of your primary asymmetric key: RSA 4096
        Checking user-ID- and user-attribute-related items:
          Philipp Zabel <[email protected]>:
            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]
            Key usage flags: [[sign-data, certify-keys]]
          Philipp Zabel <[email protected]>:
            Self-sig hash algorithms: [SHA-256]
            Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224]
            Key expiration times: [8y3m18d67886s = Mon Oct  3 12:18:51 UTC 2022]
            Key usage flags: [[sign-data, certify-keys]]
          Philipp Zabel <[email protected]>:
            Self-sig hash algorithms: [SHA-256]
            Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224]
            Key expiration times: [8y3m18d67886s = Mon Oct  3 12:18:51 UTC 2022]
            Key usage flags: [[sign-data, certify-keys]]
        Checking subkeys:
          one of the subkeys is encryption-capable: True
          fpr: 40AC EFA2 4354 2A5A DBFA  706C 8FCC 408D E8F7 F370
            version: v4
            timestamp: 20140615-095725
            algo/size: RSA 4096
            binding sig hash algorithms: [SHA-256]
            usage flags: [[encrypt-storage, encrypt-communications]]
            embedded cross-cert: False
            cross-cert hash algorithms: [SHA-256]
          fpr: 06C0 7185 5D45 68AC 17B8  2381 50C2 881C 709E 60EB
            version: v4
            timestamp: 20140615-103711
            algo/size: RSA 4096
            binding sig hash algorithms: [SHA-256]
            usage flags: [[sign-data]]
            embedded cross-cert: True
            cross-cert hash algorithms: [SHA-256]
          fpr: 513B A17A 59DA 47D5 1D2F  1A26 D585 A725 1837 62C0
            version: v4
            timestamp: 20180514-061814
            algo/size: EdDSA 256
            binding sig hash algorithms: [SHA-256]
            usage flags: [[sign-data]]
            embedded cross-cert: True
            cross-cert hash algorithms: [SHA-256]

If I export the key with only the pengutronix uid, then reimport that
cleanly, gpg also notices that there is a problem:

        uwe@taurus:~$ gpg --export --export-filter keep-uid="uid =~ 
@pengutronix.de" 6637D326999B862C > k
        uwe@taurus:~$ gpg --delete-keys 6637D326999B862C
        gpg (GnuPG) 2.2.35; Copyright (C) 2022 g10 Code GmbH
        This is free software: you are free to change and redistribute it.
        There is NO WARRANTY, to the extent permitted by law.


        pub  rsa4096/6637D326999B862C 2014-06-15 Philipp Zabel <[email protected]>

        Delete this key from the keyring? (y/N) y
        uwe@taurus:~$ gpg --import k
        gpg: key 6637D326999B862C: 1 signature not checked due to a missing key
        gpg: key 6637D326999B862C: public key "Philipp Zabel 
<[email protected]>" imported
        gpg: Total number processed: 1
        gpg:               imported: 1
        gpg: no ultimately trusted keys found
        uwe@taurus:~$ gpg --with-colons --check-sigs 6637D326999B862C
        tru::1:1655760883:0:3:1:5
        pub:e:4096:1:6637D326999B862C:1402826245:1630570236::-:::sc::::::23::0:
        fpr:::::::::27C6398DC5B132E22A8D2B516637D326999B862C:
        uid:e::::1599034236::834E8111DE69C80CC6C776EEBD2DD3BB50DCD452::Philipp 
Zabel <[email protected]>::::::::::0:
        sig:?::1:0BE9E3157A1E2C64:1403019369:::::10x:::::2:
        sig:!::1:6637D326999B862C:1599034236::::Philipp Zabel 
<[email protected]>:13x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:e:4096:1:8FCC408DE8F7F370:1402826245:1664799540:::::e::::::23:
        fpr:::::::::40ACEFA243542A5ADBFA706C8FCC408DE8F7F370:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:e:4096:1:50C2881C709E60EB:1402828631:1664799540:::::s::::::23:
        fpr:::::::::06C071855D4568AC17B8238150C2881C709E60EB:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:
        sub:e:255:22:D585A725183762C0:1526278694:1664799540:::::s:::::ed25519::
        fpr:::::::::513BA17A59DA47D51D2F1A26D585A725183762C0:
        sig:!::1:6637D326999B862C:1633263540::::Philipp Zabel 
<[email protected]>:18x::27C6398DC5B132E22A8D2B516637D326999B862C:::8:

i.e. now the 2nd field of the uid is 'e' for expired.
        
Am I missing something?

Best regards
Uwe

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (700, 'testing-debug'), (700, 'stable-security'), (700, 
'stable-debug'), (700, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 
'unstable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldoldstable'), (500, 'oldstable'), (499, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnupg depends on:
ii  dirmngr         2.2.35-2
ii  gnupg-l10n      2.2.35-2
ii  gnupg-utils     2.2.35-2
ii  gpg             2.2.35-2
ii  gpg-agent       2.2.35-2
ii  gpg-wks-client  2.2.35-2
ii  gpg-wks-server  2.2.35-2
ii  gpgsm           2.2.35-2
ii  gpgv            2.2.35-2

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  <none>
pn  xloadimage  <none>

-- no debconf information

--- End Message ---
--- Begin Message ---
Hi Uwe--

Thanks for the report.

On Mon 2022-06-20 23:37:13 +0200, Uwe Kleine-König wrote:
>       uwe@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@taurus:~$ gpg --export 6637D326999B862C | hokey lint
 […]
>       Checking user-ID- and user-attribute-related items:
>         Philipp Zabel <[email protected]>:
>           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

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply via email to