On Wednesday 23 August 2006 14:34, Jim Fenton wrote:
Damon wrote:
But there is a residual problem. Suppose jdoe(_at_)mipassoc(_dot_)org is a
subscriber to this list and someone spoofs a message from
jdoe(_at_)mipassoc(_dot_)org to the list.
ietf-dkim(_at_)mipassoc(_dot_)org accepts the
message and sends it to isp.com, their Authorized Signing Domain, and it
is signed and sent. Is the signature from jdoe (the author) or
ietf-dkim (the mailing list)? Without Authorized Signing Domains, you
could tell by looking at the local-part of i=. But now you can't. I
think this is an important distinction, even if it only applies in a
subset of use cases.
-Jim
Should mailing lists sign messages?
I believe they should.
I believe they should too.
If they did, wouldn't it be a 3rd party sig?
Yes.
Yes.
If we were able to say "No third party can sign for me" it would stop
the spoof.
But the signature from the mailing list adds value (it says the message
is really from the list), so many domains would not want to express that
policy. What's needed is a way to unambiguously interpret the role of
the signature (i.e., is it a signature representing the author or the
mailing list) and the SSP delegation proposal has made that ambiguous in
some cases.
Which is what the proposal to segreagate controlled MSA operations in a
separate subdomain achieves. Since the signing domain is not readily visible
to the user, there is no user interface issue to worry about.
I'm still missing why we are still arguing about this. The spec definitely
needs some language about controlled versus uncontrolled signing and the
unsuitability of uncontrolled signing for SSP delegation. I don't know what
more we need. I've already volunteered to write the language when we get to
that part of the process (last I checked we are still on requirements, but
it's been hard to tell recently).
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html