On Sun, 30 Sep 2007 21:39:44 +0100, Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
Eric Allman wrote:
It sounds like you are arguing that "all" should be "strict" and
"strict" should be eliminated; as a corollary, no Third Party
Signatures should be accepted under any circumstances. That's a valid
argument, but it has nothing to do with whether the -ssp draft is
accurate.
No. Strict seems consistent with the requirements. For "all", the
problem I'm
having is tying the statement "I sign everything" to any other statement,
including "I think that 3rd party signatures are groovy". They are not
inherently
linked, and the SSP draft shouldn't do that. I can very easily say "I
sign everything"
and have no opinion whatsoever about other kinds of signatures.
The scenario you need to consider is where A asserts a policy of "I sign
everything", and sends a correctly signed message to some mailing list B.
B can (and should) check that the signature is good, and is consistent
with A's policy, etc. But then B add his standard mailing list boilerplate
"NOTE WELL ..." thus breaking A's signature. He then signs the message
again (as a 3rd party).
Now the ultimate recipients see A's signature (no longer good), plus A's
policy. So the message is on the face of it "suspicious". So what is the
recipient supposed to do? He is a member of the list, and is happy to
trust the list maintainer, and can check the 2nd signature. But he is
still receiving conflicting advice.
The only real solution to this problem is for B to add an
Authentication-Results header (see the Mail-Vet-Discuss mailing list), and
to incluide that header in is own signature. Maybe that is veering off
topic for this list, but at least there should be a pointer to that sort
of possibility.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html