A lot of questions about CERT, PKA and make-dns-cert
dshaw at jabberwocky.com
Fri Oct 16 05:27:52 CEST 2009
On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote:
> 1) Currently the only tool that can generate a CERT record, make-dns-
> cert, is not built or packaged by default under any os I've found
> (I've tried FreeBSD and ubuntu). It has no documentation, no
> examples, and only a terse 4-line usage summary. I've also seen a
> few bugs reported with it, that I don't know if they're fixed, such
> as not handling whitespace in the key fingerprint properly.
The whitespace issue was handled back in 2006 (one day after the
program was added to GnuPG, as it happens). Possibly you saw an email
from someone who was tracking the code repository in between
releases. There is no version of GnuPG that was ever released with
> 2) I realize this is a fringe feature, but other than a few
> scattered blog posts that reference each other, some of which are
> written by gnupg developers, info on these methods is HARD TO FIND.
> There's nothing in the docs/faq about this, at all. I think
> adoption would be much more widespread if this were a faq-able
> item. It's mentioned once in the manpage, once in the default
> gnupg.conf, and that's really it. If you document it, people will
> use it (and with thawte dropping personal freemail certs lately,
> this is something you want).
Even if the documentation was better (and I agree, it is poorly
documented), I don't think CERT or PKA would be a very widely used
feature. The reality is that the majority of users do not have the
kind of access to DNS that CERT requires. PKA is a bit better in this
regard as it uses TXT records, which can at least be used by people
who have some web-based DNS configuration for their domain. I don't
know of many of those configuration tools that do CERT at all (we're
talking text-files-and-bind usually for CERT). Whether TXT or CERT,
though, it's a fairly high barrier for many users.
I do encourage you to document it better, and I'm willing to help
explain wherever necessary, or make code changes if there is something
that could be done better.
> 3) As far as I know, PKA isn't standardized in any RFC. Has this
> been changed? I saw mention of applying to IANA for its own
> typecode. Is there a list somewhere of what uri types are
> supported? I saw talk of it not supporting http 1.1, but that may
> be fixed with curl.
If you build GnuPG with curl (which is the default, assuming you have
curl), then you have HTTP 1.1 support. That said, is there a
particular HTTP 1.1 feature that you need here? After the PKA parsing
happens, GPG is just doing a regular HTTP GET.
> 4) Try though I might, I can't seem to get my full-key in CERT
> format to recognize. I am not sure if this is because my key is
> "complicated" (i.e. it has subkeys), because the cert is not under
> my primary uid, or because I just plain exported it wrong.
> I'm running:
> echo foo | gpg -v -v --auto-key-locate cert --recipient gushi at gushi.org
> --encrypt -a
> And get gpg: error retrieving `gushi at gushi.org' via DNS CERT: No
> I exported my key with:
> gpg --export --export-options minimal > file; and make-dns-cert -n
> gushi.gushi.org -f file
It works fine for me. What version of GPG are you using?
Incidentally, you have two different CERT records for gushi.gushi.org
at the same time. You have both a fingerprint-style answer and a full-
key answer. This is not a major problem (GPG won't care - it'll just
take the first one that parses), but if your nameserver does some sort
of round-robining, it can be confusing as to which record is the one
that gets used.
> 5) Finally, the quality of records being generated, while consistent
> with rfc3597, leaves them as a real bear to manage, and import. If
> you're going to export them in hex, could we please also get
> whitespace so we can get this into an editor easily? Ideally, the
> things would just be base64 encoded, in accordance with rfc4398.
> Most versions of bind9 understand the CERT record, with base64
> representation, and numeric typecodes. bind9.6 understands the PGP
> type value mnemonic but not IPGP. BIND 9.7 understands IPGP.
When I wrote the code, precious few nameservers understood any of this
(and none understood IPGP at all - that patch only went into BIND a
few months ago). That's why the record is TYPE37 and not CERT. It's
ugly, but it was the least common denominator. It has been a few
years since then. Possibly it's time to upgrade.
More information about the Gnupg-users