Folks, Attached are drafts of two documents related to our MIME-PEM integration effort. The first document describes the embedding of PEM processing in MIME. The second is a slightly generic document that describes the multipart/security "family." We've decided to write the next version combining these two documents but are distributing them now so folks can see the direction in which we're headed. (The rationale for two documents is that someone else might define how to embed PGP or RIPEM in MIME and need to make use of the multipart/security family. That's surely what we've intended, but we think separate presentation is too clumsy and it will be just as easy for some future writer to refer to the relevant section of the single document.) As a separate matter, our implementation provides an option to transform received MIME-PEM messages into another MIME form, multipart/pem-annotated, to record the signature checking, etc. This is a "purely local matter," but we will document it later so others can see what we're doing. We'll send another version next week when we've combined the documents. We'll send it to internet-drafts at that time. Comments and discussion are encouraged. Thanks, Jim
Network Working Group Steve Crocker
INTERNET DRAFT Ned Freed
draft-crocker-mpem-00.txt Jim Galvin
Sandy Murphy
Marshall Rose
February 1994
MIME-PEM Interaction
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 ``work in progress''.
To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).
2. Abstract
This memo defines a framework for interaction between MIME and PEM
services. MIME, an acronym for "Multipurpose Internet Mail Extensions",
defines the format of the contents of Internet mail messages and
provides for multi-part textual and non-textual message bodies. PEM, an
acronym for "Privacy Enhanced Mail", provides message encryption and
message authentication/integrity services for Internet mail messages.
The framework provides for the services of MIME and PEM to be used in a
complementary fashion. It updates the message encryption and
authentication procedures defined by Part I of the PEM
specifications [3] and obsoletes the key certification and related
services defined by Part IV of the PEM specifications [6].
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 1]
INTERNET DRAFT MIME-PEM Interaction February 1994
3. Introduction
An Internet electronic mail message consists of 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 MIME [2]. MIME does not provide encryption or
authentication/integrity services.
PEM [3-6] specifies how to apply encryption and authentication/integrity
services to the contents of an electronic mail message but does not
provide message structuring or type labelling facilities.
This memo defines a framework whereby the services provided by MIME and
PEM are used in a complementary fashion. The resulting combined service
provides encryption and authentication/integrity services for single-
part and multi-part textual and non-textual messages. We refer to the
authentication/integrity service as a signature service.
This memo updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes include the separation of the encryption
and signature services, the removal of the limitation to only enhance
text-based messages, the removal of the canonicalization and transfer
encoding operations, the deprecation of the Content-Domain: and Proc-
Type: headers, and the separation of certificate and certificate
revocation list transmission from the security enhancements. These
changes represent a departure in mechanism, not in effect, and are
detailed in the next section.
MIME-PEM interaction is provided for by making use of the
multipart/security content type [8] and defining two new MIME content
types: application/pem-request and application/certificate-data. The
relationship between MIME and PEM is described in terms of two
functions: message composition and message delivery.
These new content types (application/pem-request and
application/certificate-data) are used to transmit requests for
certificate operations (retrieval, certification, revocation list
retrieval, etc.) and the responses to those requests. These two content
types are independent body parts and are not required to be encapsulated
in any other body part.
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 2]
INTERNET DRAFT MIME-PEM Interaction February 1994
4. Summary of Changes to PEM Specification
This memo updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes are enumerated below.
(1) The PEM specification currently requires that encryption services
be applied only to message bodies that have been signed. By
providing for each of the services separately, they may be applied
recursively in any order according to the needs of the requesting
application.
(2) PEM implementations are currently restricted to processing only
text-based electronic mail messages. In fact, the message text is
required to be represented by the ASCII character set with
"<CR><LF>" line delimiters. This restriction no longer applies.
(3) With the removal of the text restriction it is not possible to
specify a universal canonical form. Thus, the transformation of
the input to a universal canonical form no longer applies.
(4) MIME includes transfer encoding operations to ensure the unmodified
transport of body parts, which subsumes these services in PEM.
(5) PEM specifies a Proc-Type: header field to identify the type of
processing that was performed on the message. This functionality
is subsumed by the MIME Content-Type: headers. The Proc-Type:
header also included a decimal number that was used to distinguish
among incompatible encapsulated header field interpretations which
may arise as changes are made to the PEM standard. This
functionality is replaced by the Version: header specified in this
memo.
(6) PEM specifies a Content-Domain: header, the purpose of which is to
describe the type of the content which is represented within a PEM
message's encapsulated text. This functionality is subsumed by the
MIME Content-Type: headers.
(7) The PEM specifications include a document that defines new types of
PEM messages, specified by unique values used in the Proc-Type:
header, to be used to request certificate and certificate
revocation list information. This functionality is subsumed by the
two new content types specified in this memo.
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 3]
INTERNET DRAFT MIME-PEM Interaction February 1994
(8) The content domain header field, defined in [3], is not included,
as its functionality is subsumed by MIME.
(9) The Proc-Type header field is not included. It's purpose was
twofold: first, to indicate the version of PEM used and second, to
indicate the security service employed. The MIME body part
content-type serves to indicate the security service employed. The
new Version header field serves to indicate the version of PEM.
Therefore, the functionality of the Proc-Type header field is
subsumed by other mechanisms.
(10) A new header field, called "Version", is introduced. It indicates
the version of PEM used.
(11) The header fields having to do with certificates and certificate
revocation lists and the header fields having to do with security
enhanced messages (e.g. Originator-ID-Asymmetric, DEK-Info, MIC-
Info, etc.) are separated into different MIME body parts. The
Originator-Certificate and Issuer-Certificate fields no longer
appear.
(12) Because encryption and signature security services are separated,
there is no need for a MIC-Info field in the header associated with
an encrypted message under asymmetric key management.
(13) Because encryption and signature security services are separated,
there is no need for a micalgid argument or a symencmic argument in
the Key-Info field associated with an orignator or recipient with
symmetric key management.
(14) In [3], when asymmetric key management is used, an Originator-ID
field is required in order to identify the private key used to sign
the MIC argument in the MIC-Info field. Because no MIC-Info field
is associated with the encryption security service under asymmetric
key managment, there is no requirement in that case to include an
Originator-ID field.
(15) In [3], when symmetric key management is used, a recipient field is
always required. This document allows a header which includes only
an Originator-ID-Symmetric field and a Key-Info field, to be used
in those cases where an originator sends a message only to
himself/herself.
(16) The grammar presented here explicitly separates the header fields
that can appear for the encryption security service and the
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 4]
INTERNET DRAFT MIME-PEM Interaction February 1994
signature security service and for symmetric and asymmetric key
management. It is the intent of this document to simply tighten
the expression of the allowed header fields; there is no intent to
reduce the functionality of combinations of symmetric and
asymmetric key management, and encrytion and signature security
from those of [3].
These changes represent a departure in mechanism, not in effect, from
those specified in [3] and [6].
5. Use of multipart/security for PEM
In Section 4.3.2 of [3], a four step process is described for preparing
outbound PEM messages. In the next section the changes to this four
step process are described in detail. The succeeding two sections
describe the content of the application/signature and application/keys
in the multipart/security when PEM services are applied to MIME body
parts.
5.1. PEM Processing Steps
In Section 4.3.2 of [3], the following four step process is described
for preparing outbound PEM messages.
(1) Local Form -- the message text is prepared in the system's native
character set
(2) Canonical Form -- the message text is converted to a universal
canonical form
(3) Signature and Encryption -- the signature and optionally the
encryption service is applied to the message text
(4) Printable Encoding -- if required, the message text is printably
encoded
This specification eliminates the last step, since this functionality is
provided by MIME. The third step is split into two steps, either or
both of which may be applied in any order. The changes to these steps
may be summarized as follows.
(1) Local Form -- the content of the message is no longer restricted to
text
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 5]
INTERNET DRAFT MIME-PEM Interaction February 1994
(2) Canonical Form -- there is no longer a universal canonical form,
since the message content to be security enhanced may be arbitrary;
however, canonicalization of the content is required
(3) Security Services -- either or both of the signature and encryption
service may be applied in any order
Each of these steps is described in detail below.
5.1.1. Step 1: Local Form
Section 4.3.2.1 in [3] is to be replaced with the following text.
This step is applicable to both signed contents and encrypted contents.
The message content is created in the system's native format.
5.1.2. Step 2: Canonical Form
Section 4.3.2.2 in [3] is to be replaced with the following text.
Prior to the application of the signature service, the content must be
converted to a canonical form, as specified by [8]. The required
conversion is summarized here for convenience, although the definitive
specification is contained only in [8] and its revisions.
No canonicalization is required for the encryption service. If both
signature and encryption services are to be applied to a content, the
content must be canonicalized just prior to the signature service. If
the content is encrypted first, the canonicalization occurs before the
signature service and after the encryption service.
If the encoding type of the content is "7bit", the line delimiters must
be converted to a universal canonical form as specified by [8]. In
particular, lines must be delimited by the "<CR><LF>" character
sequence.
In all other cases, no content conversion is explicitly required.
However, as described in [8], an originator may convert a local form to
a form more suitable for a recipient. Regardless, an originator must
ensure that the form of the content that is signed is either the same
form that is received by a recipient or is re-creatable by the
recipient. The issue is that many mail transfer agents alter messages
in transit. Preventing these alterations is easily accomplished by
applying one of the MIME transfer encoding options, for example, base64
or quoted-printable, as recommended by [2].
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 6]
INTERNET DRAFT MIME-PEM Interaction February 1994
5.1.3. Step 3: Security Services
An implementation must allow a user to select either or both security
services, in either order. The object to be enhanced is prepared by a
MIME implementation and made available to a PEM implementation according
to a local convention. The PEM implementation must produce two outputs:
the data that has been enhanced and the control information necessary to
de-enhance the data. These outputs must be made available to the MIME
implementation which will construct a multipart/security content
according to the conventions of [8].
The next two sections specify the syntax of the control information
output by a PEM implementation for each of security services. The
specification is prescribed by the BNF notation as defined in [1],
Sections 2 and 3.3.
NOTE: should summarize the differences in the BNF of PEM mes-
sages
5.2. Use of application/signature Content Type
The <keyinfo> token of [3] has been separated into <sigsymkeyinfo> and
<asymkeyinfo> tokens. The productions <micinfo>, <origid-asymm>,
<origid-symm>, <recipid-symm>, and <recipid-asymm> are defined in
Section ??.
<pemsig> ::= <version> 1*<sigorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<sigorigrecipgroups> ::=
( 1*(<origsigsymflds> 1*<recipsigsymflds>) ); symmetric
/ (<origid-symm> <sigsymkeyinfo>) ; symmetric
/ ( 1*<origasymflds> ) *<recipasymflds> ) ; asymmetric
<origsigsymflds> ::= <origid-symm> [<sigsymkeyinfo>]; symmetric
<origasymflds> ::=
<origid-asymm> [<asymkeyinfo>] <micinfo> ; asymmetric
<recipsigsymflds> ::= <recipid-symm> <sigsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<sigsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
[<symencdek>] "," <symencmic> CRLF ; symmetric
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 7]
INTERNET DRAFT MIME-PEM Interaction February 1994
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
For an implementation that supports only asymmetric key management and
does not support keyed MIC algorithms, the headers can be simply
represented by:
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
5.3. Use of application/keys Content Type
The <keyinfo> token of [3] has been separated into <encsymkeyinfo> and
<asymkeyinfo> tokens. The productions <dekinfo>, <origid-asymm>,
<origid-symm>, <recipid-symm>, and <recipid-asymm> are defined in
Section ??.
<pemkeys> ::= <version> <dekinfo> 1*<encorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<encorigrecipgroups> ::=
( 1*(<origencsymflds> 1*<recipencsymflds>) ); symmetric
/ ( <oridid-symm> <encsymkeyinfo> ) ; symmetric
/ 1*<recipasymflds> ; asymmetric
<origencsymflds> ::= <origid-symm> [<encsymkeyinfo>]; symmetric
<recipencsymflds> ::= <recipid-symm> <encsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<encsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," ","
<symencdek> "," CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
As we have separated the encryption and signature security services, the
symmetric Key-Info field has no need for the <micalgid> or <symencmic>
arguments for encrypted messages. We preserve the unneeded commas to
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 8]
INTERNET DRAFT MIME-PEM Interaction February 1994
maintain backward compatibility with existing parsers.
For an implementation that supports only asymmetric key management and
does not support keyed MIC algorithms, the headers can be simply
represented by:
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo>
6. Definition of New Content Types
This memo defines two new content types, the contents of which comprise
a replacement mechanism for [6]. The first content type is
application/pem-request, which replaces the certification request
message and the CRL-retrieval request message. The second content type
is application/certificate-data, which replaces the certification reply
message, the crl-storage request message, and the crl-retrieval reply
message. There were no requirements on a crl-storage reply message and
none are specified in this memo. This memo includes a specification for
a certificate request message, which was previously undefined.
NOTE: 1424 has some descriptive text, especially for certifica-
tion messages, that should be included
6.1. application/pem-request Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-request
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 9]
INTERNET DRAFT MIME-PEM Interaction February 1994
The content of this body part corresponds to the following production.
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <asymmid> CRLF
<issuer> ::= "Issuer:" <asymmid> CRLF
<certification> ::= "Certification:" <encbin> CRLF
This content type is used to provide for some of the requests described
in [6]. The information in the body part is entirely independent of any
particular enhanced message. As such, the application/pem-request
content type is an independent body part. It is not used in a
multipart/security context containing PEM enhanced messages.
The certification request and crl-retrieval request are provided for
directly. If the content contains a Certification: field it requests
certification of the self-signed certificate in the field value. If the
content contains an Issuer: field it requests the certificate revocation
list chain beginning with the issuer identified in the field value. The
crl-storage request is provided for by the application/certificate-data
content-type described in the next section. If the content contains a
Subject: field it requests the certificate chain beginning with the
subject identified in the field value.
The Subject: and Issuer: fields each contain a value of type Name,
encoded according to the Basic Encoding Rules, then in ASCII, as for the
Originator-ID-Asymmetric: field of [3].
In each case, the response can be transmitted in an
application/certificate-data content type. When returning certificate
and CRL chains, if there exists more than one chain, several
application/certificate-data contents would need to be returned in the
reply, one for each chain.
6.2. application/certificate-data Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: certificate-data
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 10]
INTERNET DRAFT MIME-PEM Interaction February 1994
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The content of this body part corresponds to the following production.
<certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF
This content type is used to transfer certificate or certificate
revocation list information. This information is entirely independent
of any particular enhanced message. (Note that the converse is not
true: the validity of an enhanced message cannot be determined without
the proper certificates or current CRL information.) As such, the
application/certificate-data content type is an independent body part.
It is not used in a multipart/security context containing PEM enhanced
messages.
The <certchain> production contains one certificate chain. A
certificate chain starts with a certificate and continues with the
certificates of subsequent issuers. Each issuer certificate included
must have issued the preceding certificate. For each issuer, a CRL may
be supplied. A CRL in the chain belongs to the immediately following
issuer. Therefore, it potentially contains the immediately preceding
certificate.
The <crlchain> production contains one certificate revocation list
chain. The CRLs in the chain begin with the requested CRL and continue
with the CRLs of subsequent issuers. The issuer of each CRL is presumed
to have issued a certificate for the issuer of the preceding CRL. For
each CRL, the issuer's certificate may be supplied. A certificate in
the chain must belong to the issuer of the immediately preceding CRL.
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 11]
INTERNET DRAFT MIME-PEM Interaction February 1994
The relationship between a certificate and an immediately preceding CRL
is the same in both cases. In a <certchain> the crl's are optional. In
a <crlchain> the certificates are optional.
7. Message Processing
When a user composes a message, it is the responsibility of the user
agent to construct a valid MIME message. In particular, Content-Type:
and Content-Transfer-Encoding: headers should be used wherever they are
appropriate. This allows the receiving user agent to unambiguously
interpret the message body and process it accordingly.
Each block of content headers associated with either an RFC822 <message>
or with a MIME <body-part> represents a logical place where security
enhancement can be requested. A security enhancement request associated
with a particular <message> or <body-part> content is taken to apply to
the entire content; it is not possible to security-enhance only a
portion of a body part.
The mechanism used to communicate security enhancement requests to the
pre-submission processor described below is strictly a local
implementation issue. However, the interface between the message
composer and pre-submission processing MUST be trustworthy, since the
message composer relies on pre-submission processing to either perform
the requested security enhancement operation or return an error.
Regardless of the mechanism chosen, great care should be taken to
safeguard against both the release of information that has not received
the requested type of security enhancement as well as tampering with the
enhancement request itself.
7.1. Pre-Submission Algorithm
The user agent first composes a MIME-compliant message and then applies
this algorithm:
(1) If the content at this (initially top) level has NOT been selected
for security enhancement, 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 at this level has been selected for security
enhancement, then the content, including its headers, constitutes
the object that is to be made available to the security enhancement
process. The headers at a minimum will include a Content-Type
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 12]
INTERNET DRAFT MIME-PEM Interaction February 1994
header, either explicit or implicit. The object will eventually be
replaced with the multipart/security content that is produced by
the security enhancement operation.
(3) The selected security enhancement is performed. This enhancement
produces two data streams: the enhanced object and a control stream
comprised of a set of headers as defined in the <pemsig> or
<pemkeys> productions.
(4) A new body part is then constructed, of content type
multipart/security. The body part contains two body parts, whose
content depends on the enhancement requested, which is constructed
according to the specifications in this memo.
(5) This multipart/security content replaces the original object.
7.2. Post-Delivery Algorithm
When a user receives a message containing a multipart/security content,
the user agent may transform the content back into its original form
prior to privacy-enhancement. This operation, the post-delivery
algorithm, is performed by reversing the steps performed during the
pre-submission algorithm.
When the original content is reconstituted, it may use octet values
outside of the US-ASCII repertoire and may contain body parts without
line breaks. If the user agent replaces the multipart/security content
with the original content, then it must select appropriate Content-
Transfer-Encodings for each body part and add corresponding Content-
Transfer-Encoding: headers.
Upon successful completion of the post-delivery algorithm for each
content, the type of enhancement that was in effect for that content
must be communicated to the user. The mechanism used to do this is a
local implementation issue. As with requests for enhancement to the
pre-submission algorithm, the path between post-delivery processing and
actual display of the message must be a trusted one, lest a message be
presented that purports to have undergone some form of enhancement it
did not in fact receive.
8. Examples
For example, suppose the following message was selected for security
enhancement:
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 13]
INTERNET DRAFT MIME-PEM Interaction February 1994
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
After applying pre-submission algorithm with a request that signature
enhancement be applied to the body, the message submitted for delivery
would appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1685(_dot_)762723090(_dot_)2(_at_)tis(_dot_)com>
Hi Ned. See how much nicer this works!
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1685(_dot_)762723090(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,qJ8q9mzkH/B+/ntR3xFDwTCOKaIyvIAyPw0ZoseDSCMQ6uDXD9RE=
n3QHrU5IGq1kK8bk4OU13TIh0ke7ZeRriCaypz25KoUGl9S6rUAsDSRo7De9K0FtJDzlJpnPhI=
CB
------- =Signature Boundary--
After applying the post-delivery algorithm, the resulting message would
once again appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 14]
INTERNET DRAFT MIME-PEM Interaction February 1994
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
If it was desired to also sign the headers of the example message, after
applying the pre-submission algorithm the message submitted for delivery
would appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
MIME-Version: 1.0
Content-Type: message/rfc822
Content-ID: <1732(_dot_)762723767(_dot_)2(_at_)tis(_dot_)com>
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1732(_dot_)762723767(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,qOfK2DcyOixFicDp7UII9E0fmX3asfgD1OVgt3kxpZlpPEO055ek=
bZq+eDdEFUrte8TXU00RbKilGlyZnD/1MwDykX+0u9imBbtbJ+Y/hHP/3pKXSHo8lWMlri9hg3=
+C
------- =Signature Boundary--
The content to be enhanced need not be ascii text. For example, the
following audio body part could be signed:
Content-Type: audio/basic
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 15]
INTERNET DRAFT MIME-PEM Interaction February 1994
[ binary data representing a sound ]
producing the following body part:
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
Content-Type: audio/basic
Content-ID: <1747(_dot_)762724129(_dot_)2(_at_)tis(_dot_)com>
Content-Transfer-Encoding: base64
WyBiaW5hcnkgZGF0YSByZXByZXNlbnRpbmcgYSBzb3VuZCBdCg==
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1747(_dot_)762724129(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,k6E85mx8fHD+JPxaexmuao9lwAtn1TCL8/7QfUarHW9yhaNH7E0S=
/ID2AmUQexN++R38SegJ4NukhGs6icU9cdrYZ2fvgxHx1ThAthCIt7C8cVJRldHvq72mQ10d82=
0h
------- =Signature Boundary--
Note well, the binary form of the data was signed, not the encoded form.
The content transfer encoding indicated above was applied because
multiparts are required to be 7bit clean. Thus, the encoding must be
removed before the signature is verified by the recipient.
The following content illustrates how a security enhanced content can
itself be security enhanced. The inner most text content is digitally
signed. The outer multipart/security applies a digital signature to the
entire inner signed object.
Content-Type: text/plain; charset="us-ascii"
This text will be signed and then the signed object will be signed.
Application of the pre-submission algorithm produces:
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 16]
INTERNET DRAFT MIME-PEM Interaction February 1994
Content-Type: multipart/security; boundary="----- =Outer Signature Boundary"
------- =Outer Signature Boundary
Content-Type: multipart/security; boundary="----- =Inner Signature Boundary"
------- =Inner Signature Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1759(_dot_)762724555(_dot_)3(_at_)tis(_dot_)com>
This text will be signed and then the signed object will be signed.
------- =Inner Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1759(_dot_)762724555(_dot_)2(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,pBEHvHjrcOs30+jZzy5E2UTAaeb6R7B1wdWbtEcGOqEi2WNrIfBw=
D1gZDueUZTYSyCkEHEnErXsrhGc8jsoqcAHLYg52iYdrMpDBGoXRQobXHNI+Cpnx//s4lp3PAU=
cp
------- =Inner Signature Boundary--
------- =Outer Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1759(_dot_)762724555(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,XqedEy0cwHyLdt4+oBGEl+/2BfypRx18RohAElwAZmEgZDEWiFKJ=
ujRh4aAQUCF/U9lR7Z6kyTvSNLBCG8N0D0GxONStUOjUsj7b7vX72bCLnc9wVaeWMvtiA+HFXm=
Le
------- =Outer Signature Boundary--
Suppose the body of the following message was selected for signature and
then encryption:
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 17]
INTERNET DRAFT MIME-PEM Interaction February 1994
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Yes Jim, it works much nicer!
The application of the pre-submission algorithm would produce:
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Encryption Boundary"
------- =Encryption Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
yo+jQ2neZQiFW+21/DHev4dumFTAOui7nB+cRfFhJff+5Xpwl5RWxdmzfXWiSB3nBBrsqwHu3yIv
mZONWdRyWlhy2BIpKj54OoyDj0EbmCMseY5v0JPJhMYqf4SoBRHOMGZRsFAEF849diLX4nZhC1lS
ljfF9KGgRi3OBl/JblAtOxehkvvD20Z1kQUtQ/84KYFAKxV6WferRHK+vHxeciOUYMrGa+wipGTU
sPLYm7kuESHyACb0Wihy5RZ+fOkf0LZT1aCX/945nw/CpSWnp83EsyevvXCTYz+EejnOw9GHZTR0
nBnOolfXG7uEv4PaMfcG70Wz+ic+e8rtqHXW8BOA4THGv81fZd0OCBFYc1oRz3SzVRaPVtpiN4LE
8b1tQVuBu8DKdWbGeY0HvHm/SEZ+/Cb2idbOC6Cm89/yz6o1y2dTycClXa2DbHPtuR1FjzpTm8bq
cr5/ycQ1k2gmO4MagKHCAEn+Hq9w9ITSZFNmV/jSQaE7f6lox00snfukK1aXQW4f66b+H0o83stw
adVPFVdFHIMRGMoV/17kfqaUh7LFJr7u7Xbz0geDxT2aFUzYbk1lC6H6XKLnL8Ipbczavq9GELD9
wQkbkHxUUgV9xhTuwXJzRkhpi9FF389nxR9WEoP9S+Be9GeoCPCOHcd5BJhvYKGoBUhuAL9dM6GW
7SLy0QOg/dylJEZ6Hg9FJDSRrNF6xbs+Sxf85p0oKtt+egpVoKRJXub3zniqaKK9k15bFdkZSMLz
cnqZcDG70UgyE7IFVsDL7h+P1p4DKHT60xOowCgZkUOQC98MczB78F1D5GB3s/d++rZ/J0i0v3IO
3BMGHgFHJfMFAgbH5cFBEzkTY3y0L85iDEZ6GQAkP86uCYYVMeEFIokostKrgpF++UdvA5GxbdjO
oZjzLnjjraLtkYB1Ht8iEbxjRIlYAK1YMlm29A==
------- =Encryption Boundary
Content-Type: application/keys; protocol="pem"
Content-ID: <1778(_dot_)762724901(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,933A1AB95512E140
Recipient-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEC=
hMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02
Key-Info: RSA,r8kCmWCqfe39FYybN7kTOPzVuCw4LXagpCdeYJcy942eKv2hXX8LkplY3f8Q=
E3Z8gkBh3WZjNephpor4rul7UvlKW1t+/IHmcReiWRiwSiBwuuET3o7ScOMAbdZfe8vl
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 18]
INTERNET DRAFT MIME-PEM Interaction February 1994
------- =Encryption Boundary--
If the body of the same message was selected for encryption only, the
application of the pre-submission algorithm would produce:
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Encryption Boundary"
------- =Encryption Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
oOsMVFWMmIjvk4gDeXtdQcAb9273rp+0YcFLul2fezlEn2686vuq0EHOYeduSsKYv3H5F8L79r1Y
ZyW0pHo4uPmNiLIJGhXyqh5eBXp18JCqsBJmXOQaBggzscmKNi0xBFzyDOVYXxjAE3449mRdbxsM
fbqo3cPs
------- =Encryption Boundary
Content-Type: application/keys; protocol="pem"
Content-ID: <1803(_dot_)762725084(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,E18A7DA1885E2C49
Recipient-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEC=
hMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02
Key-Info: RSA,BMD6IcGJvpu4ZDMDkLrGaQ66TNNE2yTnw+AjpbWyXEiFT70VEFUUkhwPKJVz=
kVzzEJNzMugkROc3LYbf1kJtsnF+4V34Wqs8nAl60DNrzFGpZfYtnCcIro6eAyVO8y4A
------- =Encryption Boundary--
9. Observations
The use of the pre-submission and post-delivery algorithms to combine
PEM and MIME capabilities exhibit several properties:
(1) It allows privacy-enhancement of an arbitrary content, not just an
entire RFC 822 message.
(2) For a multipart or message content, it allows the user to specify
different privacy enhancements to be applied to different
components of the structure of the content.
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 19]
INTERNET DRAFT MIME-PEM Interaction February 1994
(3) It provides for messages containing 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.
The use of a MIME-capable user agent makes complex nesting of enhanced
message body parts much easier. For example, the user can separately
sign and encrypt a message. This motivates a complete separation of the
confidentiality security service from the authentication/message
integrity security service. That is, different keys could be used for
the different services and could be protected separately. In the
asymmetric case, this means an employee's company could be given access
to the (private) decryption key but not the (private) signature key,
thereby granting the company the ability to decrypt messages addressed
to the employee in emergencies without also granting the company the
ability to sign messages as the employee.
The use of two private keys requires the ability to maintain multiple
certificates for each user.
10. Collected Grammar
The following is a summary of the grammar presented in this document.
(1) Signature headers
<pemsig> ::= <version> 1*<sigorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<sigorigrecipgroups> ::=
( 1*(<origsigsymflds> 1*<recipsigsymflds>) ); symmetric
/ (<origid-symm> <sigsymkeyinfo>) ; symmetric
/ ( 1*<origasymflds> *<recipasymflds> ) ; asymmetric
<origsigsymflds> ::= <origid-symm> [<sigsymkeyinfo>]; symmetric
<origasymflds> ::=
<origid-asymm> [<asymkeyinfo>] <micinfo> ; asymmetric
<recipsigsymflds> ::= <recipid-symm> <sigsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<sigsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
[<symencdek>] "," <symencmic> CRLF ; symmetric
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 20]
INTERNET DRAFT MIME-PEM Interaction February 1994
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
(2) Signature headers (short version)
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo>
(3) Encryption Headers
<pemkeys> ::= <version> <dekinfo> 1*<encorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<encorigrecipgroups> ::=
( 1*(<origencsymflds> 1*<recipencsymflds>) ); symmetric
/ ( <oridid-symm> <encsymkeyinfo> ) ; symmetric
/ 1*<recipasymflds> ; asymmetric
<origencsymflds> ::= <origid-symm> [<encsymkeyinfo>]; symmetric
<recipencsymflds> ::= <recipid-symm> <encsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<encsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," ","
<symencdek> "," CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
(4) Encryption Headers (short version)
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo>
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 21]
INTERNET DRAFT MIME-PEM Interaction February 1994
(5) Request Headers (certificate, certification, etc.)
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <asymmid> CRLF
<issuer> ::= "Issuer:" <asymmid> CRLF
<certification> ::= "Certification:" <encbin> CRLF
(6) Certificate Headers (certificate, certification revocation list)
<certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF
11. Security Considerations
NOTE: to be done
12. Acknowledgements
David H. Crocker suggested the use of a multipart structure for MIME-PEM
interaction.
13. References
[1] David H. Crocker. Standard for the Format of ARPA Internet Text
Messages. RFC 822, University of Delaware, August 1982.
[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet
Mail Extension) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, Bellcore and
Innosoft, September 1993. Obsoletes RFC 1341.
[3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures. RFC 1421,
February 1993. Obsoletes RFC 1113.
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 22]
INTERNET DRAFT MIME-PEM Interaction February 1994
[4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management. RFC 1422, BBN
Communications, February 1993.
[5] David M. Balenson. Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423,
Trusted Information Systems, February 1993.
[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic
Mail: Part IV: Key Certification and Related Services. RFC 1424,
RSA Laboratories, February 1993.
[7] Robert Braden, Editor. Requirements for Internet Hosts --
Application and Support. RFC 1123, USC/Information Sciences
Institute, October 1989.
[8] REFERENCE TO MULTIPART/SECURITY
14. Authors' Addresses
Steve Crocker
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: crocker(_at_)tis(_dot_)com
Ned Freed
Innosoft International, Inc.
250 West First Street, Suite 240
Claremont, CA 91711
Tel: +1 909 624 7907
FAX: +1 909 621 5319
email: ned(_at_)innosoft(_dot_)com
James M. Galvin
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: galvin(_at_)tis(_dot_)com
Sandra Murphy
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 23]
INTERNET DRAFT MIME-PEM Interaction February 1994
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: murphy(_at_)tis(_dot_)com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
Tel: +1 415 968 1052
FAX: +1 415 968 2510
email: mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 24]
INTERNET DRAFT MIME-PEM Interaction February 1994
15. Appendix: RFC 1421 Grammar
The following productions are taken from [3]. The grammar presented in
[3] remains the authoritative source for these productions; they are
repeated here for the convenience of the reader.
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld>
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<encbingrp> ::= 4*4<encbinchar>
<encbin> ::= 1*<encbingrp>
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
<IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
; The following items are defined in RFC 1423
; <dekalgid>
; <dekparameters>
; <micalgid>
; <ikalgid>
; <asymsignmic>
; <symencdek>
; <symencmic>
; <asymencdek>
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 25]
INTERNET DRAFT MIME-PEM Interaction February 1994
Table of Contents
1 Status of this Memo ............................................. 1
2 Abstract ........................................................ 1
3 Introduction .................................................... 2
4 Summary of Changes to PEM Specification ......................... 3
5 Use of multipart/security for PEM ............................... 5
5.1 PEM Processing Steps .......................................... 5
5.1.1 Step 1: Local Form .......................................... 6
5.1.2 Step 2: Canonical Form ...................................... 6
5.1.3 Step 3: Security Services ................................... 7
5.2 Use of application/signature Content Type ..................... 7
5.3 Use of application/keys Content Type .......................... 8
6 Definition of New Content Types ................................. 9
6.1 application/pem-request Content Type Definition ............... 9
6.2 application/certificate-data Content Type Definition .......... 10
7 Message Processing .............................................. 12
7.1 Pre-Submission Algorithm ...................................... 12
7.2 Post-Delivery Algorithm ....................................... 13
8 Examples ........................................................ 13
9 Observations .................................................... 19
10 Collected Grammar .............................................. 20
11 Security Considerations ........................................ 22
12 Acknowledgements ............................................... 22
13 References ..................................................... 22
14 Authors' Addresses ............................................. 23
15 Appendix: RFC 1421 Grammar ..................................... 25
Crocker/Freed/Galvin/Murphy/Rose~~~~~~Expires: August 1994
[Page 26]
Network Working Group J. Galvin
INTERNET DRAFT S. Murphy
draft-galvin-mpsec-00.txt S. Crocker
TIS
February 1994
Content-Type: Multipart/Security
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 ``work in progress''.
To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).
2. Abstract
This memo defines a new content type for specifying the application of
security services to MIME message bodies. MIME, an acronym for
"Multipurpose Internet Mail Extensions", defines the format of the
contents of Internet mail messages and provides for multi-part textual
and non-textual message bodies. The new content type is a subtype of
multipart called security. It will contain two body parts: one for the
data to be security enhanced and one for the control information
necessary to apply and remove the security enhancement. Initially, two
control information content types are defined: signature and keys. The
first is to be used when a body part is digitally signed while the
second is to be used when a body part is encrypted.
Galvin/Murphy/Crocker Expires: August 1994 [Page 1]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
3. Introduction
An Internet electronic mail message consists of 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 MIME [2]. MIME does not provide for the
application of security services.
This memo defines a framework whereby security services provided by
other protocols may be used with MIME in a complementary fashion. The
resulting combined service provides security for single-part and multi-
part textual and non-textual messages.
The framework is provided by defining a new subtype of the MIME
multipart content type: security. The content type multipart/security
will have two body parts: one content for the data to be enhanced and
one content for the control information.
This memo defines how to use the framework to provide digital signature
and encryption security services. These services are provided by
defining two control information content types, one for each of the
security services.
4. Definition of Multipart/Security
(1) MIME type name: multipart
(2) MIME subtype name: security
(3) Required parameters: boundary
(4) Optional parameters: none
(5) Encoding considerations: Either 7bit, 8bit, or binary encoding may
be used, depending on the nested part encodings and transport
limitations
(6) Security considerations: Must be treated as opaque while in transit
from an originator to a recipient
The security subtype of multipart is a multipart family [3]. Multipart
families always contain at least two body parts, where the body parts
are dependent and one of the body parts gives instructions for the
processing of all the body parts. In the security subtype, there are
exactly two body parts.
Galvin/Murphy/Crocker Expires: August 1994 [Page 2]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
The first body part contains the security enhanced content. The first
part's content type is defined according to the specification of the
second body part. The specification of the second body part may include
additional processing steps to be performed by an implementation before
(after) the application (removal) of the enhancements, for example, see
the application/keys specification below. As a result, an
implementation may not be able to display the content of this first body
part to a user.
The second body part describes the security enhancement which was
applied to the first body part. The second part's content type is
defined by the specification of the security enhancement.
The syntax and semantics of the boundary parameter is defined in [2].
The entire multipart/security body part must be treated as opaque while
it is in transit from an originator to a recipient. Intermediate
transfer agents must not alter the content of a multipart/security in
any way, including, but not limited to, changing the content transfer
encoding on the body part or any of its encapsulated body parts.
Implementations supporting the origination of multipart/security content
types must provide a mechanism with which a security protocol
implementation may make available the content of each of the body parts.
The choice of mechanism is to be made by the implementation.
Implementations supporting the receipt of multipart/security content
types must locate the second body part and continue processing according
to its content type. If the second body part's content type is not
recognized, an implementation may halt processing of the
multipart/security. If possible, an implementation should continue
processing the first body part, for example, it may attempt to display
it.
The contents of both body parts, with transfer encodings removed, must
be made available to a processor, as specified by the content type of
the second body part. This process must make available to the
implementation the content of the first body part with enhancements
removed. An implementation must continue processing with this de-
enhanced content, according to the specification of the second body part
content type. The content of the second part is not intended to be
consumed by a user.
NOTE: The reason why an implementation may not be able to display
the received form of the first body part is because the application
Galvin/Murphy/Crocker Expires: August 1994 [Page 3]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
of security enhancements may transform a body part. This
transformation will not be described in the MIME headers (Content-
Type: and Content-Transfer-Encoding:) but, rather, will be
described in the content of the second body part. Therefore, an
implementation should wait until the security enhancements have
been removed before attempting to display the content.
5. Definition of Security Service Content Types
This memo defines two additional content types, one each for when a
digital signature is applied to a body part and for when encryption is
applied to a body part. These content types are to be used as the
second body part in a multipart/security.
Each of the content types includes a required parameter of "protocol."
It is used to indicate which of the several protocols that may be used
to provide the digital signature and encryption services. The value of
this parameter is specified by the protocol definition, not by this
memo.
This memo defines the use of these content types inside a
multipart/security content type. Their use outside a multipart/security
is not defined by this memo.
5.1. Application/Signature Content Type
(1) MIME type name: application
(2) MIME subtype name: signature
(3) Required parameters: protocol
(4) Optional parameters: none
(5) Encoding considerations: any valid encoding may be used
(6) Security considerations: none
The content of this body part is comprised of at least the digital
signature of the other body part in the immediately enclosing
multipart/security and the information required to verify the signature
according to the protocol parameter. In order to process this body
part, an implementation must recognize and proceed according to the
protocol parameter. It is an error for the protocol parameter to be
missing.
Galvin/Murphy/Crocker Expires: August 1994 [Page 4]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
The signature protocol is applied only to the content of the other body
part in the enclosing multipart/security, not to its MIME headers. The
content to be digitally signed is transformed into a canonical form and
made available to the signature process according to a local convention.
The signature process must make available to an implementation both the
data content to be inserted in the other body part and the control
information necessary to verify the signature. The MIME headers of the
other body part are not altered by the application of a digital
signature service. The content of the other body part is replaced by
the data content produced by the signature process. The control
information is inserted in this body part.
Transforming the data to be signed into a canonical form is a necessary
and essential step in the digital signature process. The canonical form
must satisfy the property that it is uniquely and unambiguously
representable on both the originator and recipient's host computer.
This is required in order to ensure that both the originator and
recipient have the same data with which to calculate the digital
signature; the originator needs to be able to include the value when
transferring the body part, while the recipient needs to be able to
compare the calculated value with the received value. There are at
least two ways in which the functionality required may be realized.
(1) The data to be signed may be prepared and signed in a
representation that is most suitable for the originator. The
originator can guarantee that this representation of the data will
not be changed if the originator applies a content transfer
encoding to the data. (Recall that multipart content types are
required to have a 7bit representation and that multipart/security
content types must be handled opaquely by intermediate transfer
agents.) Having done so, upon receipt, a recipient will have the
original representation of the data as soon as the encoding is
removed. This method is most effective for non-text content types
because they are more likely to require the application of a
content transfer encoding.
(2) The originator may prepare the data to be signed in a local
representation and then may transform the data into a form that is
most likely to be acceptable to a recipient. This transformed
representation is signed and transfered to a recipient. Having
done so, upon receipt, a recipient will have a representation of
the data suitable for immediate processing. This method is most
effective for text content types because they are less likely to
require the application of a content transfer encoding. When the
content is not encoded, interoperability with non-MIME and non-PEM
Galvin/Murphy/Crocker Expires: August 1994 [Page 5]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
aware recipients is enhanced.
However, body parts representable with the "7bit" transfer encoding
value, present a special problem. Although "7bit" means that the data
is all represented as short lines of US-ASCII data, it does not specify
a universal line delimiter. Specifically, distinct platforms are known
to use carriage return <CR>, line feed <LF>, and the two character
sequence <CR><LF>. The transformation between line delimiters is
normally handled as part of the message transfer protocol, for example,
SMTP.
The application of the digital signature service requires that the same
line delimiter be used by both the originator and the recipient. This
memo specifies that the two character sequence "<CR><LF>" must be used
as the line delimiter. Thus, the canonicalization transformation for
"7bit" contents is required to include the transformation of the local
line delimiter to the two character sequence "<CR><LF>". This
transformation must be performed by both an originator and a recipient.
5.2. Application/Keys Content Type
(1) MIME type name: application
(2) MIME subtype name: keys
(3) Required parameters: protocol
(4) Optional parameters: none
(5) Encoding considerations: any valid encoding may be used
(6) Security considerations: none
The content of this body part is comprised of at least the data
encryption key used to encrypt the other body in the immediately
enclosing multipart/security and the information required to perform the
decryption according to the protocol parameter. In order to process
this body part, an implementation must recognize and proceed according
to the protocol parameter. It is an error for the protocol parameter to
be missing.
The encryption protocol is applied to the entire other body part,
including the MIME headers. The body part to be encrypted is made
available to the encryption process according to a local convention.
The encryption process must make available to an implementation both the
Galvin/Murphy/Crocker Expires: August 1994 [Page 6]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
encrypted data to be inserted in the other body part and the control
information necessary to decrypt it. The encrypted data (comprised of
the entire other body part including its MIME headers) is inserted in
the first body part and is labeled with a content type of
application/octet-stream, which is defined by [2]. The control
information is inserted in the second, application/keys body part.
The MIME headers on the first body part are included in the data to be
encrypted to protect the type of the data that has been encrypted from
disclosure. An implementation that supports the receipt of a
multipart/security body part containing an application/keys body part
must recursively process the data resulting from the decryption.
6. Security Considerations
This entire document is about security.
7. References
[1] David H. Crocker. Standard for the Format of ARPA Internet Text
Messages. RFC 822, University of Delaware, August 1982.
[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet
Mail Extension) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, Bellcore and
Innosoft, September 1993. Obsoletes RFC 1341.
[3] David H. Crocker. Multipart Family Content Types. Work in
Progress.
8. Authors' Address
James M. Galvin
email: galvin(_at_)tis(_dot_)com
Sandra Murphy
email: murphy(_at_)tis(_dot_)com
Steve Crocker
email: crocker(_at_)tis(_dot_)com
Trusted Information Systems, Inc.
3060 Washington Road (Rt 97)
Glenwood, MD 21738
Galvin/Murphy/Crocker Expires: August 1994 [Page 7]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
Tel: +1 301 854 6889
FAX: +1 301 854 5363
Galvin/Murphy/Crocker Expires: August 1994 [Page 8]
INTERNET DRAFT Content-Type: Multipart/Security February 1994
Table of Contents
1 Status of this Memo ............................................. 1
2 Abstract ........................................................ 1
3 Introduction .................................................... 2
4 Definition of Multipart/Security ................................ 2
5 Definition of Security Service Content Types .................... 4
5.1 Application/Signature Content Type ............................ 4
5.2 Application/Keys Content Type ................................. 6
6 Security Considerations ......................................... 7
7 References ...................................................... 7
8 Authors' Address ................................................ 7
Galvin/Murphy/Crocker Expires: August 1994 [Page 9]
binAs2yveHgBB.bin
Description: application/signature