I must be missing much of this argument. Dkim.bar.com=ISP.com does all of my signing Dkim.isp.com=publickey_yadayada That is manageable and not inventing a new technology. I think we need to avoid not only Touring Complete syndrome but also Tourettes as well.
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Levine Sent: Friday, August 25, 2006 3:17 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy designdecision >My point is that without the DSD mechanism, key delegation is arguably >much more likely to be used. And if true, that means we have to do more >work analysing key management. With DSD, key delegation is arguably >much less likely to be used, or at least can be more easily avoided, in >which case analysis of key management is less of an issue for us. I can see how the analysis would be different, but it's hard to see why it would be less complex. With DNS delegation, the name space is a tree, and we understand the security properties of tree delegation pretty well, warts and all. With DSD, we now overlay a graph with unknown security properties onto that tree. I'd hope we have enough self-discipline to keep it a two-level graph rather than a Turing complete rats' nest a la SPF, but recent discussion here is not encouraging. Even as is I am pretty sure we have not yet explored all of the grotty things one could do with existing DNS features and one level of indirection in SSP. We've already seen one subtle security bug in a single indirection scheme that seems to have no solution short of doing severe violence to dkim-base, and that surely will not be the last. To me, it just seems nuts to invent a new mechanism with unknown properties that has not yet been implemented anywhere merely to make an end run around a few providers who don't currently offer the well understood delegation scheme that is used for everything else. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html