ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Third-party "authorization"

2009-10-05 11:00:08

I am not necessarily advocating that this be added to DKIM base. My ox
isn't being gored on this issue but I recognize that it may not be as
resolved as Dave states. It may not always be as simple as Dave
indicates for senders and signers to "coordinate" in the manner he
suggests. 

To the extent that it is currently more difficult than less for ISPs and
ESPs dealing with a lot of domains that belong to their customers, I
still believe it is worth considering this revisiting this issue.

This is not quite the same as an ACL in the commonly used sense. I view
it more as a simple statement..... this domain signs for my mail as if I
signed it myself.

Mike

-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Monday, October 05, 2009 10:45 AM
To: MH Michael Hammer (5304)
Cc: IETF DKIM WG
Subject: Third-party "authorization"


MH Michael Hammer (5304) wrote:
In light of the comments by Bill Oxley and my belief that the
ability of
a domain to designate signing by a specified 3rd party is useful,
I'd
like to see this included in the update.


Such an addition is the equivalent of adding an access control list
(ACL)
to
DKIM. This was debated extensively before and the working group noted
that
an
adequate control mechanism already exists in DKIM:  selectors.

At its core, this change seeks to have recipients enforce
authorization to
use
DKIM by an agent that is within the a "sender's" sphere of control.
Even
though
the agent is an independent actor, they have an arrangement with the
sender and
are therefore within their sphere of control.  ACLs are a significant
bit
of
mechanism.

Rather than invent an entirely new mechanism that adds to the
complexity
of the
recipient's DKIM handling, the same level of useful information is
imparted by
having the sender and signer coordinate so that the signer uses a
selector
for a
domain (or sub-domain) of the sender.

This moves the work to (only) the folks who have the clear need and
motivation,
and it requires no additional changes to DKIM.

However what this repetition of a resolved item does suggest is that
we
ought to
generate a document that gives specific details for specific
scenarios,
beyond
what is already in the Deployment document:

    <http://www.ietf.org/id/draft-ietf-dkim-deployment-08.txt>

Apparently, the detail in its sections 6.3 and 6.4 isn't sufficient.

d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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