> 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. 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. Thus, I believe we had this debate at length and came to the conclusion that this creates more of a security problem than it solves. Any trust in the validity of the content of a field or the body can certainly be made, but DKIM itself can't do it. So we're back to protocol vs. implementation, and we can't do this in the base protocol, but maybe some higher layer or a later protocol extension could do it. I'd be happy to work on specifying or conducting some experiments if someone has an idea about it; in fact, OpenDKIM already has the hooks needed to do so. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
