>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
