[ietf-dkim] New version - draft-ietf-dkim-rfc4871-errata-01
johnl at iecc.com
Tue Feb 3 14:00:44 PST 2009
>> Further to my earlier message about clarifying the interoperability
>> problem, if the above statement is really the case, why not remove
>> i= entirely? We are already rather strongly warned about its use
>> in RFC 4871. So, what is its remaining value?
I wouldn't argue against that, since it seems likely that people will
misimplement i= no matter what we say, but the idea is that it's an
opaque identifier with two uses. One is as an audit key for the
signer; you get back complaints about mail you signed and you can use
it to help figure out what happened. The other is as a stream key for
the recipient; although the i= is opaque, it should be stable, and you
might want to treat all mail with the same i= in the same way.
> As an end user, I'd like to know if the signing system says it's
> signing the message on behalf of Aunt Tillie or Uncle George.
That's not a bad idea, but it's not DKIM, since DKIM makes no
assertions finer grained than "this domain signed this message".
Something tying the signature to an e-mail address would be a
reasonable extension for a future version. (I don't think ADSP does
this, since it, among other things, doesn't provide any way to say
that i= is an address without also requiring that it's the From: line
More information about the ietf-dkim