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 gu...@gushi.org
--encrypt -a
And get gpg: error retrieving `gu...@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
gu...@gushi.org
gpg: no keyserver known (use option --keyserver)
gpg: error retrieving `gu...@gushi.org' via DNS CERT: General error
gpg: gu...@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
---------------------------
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
