ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Purpose and sequencefor DKIM specificationand deployment

2005-08-30 08:28:05
Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton


I have been struggling with the use of "authenticate" and "authorize" ever since I started working on IIM. I had a different notion there -- that one authenticated the message (with the help of the included key) and then checked the authorization of the private key holder to send mail. But that taxonomy doesn't really help here.


The data stored in the DNS is syntactically identical to an
authorization record. The problem is provenance. Consider the following

Aardvark.com sends to Bobble.com
bobble.com accepts the email from Aardvark
Spamalot.com sends to Bobble.com
        bobble.com rejects the spam

The problem with calling the record 'authorization' is that this is
exclusively the right of the recipient. Bobble.com is not using the data
sent from spamalot.com as authorization data.

Jon Callas brought up an interesting observation about this
which if I understand it correctly, "authorization" depends
on the perspective of the party. I have been using "authorization"
as being from the perspective of the sender: my domain authorizes
(or perhaps more accurately delegates) certain entities to sign
on behalf of my domain. From the receiver's perspective, however,
it's not authorization in the sense that it authorizes me
to send mail to somebody else. What DKIM provides is a way for
the receiver to determine who the sender has delegated the
ability to sign on its behalf. From that perspective, it looks
a lot more like an authentication operation to the receiver --
it's not very concerned about the sender's delegation, per se,
only that the sender is authentically delegated by that domain
to sign, and to what scope it is allowed. That scope, on the
other hand, provides some amount of instruction to the receiver
as to how to bound the signer which muddies this a bit so it's
not an entirely clean distinction, IMO, but probably good enough.

                Mike

_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>