william(at)elan.net wrote:
On Mon, 29 Aug 2005, Scott Kitterman wrote:
I know that authentic and authorize are specific terms of art and I'm
trying to understand where DKIM stands in relation to them.
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.
I have often thought that we need to invent or appropriate other words
to describe what we're doing here because "authenticate" is usually
applied to a human, not a message. Any ideas?
DKIM-SSP attempts to at least partially fill that gap. Is that right?
Despite what some people say, I don't see how DKIM-SSP along will
seriously change this. What policy record can do is to help find those
who are definitely NOT authorized (just like with SPF) with assumption
being that the rest are - which is not entirely true. What you still
need is to have record indicating that the server that did the signing
also authenticated the user and then you have some form of
authorization (otherwise you could have different user from the same
domain using somebody else's identity within same domain for example).
Publication by the signing domain that they did this or that generally
aren't useful -- they will publish whatever gets their messages through
most successfully. Besides, we're focusing on situations where misuse
of identity might be abused; a lot of domains (particularly small ones)
don't need to worry about that, so why make them do authenticated
submission?
That is really not all that is missing, because once you have the
identity
you still don't know who the user is authorized to be in the email system
(i.e. is the identity supposed to be associated with Sender, From header
field or something else) and its just something "up in the air" for
some other system to pick up and compare against the actual email
message in some undefined way.
Other than checking to see whether the signature identity is associated
with the originator address, I don't know how useful it is to know what
the role of the signer is -- I mean, does it really matter whether the
signer was a mailing list, or some address that appears in a
Resent-From: header? I don't think that would affect a recipient's
decision a bit; what would matter to me is whether, for example, the
message was signed for the identity ietf-dkim-bounces(_at_)mipassoc(_dot_)org, not
whether that also happened to match up with some message header. In
other words, who signs is more important than what role they say they're
playing.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org