On Tue, 22 Aug 2006 16:06:08 -0700 Jim Fenton <fenton(_at_)cisco(_dot_)com>
wrote:
Scott Kitterman wrote:
On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Scott Kitterman wrote:
OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I
agree it's better, but there are operational frictions that will impede
this approach in some cases.
What I believe that we've discovered is that this isn't nearly simple as
some people hoped. Doing as little up front as possible so that you can get
operational experience is almost certainly better than guessing --
especially when the guessing wrong is a likely outcome. In this particular
case, I dooubt there will be harm because receivers will always have an
incentive to make better decisions (and hence the desire to upgrade).
I disagree. What I think we've discovered that there is no additional
complexity for signers or authors. It is, in fact, simpler for signers.
With the need to choose the appropriate subdomain depending on which
author-domain submitted the message to the signer, I think the complexity
for signers is now about the same as for key delegation, assuming that the
signer uses the same public key for all of its customers. About the only
thing that changes from author-domain to author-domain is the i= address
and the d= domain.
As I said in the previous message I don't think it's necessarily a
sub-domain per customer.
I think the simplicity for the designated signer approach is for the author
domain. All that's needed is the ability to publish a TXT record with an
underscored domain name in their DNS. These are the same DNS requirements
that exist for DKIM base. I think it's both fair to small author domains
and an aid to deployability to provide this kind of mechanism.
I'm not seeing any significant downside to it that isn't equally a problem
for the NS delegation/operator signs first party for the author approach.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html