Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released)

[Jeroen Massar]

[Cross-post-reply to most-likely interrested parties... strip where
needed]

On Mon, 2006-04-03 at 14:13 +0200, Werner Koch wrote:
 
> We are pleased to announce the availability of a new stable GnuPG
> release: Version 1.4.3

Neat ;) Muchos thanks to all the developers for their work!

>     * Implemented Public Key Association (PKA) signature verification.
[..]
>     * New auto-key-locate option that takes an ordered list of methods
>       to locate a key if it is not available at encryption time (-r or
>       --recipient).  Possible methods include "cert" (use DNS CERT as
>       per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP
>       server for the domain in question), "keyserver" (use the
>       currently defined keyserver), as well as arbitrary keyserver
>       URIs that will be contacted for the key.
> 
>     * Able to retrieve keys using DNS CERT records as per RFC-2538bis
>       (currently in draft): http://www.josefsson.org/rfc2538bis

These three lead to one big question though:
  Can we start doing automatic key verification for mail !?

It would be really good if there would now come a draft which will
propose the standard order of getting a key, when one doesn't have it or
wants to get it again. This release of GnuPG allows one to already
specify it. It would be really good if this was standardized and also
implemented. Especially in combination with a domain policy (which could
be incorporated in say SPF).

Thus, eg I mail from jeroen at unfix.org, one can lookup _policy.unfix.org,
which will say "mail:PGP:required" or something similar. SMTP
clients/servers receiving mail signed by me, can then use one, or more,
of the key retrieval techniques to fetch the key. PKA + Cert become very
good for this and thus allow automatic verification. When the mail is
not signed or falsely signed, one can discard the message based on the
policy.

For ease of deployment SMTP gateways, which receive mails from
authenticated (IP or user/pass etc based) can auto-sign unsigned email
with a generic 'automatic' key. Existing clients won't thus be affected,
unless they don't use the ISP's SMTP gateway. If they want to avoid
using the ISP's gateway, they need to have their key in DNS though.


This all though leads to a concern on the placing of the CERTS. Having a
large user base would mean that one has say 600k records or more in the
main zone for a domain, which gets reloaded every now and then when one
needs to update it. It would IMHO be better to be able to off load those
records to say _cert.example.org. Which has several benefits, one can
then run their normal DNS adminstration and delegate the CERT records to
a dedicated DNS server set which can handle the updates easier or simply
runs out of a DNSBackend. This will also be easier management wise with
DNSSEC I expect and remove the strain from the main boxes, which
currently might have maybe upto 100 RR's on average in a zone,
especially in the case of webhosting farms where one only specifies the
www.example.org and nothing else.

Of course this will also require a lot of software to make it working,
but this is going in the right direction! :)

Greets,
 Jeroen
  (Who sees this way as one of the better ways of
   killing of forged mail, bounces etc...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20060404/81ba7c17/attachment-0001.pgp