ietf-822
[Top] [All Lists]

Re: 8BITMIME to 7BIT

1998-08-17 11:37:54
The idea to define a way of computing security and identity
hash sums which will be the same with certain common
conversions which might occur on a message is great if you
can make it work. In addition to 8BIT to 7BIT or the
reverse, are there other things which should be canonized?
How about trailing spaces in lines? How about inserting
line breaks into lines longer than 80 chars? How about
addition of certain headers, like "Resent-" and "Received:"?

I'm afraid  this is precisely why we didn't define such a hashing scheme
initially -- once you start down this path people come up with ratholes such as
these. 

The problem with trailing spaces on lines is that they may have significant
meaning attached to them. It is axiomatic in security systems that you cannot
exclude from a hash things that can have significant meaning.

Igoring/adding line breaks is, if anything, far worse. If you want to monkey
with this sort of stuff do it before the signature is added.

As for the addition of headers, this would only be meaningful/useful if people
inserted this sort of stuff into signed heades. In practice they do not -- such
fields are attached to the primary message header, which for many reasons
cannot be signed reliably.

The people who define security stuff, have they not already
defined some of this?

No, for the simple reason that doing so is a very bad idea.

Even rigidly structured formats like ASN.1 encodings have all sorts of
canonicalization problems in practice. And text formats are much, much
worse.

At least the addition of "Received:"
headers ought to be in the methods already. Or perhaps they
compute a checksum only on the content, not on the RFC 822
heading?

Received: fields, like Resent- fields are only added to primary message
headers, which existing email signature mechanisms do not cover.

                                Ned

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