On 5/5/11 1:07 AM, Murray S. Kucherawy wrote: >> I think in the early days of DKIM most people assumed DKIM would become a >> protocol where: >> * the body hash and header hash, using various header fields, certifies the >> DKIM signature and >> * the DKIM signature certifies the body and header fields, that had been >> used to create the DKIM signature. >> >> The current RFC4871bis defines a protocol where: >> * the body hash and header hash, using various header fields, certifies the >> DKIM signature and >> * the DKIM signature doesn't say anything about the body and header fields, >> that had been used to create the >> DKIM signature. >> >> Well, if there is /real/ WG consensus that 4871bis is right in this respect, >> then so be it. But is there real >> consensus? Or is it just because of what Mike describes as "The set of >> people paying attention now are >> extremely few". Why don't we see any recent contributions from the authors >> of RFC4871? (except for Mike >> then). > Any WG only has the people contributing currently upon which to build > consensus. We can't possibly hope to achieve something by requiring votes > from past contributors if they've moved on or lost interest. > > Keep in mind, too, that the document still has to go to the entire IETF and > then the IESG for review and evaluation before it gets published. It will > get plenty of additional eyes on it to make sure we've done right. > >> It seems to me there are a number of WG participants (and I'm one of them), >> who regret the fact that >> RFC4871bis does not make the few additional steps required to achieve the >> expectations of the early days: a >> protocol that not only provides a DKIM signature (and an important d= >> payload) but also a protocol that >> certifies body and (some) header fields. >> >> I fail to see why we don't take those one or two extra steps, to make DKIM a >> protocol with much more use >> potential. > Suppose we do add a mechanism that allows a signer to make some assertion of > the validity of the content of some header field or the body of the message. > Won't spammers just make those assertions in an attempt to make you believe > something that's untrue? I know I for one would be scared by a message that > says "This really is a message from eBay. Trust me!" unless I have some > additional way to verify or trust the claim itself.
Excuse me for my poor English, I shouldn't have used the word 'certify' here. I'm not talking about validity of content. Were I used the word 'certify' I mean: if a DKIM signature verifies successfully, the consumer can be sure that the body of the message (or the part thereof indicated by l=) and the h= headers, used to construct this signature, has not been changed between signer and verifier, and there is a one-to-one relation between the h= headers and the corresponding headerlines in the header of the message, that leaves no room for ambiguity. And in my view neither the consumer nor the assessor should have to re-do the work of the verifier, to get the assurance, described in the previous line. > Signer assertions can't be trusted unless you know for sure you can trust the > signer. But DKIM has no way to tell you that. So this is not something DKIM > can specify. Agreed. /rolf _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
