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
draft MIME-PEM Interaction Nov 92
MIME-PEM Interaction
Mon Nov 16 15:51:54 1992
Steve Crocker
Trusted Information Systems
crocker(_at_)tis(_dot_)com
Ned Freed
Innosoft International, Inc.
ned(_at_)innosoft(_dot_)com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)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(_at_)tis(_dot_)com
To: ned(_at_)innosoft(_dot_)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(_at_)tis(_dot_)com
To: ned(_at_)innosoft(_dot_)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(_at_)tis(_dot_)com
To: ned(_at_)innosoft(_dot_)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(_at_)tis(_dot_)com
To: ned(_at_)innosoft(_dot_)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]