Jon Callas wrote:
The thing I find most disturbing is that I perceive an effort to turn
DKIM into a user-level signing system. This is not the intent of DKIM.
There are a number of places that this is happening. One of which is
the continued suggestion that i= means something, or worse *must* (I
don't know if the "musts" I have seen are MUSTs) track back to the
user. Stop that, please.
There is no requirement in DKIM, or SSP, that i= have a local-part,
unless a domain decides to delegate keys at the user level (with the g=
tag on the key). I have been talking about user-level signing a lot in
this thread in an effort to be complete.
I see the need for the local-part in i= primarily to disambiguate a use
case that Mike Thomas mentioned earlier today. If I send a message from
fenton(_at_)cisco(_dot_)com and it were to be signed by this mailing list, the
signing domain would be mipassoc.org. It's obvious then that it's not
an Originator Signature. But of my address were instead
fenton(_at_)mipassoc(_dot_)org and the list applied a signature with no
local-part
in i=, one couldn't tell whether the signature represented the message
passing from me to the mailing list (an Originator Signature), or from
the mailing list to the users. In that instance, the local-part on i=
tells what kind of signature this is, to provide equivalent
functionality when users and lists (or other re-signers) happen to be in
the same domain as when they don't. I believe this is better than
requiring that re-signers and users be relegated to different domains.
The i= tag is a note from the signer to the signer. It can be
anything the signer desires, and the verifier interprets it at his
own peril. It is a Humpty-Dumpty thing, it means whatever the signer
wants it to mean.
The SSP draft that's on the table matches the local-part of the From
address against the local-part of i= if it is provided, so it goes
against what you just said. RFC 4871 also requires the local-part to
match the g= tag on the key if it is present.
In general, signers *will* put something that is essentially tracking
information in i=. I accept that. In general, if
"i=foobar(_at_)example(_dot_)com" is in a DKIM signature, there are things a
clever receiver can deduce from that. Fair enough.
Nonetheless, to step past that and assert that there must be user-
level tracking in DKIM whatever the mechanism, or even that user-
level tracking should be part of best practices is stepping too far.
Spam fighting is not so important that we should erode privacy
further than it is already eroded. It is not so important that we
should infringe upon the sovereignty of a domain and impede its
ability to protect its users.
I consider myself to be a privacy advocate too, but feel that we need to
balance user-level signing assertions against ambiguities that exist in
their absence. I think DKIM and SSP strike a good balance.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html