ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Weird i= in client mail

2013-06-19 14:19:53
I want to add in a bit here as well.

In doing the crypto/security parts of DKIM, we had two goals in tension with 
each other. One was to provide accountability for a message for all the obvious 
good reasons.

But in the other direction, we didn't want DKIM to accidentally turn email into 
an always-on-the-record tracking system with severe negative privacy 
consequences.

We wanted to maximize the effectiveness of authentication while minimizing the 
tracking and privacy-loss aspects of authentication.

(Side notes -- by "we," I mean me, but I know that I wasn't alone. Also, we 
know full well that unencrypted email has horrible privacy characteristics all 
on its own.)

That's why, for example, there's an emphasis on DKIM being about the 
intentionally vague term "administrative domain."

Now on the other hand, if an administrative domain wanted to go to the trouble 
to authenticate down to the user level, we didn't want to prevent that, either. 
The primary audience for DKIM includes regulated industries, after all.

I also add that some of the working group *wanted* to push i= into mandatory 
user-level accountability, as well. Some wanted user-level as a MUST, and the 
result was it being a MAY.

That means that we tried to:

* Maximize the domain-level accountability.
* Minimize the user-level metadata and privacy damage
* Permit user-level accountability for domains that want to add it on.

And this is a good deal of why i= is the weird beast that it is.

        Jon


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html