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