Mailing List Archive: Questions re auto-key-locate

Questions re auto-key-locate

Feb 15, 2022, 12:32 PM

Post #1 of 9 (754 views)

Hey all,

A long time ago I wrote a doc on a blog about putting PGP keys in the DNS,
which has been linked to quite a bit. I also recoded make-dns-cert as a
shell script so that people who want to do this but don't have access to
the make-dns-cert tool (which is not built by default on some OS packages)
had an option to do this.

At the day job, we have a script that we use to push gpg-signed releases
to our FTP server, and as part of that job, it verifies the signatures on
the tarball, and will try to auto-key-locate those keys if it can't find
them.

Since the debacle a few years ago with the SKS keyserver denial-of-service
attack, the keyservers are kind of a non-starter. And because GPG
searches for keys on a tarball by keyid, not by user@domain, a keyserver
is the only real retrieval method available to look up a key by keyid,
which is now a non-starter.

Worse still, if you know a key exists via something like DANE (dayjob
makes DNS software, we like the idea of it being available via DANE),
there's no way to do gpg --search via DANE, only via a keyserver.

Thus, using that as a prefetch method to grab the current version of our
codesign@ key into our keyring is not helpful either, unless we "faked it"
by attempting to encrypt a message to that address, then discarded it.

Is there another way forward? The normal things for auto-key-locate don't
seem to help here. I'm open to ideas.

-Dan

(PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate
a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt." It
should probably say RFC7929 rather than referring to an I-D.)

--

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
FB: fb.com/DanielMahoneyIV
LI: linkedin.com/in/gushi
Site: http://www.gushi.org
---------------------------

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

Re: Questions re auto-key-locate [ In reply to ]

kloecker at kde

Feb 15, 2022, 1:43 PM

Post #2 of 9 (754 views)

Permalink

On Dienstag, 15. Februar 2022 21:32:50 CET Dan Mahoney (Gushi) via Gnupg-users
wrote:
> Worse still, if you know a key exists via something like DANE (dayjob
> makes DNS software, we like the idea of it being available via DANE),
> there's no way to do gpg --search via DANE, only via a keyserver.
>
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
>
> Is there another way forward? The normal things for auto-key-locate don't
> seem to help here. I'm open to ideas.

I'm not sure I understand your question, but you can use --locate-keys instead
of a "faked" --encrypt to look up keys by email address.

Regards,
Ingo

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 15, 2022, 1:57 PM

Post #3 of 9 (754 views)

Permalink

On Tuesday, 15 February 2022 20:32:50 GMT Dan Mahoney (Gushi) via Gnupg-users
wrote:
> Worse still, if you know a key exists via something like DANE (dayjob
> makes DNS software, we like the idea of it being available via DANE),
> there's no way to do gpg --search via DANE, only via a keyserver.
>
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
>
> Is there another way forward? The normal things for auto-key-locate don't
> seem to help here. I'm open to ideas.

Unless I misunderstood what you’re trying to achieve, I think the `--locate-
external-keys` command should be what you’re looking for?

This is basically the equivalent of `--search-keys`, except that the search is
not limited to keyservers but instead use the mechanisms configured via the
`--auto-key-locate` option (which can include DNS lookups, either using the
“historical“ method of RFC-4398, or the modern method of RFC-7929).

- Damien

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 15, 2022, 2:01 PM

Post #4 of 9 (754 views)

Permalink

On Tue, Feb 15, 2022 at 12:32:50PM -0800, Dan Mahoney (Gushi) via Gnupg-users wrote:
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
>
> Is there another way forward? The normal things for auto-key-locate don't
> seem to help here. I'm open to ideas.

Hi, Dan:

Any reason you want to stick with auto-locating keys instead of just
maintaining a keyring for verification purposes?

If you do want to keep using DANE, you can "gpg --auto-key-locate dane
--locate-keys codesign@whatnot" to build your pubring, e.g. (using wkd):

$ export GNUPGHOME=$(mktemp -d)
$ gpg --auto-key-locate wkd --locate-keys torvalds@kernel.org gregkh@kernel.org

We now have a $GNUPGHOME/pubring.kbx containing the keys we can use for
verification. At some point in the past I wrote the following script that
makes use of this exact approach:

https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/get-verified-tarball

-K

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

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 15, 2022, 2:45 PM

Post #5 of 9 (754 views)

Permalink

?
> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users <gnupg-users@gnupg.org> wrote:
>
> Since the debacle a few years ago with the SKS keyserver denial-of-service attack, the keyservers are kind of a non-starter.

Why so? Keyservers are still around, and the ones that survived the apocalypse are generally the ones that are better maintained. The only glitch from a user POV is that you have to publish to both a synchronising server and keys.openpgp.org to make sure everyone sees your updates…

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

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 15, 2022, 3:37 PM

Post #6 of 9 (754 views)

Permalink

> On Feb 15, 2022, at 2:45 PM, Andrew Gallagher <andrewg@andrewg.com> wrote:
>
>
>> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users <gnupg-users@gnupg.org> wrote:
>>
>> Since the debacle a few years ago with the SKS keyserver denial-of-service attack, the keyservers are kind of a non-starter.
>
> Why so? Keyservers are still around, and the ones that survived the apocalypse are generally the ones that are better maintained. The only glitch from a user POV is that you have to publish to both a synchronising server and keys.openpgp.org to make sure everyone sees your updates…

That's a decision I leave up to the people who *make* the key (and the software that it's signing). If they've decided not to push the key out there (and it's no longer the case that you can publish just anyone's key) I need to respect that.

Right now, the decision is that our key (signed with our prior-year key) is on our website and FTP (also via https) site, and we do not assert that it's available on the keyservers.

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

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 15, 2022, 11:03 PM

Post #7 of 9 (753 views)

Permalink

On Tue, Feb 15, 2022 at 12:32:50PM -0800, "Dan Mahoney (Gushi) via Gnupg-users" <gnupg-users@gnupg.org> wrote:

> Hey all,
>
> A long time ago I wrote a doc on a blog about putting PGP keys in the DNS,
> which has been linked to quite a bit. I also recoded make-dns-cert as a
> shell script so that people who want to do this but don't have access to the
> make-dns-cert tool (which is not built by default on some OS packages) had
> an option to do this.
>
> At the day job, we have a script that we use to push gpg-signed releases to
> our FTP server, and as part of that job, it verifies the signatures on the
> tarball, and will try to auto-key-locate those keys if it can't find them.
>
> Since the debacle a few years ago with the SKS keyserver denial-of-service
> attack, the keyservers are kind of a non-starter. And because GPG searches
> for keys on a tarball by keyid, not by user@domain, a keyserver is the only
> real retrieval method available to look up a key by keyid, which is now a
> non-starter.
>
> Worse still, if you know a key exists via something like DANE (dayjob makes
> DNS software, we like the idea of it being available via DANE), there's no
> way to do gpg --search via DANE, only via a keyserver.
>
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
>
> Is there another way forward? The normal things for auto-key-locate don't
> seem to help here. I'm open to ideas.
>
> -Dan
>
> (PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate a
> key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt." It
> should probably say RFC7929 rather than referring to an I-D.)
>
> --
>
> --------Dan Mahoney--------
> Techie, Sysadmin, WebGeek
> Gushi on efnet/undernet IRC
> FB: fb.com/DanielMahoneyIV
> LI: linkedin.com/in/gushi
> Site: http://www.gushi.org
> ---------------------------

Hi,

Recently, I asked for dane to be added to --auto-key-retrieve
when dane was in the auto-key-locate list (https://dev.gnupg.org/T5586),
but the outcome was: "Wontfix: DANE has been an experimental thing
and is imho dead".

I think that experiment might have taken place at a time when DNSSEC
was too much effort to implement. That's not longer the case, so maybe
the experiment should be allowed to continue.

But maybe it is dead. I don't really need it. My only interest was that
I'd written software that manages dane records (including openpgpkey),
but I don't know if anyone else is using that feature. Probably not.

cheers,
raf

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

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 16, 2022, 1:32 AM

Post #8 of 9 (753 views)

Permalink

On 15/02/2022 23:37, Dan Mahoney wrote:
> That's a decision I leave up to the people who *make* the key (and the software that it's signing).

Sorry, from your previous message it sounded like you were publishing
your own software.

> (and it's no longer the case that you can publish just anyone's key)

This is not true, you can still publish any key you want. In the
specific case that you publish to keys.openpgp.org it will not be
searchable by userid until the key owner verifies it, but your use case
only requires lookup by fingerprint, so that doesn't arise.

> Right now, the decision is that our key (signed with our prior-year key) is on our website and FTP (also via https) site, and we do not assert that it's available on the keyservers.

OK, but again I'm curious about the reasoning...

--
Andrew Gallagher

Re: Questions re auto-key-locate [ In reply to ]

gnupg-users at gnupg

Feb 17, 2022, 11:21 AM

Post #9 of 9 (753 views)

Permalink

On Wed, 16 Feb 2022 18:03, raf said:

> But maybe it is dead. I don't really need it. My only interest was that

Yes, it is dead. Except for a minority of users, it is impossible to
easily add new resource records. However, putting new files on a
webserver is easy.

FWIW, you can build your keys for WKD distribution on your local machine
and then rsync (or whatever you use to upload files) them to the
webserver.

gpg-wks-client -C . --install-key [FILE|FINGERPRINT USER-ID]

The command --install-key manually installs a key into a local
directory (see option -C) reflecting the structure of a WKD. The
arguments are a file with the keyblock and the user-id to install.
If the first argument resembles a fingerprint the key is taken from
the current keyring; to force the use of a file, prefix the first
argument with "./". If no arguments are given the parameters are
read from stdin; the expected format are lines with the fingerprint
and the mailbox separated by a space. The command --remove-key
removes a key from that directory, its only argument is a user-id

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Mailing List Archive

Attached Files:

Attached Files:

Attached Files:

Attached Files: