Bug#953733: hokey lint: please warn when different self-sigs have different key expiration times or primary key usage flags

[Daniel Kahn Gillmor]

Package: hopenpgp-tools
Version: 0.22-2+b1
Severity: wishlist

The attached OpenPGP certificate is weirdly inconsistent, and "hokey
lint" should observe the inconsistencies and warn the user about them.

hokey lint currently produces this information about the attached
certificate:

Key has potential validity: good
Key has fingerprint: 7138 FE5E B689 5581 ED99  E3AD 3CB7 A196 83B4 28D1
Checking to see if key is OpenPGPv4: V4
Checking to see if key is RSA or DSA (>= 2048-bit): RSA 3072
Checking user-ID- and user-attribute-related items:
  <alice.jones at example.com>:
    Self-sig hash algorithms: [SHA-512]
    Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224, SHA-1]
    Key expiration times: [4y11m29d16200s = Tue Mar 11 17:26:30 UTC 2025]
    Key usage flags: [[certify-keys]]
  <alice at example.net>:
    Self-sig hash algorithms: [SHA-512]
    Preferred hash algorithms: [SHA-512, SHA-384, SHA-256, SHA-224, SHA-1]
    Key expiration times: [1y11m29d81000s = Sat Mar 12 17:26:30 UTC 2022]
    Key usage flags: [[sign-data, certify-keys]]
Checking subkeys:
  one of the subkeys is encryption-capable: True
  fpr: 672F B213 DC01 10CC 1833  9BC5 84AE 1ECF D087 1C30
    version: v4
    timestamp: 20200312-172630
    algo/size: RSA 3072
    binding sig hash algorithms: [SHA-512]
    usage flags: [[encrypt-storage, encrypt-communications]]
    embedded cross-cert: False
    cross-cert hash algorithms: [SHA-512]


Both self-sigs make claims about the primary key, and they *differ* in
their claims.

The selfsig over the alice.jones at example.com uid claims an expiration
date in 2025, and that the primary key is only certification-capable.

The selfsig over alice at example.net claims an expiration date in 2022,
and that the primary key can sign as well as certify.

It's not clear how a receiving implementation would treat such a
composite certificate. GnuPG, for example, appears to take the union of
all validity times when it comes to expiration (valid through 2025), but
the intersection of all capabilities when it comes to key usage flags
(primary key is certification-capable only):


pub   rsa3072 2020-03-12 [C] [expires: 2025-03-11]
      7138FE5EB6895581ED99E3AD3CB7A19683B428D1
uid           [ultimate] <alice.jones at example.com>
uid           [ultimate] <alice at example.net>
sub   rsa3072 2020-03-12 [E]

It's also pretty weird that removal of one user ID or the other will
result in a different treatment of the certificate as a whole (e.g., in
2023, deletion or revocation of the alice.jones at example.com user ID will
cause the alice at example.net user ID to become expired because the
primary key now appears to be expired; before 2023, such a removal would
make the primary key appear to be signing-capable)

"hokey lint" should warn the user that these inconsistencies are present
and encourage them to unify the key-specific metadata in all the
self-sigs.

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: alice.key
Type: application/pgp-keys
Size: 3102 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20200312/45e9a01b/attachment-0001.key>
-------------- 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-haskell-maintainers/attachments/20200312/45e9a01b/attachment-0001.sig>