CMS object of type SignedData.
Step 3. The SignedData object is wrapped in a CMS ContentInfo
object.
Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity.
The smime-type parameter for messages using application/pkcs7-mime
with SignedData is "signed-data". The file extension for this type
of message is ".p7m".
A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
3.4.3. Signing Using the multipart/signed Format
This format is a clear-signing format. Recipients without any S/MIME
or CMS processing facilities are able to view the message. It makes
use of the multipart/signed MIME type described in [MIME-SECURE].
The multipart/signed MIME type has two parts. The first part
contains the MIME entity that is signed; the second part contains the
"detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent.
3.4.3.1. The application/pkcs7-signature MIME Type
This MIME type always contains a CMS ContentInfo containing a single
CMS object of type SignedData. The SignedData encapContentInfo
eContent field MUST be absent. The signerInfos field contains the
signatures for the MIME entity.
The file extension for signed-only messages using application/pkcs7-
signature is ".p7s".
3.4.3.2. Creating a multipart/signed Message
Step 1. The MIME entity to be signed is prepared according to
section 3.1, taking special care for clear-signing.
Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type SignedData in which the encapContentInfo
eContent field is absent.
Step 3. The MIME entity is inserted into the first part of a
multipart/signed message with no processing other than that described
in section 3.1.
Step 4. Transfer encoding is applied to the "detached signature" CMS
SignedData object and it is inserted into a MIME entity of type
application/pkcs7-signature.
Step 5. The MIME entity of the application/pkcs7-signature is
inserted into the second part of the multipart/signed entity.
The multipart/signed Content type has two required parameters: the
protocol parameter and the micalg parameter.
The protocol parameter MUST be "application/pkcs7-signature". Note
that quotation marks are required around the protocol parameter
because MIME requires that the "/" character in the parameter value
MUST be quoted.
The micalg parameter allows for one-pass processing when the
signature is being verified. The value of the micalg parameter is
dependent on the message digest algorithm(s) used in the calculation
of the Message Integrity Check. If multiple message digest
algorithms are used they MUST be separated by commas per [MIME-
SECURE]. The values to be placed in the micalg parameter SHOULD be
from the following:
Algorithm Value
used
MD5 md5
SHA-1 sha1
SHA-256 sha256
SHA-384 sha384
SHA-512 sha512
Any other (defined separately in algorithm profile or "unknown"
if not defined)
(Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize.
The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not
currently recommended in S/MIME, and are included here for
completeness.
3.4.3.3. Sample multipart/signed Message
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
This is a clear-signed message.
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--
The content that is digested (the first part of the multipart/signed)
are the bytes:
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
3.5. Creating an Compressed-only Message
This section describes the format for compressing a MIME entity.
Please note that versions of S/MIME prior to 3.1 did not specify any
use of CompressedData, and will not recognize it. The use of a
capability to indicate the ability to receive CompressedData is
described in [CMSCOMPR] and is the preferred method for
compatibility.
Step 1. The MIME entity to be compressed is prepared according to
section 3.1.
Step 2. The MIME entity and other required data is processed into a
CMS object of type CompressedData.
Step 3. The CompressedData object is wrapped in a CMS ContentInfo
object.
Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity.
The smime-type parameter for compressed-only messages is
"compressed-data". The file extension for this type of message is
".p7z".
A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
3.6. Multiple Operations
The signed-only, encrypted-only, and compressed-only MIME formats can
be nested. This works because these formats are all MIME entities
that encapsulate other MIME entities.
An S/MIME implementation MUST be able to receive and process
arbitrarily nested S/MIME within reasonable resource limits of the
recipient computer.
It is possible to apply any of the signing, encrypting, and
compressing operations in any order. It is up to the implementer and
the user to choose. When signing first, the signatories are then
securely obscured by the enveloping. When enveloping first the
signatories are exposed, but it is possible to verify signatures
without removing the enveloping. This can be useful in an
environment were automatic signature verification is desired, as no
private key material is required to verify a signature.
There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but
cannot determine any relationship between the signer and the
unencrypted contents of the message. A recipient of a message that
is signed-then-encrypted can assume that the signed message itself
has not been altered, but that a careful attacker could have changed
the unauthenticated portions of the encrypted message.
When using compression, keep the following guidelines in mind:
- Compression of binary encoded encrypted data is discouraged, since
it will not yield significant compression. Base64 encrypted data
could very well benefit, however.
- If a lossy compression algorithm is used with signing, you will
need to compress first, then sign.
3.7. Creating a Certificate Management Message
The certificate management message or MIME entity is used to
transport certificates and/or certificate revocation lists, such as
in response to a registration request.
Step 1. The certificates and/or certificate revocation lists are
made available to the CMS generating process which creates a CMS
object of type SignedData. The SignedData encapContentInfo eContent
field MUST be absent and signerInfos field MUST be empty.
Step 2. The SignedData object is wrapped in a CMS ContentInfo
object.
Step 3. The ContentInfo object is enclosed in an application/pkcs7-
mime MIME entity.
The smime-type parameter for a certificate management message is
"certs-only". The file extension for this type of message is ".p7c".
3.8. Registration Requests
A sending agent that signs messages MUST have a certificate for the
signature so that a receiving agent can verify the signature. There
are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette,
and so on.
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates. However, S/MIME v3.1 does not
require a particular certificate request mechanism.
3.9. Identifying an S/MIME Message
Because S/MIME takes into account interoperation in non-MIME
environments, several different mechanisms are employed to carry the
type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an
S/MIME message if it matches any of the criteria listed below.
The file suffix in the table below comes from the "name" parameter in
the content-type header, or the "filename" parameter on the content-
disposition header. These parameters that give the file suffix are
not listed below as part of the parameter section.
MIME type: application/pkcs7-mime
parameters: any
file suffix: any
MIME type: multipart/signed
parameters: protocol="application/pkcs7-signature"
file suffix: any
MIME type: application/octet-stream
parameters: any
file suffix: p7m, p7s, p7c, p7z
4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes. This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been
validated or rejected. S/MIME certificate issues are covered in
[CERT31].
At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting
that recipient’s certificate in a signed return message. Receiving
and sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval.
4.1. Key Pair Generation
All generated key pairs MUST be generated from a good source of non-
deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion.
If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
agent or some related administrative utility or function SHOULD
generate RSA key pairs using the following guidelines. A user agent
SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
user agent MUST NOT generate RSA key pairs less than 512 bits long.
Creating keys longer than 1024 bits can cause some older S/MIME
receiving agents to not be able to verify signatures, but gives
better security and is therefore valuable. A receiving agent SHOULD
be able to verify signatures with keys of any size over 512 bits.
Some agents created in the United States have chosen to create 512
bit keys in order to get more advantageous export licenses. However,
512 bit keys are considered by many to be cryptographically insecure.
Implementers SHOULD be aware that multiple (active) key pairs can be
associated with a single individual. For example, one key pair can
be used to support confidentiality, while a different key pair can be
used for authentication.
5. Security Considerations
40-bit encryption is considered weak by most cryptographers. Using
weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the
specification of tripleDES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is
no cryptography. When feasible, sending and receiving agents SHOULD
inform senders and recipients of the relative cryptographic strength
of messages.
It is impossible for most software or people to estimate the value of
a message. Further, it is impossible for most software or people to
estimate the actual cost of decrypting a message that is encrypted
with a key of a particular size. Further, it is quite difficult to
determine the cost of a failed decryption if a recipient cannot
decode a message. Thus, choosing between different key sizes (or
choosing whether to just use plaintext) is also impossible. However,
decisions based on these criteria are made all the time, and
therefore this specification gives a framework for using those
estimates in choosing algorithms.
If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications
channel might be able to determine the contents of the strongly-
encrypted message by decrypting the weakly-encrypted version. In
other words, a sender SHOULD NOT send a copy of a message using
weaker cryptography than they would use for the original of the
message.
Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it.
See RFC 3218 [MMA] for more information about thwarting the adaptive
chosen ciphertext vulnerability in PKCS #1 Version 1.5
implementations.
In some circumstances the use of the Diffie-Hellman key agreement
scheme in a prime order subgroup of a large prime p is vulnerable to
certain attacks known as "small-subgroup" attacks. Methods exist,
however, to prevent these attacks. These methods are described in
RFC 2785 [DHSUB].
A. ASN.1 Module
SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced the by S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the symmetric
-- capabilities understood. Algorithms SHOULD be ordered by
-- preference and grouped by type
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list the OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [CMSALG]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits))
END
B. References
B.1. Normative References
[CERT31] Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate
Handling", RFC 3850, July 2004.
[CHARSETS] Character sets assigned by IANA. See
http://www.iana.org/assignments/character-sets
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS)", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August
1997.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[FIPS180-2] "Secure Hash Signature Standard (SHS)", National
Institute of Standards and Technology (NIST). FIPS
Publication 180-2.
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996.
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One
(ASN.1). 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
B.2. Informative References
[DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman Key Agreement
Method for S/MIME", RFC 2785, March 2000.
[MMA] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218, January 2002.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
and L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.
C. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka.
A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they
made direct contributions to this document.
Tony Capel
Piers Chivers
Dave Crocker
Bill Flanigan
Peter Gutmann
Paul Hoffman
Russ Housley
William Ottaway
John Pawling
Jim Schaad
D. Editor’s Address
Blake Ramsdell
Sendmail, Inc.
704 228th Ave NE #775
Sammamish, WA 98074
EMail: blake@sendmail.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the