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:
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
> 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:
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
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
> It works fine for me. What version of GPG are you using?
gpg (GnuPG) 2.0.12
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
> 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
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
> 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.
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
More information about the Gnupg-users