Signing entire messages...

Brad Knowles (brad@his.com)
Fri, 23 Feb 1996 03:55:54 -0500 

Folks,

    Something that came up at the informal dinner after the
workshop was the issue of signing messages and parts thereof,
specifically the originating headers.


    I don't know the MIME spec that well, but what I personally
would like to see in any Secure Internet Mail standard is the
ability to sign entire messages with all originating headers
included (this is an important distinction), and then send that
out in proper MIME format.

    One idea was to do up the MIME message and have it be 100%
ready to go (already converted to base64 or quoted-printable, as
necessary), and then feed that to the appropriate program (which
would obviously leave the data itself alone, although it would
generate a signature), and then take the data that had just been
signed and include that in another MIME envelope as a
message/rfc822 format bodypart, and then the signature attached
in the appropriate manner.  The headers from the signed bodypart
would obviously need to be hoisted to the new MIME envelope.

    in this way, everything remains readable (if not verifiable)
by all RFC 822-only and MIME-aware MUAs, and it is then up to
the secure mail-aware MUAs to decode this structure properly, do
all the checking between the signed headers and the hoisted
unsigned ones, etc....


    Obviously, you also want to be able to sign one or more
bodyparts individually, and have that properly MIME enveloped.


    This might mean some additional complications for IMAP
relative to RFC 1874, however.



    This also is a framework that could be used (should be
used?) for encrypted mail, but you'd want to make very certain
that the user has the option of whether or not to hoist any
particular header to the unencrypted envelope.  I can't think of
any other factors that might need to be addressed specific to
this proposal relative to how encrypted is necessarily different
from signed.



    What do I think I've achieved?

    For one, I'd like to think that this framework (if not
already subsumed by the existing or developing standards) gives
both the sender and the recipient a better feeling that all the
parts of their mail are being treated according to their
desires, including both the bodies of the messages and their
headers (at least, as originated).

    For two, I think that if we engineer this right, it just
becomes another use of MIME recursion on the body parts, and
therefore is already something that MIME parsers are expected to
understand, and therefore doesn't necessarily entail additional
coding (or at least, not much additional coding, but certainly
perhaps more careful or slightly different coding than might
have been planned).



    I'd like to know what you think.  Is this idea totally
whacko?  Is this so totally obvious from the definition of MIME
that I missed it in all the RFCs and drafts that I've read?

    Can you think of alternative ways to achieve the same goal
(signing and/or encrypting the originating headers, as well as
the body and attachments and making sure that all parts can get
the same treatment)?

    Perhaps there's a better way than message/rfc822 (is there a
message/mime type?  Perhaps message/report a la 1894 (?) is more
appropriate)?

--
Brad Knowles,                                       MIME: brad@his.com
    comp.mail.sendmail FAQ Maintainer      <http://www.his.com/~brad/>

The comp.mail.sendmail FAQ is at
<http://www.his.com/~brad/sendmail/>