A lot of questions about CERT, PKA and make-dns-cert

[David Shaw]

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  
the bug.

> 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  
> fingerprint
>
> 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.

David