WDIFF

draft-ietf-pem-sigenc-01.txt --> draft-ietf-pem-sigenc-02.txt

Network Working Group Jim Galvin
INTERNET DRAFT Sandy Murphy
draft-ietf-pem-sigenc-01.txt
draft-ietf-pem-sigenc-02.txt Steve Crocker
Ned Freed
July
November 1994

Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted

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).

Abstract

This document defines two new content types 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 types are
subtypes of multipart: signed and encrypted. Each will contain two body
parts: one for the protected data and one for the control information
necessary to remove the protection. Two control information content
types are defined, application/signature and application/keys, one for
each of the multiparts. The first is to be used when a body part is
digitally signed; the second is to be used when a body part is
encrypted. The type and contents of each of the multipart
control information body parts is are determined by the value of the
protocol parameter, parameter of the enclosing multipart/signed or
multipart/encrypted content type, which is required to be present.

Galvin/Murphy/Crocker/Freed Expires: January May 1995 [Page 1]

INTERNET DRAFT Security Multiparts July November 1994

1. 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 RFC822 [1], whilst the body, if structured, is
defined according to MIME [2]. The basic MIME specification does not
provide specific security protection.

This document defines a framework whereby security protection 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 two new security subtypes of the
MIME multipart content type: signed and encrypted. In each of the
security subtypes, there are exactly two related body parts: one for the
protected data and one for the control information. This should allow
the framework to be used by all protocols providing signature and
encryption services.

A three-step process is specified for the origination and reception of
the multipart contents. The details of the processing performed during
each step is specified by the protocol being used.

By registering new values for the required protocol parameter, the
framework is easily extended to accommodate a variety of protocols. If
necessary, additional content types may be defined

A MIME agent that includes support for this framework will be able to
parse protected body parts, even when the control
information carried in each value of the multiparts defined in this
specification.

4. protocol
parameter is unrecognized and the body part can not be displayed to the
user.

2. Definition of Security Subtypes of Multipart

The multipart/signed content type specifies how to support
authentication and integrity services via digital signature. The
control information is carried in a new content type:
application/signature. the second of the two required body
parts.

The multipart/encrypted content type specifies how to support
confidentiality via encryption. The control information is carried in a
new content type: application/keys.

4.1. Definition
the first of Multipart/Signed

(1) MIME type name: multipart the two required body parts.

Galvin/Murphy/Crocker/Freed Expires: January May 1995 [Page 2]

INTERNET DRAFT Security Multiparts July November 1994

2.1. Definition of Multipart/Signed

(1) MIME type name: multipart

(2) MIME subtype name: signed

(3) Required parameters: boundary, protocol, and hashalg micalg

(4) Optional parameters: none

(5) Encoding considerations: 7bit, 8bit, or binary depending on
transport requirements and encoding of the digitally signed data

(6) Security considerations: Must be treated as opaque while in transit

The multipart/signed content type contains exactly two body parts. The
first body part is the body part over which the digital signature was
created, including its content type label. The second body part
contains the control information necessary to verify the digital
signature and is
signature. The first body part may contain any valid MIME content type,
labelled accordingly. Its content The second body part is defined labelled according to the
value of the protocol parameter. This document includes the
specification of one content type for the control information, which is
intended to be suitable

The attribute token for most protocols: application/signature.

When using the protocol parameter the attribute token is "protocol", i.e.,

parameter := "protocol" "=" value

Valid

The value token is comprised of the type and sub-type tokens of the
Content-Type: header of the second body part, i.e.,

value := type "/" subtype

where the type and subtype tokens will be maintained are defined by the Internet Assigned Numbers
Authority (IANA). MIME [2]
specification. The semantics of the protocol parameter are defined
according to its value.

When using the hashalg parameter the

The attribute token for the micalg parameter is "hashalg", "micalg", i.e.,

parameter := "hashalg" "micalg" "=" value

The Message Integrity Check (MIC) is the name given to the quantity
computed over the body part with a message digest or hash function, in
support of the digital signature service. Valid value tokens will be maintained by the IANA. are

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 3]

INTERNET DRAFT Security Multiparts November 1994

defined by the specification for the value of the protocol parameter.
The value may be a comma (",") separated list of tokens, indicating the
presence of multiple signatures. MIC algorithms. As a result, the comma (",")
character is explicitly excluded from the list of characters that may be
included in a token used as a value of the hashalg micalg parameter. If
multiple hash MIC algorithms are specified, the purpose and use of the
multiple algorithms is defined by the protocol. If the hash MIC algorithm is
also specified in the control information and the value there does not
agree with the value in this parameter, the control information value it must be given
precedence.

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 3]

INTERNET DRAFT Security Multiparts July 1994 treated as an error.

NOTE: The presence of the hashalg micalg parameter on the
multipart/signed content type header is explicitly intended to
support one-pass processing. MIME implementations may locate
the second body part by inputting the first body part and
computing the specified hash MIC values until the boundary
identifying the second body part is found.

The entire multipart/signed body part must be treated as opaque while it
is in transit from an originator to a recipient. Intermediate message
transfer agents must not alter the content of a multipart/signed in any
way, including, but not limited to, changing the content transfer
encoding on of the body part or any of its encapsulated body parts.

When creating a multipart/signed body part, the following sequence of
steps describes the processing necessary. It must be emphasized that
these steps are descriptive, not prescriptive, and in no way impose
restrictions or requirements on implementations of this specification.

(1) The contents content of the body part to be protected is prepared according
to a local convention. The contents are content is then transformed into a MIME
body part, including an appropriate set of headers. The
result of this transformation must be a MIME body part that could
be submitted for delivery.

(2) The body part (content and headers) to be digitally signed is
prepared for signature according to the value of the protocol
parameter. The MIME headers of the signed body part are included
in the signature to protect the integrity of the type MIME labelling of
the data that is signed.

(3) The prepared body part is made available to the signature creation
process according to a local convention. The signature creation
process must make available to a MIME implementation two data
streams: the control information necessary to verify the signature,
which the MIME implementation will place in the second body part,
and the digitally signed body part, which the MIME implementation

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 4]

INTERNET DRAFT Security Multiparts November 1994

will use as the first body part.

When receiving a multipart/signed body part, the following sequence of
steps describes the processing necessary. It must be emphasized that
these steps are descriptive, not prescriptive, and in no way impose
restrictions or requirements on implementations of this specification.

(1) The first body part and the control information in the second body
part must be prepared for the signature verification process
according to the

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 4]

INTERNET DRAFT Security Multiparts July 1994 value of the protocol parameter.

(2) The prepared body parts must be made available to the signature
verification process according to a local convention. The
signature verification process must make available to the MIME
implementation the result of the signature verification and the
body part that was digitally signed.

NOTE: The result of the signature verification is likely to
include a testament of the success or failure of the
verification. Also, in the usual case, the body part
returned after signature verification will be the same as
the body part that was received. We do not insist that
this be the case to allow for protocols that may modify the
body part during the signature processing.

(3) The result of the signature verification process is made available
to the user and the MIME implementation continues processing with
the verified body part, i.e., the body part returned by the
signature verification process.

4.2.

2.2. Definition of Multipart/Encrypted

(1) MIME type name: multipart

(2) MIME subtype name: encrypted

(3) Required parameters: boundary, protocol

(4) Optional parameters: none

(5) Encoding considerations: 7bit, 8bit, or binary depending on
transport requirements and encoding of the encrypted data

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 5]

INTERNET DRAFT Security Multiparts November 1994

(6) Security considerations: none

The multipart/encrypted content type contains exactly two body parts.
The first body part contains the control information necessary to
decrypt the data in the second body part and is labelled accordingly.
Its content is defined according to
the value of the protocol parameter. The second body part contains the
data which was encrypted and is always labelled application/octet-stream. This document includes the
specification of one content type application/octet-
stream.

The attribute token for the control information:
application/keys.

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 5]

INTERNET DRAFT Security Multiparts July 1994

When using the protocol parameter the attribute token is "protocol", i.e.,

parameter := "protocol" "=" value

Valid

The value token is comprised of the type and sub-type tokens will be maintained of the
Content-Type: header of the first body part, i.e.,

value := type "/" subtype

where the type and subtype tokens are defined by the Internet Assigned Numbers
Authority (IANA). MIME [2]
specification. The semantics of the protocol parameter are defined
according to its value.

When creating a multipart/encrypted body part, the following sequence of
steps describes the processing necessary. It must be emphasized that
these steps are descriptive, not prescriptive, and in no way impose
restrictions or requirments requirements on implementations of this specification.

(1) The contents of the body part to be protected is prepared according
to a local convention. The contents are then transformed into a
MIME body part, including an appropriate set of headers. The
result of this transformation must be a MIME body part that could
be submitted for delivery.

(2) The body part (content and headers) to be encrypted is prepared for
encryption according to the value of the protocol parameter. The
MIME headers of the encrypted body part are included in the
encryption to protect from disclosure the type MIME labelling of the
data that is encrypted.

(3) The prepared body part is made available to the encryption process
according to a local convention. The encryption process must make
available to a MIME implementation two data streams: the control
information necessary to decrypt the body part, which the MIME
implementation will place in the first body part, and the encrypted
body part, which the MIME implementation will place in the second
body part and label application/octet-stream. Thus, when used in a

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 6]

INTERNET DRAFT Security Multiparts November 1994

multipart/encrypted, the application/octet-stream data is comprised
of a nested MIME body part.

When receiving a multipart/encrypted body part, the following sequence
of steps describes the processing necessary. It must be emphasized that
these steps are descriptive, not prescriptive, and in no way impose
restrictions or requirements on implementations of this specification.

(1) The second body part and the control information in the first body
part must be prepared for the decryption process according to the
value of the protocol parameter.

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 6]

INTERNET DRAFT Security Multiparts July 1994

(2) The prepared body parts must be made available to the decryption
process according to a local convention. The decryption process
must make available to the MIME implementation the result of the
decryption and the decrypted form of the encrypted body part.

NOTE: The result of the decryption process is likely to
include a testament of the success or failure of the
decryption. Failure may be due to an inability to locate
the proper decryption key or the proper recipient field,
etc.

(3) The result of the decryption process is made available to the user
and the MIME implementation continues processing with the decrypted
body part, i.e., the body part returned by the decryption process.

NOTE: A MIME implementation will not be able to display the
received form of the second body part because the
application of encryption will transform the 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 first body
part. Therefore, an implementation should wait until the
encryption has been removed before attempting to display
the content.

3. Definition of Security Subtypes of Application Control Information Content Types

This document defines requires the definition of 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 in multipart/signed and multipart/encrypted body parts, respectively.

This document defines

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 7]

INTERNET DRAFT Security Multiparts November 1994

respectively, as indicated above. Their definition must be included in
the specification defining the use of these content types inside their
multipart content types. Their use outside a multipart content is not
defined by this document.

5.1. Application/Signature Content Type

(1) MIME type name: application

(2) MIME subtype name: signature

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 7]

INTERNET DRAFT Security Multiparts July 1994

(3) Required parameters: none

(4) Optional parameters: none

(5) Encoding considerations: any valid encoding may be used

(6) Security considerations: none

This content type is used on the second body part of an enclosing
multipart/signed. It is comprised of the digital signature of the data,
which is the first body part of the enclosing multipart/signed, and the
information required to verify that signature. In order to process this
body part an implementation must recognize and proceed according to security protocol indicated in
the protocol parameter parameter.

4. Definition of the enclosing multipart/signed. Key Management Content Types

It is an error recognized that many cryptographic techniques require a mechanism
for distributing the protocol parameter to be missing in the enclosing
multipart/signed body part.

Included in the signature verification information will be the hash
algorithm cryptographic keys used during the signature creation process. The hash
algorithm identified in this body part must match the algorithm
identified in the hashalg parameter support of the enclosing multipart/signed.
If it does not, a user agent should identify the discrepancy to their
services. As a user
and may choose to either halt or continue processing, giving precedence
to the algorithm identified in this body part.

5.2. Application/Keys Content Type

(1) MIME type name: application

(2) MIME subtype name: keys

(3) Required parameters: none

(4) Optional parameters: none

(5) Encoding considerations: any valid encoding may be used

(6) Security considerations: none

This content type is used on the first result, many security protocols will define two
additional body part of an enclosing
multipart/encrypted. It is comprised of the data encryption key used to
encrypt the data, located in parts: one for the second body part purpose of the enclosing
multipart/encrypted, and the information required to perform the
decryption. In order to process this body part, an implementation must
recognize requesting cryptographic
keys and proceed according to the protocol parameter of the

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 8]

INTERNET DRAFT Security Multiparts July 1994

enclosing multipart/encrypted. It is an error one for the protocol
parameter to be missing in the enclosing multipart/encrypted body part.

6. purpose of distributing cryptographic keys.

5. Security Considerations

This specification describes an enhancement to MIME to support signed
and encrypted body parts. In that context this entire document is about
security.

6. Acknowledgements

David H. Crocker suggested the use of a multipart structure for MIME-PEM
interaction.

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.

8. Authors' Addresses

Jim Galvin
email: galvin@tis.com

Sandy Murphy
email: sandy@tis.com

Steve Crocker
email: crocker@tis.com

Trusted Information Systems

Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 8]

INTERNET DRAFT Security Multiparts November 1994

3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363

Ned Freed
Innosoft International, Inc.
250
1050 East Garvey Avenue South
West First Street, Suite 240
Claremont, Covina, CA 91711

Galvin/Murphy/Crocker/Freed Expires: January 1995 [Page 9]

INTERNET DRAFT Security Multiparts July 1994 91790
Tel: +1 909 624 7907 818 919 3600
FAX: +1 909 621 5319 818 919 3614
email: ned@innosoft.com

Galvin/Murphy/Crocker/Freed Expires: January May 1995 [Page 10] 9]

INTERNET DRAFT Security Multiparts July November 1994

Table of Contents

Status of this Memo ............................................. 1
2
Abstract ........................................................ 1
3
1 Introduction .................................................... ................................................... 2
2
4 Definition of Security Subtypes of Multipart .................... ................... 2
4.1
2.1 Definition of Multipart/Signed ................................ 2
4.2 ............................... 3
2.2 Definition of Multipart/Encrypted ............................. 5 ............................ 5
3 Definition of Security Subtypes of Application .................. 7
5.1 Application/Signature Control Information Content Type ............................ Types ................ 7
5.2 Application/Keys
4 Definition of Key Management Content Type ................................. Types ..................... 8
6
5 Security Considerations ......................................... 9
7 ........................................ 8
6 Acknowledgements ................................................ 9 ............................................... 8
7 References ...................................................... 9
9 ..................................................... 8
8 Authors' Addresses .............................................. 9 ............................................. 8

Galvin/Murphy/Crocker/Freed Expires: January May 1995 [Page 11] 10]

----