Doug, I'm clearly not understanding something. I hope I'm not
misrepresenting you here; if so it is out of misunderstanding, not
maliciousness.
You have said that you are opposed to per-user keys because of the
potential damage to DNS (or at least that's my understanding). I
think this is a legitimate concern even if it doesn't actually damage
DNS, since the large number of queries for different values will
trash caches on DNS servers.
But you are also pushing revocation ids. For those to be useful they
have to be fine granularity (if they have the resolution of a
selector then they don't have much point), perhaps even finer than
per-user keys (since they could be per-message). They also need to
have short TTLs, for obvious reasons.
It seems like the obvious place to store revocation information is in
DNS (so that you don't start having to add additional ports, which is
a problem from a firewall perspective). If you don't store the
revocation ids in DNS then you have substantially raised the bar for
using DKIM. But if you do store them in DNS, aren't you actually
trashing DNS in exactly the same way as with per-user keys?
eric
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim