Proof of email ownership

[Jeroen Massar]

Werner Koch wrote:
<SNIP>
>   gpg -s -Npka-address at gnupg.org=werner at 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:wk at example.com"

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 -Npka-address at gnupg.org=test at example.org foo

while you send the mail from tester at example.com. example.com doesn't
have a keyserver, example.org has. test at example.org 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20050807/8801fe5f/signature.pgp