Re: Questions re auto-key-locate
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. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions re auto-key-locate
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 OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions re auto-key-locate
On Tue, Feb 15, 2022 at 12:32:50PM -0800, "Dan Mahoney (Gushi) via Gnupg-users" 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
> On Feb 15, 2022, at 2:45 PM, Andrew Gallagher wrote: > > >> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users >> 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
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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions re auto-key-locate
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 torva...@kernel.org gre...@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
> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users > 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
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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Questions re auto-key-locate
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
