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

Dan Mahoney, System Admin danm at prime.gushi.org
Fri Oct 16 06:34:46 CEST 2009


On Thu, 15 Oct 2009, David Shaw wrote:

David,

For starters let me thank you on both the fullness and the expedience of 
your answer.  Far too many open source projects just go "crickets" when I 
send out a laundry list, and I need to recognize your time.  Let me also 
apologize in advance for my wordiness.  We have quite a bit of ground to 
cover.

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

I was referencing this thread:

http://lists.gnupg.org/pipermail/gnupg-users/2006-April/028314.html

If that's no longer the case, then no worry.  I suppose if doc were more 
abundant I wouldn't have had to pore over old mailing list entries looking 
for examples :)  The few examples I've seen online as to how to use this 
have the FP whitespace-stripped, so I assumed it was done so deliberately 
to work around that, and I did the same.

> Whether TXT or CERT, though, it's a fairly high barrier for many users.

True, and sadly, applying for a separate typecode would be an additional 
barrier to entry there.  (SPF made TXT what it is today!)  Is there a 
formal spec document?  The most I could find was a PDF slideshow.

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

Docs, I'm totally on.  I'm trying as much as I can to link to the 
standards docs as well, which is why I was asking for a 
supported-uri-format doc.

Ideally there should be something in the gpg faq, something in the 
manpage, and at least a small README in tools that covers all the things 
in there (maybe we can talk about what the rest of those do as well).

If you really feel up to making code changes:

gpg --export --format cert-PGP danm at prime.gushi.org
gpg --export --format cert-IPGP gushi at gushi.org [--url=http://foo]
gpg --export --format pka foo at bar.com --url=http://foo

Some variation on the above would all be wonderful, but I don't think I'm 
likely to get that wish granted.

One of the tutorials I saw made reference of using pgp-clean -- what is 
the gnupg equivalent of this?

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

No, I'm just looking for a full list of what you can put in the uri= 
portion of a _pka record.  I never found it enumerated.  Is https 
supported?  If so, does the system do cert validation?  I've seen finger 
and http, but wouldn't know where in the code to try to read to figure out 
the full list.

I also didn't find a clear listing of what format the key should be in, 
although the finger "hinted" at the usual armored format.  From a code 
end, I'd like to know for sure if either/both work.

>> 4) Try though I might, I can't seem to get my full-key in CERT format to 
>> recognize.
>
> It works fine for me.  What version of GPG are you using?

gpg (GnuPG) 2.0.12
libgcrypt 1.4.4

When you say it works for you, do you mean you're able to parse my key, or 
that you've been able to publish and retrieve your own CERT-PGP record?

If I nuke things down to my single cert-ipgp record, could you try again?

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

I did that because it complained about having "no fingerprint", so I 
thought for a moment it needed both kinds, one with the key, and a 
separate one with the FP.

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

The cert is a single, long, unbroken hex string.  BIND will understand it 
if you chuck it into an include file or paste it in with a non-wrapping 
editor.  But it's fragile and unwieldly.

If you feel like carefully counting characters, you can wrap it, as long 
as you hit a hex boundary.  Adding a few spaces and parens would make it 
just work if wrapped.  And the presentation format should be base64, not 
binary (dnssec-signzone will convert both _pka and CERT records to this 
format anyway).

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

Per one of the BIND developers, cert has been supported for 10 years, 
typeXX for 7, although you probably would have had to use numeric algo 
id's.

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

I think so.  I'm in favor of keeping the algotype numeric, but using the 
CERT record, properly encoded.  For most DNS folks, the \# notation is 
confusing: it looks like an escaped comment.

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------




More information about the Gnupg-users mailing list