On Wed, 2005-11-02 at 09:38 +0000, Stephen Farrell wrote: > Doug, > > Douglas Otis wrote: > > > The revocation record would be self-published within their domain in > > the same fashion as the keys. If the task of publishing the revocation > > records proves too burdensome, they could delegate the revocation zone > > to a provider ... > > So you need a different mechanism to distribute those > revocation lists to the provider when they're too > big/quickly changing for me to manage in my own > domain. Is that what you mean?
I was considering the entire aspect of responding to abuse reports and revoking accounts. If that entire process were delegated, then the revocation zone should also be delegated. It is possible to automate most aspects of this process. While perhaps not everyone would want to make that effort, some providers could specialize in this aspect of the process. > If so, which protocol is used for that? There would be no changes to the protocol to delegate this task. > If that's an intrinsic part of your opaque-identifier scheme, > then it'd have to be specified at the same time or else we'd > have an unacceptable scaling issue, right? I brought this up to allay concerns about automation more than scaling. If message replay abuse becomes a problem, I would hate to see a domain resort to using a key per user as the only alternative. This will change the dynamics of DNS to a much greater extent, and yet not be as responsive to the problem without very short TTLs for keys. At that point, DNS key traffic may become a significant portion of the Internet traffic. The amount of this traffic grows if DNSSEC is ever employed. If they don't get DNSSEC working, then there should be some consideration given about using something other than DNS for the keys. With that in mind, the number of keys, a few per domain to millions per domain becomes, an even greater concern. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
