Folks,
Wietse Venema wrote:
With a shared signing key+domain, if one of those thousands of
domains mis-behaves, all the other domains could suffer from the
bad reputation of that shared signing key+domain.
Thus it's better to avoid shared signing key+domain scenarios.
Based on some conversations today, I think we need to do a better job of
distinguishing keys from reputations (identities).
It is even more important that we carefully distinguish between internal
operational policies, versus the information that a signer must make public.
Good protocol design makes it imperative that we separate these and that we make
the portion visible to -- or, rather, imposed upon -- other protocol
participants be absolutely as small as possible.
(I am using the term "reputation" as a placehold for the wide range of analyses
that can be performed, once one believes that a claimed identity is valid.)
Keys
----
The allocation of private keys provides a means of controlling who can create
signatures, under a particular domain name. The selector is used to support
multiple simultaneous keys, under that single domain name. Selectors can be
used for something as simple as introducing a new key to replace an old one, or
as complex as support of an army of mobile users who do not submit mail through
the organization's servers.
The critical point about such a set of keys/selectors is that they all map to a
single domain name and that that single domain name is the basis for reputation
analysis.
Reputation
----------
The d= parameter in a DKIM signature field defines the domain name that is to be
used for reputation assessment. The signer chooses what domain to use. It does
not matter how many different keys exist for that domain or how many different
instances of the signing function there are -- that is, it does not matter if
lots of different folk are signing under that same, single name. If they all
produce the same domain name, their messages share the reputation of that single
domain name.
An email signing administration can choose a variety of schemes for supporting
name assignment to the d= parameter. It can have something as simple as one
name for all mail, with only one instance of the signing function. It can have
something as complex as a different d= parameter for every author of content.
That is entirely up to the folks administering the signature service.
The question is what does the signer need to communicate to a validation site,
for the validation site to be able to make a useful assessment?
The answer is: a validly signed domain name.
That's all.
If the signer wants to have assessment be based on different reputations, such
as for messages authored by different customers of the signer or messages
authored by different departments in the signer's organization, then the signer
needs to use different d= values.
Scope
-----
I claim that this is all that is needed, for DKIM signed mail, in terms of
determining what identity to use for assessment of the message and to determine
whether the use of that identity is "authorized".
For a signed message, anything beyond this is really trying to dive into the
complex arena of reputation subtleties. While these are, of course, important,
they are vastly more complex than ensuring valid signatures.
In other words, the job of DKIM is to deliver a valid identity to an assessment
mechanism.
The signer determines what identity is to be delivered and DKIM makes sure that
the assessment mechanism whether the assertion of that identity is valid. DKIM
needs to support fine-grained naming, so that signers have a wide-range of
choices for they way their different signing identities can be evaluated.
However DKIM does not have a role in deciding what those choices can or will be.
How the assessment service decides to use different names is a matter that falls
under reputation and accreditation. My reading of the charter says that that is
out of scope.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html