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