Related to how much the charter pre-supposes the solution, the sentence
that "Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy." seems like a pretty heavy
constraint on the possible solutions and one that some proposals
disagreed with.
I think this is part of "divide and conquer" that is generally argued to
be an useful strategy in the IETF: once we buckle down and start writing
specs, we're documenting one approach, with one set of advantages and
disadvantages, and are trying to prove that *this approach* is feasible.
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.
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
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. 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf