Re: Extending DKIM through an identity tag

From: Dave CROCKER <dhc2_at_dcrocker.net>
Date: Sat, 17 Oct 2009 09:16:17 -0700

SM,

Some clarification questions, hoping to fill out the motivations, behaviors and
benefits in your proposal:


SM wrote:
> It is not possible for a receiver to tell to what
> that DKIM signature is tied to. If we can specify a "link" to one of
> "identities" in the message headers, e.g. the List-ID: or Sender:, it
> can help receivers validate mailing list traffic and other third-party
> signatures.

What exactly does it mean to be "tied to"? What is the exact assertion that one
can make when this tied to relationship is present?

What are the specific semantics?

What does it mean to be NOT tied to?

What benefit comes from being able to "prove" that the identities have this tied
to relationship? "help receivers validate... signatures" probably implies the
answer to my question, but I woudl appreciate your elaborating on this more.

What dangers come from not being able to prove it? I


> Once the DKIM verification is done or as a last stage in a DKIM
> verification, we see whether the domain name part in the List-ID matches
> the DKIM User/Agent Identifier. That identifier should also match or be
> a subdomain of the Signing Domain Identifier to prevent abuse.

Why AUID rather than SDID?


> With the above, receivers would be able to whitelist or score mailing
> list traffic.

How will this enable whitelisting or scoring that cannot current be performed?
Currently an SDID develops a performance history, good or bad, no matter what it
is "tied to". How does this added feature change that?


  The above extension could also be used to identify
> forwarders, resent messages, etc.

The presence of List-* or Resent- fields declares that a message has gone
through particular re-submission. So your proposal is not needed for the
purpose you just stated. I suspect you mean something deeper that cannot
already be discerned from their presence?


  I am not suggesting having a
> constraint on the "hi=" tag as the aim is to be able to express the
> identity through the semantics of the header fields chosen by the
> signer. Note that final decision rests with the receivers and as such,
> this should be viewed more as a way for signers to signal what they are
> doing instead of forcing a policy onto the receivers.

This opens the essential question of whether there is a basis for believing that
receivers will adopt this? Stated more pedantically, what is the receive-side
value proposition and which receivers find it compelling and why?

d/
-- 
   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Received on Sat Oct 17 2009 - 16:16:58 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:29 PST