I think that it all comes down to what the compliance requirements are.
It seems entirely reasonable to me that an email product that is
advertised as DKIM compliant MUST support the dns retrieval mechanism.
That does not suggest to me that an individual signature cannot be DKIM
compliant unless the key can be retrieved using the dns mechanism. It is
like saying that everyone MUST support RSA signatures, you can still
extend to new signature mechanisms but you cannot depend on
interoperability.
I think that it is likely that there will be some significant issues
supporting end user keying via the DNS, not least the fact that some
form of key provisioning protocol will be required.
If you go to per-user keying you open up a new set of requirements, this
is one reason why I argued for allowing multiple signatures per message.
I think that the way per-user keying is likely to be introduced is as a
supplement to domain keying and that this will strongly encourage the
use of different key retrieval mechanisms.
I very strongly suggest that people do not redo the work already done in
the W3C XKMS group or PKIX. We already have some very good private key
management protocols that have been exhaustively managed.
We should define what specifying the key retrieval mechanism as XKMS
means. Either in the core text or in a supplementary draft. Linking to
PKIX would be more problematic due to the status of their draft. XKMS is
a full standard, the PKIX repository proposal is not at the same level -
though Russ is likely to consider this a temporary issue.
What also worries me is that there seems to be taken an
approach that any methods must be such that public key is
retrieved from somewhere. I do not believe that there has
been an agreement on this issue as part of MASS list
discussions or that technical arguments say that this is
better then verifying public key included in the message. If
anything it seems in
some cases one is better while in others the other and this
means both options should be on the table.