I pretty much agree with Jon as to conclusions, the argument I use is
somewhat different.
I think the real distinction here is not between per-user and per-domain
keys, its between persistent keys that provide for non-repudiation and
ephemeral keys that allow for limited term verification.
The DKIM key retrieval mechanism is only designed to do ephemeral keys.
Extending it to do persistent keys or non repudiation is a very bad idea
and would require the DNS to become a PKI. Even if you have DNSSEC
deployed you will not change this.
Ephemeral per-user keys do not provide a significant advantage over
ephemeral domain keys. The only instances I can think of where there
would be an advantage would be cases where DKIM keys are being
provisioned through a full featured PKI and the DKIM key records are
essentially an alternative publication mechanism provided for the
benefit of edge verifiers that don't understand XKMS or PKIX or
whatever.
Moreover before you can have meaningful per-user records you need to
think of key registration mechanisms etc. you have to support the entire
key life cycle. This is much more complex than the type of management
that DNS is designed to support.
As I argue in a separate email it is not necessary to have per-user key
records to have the ability to perform per-user revocation. In fact all
you need to do is to issue per-user records for the users you want to
revoke.
This is all completely separate from the hand-off mechanism to allow
benefits(_at_)microsoft(_dot_)com to be delegated without delegating
rms(_at_)microsoft(_dot_)com(_dot_)
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim