To: pem-dev(a)TIS.COM, ietf-822(a)dimacs.rutgers.edu Subject: MIME-PEM Interaction
Reply-To: ietf-822(a)dimacs.rutgers.edu
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Mon, 16 Nov 1992 16:41:22 -0800
From: Marshall Rose <mrose(a)dbc.mtview.ca.us> Sender: pem-dev-relay(a)TIS.COM
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Friends, at the request of the participants at the SAAG meeting this afternoon, I am posting a draft regarding the interaction of MIME and PEM. I believe that this draft will be presented by Ned Freed at the PEM meeting on Wednesday (which, regrettably, I will be unable to attend due to a conflict.)
Although Steve, Ned and I think that the draft is fairly complete, there are likely some issues which remain to be resolved or at least given greater exposition. As such, your comments are most certainly welcome!
/mtr
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii" Content-Description: mime-pem.txt
draft MIME-PEM Interaction Nov 92
MIME-PEM Interaction
Mon Nov 16 15:51:54 1992
Steve Crocker
Trusted Information Systems
crocker(a)tis.com
Ned Freed
Innosoft International, Inc.
ned(a)innosoft.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose(a)dbc.mtview.ca.us
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress".
2. Abstract
This memo defines a framework for interaction between MIME and PEM services.
Expires May 16, 1993 [Page 1]
draft MIME-PEM Interaction Nov 92
3. Introduction
In the Internet community, an electronic mail message has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to Multipurpose Internet Mail Extensions (MIME) [2].
Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message.
This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion.
In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. Then, the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery.
Expires May 16, 1993 [Page 2]
draft MIME-PEM Interaction Nov 92
4. Definiton of new Content Types
4.1. Definition of the multipart/pem Content Type
(1) MIME type name: multipart
(2) MIME subtype name: pem
(3) Required parameters: boundary, privacy
(4) Optional parameters: none
(5) Encoding considerations: always 7bit
(6) Security Considerations: see [3]
This subtype of multipart always contains two body parts: the first is an arbitrary content; and, the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part.
The value of the first body part corresponds to <pemtext> as defined in [3]. Note that if <pemtext> is represented using the base64 encoding, then a a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. Otherwise, if a Content-Transfer-Encoding: header is present, it indicates use of the 7bit content encoding.
The syntax and semantics of the boundary parameter is defined in [2].
The syntax of the privacy parameter, using the ABNF notation of [1], is:
privacy-value ::= "ENCRYPTED"
/ "MIC-ONLY"
/ "MIC-CLEAR"
with each value conveying the intent as specified in [3].
Expires May 16, 1993 [Page 3]
draft MIME-PEM Interaction Nov 92
4.2. Definition of the application/pem Content Type
(1) MIME type name: application
(2) MIME subtype name: pem
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: always 7bit
(6) Security Considerations: see [3]
The syntax of this content type corresponds to the <pemhdr> production defined in [3].
Expires May 16, 1993 [Page 4]
draft MIME-PEM Interaction Nov 92
5. Message Composition
When a user composes a message, it is the responsibility of the user agent to use the Content-Type: header. This allows the receiving user agent to unambiguously interpret the body and process it accordingly.
This memo introduces a new header field, "Content-Privacy", which is used to indicate that the message should undergo privacy-enhancement prior to submission. The syntax of this header field corresponds to the <privacy-value> production defined above.
5.1. Pre-Submission Algorithm
Prior to submission, the user agent applies this algorithm:
(1) If the content does not contain the Content-Privacy:
header, then the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content.
(2) If the content does contain the Content-Privacy: header,
the content is transformed from local form to its canonical form. Note that if a Content-Transfer- Encoding: header is present, then the content encoding is reversed as a part of this process.
(3) If the canonical form of the content uses octet values
outside of the NVT ASCII repertoire, and if the value of the Content-Privacy: header is MIC-CLEAR, then this inconsistency is reported to the user and the algorithm aborts.
(4) Otherwise, the privacy-enhancement indicated by the
Content-Privacy: header is performed, constructing a new content. The Content- headers, other than Content- Transfer-Encoding: and Content-Privacy:, are taken from the original content, if any.
(5) If the value of the Content-Privacy: header is not MIC-
CLEAR, then the base64 content encoding is applied and a Content-Transfer-Encoding: header is added to the new
Expires May 16, 1993 [Page 5]
draft MIME-PEM Interaction Nov 92
content.
(6) Finally, a multipart/pem content is constructed, whcih
contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content.
Expires May 16, 1993 [Page 6]
draft MIME-PEM Interaction Nov 92
6. Message Delivery
When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm.
When the original content is reconstituted into canonical form, it may use octet values outside of the NVT ASCII repertoire. If the user agent replaces the multipart/pem content with the original content, then it must select an appropriate transfer encoding and include the appropriate Content-Transfer-Encoding: header.
Upon successful completion of the post-delivery algorithm for each content, the user agent adds a new header field, "Content-Annotation", which is used to indicate the privacy- enhancements that were in effect when the content was submitted. The syntax of this header field, using the ABNF notation of [1], is:
content-annotation ::= "Content-Annotation" ":"
annotation-value
annotation-value ::= <privacy-value> ";" <date-time>
with <privacy-value> corresponding to the privacy-enhancements that was in effect during submission, and <date-time>, defined in [1], indicates the date and time that the privacy- enhancements were verified by the receiving user agent.
NOTE
It must be strongly emphasized that the user's level of trust in the value of the Content-Annotation: header should be no higher than the user's level of trust in the message store employed by the user agent.
Expires May 16, 1993 [Page 7]
draft MIME-PEM Interaction Nov 92
7. An Example
For example, suppose the following message was being readied for submission:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker(a)tis.com
To: ned(a)innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-clear
Hi Ned. See how much nicer this works!
After applying pre-submission algorithm, the message submitted for delivery would appear as:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker(a)tis.com
To: ned(a)innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="next-part";
privacy=mic-clear
Content-Type: text/plain; charset=us-ascii
Hi Ned. See how much nicer this works!
--next-part
Content-Type: application/pem
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: ...
MIC-Info: RSA-MD5,RSA, ...
--next-part--
Expires May 16, 1993 [Page 8]
draft MIME-PEM Interaction Nov 92
After applying the post-delivery algorithm, the resulting message would appear as:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker(a)tis.com
To: ned(a)innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Annotation: mic-clear;
Thu, 12 Nov 1992 22:13:40 -0800
(integrity verified)
Hi Ned. See how much nicer this works!
Of course, as the message being submitted was only plain text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as:
Date: Thu, 12 Nov 1992 21:43:40 -0800
From: scrocker(a)tis.com
To: ned(a)innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/pem; boundary="next-part";
privacy=mic-clear
Hi Ned. See how much nicer this works!
--next-part
Content-Type: application/pem
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: ...
MIC-Info: RSA-MD5,RSA, ...
--next-part--
Expires May 16, 1993 [Page 9]
draft MIME-PEM Interaction Nov 92
8. Observations
The use of the pre-submission and post-delivery algorithms exhibit several properties:
(1) It allows privacy-enhancement of an arbitrary content,
not just an RFC 822 message.
(2) For a multipart or message content, it allows the user to
decide whether the structure of the content should receive privacy-enhancement.
(3) It allows a message to contain several privacy enhanced
contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components.
(4) It minimizes confusion when viewing a MIC-CLEAR content
without a PEM-capable user agent.
(5) It minimizes confusing when viewing a MIC-ONLY content
with a MIME-capable user agent that is not PEM-capable.
9. Acknowledgements
David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction.
Expires May 16, 1993 [Page 10]
draft MIME-PEM Interaction Nov 92
10. References
[1] D.H. Crocker. Standard for the Format of ARPA Internet
Text Messages. Request for Comments 822, (August, 1982).
[2] N. Borenstein, N. Freed, Multipurpose Internet Mail
Extensions. Request for Comments 1341, (June, 1992).
[3] J. Linn, Privacy Enhancement for Internet Electronic
Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992).
[4] S. Kent, Privacy Enhancement for Internet Electronic
Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992).
[5] D. Balenson, Privacy Enhancement for Internet Electronic
Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992).
[6] B. Kaliski, Privacy Enhancement for Internet Electronic
Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992).
Expires May 16, 1993 [Page 11]
draft MIME-PEM Interaction Nov 92
Table of Contents
1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Introduction .......................................... 2 4 Definiton of new Content Types ........................ 3 4.1 Definition of the multipart/pem Content Type ........ 3 4.2 Definition of the application/pem Content Type ...... 4 5 Message Composition ................................... 5 5.1 Pre-Submission Algorithm ............................ 5 6 Message Delivery ...................................... 7 7 An Example ............................................ 8 8 Observations .......................................... 10 9 Acknowledgements ...................................... 10 10 References ........................................... 11
Expires May 16, 1993 [Page 12]
------- =_aaaaaaaaaa0--
[ sorry for the double spacing - my mailer's acting up and I'm too
tired to fight with it anymore. What we need MORE than encrypted mailers
is mailers that do the standard stuff right... The one on the WELL sux!]
