On 8/15/2010 6:25 PM, Daniel Black wrote:
"email identity" is an ambiguous term.
All sorts of value-added enhancements might be possible, on top of DKIM,
but "protecting email identity" isn't really what DKIM is defined to do.
rfc4781 Abstract - last sentence. Still abstract however this was a general
lead-in discussion.
That's why the bis draft uses different language. It's also why wg docs
written
aftr 4871 have been searching for better language.
* end users rely, or should rely, on their MUA to present verified
identity information in an easily digestable way.
Human usability issues with respect to security is, at best, extremely
poorly understood. The state of the design art appears to have no idea
what is effective.
There are a number of significant papers on the topic available.
I've no idea what you mean by this. If you mean that there's been research on
security and usability, yeah that's true. So what?
My point is that the track record for developing mass-market user interfaces
that produce good security-related interactions with end-uses is essentially
non
existent. My other point is that the level of the research on this topic, to
date, is extremely limited and poor.
Either way
DKIM provides a domain responsibility signature and providing some information
to the end user is useful.
The assertion that it is useful is different from saying that the information
is
objectively meaningful. To say it is useful, there must be some basis for
knowing that users will actually be able to employ the information to a
productive end.
The reality is that the minimal research that has been done so far suggests
that
such information more often confuses uses. Their cognitive model of the system
and especially of security issues is far, far more limited that folks tend to
realize. In addition, the presentation of the information is usually
problematic.
As noted, you are seeking to have DKIM perform functions it was not
designed to perform. There should be no surprise that it falls shy of
your desired mark.
While it seems to be the intent of many within this working group to define
dkim in such a way that its only plausable use is dkim reputation, a little
constructive thought to other benefits for verifiers, filters and recipients
would be appreciated.
There is a difference between defining new semantics, versus applying existing
semantics in new ways. You appear to be doing the former. That, therefore,
goes beyond the DKIM Signing specification.
Recipients are an important aspect of the message flow and an attempting to
define a benefit to them from DKIM is an element of what I'm attempting to
define.
That's clear. It's also beyond the skillset of this group. It's also not
required for DKIM to be useful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html