Use of '--auto-key-locate pka' for DNS key install results in 'Not implemented' error
Closed, ResolvedPublic

Description

I was attempting to setup a PKA DNS record to allow gpg to find my key through DNS. I
was following instructions found here:

http://www.gushi.org/make-dns-cert/HOWTO.html

I have tested this with 'gpg (GnuPG) 1.4.12' on Ubuntu and it works as expected with
the following command:

echo "foo" | gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-
key-locate pka -r glenn@rempe.us --verbose

gpg: requesting key BECCAE17 from http server www.rempe.us
gpg: pub 4096R/BECCAE17 2014-10-02 Glenn Rempe <glenn@rempe.us>
gpg: using PGP trust model
gpg: NOTE: signature key CF97D091 expired Thu 01 Oct 2015 07:55:20 PM PDT
gpg: key BECCAE17: public key "Glenn Rempe <glenn@rempe.us>" imported
gpg: 1 keys cached (21 signatures)
gpg: 0 keys processed (0 validity counts cleared)
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: automatically retrieved `glenn@rempe.us' via PKA
...etc OK...

However, if I try the same command with version 2.1.10 I get the following error
message:

$ echo "foo" | gpg2 --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --
auto-key-locate pka -r glenn@rempe.us
gpg: error retrieving 'glenn@rempe.us' via PKA: Not implemented
gpg: glenn@rempe.us: skipped: Not implemented
gpg: [stdin]: encryption failed: Not implemented

Here is the DNS record. I've left it in place for testing.

$ dig +short glenn._pka.rempe.us. TXT
"v=pka1\;fpr=497A6138963D6C47202B238BA4A288A3BECCAE17\;uri=http://www.rempe.us/download
s/keys/0xA4A288A3BECCAE17.asc"

Details

Version
2.1.10
grempe set Version to 2.1.10.Jan 9 2016, 9:22 PM
grempe added projects: gnupg, Bug Report.
grempe added a subscriber: grempe.
werner added a subscriber: werner.Jan 11 2016, 11:59 AM

That website is outdated. The format of the PKA records changed. Use

gpg --print-pka-records -k <userid>

to create a record.

You also need to build gnupg with a proper DNS resolver library and make sure
that you are using the matching dirmngr version.

For further questions please resort to the gnupg-users mailing list so that
others may help or learn from the replies.

werner closed this task as Resolved.Jan 11 2016, 11:59 AM
werner claimed this task.
werner added a project: Not A Bug.
grempe reopened this task as Open.Jan 11 2016, 6:44 PM

OK, thanks for the response Werner. Perhaps this bug then is to update the website
docs to reflect what I gather may be big changes to this feature as compared to earlier
gnupg releases.

It seems that everything that can be found here (the best source I have found for using
gnupg w/ DNS) is now outdated and will no longer work:
http://gushi.org/make-dns-cert/HOWTO.html

I wanted to learn more about the new changes but I was only able to find the following
references which I'll document here in case someone else comes across it.
Unfortunately, I won't be able to test out the new method as I don't run my own bind
server and like many of us rely on a DNS provider that doesn't allow me to create the
form of DNS record output by --print-pka-records.

I only found three references to the new '--print-pka-records':

2.1.3 Announce:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000365.html

"* gpg: New option --print-pka-records. Changed the PKA method to use

   CERT records and hashed names."

gnupg docs:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

"--print-pka-records
Modify the output of the list commands to print PKA records suitable to put into DNS
zone files. An ORIGIN line is printed before each record to allow diverting the records
to the corresponding zone file."

And finally an announcement from you in gnupg-devel from last year where you state that
all of the old functionality for PKA has been removed and replaced with something
entirely new (which is just for key 'validation' and not for key installation?):
http://marc.info/?l=gnupg-devel&m=142488047809150&w=2

werner closed this task as Resolved.Jan 14 2016, 10:37 AM