On Wed, 16 Aug 2006 17:41:35 -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Jim Fenton wrote:
Douglas Otis wrote:
This seems like a minor change for the better. What weakness can't be
fixed by the proper procedures followed by a signing domain?
The one I described: the inability for a verifier to distinguish an
author signature generated by the delegate from a third-party signature
generated by the delegate operating in a different context.
What would be useful is for people who are neutral about this issue to
look at the attack vector Jim describes. It sure seems real to me, but some
independent verification would be helpful as well. In particular what would
be nice is to place requirement constraints on the protocol such that this
attack must be able to be mitigated by the delegated third party. If that's
possible at all.
It seems to me that bringing a mailing list into the scenario changes the
scenario slightly, but not in a significant way. I would envision two
basic modes of operation for a signer:
1. Uncontrolled - Sign mail submitted by authorized users of the MTA
without extra regard for identities used in the message (I say extra regard
since many mailing lists only accept mail sent by subscribers).
2. Controlled - Sign mail submitted by authorized users whose authority to
use the requisite identity (2822.From) has been verified.
Shifting from uncontrolled operation to controlled operation is, in my
opinion, a pre-requisite for being a safe delegated first party signer. I
can see that doing this for a mailing list could be problematic. I expect
that this is the next step in the evolution of MSA operational constraints
- a next logical step analagous to closing open relays.
In summary, I think the concern is valid, but not one the protocol can
solve. I view it as an operational issue for MSA operators.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html