I think I've answered all your questions, though I've re-ordered and
combined many of them so that this message is less bitty.
1. Who is supposed to do the signing? That is, what is the
"nature" of the entity doing the signing?
An agent of the domain of the message's sender.
the word "sender" is unfortunately ambiguous.
There's a problem here that the domain might not be well defined,
how can a domain not be well defined? i really don't understand.
I was deliberately vague about the meaning of "sender" here because of the
number of people that may be involved in the sending of a message and the
way this can result in ambiguity over (or perhaps I should say, too many
ways to choose) which domain is responsible.
There are the authors of the message listed in the From: header and the
the actual sender in the Sender: header. In general there's no formal
(computer-checkable) relationship between them. What the computer can
check is that the sender is the user that was authenticated (or at least
authorized by IP address) to send the message.
So I think the signature should be tied to the message Sender: (or
Resent-Sender: but more about that later), and it shouldn't embody any
formal statement about the relationship between the signing entity and the
message authors. The signer signs on behalf of the sender (this is
checked) and the sender sends on behalf of the authors (this is not
I'd be interested in ideas for ways that we can automatically check the
author/sender association, especially in the case of multiple authors, and
in the case where the author and sender are different roles (with email
addresses in different domains) of the same person.
Without it we are relying on reputation systems to keep track of senders
who habitually lie about the authors they are sending for.
Why should more than one signature be allowed?
I think this is partly in order to accurately express the semantics of
email, and partly as a way of making it easier to deal with partial
It would be nice, when a message is re-sent by someone, to know that both
the original sender and the re-sender were acting legitimately (according
to their respective signers). This extends to the multiple re-sendings
allowed by 2822.
If you only allow one signature, do re-senders not sign? or do they use a
modified signature so that the verifier knows to check Resent-Sender:
rather than Sender:?
Mailing lists are slighly more uncomfortable with the model I'm thinking
of, because they override the Sender: header rather than adding to it.
Still, the original signature will have closer ties to the message's
authors (formal or otherwise) than the signature of the mailing list
system so it provides valuable extra reassurance.
In the partial deployment scenario, a verifier would like to know if the
signature on the message came from its first sender or most recent
re-sender or mailing list, so that it can check it appropriately.
(Depending on the details of the format the verification might need to
work differently in the various cases.) If the signature's semantics
include the concept of a message being sent more than once then a broken
signature will be less likely to occur with legitimate usage.
3. What is the intended purpose of the signature? What does
it prove and to whom? How is it supposed to be used?
Two parts to this:
(1) If the message has a signature that fails to validate, it
should be possible to reject the message with a very low
likelihood that legitimate messages will be rejected.
(2) If the message has a signature that validates, we can look up
the signer in reputation and/or accreditation databases to help us
decide the message's disposition.
these sound reasonable, but are not really what i meant to ask for.
They are stated pretty much as low-level mechanical choices. What i
am asking is the higher-level purpose of the signature.
Is the goal to "trust the From" or to "trust that the content is
within some bounds of acceptability"? They strike me as different
I think the goal is to identify someone close to the message's origin who
claims (by signing the message) that it is legitimate. I'm not making any
claims about acceptability or trustworthiness - that's a job for third
party reputation and/or accreditation services.
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING