There are two basic scenarios, both with flaws:
1.) The MTA signs the message: This is problematic in the "traveling
salesperson" type scenario, because often then cannot use their
company mail server due to ISP filtering, etc.
2.) The MUA signs the message: This yields one of two subproblems:
2.a.) The MUA signs using a "per-user" key : You now have to
maintain in DNS several thousand keys for your large organizations
2.b.) The MUA signs using a "domain-wide" key : Every time you fire
an employee you have to change the key or risk its misuse
or:
3) The signing is done by the MUA, but the key and crypto are all done
by a separate entity, which I have called an MAA in the past. The MUA
authenticates to the MAA and sends a digest of the message, then gets a
signature back to attach to the message. The MAA may be physically
colocated on the MTA, but is logically separate, uses a different
protocol, and should avoid filtering by most ISPs.
This last scenario is what I suggested some time ago, and may yet be
used as a component of the consent framework.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg