From: John Stanley (stanley@peak.org)
Date: Mon Feb 04 2002 - 13:56:43 CST
Clive D.W. Feather (clive@demon.net):
>> When I am the entity that is
>> posting an article, I certainly am a human being. When you post, do you
>> lose your membership in the human race?
>I thought it was you who said that:
>> and the flawed logic that "A means B is the same as B means A".
>Obviously I was wrong and you don't understand logic.
I'd like to understand what you are babbling about here, but I cannot. Are
you saying that you are NOT a human being when you post, or that "entity"
cannot mean "human being" or what?
I said that entity includes human beings, not that it was the exclusive
meaning. You're the one trying to make the B means A argument here.
>> Or are there "persons" who are not "human beings"?
>Yes.
Hmmm. From MY dictionary,
per-son n.
1. a human being, esp. as distinguished from a
thing or lower animal; individual man, woman,
or child: now usually pluralized as people,
which formerly was used only to indicate an
indefinite number of persons
>However, I *do* disagree that "entity",
>in the context of this document, means "a specific human being no matter
>how they designate themself".
"Entity" in the context of "the person who is posting" most certainly does
mean "that human, no matter which of his many possible mailboxes he uses
in the From header." We are talking about a person posting, for the most
part, and yes, indeedy doo, they are the same no matter which mailbox they
use. To try to claim otherwise is patently absurd.
You say that "entity" includes "Something that exists as a particular and
discrete unit". Does the "particular and discrete" human unit change based
on his mailbox in the From header? Do you realize how silly it will sound
when you say "yes"?
>"responsible for" is not the same as "using".
"Responsible for the operation of" is. When you borrow my terminal, it is
you who is responsible for pressing "F" to followup. The operation took
place not at my request, but at yours.
>> That would be sufficient to warrant a prohibition; as it is, it is icing
>> on the cake.
>No.
So it's ok by you if an injector does something that breaks an electronic
signature? Of what value is that signature?
>Firstly, I'm not condoning the *modification* of headers.
Yes, you most certainly are. You are condoning the change of meaning in
the From header when a Sender is present, and the change of meaning of
Sender to be "I cannot verify the From address" instead of its
standard-specified meaning. You are also allowing the injector to change
the Sender based on "verification" of the From.
And, as the draft says:
Be warned also that some injecting agents that have
authentication information may choose to replace the From-
content based upon the authenticated identity.
How you can say this is not modification of headers is beyond any
comprehension.
>Secondly, if the signature says that it includes a list of headers which
>don't include the (at that point nonexistent) Sender,
That's not the problem with signing a Sender-containing argicle, and you
know it. If the POSTER puts in the Sender header, because he knows what
data should be there, and signs the message, then an injector replacing
the Sender header is breaking the signature by inserting a guess.
If a FORGER inserts a Sender header and signs the article with a bogus
key, and the injector replaces the Sender with authenticated data, then
the signature is broken.
One case is the real signature failing, the other the forgers. How do you
tell them apart?
>That is *not* the same
>as "failed to verify", since the added-later Sender won't be included in
>the checking process.
When the Sender is replaced at the whim of the injector, yes, indeedy doo,
the signature will fail to verify, and not just report that the Sender
wasn't included in the signature.
>> All the forger has to do is say the Sender was included in the signature
>> and he can claim that the failure to verify is due to the injector; there
>> is nothing the real McCoy can do to get his article to verify.
>Rubbish. There is a difference between "validation failed" and "validation
>succeeded but some headers not part of the check".
Had you read the example I used, you would have noticed that the Sender
was part of the signature, and for it to be part of the signature it had
to be present when it was signed. When the injector changes the Sender
header when it cannot verify the From content (the incorrect behaviour
that needs to be prohibited), then the signature verification will not
suddenly magically change to "Sender not signed", it will still think the
Sender was signed and the result will absolutely be "validation failed".
And all the forger has to do is claim that the injector did what you
allowed it to do and changed the Sender, and that's why why validation
failed, which would be indistinguishable from providing a bogus signature.
Of what good is a signature system that the transport breaks?