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

[Dan Mahoney, System Admin]

On Wed, 21 Oct 2009, David Shaw wrote:

> On Oct 20, 2009, at 10:55 PM, Dan Mahoney, System Admin wrote:
>
>> On Thu, 15 Oct 2009, David Shaw wrote:
>> 
>>> On Oct 15, 2009, at 9:37 PM, Dan Mahoney, System Admin wrote:
>>>> 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?
>> 
>> I tried this again, after I nuked the "fingerprint" cert record.
>> 
>> Oddly, running on gpg2 on an older debian system, I get:
>> 
>> # echo "foo" | gpg2 -v -v --auto-key-locate cert --encrypt -r 
>> gushi at gushi.org
>> gpg: no keyserver known (use option --keyserver)
>> gpg: error retrieving `gushi at gushi.org' via DNS CERT: General error
>> gpg: gushi at gushi.org: skipped: General error
>> gpg: [stdin]: encryption failed: General error
>> 
>> That first line specifically makes me scratch my head a bit.
>
> You didn't give an actual version number (run gpg2 --version), so I can only 
> make an educated guess, but I do think I see your problem.  You don't have 
> one key in your CERT - you have two (309C17C5 and 624BB249) combined into one 
> DNS record.  That doesn't work - it's a one-name-one-key mapping.  We should 
> give a better error message in this case.
>
> Can you try again with a single key in your CERT?  Alternately, if you want 
> both of your keys, you could use 2 different CERT records for the 
> gushi.gushi.org. name, each with one of your keys (rather than 1 CERT record 
> with a payload containing two keys).  Note that this will usually result in 
> round-robining for those people who don't have your key, which may or may not 
> be what you want.

For the benefit of people who may search this later, what's the best 
set of args to extract the key with?

Neither export-clean nor export-minimal seems to be what I want.  In 
effect what I want is only the most recent signature from each other key, 
so some hybrid of export-clean and export-minimal?

> At least using gpg 2.0.13, and a single key in the CERT, this works properly 
> for me.  I can't speak for an earlier version.
>
> All of that said, I think it's worth pointing out that IPGP (the 
> fingerprint+URL variation of CERT) is far more useful that PGP (the full 
> key).  Not all systems are going to be able to pass a 1718-byte DNS message, 
> as yours is.

As DNSSEC becomes more widely adopted, as EDNS0 and TCPDNS become more the 
norm, this is less of an issue. IPGP is also little more than a 
standards-based version of HKP, which I'm also publishing.

If I've uncommented the line in options.skel (present in some distros, 
not others), the order will be:
#auto-key-locate cert pka ldap hkp://subkeys.pgp.net

(one of my other pet peeves is that gpg hangs up on unknown options, 
instead of falling to the next, so if I haven't compiled with LDAP 
support that whole line will break things.  Is this worth filing a bug?)

Anyway, if we assume most people just say "yeah sounds good" and uncomment 
the option, pka is a chance to get info out if CERT fails.  Why would I 
duplicate the same info?  If I've published an IPGP cert, and it fails to 
validate, the same info in PKA won't fare any better.

Since there's no way to reliably publish both forms of CERT and have the 
client able to request one or the other (or parse all records until we 
find one that works, instead of the first it gets), the PGP variant 
actually gets the key out there in a case where the URL is unretrievable 
(for example, behind a firewall where outbound finger is blocked, or in a 
case where we're compiled without curl support, but hitting a host that 
requires HTTP 1.1).  Put another way, with PGP, all the info you need is 
in the DNS packets.  With IPGP, you have another step to chase down.

Only parsing one CERT response also prevents one from putting in multiple 
keys with the same key retrievable via multiple URIs, i.e. one finger, one 
http, etc.  (On a related note, I can't specify multiple keyservers to 
search on the command line or in my config file, which is also annoying, 
is this worth filing a bug?).

Is the way a CERT record is parsed (i.e. only parsing the first one) 
goverened by an RFC?  Or considering the likely little use this is 
getting, do you feel it's too late in the game to change the way multiple 
records would be handled?

This is also why I asked for a list of what uri formats are supported, and 
it would help me to know which of those are retrievable by default with no 
external libs.  Given an HTTPS-capable webserver where I also control 
vhost order, if I only have one URI-format to publish, what's my best 
chance to have this support the most clients?  Hell, can one put an hkp:// 
uri in that URL field?

>> I suspect strongly that this feature doesn't get the most broad platform 
>> testing.  Let me know if you'd like to help.
>
> Please do!  More testing is always welcome.
>
> David

-- 

"No mowore webooting!!!"

-Paul, 10-16-99, 10 PM

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