I actually worked on that for an hour two days ago and failed to get rid of all the sha1’s. So we postponed this and will generate a new key
Sent using a virtual keyboard on a phone > On May 25, 2022, at 18:49, Daniel Kahn Gillmor <[email protected]> wrote: > > Hi folks-- > > I just noticed that the self-sigs over the libreswan signing key and its > subkey binding signature are all made using SHA1. > > As SHA1 is further deprecated, this makes the certificate difficult to > use, since the self-sig is what asserts signing capabilities from the > primary key -- if the self-sig is considerd invalid because of, say, an > implementation declining to accept SHA-1 digests, then the primary key > isn't considered signing-capable, which means that signatures made by it > won't be considered valid. > > the digest used in the subkey-binding signature is relevant if you want > to be able to receive encrypted mail (e.g. security bug reports). > > To fix this, just re-issue the self-sigs and subkey binding signatures > with a stronger digest (at least SHA2-256). > > If you're using a modern version of GnuPG that has access to the secret > key, the arcane command to do that is probably something like: > > gpg --cert-digest-algo sha256 --quick-set-expire > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 > gpg --cert-digest-algo sha256 --quick-set-expire > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 0 '*' > > and then re-export and re-publish the OpenPGP certificate wherever it's > published (at least in LIBRESWAN-GPG-KEY.txt in the git repo). > > The first line updates the expiration date and re-issues the self-sig > for the primary key, the second handles the subkey binding signature. > > Note that leaving the expiration date unset (the "0" above) might itself > be problematic if you ever lose control over the key and you don't have > any revocation certificate handy, but that's a separate question. i'd > recommend setting an expiration date of "2y" (instead of "0" above), and > then just repeat this process every time you have a release. Since > releases come out in a less-than-2-year cadence, this should be fine. > > But i'd be happy for now with just a primary key with a non-SHA1 > self-sig. > > Thanks for maintaining libreswan! > > --dkg > > PS here's the diagnosis: > > The "sig:.*:2:" lines are SHA1 signatures here: > > 0 dkg@alice:~$ gpg --with-colons --check-sigs > 907E790F25C1E8E561CD73B585FF4B43B30FC6F9 > tru::1:1652480124:1691085522:3:1:5 > pub:-:4096:1:85FF4B43B30FC6F9:1357089367:::-:::scESC::::::23::0: > fpr:::::::::907E790F25C1E8E561CD73B585FF4B43B30FC6F9: > uid:-::::1357089367::ED0B44951C7DD5295C3DDEF9C67942731B01068E::Libreswan > (Signing Key) <[email protected]>::::::::::0: > sig:!::1:85FF4B43B30FC6F9:1357089367::::Libreswan (Signing Key) > <[email protected]>:13x:::::2: > sig:?::1:E71806A6B5CC27E1:1357192633:::::10x:::::8: > sig:!::1:C30040228501D2EC:1357583027:::::10x:::::2: > sig:!::1:467564B7505DA62B:1420472842:::::10x:::::2: > sig:!::1:62D3582FE0FD94D2:1418273023:::::10x:::::8: > sig:?::1:CCD2ED94D21739E9:1490035473:1553107473::::10l::0EE5BE979282D80B9F7540F1CCD2ED94D21739E9:::10: > sub:-:4096:1:43CD400C70C28757:1357089367::::::e::::::23: > fpr:::::::::1CF137415217927923F01BB943CD400C70C28757: > sig:!::1:85FF4B43B30FC6F9:1357089367::::Libreswan (Signing Key) > <[email protected]>:18x:::::2: > 0 dkg@alice:~$ > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev
signature.asc
Description: Binary data
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
