-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIB+jCCAWMCAQIwDQYJKoZIhvcNAQECBQAwSjELMAkGA1UEBhMCVVMxCzAJBgNV
BAgTAk1BMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNo
bm9sb2d5MB4XDTkzMDYwODAxMDQ1MVoXDTk1MDYwODAxMDQ1MVowaDELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAk1BMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp
dHV0ZSBvZiBUZWNobm9sb2d5MRwwGgYDVQQDExNKZWZmcmV5IEkuIFNjaGlsbGVy
MHkwCgYEVQgBAQICAwADawAwaAJhALWbXFwD8HgYebf1Hxazog7hrgMXt2QTTg0h
9nqqPsNkhdCZPRsH+4vUh1otR1W41eJTFqTiB5ZTj3tSVSk1tvmsgKZaYtA6uY8+
pm/morYjbPYkq5hdCfJDL6sPLoEpyQIDAQABMA0GCSqGSIb3DQEBAgUAA4GBABBa
QkzRkeMZ9Mz5xzLCCHg1N1tXyCcbYMOOLF4ZvBfCztMutsO6k8XRISOoYNjzE6wZ
ZeSHwDss4NxtgCQ5nTbmlUR+bJmmkMzGxA321BKURssJshD7jnGC025D5AF5QnRO
/Ps8kZcuhQtUsS8V/tnWep1mhsVhBU7DYfula/Bj
Issuer-Certificate:
MIIB+jCCAWMCAQQwDQYJKoZIhvcNAQECBQAwRDELMAkGA1UEBhMCVVMxCzAJBgNV
BAgTAk1EMSgwJgYDVQQKEx9UcnVzdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMgUENB
MB4XDTkzMDYwMTIxMDYyMloXDTkzMDkwOTIxMDYyMlowSjELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAk1BMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBv
ZiBUZWNobm9sb2d5MIGcMAoGBFUIAQECAgQAA4GNADCBiQKBgQDA9lpS1UKXSpGd
OtoKQoRL12oyNf1hrCz4XBHZ0/Cpw5DaeLIUXeVtXUejzn/0/kbKxnl+uVknciO0
b4x0fe3mZA2lbfLoJOJjKSdkUdKhUDMrBw24NZVjJetRj+voepHQKafvcw0DZoLN
6FT0AfHLVvRDt4xTpSS2YOAFNyy52wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAJ3V
/aqDDTRPxw9De7cIHRU1vOKlSm63eSqszpjkYhIa3IJhoucPJ9iUAJHoIBsVjUri
XXB+A2EMjLpY7S/UMzlF/vgNz4OORtrBP4j6v4bsV48+GX5YbUfRGVfnuyJW2eBx
2yHHd/yk5vY/5u6vQxnjKpSX+3hZoaj1hWd1qmI/
MIC-Info: RSA-MD2,RSA,
SjwY8qtaC1fB3KBen4AfWesfYx0UfEPKECC7w9AF/Xlqgwl61yeXZpv8Ub0gY3FY
TA9sggirmepuDOHfBsfXLkwBRUIIlov9GidEE9shcO03T4SzBSIvBdsBGCRMNyqC
Here is an alternative PEM/MIME Integration Proposal... as I
discussed at the meeting in Amsterdam.
-Jeff
Network Working Group Internet Engineering Task Force
Internet Draft Privacy Enhanced Mail Working Group
J. I. Schiller
MIT
July 1993
An Alternative PEM MIME Integration
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 draft documents valid for a maximum
of six months. Internet Drafts may be updated, replaced,
or obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work
in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of
this or any other Internet Draft.
Distribution of this memo is unlimited. Please send
comments to the <pem-dev(_at_)tis(_dot_)com> mailing list.
This is the second document to describe a mechanism to
enclose MIME messages within PEM and vica versa. This
document is an independent effort to be considered as an
alternative to the previous document. This is *not* a
revision of that document and the authors of it do not
necessarily endorse the approach described here.
[Note: This version of this document has not been
submitted (yet) for consideration as an Internet Draft.
Whether or not I will do that depends in large part on
the discussion and deliberations of this, the pem-dev
community.]
Introduction
This document describes a mechanism for providing Privacy
Enhanced Mail (PEM) functionality within the context of
MIME messages.
Background
MIME (RFC1341-1342) and PEM (RFC1421-1424) have taken
separate evolution paths. Specifically PEM was designed
and specified to handle RFC822 (non-MIME) messages. The
goal of this document is to describe a method for using
PEM to protect MIME messages, and to define a way to
enclose PEM processed messages within MIME messages.
Expires:
[Page 1]
Network Working Group Internet Engineering Task Force
Internet Draft Privacy Enhanced Mail Working Group
J. I. Schiller
MIT
July 1993
To accomplish these goals requires an additional profile
for RFC1421 (Content-Domain: MIME) and the definition of
a new MIME "application" (application/pem-1421).
There are four possibilities for interaction between PEM
and MIME. They are:
* A MIME message transporting an RFC1421 PEM message
which itself contains an RFC822 message (Content-
Domain: RFC822).
* A MIME message transporting an RFC1421 PEM message
which itself contains a MIME object (Content-Domain:
MIME).
* A PEM message which contains a RFC822 message (as
specified by RFC1421).
* A PEM message which contains a MIME message or object
(Content-Domain: MIME).
Definition of "Content-Domain: MIME" within an RFC1421 PEM
message
When a PEM message contains a MIME object, as opposed to
a simple text message, the value of the Content-Domain
field of the PEM headers shall be the string "MIME".
An RFC1421 PEM message of Content-Domain "MIME" shall
contain a MIME "object" that begins with a "Content-Type"
MIME header. The PEM body, upon completion of successful
PEM processing is handed to a MIME interpreter for
further processing. Content-Domain "MIME" messages may be
protected with either ENCRYPTED, MIC-ONLY or MIC-CLEAR
PEM services. However if MIC-CLEAR is chosen, the MIME
content should be in a canonical 7bit form.
In other words, if the enclosed MIME object is encoded in
such fashion as to be 7bit transportable, then MIC-CLEAR
may be (and perhaps should be) used. Other non-encrypted
messages should be encoded via the MIC-ONLY mechanism.
Enclosing a PEM message within a MIME object
An RFC1421 PEM message may be enclosed in a MIME message
by defining it to be of Content Type "application/pem-
1421" by preceding the PEM processed body with:
Content-Type: application/pem-1421
Note that the application subtype is defined to be "pem-
Expires:
[Page 2]
Network Working Group Internet Engineering Task Force
Internet Draft Privacy Enhanced Mail Working Group
J. I. Schiller
MIT
July 1993
1421" and that the representation *must* be text/plain;
charset=us-ascii. This is because these are correct
characterizations of what a RFC1421 message appears as.
The behavior of a MIME mail reader with PEM capability
A MIME mail reader with PEM capability will be able to
fully process a MIME message which includes a PEM portion
(which may either be the entire message or only part of a
multi-part message).
The MIME reader will process a message which contains a
PEM portion as it would any other MIME message. Upon
encountering a "application/pem-1421" body part, it will
invoke PEM processing on the enclosed PEM message. If the
PEM message contains a Content-Domain "MIME" body, it
will invoke MIME recursively on the successfully
processed PEM body. If the Content-Domain is RFC822, the
PEM software will either display the enclosed text, or
prepend the necessary headers such that it can be fed to
a MIME reader which will treat it as an RFC822 mail
message.
The behavior of a MIME mail reader without PEM capability
A MIME mail reader will process a MIME message with PEM
contents as any other MIME message. If an application/pem-
1421 object is found and the MIME reader does not support
PEM, then the MIME reader may handle the enclosed PEM
message in the same or similar fashion as it handles any
other application subtype for which it has no support
software.
The behavior of a non-MIME but PEM capable mail reader
A PEM mail reader that does not understand MIME will be
able to process a MIME/PEM message provided that the
message itself is a PEM message. In other words, if the
whole message is PEM processed as the last step prior to
transmission, then a PEM capable, but non-MIME capable
mail reader will be able to process the PEM message and
then display the enclosed MIME object in the same fashion
that a non-MIME mail reader handles a MIME (but non-PEM)
message today.
It is likely that a non-MIME compliant mail reading agent
may not be able to parse a MIME message in order to
discover an enclosed "application/pem-1421" component
containing a PEM message. However an end-user may be able
to manually reformat the incoming message so as to make
it amenable to PEM processing.
Expires:
[Page 3]
Network Working Group Internet Engineering Task Force
Internet Draft Privacy Enhanced Mail Working Group
J. I. Schiller
MIT
July 1993
Discussion
Prior approaches to integrating PEM and MIME have
suggested a significant departure from the RFC1421 PEM
encapsulation mechanism. Specifically it has been
recommended that PEM messages be represented as MIME
multi-part messages. One part of the multi-part would
contain what in RFC1421 is described as the PEM headers,
and the other would contain the PEM body that is
protected by the PEM mechanisms specified in the PEM
header part.
This document intentionally does not recommend such an
approach. This is because it is important for MIME
interpreters to *not* reach down into the structure of a
PEM body until PEM processing has been performed. The
reason for this requirement has to do with the
requirement that PEM body parts be immutable so that
digital signatures computed on them can be verified. If a
PEM body part is decomposeable by MIME readers, then it
is quite possible that MIME gateways could reassemble PEM
body parts in a fashion semantically equivalent to the
original message, but sufficiently different (i.e.,
different in one bit is sufficient) to cause signature
verification to later fail.
It is important to understand that the signature
verification requirement mandates that PEM messages be
carried within MIME as "application" objects and not as
"message", "multipart" or other types of body parts. Once
this is recognized, it no longer matters whether or not
the object within the "application" enclosure appears to
be a MIME object upon visual inspection, for it is now
outside the realm of what a MIME interpreter may attempt
to parse without the aid of the application processor
(PEM in this case).
By using the RFC1421 based encapsulation technology we
benefit from the experience gained in debugging existing
PEM implementations as well as ease backward
compatibility with non-MIME based PEM agents.
Examples
Date: Sun, 30 May 93 23:59:39 EST
From: jis(_at_)MIT(_dot_)EDU (Jeffrey I. Schiller)
To: pem-dev(_at_)tis(_dot_)com
Subject: Example PEM MIME Interaction
MIME-Version: 1.0
Content-Type: application/pem-1421
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: MIME
Originator-Certificate:
MIIB+jCCAWMCAQIwDQYJKoZIhvcNAQECBQAwSj...
Issuer-Certificate:
MIIB+jCCAWMCAQQwDQYJKoZIhvcNAQECBQAwRDELMA...
MIC-Info: RSA-MD5,RSA,dlSRMLFiwcK7FDvFef8gJfLWwMM4uxMSNtKG
lLz9xxwfAyvaFuzp85davcwX4q7EImDs4K46Uwh0oL2GueLnv6b4s1gg25
mMg/Y5Bd7/HaEcvkV77tKWGXZrDGEgGSDA
Content-Type: text/plain; charset=us-ascii
This is a test message.
-----END PRIVACY-ENHANCED MESSAGE-----
Expires:
[Page 4]
Network Working Group Internet Engineering Task Force
Internet Draft Privacy Enhanced Mail Working Group
J. I. Schiller
MIT
July 1993
Author's Address
Jeffrey I. Schiller
Massachusetts Institute of Technology
MIT Room E40-311
1 Amherst Street
Cambridge, MA 02139
U.S.A.
Tel: +1 (617) 253-0161
Fax: +1 (617) 258-8736
Email: jis(_at_)mit(_dot_)edu
Expires:
[Page 5]
-----END PRIVACY-ENHANCED MESSAGE-----