Some PKA notes

[Phil Pennock]

Further to Werner's work on the new-style PKA records, as announced at:
  https://lists.gnupg.org/pipermail/gnupg-devel/2015-February/029544.html
I did some debugging to get this working for me; here are some notes,
which might be useful for feeding back into documentation or FAQs.  Also
a Python script, attached and as a GitHub gist.

I initially added to DNS zones I control records from output of:

  gpg2.1 --export-options export-minimal,export-pka \
    --export 0x4D1E900E14C1CC04

In the spodhuis.org zone, I've now updated these, per the below.

The DNS records from that look like:

  $ORIGIN _pka.spodhuis.org.
  r6thk89hkz9zsaiqecoquhaucjatbz3o TYPE37 \# 26 0006 0000 00 14 ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04

Testing with:

  $ export GNUPGHOME=$(mktemp -dt gpg.XXXXXXXXX)
  $ echo foo | gpg -v --auto-key-locate pka -r pdp at spodhuis.org -ea
  gpg: auto-key-locate found fingerprint ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
  gpg: error retrieving 'pdp at spodhuis.org' via PKA: No public key
  gpg: pdp at spodhuis.org: skipped: No public key
  gpg: [stdin]: encryption failed: No public key

Specifying an explicit keyserver on the command-line failed too.

The DNS records are actually classic CERT records of type 6 (IPGP); I
had these already, just not in _pka and for the unencoded LHS; skimming
GnuPG source showed that the URL was being returned from the DNS parsing
function.

So I tried copying my existing DNS records into place and giving them
the right name; the records length-prefix the fingerprint and any data
after that is a URL to get the content from.  I was using
<https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc>.

  gpg: requesting key 4D1E900E14C1CC04 from https server www.security.spodhuis.org
  gpg: error retrieving 'pdp at spodhuis.org' via PKA: General error

Fix:

  grep '^hkp-cacert' ~/.gnupg/dirmngr.conf >| $GNUPGHOME/dirmngr.conf
  gpgconf --kill dirmngr

But there was still an error (which I can't find in scrollback, sorry).

Turning up dirmngr logging levels revealed that the URL returned was
being massaged into an HKP URL:

  error accessing 'https://www.security.spodhuis.org:443/pks/lookup?op=get&options=mr&search=0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04': http status 404

So I switched to specifying my SKS keyserver:

  % echo foo | gpg -v --auto-key-locate pka -r pdp at spodhuis.org -ea
  gpg: no running Dirmngr - starting '/usr/local/bin/dirmngr'
  gpg: waiting for the dirmngr to come up ... (5s)
  gpg: connection to the dirmngr established
  gpg: requesting key 4D1E900E14C1CC04 from https server sks.spodhuis.org
  gpg: data source: https://sks.spodhuis.org:443
  gpg: armor header: Version: SKS 1.1.5
  gpg: armor header: Comment: Hostname: sks.spodhuis.org
  gpg: pub  rsa4096/4D1E900E14C1CC04 2013-10-22  Phil Pennock <pdp at exim.org>
  gpg: /home/pdp/tmp/gpg.XXXXXXXXX.Am0UHa5O/trustdb.gpg: trustdb created
  gpg: using pgp trust model
  gpg: key 4D1E900E14C1CC04: public key "Phil Pennock <phil.pennock at spodhuis.org>" imported
  gpg: no running gpg-agent - starting '/usr/local/bin/gpg-agent'
  gpg: waiting for the agent to come up ... (5s)
  gpg: connection to agent established
  gpg: 0 keys processed (0 validity counts cleared)
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 1
  gpg:               imported: 1
  gpg: auto-key-locate found fingerprint ACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
  gpg: using subkey A445DC2B1C5B7F39 instead of primary key 4D1E900E14C1CC04
  gpg: automatically retrieved 'pdp at spodhuis.org' via PKA
  gpg: A445DC2B1C5B7F39: There is no assurance this key belongs to the named user
  sub  rsa4096/A445DC2B1C5B7F39 2013-10-22 Phil Pennock <phil.pennock at spodhuis.org>
   Primary key fingerprint: ACBB 4324 393A DE35 15DA  2DDA 4D1E 900E 14C1 CC04
        Subkey fingerprint: A689 CBD8 637B 57F2 B46B  7F53 A445 DC2B 1C5B 7F39


Success!

Other notes:
* The RR-name is encoded with Zooko-base32 encoding
* The zbase32 Python module does not support Python3, so the attached
  script is Python2 instead
* The payload in CERT form is given as base64-encoded data

r6thk89hkz9zsaiqecoquhaucjatbz3o  IN  CERT  6 0 0 FKy7QyQ5Ot41Fdot2k0ekA4UwcwEaHR0cHM6Ly9za3Muc3BvZGh1aXMub3Jn
96bqcjktdxra6hd6mor16dn1huc49irf  IN  CERT  6 0 0 FKy7QyQ5Ot41Fdot2k0ekA4UwcwEaHR0cHM6Ly9za3Muc3BvZGh1aXMub3Jn

The attached script is Python 2 (only tested with 2.7.12), requires
`pip install attrs zbase32` and can be found in a Gist for retrieval at:

  https://gist.github.com/philpennock/30d030b6d1d0d86603febdabd98a1313

Invoked as:

  ./pka.py -k https://sks.spodhuis.org $pgp_key_main

gives output modelled after that from `gpg --export-options export-pka`
in CERT form, not TYPE37, skipping only the display-name (laziness in
what data I schlep around) but including the URL.  Skip the `-k
$keyserver` and the non-comment output should match on-the-wire that
from gpg.

Regards,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pka.py
Type: text/x-python
Size: 3272 bytes
Desc: not available
URL: </pipermail/attachments/20160824/47e1a245/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: </pipermail/attachments/20160824/47e1a245/attachment-0001.sig>