From: Brad Templeton (brad@templetons.com)
Date: Sun Jan 06 2002 - 13:51:43 CST
On Sat, Jan 05, 2002 at 08:19:34PM +0000, Charles Lindsey wrote:
> In <Pine.LNX.4.10.10201041445380.17458-100000@spock.peak.org> John Stanley <stanley@peak.org> writes:
>
>
> >Seth Breidbart (sethb@panix.com):
>
> >>> A - Sender is going to be signed just like From,
>
> >>That would break the signature, so the poster shouldn't do it.
>
> It would be unwise (though not prohibited) to include Sender in a signature.
>
> My draft signature proposal carefully excludes Sender from the default set
> that is normally signed, and also explicitly points out that signing it is
> not a good idea.
Well, as the header was designed originally for mail, that's not true.
In mail, it was intended to be a way for the real sender of a message to
indicate he/she/it was sending it on behalf of somebody else. The
classic example was a secretary sending mail for the boss.
In this classic example, the sender would sign the messages (including
of course the sender header) and not the From line author, though in this
case the Sender's certificate would authorize them to use the address
in the From line.
In the case where the sender is a different entity, more correctly a
forwarder such as a mailing list, then both would sign it. If the
forwarder insists on putting in their own Sender header, then of course
the submitted message can't have one that is signed. That's the duty of
the party that is sending a signed message to that forwarder to worry
about.
In a signature system, rewriting of what has been signed is not just
forbidden, it's impossible, without eliminating the signature. So if
you really want people to go about rewriting things in signed articles,
you have to put the burden on the original signer to prepapre for that
and indicate in some fashion that some headers are not signed and thus
rewritable. Path is such a header, inherently, and since some folks
want an injector-info header, it is also one.
However, as it turns out, while many people are used to rewriting things
they are thinking the old way.
Current "injectors" such as they are add headers and rewrite for the prime
reason that they are a more known or "trusted" party, and that they bear
some responsibility for the article and thus must add their stamp to
it. A secondary reason is that they have newer software than the user
and wish to upgrade the user's actions to newer rules.
With signatures, it is possible to rethink that. The trust and
and responsibility can be handled by the certification process, not the
"cabal" appraoch of injectors.
This is really an example of the classic debate between end to end
design with a dumb network in the middle, and the "smart network" design.
End to end people believe you put the smarts at the endpoints, and have
the middle do nothing but routing. This leads to much more flexibility
and innovation and better results in the end, but it's harder. Having
the smarts in the middle means fewer points have to be smart, and as noted
they can accomodate for older, dumber endpoints.
Though often it is a political battle. Smart network advocates often
do so because it gives the network owner _control_ while dumb networks
give the users control.
This is a grand debate, and you will find many essays on the net about it.
There are valid points for both sides.