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>