The security multiparts document has been revised and submitted to the
internet-drafts directory. You should see an announcement here soon.
This was motivated by comments abstracted from this mailing list and
from explicit comments received from folks who read the document in
detail.
The changes have been strictly editorial. Included below are the diffs
between "draft-ietf-pem-sigenc-02.txt" and the version submitted to
internet-drafts. I've eliminated all the page number, header, and
footer differences.
Careful readers will note that two example examples (sic) have been
included: one for multipart/signature and one for multipart/encrypted.
In addition, we've raised the importance of the CRLF canonicalization
specified in the PEM/MIME document by reminding implementors of what
they should already know from the MIME documentation.
That does it. Enjoy,
Jim
34,44c39,49
< 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. The type and contents of the
< control information body parts are determined by the value of the
< protocol parameter of the enclosing multipart/signed or
< multipart/encrypted content type, which is required to be present.
---
This document defines a framework within which security services may be
applied to MIME body parts. 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.
The type and contents of the control information body parts are
determined by the value of the protocol parameter of the enclosing
multipart/signed or multipart/encrypted content type, which is required
to be present.
67,69c72,77
< 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.
---
by other protocols may be used with MIME in a complementary fashion. By
itself, it does not specify security protection. A MIME agent must
include support for both the framework defined here and a mechanism to
interact with a security protocol defined in a separate document. The
resulting combined service provides security for single-part and multi-
part textual and non-textual messages.
74,82c82,86
< 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
---
protected data and one for the control information. The type and
contents of the control information body parts are determined by the
value of the protocol parameter of the enclosing multipart/signed or
multipart/encrypted content type, which is required to be present. By
registering new values for the required protocol parameter, the
86,88c90,94
< parse protected body parts, even when the value of the protocol
< parameter is unrecognized and the body part can not be displayed to the
< user.
---
recognize a security multipart body part and to identify its protected
data and control information body parts. If the value of the protocol
parameter is unrecognized the MIME agent will not be able to process the
security multipart. However, a MIME agent may continue to process any
other body parts that may be present.
112a118,122
A three-step process is described for the origination and reception of
the multipart/signed and multipart/encrypted contents. The details of
the processing performed during each step is left to be specified by the
security protocol being used.
123,124c133
< (5) Encoding considerations: 7bit, 8bit, or binary depending on
< transport requirements and encoding of the digitally signed data
---
(5) Security considerations: Must be treated as opaque while in transit
126,127d134
< (6) Security considerations: Must be treated as opaque while in transit
<
130,134c137,141
< created, including its content type label. The second body part
< contains the control information necessary to verify the digital
< signature. The first body part may contain any valid MIME content type,
< labelled accordingly. The second body part is labelled according to the
< value of the protocol parameter.
---
created, including its MIME headers. The second body part contains the
control information necessary to verify the digital signature. The
first body part may contain any valid MIME content type, labeled
accordingly. The second body part is labeled according to the value of
the protocol parameter.
144c151
< value := type "/" subtype
---
value := <"> type "/" subtype <">
155,157d161
< 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 are
167a173,175
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 are
170,176c178,184
< presence of multiple 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 micalg parameter. If
< multiple MIC algorithms are specified, the purpose and use of the
< multiple algorithms is defined by the protocol. If the MIC algorithm is
< also specified in the control information and the value there does not
< agree with the value in this parameter, it must be treated as an error.
---
use of multiple 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 micalg parameter. If multiple MIC
algorithms are specified, the purpose and use of the multiple algorithms
is defined by the protocol. If the MIC algorithm is also specified in
the control information and the value there does not agree with the
value in this parameter, it must be treated as an error.
186,190c194,199
< 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 of the body part or any of its encapsulated body parts.
---
The entire contents of the multipart/signed container 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 of the body part or any of its encapsulated
body parts.
191a201,206
The signature in a multipart/signed only applies to the material that is
actually within the multipart/signed object. In particular, it does not
apply to any enclosing message material, nor does it apply to entities
that are referenced (e.g. via a MIME message/external-body) by rather
than included in the signed content.
199c214,215
< body part, including an appropriate set of headers.
---
body part in canonical MIME format, including an appropriate set of
MIME headers.
201c217,248
< (2) The body part (content and headers) to be digitally signed is
---
Galvin/Murphy/Crocker/Freed Expires: July 1995 [Page 4]
INTERNET DRAFT Security Multiparts January 1995
In addition, if the multipart/signed object is EVER to be
transferred over the standard Internet SMTP infrastructure, the
resulting MIME body is constrained to 7 bits -- that is, the use of
material requiring either 8bit or binary content-transfer-encoding
is NOT allowed. Such 8bit or binary material MUST be encoded using
either the quoted-printable or base64 encodings.
This requirement exists because it is not generally possible, given
the current characteristics of Internet SMTP, for a message
originator to guarantee that a message will travel only along paths
capable of carrying 8bit or binary material.
SMTP clients normally have the option of either converting the
message to eliminate the use of 8bit or binary encoding or
returning a nondelivery notification to the originator. However,
conversion is not viable in the case of signed objects since
conversion would necessarily invalidate the signature. This leaves
a nondelivery notification as the only available option, which is
not acceptable.
(2) The body part (headers and content) to be digitally signed is
204c251
< in the signature to protect the integrity of the MIME labelling of
---
in the signature to protect the integrity of the MIME labeling of
211,212c258,261
< which the MIME implementation will place in the second body part,
< and the digitally signed body part, which the MIME implementation
---
which the MIME implementation will place in the second body part
and label according to the value of the protocol parameter, and the
digitally signed body part, which the MIME implementation will use
as the first body part.
213a263,267
When receiving a multipart/signed body part, the following sequence of
steps describes the processing necessary to verify the signature or
signatures. It must be emphasized that these steps are descriptive, not
prescriptive, and in no way impose restrictions or requirements on
implementations of this specification.
214a269,271
(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 value of the protocol parameter.
223d276
< will use as the first body part.
225,228c278,280
< 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.
---
Galvin/Murphy/Crocker/Freed Expires: July 1995 [Page 5]
INTERNET DRAFT Security Multiparts January 1995
230,232d281
< (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 value of the protocol parameter.
254c303,306
< 2.2. Definition of Multipart/Encrypted
---
The following example is an illustration of a multipart/signed body
part. It is necessarily incomplete since the control information is
defined by the security protocol, which must be specified in a separate
document.
256c308,309
< (1) MIME type name: multipart
---
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
258c311,312
< (2) MIME subtype name: encrypted
---
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
260c314,315
< (3) Required parameters: boundary, protocol
---
This is some text to be signed although it could be
any type of data, labeled accordingly, of course.
262c317,318
< (4) Optional parameters: none
---
--Signed Boundary
Content-Type: TYPE/STYPE
264,265c320
< (5) Encoding considerations: 7bit, 8bit, or binary depending on
< transport requirements and encoding of the encrypted data
---
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
266a322
--Signed Boundary--
278c338
< (6) Security considerations: none
---
2.2. Definition of Multipart/Encrypted
279a340,349
(1) MIME type name: multipart
(2) MIME subtype name: encrypted
(3) Required parameters: boundary, protocol
(4) Optional parameters: none
(5) Security considerations: none
282,285c352,354
< decrypt the data in the second body part and is labelled 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.
---
decrypt the data in the second body part and is labeled according to the
value of the protocol parameter. The second body part contains the data
which was encrypted and is always labeled application/octet-stream.
295c364
< value := type "/" subtype
---
value := <"> type "/" subtype <">
308c377,378
< MIME body part, including an appropriate set of headers.
---
MIME body part in canonical MIME format, including an appropriate
set of MIME headers.
310c380
< (2) The body part (content and headers) to be encrypted is prepared for
---
(2) The body part (headers and content) to be encrypted is prepared for
313,314d382
< encryption to protect from disclosure the MIME labelling of the
< data that is encrypted.
316,322d383
< (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
332a393,403
encryption to protect from disclosure the MIME labeling 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 label
according to the value of the protocol parameter, 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
337,339c408,411
< 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.
---
of steps describes the processing necessary to decrypt the enclosed
data. It must be emphasized that these steps are descriptive, not
prescriptive, and in no way impose restrictions or requirements on
implementations of this specification.
354c426,428
< etc.
---
etc. Implementors should note that the data, if any, of a
failed decryption process is pretty much guaranteed to be
garbage.
371a456,481
The following example is an illustration of a multipart/encrypted body
part. It is necessarily incomplete since the control information is
defined by the security protocol, which must be specified in a separate
document.
Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: TYPE/STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Type: text/plain; charset="us-ascii"
All of this indented text, including the indented headers,
would be unreadable since it would have been encrypted by
the protocol "TYPE/STYPE". Also, this encrypted data could
be any type of data, labeled accordingly, of course.
--Encrypted Boundary--
374,377c484,488
< This document 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,
---
This document defines a framework within which security services may be
applied to MIME body parts. A minimal MIME implementation will be able
to recognize multipart/signed and multipart/encrypted body parts and be
able to identify the protected data and control information body parts
within them.
378a490,492
Complete support for security services requires the MIME agent to
recognize the value of the protocol parameter and to continue processing
based on its value. The value of the protocol parameter is the same
388,390c503
< respectively, as indicated above. Their definition must be included in
< the specification defining the use of the security protocol indicated in
< the protocol parameter.
---
value used to label the content type of the control information.
391a505,509
The value of the protocol parameter and the resulting processing
required must be specified in the document defining the security
protocol used. That document must also precisely specify the contents
of the control information body part.
394,398c512,517
< It is recognized that many cryptographic techniques require a mechanism
< for distributing the cryptographic keys used in support of their
< services. As a result, many security protocols will define two
< additional body parts: one for the purpose of requesting cryptographic
< keys and one for the purpose of distributing cryptographic keys.
---
This specification recognizes that the complete specification of a
MIME-based security protocol must include a mechanism for distributing
the cryptographic material used in support of the security services.
For example, a digital signature service implemented with asymmetric
cryptography requires that a signer's public key be available to the
signee.
399a519,526
One possible mechanism for distributing cryptographic material is to
define two additional body parts: one for the purpose of requesting
cryptographic information and one for the purpose of returning the
cryptographic information requested. The specification of a security
protocol may include a definition of two such body parts or it may
specify an alternate mechanism for the distribution of cryptographic
material.
408,409c535,536
< David H. Crocker suggested the use of a multipart structure for MIME-PEM
< interaction.
---
David H. Crocker suggested the use of a multipart structure for the MIME
and PEM interaction.
421d547
< 8. Authors' Addresses
423,424d548
< Jim Galvin
< email: galvin(_at_)tis(_dot_)com
426,427d549
< Sandy Murphy
< email: sandy(_at_)tis(_dot_)com
429,430d550
< Steve Crocker
< email: crocker(_at_)tis(_dot_)com
432d551
< Trusted Information Systems
433a553,555
Galvin/Murphy/Crocker/Freed Expires: July 1995 [Page 10]
INTERNET DRAFT Security Multiparts January 1995
435a558
8. Authors' Addresses
436a560,561
Jim Galvin
email: galvin(_at_)tis(_dot_)com
438,440c563,564
< Galvin/Murphy/Crocker/Freed Expires: May 1995 [Page 8]
<
< INTERNET DRAFT Security Multiparts November 1994
---
Sandy Murphy
email: sandy(_at_)tis(_dot_)com
442c566
<
---
Trusted Information Systems
447a572,579
Steve Crocker
CyberCash, Inc.
2086 Hunters Crest Way
Vienna, VA 22181
Tel: +1 703 620 1222
Fax: +1 703 391 2651
email: crocker(_at_)cybercash(_dot_)com
506,512c621,627
< 2.2 Definition of Multipart/Encrypted ............................ 5
< 3 Definition of Control Information Content Types ................ 7
< 4 Definition of Key Management Content Types ..................... 8
< 5 Security Considerations ........................................ 8
< 6 Acknowledgements ............................................... 8
< 7 References ..................................................... 8
< 8 Authors' Addresses ............................................. 8
---
2.2 Definition of Multipart/Encrypted ............................ 7
3 Definition of Control Information Content Types ................ 9
4 Definition of Key Management Content Types ..................... 10
5 Security Considerations ........................................ 10
6 Acknowledgements ............................................... 10
7 References ..................................................... 10
8 Authors' Addresses ............................................. 11