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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf