Werner Koch wrote: <SNIP> > gpg -s [EMAIL PROTECTED]@example.org foo
This parts looks good...
> gpg detects that foo.gpg has the notation key pka-address at gnupg.org
> and takes its value (werner at example.org) to run a DNS query like:
>
> $ host -t txt werner._pka.example.org
> werner._pka.example.org text "v=pka1\;fpr=A4D94E92B0986AB5EE9DC\
> D755DE249965B0358A2\;uri=finger:[EMAIL PROTECTED]"
This will never be accepted by the IETF because:
- DNS is not a directory for random information
- Don't overload TXT records (though you can go the SPF
way and just make a record called SPF which is a TXT)
I've been thinking about the above quite a bit and I would actually want
to solve it somewhat similar but a bit different.
What about a DNS RR that looks like;
example.org
PGPSRV https keyserver.example.net /pks/
PGPSRV hkp keyserver.example.net
These two records basically are the same as specifying:
keyserver https://keyserver.example.net/pks/
keyserver hkp://keyserver.example.net
in the gpg.conf
This thus allows one to specify the keyserver location for that domain,
which one could point to pgp.mit.edu too if wanted.
Another approach would be DNS-SD, but they don't allow multiple
protocols at the moment. Which is why I brought up:
http://www.ietf.org/internet-drafts/draft-massar-dnsop-service-00.txt
but the folks tripped heavily over the word anycast there, I should have
avoided that part. A simple:
_pka.example.org TXT "https://keyserver.example.net/pks/";
also does the trick, but we need a standard for this.
Btw I specified https above, which is something I would really like to
see implemented and usable in gpg. This allows everybody, who has access
to their DNS that is, to specify a keyserver of their choice for that
domain. The HTTPS, which implies SSL, makes it able for gnupg to have a
secure transfer of this data and verification of the SSL certificate to
know that you are really talking to the correct host in the first place.
(DNSSEC might then also be nice to have, but we'll have to wait a bit
for that to be deployed everywhere...)
$ dig _pgpkey._service.unfix.org any
_pgpkey._service.unfix.org. 3600 IN PTR _pgpkey-http._tcp.unfix.org.
_pgpkey._service.unfix.org. 3600 IN PTR
_pgpkey-https._tcp.unfix.org.
$ dig _pgpkey-https._tcp.unfix.org. any
_pgpkey-https._tcp.unfix.org. 3600 IN TXT "path=/pks/"
_pgpkey-https._tcp.unfix.org. 3600 IN SRV 13 100 443
purgatory.unfix.org.
As to a note from somebody else "what about domains that people don't
have access to and thus can't configure the above". One might make an
extra uid, to a domain that does support the above trick, the key can
then also be automatically fetched. eg:
gpg -s [EMAIL PROTECTED]@example.org foo
while you send the mail from [EMAIL PROTECTED] example.com doesn't
have a keyserver, example.org has. [EMAIL PROTECTED] is a (sub)key, but
both keys are in the same set.
Another note is that this all indeed still does not imply any trust,
that needs to come from a lot of users signing your key, one way to
solve it would be to have the domain admin have a trusted key, thus
someone who has been verified, and have this key sign the keys in that
domain, could even been done semi-automatically, this way the user key
becomes quite trusted too. This might be good for larger installation.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
