ietf-822
[Top] [All Lists]

Re: Signed headers in email (was Re: Draft for signed headers)

1999-03-29 04:13:35
In <199903262020(_dot_)PAA01627(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu> Keith 
Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:

To be very blunt:

(1) If I want to sign headers, I'll use multipart/signed of message/rfc822.

Fine. You can do that, but it is no solution for some news applications.

Then develop a solution that is tailored to those news applications,
but don't pretend that it is for use by end-users.  If you try to 
solve both problems at once you may end up making it too difficult.

The problem with this discussion is that it has been hijacked by those who
want to discuss all sorts of bells and whistles that go beyond what I was
proposing. I have no desire to supersede the use of S/MIME and PGP/MIME
for those applications for which is adequate (if that is what you are
meaning by "end-users"). I am only concerned with those applications where
the integrity of the _headers_ needs to be ensured, and admittedly it is
news that provides such applications presently. However, news articles
tend to wander in and out of mail systems for a variety of reasons, which
is why the system should preferably not break if it happens to pass
through a mail route.


Agreed. My proposal says nothing about envelopes.

strictly speaking, about half of the Usenet message header *is* an envelope.
(i.e. it's intended for use by the news transport system)
that's part of why the needs of Usenet are different than those of email.

Problem with mail is that envelope information sometimes duplicates (or
even contradicts) header information (e.g. in SMTP you can deliver a
message to A, even if all the To: fields, etc, say to deliver it to B). My
proposal is concerned only with the integrity of the headers that
accompany the message.

(4) Any attempt at a canonicalization algorithm for mail header signing is
   doomed to failure from the outset.  It will be ambiguous, too complex,
   or inadequate.

people who have done this before in the context of email, understand
why canonicalization is difficult.  the problems are similar enough that
people who haven't done this before should respect the experience of those
who have.  that doesn't inherently mean that new proposals cannot be 
examined, but neither can you demand that other people consider them.  
one of the things that experience teaches you is how to tell when you're 
getting near a rathole.

Yes, canonicalization is difficult, which is why I took a lot of trouble
over it. So please look at what I proposed, and tell me where I got it
wrong, rather than just saying "it is known to be impossible, so there is
no point in trying to do it".


(B) If signed headers in email are attempted, I suspect the IESG will kill
   the proposal so I don't have to expend energy fighting it.

If the usenet-format people submit any kind of signature proposal to IESG,
IESG is going to want (a) strong justification for why it should be approved
and (b) absent very good reasons why this is a lot better than s/mime or 
openpgp for general purpose uses, an applicability statement which says 
what signed headers are good for and what they're not good for.

It's not supposed to be better than s/mime or openpgp, or to be for
general purpose uses. If people want to use it that way, then that is
their problem. It is to fill a gap that s/mime or openpgp do not fill (in
fact, it actually uses openpgp internally, as currently proposed).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk  Web:   
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

<Prev in Thread] Current Thread [Next in Thread>