Dave CROCKER wrote: > >> I have two >> submission domains that I use. One, gmail.com, which does DKIM >> signing, will only allow me to use a "From" address after it has sent >> a test message to that address and seen that I can access the test >> message. So it's made *some* level of confirmation that I owned the >> address at the time I set it up. > > Well, this is a reasonably common type of example. I think it confuses the > difference between a signer's policies, versus DKIM semantics. It is > certainly > true that different signers have wildly different meanings behind their > signing > behavior. However there is nothing in DKIM that communicates a signer's > policies. (Obviously, ADSP is an example of a value-added semantic, but as > we > all have been reminding ourselves, that's an additional function.) > > The critical point, here, is the question: What can the verifier know? They > cannot know about differential policies and in particular the choice of what > parts of the message are covered by the signature communicates no additional > semantics.
I think that is a different question but one that is based on a fundamental premise of having statements of validity for cryptographically protected parts of the message. Does all this suggest that one must begin with a presumption of false information? In other words before you can ask the question "How/what can the verifier know?" it has to begin with the validity claims made by the signature and its bound parts. So when you sign a message with signer-domain and it has a required bind for a author domain, these are two minimal statements of validity to be verified and perhaps confirmed by some "higher power." Perhaps Policy with its author-domain feed, and/or perhaps out of scope reputation engines with its signer-domain feed. I think it is the latter that you are pushing for. I would like to keep DKIM pure and open to not just be about the signer domain. I believe that as long we continue to minimize the statement of validity a valid DKIM signature provides for 5322.From, the more these "usual misunderstandings" will persist. There is a reason why it doesn't go away and might we are trying to promote an obscure and abstract concept of an independent signer domain that today it is still very hard to grasp, especially with the lack of application demonstration. On the other hand, the majority of the industry can grasp and feel the issues regarding a 5322.From and can better understand the idea that DKIM might be a technology to help protect it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
