Mailing List Archive

Hi Simon,

On 27.01.2023 09:13, Simon Josefsson via Gnupg-devel wrote:
> Currently I'm using the text below, which recommends 'gpg
> --locate-external-key' as the preferred mechanism and normally that uses
> WKD and will try to refresh the key from the server (otherwise people
> get old cached keys from local key storage). I like the simplicity and
> UX of this approach. This mechanism must be able to retrieve all
> currently valid keys for a particular e-mail address, otherwise people
> will complain not finding the right key.

I don't know if you know but if the signature contains Signer's User ID
packet (added with --sender email@example.com option during gpg --sign)
then when verifying you can use --auto-key-retrieve and it will use WKD
to fetch the key (of course the Signer User ID packet is needed to
supply the e-mail at verification time).

This makes verification one command instead of two (first get the key
then verify).

> Second to using the e-mail, maybe retrieving by key id should be
> preferred because that is more stable. However there aren't really any
> stable working keyid-based OpenPGP key search engines left, are there?
> So this method is not reliable. There also were issues with it using
> only the first 64-bit of the key id, and I'm not sure this is fixed
> (hence the text below uses only that to not give false sense of
> security). The --recv-keys parameter behaves different for different
> GnuPG versions wrt default keyserver and has been somewhat unreliable in
> the last 5 years or so. It also requires additional configuration, most
> GnuPG installation doesn't come with a default keyserver URL.

There is keys.openpgp.org and it allows fetching keys via subkey
fingerprints.

Still, since it's technically possible to put multiple keys on WKD IMO
the spec should say what to do when there are multiple keys there (e.g.
prefer the most recent key, and specify what does it mean for key to be
recent).

The problem, as described earlier, is only for encryption subkeys and I
wouldn't mind if the e-mail client just used all valid available keys
(for key rotation) but I think the notion of "one recipient, one key" is
ingrained so hard that it's not going to change.

Kind regards,
Wiktor

PS. Sample clearsigned file with the Signer's User ID packet (remove #,
you can pipe it to gpg --list-packets):

#-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

santa
#-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQTn4rhKNkV76j9DaS3mi+OzEvoz/AUCY9OMZRQcd2lrdG9yQG1l
dGFjb2RlLmJpegAKCRDmi+OzEvoz/K6bAQDmxeSoILv1D9wFEPYmEYFiYjKiO5M1
oWh/sJz8o/kjygD9EpihKlBRhKcH/hf1tsAwqE7iomDM98CsSJ6kxTHnFQ0=
=RQba
#-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hi!

Just a quick note:

> Currently I'm using the text below, which recommends 'gpg
> --locate-external-key' as the preferred mechanism and normally that uses
> WKD and will try to refresh the key from the server (otherwise people
> get old cached keys from local key storage). I like the simplicity and

You may also include the key in the signature:

gpg -sabvu commit --include-key </etc/motd >motd.asc

and then advise to use

gpg --verify --auto-key-import -v motd.asc /etc/motd

However, auto-key-import will only import the key if is not yet there.
It won't update a key. These options are available since gnupg 2.2.20

FWIW, I recently had to build gcc and I have found no way to validate
the key of Jakub. No key signatures available and I have found nowhere
a listing of fingerprints - even not on the RedHat site which only lists
product keys. If even I am not able to figure this out, how shall we
bootstrap our software ecosystem in a somewhat secure way? How does
Debian verifies that a gcc update is pristine - private exchange of keys
with Jakub?

--locate-external-key does not help either because it relies on the very
same mechanism we anyway use to download the source (i.e. TLS).


Salam-Shalom,

Werner


p.s.
gcc is just one of a myriad of examples; sorry for picking its author

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

* Simon Josefsson via Gnupg-devel <gnupg-devel@gnupg.org>, 2023-01-27 09:13:
> gpg --recv-keys 51722B08FE4745A2

Beware that this may import unrelated keys to your keyring:
https://bugs.debian.org/909755

--
Jakub Wilk

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Am Freitag 27 Januar 2023 09:13:15 schrieb Simon Josefsson via Gnupg-devel:
> my goal is to come up with the best/safest text to write in a software
> release on how to verify OpenPGP signatures for the tarball.
>
> Currently I'm using the text below, which recommends 'gpg
> --locate-external-key' as the preferred mechanism and normally that uses
> WKD and will try to refresh the key from the server (otherwise people
> get old cached keys from local key storage).  I like the simplicity and
> UX of this approach.

If the email address has the same domain as the downloading domain
of the package, it all is controlled by the same entity. It would make more
sense to have a second paths to building trust in a public key.

One source of trust would be that you already have an old pub key from a
previous download.

Another practice I hope to establish is that clients will from time to time
query a keyserver about the pubkey to have a chance to see if there is a
revokation for the pubkey, they'll get from the email provider and to have a
chance to detect malicious acts by the email provider itself.

> This mechanism must be able to retrieve all
> currently valid keys for a particular e-mail address, otherwise people
> will complain not finding the right key.

This only is a problem if an old tarball is to be verified.
One way to build trust could be to get the new, current, recommended pubkey
from the WKD and then retrieve the other pubkey from a keyserver
and a signature from the WKD pubkey. Would only work if keyserver
would carry 3rd party signatures again.

> Second to using the e-mail, maybe retrieving by key id should be
> preferred because that is more stable.  However there aren't really any
> stable working keyid-based OpenPGP key search engines left, are there?

Sure, a number of them:
https://spider.pgpkeys.eu/
e.g.
https://keyserver2.gnupg.org/

Bernhard
--
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter

On Sat, 28 Jan 2023 23:50, Jakub Wilk said:

> Beware that this may import unrelated keys to your keyring:
> https://bugs.debian.org/909755

Nope (see also https://dev.gnupg.org/T3398). The security of GnUPG
OpenPGP keys does not rely on the keys in a certain database but soley
on key signatures.

The whole idea of using "curated keyrings" for general purposes is
entirely wrong. If you do this, you should at least disable dirmngr and
don't use any frontends or tools which might import keys (e.g. taken
from a mail).

The only standard use of "curated keyrings" is with gpgv which - for
that reason - uses a dedicated file name (trustedkeys.kbx or
trustedkeys.gpg).


Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein