ietf-openpgp
[Top] [All Lists]

Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.

2001-04-16 16:50:51
Brad Templeton <brad(_at_)templetons(_dot_)com> writes:
On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote:

That seems to be a non-sequitur.  It's certainly possible to
automatically verify a multipart/signed message.  Some news readers and
many mail readers already do this.

If all the software does is include a string about the verification,
that is then manually checked, it's manual verification.  Humans ignore
warnings which happen frequently.  Thus if most (or even just a lot,
like a few percent) of otherwise valid messages have the warning, people
learn to ignore the warning.

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.

What are these "important announcements" though?  As I indicated, I mean
that all the messages in a "class" have to be signed, so that it becomes
worthy of note when a message in a class is not signed, and this can
cause a warning that will be paid attention to.

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.

I would rather solve the real problems the net faces with security,
which are unauthorized control messages (and the resulting lack of trust
in authorized control messages), most of all cancel, and large scale
spam.

Yes, I agree.  However, no one is asking you to solve any of these other
problems.  This thread started with the OpenPGP folks asking us to please
not arbitrarily mangle their existing standard.  That seems rather
reasonable to me.  We don't have to do any work at all beyond not
interfering with their (existing!) standard.

We will eventually need to put all that mime stuff in, and it will annoy
a lot of users (we've all seen this) but we should do it for something
really useful, not mostly ignored signature of bodies.

So it's your position that this standard should *not* adopt MIME?

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
done as part of a different working group than this one; at this point,
it's just Not Invented Here syndrome.  Either netnews should continue to
track the mail standards (which I would argue should be the *default*
since that's been the policy behind netnews from the beginning), or we
should explicitly say that we're not adopting MIME, but trying to grab
bits and pieces creates exactly the kinds of internal inconsistencies that
are being pointed out in this thread.

If we want multipart messages, well-labelled character sets, the ability
to transfer non-text messages without unlabelled structural content like
uuencode, and the ability to take advantage of all of the work that the
(quite a bit larger, quite a bit better-funded, and quite a bit better at
developing and deploying new technology) mail community is doing, then I
think we should simply say that the MIME standard also applies to netnews
messages and then pick up the pieces, if any, within the framework already
laid out for extending MIME.  The current draft leans more in that
direction than in the direction of not adopting MIME, but currently in
some places is still trying to balance on the top of non-existent fences.

And lest people worry too much about some portions of that, let me point
out that (a) Usenet is not the only thing that netnews is used for and the
standard should be usable for things other than Usenet, and (b) it's still
perfectly reasonable for individual hierarchies to have their own policies
about acceptable message body formats above and beyond what the standard
*allows* for.  If they want to try to figure out how to get message/signed
working without QP, that's their lookout; it's a heck of a lot easier to
change hierarchy policies than it is to change an RFC.

-- 
Russ Allbery (rra(_at_)stanford(_dot_)edu)             
<http://www.eyrie.org/~eagle/>