At the risk of repeating some points that have already been made by others...
At 07:37 AM 10/28/2004 -0700, Dave Crocker wrote:
For the current discussion, we need adoption by sending sites and
receiving sites (and, here, the different between adoption by mtas vs.
muas is irrelevant). Mailing Lists are just one more example of
adoption.
I see mailing lists as being different because they're in series between the
(original) sender and an eventual recipient. So now there are three parties
that have to implement message signing and verification in order for message
signing to work for a particular message. That has got to be slower on the
average than when only two parties were required to deploy.
Treating mailing lists as a special concern introduces significant
additional complexity to the specification, makes end-to-end
performance significantly more problematic -- by defining the
end-points as crossing an intermediate UA -- and is just as likely to
frustrate user expectations as it is to aid them.
I don't think the architectural model of a mailing list (back-to-back UA, or
multi-pronged forwarder, to name two) matters a whole lot here. The question
is whether we should make some effort -- and not a large one -- to try to help
messages pass validation if they have been modified in transit, whether it's by
a mailing list, or by an MTA that adds a legal disclaimer or advertising
statement to a message.
Some/most of the signing proposals include options for canonicalizing the
signed content. Do you also disagree with this?
We should make some attempt to get
message signing to work with at least some mailing lists to make
it more effective before the lists upgrade.
We should also make some attempt to get message signing to work with
at least some personal Forwarding or Resending.
Or maybe we shouldn't.
Maybe survivial of the signature across re-postings is not a goal.
Or maybe it is. That's the question.
Maybe we should define a simple, clean service, that has a constrained
goal and constrained specification. That way it will be easier to
understand and implement and it will work predictably. This will make
adoption and use far easier.
Simple and clean are relative terms. I would argue that IIM, with body length
counts and header copying, is still simple, clean, and constrained.
I am trying to imagine designing any other Internet protocol that has
special features to hack around transient adoption concerns.
Any protocol that negotiates options for, say, an obsolete authentication
technique or encryption algorithm has a special hack around a transient
adoption concern. I'm sure there are others on the list that can supply
specific examples.
I agree, but this is a different issue entirely. In the absence
of mailing lists that re-sign, the original sender signature will
be the only one available.
The problem is that, in a very real sense, it will not be valid and it
should not be!
Are you saying that this mechanism, as you envision it, is broken when a
mailing list does not modify the message nor remove the signature? Because the
signature will be present and will verify successfully in some cases.
Let's step back and ask what the purpose of this signature is.
The purpose of the mailsig mechanism is:
Provide an assertion of message transit origination
accountability that can be validated.
Please remind me where this is from. I'm trying to parse the phrase "message
transit origination accountability". This isn't clean and simple!
The use of this accountability is during message reception,
to assess likely acceptability.
We are not trying to replicate pgp or s/mime. We are trying to serve
an entirely different purpose. We are trying to say who is
responsible for injecting this message into the message transfer
service.
The mailing list processor is responsible for injecting the message
into the transfer service. Therefore the only signature that is valid
for mail coming from it is the mailing list signature. The original
authors are not accountable for the potentially arbitrary behavior of
mailing list processors.
Let's not design a specification that pretends otherwise.
We aren't pretending otherwise. It is clear exactly what the original author
signed, and the recipient can decide whether to accept the "arbitrary behavior"
or not.
I consider a valid signature that is based on the 2822 From
address to be more valuable than another one applied later because
it signs the address that I will be looking at in my MUA;
There is no automatic requirement that the recipient user see anything
about the signature.
Really.
You can't require that the recipient user see anything. But most MUAs I have
seen display From and not Sender, and I want to encourage display of the
address that was signed. If there is a valid signature corresponding to the
From address, that requirement is satisfied (except maybe for Outlook).
-Jim