idnits 2.17.1
draft-ietf-smime-3851bis-10.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 27, 2009) is 5472 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '0' on line 1991
-- Looks like a reference, but probably isn't: '1' on line 1992
-- Looks like a reference, but probably isn't: '2' on line 1993
== Outdated reference: A later version (-11) exists of
draft-ietf-smime-3850bis-10
-- Possible downref: Non-RFC (?) normative reference: ref. 'CHARSETS'
** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC
5652)
-- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-3'
-- Obsolete informational reference (is this intentional?): RFC 2630 (ref.
'SMIMEv3') (Obsoleted by RFC 3369, RFC 3370)
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 S/MIME WG B. Ramsdell
2 Internet Draft Brute Squad Labs
3 Intended Status: Standard Track S. Turner
4 Obsoletes: 3851 (when approved) IECA
5 Expires: October 27, 2009 April 27, 2009
7 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
8 Message Specification
9 draft-ietf-smime-3851bis-10.txt
11 Status of this Memo
13 This Internet-Draft is submitted to IETF in full conformance with the
14 provisions of BCP 78 and BCP 79. This document may contain material
15 from IETF Documents or IETF Contributions published or made publicly
16 available before November 10, 2008. The person(s) controlling the
17 copyright in some of this material may not have granted the IETF
18 Trust the right to allow modifications of such material outside the
19 IETF Standards Process. Without obtaining an adequate license from
20 the person(s) controlling the copyright in such materials, this
21 document may not be modified outside the IETF Standards Process, and
22 derivative works of it may not be created outside the IETF Standards
23 Process, except to format it for publication as an RFC or to
24 translate it into languages other than English.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html
42 This Internet-Draft will expire on October 27, 2009.
44 Copyright Notice
46 Copyright (c) 2009 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents in effect on the date of
51 publication of this document (http://trustee.ietf.org/license-info).
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document.
55 Abstract
57 This document defines Secure/Multipurpose Internet Mail Extensions
58 (S/MIME) version 3.2. S/MIME provides a consistent way to send and
59 receive secure MIME data. Digital signatures provide authentication,
60 message integrity, and non-repudiation with proof of origin.
61 Encryption provides data confidentiality. Compression can be used to
62 reduce data size. This document obsoletes RFC 3851.
64 Discussion
66 This draft is being discussed on the 'ietf-smime' mailing list. To
67 subscribe, send a message to ietf-smime-request@imc.org with the
68 single word subscribe in the body of the message. There is a Web site
69 for the mailing list at .
71 Table of Contents
73 1. Introduction...................................................3
74 1.1. Specification Overview....................................4
75 1.2. Definitions...............................................5
76 1.3. Conventions used in this document.........................5
77 1.4. Compatibility with Prior Practice of S/MIME...............6
78 1.5. Changes From S/MIME v3 to S/MIME v3.1.....................6
79 1.6. Changes Since S/MIME v3.1.................................7
80 2. CMS Options....................................................8
81 2.1. DigestAlgorithmIdentifier.................................8
82 2.2. SignatureAlgorithmIdentifier..............................9
83 2.3. KeyEncryptionAlgorithmIdentifier..........................9
84 2.4. General Syntax...........................................10
85 2.5. Attributes and the SignerInfo Type.......................11
86 2.6. SignerIdentifier SignerInfo Type.........................15
87 2.7. ContentEncryptionAlgorithmIdentifier.....................15
88 3. Creating S/MIME Messages......................................18
89 3.1. Preparing the MIME Entity for Signing, Enveloping or
90 Compressing..............................................18
92 3.2. The application/pkcs7-mime Media Type....................22
93 3.3. Creating an Enveloped-only Message.......................25
94 3.4. Creating a Signed-only Message...........................26
95 3.5. Creating a Compressed-only Message.......................29
96 3.6. Multiple Operations......................................30
97 3.7. Creating a Certificate Management Message................31
98 3.8. Registration Requests....................................31
99 3.9. Identifying an S/MIME Message............................32
100 4. Certificate Processing........................................32
101 4.1. Key Pair Generation......................................32
102 4.2. Signature Generation.....................................33
103 4.3. Signature Verification...................................33
104 4.4. Encryption...............................................34
105 4.5. Decryption...............................................34
106 5. IANA Considerations...........................................34
107 5.1. Media Type for application/pkcs7-mime....................35
108 5.2. Media Type for application/pkcs7-signature...............35
109 6. Security Considerations.......................................36
110 7. References....................................................38
111 7.1. Normative References.....................................38
112 7.2. Informative References...................................41
113 Appendix A. ASN.1 Module.........................................43
114 Appendix B. Moving S/MIME v2 Message Specification to Historic
115 Status...............................................45
116 Appendix C. Acknowledgments......................................45
117 Authors' Addresses...............................................45
119 1. Introduction
121 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
122 consistent way to send and receive secure MIME data. Based on the
123 popular Internet MIME standard, S/MIME provides the following
124 cryptographic security services for electronic messaging
125 applications: authentication, message integrity and non-repudiation
126 of origin (using digital signatures), and data confidentiality (using
127 encryption). As a supplementary service, S/MIME provides for message
128 compression.
130 S/MIME can be used by traditional mail user agents (MUAs) to add
131 cryptographic security services to mail that is sent, and to
132 interpret cryptographic security services in mail that is received.
133 However, S/MIME is not restricted to mail; it can be used with any
134 transport mechanism that transports MIME data, such as HTTP or SIP.
135 As such, S/MIME takes advantage of the object-based features of MIME
136 and allows secure messages to be exchanged in mixed-transport
137 systems.
139 Further, S/MIME can be used in automated message transfer agents that
140 use cryptographic security services that do not require any human
141 intervention, such as the signing of software-generated documents and
142 the encryption of FAX messages sent over the Internet.
144 1.1. Specification Overview
146 This document describes a protocol for adding cryptographic signature
147 and encryption services to MIME data. The MIME standard [MIME-SPEC]
148 provides a general structure for the content of Internet messages and
149 allows extensions for new content type based applications.
151 This specification defines how to create a MIME body part that has
152 been cryptographically enhanced according to the Cryptographic
153 Message Syntax (CMS) RFC 3852 and RFC 4853 [CMS], which is derived
154 from PKCS #7 [PKCS-7]. This specification also defines the
155 application/pkcs7-mime media type that can be used to transport those
156 body parts.
158 This document also discusses how to use the multipart/signed media
159 type defined in [MIME-SECURE] to transport S/MIME signed messages.
160 multipart/signed is used in conjunction with the application/pkcs7-
161 signature media type, which is used to transport a detached S/MIME
162 signature.
164 In order to create S/MIME messages, an S/MIME agent MUST follow the
165 specifications in this document, as well as the specifications listed
166 in the Cryptographic Message Syntax document [CMS], [CMSALG],
167 [RSAPSS], [RSAOAEP], and [CMS-SHA2].
169 Throughout this specification, there are requirements and
170 recommendations made for how receiving agents handle incoming
171 messages. There are separate requirements and recommendations for
172 how sending agents create outgoing messages. In general, the best
173 strategy is to "be liberal in what you receive and conservative in
174 what you send". Most of the requirements are placed on the handling
175 of incoming messages while the recommendations are mostly on the
176 creation of outgoing messages.
178 The separation for requirements on receiving agents and sending
179 agents also derives from the likelihood that there will be S/MIME
180 systems that involve software other than traditional Internet mail
181 clients. S/MIME can be used with any system that transports MIME
182 data. An automated process that sends an encrypted message might not
183 be able to receive an encrypted message at all, for example. Thus,
184 the requirements and recommendations for the two types of agents are
185 listed separately when appropriate.
187 1.2. Definitions
189 For the purposes of this specification, the following definitions
190 apply.
192 ASN.1: Abstract Syntax Notation One, as defined in ITU-T
193 Recommendation X.680 [X.680].
195 BER: Basic Encoding Rules for ASN.1, as defined in ITU-T
196 Recommendation X.690 [X.690].
198 Certificate: A type that binds an entity's name to a public key with
199 a digital signature.
201 DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
202 Recommendation X.690 [X.690].
204 7-bit data: Text data with lines less than 998 characters long, where
205 none of the characters have the 8th bit set, and there are no NULL
206 characters. and occur only as part of a end of
207 line delimiter.
209 8-bit data: Text data with lines less than 998 characters, and where
210 none of the characters are NULL characters. and occur only
211 as part of a end of line delimiter.
213 Binary data: Arbitrary data.
215 Transfer Encoding: A reversible transformation made on data so 8-bit
216 or binary data can be sent via a channel that only transmits 7-bit
217 data.
219 Receiving agent: Software that interprets and processes S/MIME CMS
220 objects, MIME body parts that contain CMS content types, or both.
222 Sending agent: Software that creates S/MIME CMS content types, MIME
223 body parts that contain CMS content types, or both.
225 S/MIME agent: User software that is a receiving agent, a sending
226 agent, or both.
228 1.3. Conventions used in this document
230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232 document are to be interpreted as described in [MUSTSHOULD].
234 We define some additional terms here:
236 SHOULD+ This term means the same as SHOULD. However, the authors
237 expect that a requirement marked as SHOULD+ will be promoted at
238 some future time to be a MUST.
240 SHOULD- This term means the same as SHOULD. However, the authors
241 expect that a requirement marked as SHOULD- will be demoted to a
242 MAY in a future version of this document.
244 MUST- This term means the same as MUST. However, the authors
245 expect that this requirement will no longer be a MUST in a future
246 document. Although its status will be determined at a later
247 time, it is reasonable to expect that if a future revision of a
248 document alters the status of a MUST- requirement, it will remain
249 at least a SHOULD or a SHOULD-.
251 1.4. Compatibility with Prior Practice of S/MIME
253 S/MIME version 3.2 agents ought to attempt to have the greatest
254 interoperability possible with agents for prior versions of S/MIME.
255 S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
256 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
257 inclusive and RFC 5035[SMIMEv3], and S/MIME version 3.1 is described
258 in RFC 3850, RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035
259 [SMIMEv3.1]. RFC 2311 also has historical information about the
260 development of S/MIME.
262 1.5. Changes From S/MIME v3 to S/MIME v3.1
264 The RSA public key algorithm was changed to a MUST implement key
265 wrapping algorithm, and the Diffie-Hellman algorithm changed to a
266 SHOULD implement.
268 The AES symmetric encryption algorithm has been included as a SHOULD
269 implement.
271 The RSA public key algorithm was changed to a MUST implement
272 signature algorithm.
274 Ambiguous language about the use of "empty" SignedData messages to
275 transmit certificates was clarified to reflect that transmission of
276 certificate revocation lists is also allowed.
278 The use of binary encoding for some MIME entities is now explicitly
279 discussed.
281 Header protection through the use of the message/rfc822 media type
282 has been added.
284 Use of the CompressedData CMS type is allowed, along with required
285 media type and file extension additions.
287 1.6. Changes Since S/MIME v3.1
289 Editorial changes, e.g., replaced "MIME type" with "media type",
290 content-type with Content-Type.
292 Moved "Conventions Used in This Document" to Section 1.3. Added
293 definitions for SHOULD+, SHOULD-, and MUST-.
295 Sec 1.1 and Appendix A: Added references to RFCs for RSASSA-PSS,
296 RSAES-OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers
297 Clarification to CMS reference.
299 Sec 1.2: Updated references to ASN.1 to X.680 and BER and DER to
300 X.690.
302 Sec 1.4: Added references to S/MIME MSG 3.1 RFCs.
304 Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made
305 SHOULD-.
307 Sec 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and
308 DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1,
309 and RSA with MD5 changed to SHOULD-, and RSASSA-PSS with SHA-256
310 added as SHOULD+. Also added note about what S/MIME v3.1 clients
311 support.
313 Sec 2.3 (key encryption): DH changed to SHOULD- and RSAES-OAEP added
314 as SHOULD+. Elaborated requirements for key wrap algorithm.
316 Sec 2.5.1: Added requirement that receiving agents MUST support both
317 GeneralizedTime and UTCTime.
319 Sec 2.5.2: Replaced reference "sha1WithRSAEncryption" with
320 "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and
321 deleted the RC5 example.
323 Sec 2.5.2.1: Deleted entire section (discussed deprecated RC2).
325 Sec 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
327 Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and
328 AES-256 CBC SHOULD+, tripleDES now SHOULD-.
330 Sec 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1
331 to 2.7.1.2.
333 Sec 3.1.1: Removed text about MIME character sets.
335 Sec 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". Update OID
336 example to use AES-128 CBC oid.
338 Sec 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1.
340 Sec 4: Updated reference to CERT v3.2.
342 Sec 4.1: Updated RSA and DSA key size discussion. Moved last four
343 sentences to security considerations. Updated reference to randomness
344 requirements for security.
346 Sec 5: Added IANA registration templates to update media type
347 registry to point to this document as opposed to RFC 2311.
349 Sec 6: Updated Security Considerations.
351 Sec 7: Moved references from Appendix B to this section. Updated
352 references. Added informational references to SMIMEv2, SMIMEv3, and
353 SMIMEv3.1.
355 App B: Added Appendix B to move S/MIME v2 to historic status.
357 2. CMS Options
359 CMS allows for a wide variety of options in content, attributes, and
360 algorithm support. This section puts forth a number of support
361 requirements and recommendations in order to achieve a base level of
362 interoperability among all S/MIME implementations. [CMSALG] and [CMS-
363 SHA2] provides additional details regarding the use of the
364 cryptographic algorithms. [ESS] provides additional details
365 regarding the use of additional attributes.
367 2.1. DigestAlgorithmIdentifier
369 Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and
370 SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5
371 [CMSALG] for the purpose of providing backward compatibility with
372 MD5-digested S/MIME v2 SignedData objects.
374 2.2. SignatureAlgorithmIdentifier
376 Receiving agents:
378 - MUST support RSA with SHA-256
380 - SHOULD+ support DSA with SHA-256
382 - SHOULD+ support RSASSA-PSS with SHA-256
384 - SHOULD- support RSA with SHA-1
386 - SHOULD- support DSA with SHA-1
388 - SHOULD- support RSA with MD5.
390 Sending agents:
392 - MUST support RSA with SHA-256
394 - SHOULD+ support DSA with SHA-256
396 - SHOULD+ support RSASSA-PSS with SHA-256
398 - SHOULD- support RSA with SHA-1 or DSA with SHA-1
400 - SHOULD- support RSA with MD5.
402 See section 4.1 for information on key size and algorithm references.
404 Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 and
405 rsaEncryption and might not implement sha256withRSAEncryption. Note
406 that S/MIME v3 clients might only implement signing or signature
407 verification using id-dsa-with-sha1, and might also use id-dsa as an
408 AlgorithmIdentifier in this field. Receiving clients SHOULD
409 recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
410 clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
411 that S/MIME v2 clients are only required to verify digital signatures
412 using the rsaEncryption algorithm with SHA-1 or MD5, and might not
413 implement id-dsa-with-sha1 or id-dsa at all.
415 2.3. KeyEncryptionAlgorithmIdentifier
417 Receiving and sending agents:
419 - MUST support RSA Encryption, as specified in [CMSALG]
420 - SHOULD+ support RSAES-OAEP, as specified in [RSAOAEP]
422 - SHOULD- support DH ephemeral-static mode, as specified
423 in [CMSALG].
425 When DH ephemeral-static is used, a key wrap algorithm is also
426 specified in the KeyEncryptionAlgorithmIdentifier [CMS]. The
427 underlying encryption functions for the key wrap and content
428 encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for
429 the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
430 with AES 128 content encryption algorithm). As AES 128 CBC is the
431 mandatory to implement content encryption algorithm, the AES-128 key
432 wrap algorithm MUST also be supported when DH ephemeral-static is
433 used.
435 Note that S/MIME v3.1 clients might only implement key encryption and
436 decryption using the rsaEncryption algorithm. Note that S/MIME v3
437 clients might only implement key encryption and decryption using the
438 Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only
439 capable of decrypting content-encryption keys using the rsaEncryption
440 algorithm.
442 2.4. General Syntax
444 There are several CMS content types. Of these, only the Data,
445 SignedData, EnvelopedData, and CompressedData content types are
446 currently used for S/MIME.
448 2.4.1. Data Content Type
450 Sending agents MUST use the id-data content type identifier to
451 identify the "inner" MIME message content. For example, when
452 applying a digital signature to MIME data, the CMS SignedData
453 encapContentInfo eContentType MUST include the id-data object
454 identifier and the media type MUST be stored in the SignedData
455 encapContentInfo eContent OCTET STRING (unless the sending agent is
456 using multipart/signed, in which case the eContent is absent, per
457 section 3.4.3 of this document). As another example, when applying
458 encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
459 contentType MUST include the id-data object identifier and the
460 encrypted MIME content MUST be stored in the EnvelopedData
461 encryptedContentInfo encryptedContent OCTET STRING.
463 2.4.2. SignedData Content Type
465 Sending agents MUST use the SignedData content type to apply a
466 digital signature to a message or, in a degenerate case where there
467 is no signature information, to convey certificates. Applying a
468 signature to a message provides authentication, message integrity,
469 and non-repudiation of origin.
471 2.4.3. EnvelopedData Content Type
473 This content type is used to apply data confidentiality to a message.
474 A sender needs to have access to a public key for each intended
475 message recipient to use this service.
477 2.4.4. CompressedData Content Type
479 This content type is used to apply data compression to a message.
480 This content type does not provide authentication, message integrity,
481 non-repudiation, or data confidentiality, and is only used to reduce
482 the message's size.
484 See section 3.6 for further guidance on the use of this type in
485 conjunction with other CMS types.
487 2.5. Attributes and the SignerInfo Type
489 The SignerInfo type allows the inclusion of unsigned and signed
490 attributes along with a signature.
492 Receiving agents MUST be able to handle zero or one instance of each
493 of the signed attributes listed here. Sending agents SHOULD generate
494 one instance of each of the following signed attributes in each
495 S/MIME message:
497 - signingTime (section 2.5.1 in this document)
499 - sMIMECapabilities (section 2.5.2 in this document)
501 - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
503 - id-messageDigest (section 11.2 in [CMS])
505 - id-contentType (section 11.1 in [CMS])
507 Further, receiving agents SHOULD be able to handle zero or one
508 instance of the signingCertificate and signingCertificatev2 signed
509 attributes, as defined in section 5 of RFC 2634 [ESS] and section 3
510 of RFC 5035 [ESS].
512 Sending agents SHOULD generate one instance of the signingCertificate
513 or signingCertificatev2 signed attribute in each SignerInfo
514 structure.
516 Additional attributes and values for these attributes might be
517 defined in the future. Receiving agents SHOULD handle attributes or
518 values that they do not recognize in a graceful manner.
520 Interactive sending agents that include signed attributes that are
521 not listed here SHOULD display those attributes to the user, so that
522 the user is aware of all of the data being signed.
524 2.5.1. Signing-Time Attribute
526 The signing-time attribute is used to convey the time that a message
527 was signed. The time of signing will most likely be created by a
528 message originator and therefore is only as trustworthy as the
529 originator.
531 Sending agents MUST encode signing time through the year 2049 as
532 UTCTime; signing times in 2050 or later MUST be encoded as
533 GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
534 interpret the year field (YY) as follows:
536 If YY is greater than or equal to 50, the year is interpreted as
537 19YY; if YY is less than 50, the year is interpreted as 20YY.
539 Receiving agents MUST be able to process signing-time attributes that
540 are encoded in either UTCTime or GeneralizedTime.
542 2.5.2. SMIMECapabilities Attribute
544 The SMIMECapabilities attribute includes signature algorithms (such
545 as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
546 CBC"), and key encipherment algorithms (such as "rsaEncryption").
547 There are also several identifiers which indicate support for other
548 optional features such as binary encoding and compression. The
549 SMIMECapabilities were designed to be flexible and extensible so
550 that, in the future, a means of identifying other capabilities and
551 preferences such as certificates can be added in a way that will not
552 cause current clients to break.
554 If present, the SMIMECapabilities attribute MUST be a
555 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
556 SignedAttributes as a SET OF Attribute. The SignedAttributes in a
557 signerInfo MUST NOT include multiple instances of the
558 SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
559 Attribute to include attrValues SET OF AttributeValue. A
560 SMIMECapabilities attribute MUST only include a single instance of
561 AttributeValue. There MUST NOT be zero or multiple instances of
562 AttributeValue present in the attrValues SET OF AttributeValue.
564 The semantics of the SMIMECapabilities attribute specify a partial
565 list as to what the client announcing the SMIMECapabilities can
566 support. A client does not have to list every capability it
567 supports, and need not list all its capabilities so that the
568 capabilities list doesn't get too long. In an SMIMECapabilities
569 attribute, the object identifiers (OIDs) are listed in order of their
570 preference, but SHOULD be separated logically along the lines of
571 their categories (signature algorithms, symmetric algorithms, key
572 encipherment algorithms, etc.)
574 The structure of the SMIMECapabilities attribute is to facilitate
575 simple table lookups and binary comparisons in order to determine
576 matches. For instance, the DER-encoding for the SMIMECapability for
577 AES-128 CBC MUST be identically encoded regardless of the
578 implementation. Because of the requirement for identical encoding,
579 individuals documenting algorithms to be used in the
580 SMIMECapabilities attribute SHOULD explicitly document the correct
581 byte sequence for the common cases.
583 For any capability, the associated parameters for the OID MUST
584 specify all of the parameters necessary to differentiate between two
585 instances of the same algorithm.
587 The OIDs that correspond to algorithms SHOULD use the same OID as the
588 actual algorithm, except in the case where the algorithm usage is
589 ambiguous from the OID. For instance, in an earlier specification,
590 rsaEncryption was ambiguous because it could refer to either a
591 signature algorithm or a key encipherment algorithm. In the event
592 that an OID is ambiguous, it needs to be arbitrated by the maintainer
593 of the registered SMIMECapabilities list as to which type of
594 algorithm will use the OID, and a new OID MUST be allocated under the
595 smimeCapabilities OID to satisfy the other use of the OID.
597 The registered SMIMECapabilities list specifies the parameters for
598 OIDs that need them, most notably key lengths in the case of
599 variable-length symmetric ciphers. In the event that there are no
600 differentiating parameters for a particular OID, the parameters MUST
601 be omitted, and MUST NOT be encoded as NULL. Additional values for
602 the SMIMECapabilities attribute might be defined in the future.
603 Receiving agents MUST handle a SMIMECapabilities object that has
604 values that it does not recognize in a graceful manner.
606 Section 2.7.1 explains a strategy for caching capabilities.
608 2.5.3. Encryption Key Preference Attribute
610 The encryption key preference attribute allows the signer to
611 unambiguously describe which of the signer's certificates has the
612 signer's preferred encryption key. This attribute is designed to
613 enhance behavior for interoperating with those clients that use
614 separate keys for encryption and signing. This attribute is used to
615 convey to anyone viewing the attribute which of the listed
616 certificates is appropriate for encrypting a session key for future
617 encrypted messages.
619 If present, the SMIMEEncryptionKeyPreference attribute MUST be a
620 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
621 SignedAttributes as a SET OF Attribute. The SignedAttributes in a
622 signerInfo MUST NOT include multiple instances of the
623 SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
624 for Attribute to include attrValues SET OF AttributeValue. A
625 SMIMEEncryptionKeyPreference attribute MUST only include a single
626 instance of AttributeValue. There MUST NOT be zero or multiple
627 instances of AttributeValue present in the attrValues SET OF
628 AttributeValue.
630 The sending agent SHOULD include the referenced certificate in the
631 set of certificates included in the signed message if this attribute
632 is used. The certificate MAY be omitted if it has been previously
633 made available to the receiving agent. Sending agents SHOULD use
634 this attribute if the commonly used or preferred encryption
635 certificate is not the same as the certificate used to sign the
636 message.
638 Receiving agents SHOULD store the preference data if the signature on
639 the message is valid and the signing time is greater than the
640 currently stored value. (As with the SMIMECapabilities, the clock
641 skew SHOULD be checked and the data not used if the skew is too
642 great.) Receiving agents SHOULD respect the sender's encryption key
643 preference attribute if possible. This, however, represents only a
644 preference and the receiving agent can use any certificate in
645 replying to the sender that is valid.
647 Section 2.7.1 explains a strategy for caching preference data.
649 2.5.3.1. Selection of Recipient Key Management Certificate
651 In order to determine the key management certificate to be used when
652 sending a future CMS EnvelopedData message for a particular
653 recipient, the following steps SHOULD be followed:
655 - If an SMIMEEncryptionKeyPreference attribute is found in a
656 SignedData object received from the desired recipient, this
657 identifies the X.509 certificate that SHOULD be used as the X.509
658 key management certificate for the recipient.
660 - If an SMIMEEncryptionKeyPreference attribute is not found in a
661 SignedData object received from the desired recipient, the set of
662 X.509 certificates SHOULD be searched for a X.509 certificate
663 with the same subject name as the signer of a X.509 certificate
664 which can be used for key management.
666 - Or use some other method of determining the user's key management
667 key. If a X.509 key management certificate is not found, then
668 encryption cannot be done with the signer of the message. If
669 multiple X.509 key management certificates are found, the S/MIME
670 agent can make an arbitrary choice between them.
672 2.6. SignerIdentifier SignerInfo Type
674 S/MIME v3.2 implementations MUST support both issuerAndSerialNumber
675 as well as subjectKeyIdentifier. Messages that use the
676 subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
678 It is important to understand that some certificates use a value for
679 subjectKeyIdentifier that is not suitable for uniquely identifying a
680 certificate. Implementations MUST be prepared for multiple
681 certificates for potentially different entities to have the same
682 value for subjectKeyIdentifier, and MUST be prepared to try each
683 matching certificate during signature verification before indicating
684 an error condition.
686 2.7. ContentEncryptionAlgorithmIdentifier
688 Sending and receiving agents:
690 - MUST support encryption and decryption with AES-128 CBC [CMSAES]
692 - SHOULD+ support encryption and decryption with AES-192 CBC and
693 AES-256 CBC [CMSAES]
695 - SHOULD- support encryption and decryption with DES EDE3 CBC,
696 hereinafter called "tripleDES" [CMSALG].
698 2.7.1. Deciding Which Encryption Method To Use
700 When a sending agent creates an encrypted message, it has to decide
701 which type of encryption to use. The decision process involves using
702 information garnered from the capabilities lists included in messages
703 received from the recipient, as well as out-of-band information such
704 as private agreements, user preferences, legal restrictions, and so
705 on.
707 Section 2.5.2 defines a method by which a sending agent can
708 optionally announce, among other things, its decrypting capabilities
709 in its order of preference. The following method for processing and
710 remembering the encryption capabilities attribute in incoming signed
711 messages SHOULD be used.
713 - If the receiving agent has not yet created a list of capabilities
714 for the sender's public key, then, after verifying the signature
715 on the incoming message and checking the timestamp, the receiving
716 agent SHOULD create a new list containing at least the signing
717 time and the symmetric capabilities.
719 - If such a list already exists, the receiving agent SHOULD verify
720 that the signing time in the incoming message is greater than the
721 signing time stored in the list and that the signature is valid.
722 If so, the receiving agent SHOULD update both the signing time
723 and capabilities in the list. Values of the signing time that
724 lie far in the future (that is, a greater discrepancy than any
725 reasonable clock skew), or a capabilities list in messages whose
726 signature could not be verified, MUST NOT be accepted.
728 The list of capabilities SHOULD be stored for future use in creating
729 messages.
731 Before sending a message, the sending agent MUST decide whether it is
732 willing to use weak encryption for the particular data in the
733 message. If the sending agent decides that weak encryption is
734 unacceptable for this data, then the sending agent MUST NOT use a
735 weak algorithm. The decision to use or not use weak encryption
736 overrides any other decision in this section about which encryption
737 algorithm to use.
739 Sections 2.7.1.1 through 2.7.1.2 describe the decisions a sending
740 agent SHOULD use in deciding which type of encryption will be applied
741 to a message. These rules are ordered, so the sending agent SHOULD
742 make its decision in the order given.
744 2.7.1.1. Rule 1: Known Capabilities
746 If the sending agent has received a set of capabilities from the
747 recipient for the message the agent is about to encrypt, then the
748 sending agent SHOULD use that information by selecting the first
749 capability in the list (that is, the capability most preferred by the
750 intended recipient) that the sending agent knows how to encrypt. The
751 sending agent SHOULD use one of the capabilities in the list if the
752 agent reasonably expects the recipient to be able to decrypt the
753 message.
755 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
757 If the following two conditions are met:
759 - the sending agent has no knowledge of the encryption capabilities
760 of the recipient, and
762 - the sending agent has no knowledge of the version of S/MIME of the
763 recipient,
765 then the sending agent SHOULD use AES-128 because it is a stronger
766 algorithm and is required by S/MIME v3.2. If the sending agent
767 chooses not to use AES-128 in this step, it SHOULD use tripleDES.
769 2.7.2. Choosing Weak Encryption
771 All algorithms that use 40 bit keys are considered by many to be weak
772 encryption. A sending agent that is controlled by a human SHOULD
773 allow a human sender to determine the risks of sending data using a
774 weak encryption algorithm before sending the data, and possibly allow
775 the human to use a stronger encryption method such as tripleDES or
776 AES.
778 2.7.3. Multiple Recipients
780 If a sending agent is composing an encrypted message to a group of
781 recipients where the encryption capabilities of some of the
782 recipients do not overlap, the sending agent is forced to send more
783 than one message. Please note that if the sending agent chooses to
784 send a message encrypted with a strong algorithm, and then send the
785 same message encrypted with a weak algorithm, someone watching the
786 communications channel could learn the contents of the strongly-
787 encrypted message simply by decrypting the weakly-encrypted message.
789 3. Creating S/MIME Messages
791 This section describes the S/MIME message formats and how they are
792 created. S/MIME messages are a combination of MIME bodies and CMS
793 content types. Several media types as well as several CMS content
794 types are used. The data to be secured is always a canonical MIME
795 entity. The MIME entity and other data, such as certificates and
796 algorithm identifiers, are given to CMS processing facilities which
797 produce a CMS object. Finally, the CMS object is wrapped in MIME.
798 The Enhanced Security Services for S/MIME [ESS] document provides
799 descriptions of how nested, secured S/MIME messages are formatted.
800 ESS provides a description of how a triple-wrapped S/MIME message is
801 formatted using multipart/signed and application/pkcs7-mime for the
802 signatures.
804 S/MIME provides one format for enveloped-only data, several formats
805 for signed-only data, and several formats for signed and enveloped
806 data. Several formats are required to accommodate several
807 environments, in particular for signed messages. The criteria for
808 choosing among these formats are also described.
810 The reader of this section is expected to understand MIME as
811 described in [MIME-SPEC] and [MIME-SECURE].
813 3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing
815 S/MIME is used to secure MIME entities. A MIME entity can be a sub-
816 part, sub-parts of a message, or the whole message with all its sub-
817 parts. A MIME entity that is the whole message includes only the
818 MIME message headers and MIME body, and does not include the RFC-822
819 header. Note that S/MIME can also be used to secure MIME entities
820 used in applications other than Internet mail. If protection of the
821 RFC-822 header is required, the use of the message/rfc822 media type
822 is explained later in this section.
824 The MIME entity that is secured and described in this section can be
825 thought of as the "inside" MIME entity. That is, it is the
826 "innermost" object in what is possibly a larger MIME message.
827 Processing "outside" MIME entities into CMS content types is
828 described in Section 3.2, 3.4, and elsewhere.
830 The procedure for preparing a MIME entity is given in [MIME-SPEC].
831 The same procedure is used here with some additional restrictions
832 when signing. Description of the procedures from [MIME-SPEC] are
833 repeated here, but it is suggested that the reader refer to that
834 document for the exact procedure. This section also describes
835 additional requirements.
837 A single procedure is used for creating MIME entities that are to
838 have any combination of signing, enveloping, and compressing applied.
839 Some additional steps are recommended to defend against known
840 corruptions that can occur during mail transport that are of
841 particular importance for clear-signing using the multipart/signed
842 format. It is recommended that these additional steps be performed
843 on enveloped messages, or signed and enveloped messages, so that the
844 message can be forwarded to any environment without modification.
846 These steps are descriptive rather than prescriptive. The
847 implementer is free to use any procedure as long as the result is the
848 same.
850 Step 1. The MIME entity is prepared according to the local
851 conventions.
853 Step 2. The leaf parts of the MIME entity are converted to
854 canonical form.
856 Step 3. Appropriate transfer encoding is applied to the leaves
857 of the MIME entity.
859 When an S/MIME message is received, the security services on the
860 message are processed, and the result is the MIME entity. That MIME
861 entity is typically passed to a MIME-capable user agent where it is
862 further decoded and presented to the user or receiving application.
864 In order to protect outer, non-content related message header fields
865 (for instance, the "Subject", "To", "From" and "Cc" fields), the
866 sending client MAY wrap a full MIME message in a message/rfc822
867 wrapper in order to apply S/MIME security services to these header
868 fields. It is up to the receiving client to decide how to present
869 this "inner" header along with the unprotected "outer" header.
871 When an S/MIME message is received, if the top-level protected MIME
872 entity has a Content-Type of message/rfc822, it can be assumed that
873 the intent was to provide header protection. This entity SHOULD be
874 presented as the top-level message, taking into account header
875 merging issues as previously discussed.
877 3.1.1. Canonicalization
879 Each MIME entity MUST be converted to a canonical form that is
880 uniquely and unambiguously representable in the environment where the
881 signature is created and the environment where the signature will be
882 verified. MIME entities MUST be canonicalized for enveloping and
883 compressing as well as signing.
885 The exact details of canonicalization depend on the actual media type
886 and subtype of an entity, and are not described here. Instead, the
887 standard for the particular media type SHOULD be consulted. For
888 example, canonicalization of type text/plain is different from
889 canonicalization of audio/basic. Other than text types, most types
890 have only one representation regardless of computing platform or
891 environment which can be considered their canonical representation.
892 In general, canonicalization will be performed by the non-security
893 part of the sending agent rather than the S/MIME implementation.
895 The most common and important canonicalization is for text, which is
896 often represented differently in different environments. MIME
897 entities of major type "text" MUST have both their line endings and
898 character set canonicalized. The line ending MUST be the pair of
899 characters , and the charset SHOULD be a registered charset
900 [CHARSETS]. The details of the canonicalization are specified in
901 [MIME-SPEC].
903 Note that some charsets such as ISO-2022 have multiple
904 representations for the same characters. When preparing such text
905 for signing, the canonical representation specified for the charset
906 MUST be used.
908 3.1.2. Transfer Encoding
910 When generating any of the secured MIME entities below, except the
911 signing using the multipart/signed format, no transfer encoding is
912 required at all. S/MIME implementations MUST be able to deal with
913 binary MIME objects. If no Content-Transfer-Encoding header field is
914 present, the transfer encoding is presumed to be 7BIT.
916 S/MIME implementations SHOULD however use transfer encoding described
917 in section 3.1.3 for all MIME entities they secure. The reason for
918 securing only 7-bit MIME entities, even for enveloped data that are
919 not exposed to the transport, is that it allows the MIME entity to be
920 handled in any environment without changing it. For example, a
921 trusted gateway might remove the envelope, but not the signature, of
922 a message, and then forward the signed message on to the end
923 recipient so that they can verify the signatures directly. If the
924 transport internal to the site is not 8-bit clean, such as on a wide-
925 area network with a single mail gateway, verifying the signature will
926 not be possible unless the original MIME entity was only 7-bit data.
928 S/MIME implementations which "know" that all intended recipient(s)
929 are capable of handling inner (all but the outermost) binary MIME
930 objects SHOULD use binary encoding as opposed to a 7-bit-safe
931 transfer encoding for the inner entities. The use of a 7-bit-safe
932 encoding (such as base64) would unnecessarily expand the message
933 size. Implementations MAY "know" that recipient implementations are
934 capable of handling inner binary MIME entities either by interpreting
935 the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
936 agreement, or by other means.
938 If one or more intended recipients are unable to handle inner binary
939 MIME objects, or if this capability is unknown for any of the
940 intended recipients, S/MIME implementations SHOULD use transfer
941 encoding described in section 3.1.3 for all MIME entities they
942 secure.
944 3.1.3. Transfer Encoding for Signing Using multipart/signed
946 If a multipart/signed entity is ever to be transmitted over the
947 standard Internet SMTP infrastructure or other transport that is
948 constrained to 7-bit text, it MUST have transfer encoding applied so
949 that it is represented as 7-bit text. MIME entities that are 7-bit
950 data already need no transfer encoding. Entities such as 8-bit text
951 and binary data can be encoded with quoted-printable or base-64
952 transfer encoding.
954 The primary reason for the 7-bit requirement is that the Internet
955 mail transport infrastructure cannot guarantee transport of 8-bit or
956 binary data. Even though many segments of the transport
957 infrastructure now handle 8-bit and even binary data, it is sometimes
958 not possible to know whether the transport path is 8-bit clean. If a
959 mail message with 8-bit data were to encounter a message transfer
960 agent that can not transmit 8-bit or binary data, the agent has three
961 options, none of which are acceptable for a clear-signed message:
963 - The agent could change the transfer encoding; this would
964 invalidate the signature.
966 - The agent could transmit the data anyway, which would most likely
967 result in the 8th bit being corrupted; this too would invalidate
968 the signature.
970 - The agent could return the message to the sender.
972 [MIME-SECURE] prohibits an agent from changing the transfer encoding
973 of the first part of a multipart/signed message. If a compliant
974 agent that can not transmit 8-bit or binary data encounters a
975 multipart/signed message with 8-bit or binary data in the first part,
976 it would have to return the message to the sender as undeliverable.
978 3.1.4. Sample Canonical MIME Entity
980 This example shows a multipart/mixed message with full transfer
981 encoding. This message contains a text part and an attachment. The
982 sample message text includes characters that are not US-ASCII and
983 thus need to be transfer encoded. Though not shown here, the end of
984 each line is . The line ending of the MIME headers, the
985 text, and transfer encoded parts, all MUST be .
987 Note that this example is not of an S/MIME message.
989 Content-Type: multipart/mixed; boundary=bar
991 --bar
992 Content-Type: text/plain; charset=iso-8859-1
993 Content-Transfer-Encoding: quoted-printable
995 =A1Hola Michael!
997 How do you like the new S/MIME specification?
999 It's generally a good idea to encode lines that begin with
1000 From=20because some mail transport agents will insert a greater-
1001 than (>) sign, thus invalidating the signature.
1003 Also, in some cases it might be desirable to encode any =20
1004 trailing whitespace that occurs on lines in order to ensure =20
1005 that the message signature is not invalidated when passing =20
1006 a gateway that modifies such whitespace (like BITNET). =20
1008 --bar
1009 Content-Type: image/jpeg
1010 Content-Transfer-Encoding: base64
1012 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
1013 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
1014 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
1015 HOxEa44b+EI=
1017 --bar--
1019 3.2. The application/pkcs7-mime Media Type
1021 The application/pkcs7-mime media type is used to carry CMS content
1022 types including EnvelopedData, SignedData, and CompressedData. The
1023 details of constructing these entities are described in subsequent
1024 sections. This section describes the general characteristics of the
1025 application/pkcs7-mime media type.
1027 The carried CMS object always contains a MIME entity that is prepared
1028 as described in section 3.1 if the eContentType is id-data. Other
1029 contents MAY be carried when the eContentType contains different
1030 values. See [ESS] for an example of this with signed receipts.
1032 Since CMS content types are binary data, in most cases base-64
1033 transfer encoding is appropriate, in particular, when used with SMTP
1034 transport. The transfer encoding used depends on the transport
1035 through which the object is to be sent, and is not a characteristic
1036 of the media type.
1038 Note that this discussion refers to the transfer encoding of the CMS
1039 object or "outside" MIME entity. It is completely distinct from, and
1040 unrelated to, the transfer encoding of the MIME entity secured by the
1041 CMS object, the "inside" object, which is described in section 3.1.
1043 Because there are several types of application/pkcs7-mime objects, a
1044 sending agent SHOULD do as much as possible to help a receiving agent
1045 know about the contents of the object without forcing the receiving
1046 agent to decode the ASN.1 for the object. The Content-Type header
1047 field of all application/pkcs7-mime objects SHOULD include the
1048 optional "smime-type" parameter, as described in the following
1049 sections.
1051 3.2.1. The name and filename Parameters
1053 For the application/pkcs7-mime, sending agents SHOULD emit the
1054 optional "name" parameter to the Content-Type field for compatibility
1055 with older systems. Sending agents SHOULD also emit the optional
1056 Content-Disposition field [CONTDISP] with the "filename" parameter.
1057 If a sending agent emits the above parameters, the value of the
1058 parameters SHOULD be a file name with the appropriate extension:
1060 Media Type File Extension
1061 application/pkcs7-mime (SignedData, EnvelopedData) .p7m
1062 application/pkcs7-mime (degenerate SignedData .p7c
1063 certificate management message)
1064 application/pkcs7-mime (CompressedData) .p7z
1065 application/pkcs7-signature (SignedData) .p7s
1067 In addition, the file name SHOULD be limited to eight characters
1068 followed by a three letter extension. The eight character filename
1069 base can be any distinct name; the use of the filename base "smime"
1070 SHOULD be used to indicate that the MIME entity is associated with
1071 S/MIME.
1073 Including a file name serves two purposes. It facilitates easier use
1074 of S/MIME objects as files on disk. It also can convey type
1075 information across gateways. When a MIME entity of type
1076 application/pkcs7-mime (for example) arrives at a gateway that has no
1077 special knowledge of S/MIME, it will default the entity's media type
1078 to application/octet-stream and treat it as a generic attachment,
1079 thus losing the type information. However, the suggested filename
1080 for an attachment is often carried across a gateway. This often
1081 allows the receiving systems to determine the appropriate application
1082 to hand the attachment off to, in this case, a stand-alone S/MIME
1083 processing application. Note that this mechanism is provided as a
1084 convenience for implementations in certain environments. A proper
1085 S/MIME implementation MUST use the media types and MUST NOT rely on
1086 the file extensions.
1088 3.2.2. The smime-type parameter
1090 The application/pkcs7-mime content type defines the optional "smime-
1091 type" parameter. The intent of this parameter is to convey details
1092 about the security applied (signed or enveloped) along with
1093 information about the contained content. This specification defines
1094 the following smime-types.
1096 Name CMS type Inner Content
1097 enveloped-data EnvelopedData id-data
1098 signed-data SignedData id-data
1099 certs-only SignedData none
1100 compressed-data CompressedData id-data
1102 In order for consistency to be obtained with future specifications,
1103 the following guidelines SHOULD be followed when assigning a new
1104 smime-type parameter.
1106 1. If both signing and encryption can be applied to the content,
1107 then two values for smime-type SHOULD be assigned "signed-*" and
1108 "enveloped-*". If one operation can be assigned then this can be
1109 omitted. Thus since "certs-only" can only be signed, "signed-"
1110 is omitted.
1112 2. A common string for a content OID SHOULD be assigned. We use
1113 "data" for the id-data content OID when MIME is the inner
1114 content.
1116 3. If no common string is assigned, then the common string of
1117 "OID." is recommended (for example,
1118 "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
1120 It is explicitly intended that this field be a suitable hint for mail
1121 client applications to indicate whether a message is "signed" or
1122 "enveloped" without having to tunnel into the CMS payload.
1124 3.3. Creating an Enveloped-only Message
1126 This section describes the format for enveloping a MIME entity
1127 without signing it. It is important to note that sending enveloped
1128 but not signed messages does not provide for data integrity. It is
1129 possible to replace ciphertext in such a way that the processed
1130 message will still be valid, but the meaning can be altered.
1132 Step 1. The MIME entity to be enveloped is prepared according to
1133 section 3.1.
1135 Step 2. The MIME entity and other required data is processed
1136 into a CMS object of type EnvelopedData. In addition to
1137 encrypting a copy of the content-encryption key for each
1138 recipient, a copy of the content-encryption key SHOULD be
1139 encrypted for the originator and included in the EnvelopedData
1140 (see [CMS] Section 6).
1142 Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo
1143 object.
1145 Step 4. The ContentInfo object is inserted into an
1146 application/pkcs7-mime MIME entity.
1148 The smime-type parameter for enveloped-only messages is "enveloped-
1149 data". The file extension for this type of message is ".p7m".
1151 A sample message would be:
1153 Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
1154 name=smime.p7m
1155 Content-Transfer-Encoding: base64
1156 Content-Disposition: attachment; filename=smime.p7m
1158 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
1159 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
1160 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1161 0GhIGfHfQbnj756YT64V
1163 3.4. Creating a Signed-only Message
1165 There are two formats for signed messages defined for S/MIME:
1167 - application/pkcs7-mime with SignedData; and,
1169 - multipart/signed.
1171 In general, the multipart/signed form is preferred for sending, and
1172 receiving agents MUST be able to handle both.
1174 3.4.1. Choosing a Format for Signed-only Messages
1176 There are no hard-and-fast rules when a particular signed-only format
1177 is chosen because it depends on the capabilities of all the receivers
1178 and the relative importance of receivers with S/MIME facilities being
1179 able to verify the signature versus the importance of receivers
1180 without S/MIME software being able to view the message.
1182 Messages signed using the multipart/signed format can always be
1183 viewed by the receiver whether they have S/MIME software or not. They
1184 can also be viewed whether they are using a MIME-native user agent or
1185 they have messages translated by a gateway. In this context, "be
1186 viewed" means the ability to process the message essentially as if it
1187 were not a signed message, including any other MIME structure the
1188 message might have.
1190 Messages signed using the SignedData format cannot be viewed by a
1191 recipient unless they have S/MIME facilities. However, the
1192 SignedData format protects the message content from being changed by
1193 benign intermediate agents. Such agents might do line wrapping or
1194 content-transfer encoding changes which would break the signature.
1196 3.4.2. Signing Using application/pkcs7-mime with SignedData
1198 This signing format uses the application/pkcs7-mime media type. The
1199 steps to create this format are:
1201 Step 1. The MIME entity is prepared according to section 3.1.
1203 Step 2. The MIME entity and other required data is processed
1204 into a CMS object of type SignedData.
1206 Step 3. The SignedData object is wrapped in a CMS ContentInfo
1207 object.
1209 Step 4. The ContentInfo object is inserted into an
1210 application/pkcs7-mime MIME entity.
1212 The smime-type parameter for messages using application/pkcs7-mime
1213 with SignedData is "signed-data". The file extension for this type
1214 of message is ".p7m".
1216 A sample message would be:
1218 Content-Type: application/pkcs7-mime; smime-type=signed-data;
1219 name=smime.p7m
1220 Content-Transfer-Encoding: base64
1221 Content-Disposition: attachment; filename=smime.p7m
1223 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
1224 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
1225 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
1226 6YT64V0GhIGfHfQbnj75
1228 3.4.3. Signing Using the multipart/signed Format
1230 This format is a clear-signing format. Recipients without any S/MIME
1231 or CMS processing facilities are able to view the message. It makes
1232 use of the multipart/signed media type described in [MIME-SECURE].
1233 The multipart/signed media type has two parts. The first part
1234 contains the MIME entity that is signed; the second part contains the
1235 "detached signature" CMS SignedData object in which the
1236 encapContentInfo eContent field is absent.
1238 3.4.3.1. The application/pkcs7-signature Media Type
1240 This media type always contains a CMS ContentInfo containing a single
1241 CMS object of type SignedData. The SignedData encapContentInfo
1242 eContent field MUST be absent. The signerInfos field contains the
1243 signatures for the MIME entity.
1245 The file extension for signed-only messages using application/pkcs7-
1246 signature is ".p7s".
1248 3.4.3.2. Creating a multipart/signed Message
1250 Step 1. The MIME entity to be signed is prepared according to
1251 section 3.1, taking special care for clear-signing.
1253 Step 2. The MIME entity is presented to CMS processing in order
1254 to obtain an object of type SignedData in which the
1255 encapContentInfo eContent field is absent.
1257 Step 3. The MIME entity is inserted into the first part of a
1258 multipart/signed message with no processing other than that
1259 described in section 3.1.
1261 Step 4. Transfer encoding is applied to the "detached signature"
1262 CMS SignedData object and it is inserted into a MIME entity of
1263 type application/pkcs7-signature.
1265 Step 5. The MIME entity of the application/pkcs7-signature is
1266 inserted into the second part of the multipart/signed entity.
1268 The multipart/signed Content-Type has two required parameters: the
1269 protocol parameter and the micalg parameter.
1271 The protocol parameter MUST be "application/pkcs7-signature". Note
1272 that quotation marks are required around the protocol parameter
1273 because MIME requires that the "/" character in the parameter value
1274 MUST be quoted.
1276 The micalg parameter allows for one-pass processing when the
1277 signature is being verified. The value of the micalg parameter is
1278 dependent on the message digest algorithm(s) used in the calculation
1279 of the Message Integrity Check. If multiple message digest
1280 algorithms are used they MUST be separated by commas per [MIME-
1281 SECURE]. The values to be placed in the micalg parameter SHOULD be
1282 from the following:
1284 Algorithm Value used
1286 MD5 md5
1287 SHA-1 sha-1
1288 SHA-224 sha-224
1289 SHA-256 sha-256
1290 SHA-384 sha-384
1291 SHA-512 sha-512
1292 Any other (defined separately in algorithm profile or "unknown"
1293 if not defined)
1295 (Historical note: some early implementations of S/MIME emitted and
1296 expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
1297 Receiving agents SHOULD be able to recover gracefully from a micalg
1298 parameter value that they do not recognize. Future names for this
1299 parameter will be consistent with the IANA "Hash Function Textual
1300 Names" registry.
1302 3.4.3.3. Sample multipart/signed Message
1304 Content-Type: multipart/signed;
1305 protocol="application/pkcs7-signature";
1306 micalg=sha1; boundary=boundary42
1308 --boundary42
1309 Content-Type: text/plain
1311 This is a clear-signed message.
1313 --boundary42
1314 Content-Type: application/pkcs7-signature; name=smime.p7s
1315 Content-Transfer-Encoding: base64
1316 Content-Disposition: attachment; filename=smime.p7s
1318 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
1319 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
1320 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1321 7GhIGfHfYT64VQbnj756
1323 --boundary42--
1325 The content that is digested (the first part of the multipart/signed)
1326 are the bytes:
1328 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
1329 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
1330 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
1332 3.5. Creating a Compressed-only Message
1334 This section describes the format for compressing a MIME entity.
1335 Please note that versions of S/MIME prior to version 3.1 did not
1336 specify any use of CompressedData, and will not recognize it. The
1337 use of a capability to indicate the ability to receive CompressedData
1338 is described in [CMSCOMPR] and is the preferred method for
1339 compatibility.
1341 Step 1. The MIME entity to be compressed is prepared according
1342 to section 3.1.
1344 Step 2. The MIME entity and other required data is processed
1345 into a CMS object of type CompressedData.
1347 Step 3. The CompressedData object is wrapped in a CMS
1348 ContentInfo object.
1350 Step 4. The ContentInfo object is inserted into an
1351 application/pkcs7-mime MIME entity.
1353 The smime-type parameter for compressed-only messages is "compressed-
1354 data". The file extension for this type of message is ".p7z".
1356 A sample message would be:
1358 Content-Type: application/pkcs7-mime; smime-type=compressed-data;
1359 name=smime.p7z
1360 Content-Transfer-Encoding: base64
1361 Content-Disposition: attachment; filename=smime.p7z
1363 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
1364 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
1365 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1366 0GhIGfHfQbnj756YT64V
1368 3.6. Multiple Operations
1370 The signed-only, enveloped-only, and compressed-only MIME formats can
1371 be nested. This works because these formats are all MIME entities
1372 that encapsulate other MIME entities.
1374 An S/MIME implementation MUST be able to receive and process
1375 arbitrarily nested S/MIME within reasonable resource limits of the
1376 recipient computer.
1378 It is possible to apply any of the signing, encrypting, and
1379 compressing operations in any order. It is up to the implementer and
1380 the user to choose. When signing first, the signatories are then
1381 securely obscured by the enveloping. When enveloping first the
1382 signatories are exposed, but it is possible to verify signatures
1383 without removing the enveloping. This can be useful in an
1384 environment were automatic signature verification is desired, as no
1385 private key material is required to verify a signature.
1387 There are security ramifications to choosing whether to sign first or
1388 encrypt first. A recipient of a message that is encrypted and then
1389 signed can validate that the encrypted block was unaltered, but
1390 cannot determine any relationship between the signer and the
1391 unencrypted contents of the message. A recipient of a message that
1392 is signed-then-encrypted can assume that the signed message itself
1393 has not been altered, but that a careful attacker could have changed
1394 the unauthenticated portions of the encrypted message.
1396 When using compression, keep the following guidelines in mind:
1398 - Compression of binary encoded encrypted data is discouraged, since
1399 it will not yield significant compression. Base64 encrypted data
1400 could very well benefit, however.
1402 - If a lossy compression algorithm is used with signing, you will
1403 need to compress first, then sign.
1405 3.7. Creating a Certificate Management Message
1407 The certificate management message or MIME entity is used to
1408 transport certificates and/or certificate revocation lists, such as
1409 in response to a registration request.
1411 Step 1. The certificates and/or certificate revocation lists are
1412 made available to the CMS generating process which creates a CMS
1413 object of type SignedData. The SignedData encapContentInfo
1414 eContent field MUST be absent and signerInfos field MUST be
1415 empty.
1417 Step 2. The SignedData object is wrapped in a CMS ContentInfo
1418 object.
1420 Step 3. The ContentInfo object is enclosed in an
1421 application/pkcs7-mime MIME entity.
1423 The smime-type parameter for a certificate management message is
1424 "certs-only". The file extension for this type of message is ".p7c".
1426 3.8. Registration Requests
1428 A sending agent that signs messages MUST have a certificate for the
1429 signature so that a receiving agent can verify the signature. There
1430 are many ways of getting certificates, such as through an exchange
1431 with a certificate authority, through a hardware token or diskette,
1432 and so on.
1434 S/MIME v2 [SMIMEv2] specified a method for "registering" public keys
1435 with certificate authorities using an application/pkcs10 body part.
1436 Since that time, the IETF PKIX Working Group has developed other
1437 methods for requesting certificates. However, S/MIME v3.2 does not
1438 require a particular certificate request mechanism.
1440 3.9. Identifying an S/MIME Message
1442 Because S/MIME takes into account interoperation in non-MIME
1443 environments, several different mechanisms are employed to carry the
1444 type information, and it becomes a bit difficult to identify S/MIME
1445 messages. The following table lists criteria for determining whether
1446 or not a message is an S/MIME message. A message is considered an
1447 S/MIME message if it matches any of the criteria listed below.
1449 The file suffix in the table below comes from the "name" parameter in
1450 the Content-Type header field, or the "filename" parameter on the
1451 Content-Disposition header field. These parameters that give the
1452 file suffix are not listed below as part of the parameter section.
1454 Media type: application/pkcs7-mime
1455 parameters: any
1456 file suffix: any
1458 Media type: multipart/signed
1459 parameters: protocol="application/pkcs7-signature"
1460 file suffix: any
1462 Media type: application/octet-stream
1463 parameters: any
1464 file suffix: p7m, p7s, p7c, p7z
1466 4. Certificate Processing
1468 A receiving agent MUST provide some certificate retrieval mechanism
1469 in order to gain access to certificates for recipients of digital
1470 envelopes. This specification does not cover how S/MIME agents
1471 handle certificates, only what they do after a certificate has been
1472 validated or rejected. S/MIME certificate issues are covered in
1473 [CERT32].
1475 At a minimum, for initial S/MIME deployment, a user agent could
1476 automatically generate a message to an intended recipient requesting
1477 that recipient's certificate in a signed return message. Receiving
1478 and sending agents SHOULD also provide a mechanism to allow a user to
1479 "store and protect" certificates for correspondents in such a way so
1480 as to guarantee their later retrieval.
1482 4.1. Key Pair Generation
1484 All generated key pairs MUST be generated from a good source of non-
1485 deterministic random input [RANDOM] and the private key MUST be
1486 protected in a secure fashion.
1488 An S/MIME user agent MUST NOT generate asymmetric keys less than 512
1489 bits for use with the RSA or DSA signature algorithms.
1491 For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without
1492 Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and
1493 [FIPS186-2] without Change Notice 1, for 1024-bit through 2048-bit
1494 RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change Notice 1.
1495 The first reference provides the signature algorithm's object
1496 identifier and the second provides the signature algorithm's
1497 definition.
1499 For 512-bit DSA with SHA-1 see [CMSALG] and [FIPS186-2] without
1500 Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and
1501 [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
1502 [CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit DSA with
1503 SHA-256 see [CMS-SHA2] and [FIPS186-3]. The first reference provides
1504 the signature algorithm's object identifier and the second provides
1505 the signature algorithm's definition.
1507 For 512-2048-bit RSASSA-PSS with SHA-256 see [RSAPSS].
1509 4.2. Signature Generation
1511 The following are the requirements for an S/MIME agent generated RSA
1512 signatures:
1514 key size <= 1023 : SHOULD NOT (see Security Considerations)
1515 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
1516 2048 < key size : MAY (see Security Considerations)
1518 The following are the requirements for an S/MIME agent generated DSA
1519 signatures:
1521 key size <= 1023 : SHOULD NOT (see Security Considerations)
1522 1024 = key size : SHOULD (see Security Considerations)
1524 4.3. Signature Verification
1526 The following are the requirements for S/MIME receiving agents during
1527 signature verification of RSA signatures:
1529 key size <= 1023 : MAY (see Security Considerations)
1530 1024 <= key size <= 2048 : MUST (see Security Considerations)
1531 2048 < key size : MAY (see Security Considerations)
1532 The following are the requirements for S/MIME receiving agents during
1533 signature verification of DSA signatures:
1535 key size <= 1023 : MAY (see Security Considerations)
1536 1024 = key size : SHOULD (see Security Considerations)
1538 4.4. Encryption
1540 The following are the requirements for an S/MIME agent when
1541 establishing keys for content encryption using the RSA algorithms:
1543 key size <= 1023 : SHOULD NOT (see Security Considerations)
1544 1024 <= key size <= 2048 : SHOULD (see Security Considerations)
1545 2048 < key size : MAY (see Security Considerations)
1547 The following are the requirements for an S/MIME agent when
1548 establishing keys for content encryption using the DH algorithms:
1550 key size <= 1023 : SHOULD NOT (see Security Considerations)
1551 1024 = key size : SHOULD (see Security Considerations)
1553 4.5. Decryption
1555 The following are the requirements for an S/MIME agent when
1556 establishing keys for content decryption using the RSA algorithms:
1558 key size <= 1023 : MAY (see Security Considerations)
1559 1024 <= key size <= 2048 : MUST (see Security Considerations)
1560 2048 < key size : MAY (see Security Considerations)
1562 The following are the requirements for an S/MIME agent when
1563 establishing keys for content decryption using the DH algorithms:
1565 key size <= 1023 : MAY (see Security Considerations)
1566 1024 = key size : SHOULD (see Security Considerations)
1568 5. IANA Considerations
1570 The following is intended to provide sufficient information to update
1571 the media type registration for application/pkcs7-mime and
1572 application/pkcs7-signature to refer to this document as opposed to
1573 RFC 2311.
1575 Note that other documents can define additional MIME media types for
1576 S/MIME.
1578 5.1. Media Type for application/pkcs7-mime
1580 Type name: application
1582 Subtype Name: pkcs7-mime
1584 Required Parameters: NONE
1586 Optional Parameters: smime-type/signed-data
1587 smime-type/enveloped-data
1588 smime-type/compressed-data
1589 smime-type/certs-only
1590 name
1592 Encoding Considerations: See Section 3 of this document
1594 Security Considerations: See Section 6 of this document
1596 Interoperability Considerations: See Sections 1-6 of this document
1598 Published Specification: RFC 2311, RFC 2633, and this document
1600 Applications that use this media type: Security applications
1602 Additional information: NONE
1604 Person & email to contact for further information: S/MIME working
1605 group chairs smime-chairs@tools.ietf.org
1607 Intended usage: COMMON
1609 Restrictions on usage: NONE
1611 Author: Sean Turner
1613 Change Controller: S/MIME working group delegated from the IESG
1615 5.2. Media Type for application/pkcs7-signature
1617 Type name: application
1619 Subtype Name: pkcs7-signature
1621 Required Parameters: NONE
1623 Optional Parameters: NONE
1624 Encoding Considerations: See Section 3 of this document
1626 Security Considerations: See Section 6 of this document
1628 Interoperability Considerations: See Sections 1-6 of this document
1630 Published Specification: RFC 2311, RFC 2633, and this document
1632 Applications that use this media type: Security applications
1634 Additional information: NONE
1636 Person & email to contact for further information: S/MIME working
1637 group chairs smime-chairs@tools.ietf.org
1639 Intended usage: COMMON
1641 Restrictions on usage: NONE
1643 Author: Sean Turner
1645 Change Controller: S/MIME working group delegated from the IESG
1647 6. Security Considerations
1649 Cryptographic algorithms will be broken or weakened over time.
1650 Implementers and users need to check that the cryptographic
1651 algorithms listed in this document continue to provide the expected
1652 level of security. The IETF from time to time may issue documents
1653 dealing with the current state of the art. For example:
1655 - The Million Message Attack described in RFC 3218 [MMA].
1657 - The Diffie-Hellman "small-subgroup" attacks described in
1658 RFC 2785 [DHSUB].
1660 - The attacks against hash algorithms described in
1661 RFC 4270 [HASH-ATTACK].
1663 This specification uses Public-Key Cryptography technologies. It is
1664 assumed that the private key is protected to ensure that it is not
1665 accessed or altered by unauthorized parties.
1667 It is impossible for most people or software to estimate the value of
1668 a message's content. Further, it is impossible for most people or
1669 software to estimate the actual cost of recovering an encrypted
1670 message content that is encrypted with a key of a particular size.
1672 Further, it is quite difficult to determine the cost of a failed
1673 decryption if a recipient cannot process a message's content. Thus,
1674 choosing between different key sizes (or choosing whether to just use
1675 plaintext) is also impossible for most people or software. However,
1676 decisions based on these criteria are made all the time, and
1677 therefore this specification gives a framework for using those
1678 estimates in choosing algorithms.
1680 The choice of 2048 bits as the RSA asymmetric key size in this
1681 specification is based on the desire to provide at least 100 bits of
1682 security. The standards to offer the same level of security for DSA
1683 and DH are not yet available. In particular, [FIPS186-2] without
1684 Change Notice allowed DSA key sizes between 512 and 1024 bits and
1685 [FIPS186-2] with Change Notice 1 only allowed DSA key sizes of 1024
1686 bits. A revision to support larger key sizes is being developed, and
1687 once it is available, implementors ought to support DSA key sizes
1688 comparable to the RSA key sizes recommended in this specification.
1689 The key sizes that must be supported to conform to this specification
1690 seem appropriate for the Internet based on [STRENGTH]. Of course,
1691 there are environments, such as financial and medical system, that
1692 may select different key sizes. For this reason, an implementation
1693 MAY support key sizes beyond those recommended in this specification.
1695 Receiving agents that validate signatures and sending agents that
1696 encrypt messages, need to be cautious of cryptographic processing
1697 usage when validating signatures and encrypting messages using keys
1698 larger than those mandated in this specification. An attacker could
1699 send certificates with keys which would result in excessive
1700 cryptographic processing, for example keys larger than those mandated
1701 in this specification, which could swamp the processing element.
1702 Agents which use such keys without first validating the certificate
1703 to a trust anchor are advised to have some sort of cryptographic
1704 resource management system to prevent such attacks.
1706 Using weak cryptography in S/MIME offers little actual security over
1707 sending plaintext. However, other features of S/MIME, such as the
1708 specification of AES and the ability to announce stronger
1709 cryptographic capabilities to parties with whom you communicate,
1710 allow senders to create messages that use strong encryption. Using
1711 weak cryptography is never recommended unless the only alternative is
1712 no cryptography.
1714 RSA and DSA keys of less than 1024 bits are now considered by many
1715 experts to be cryptographically insecure (due to advances in
1716 computing power), and should no longer be used to protect messages.
1717 Such keys were previously considered secure, so processing previously
1718 received signed and encrypted mail will often result in the use of
1719 weak keys. Implementations that wish to support previous versions of
1720 S/MIME or process old messages need to consider the security risks
1721 that result from smaller key sizes (e.g., spoofed messages) versus
1722 the costs of denial of service. If an implementation supports
1723 verification of digital signatures generated with RSA and DSA keys of
1724 less than 1024 bits, it MUST warn the user. Implementers should
1725 consider providing different warnings for newly received messages and
1726 previously stored messages. Server implementations (e.g., secure
1727 mail list servers) where user warnings are not appropriate SHOULD
1728 reject messages with weak signatures.
1730 Implementers SHOULD be aware that multiple active key pairs can be
1731 associated with a single individual. For example, one key pair can
1732 be used to support confidentiality, while a different key pair can be
1733 used for digital signatures.
1735 If a sending agent is sending the same message using different
1736 strengths of cryptography, an attacker watching the communications
1737 channel might be able to determine the contents of the strongly-
1738 encrypted message by decrypting the weakly-encrypted version. In
1739 other words, a sender SHOULD NOT send a copy of a message using
1740 weaker cryptography than they would use for the original of the
1741 message.
1743 Modification of the ciphertext can go undetected if authentication is
1744 not also used, which is the case when sending EnvelopedData without
1745 wrapping it in SignedData or enclosing SignedData within it.
1747 If an implementation is concerned about compliance with NIST key size
1748 recommendations, then see [SP800-57].
1750 If messaging environments make use of the fact that a message is
1751 signed to change the behavior of message processing (examples would
1752 be running rules or UI display hints), without first verifying that
1753 the message is actually signed and knowing the state of the
1754 signature, can lead to incorrect handling of the message. Visual
1755 indicators on messages may need to have the signature validation code
1756 check periodically if the indicator is supposed to give information
1757 on the current status of a message.
1759 7. References
1761 7.1. Normative References
1763 [CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
1764 Certificate Handling", draft-ietf-smime-3850bis-
1765 10.txt, work-in-progress.
1767 [CHARSETS] Character sets assigned by IANA. See
1768 http://www.iana.org/assignments/character-sets.
1770 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
1771 3852, July 2004.
1773 Housley, R., "Cryptographic Message Syntax (CMS)
1774 Multiple Signer Clarification", RFC 4853, April 2007.
1776 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
1777 (AES) Encryption Algorithm in Cryptographic Message
1778 Syntax (CMS)", RFC 3565, July 2003.
1780 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
1781 Algorithms", RFC 3370, August 2002.
1783 [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
1784 Cryptographic Message Syntax (CMS)", RFC 3274, June
1785 2002.
1787 [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic
1788 Message Syntax", draft-ietf-smime-sha2-11.txt, work in
1789 progress.
1791 [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
1792 Presentation Information in Internet Messages: The
1793 Content-Disposition Header Field", RFC 2183, August
1794 1997.
1796 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
1797 RFC 2634, June 1999.
1799 Schaad, J., "ESS Update: Adding CertID Algorithm
1800 Agility", RFC 5035, August 2007.
1802 [FIPS186-2] National Institute of Standards and Technology (NIST),
1803 "Digital Signature Standard (DSS)", FIPS Publication
1804 186-2, January 2000. [With Change Notice 1].
1806 [FIPS186-3] National Institute of Standards and Technology (NIST),
1807 FIPS Publication 186-3: Digital Signature Standard,
1808 (draft) March 2006.
1810 [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
1811 Mail Extensions (MIME) Part One: Format of Internet
1812 Message Bodies", RFC 2045, November 1996.
1814 Freed, N. and N. Borenstein, "Multipurpose Internet
1815 Mail Extensions (MIME) Part Two: Media Types", RFC
1816 2046, November 1996.
1818 Moore, K., "MIME (Multipurpose Internet Mail
1819 Extensions) Part Three: Message Header Extensions for
1820 Non-ASCII Text", RFC 2047, November 1996.
1822 Freed, N., and J. Klensin, "Multipurpose Internet Mail
1823 Extensions (MIME) Part Four: Registration Procedures",
1824 BCP 13, RFC 4289, December 2005.
1826 Freed, N., and J. Klensin, "Media Type Specifications
1827 and Registration Procedures", BCP 13, RFC 4288,
1828 December 2005.
1830 Freed, N. and N. Borenstein, "Multipurpose Internet
1831 Mail Extensions (MIME) Part Five: Conformance Criteria
1832 and Examples", RFC 2049, November 1996.
1834 [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
1835 "Security Multiparts for MIME: Multipart/Signed and
1836 Multipart/Encrypted", RFC 1847, October 1995.
1838 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
1839 Requirement Levels", BCP 14, RFC 2119, March 1997.
1841 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
1842 "Randomness Requirements for Security", BCP 106, RFC
1843 4086, June 2005.
1845 [RSAPSS] Schaad, J., "Use of RSASSA-PSS Signature Algorithm in
1846 Cryptographic Message Syntax (CMS)", RFC 4056, June
1847 2005.
1849 [RSAOAEP] Housley, R. "Use of the RSAES-OAEP Key Transport
1850 Algorithm in the Cryptographic Message Syntax (CMS)",
1851 RFC 3560, July 2003.
1853 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1854 1:2002. Information Technology - Abstract Syntax
1855 Notation One (ASN.1): Specification of basic
1856 notation.
1858 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
1859 1:2002. Information Technology - ASN.1 encoding
1860 rules: Specification of Basic Encoding Rules (BER),
1861 Canonical Encoding Rules (CER) and Distinguished
1862 Encoding Rules (DER).
1864 7.2. Informative References
1866 [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
1867 Subgroup" Attacks on the Diffie-Hellman Key Agreement
1868 Method for S/MIME", RFC 2785, March 2000.
1870 [HASH-ATTACK] Hoffman, P., Schneier, B., "Attacks on Cryptographic
1871 Hashes in Internet Protocols", RFC 4270, November
1872 2005.
1874 [MMA] Rescorla, E., "Preventing the Million Message Attack
1875 on Cryptographic Message Syntax", RFC 3218, January
1876 2002.
1878 [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
1879 Version 1.5", RFC 2315, March 1998.
1881 [SMIMEv2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
1882 and L. Repka, "S/MIME Version 2 Message
1883 Specification", RFC 2311, March 1998.
1885 Dusse, S., Hoffman, P., Ramsdell, B., and J.
1886 Weinstein, "S/MIME Version 2 Certificate Handling",
1887 RFC 2312, March 1998.
1889 Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
1890 RFC 2313, March 1998.
1892 Kaliski, B., "PKCS #10: Certificate Request Syntax
1893 Version 1.5", RFC 2314, March 1998.
1895 Kaliski, B., "PKCS #7: Certificate Message Syntax
1896 Version 1.5", RFC 2315, March 1998.
1898 [SMIMEv3] Housley, R., "Cryptographic Message Syntax", RFC 2630,
1899 June 1999.
1901 Rescorla, E., "Diffie-Hellman Key Agreement Method",
1902 RFC 2631, June 1999.
1904 Ramsdell, B., "S/MIME Version 3 Certificate Handling",
1905 RFC 2632, June 1999.
1907 Ramsdell, B., "S/MIME Version 3 Message
1908 Specification", RFC 2633, June 1999.
1910 Hoffman, P., "Enhanced Security Services for S/MIME",
1911 RFC 2634, June 1999.
1913 Schaad, J., "ESS Update: Adding CertID Algorithm
1914 Agility", RFC 5035, August 2007.
1916 [SMIMEv3.1] Housley, R., "Cryptographic Message Syntax", RFC 3852,
1917 July 2004.
1919 Housley, R., "Cryptographic Message Syntax (CMS)
1920 Multiple Signer Clarification", RFC 4853, April 2007.
1922 Ramsdell, B., "S/MIME Version 3.1 Certificate
1923 Handling", RFC 3850, July 2004.
1925 Ramsdell, B., "S/MIME Version 3.1 Message
1926 Specification", RFC 3851, July 2004.
1928 Hoffman, P., "Enhanced Security Services for S/MIME",
1929 RFC 2634, June 1999.
1931 Schaad, J., "ESS Update: Adding CertID Algorithm
1932 Agility", RFC 5035, August 2007.
1934 [SP800-57] National Institute of Standards and Technology (NIST),
1935 Special Publication 800-57: Recommendation for Key
1936 Management, August 2005.
1938 [STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For
1939 Public Keys Used For Exchanging Symmetric Keys", BCP
1940 86, RFC 3766, April 2004.
1942 Appendix A. ASN.1 Module
1944 NOTE: The ASN.1 module contained herein is unchanged from RFC 3851
1945 [SMIMEv3.1] with the exception of a change to the prefersBinaryInside
1946 ASN.1 comment. This module uses the 1988 version of ASN.1.
1948 SecureMimeMessageV3dot1
1950 { iso(1) member-body(2) us(840) rsadsi(113549)
1951 pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
1953 DEFINITIONS IMPLICIT TAGS ::=
1955 BEGIN
1957 IMPORTS
1959 -- Cryptographic Message Syntax [CMS]
1960 SubjectKeyIdentifier, IssuerAndSerialNumber,
1961 RecipientKeyIdentifier
1962 FROM CryptographicMessageSyntax
1963 { iso(1) member-body(2) us(840) rsadsi(113549)
1964 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
1966 -- id-aa is the arc with all new authenticated and unauthenticated
1967 -- attributes produced by the S/MIME Working Group
1969 id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
1970 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
1972 -- S/MIME Capabilities provides a method of broadcasting the
1973 -- symmetric capabilities understood. Algorithms SHOULD be ordered
1974 -- by preference and grouped by type
1976 smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
1977 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
1979 SMIMECapability ::= SEQUENCE {
1980 capabilityID OBJECT IDENTIFIER,
1981 parameters ANY DEFINED BY capabilityID OPTIONAL }
1983 SMIMECapabilities ::= SEQUENCE OF SMIMECapability
1985 -- Encryption Key Preference provides a method of broadcasting the
1986 -- preferred encryption certificate.
1988 id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
1990 SMIMEEncryptionKeyPreference ::= CHOICE {
1991 issuerAndSerialNumber [0] IssuerAndSerialNumber,
1992 receipentKeyId [1] RecipientKeyIdentifier,
1993 subjectAltKeyIdentifier [2] SubjectKeyIdentifier
1994 }
1996 -- receipentKeyId is spelt incorrectly, but kept for historical
1997 -- reasons.
1999 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2000 rsadsi(113549) pkcs(1) pkcs9(9) 16 }
2002 id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
2004 -- The preferBinaryInside OID indicates an ability to receive
2005 -- messages with binary encoding inside the CMS wrapper.
2006 -- The preferBinaryInside attribute's value field is ABSENT.
2008 id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
2010 -- The following list OIDs to be used with S/MIME V3
2012 -- Signature Algorithms Not Found in [CMSALG], [CMS-SHA2], [RSAPSS],
2013 -- and [RSAOAEP]
2015 --
2017 -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
2018 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
2019 -- 2}
2021 --
2023 -- Other Signed Attributes
2024 --
2025 -- signingTime OBJECT IDENTIFIER ::=
2026 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
2027 -- 5}
2028 -- See [CMS] for a description of how to encode the attribute
2029 -- value.
2031 SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
2032 -- (RC2 Key Length (number of bits))
2034 END
2036 Appendix B. Moving S/MIME v2 Message Specification to Historic Status
2038 The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
2039 are backwards compatible with the S/MIME v2 Message Specification
2040 [SMIMEv2], with the exception of the algorithms (dropped RC2/40
2041 requirement and added DSA and RSASSA-PSS requirements). Therefore, it
2042 is recommended that RFC 2311 [SMIMEv2] be moved to Historic status.
2044 Appendix C. Acknowledgments
2046 Many thanks go out to the other authors of the S/MIME Version 2
2047 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
2048 Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or
2049 v3.2.
2051 A number of the members of the S/MIME Working Group have also worked
2052 very hard and contributed to this document. Any list of people is
2053 doomed to omission, and for that I apologize. In alphabetical order,
2054 the following people stand out in my mind due to the fact that they
2055 made direct contributions to this document.
2057 Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
2058 Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
2059 John Pawling, and Jim Schaad.
2061 Authors' Addresses
2063 Blake Ramsdell
2065 Brute Squad Labs, Inc.
2067 EMail: blaker@gmail.com
2069 Sean Turner
2071 IECA, Inc.
2072 3057 Nutley Street, Suite 106
2073 Fairfax, VA 22031
2074 USA
2076 EMail: turners@ieca.com