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 [EMAIL PROTECTED] to be delegated without delegating [EMAIL PROTECTED] _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
