[Swan-dev] Libreswan signing key (907E790F25C1E8E561CD73B585FF4B43B30FC6F9)

[Paul Wouters]

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 <dkg at fifthhorseman.net> 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 at 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) <team at libreswan.org>::::::::::0:
> sig:!::1:85FF4B43B30FC6F9:1357089367::::Libreswan (Signing Key) <team at libreswan.org>: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) <team at libreswan.org>:18x:::::2:
> 0 dkg at alice:~$ 
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/octet-stream
Size: 227 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20220525/70af7fe8/attachment.obj>