From: Fen Labalme <fen@well.sf.ca.us>
Date: Sat, 21 Nov 92 00:42:36 PST
To: cypherpunks@toad.com
Subject: The Cypherpunks Mail Project
Message-ID: <199211210841.AA20896@well.sf.ca.us>
MIME-Version: 1.0
Content-Type: text/plain


To: pem-dev@TIS.COM, ietf-822@dimacs.rutgers.edu Subject: MIME-PEM Interaction
Reply-To: ietf-822@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@dbc.mtview.ca.us> Sender: pem-dev-relay@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@tis.com


Ned Freed
Innosoft International, Inc.
ned@innosoft.com


Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@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@tis.com
To:	ned@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@tis.com
To:	ned@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@tis.com
To:	ned@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@tis.com
To:	ned@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!]