Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)

["william(at)elan.net" <william at elan.net>]

On Thu, 22 Dec 2005, Keith Moore wrote:

> Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to 
> store public key information is one of the fundamental assumptions behind 
> DKIM.  Change that assumption and you will probably produce a system with 
> very different characteristics than DKIM is currently assumed to have.

Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advantages and unlike DKIM or DK does not put serious extra
pressure on DNS infrastructure - which while very capable of serving data 
like ip addresses (i.e. fixed size small data) would not work so well for 
when data served & answer would either come close to or exceed 512bytes 
UDP limit.

But fingerprints (hash of public key) are finite and small pieces of data
that are the same size no matter of public key size has to be larger or
smaller and with this size being close to that of ipv6 address. Additionally
having public key available with a message brings some additional advantages
and allows for optimized algorithms during verification.

As I noted the group forcefully removed considerations of such alternatives
based on the charter and I consider this to be a disadvantage to community.

> OTOH, the assumption that _all_ public keys used to validate DKIM signatures 
> will be stored in DNS is a very limiting one, because it appears to lead to 
> either
>
> a) a constraint that policy be specified only on a per-domain basis (which 
> is far too coarse for many domains) or
>
> b) a situation that large numbers of DNS queries may be required to validate 
> a single signature

Its rather likely that it would lead to both.

> I'm comfortable with having a domain's "root public keys" stored in DNS but 
> allowing the corresponding "root private keys" to sign key certificates for 
> "individual public keys" that can be included in DKIM-signed messages.  The 
> policies for use of those public keys can then be encoded in the
> certificates, allowing those policies to be specified on a per-user basis.

You can just use X.509 certificates and retrieve them from HTTP with SRV
records being used to confirm location of domain's root certificate. That 
walso one of the other alternatives (and the one I used for my proposal)
and yes, it does make it much easier to do per-user policies & signatures.

> This gets out of the trap of having to specify policy on a per-domain basis, 
> and doesn't require any more DNS queries than current DKIM.  IMHO it would 
> make DKIM much more flexible and adaptable to diverse domain situations (and 
> thereby much more acceptable as a standard) than the current proposal.
>
> Keith
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf