On Tue, 22 Aug 2006 16:06:08 -0700 Jim Fenton <[EMAIL PROTECTED]> wrote: >Scott Kitterman wrote: > >On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <[EMAIL PROTECTED]> 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
