On Sun, 25 Oct 2020 02:03:43 +0100,
Phil Pennock wrote:
For myself, even with the oldest key, using expiring subkeys and
refreshing periodically with newer subkeys, everything _except_ the
self-sig had updated automatically by the time I went looking.
Right. User ID self signatures are the worse offenders, but subkey
binding signatures are also a problem. I collected some statistics
about different projects. You can find them here:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
It seems that there are 19 certificates in the Debian keyring that
have non-revoked, live signing-capable subkeys that rely on SHA-1 in
someway. 10 use SHA1 for the subkey binding signature, and 9 only use
it for the primary key binding signature (the backsig). That's just
over 2% of the certificates in the Debian keyring. Arch is about the
same (2 of 76 certificates).
Although it is possible to fix the subkey binding signature by
adjusting the subkey's expiration time, using gpg, this won't update
the backsig, see:
https://dev.gnupg.org/T5110
I think really we need some nice pgpkey-sanitycheck command-line tool,
from any project, which looks purely at public key information, so
doesn't need to care about internals (private keys, keyboxes, etc).
Such a tool might then report on outdated algorithms used in important
places, while avoiding getting into the political mess of which
algorithm order preferences should be included in a key.
Deprecating X without tools to make it _trivial_ for people to tell if
they're affected by X is going to be frustrating. In my previous email,
I didn't mention the diagnostics I used to show people that their key
was affected, but it involved `gpg --list-packets` and it was not
pretty.
Indeed. Unfortunately, `gpg --list-packets` doesn't show the content
of the backsig:
$ gpg --export FPR | gpg --list-packets
...
# off=806 ctb=89 tag=2 hlen=3 plen=346
:signature packet: algo 1, keyid A23C95250F66162A
version 4, created 1603438577, md5len 0, sigclass 0x18
digest algo 10, begin of digest e9 34
hashed subpkt 27 len 1 (key flags: 02)
hashed subpkt 33 len 21 (issuer fpr v4 2...)
hashed subpkt 2 len 4 (sig created 2020-10-23)
hashed subpkt 9 len 4 (key expires after 3y0d0h5m)
** subpkt 32 len 156 (signature: v4, class 0x19, algo 1, digest algo 2)
subpkt 16 len 8 (issuer key ID A...)
data: [1024 bits]
For what it is worth, `pgpdump` `sq packet dump` (also at
https://dump.sequoia-pgp.org), and `rnp --list-packets` do show that
information.
I held off on "asking others to write software for me" in the previous
post, keeping it to "this exists now". This time around, I'm throwing
out a "Hey, pgpkey-sanitycheck would be a nice tool to have, folks" and
running away.
The tool that I used to conduct my analysis is available here:
https://gitlab.com/sequoia-pgp/keyring-linter
(Eventually we plan to integrate a linter into `sq`.)
Justus was nice enough to upload it to crates.io:
https://crates.io/crates/sequoia-keyring-linter
So it should be just a `cargo install sequoia-keyring-linter` away.
And, if I understood dkg correctly, he is in the process of packaging
it for Debian.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp