[ietf-dkim] Purpose and sequencefor
DKIM specificationand deployment
pbaker at verisign.com
Tue Aug 30 08:38:38 PDT 2005
> Jon Callas brought up an interesting observation about this
> which if I understand it correctly, "authorization" depends
> on the perspective of the party.
Yes, I have seen that argument in the SPF group. I think it is wrong.
The problem with this point of view is that when we use authorization as
a term of art we are using it with respect to a party that has either
been authenticated or will be authenticated before the access control
decision is made.
That is not what we are doing here. The result of our process is not
'Fred is not allowed to send', the result is 'That was not Fred'.
The semantics only look like authorization if you follow the legitimate
sender path. If you follow the impersonation path the semantics are very
clearly authentication. There is almost always some degree of conflation
of authentication and authorization in a practical access control
scheme. The fact that you have a user account on a machine almost always
results in the grant of at least some default privileges.
The problem with introducing the sender perspective here is that it is
the person coding the recipient code that is most likely to screw up.
Describing the problem from the opposite point of view increases the
probability of a screw up.
> 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.
Whats wrong with using the term delegation here? Why do we have to
introduce muddy thinking and abuse an established term of art?
> 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.
The key record provides the way for the receiver to determine who the
sender ACCEPTS responsibility for, the policy record provides the way to
determine who the sender DENIES responsibility for.
> 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.
I know that we CAN look at the problem this way. What I am saying is
that WE SHOULD NOT.
What we should attempt to achieve in the specification is a method of
describing the protocol from a neutral point of view that is independent
of the perspective of any given prarty. We should develop and articulate
a description of the protocol that confuses as few people as possible.
That requires a global view and not a post modern relativistic approach
that requires the reader to engage in hermeneutic exegeis of the
More information about the ietf-dkim