From: "L. McCarthy" <lmccarth@thor.cs.umass.edu>
Date: Sun, 23 Jul 95 21:05:09 PDT
To: cypherpunks@toad.com (Cypherpunks Mailing List)
Subject: MOSS and Mixmaster: A Media Type Proposal
In-Reply-To: <9507090007.AA06052@snark.imsi.com>
Message-ID: <199507240403.AAA00248@thor.cs.umass.edu>
MIME-Version: 1.0
Content-Type: text/plain


Perry Metzger writes:
>>> It would be very, very good if everyone doing secure mail systems of
>>> one sort or another (including PGP integrated mail packages and
>>> remailers) slowly moved forward to the formats described in this
>>> document, which is now a proposed internet standard...

The IESG writes:
> The IESG has approved the following two Internet-Drafts as Proposed
> Standards:
> 
>  1. MIME Object Security Services <draft-ietf-pem-mime-08.txt>
>  2. Security Multiparts for MIME: Multipart/Signed and
>     Multipart/Encrypted
> 	<draft-ietf-pem-sigenc-03.txt>
> 
> These documents are the product of the Privacy-Enhanced Electronic Mail
> Working Group. The IESG contact person is Jeffrey Schiller.
> 
> 
> Technical Summary
> 
> These documents describe a general framework for security within MIME
> (draft-ietf-pem-sigenc-03.txt) and a specific proposal for offering
> Privacy Enhanced Mail services within MIME(draft-ietf-pem-mime-08.txt).
> Support is provided for digital signatures on MIME objects (both simple
> and compound) as well as for confidentiality provided through data
> encryption.

I've spent some time reading these proposed standards, along with parts of
RFCs 1423 and 1590, with an eye to applying them to remailers. I'd like to
get a sanity check and comments before I consider proceeding with submission
to the IETF Media Types review list, etc.

I propose a new Media Type subtype for Mixmaster remailer packets,
"application/mixmaster". (For the purposes of this message, "Mixmaster
remailer packet" refers to a packet generated by a Mixmaster server or client,
and intended for transmission to a Mixmaster server. It does *not* cover
messages generated by a Mixmaster server that are intended for an ultimate
message recipient.) This is intended to be an experimental protocol
for use in the control part of a multipart/encrypted message. 

There is one required parameter, "version", meant to indicate the version
number of the originating Mixmaster software.  In addition, one optional
parameter, "key-id", may be included. If present, this parameter would
indicate the single line key prefix/ID of the public Mix key used to
encrypt (at the outermost layer) the contents of the application/mixmaster
part. This might be used to thoroughly disambiguate decryption options in
the event that the recipient server has more than one currently active
public Mix keys.

The application/mixmaster (control) part of the multipart/encrypted message 
would contain the padded list of Mixmaster server hop headers, superencrypted 
at the outermost layer with a public Mix key (presumably, one belonging to the
recipient server). A single decryption of these headers should reveal the
IDEA key used to superencrypt, at the outermost layer, the body part of the
multipart/encrypted message. The application/octet-stream (body) part of the
multipart/encrypted message would contain the list of ultimate recipients of
the remailed message, the text of the message itself, and any additional 
processing instructions to the final Mix server. The latter, body part of
the multipart/encrypted message shall have been encrypted by the originator
using the IDEA key specified in the former, control part.

The contents of the application/mixmaster part should be encoded in
accordance with the standards for application/octet-stream.

(NB: this amounts to a division of the extant Mixmaster packet format 
roughly into a control section and a body ("payload") section.)

Comments ?

-Futplex <futplex@pseudonym.com>