On Mon, Apr 16, 2001 at 04:50:48PM -0700, Russ Allbery wrote:
Brad Templeton <brad(_at_)templetons(_dot_)com> writes:
It seems reasonably easy to warn if the identity associated with the
signature doesn't match the displayed identity derived from the From
header, but I haven't thought a great deal about the user interface
portion of this.
Indeed that's good. That's header verification, which is what I'm
pushing for, though you should verify more than just the From header.
There are a variety of ways to do this. The right "mime" way is ugly,
namely to embed another multipart in the 1st half of the mult/signed,
which in turn has the body and a representation of the header.
I have advocated (and the multipart/signed people I have talked to have
agreed, saying they should have done this in the first place) that the
multipart/signed form allow more than 2 parts, with semantics in the final
signature part controlling just how the signature is checked on parts
1...N-1. USENET could be the first to include this extension.
If there were a body issuing certificates for email addresses, that could
be used to verify just the from line or other email lines, but again,
why stop there.
Somehow, somewhere in the body, a hash of the valid header needs to be
provided. Putting it in the text is ugly, but is the only way the
existing multipart/signed spec would verify it.
The best option is probably to extend the spec.
There are some announce groups where all the content is signed.
comp.os.linux.announce, for example. There are some people who always
sign all of their posts.
A group where everything is signed can be secured, if the software is
then programmed to reject or give warnings on the rare unsigned messages.
(ideally relays should just not carry them in such a group, just as they
in theory reject unauthorized postings in moderated groups.)
However, support for "people who signs all their posts" is the hard issue.
You need to spec a lot of extra stuff to make this work, somehow building
databases of people who are in this state, and getting software to use those
databases.
You must have a certificate system, because you can't just put this flag on
a user once they sign their first post, as the first one might be forged,
thus locking the user out from posting under his own email.
But even then, as I have indicated, it's easy for me to post as
"rra(_at_)leland3(_dot_)stanford(_dot_)edu" even if you are the only one who
can post
as "rra(_at_)stanford(_dot_)edu". It would be tough for you to figure out
every
form of your name and reserve it.
So it's your position that this standard should *not* adopt MIME?
It should absolutely adopt MIME, and should make it a SHOULD, possibly
even a MUST. At the same time, non-conformant readers will exist for
quite some time, so we must for some years be aware of the older readers,
and decide how we will _use_ MIME, comparing the tradeoff for those users
with the benefit of it.
Securing headers is well worth the ugly display to users of old newsreaders.
Signing bodies is less convincing a sell.
To repeat myself (again), I feel very strongly that adopting MIME is a
binary switch. Either we adopt MIME or we don't. The time to try to
fiddle with MIME was when MIME was being developed, and should have been
MIME is meant to be extended, and major users of it are free to develop
extensions and try to get them adopted outside their space.
I fully agree we should throw that binary switch, but I also face reality.
I've seen newsgroups where people post with wasteful stuff, for no benefit
to most of the readers, and it gets a lot of antipathy.
Mime multipart/alternative was created so MIME systems could go through
evolutions, but it's a very bulky system, more suited to mail than news,
and so when it first started being used by Netscape, people were screamed
at to go away. It's a little more accepted now but it took a lot.
That was, in part, why I pushed the concept of out of band markup, which
is a better migration to rich text than multipart/alternative.
Note that at this time, the vast majority of USENET users have a reader
that handles not just MIME, but even HTML.
Still, some things are worth it and some are not. Non-english
character sets, hyperlinks, structure, and securing headers are all worth
it.
Signing bodies is something we've seen for a while, but I have yet to
see it actually be useful to anybody.