signingTime OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
B. References
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[CHARSETS] Character sets assigned by IANA. See
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>.
[CONTDISP] Troost, R., Dorner, S and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC2183, August 1997.
[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards Institute,
1983.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC1321, April
1992.
[MIME-SPEC] The primary definition of MIME.
Freed, N., and N. Borenstein, "MIME Part 1: Format of Internet
Message Bodies", RFC2045, November 1996.
Freed, N., and N. Borenstein, "MIME Part 2: Media Types", RFC2046,
November 1996.
Moore, K., "MIME Part 3: Message Header Extensions for Non-ASCII
Text", RFC2047, November 1996.
Freed, N., Klensin, J., and J. Postel, "MIME Part 4: Registration
Procedures", RFC2048, November 1996.
Freed, N., and N. Borenstein, "MIME Part 5: Conformance Criteria and
Examples", RFC2049, November 1996.
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC1847, October 1995.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
2313, March 1998.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", RFC2315, March 1998.
[PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC2314, March 1998.
[RC2] Rivest, R., "Description of the RC2(r) Encryption Algorithm",
RFC2268, January 1998.
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce,
DRAFT, 31 May 1994.
C. Compatibility with Prior Practice in S/MIME
S/MIME was originally developed by RSA Data Security, Inc. Many
developers implemented S/MIME agents before this document was
published. All S/MIME receiving agents SHOULD make every attempt to
interoperate with these earlier implementations of S/MIME.
C.1 Early MIME Types
Some early implementations of S/MIME agents used the following MIME
types:
application/x-pkcs7-mime
application/x-pkcs7-signature
application/x-pkcs10
In each case, the "x-" subtypes correspond to the subtypes described
in this document without the "x-".
C.2 Profiles
Early S/MIME documentation had two profiles for encryption:
"restricted" and "unrestricted". The difference between these
profiles historically came about due to US Government export
regulations, as described at the end of this section. It is expected
that in the future, there will be few agents that only use the
restricted profile.
Briefly, the restricted profile required the ability to encrypt and
decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-
bit keys. The unrestricted profile required the ability to encrypt
and decrypt using RSA's trade-secret RC2 algorithm in CBC mode with
40-bit keys, and to encrypt and decrypt using tripleDES. The
restricted profile also had non-mandatory suggestions for other
algorithms, but these were not widely implemented.
It is important to note that many current implementations of S/MIME
use the restricted profile.
C.2.1 Historical Reasons for the Existence of Two Encryption Profiles
Due to US Government export regulations, an S/MIME agent which
supports a strong content encryption algorithm such as DES would not
be freely exportable outside of North America. US software
manufacturers have been compelled to incorporate an exportable or
"restricted" content encryption algorithm in order to create a widely
exportable version of their product. S/MIME agents created in the US
and intended for US domestic use (or use under special State
Department export licenses) can utilize stronger, "unrestricted"
content encryption. However, in order to achieve interoperability,
such agents need to support whatever exportable algorithm is
incorporated in restricted S/MIME agents.
The RC2 symmetric encryption algorithm has been approved by the US
Government for "expedited" export licensing at certain key sizes.
Consequently, support for the RC2 algorithm in CBC mode is required
for baseline interoperability in all S/MIME implementations. Support
for other strong symmetric encryption algorithms such as RC5 CBC, DES
CBC and DES EDE3-CBC for content encryption is strongly encouraged
where possible.
D. Request for New MIME Subtypes
D.1 application/pkcs7-mime
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mime
MIME media type name: application
MIME subtype name: pkcs7-mime
Required parameters: none
Optional parameters: name, filename, smime-type
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry data formatted
with PKCS-7, as described in [PKCS-7]
Published specification: RFC2311
Applications which use this media type: Secure Internet mail and
other secure data transports.
Additional information:
File extension(s): .p7m and .p7c
Macintosh File Type Code(s):
Person & email address to contact for further information:
Steve Dusse, spock@rsa.com
Intended usage: COMMON
D.2 application/pkcs7-signature
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-signature
MIME media type name: application
MIME subtype name: pkcs7-signature
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry digital
signatures with PKCS-7, as described in [PKCS-7]
Published specification: RFC2311
Applications which use this media type: Secure Internet mail and
other secure data transports.
Additional information:
File extension(s): .p7s
Macintosh File Type Code(s):
Person & email address to contact for further information:
Steve Dusse, spock@rsa.com
Intended usage: COMMON
D.3 application/pkcs10
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs10
MIME media type name: application
MIME subtype name: pkcs10
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-10]
Interoperability considerations: Designed to carry digital
certificates formatted with PKCS-10, as described in [PKCS-10]
Published specification: RFC2311
Applications which use this media type: Secure Internet mail and
other transports where certificates are required.
Additional information:
File extension(s): .p10
Macintosh File Type Code(s):
Person & email address to contact for further information:
Steve Dusse, spock@rsa.com
Intended usage: COMMON
E. Encapsulating Signed Messages for Internet Transport
The rationale behind the multiple formats for signing has to do with
the MIME subtype defaulting rules of the application and multipart
top-level types, and the behavior of currently deployed gateways and
mail user agents.
Ideally, the multipart/signed format would be the only format used
because it provides a truly backwards compatible way to sign MIME
entities. In a pure MIME environment with very capable user agents,
this would be possible. The world, however, is more complex than
this.
One problem with the multipart/signed format occurs with gateways to
non-MIME environments. In these environments, the gateway will
generally not be S/MIME aware, will not recognize the
multipart/signed type, and will default its treatment to
multipart/mixed as is prescribed by the MIME standard. The real
problem occurs when the gateway also applies conversions to the MIME
structure of the original message that is being signed and is
contained in the first part of the multipart/signed structure, such
as the gateway converting text and attachments to the local format.
Because the signature is over the MIME structure of the original
message, but the original message is now decomposed and transformed,
the signature cannot be verified. Because MIME encoding of a
particular set of body parts can be done in many different ways,
there is no way to reconstruct the original MIME entity over which
the signature was computed.
A similar problem occurs when an attempt is made to combine an
existing user agent with a stand-alone S/MIME facility. Typical user
agents do not have the ability to make a multipart sub-entity
available to a stand-alone application in the same way they make leaf
MIME entities available to "viewer" applications. This user agent
behavior is not required by the MIME standard and thus not widely
implemented. The result is that it is impossible for most user agents
to hand off the entire multipart/signed entity to a stand-alone
application.
E.1 Solutions to the Problem
To work around these two problems, the application/pkcs7-mime type
can be used. When going through a gateway, it will be defaulted to
the MIME type of application/octet-stream and treated as a single
opaque entity. That is, the message will be treated as an attachment
of unknown type, converted into the local representation for an
attachment and thus can be made available to an S/MIME facility
completely intact. A similar result is achieved when a user agent
similarly treats the application/pkcs7-mime MIME entity as a simple
leaf node of the MIME structure and makes it available to viewer
applications.
Another way to work around these problems is to encapsulate the
multipart/signed MIME entity in a MIME entity that will not be
damaged by the gateway. At the time that this memo is being written,
there is a proposal for a MIME entity "application/mime" for this
purpose. However, no implementations of S/MIME use this type of
wrapping.
E.2 Encapsulation in an Non-MIME Environment
While this document primarily addresses the Internet, it is useful to
compose and receive S/MIME secured messages in non-MIME environments.
This is particularly the case when it is desired that security be
implemented end-to-end. Other discussion here addresses the receipt
of S/MIME messages in non-MIME environments. Here the composition of
multipart/signed entities is addressed.
When a message is to be sent in such an environment, the
multipart/signed entity is created as described above. That entity is
then treated as an opaque stream of bits and added to the message as
an attachment. It must have a file name that ends with ".aps", as
this is the sole mechanism for recognizing it as an S/MIME message by
the receiving agent.
When this message arrives in a MIME environment, it is likely to have
a MIME type of application/octet-stream, with MIME parameters giving
the filename for the attachment. If the intervening gateway has
carried the file type, it will end in ".aps" and be recognized as an
S/MIME message.
F. Acknowledgements
Significant contributions to the content of this memo were made by
many people, including Jim Schaad, Jeff Thompson, and Jeff Weinstein.
G. Authors' Addresses
Steve Dusse
RSA Data Security, Inc.
100 Marine Parkway, #500
Redwood City, CA 94065 USA
Phone: (415) 595-8782
EMail: spock@rsa.com
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060
Phone: (408) 426-9827
EMail: phoffman@imc.org
Blake Ramsdell
Worldtalk
13122 NE 20th St., Suite C
Bellevue, WA 98005
Phone: (425) 882-8861
EMail: blaker@deming.com
Laurence Lundblade
QUALCOMM Incorporated
Eudora Division
6455 Lusk Boulevard
San Diego, California 92121-2779
Phone: (800) 238-3672
EMail: lgl@qualcomm.com
Lisa Repka
Netscape Communications Corporation
501 East Middlefield Road
Mountain View, CA 94043
Phone: (415) 254-1900
EMail: repka@netscape.com
H. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.