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: <[email protected]>: 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]] <[email protected]>: 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 [email protected] uid claims an expiration date in 2025, and that the primary key is only certification-capable. The selfsig over [email protected] 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] <[email protected]> uid [ultimate] <[email protected]> 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 [email protected] user ID will cause the [email protected] 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
alice.key
Description: application/pgp-keys
signature.asc
Description: PGP signature
