I think it is fair to say that this is not a DKIM issue, in the sense
that some DKIM users (senders and recipients) may agree on some
standard solution, without requiring change to DKIM - so, the text
simply needs to be modified so that we don't _exclude_ such usage of
DKIM. BTW, I believe this issue is Ok with Meta-Signatures.
If we're going to start adding problems we don't want to exclude
solving, I have a rather long list here, starting with proving that
P=NP and ending with feeding the world's hungry. (I don't have great
hope of DKIM doing either, but you never know.) Making such lists is
not a productive use of anyone's time.
Can we back up a little and remind ourselves of what we're doing here?
We're trying to create an IETF standard version of DKIM. The point of
the threat analysis is to be able to look at a proposed spec and see
whether it addresses the problems it's supposed to address. It's
irrelevant if it might be able to solve other problems as well. If
you're concerned that a standard should permit future upward and
downward compatible extensions, fine, I suppose we can put that in,
but don't start telling us what you think the extensions might be.
I specifically don't want to say anything about signing messages
intended for a specific recipient, because that is a problem that
existing IETF message signing standards like S/MIME already address
pretty well. If it's there, someone in review will ask why are we
revisiting it. It just adds something else for people to nitpick.
R's,
John
_______________________________________________
ietf-dkim mailing list
http://dkim.org