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