Re: IMAP vs. multipart/signed
Mark Crispin (MRC@Panda.COM)
Sat, 24 Feb 1996 12:54:51 -0800 (PST)
On Sat, 24 Feb 1996 11:16:15 -0800 (PST), Terry Gray wrote:
> Read 1847. It is very clear on the point that an object must be or become
> 7bit *before* it is signed, and that nobody en route can modify the
> protected object after that (e.g. no CTE transforms), lest the signature
> fail to verify.
Thanks. Obviously, I consider this method to be a backwards (and not terribly
robust) way of doing it.
> I suspect that if someone proposed a robust way to sign 8bit objects that
> could tolerate CTE transforms, there would be loud cheers from Northern
> Europe...
I think that I suggested one! It is to abandon the idea of signing an
immutable char* of RFC822/MIME text, and instead sign the *original* form of
the data (not the 7bit transformed form), along with attributes considered to
be important enough to be signed.
The problem with considering text headers, as opposed to the data contained
within, as something that needs to be signed is that it interferes with
anything else which might change those headers.
Consider a message to be an object that contains various forms of data (text,
programs, audio, image, video, smell,...) and data attributes within a
particular framework. What needs to be signed is the object itself, and not
the char* text of a particular framework that represents that object (e.g.
RFC822/MIME). It really does not matter that some intermediate agent changes
the RFC822/MIME text framework, as long as the object itself is undamaged.
Put another way -- What would you do if it was guaranteed that CTE transforms,
RFC822 transforms, and MIME header, *would* happen with every message
transformed on the Internet? That it was absolutely hopeless to sign the text
of RFC822/MIME, since it was guaranteed to change in transit? But you wanted
to sign the attributes contained in the RFC822/MIME framework (not to mention
the actual message data!) anyway? How would you do it?
I'm just musing out loud about the right thing; I really don't want to
introduce Yet Another Mail Security Format. It just seems to me that the
security guys consider MIME as something to work *around* instead of work
*with*, and thus aren't being very creative in their thinking.