idnits 2.17.1
draft-ietf-smime-3851bis-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1708.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1719.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1726.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1732.
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 is 1 instance of too long lines in the document, the longest one
being 16 characters in excess of 72.
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
-- The abstract seems to indicate that this document obsoletes RFC3851, but
the header doesn't have an 'Obsoletes:' line to match this.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 5, 2007) is 6010 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)
-- Missing reference section? 'RFC2119' on line 54 looks like a reference
-- Missing reference section? 'MIME-SPEC' on line 1602 looks like a
reference
-- Missing reference section? 'CMS' on line 1565 looks like a reference
-- Missing reference section? 'PKCS-7' on line 1652 looks like a reference
-- Missing reference section? 'MIME-SECURE' on line 1622 looks like a
reference
-- Missing reference section? 'CMSALG' on line 1575 looks like a reference
-- Missing reference section? 'RSAPSS' on line 1629 looks like a reference
-- Missing reference section? 'RSAOAEP' on line 342 looks like a reference
-- Missing reference section? 'CMSECC' on line 1582 looks like a reference
-- Missing reference section? 'CMS-SHA2' on line 1587 looks like a reference
-- Missing reference section? 'ESS' on line 1595 looks like a reference
-- Missing reference section? 'CMSAES' on line 1571 looks like a reference
-- Missing reference section? 'CHARSETS' on line 1562 looks like a reference
-- Missing reference section? 'CONTDISP' on line 1590 looks like a reference
-- Missing reference section? 'SHA224' on line 1659 looks like a reference
-- Missing reference section? 'FIPS180-2' on line 1598 looks like a
reference
-- Missing reference section? 'CMSCOMPR' on line 1578 looks like a reference
-- Missing reference section? 'SMIMEV2' on line 1662 looks like a reference
-- Missing reference section? 'CERT32' on line 1559 looks like a reference
-- Missing reference section? 'RANDOM' on line 1655 looks like a reference
-- Missing reference section? 'MMA' on line 1649 looks like a reference
-- Missing reference section? 'DHSUB' on line 1645 looks like a reference
-- Missing reference section? '0' on line 1515 looks like a reference
-- Missing reference section? '1' on line 1516 looks like a reference
-- Missing reference section? '2' on line 1517 looks like a reference
-- Missing reference section? 'MUSTSHOULD' on line 1626 looks like a
reference
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 34 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 S/MIME WG Blake Ramsdell, SendMail
2 Internet Draft Sean Turner, IECA
3 Intended Status: Standard Track November 5, 2007
4 Expires: May 5, 2008
6 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
7 Message Specification
8 draft-ietf-smime-3851bis-00.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html
33 This Internet-Draft will expire on April 5, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This document defines Secure/Multipurpose Internet Mail Extensions
42 (S/MIME) version 3.2. S/MIME provides a consistent way to send and
43 receive secure MIME data. Digital signatures provide authentication,
44 message integrity, and non-repudiation with proof of origin.
46 Encryption provides data confidentiality. Compression can be used to
47 reduce data size. This document obsoletes RFC 3851.
49 Conventions used in this document
51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
53 document are to be interpreted as described in [RFC2119].
55 Discussion
57 This draft is being discussed on the 'ietf-smime' mailing list. To
58 subscribe, send a message to ietf-smime-request@imc.org with the
59 single word subscribe in the body of the message. There is a Web site
60 for the mailing list at .
62 Table of Contents
64 1. Introduction...................................................3
65 1.1. Specification Overview....................................4
66 1.2. Definitions...............................................5
67 1.3. Compatibility with Prior Practice of S/MIME...............6
68 1.4. Changes Since S/MIME v3...................................6
69 1.5. Changes Since S/MIME v3.1.................................6
70 2. CMS Options....................................................7
71 2.1. DigestAlgorithmIdentifier.................................7
72 2.2. SignatureAlgorithmIdentifier..............................7
73 2.3. KeyEncryptionAlgorithmIdentifier..........................8
74 2.4. General Syntax............................................8
75 2.4.1. Data Content Type....................................8
76 2.4.2. SignedData Content Type..............................9
77 2.4.3. EnvelopedData Content Type...........................9
78 2.4.4. CompressedData Content Type..........................9
79 2.5. Attributes and the SignerInfo Type........................9
80 2.5.1. Signing-Time Attribute..............................10
81 2.5.2. SMIMECapabilities Attribute.........................10
82 2.5.3. Encryption Key Preference Attribute.................12
83 2.5.3.1. Selection of Recipient Key Management
84 Certificate....................................13
85 2.6. SignerIdentifier SignerInfo Type.........................13
86 2.7. ContentEncryptionAlgorithmIdentifier.....................13
87 2.7.1. Deciding Which Encryption Method To Use.............14
88 2.7.1.1. Rule 1: Known Capabilities.....................15
89 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of
90 S/MIME..................................................15
91 2.7.2. Choosing Weak Encryption............................15
92 2.7.3. Multiple Recipients.................................15
94 3. Creating S/MIME Messages......................................16
95 3.1. Preparing the MIME Entity for Signing, Enveloping or
96 Compressing..............................................16
97 3.1.1. Canonicalization....................................17
98 3.1.2. Transfer Encoding...................................18
99 3.1.3. Transfer Encoding for Signing Using multipart/signed19
100 3.1.4. Sample Canonical MIME Entity........................20
101 3.2. The application/pkcs7-mime Type..........................20
102 3.2.1. The name and filename Parameters....................21
103 3.2.2. The smime-type parameter............................22
104 3.3. Creating an Enveloped-only Message.......................23
105 3.4. Creating a Signed-only Message...........................24
106 3.4.1. Choosing a Format for Signed-only Messages..........24
107 3.4.2. Signing Using application/pkcs7-mime with SignedData24
108 3.4.3. Signing Using the multipart/signed Format...........25
109 3.4.3.1. The application/pkcs7-signature MIME Type......25
110 3.4.3.2. Creating a multipart/signed Message............25
111 3.4.3.3. Sample multipart/signed Message................27
112 3.5. Creating an Compressed-only Message......................27
113 3.6. Multiple Operations......................................28
114 3.7. Creating a Certificate Management Message................29
115 3.8. Registration Requests....................................29
116 3.9. Identifying an S/MIME Message............................30
117 4. Certificate Processing........................................30
118 4.1. Key Pair Generation......................................30
119 5. IANA Considerations...........................................31
120 6. Security Considerations.......................................31
121 Appendix A. ASN.1 Module.........................................33
122 Appendix B. References...........................................35
123 B.1. Normative References.....................................35
124 B.2. Informative References...................................36
126 1. Introduction
128 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
129 consistent way to send and receive secure MIME data. Based on the
130 popular Internet MIME standard, S/MIME provides the following
131 cryptographic security services for electronic messaging
132 applications: authentication, message integrity and non-repudiation
133 of origin (using digital signatures), and data confidentiality (using
134 encryption).
136 S/MIME can be used by traditional mail user agents (MUAs) to add
137 cryptographic security services to mail that is sent, and to
138 interpret cryptographic security services in mail that is received.
139 However, S/MIME is not restricted to mail; it can be used with any
140 transport mechanism that transports MIME data, such as HTTP. As
141 such, S/MIME takes advantage of the object-based features of MIME and
142 allows secure messages to be exchanged in mixed-transport systems.
144 Further, S/MIME can be used in automated message transfer agents that
145 use cryptographic security services that do not require any human
146 intervention, such as the signing of software-generated documents and
147 the encryption of FAX messages sent over the Internet.
149 1.1. Specification Overview
151 This document describes a protocol for adding cryptographic signature
152 and encryption services to MIME data. The MIME standard [MIME-SPEC]
153 provides a general structure for the content type of Internet
154 messages and allows extensions for new content type applications.
156 This specification defines how to create a MIME body part that has
157 been cryptographically enhanced according to CMS [CMS], which is
158 derived from PKCS #7 [PKCS-7]. This specification also defines the
159 application/pkcs7-mime MIME type that can be used to transport those
160 body parts.
162 This document also discusses how to use the multipart/signed MIME
163 type defined in [MIME-SECURE] to transport S/MIME signed messages.
164 multipart/signed is used in conjunction with the application/pkcs7-
165 signature MIME type, which is used to transport a detached S/MIME
166 signature.
168 In order to create S/MIME messages, an S/MIME agent MUST follow the
169 specifications in this document, as well as the specifications listed
170 in the Cryptographic Message Syntax document [CMS], [CMSALG],
171 [RSAPSS], [RSAOAEP], [CMSECC], [CMS-SHA2].
173 Throughout this specification, there are requirements and
174 recommendations made for how receiving agents handle incoming
175 messages. There are separate requirements and recommendations for
176 how sending agents create outgoing messages. In general, the best
177 strategy is to "be liberal in what you receive and conservative in
178 what you send". Most of the requirements are placed on the handling
179 of incoming messages while the recommendations are mostly on the
180 creation of outgoing messages.
182 The separation for requirements on receiving agents and sending
183 agents also derives from the likelihood that there will be S/MIME
184 systems that involve software other than traditional Internet mail
185 clients. S/MIME can be used with any system that transports MIME
186 data. An automated process that sends an encrypted message might not
187 be able to receive an encrypted message at all, for example. Thus,
188 the requirements and recommendations for the two types of agents are
189 listed separately when appropriate.
191 1.2. Definitions
193 For the purposes of this specification, the following definitions
194 apply.
196 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208
197 [X.208-88].
199 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209
200 [X.209-88].
202 Certificate: A type that binds an entity's name to a public key with
203 a digital signature.
205 DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
206 X.509 [X.509-88].
208 7-bit data: Text data with lines less than 998 characters long, where
209 none of the characters have the 8th bit set, and there are no NULL
210 characters. and occur only as part of a end of
211 line delimiter.
213 8-bit data: Text data with lines less than 998 characters, and where
214 none of the characters are NULL characters. and occur only
215 as part of a end of line delimiter.
217 Binary data: Arbitrary data.
219 Transfer Encoding: A reversible transformation made on data so 8-bit
220 or binary data can be sent via a channel that only transmits 7-bit
221 data.
223 Receiving agent: Software that interprets and processes S/MIME CMS
224 objects, MIME body parts that contain CMS content types, or both.
226 Sending agent: Software that creates S/MIME CMS content types, MIME
227 body parts that contain CMS content types, or both.
229 S/MIME agent: User software that is a receiving agent, a sending
230 agent, or both.
232 1.3. Compatibility with Prior Practice of S/MIME
234 S/MIME version 3.2 agents SHOULD attempt to have the greatest
235 interoperability possible with agents for prior versions of S/MIME.
236 S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
237 S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive,
238 and S/MIME version 3.1 is described in RFC 3850 through 3851
239 inclusive and RFC 2634. RFC 2311 also has historical information
240 about the development of S/MIME.
242 1.4. Changes Since S/MIME v3
244 The RSA public key algorithm was changed to a MUST implement key
245 wrapping algorithm, and the Diffie-Hellman algorithm changed to a
246 SHOULD implement.
248 The AES symmetric encryption algorithm has been included as a SHOULD
249 implement.
251 The RSA public key algorithm was changed to a MUST implement
252 signature algorithm.
254 Ambiguous language about the use of "empty" SignedData messages to
255 transmit certificates was clarified to reflect that transmission of
256 certificate revocation lists is also allowed.
258 The use of binary encoding for some MIME entities is now explicitly
259 discussed.
261 Header protection through the use of the message/rfc822 MIME type has
262 been added.
264 Use of the CompressedData CMS type is allowed, along with required
265 MIME type and file extension additions.
267 1.5. Changes Since S/MIME v3.1
269 Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA-
270 OAEP, ECDH, and SHA2 CMS Algorithms. Added CMS Multiple Signers
271 Clarification to CMS reference.
273 Sec 1.3: Added references to S/MIME MSG 3.1 RFCs.
275 Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made
276 SHOULD-.
278 Sec 2.2 (signature algorithms): RSA with SHA256 added as the MUST,
279 RSA with SHA-1 changed to MUST-, DSA with SHA-1, and RSA with MD5
280 changed to SHOULD-, and RSA-PS with SHA-256, ECDSA with SHA-256 added
281 as SHOULD+. Also added note about what S/MIME v3.1 clients support.
283 Sec 2.3 (key encryption): DH changed to SHOULD-, RSA-OAEP added as
284 SHOULD+, ECDH added as SHOULD+.
286 Sec 2.5.2.1, 2.7, 2.7.1, Appendix A: reference to RC2/40 removed.
288 Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and
289 AES-256 CBC SHOULD+, tripleDES now SHOULD-.
291 Sec 4: Updated reference to CERT v3.2.
293 2. CMS Options
295 CMS allows for a wide variety of options in content and algorithm
296 support. This section puts forth a number of support requirements
297 and recommendations in order to achieve a base level of
298 interoperability among all S/MIME implementations. [CMSALG] and [CMS-
299 SHA2] provides additional details regarding the use of the
300 cryptographic algorithms.
302 2.1. DigestAlgorithmIdentifier
304 Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and
305 SHOULD- support SHA-1 [CMSALG]. Receiving agents SHOULD- support MD5
306 [CMSALG] for the purpose of providing backward compatibility with
307 MD5-digested S/MIME v2 SignedData objects.
309 2.2. SignatureAlgorithmIdentifier
311 Receiving and sending agents:
313 - MUST support RSA with SHA-256, as specified in [CMS-SHA2]
315 - MUST- support RSA with SHA-1, as specified in [CMSALG]
317 - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
319 - SHOULD+ support ECDSA with SHA-256, as specified in [CMS-SHA2]
321 - SHOULD- support DSA with SHA-1, as specified in [CMSALG]
323 - SHOULD- support RSA with MD5, as specified in [CMSALG].
325 Note that S/MIME v3.1 client support verifying id-dsa-with-sha1 and
326 rsaEncryption and might not implement sha256withRSAEncryption. Note
327 that S/MIME v3 clients might only implement signing or signature
328 verification using id-dsa-with-sha1, and might also use id-dsa as an
329 AlgorithmIdentifier in this field. Receiving clients SHOULD
330 recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
331 clients MUST use id-dsa-with-sha1 if using that algorithm. Also note
332 that S/MIME v2 clients are only required to verify digital signatures
333 using the rsaEncryption algorithm with SHA-1 or MD5, and might not
334 implement id-dsa-with-sha1 or id-dsa at all.
336 2.3. KeyEncryptionAlgorithmIdentifier
338 Receiving and sending agents:
340 - MUST support RSA Encryption, as specified in [CMSALG]
342 - SHOULD+ support RSA-OAEP, as specified in [RSAOAEP]
344 - SHOULD+ support ECDH, as specified in [CMSECC]
346 - SHOULD- support DH ephemeral-static mode, as specified
347 in [CMSALG].
349 Note that S/MIME v3.1 clients might only implement key encryption and
350 decryption using rsaEncryption algorithm. Note that S/MIME v3 clients
351 might only implement key encryption and decryption using the Diffie-
352 Hellman algorithm. Also note that S/MIME v2 clients are only capable
353 of decrypting content-encryption keys using the rsaEncryption
354 algorithm.
356 2.4. General Syntax
358 There are several CMS content types. Of these, only the Data,
359 SignedData, EnvelopedData, and CompressedData content types are
360 currently used for S/MIME.
362 2.4.1. Data Content Type
364 Sending agents MUST use the id-data content type identifier to
365 identify the "inner" MIME message content. For example, when
366 applying a digital signature to MIME data, the CMS SignedData
367 encapContentInfo eContentType MUST include the id-data object
368 identifier and the MIME content MUST be stored in the SignedData
369 encapContentInfo eContent OCTET STRING (unless the sending agent is
370 using multipart/signed, in which case the eContent is absent, per
371 section 3.4.3 of this document). As another example, when applying
372 encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
373 contentType MUST include the id-data object identifier and the
374 encrypted MIME content MUST be stored in the EnvelopedData
375 encryptedContentInfo encryptedContent OCTET STRING.
377 2.4.2. SignedData Content Type
379 Sending agents MUST use the SignedData content type to apply a
380 digital signature to a message or, in a degenerate case where there
381 is no signature information, to convey certificates. Applying a
382 signature to a message provides authentication, message integrity,
383 and non-repudiation of origin.
385 2.4.3. EnvelopedData Content Type
387 This content type is used to apply data confidentiality to a message.
388 A sender needs to have access to a public key for each intended
389 message recipient to use this service.
391 2.4.4. CompressedData Content Type
393 This content type is used to apply data compression to a message.
394 This content type does not provide authentication, message integrity,
395 non-repudiation, or data confidentiality, and is only used to reduce
396 message size.
398 See section 3.6 for further guidance on the use of this type in
399 conjunction with other CMS types.
401 2.5. Attributes and the SignerInfo Type
403 The SignerInfo type allows the inclusion of unsigned and signed
404 attributes to be included along with a signature.
406 Receiving agents MUST be able to handle zero or one instance of each
407 of the signed attributes listed here. Sending agents SHOULD generate
408 one instance of each of the following signed attributes in each
409 S/MIME message:
411 - signingTime (section 2.5.1 in this document)
413 - sMIMECapabilities (section 2.5.2 in this document)
415 - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
417 - id-messageDigest (section 11.2 in [CMS])
418 - id-contentType (section 11.1 in [CMS])
420 Further, receiving agents SHOULD be able to handle zero or one
421 instance in the signingCertificate signed attribute, as defined in
422 section 5 of [ESS].
424 Sending agents SHOULD generate one instance of the signingCertificate
425 signed attribute in each SignerInfo structure.
427 Additional attributes and values for these attributes might be
428 defined in the future. Receiving agents SHOULD handle attributes or
429 values that it does not recognize in a graceful manner.
431 Interactive sending agents that include signed attributes that are
432 not listed here SHOULD display those attributes to the user, so that
433 the user is aware of all of the data being signed.
435 2.5.1. Signing-Time Attribute
437 The signing-time attribute is used to convey the time that a message
438 was signed. The time of signing will most likely be created by a
439 message originator and therefore is only as trustworthy as the
440 originator.
442 Sending agents MUST encode signing time through the year 2049 as
443 UTCTime; signing times in 2050 or later MUST be encoded as
444 GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
445 interpret the year field (YY) as follows:
447 If YY is greater than or equal to 50, the year is interpreted as
448 19YY; if YY is less than 50, the year is interpreted as 20YY.
450 2.5.2. SMIMECapabilities Attribute
452 The SMIMECapabilities attribute includes signature algorithms (such
453 as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-
454 EDE3-CBC"), and key encipherment algorithms (such as
455 "rsaEncryption"). There are also several identifiers which indicate
456 support for other optional features such as binary encoding and
457 compression. The SMIMECapabilities were designed to be flexible and
458 extensible so that, in the future, a means of identifying other
459 capabilities and preferences such as certificates can be added in a
460 way that will not cause current clients to break.
462 If present, the SMIMECapabilities attribute MUST be a
463 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
464 SignedAttributes as a SET OF Attribute. The SignedAttributes in a
465 signerInfo MUST NOT include multiple instances of the
466 SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
467 Attribute to include attrValues SET OF AttributeValue. A
468 SMIMECapabilities attribute MUST only include a single instance of
469 AttributeValue. There MUST NOT be zero or multiple instances of
470 AttributeValue present in the attrValues SET OF AttributeValue.
472 The semantics of the SMIMECapabilities attribute specify a partial
473 list as to what the client announcing the SMIMECapabilities can
474 support. A client does not have to list every capability it
475 supports, and need not list all its capabilities so that the
476 capabilities list doesn't get too long. In an SMIMECapabilities
477 attribute, the object identifiers (OIDs) are listed in order of their
478 preference, but SHOULD be separated logically along the lines of
479 their categories (signature algorithms, symmetric algorithms, key
480 encipherment algorithms, etc.)
482 The structure of the SMIMECapabilities attribute is to facilitate
483 simple table lookups and binary comparisons in order to determine
484 matches. For instance, the DER-encoding for the SMIMECapability for
485 DES EDE3 CBC MUST be identically encoded regardless of the
486 implementation. Because of the requirement for identical encoding,
487 individuals documenting algorithms to be used in the
488 SMIMECapabilities attribute SHOULD explicitly document the correct
489 byte sequence for the common cases.
491 For any capability, the associated parameters for the OID MUST
492 specify all of the parameters necessary to differentiate between two
493 instances of the same algorithm. For instance, the number of rounds
494 and the block size for RC5 needs to be specified in addition to the
495 key length.
497 The OIDs that correspond to algorithms SHOULD use the same OID as the
498 actual algorithm, except in the case where the algorithm usage is
499 ambiguous from the OID. For instance, in an earlier specification,
500 rsaEncryption was ambiguous because it could refer to either a
501 signature algorithm or a key encipherment algorithm. In the event
502 that an OID is ambiguous, it needs to be arbitrated by the maintainer
503 of the registered SMIMECapabilities list as to which type of
504 algorithm will use the OID, and a new OID MUST be allocated under the
505 smimeCapabilities OID to satisfy the other use of the OID.
507 The registered SMIMECapabilities list specifies the parameters for
508 OIDs that need them, most notably key lengths in the case of
509 variable-length symmetric ciphers. In the event that there are no
510 differentiating parameters for a particular OID, the parameters MUST
511 be omitted, and MUST NOT be encoded as NULL. Additional values for
512 the SMIMECapabilities attribute might be defined in the future.
513 Receiving agents MUST handle a SMIMECapabilities object that has
514 values that it does not recognize in a graceful manner.
516 Section 2.7.1 explains a strategy for caching capabilities.
518 2.5.3. Encryption Key Preference Attribute
520 The encryption key preference attribute allows the signer to
521 unambiguously describe which of the signer's certificates has the
522 signer's preferred encryption key. This attribute is designed to
523 enhance behavior for interoperating with those clients that use
524 separate keys for encryption and signing. This attribute is used to
525 convey to anyone viewing the attribute which of the listed
526 certificates is appropriate for encrypting a session key for future
527 encrypted messages.
529 If present, the SMIMEEncryptionKeyPreference attribute MUST be a
530 SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
531 SignedAttributes as a SET OF Attribute. The SignedAttributes in a
532 signerInfo MUST NOT include multiple instances of the
533 SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
534 for Attribute to include attrValues SET OF AttributeValue. A
535 SMIMEEncryptionKeyPreference attribute MUST only include a single
536 instance of AttributeValue. There MUST NOT be zero or multiple
537 instances of AttributeValue present in the attrValues SET OF
538 AttributeValue.
540 The sending agent SHOULD include the referenced certificate in the
541 set of certificates included in the signed message if this attribute
542 is used. The certificate MAY be omitted if it has been previously
543 made available to the receiving agent. Sending agents SHOULD use
544 this attribute if the commonly used or preferred encryption
545 certificate is not the same as the certificate used to sign the
546 message.
548 Receiving agents SHOULD store the preference data if the signature on
549 the message is valid and the signing time is greater than the
550 currently stored value. (As with the SMIMECapabilities, the clock
551 skew SHOULD be checked and the data not used if the skew is too
552 great.) Receiving agents SHOULD respect the sender's encryption key
553 preference attribute if possible. This, however, represents only a
554 preference and the receiving agent can use any certificate in
555 replying to the sender that is valid.
557 Section 2.7.1 explains a strategy for caching preference data.
559 2.5.3.1. Selection of Recipient Key Management Certificate
561 In order to determine the key management certificate to be used when
562 sending a future CMS EnvelopedData message for a particular
563 recipient, the following steps SHOULD be followed:
565 - If an SMIMEEncryptionKeyPreference attribute is found in a
566 SignedData object received from the desired recipient, this
567 identifies the X.509 certificate that SHOULD be used as the X.509
568 key management certificate for the recipient.
570 - If an SMIMEEncryptionKeyPreference attribute is not found in a
571 SignedData object received from the desired recipient, the set of
572 X.509 certificates SHOULD be searched for a X.509 certificate
573 with the same subject name as the signing of a X.509 certificate
574 which can be used for key management.
576 - Or use some other method of determining the user's key management
577 key. If a X.509 key management certificate is not found, then
578 encryption cannot be done with the signer of the message. If
579 multiple X.509 key management certificates are found, the S/MIME
580 agent can make an arbitrary choice between them.
582 2.6. SignerIdentifier SignerInfo Type
584 S/MIME v3.2 implementations MUST support both issuerAndSerialNumber
585 as well as subjectKeyIdentifier. Messages that use the
586 subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
588 It is important to understand that some certificates use a value for
589 subjectKeyIdentifier that is not suitable for uniquely identifying a
590 certificate. Implementations MUST be prepared for multiple
591 certificates for potentially different entities to have the same
592 value for subjectKeyIdentifier, and MUST be prepared to try each
593 matching certificate during signature verification before indicating
594 an error condition.
596 2.7. ContentEncryptionAlgorithmIdentifier
598 Sending and receiving agents:
600 - MUST support encryption and decryption with AES-128 CBC [CMSAES]
602 - SHOULD+ support encryption and decryption with AES-192 CBC and
603 AES-256 CBC [CMSAES]
605 - SHOULD- support encryption and decryption with DES EDE3 CBC,
606 hereinafter called "tripleDES" [CMSALG].
608 2.7.1. Deciding Which Encryption Method To Use
610 When a sending agent creates an encrypted message, it has to decide
611 which type of encryption to use. The decision process involves using
612 information garnered from the capabilities lists included in messages
613 received from the recipient, as well as out-of-band information such
614 as private agreements, user preferences, legal restrictions, and so
615 on.
617 Section 2.5.2 defines a method by which a sending agent can
618 optionally announce, among other things, its decrypting capabilities
619 in its order of preference. The following method for processing and
620 remembering the encryption capabilities attribute in incoming signed
621 messages SHOULD be used.
623 - If the receiving agent has not yet created a list of capabilities
624 for the sender's public key, then, after verifying the signature
625 on the incoming message and checking the timestamp, the receiving
626 agent SHOULD create a new list containing at least the signing
627 time and the symmetric capabilities.
629 - If such a list already exists, the receiving agent SHOULD verify
630 that the signing time in the incoming message is greater than the
631 signing time stored in the list and that the signature is valid.
632 If so, the receiving agent SHOULD update both the signing time
633 and capabilities in the list. Values of the signing time that
634 lie far in the future (that is, a greater discrepancy than any
635 reasonable clock skew), or a capabilities list in messages whose
636 signature could not be verified, MUST NOT be accepted.
638 The list of capabilities SHOULD be stored for future use in creating
639 messages.
641 Before sending a message, the sending agent MUST decide whether it is
642 willing to use weak encryption for the particular data in the
643 message. If the sending agent decides that weak encryption is
644 unacceptable for this data, then the sending agent MUST NOT use a
645 weak algorithm. The decision to use or not use weak encryption
646 overrides any other decision in this section about which encryption
647 algorithm to use.
649 Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending
650 agent SHOULD use in deciding which type of encryption will be applied
651 to a message. These rules are ordered, so the sending agent SHOULD
652 make its decision in the order given.
654 2.7.1.1. Rule 1: Known Capabilities
656 If the sending agent has received a set of capabilities from the
657 recipient for the message the agent is about to encrypt, then the
658 sending agent SHOULD use that information by selecting the first
659 capability in the list (that is, the capability most preferred by the
660 intended recipient) that the sending agent knows how to encrypt. The
661 sending agent SHOULD use one of the capabilities in the list if the
662 agent reasonably expects the recipient to be able to decrypt the
663 message.
665 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
667 If the following two conditions are met:
669 - The sending agent has no knowledge of the encryption capabilities
670 of the recipient; and,
672 - The sending agent has no knowledge of the version of S/MIME of the
673 recipient, then the sending agent SHOULD use AES 128 because it
674 is a stronger algorithm and is required by S/MIME v3.2. If the
675 sending agent chooses not to use AES 128 in this step, it SHOULD
676 use tripleDES.
678 2.7.2. Choosing Weak Encryption
680 All algorithms that use 40 bit keys are considered by many to be weak
681 encryption. A sending agent that is controlled by a human SHOULD
682 allow a human sender to determine the risks of sending data using
683 weak encryption algorithm before sending the data, and possibly allow
684 the human to use a stronger encryption method such as tripleDES or
685 AES.
687 2.7.3. Multiple Recipients
689 If a sending agent is composing an encrypted message to a group of
690 recipients where the encryption capabilities of some of the
691 recipients do not overlap, the sending agent is forced to send more
692 than one message. Please note that if the sending agent chooses to
693 send a message encrypted with a strong algorithm, and then send the
694 same message encrypted with a weak algorithm, someone watching the
695 communications channel could learn the contents of the strongly-
696 encrypted message simply by decrypting the weakly-encrypted message.
698 3. Creating S/MIME Messages
700 This section describes the S/MIME message formats and how they are
701 created. S/MIME messages are a combination of MIME bodies and CMS
702 content types. Several MIME types as well as several CMS content
703 types are used. The data to be secured is always a canonical MIME
704 entity. The MIME entity and other data, such as certificates and
705 algorithm identifiers, are given to CMS processing facilities which
706 produce a CMS object. Finally, the CMS object is wrapped in MIME.
707 The Enhanced Security Services for S/MIME [ESS] document provides
708 descriptions of how nested, secured S/MIME messages are formatted.
709 ESS provides a description of how a triple-wrapped S/MIME message is
710 formatted using multipart/signed and application/pkcs7-mime for the
711 signatures.
713 S/MIME provides one format for enveloped-only data, several formats
714 for signed-only data, and several formats for signed and enveloped
715 data. Several formats are required to accommodate several
716 environments, in particular for signed messages. The criteria for
717 choosing among these formats are also described.
719 The reader of this section is expected to understand MIME as
720 described in [MIME-SPEC] and [MIME-SECURE].
722 3.1. Preparing the MIME Entity for Signing, Enveloping or Compressing
724 S/MIME is used to secure MIME entities. A MIME entity can be a sub-
725 part, sub-parts of a message, or the whole message with all its sub-
726 parts. A MIME entity that is the whole message includes only the
727 MIME headers and MIME body, and does not include the RFC-822 headers.
728 Note that S/MIME can also be used to secure MIME entities used in
729 applications other than Internet mail. If protection of the RFC-822
730 headers is required, the use of the message/rfc822 MIME type is
731 explained later in this section.
733 The MIME entity that is secured and described in this section can be
734 thought of as the "inside" MIME entity. That is, it is the
735 "innermost" object in what is possibly a larger MIME message.
736 Processing "outside" MIME entities into CMS content types is
737 described in Section 3.2, 3.4, and elsewhere.
739 The procedure for preparing a MIME entity is given in [MIME-SPEC].
740 The same procedure is used here with some additional restrictions
741 when signing. Description of the procedures from [MIME-SPEC] are
742 repeated here, but it is suggested that the reader refer to that
743 document for the exact procedure. This section also describes
744 additional requirements.
746 A single procedure is used for creating MIME entities that are to
747 have any combination of signing, enveloping, and compressing applied.
748 Some additional steps are recommended to defend against known
749 corruptions that can occur during mail transport that are of
750 particular importance for clear-signing using the multipart/signed
751 format. It is recommended that these additional steps be performed
752 on enveloped messages, or signed and enveloped messages, so that the
753 message can be forwarded to any environment without modification.
755 These steps are descriptive rather than prescriptive. The
756 implementer is free to use any procedure as long as the result is the
757 same.
759 Step 1. The MIME entity is prepared according to the local
760 conventions.
762 Step 2. The leaf parts of the MIME entity are converted to
763 canonical form.
765 Step 3. Appropriate transfer encoding is applied to the leaves
766 of the MIME entity.
768 When an S/MIME message is received, the security services on the
769 message are processed, and the result is the MIME entity. That MIME
770 entity is typically passed to a MIME-capable user agent where, it is
771 further decoded and presented to the user or receiving application.
773 In order to protect outer, non-content related message headers (for
774 nstance, the "Subject", "To", "From" and "CC" fields), the sending
775 client MAY wrap a full MIME message in a message/rfc822 wrapper in
776 order to apply S/MIME security services to these headers. It is up
777 to the receiving client to decide how to present these "inner"
778 headers along with the unprotected "outer" headers.
780 When an S/MIME message is received, if the top-level protected MIME
781 entity has a Content-Type of message/rfc822, it can be assumed that
782 the intent was to provide header protection. This entity SHOULD be
783 presented as the top-level message, taking into account header
784 merging issues as previously discussed.
786 3.1.1. Canonicalization
788 Each MIME entity MUST be converted to a canonical form that is
789 uniquely and unambiguously representable in the environment where the
790 signature is created and the environment where the signature will be
791 verified. MIME entities MUST be canonicalized for enveloping and
792 compressing as well as signing.
794 The exact details of canonicalization depend on the actual MIME type
795 and subtype of an entity, and are not described here. Instead, the
796 standard for the particular MIME type SHOULD be consulted. For
797 example, canonicalization of type text/plain is different from
798 canonicalization of audio/basic. Other than text types, most types
799 have only one representation regardless of computing platform or
800 environment which can be considered their canonical representation.
801 In general, canonicalization will be performed by the non-security
802 part of the sending agent rather than the S/MIME implementation.
804 The most common and important canonicalization is for text, which is
805 often represented differently in different environments. MIME
806 entities of major type "text" MUST have both their line endings and
807 character set canonicalized. The line ending MUST be the pair of
808 characters , and the charset SHOULD be a registered charset
809 [CHARSETS]. The details of the canonicalization are specified in
810 [MIME-SPEC]. The chosen charset SHOULD be named in the charset
811 parameter so that the receiving agent can unambiguously determine the
812 charset used.
814 Note that some charsets such as ISO-2022 have multiple
815 representations for the same characters. When preparing such text
816 for signing, the canonical representation specified for the charset
817 MUST be used.
819 3.1.2. Transfer Encoding
821 When generating any of the secured MIME entities below, except the
822 signing using the multipart/signed format, no transfer encoding is
823 required at all. S/MIME implementations MUST be able to deal with
824 binary MIME objects. If no Content-Transfer-Encoding header is
825 present, the transfer encoding is presumed to be 7BIT.
827 S/MIME implementations SHOULD however use transfer encoding described
828 in section 3.1.3 for all MIME entities they secure. The reason for
829 securing only 7-bit MIME entities, even for enveloped data that are
830 not exposed to the transport, is that it allows the MIME entity to be
831 handled in any environment without changing it. For example, a
832 trusted gateway might remove the envelope, but not the signature, of
833 a message, and then forward the signed message on to the end
834 recipient so that they can verify the signatures directly. If the
835 transport internal to the site is not 8-bit clean, such as on a wide-
836 area network with a single mail gateway, verifying the signature will
837 not be possible unless the original MIME entity was only 7-bit data.
839 S/MIME implementations which "know" that all intended recipient(s)
840 are capable of handling inner (all but the outermost) binary MIME
841 objects SHOULD use binary encoding as opposed to a 7-bit-safe
842 transfer encoding for the inner entities. The use of a 7-bit-safe
843 encoding (such as base64) would unnecessarily expand the message
844 size. Implementations MAY "know" that recipient implementations are
845 capable of handling inner binary MIME entities either by interpreting
846 the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
847 agreement, or by other means.
849 If one or more intended recipients are unable to handle inner binary
850 MIME objects, or if this capability is unknown for any of the
851 intended recipients, S/MIME implementations SHOULD use transfer
852 encoding described in section 3.1.3 for all MIME entities they
853 secure.
855 3.1.3. Transfer Encoding for Signing Using multipart/signed
857 If a multipart/signed entity is ever to be transmitted over the
858 standard Internet SMTP infrastructure or other transport that is
859 constrained to 7-bit text, it MUST have transfer encoding applied so
860 that it is represented as 7-bit text. MIME entities that are 7-bit
861 data already need no transfer encoding. Entities such as 8-bit text
862 and binary data can be encoded with quoted-printable or base-64
863 transfer encoding.
865 The primary reason for the 7-bit requirement is that the Internet
866 mail transport infrastructure cannot guarantee transport of 8-bit or
867 binary data. Even though many segments of the transport
868 infrastructure now handle 8-bit and even binary data, it is sometimes
869 not possible to know whether the transport path is 8-bit clean. If a
870 mail message with 8-bit data were to encounter a message transfer
871 agent that can not transmit 8-bit or binary data, the agent has three
872 options, none of which are acceptable for a clear-signed message:
874 - The agent could change the transfer encoding; this would
875 invalidate the signature.
877 - The agent could transmit the data anyway, which would most likely
878 result in the 8th bit being corrupted; this too would invalidate
879 the signature.
881 - The agent could return the message to the sender.
883 [MIME-SECURE] prohibits an agent from changing the transfer encoding
884 of the first part of a multipart/signed message. If a compliant
885 agent that can not transmit 8-bit or binary data encounters a
886 multipart/signed message with 8-bit or binary data in the first part,
887 it would have to return the message to the sender as undeliverable.
889 3.1.4. Sample Canonical MIME Entity
891 This example shows a multipart/mixed message with full transfer
892 encoding. This message contains a text part and an attachment. The
893 sample message text includes characters that are not US-ASCII and
894 thus need to be transfer encoded. Though not shown here, the end of
895 each line is . The line ending of the MIME headers, the
896 text, and transfer encoded parts, all MUST be .
898 Note that this example is not of an S/MIME message.
900 Content-Type: multipart/mixed; boundary=bar
902 --bar
903 Content-Type: text/plain; charset=iso-8859-1
904 Content-Transfer-Encoding: quoted-printable
906 =A1Hola Michael!
908 How do you like the new S/MIME specification?
910 It's generally a good idea to encode lines that begin with
911 From=20because some mail transport agents will insert a greater-
912 than (>) sign, thus invalidating the signature.
914 Also, in some cases it might be desirable to encode any =20
915 trailing whitespace that occurs on lines in order to ensure =20
916 that the message signature is not invalidated when passing =20
917 a gateway that modifies such whitespace (like BITNET). =20
919 --bar
920 Content-Type: image/jpeg
921 Content-Transfer-Encoding: base64
923 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
924 jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
925 uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
926 HOxEa44b+EI=
928 --bar--
930 3.2. The application/pkcs7-mime Type
932 The application/pkcs7-mime type is used to carry CMS content types
933 including EnvelopedData, SignedData, and CompressedData. The details
934 of constructing these entities are described in subsequent sections.
936 This section describes the general characteristics of the
937 application/pkcs7-mime type.
939 The carried CMS object always contains a MIME entity that is prepared
940 as described in section 3.1 if the eContentType is id-data. Other
941 contents MAY be carried when the eContentType contains different
942 values. See [ESS] for an example of this with signed receipts.
944 Since CMS content types are binary data, in most cases base-64
945 transfer encoding is appropriate, in particular, when used with SMTP
946 transport. The transfer encoding used depends on the transport
947 through which the object is to be sent, and is not a characteristic
948 of the MIME type.
950 Note that this discussion refers to the transfer encoding of the CMS
951 object or "outside" MIME entity. It is completely distinct from, and
952 unrelated to, the transfer encoding of the MIME entity secured by the
953 CMS object, the "inside" object, which is described in section 3.1.
955 Because there are several types of application/pkcs7-mime objects, a
956 sending agent SHOULD do as much as possible to help a receiving agent
957 know about the contents of the object without forcing the receiving
958 agent to decode the ASN.1 for the object. The MIME headers of all
959 application/pkcs7-mime objects SHOULD include the optional "smime-
960 type" parameter, as described in the following sections.
962 3.2.1. The name and filename Parameters
964 For the application/pkcs7-mime, sending agents SHOULD emit the
965 optional "name" parameter to the Content-Type field for compatibility
966 with older systems. Sending agents SHOULD also emit the optional
967 Content-Disposition field [CONTDISP] with the "filename" parameter.
968 If a sending agent emits the above parameters, the value of the
969 parameters SHOULD be a file name with the appropriate extension:
971 MIME Type File Extension
972 application/pkcs7-mime (SignedData, EnvelopedData) .p7m
973 application/pkcs7-mime (degenerate SignedData .p7c
974 certificate management message)
975 application/pkcs7-mime (CompressedData) .p7z
976 application/pkcs7-signature (SignedData) .p7s
978 In addition, the file name SHOULD be limited to eight characters
979 followed by a three letter extension. The eight character filename
980 base can be any distinct name; the use of the filename base "smime"
981 SHOULD be used to indicate that the MIME entity is associated with
982 S/MIME.
984 Including a file name serves two purposes. It facilitates easier use
985 of S/MIME objects as files on disk. It also can convey type
986 information across gateways. When a MIME entity of type
987 application/pkcs7-mime (for example) arrives at a gateway that has no
988 special knowledge of S/MIME, it will default the entity's MIME type
989 to application/octet-stream and treat it as a generic attachment,
990 thus losing the type information. However, the suggested filename
991 for an attachment is often carried across a gateway. This often
992 allows the receiving systems to determine the appropriate application
993 to hand the attachment off to, in this case, a stand-alone S/MIME
994 processing application. Note that this mechanism is provided as a
995 convenience for implementations in certain environments. A proper
996 S/MIME implementation MUST use the MIME types and MUST NOT rely on
997 the file extensions.
999 3.2.2. The smime-type parameter
1001 The application/pkcs7-mime content type defines the optional "smime-
1002 type" parameter. The intent of this parameter is to convey details
1003 about the security applied (signed or enveloped) along with
1004 information about the contained content. This specification defines
1005 the following smime-types.
1007 Name CMS type Inner Content
1008 enveloped-data EnvelopedData id-data
1009 signed-data SignedData id-data
1010 certs-only SignedData none
1011 compressed-data CompressedData id-data
1013 In order for consistency to be obtained with future specifications,
1014 the following guidelines SHOULD be followed when assigning a new
1015 smime-type parameter.
1017 1. If both signing and encryption can be applied to the content,
1018 then two values for smime-type SHOULD be assigned "signed-*" and
1019 "encrypted-*". If one operation can be assigned then this can be
1020 omitted. Thus since "certs-only" can only be signed, "signed-"
1021 is omitted.
1023 2. A common string for a content OID SHOULD be assigned. We use
1024 "data" for the id-data content OID when MIME is the inner
1025 content.
1027 3. If no common string is assigned. Then the common string of
1028 "OID." is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
1029 would be DES40).
1031 It is explicitly intended that this field be a suitable hint for mail
1032 client applications to indicate whether a message is "signed" or
1033 "encrypted" without having to tunnel into the CMS payload.
1035 3.3. Creating an Enveloped-only Message
1037 This section describes the format for enveloping a MIME entity
1038 without signing it. It is important to note that sending enveloped
1039 but not signed messages does not provide for data integrity. It is
1040 possible to replace ciphertext in such a way that the processed
1041 message will still be valid, but the meaning can be altered.
1043 Step 1. The MIME entity to be enveloped is prepared according to
1044 section 3.1.
1046 Step 2. The MIME entity and other required data is processed
1047 into a CMS object of type EnvelopedData. In addition to
1048 encrypting a copy of the content-encryption key for each
1049 recipient, a copy of the content-encryption key SHOULD be
1050 encrypted for the originator and included in the EnvelopedData
1051 (see [CMS] Section 6).
1053 Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo
1054 object.
1056 Step 4. The ContentInfo object is inserted into an
1057 application/pkcs7-mime MIME entity.
1059 The smime-type parameter for enveloped-only messages is "enveloped-
1060 data". The file extension for this type of message is ".p7m".
1062 A sample message would be:
1064 Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
1065 name=smime.p7m
1066 Content-Transfer-Encoding: base64
1067 Content-Disposition: attachment; filename=smime.p7m
1069 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
1070 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
1071 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1072 0GhIGfHfQbnj756YT64V
1074 3.4. Creating a Signed-only Message
1076 There are two formats for signed messages defined for S/MIME:
1078 - application/pkcs7-mime with SignedData; and,
1080 - multipart/signed.
1082 In general, the multipart/signed form is preferred for sending, and
1083 receiving agents MUST be able to handle both.
1085 3.4.1. Choosing a Format for Signed-only Messages
1087 There are no hard-and-fast rules when a particular signed-only format
1088 is chosen because it depends on the capabilities of all the receivers
1089 and the relative importance of receivers with S/MIME facilities being
1090 able to verify the signature versus the importance of receivers
1091 without S/MIME software being able to view the message.
1093 Messages signed using the multipart/signed format can always be
1094 viewed by the receiver whether they have S/MIME software or not. They
1095 can also be viewed whether they are using a MIME-native user agent or
1096 they have messages translated by a gateway. In this context, "be
1097 viewed" means the ability to process the message essentially as if it
1098 were not a signed message, including any other MIME structure the
1099 message might have.
1101 Messages signed using the SignedData format cannot be viewed by a
1102 recipient unless they have S/MIME facilities. However, the
1103 SignedData format protects the message content from being changed by
1104 benign intermediate agents. Such agents might do line wrapping or
1105 content-transfer encoding changes which would break the signature.
1107 3.4.2. Signing Using application/pkcs7-mime with SignedData
1109 This signing format uses the application/pkcs7-mime MIME type. The
1110 steps to create this format are:
1112 Step 1. The MIME entity is prepared according to section 3.1.
1114 Step 2. The MIME entity and other required data is processed
1115 into a CMS object of type SignedData.
1117 Step 3. The SignedData object is wrapped in a CMS ContentInfo
1118 object.
1120 Step 4. The ContentInfo object is inserted into an
1121 application/pkcs7-mime MIME entity.
1123 The smime-type parameter for messages using application/pkcs7-mime
1124 with SignedData is "signed-data". The file extension for this type
1125 of message is ".p7m".
1127 A sample message would be:
1129 Content-Type: application/pkcs7-mime; smime-type=signed-data;
1130 name=smime.p7m
1131 Content-Transfer-Encoding: base64
1132 Content-Disposition: attachment; filename=smime.p7m
1134 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
1135 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
1136 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
1137 6YT64V0GhIGfHfQbnj75
1139 3.4.3. Signing Using the multipart/signed Format
1141 This format is a clear-signing format. Recipients without any S/MIME
1142 or CMS processing facilities are able to view the message. It makes
1143 use of the multipart/signed MIME type described in [MIME-SECURE]. The
1144 multipart/signed MIME type has two parts. The first part contains
1145 the MIME entity that is signed; the second part contains the
1146 "detached signature" CMS SignedData object in which the
1147 encapContentInfo eContent field is absent.
1149 3.4.3.1. The application/pkcs7-signature MIME Type
1151 This MIME type always contains a CMS ContentInfo containing a single
1152 CMS object of type SignedData. The SignedData encapContentInfo
1153 eContent field MUST be absent. The signerInfos field contains the
1154 signatures for the MIME entity.
1156 The file extension for signed-only messages using application/pkcs7-
1157 signature is ".p7s".
1159 3.4.3.2. Creating a multipart/signed Message
1161 Step 1. The MIME entity to be signed is prepared according to
1162 section 3.1, taking special care for clear-signing.
1164 Step 2. The MIME entity is presented to CMS processing in order
1165 to obtain an object of type SignedData in which the
1166 encapContentInfo eContent field is absent.
1168 Step 3. The MIME entity is inserted into the first part of a
1169 multipart/signed message with no processing other than that
1170 described in section 3.1.
1172 Step 4. Transfer encoding is applied to the "detached signature"
1173 CMS SignedData object and it is inserted into a MIME entity of
1174 type application/pkcs7-signature.
1176 Step 5. The MIME entity of the application/pkcs7-signature is
1177 inserted into the second part of the multipart/signed entity.
1179 The multipart/signed Content type has two required parameters: the
1180 protocol parameter and the micalg parameter.
1182 The protocol parameter MUST be "application/pkcs7-signature". Note
1183 that quotation marks are required around the protocol parameter
1184 because MIME requires that the "/" character in the parameter value
1185 MUST be quoted.
1187 The micalg parameter allows for one-pass processing when the
1188 signature is being verified. The value of the micalg parameter is
1189 dependent on the message digest algorithm(s) used in the calculation
1190 of the Message Integrity Check. If multiple message digest
1191 algorithms are used they MUST be separated by commas per [MIME-
1192 SECURE]. The values to be placed in the micalg parameter SHOULD be
1193 from the following:
1195 Algorithm Value used
1197 MD5 md5
1198 SHA-1 sha1
1199 SHA-224 sha224
1200 SHA-256 sha256
1201 SHA-384 sha384
1202 SHA-512 sha512
1203 Any other (defined separately in algorithm profile or "unknown"
1204 if not defined)
1206 (Historical note: some early implementations of S/MIME emitted and
1207 expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
1208 Receiving agents SHOULD be able to recover gracefully from a micalg
1209 parameter value that they do not recognize.
1211 The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms
1212 [FIPS180-2] are not currently recommended in S/MIME, and are included
1213 here for completeness.
1215 3.4.3.3. Sample multipart/signed Message
1217 Content-Type: multipart/signed;
1218 protocol="application/pkcs7-signature";
1219 micalg=sha1; boundary=boundary42
1221 --boundary42
1222 Content-Type: text/plain
1224 This is a clear-signed message.
1226 --boundary42
1227 Content-Type: application/pkcs7-signature; name=smime.p7s
1228 Content-Transfer-Encoding: base64
1229 Content-Disposition: attachment; filename=smime.p7s
1231 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
1232 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
1233 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1234 7GhIGfHfYT64VQbnj756
1236 --boundary42--
1238 The content that is digested (the first part of the multipart/signed)
1239 are the bytes:
1241 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
1242 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
1243 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
1245 3.5. Creating an Compressed-only Message
1247 This section describes the format for compressing a MIME entity.
1248 Please note that versions of S/MIME prior to version 3.1 did not
1249 specify any use of CompressedData, and will not recognize it. The
1250 use of a capability to indicate the ability to receive CompressedData
1251 is described in [CMSCOMPR] and is the preferred method for
1252 compatibility.
1254 Step 1. The MIME entity to be compressed is prepared according
1255 to section 3.1.
1257 Step 2. The MIME entity and other required data is processed
1258 into a CMS object of type CompressedData.
1260 Step 3. The CompressedData object is wrapped in a CMS
1261 ContentInfo object.
1263 Step 4. The ContentInfo object is inserted into an
1264 application/pkcs7-mime MIME entity.
1266 The smime-type parameter for compressed-only messages is "compressed-
1267 data". The file extension for this type of message is ".p7z".
1269 A sample message would be:
1271 Content-Type: application/pkcs7-mime; smime-type=compressed-data;
1272 name=smime.p7z
1273 Content-Transfer-Encoding: base64
1274 Content-Disposition: attachment; filename=smime.p7z
1276 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
1277 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
1278 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
1279 0GhIGfHfQbnj756YT64V
1281 3.6. Multiple Operations
1283 The signed-only, encrypted-only, and compressed-only MIME formats can
1284 be nested. This works because these formats are all MIME entities
1285 that encapsulate other MIME entities.
1287 An S/MIME implementation MUST be able to receive and process
1288 arbitrarily nested S/MIME within reasonable resource limits of the
1289 recipient computer.
1291 It is possible to apply any of the signing, encrypting, and
1292 compressing operations in any order. It is up to the implementer and
1293 the user to choose. When signing first, the signatories are then
1294 securely obscured by the enveloping. When enveloping first the
1295 signatories are exposed, but it is possible to verify signatures
1296 without removing the enveloping. This can be useful in an
1297 environment were automatic signature verification is desired, as no
1298 private key material is required to verify a signature.
1300 There are security ramifications to choosing whether to sign first or
1301 encrypt first. A recipient of a message that is encrypted and then
1302 signed can validate that the encrypted block was unaltered, but
1303 cannot determine any relationship between the signer and the
1304 unencrypted contents of the message. A recipient of a message that
1305 is signed-then-encrypted can assume that the signed message itself
1306 has not been altered, but that a careful attacker could have changed
1307 the unauthenticated portions of the encrypted message.
1309 When using compression, keep the following guidelines in mind:
1311 - Compression of binary encoded encrypted data is discouraged, since
1312 it will not yield significant compression. Base64 encrypted data
1313 could very well benefit, however.
1315 - If a lossy compression algorithm is used with signing, you will
1316 need to compress first, then sign.
1318 3.7. Creating a Certificate Management Message
1320 The certificate management message or MIME entity is used to
1321 transport certificates and/or certificate revocation lists, such as
1322 in response to a registration request.
1324 Step 1. The certificates and/or certificate revocation lists are
1325 made available to the CMS generating process which creates a CMS
1326 object of type SignedData. The SignedData encapContentInfo
1327 eContent field MUST be absent and signerInfos field MUST be
1328 empty.
1330 Step 2. The SignedData object is wrapped in a CMS ContentInfo
1331 object.
1333 Step 3. The ContentInfo object is enclosed in an
1334 application/pkcs7-mime MIME entity.
1336 The smime-type parameter for a certificate management message is
1337 "certs-only". The file extension for this type of message is ".p7c".
1339 3.8. Registration Requests
1341 A sending agent that signs messages MUST have a certificate for the
1342 signature so that a receiving agent can verify the signature. There
1343 are many ways of getting certificates, such as through an exchange
1344 with a certificate authority, through a hardware token or diskette,
1345 and so on.
1347 S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
1348 with certificate authorities using an application/pkcs10 body part.
1349 Since that time, the IETF PKIX Working Group has developed other
1350 methods for requesting certificates. However, S/MIME v3.2 does not
1351 require a particular certificate request mechanism.
1353 3.9. Identifying an S/MIME Message
1355 Because S/MIME takes into account interoperation in non-MIME
1356 environments, several different mechanisms are employed to carry the
1357 type information, and it becomes a bit difficult to identify S/MIME
1358 messages. The following table lists criteria for determining whether
1359 or not a message is an S/MIME message. A message is considered an
1360 S/MIME message if it matches any of the criteria listed below.
1362 The file suffix in the table below comes from the "name" parameter in
1363 the content-type header, or the "filename" parameter on the content-
1364 disposition header. These parameters that give the file suffix are
1365 not listed below as part of the parameter section.
1367 MIME type: application/pkcs7-mime
1368 parameters: any
1369 file suffix: any
1371 MIME type: multipart/signed
1372 parameters: protocol="application/pkcs7-signature"
1373 file suffix: any
1375 MIME type: application/octet-stream
1376 parameters: any
1377 file suffix: p7m, p7s, p7c, p7z
1379 4. Certificate Processing
1381 A receiving agent MUST provide some certificate retrieval mechanism
1382 in order to gain access to certificates for recipients of digital
1383 envelopes. This specification does not cover how S/MIME agents
1384 handle certificates, only what they do after a certificate has been
1385 validated or rejected. S/MIME certificate issues are covered in
1386 [CERT32].
1388 At a minimum, for initial S/MIME deployment, a user agent could
1389 automatically generate a message to an intended recipient requesting
1390 that recipient's certificate in a signed return message. Receiving
1391 and sending agents SHOULD also provide a mechanism to allow a user to
1392 "store and protect" certificates for correspondents in such a way so
1393 as to guarantee their later retrieval.
1395 4.1. Key Pair Generation
1397 All generated key pairs MUST be generated from a good source of non-
1398 deterministic random input [RANDOM] and the private key MUST be
1399 protected in a secure fashion.
1401 If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
1402 agent or some related administrative utility or function SHOULD
1403 generate RSA key pairs using the following guidelines. A user agent
1404 SHOULD generate RSA key pairs at a minimum key size of 768 bits. A
1405 user agent MUST NOT generate RSA key pairs less than 512 bits long.
1406 Creating keys longer than 1024 bits can cause some older S/MIME
1407 receiving agents to not be able to verify signatures, but gives
1408 better security and is therefore valuable. A receiving agent SHOULD
1409 be able to verify signatures with keys of any size over 512 bits.
1410 Some agents created in the United States have chosen to create 512
1411 bit keys in order to get more advantageous export licenses. However,
1412 512 bit keys are considered by many to be cryptographically insecure.
1413 Implementers SHOULD be aware that multiple (active) key pairs can be
1414 associated with a single individual. For example, one key pair can
1415 be used to support confidentiality, while a different key pair can be
1416 used for authentication.
1418 5. IANA Considerations
1420 None: All identifiers are already registered. Please remove this
1421 section prior to publication as an RFC.
1423 6. Security Considerations
1425 40-bit encryption is considered weak by most cryptographers. Using
1426 weak cryptography in S/MIME offers little actual security over
1427 sending plaintext. However, other features of S/MIME, such as the
1428 specification of tripleDES and the ability to announce stronger
1429 cryptographic capabilities to parties with whom you communicate,
1430 allow senders to create messages that use strong encryption. Using
1431 weak cryptography is never recommended unless the only alternative is
1432 no cryptography. When feasible, sending and receiving agents SHOULD
1433 inform senders and recipients of the relative cryptographic strength
1434 of messages.
1436 It is impossible for most software or people to estimate the value of
1437 a message. Further, it is impossible for most software or people to
1438 estimate the actual cost of decrypting a message that is encrypted
1439 with a key of a particular size. Further, it is quite difficult to
1440 determine the cost of a failed decryption if a recipient cannot
1441 decode a message. Thus, choosing between different key sizes (or
1442 choosing whether to just use plaintext) is also impossible. However,
1443 decisions based on these criteria are made all the time, and
1444 therefore this specification gives a framework for using those
1445 estimates in choosing algorithms.
1447 If a sending agent is sending the same message using different
1448 strengths of cryptography, an attacker watching the communications
1449 channel might be able to determine the contents of the strongly-
1450 encrypted message by decrypting the weakly-encrypted version. In
1451 other words, a sender SHOULD NOT send a copy of a message using
1452 weaker cryptography than they would use for the original of the
1453 message.
1455 Modification of the ciphertext can go undetected if authentication is
1456 not also used, which is the case when sending EnvelopedData without
1457 wrapping it in SignedData or enclosing SignedData within it.
1459 See RFC 3218 [MMA] for more information about thwarting the adaptive
1460 chosen ciphertext vulnerability in PKCS #1 Version 1.5
1461 implementations.
1463 In some circumstances the use of the Diffie-Hellman key agreement
1464 scheme in a prime order subgroup of a large prime p is vulnerable to
1465 certain attacks known as "small-subgroup" attacks. Methods exist,
1466 however, to prevent these attacks. These methods are described in
1467 RFC 2785 [DHSUB].
1469 Appendix A. ASN.1 Module
1471 SecureMimeMessageV3dot1
1473 { iso(1) member-body(2) us(840) rsadsi(113549)
1474 pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
1476 DEFINITIONS IMPLICIT TAGS ::=
1478 BEGIN
1480 IMPORTS
1482 -- Cryptographic Message Syntax
1483 SubjectKeyIdentifier, IssuerAndSerialNumber,
1484 RecipientKeyIdentifier
1485 FROM CryptographicMessageSyntax
1486 { iso(1) member-body(2) us(840) rsadsi(113549)
1487 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14)
1488 };
1490 -- id-aa is the arc with all new authenticated and unauthenticated
1491 -- attributes produced the by S/MIME Working Group
1493 id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
1494 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
1496 -- S/MIME Capabilities provides a method of broadcasting the
1497 -- symmetric capabilities understood. Algorithms SHOULD be ordered
1498 -- by preference and grouped by type
1500 smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
1501 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
1503 SMIMECapability ::= SEQUENCE {
1504 capabilityID OBJECT IDENTIFIER,
1505 parameters ANY DEFINED BY capabilityID OPTIONAL }
1507 SMIMECapabilities ::= SEQUENCE OF SMIMECapability
1509 -- Encryption Key Preference provides a method of broadcasting the
1510 -- preferred encryption certificate.
1512 id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
1514 SMIMEEncryptionKeyPreference ::= CHOICE {
1515 issuerAndSerialNumber [0] IssuerAndSerialNumber,
1516 receipentKeyId [1] RecipientKeyIdentifier,
1517 subjectAltKeyIdentifier [2] SubjectKeyIdentifier
1518 }
1520 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
1521 rsadsi(113549) pkcs(1) pkcs9(9) 16 }
1523 id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
1525 -- The preferBinaryInside indicates an ability to receive messages
1526 -- with binary encoding inside the CMS wrapper
1528 id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
1530 -- The following list the OIDs to be used with S/MIME V3
1532 -- Signature Algorithms Not Found in [CMSALG]
1534 --
1536 -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
1537 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
1538 -- 2}
1540 --
1542 -- Other Signed Attributes
1543 --
1544 -- signingTime OBJECT IDENTIFIER ::=
1545 -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
1546 -- 5}
1547 -- See [CMS] for a description of how to encode the attribute
1548 -- value.
1550 SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
1551 -- (RC2 Key Length (number of bits))
1553 END
1555 Appendix B. References
1557 B.1. Normative References
1559 [CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
1560 Certificate Handling", work in progress.
1562 [CHARSETS] Character sets assigned by IANA. See
1563 http://www.iana.org/assignments/character-sets
1565 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
1566 3852, July 2004.
1568 Housley, R., "Cryptographic Message Syntax (CMS)
1569 Multiple Signer Clarification", RFC 4852, April 2007.
1571 [CMSAES] Schaad, J., "Use of the Advanced Encryption Standard
1572 (AES) Encryption Algorithm in Cryptographic Message
1573 Syntax (CMS)", RFC 3565, July 2003.
1575 [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
1576 Algorithms", RFC 3370, August 2002.
1578 [CMSCOMPR] Gutmann, P., "Compressed Data Content Type for
1579 Cryptographic Message Syntax (CMS)", RFC 3274, June
1580 2002.
1582 [CMSECC] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
1583 Elliptic Curve Cryptography (ECC) Algorithms in
1584 Cryptographic Message Syntax (CMS)", RFC 3278, April
1585 2002.
1587 [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic
1588 Message Syntax", work in progress.
1590 [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
1591 Presentation Information in Internet Messages: The
1592 Content-Disposition Header Field", RFC 2183, August
1593 1997.
1595 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
1596 RFC 2634, June 1999.
1598 [FIPS180-2] "Secure Hash Signature Standard (SHS)", National
1599 Institute of Standards and Technology (NIST). FIPS
1600 Publication 180-2.
1602 [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
1603 Mail Extensions (MIME) Part One: Format of Internet
1604 Message Bodies", RFC 2045, November 1996.
1606 Freed, N. and N. Borenstein, "Multipurpose Internet
1607 Mail Extensions (MIME) Part Two: Media Types", RFC
1608 2046, November 1996.
1610 Moore, K., "MIME (Multipurpose Internet Mail
1611 Extensions) Part Three: Message Header Extensions for
1612 Non-ASCII Text", RFC 2047, November 1996.
1614 Freed, N., Klensin, J., and J. Postel, "Multipurpose
1615 Internet Mail Extensions (MIME) Part Four: Registration
1616 Procedures", BCP 13, RFC 2048, November 1996.
1618 Freed, N. and N. Borenstein, "Multipurpose Internet
1619 Mail Extensions (MIME) Part Five: Conformance Criteria
1620 and Examples", RFC 2049, November 1996.
1622 [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
1623 "Security Multiparts for MIME: Multipart/Signed and
1624 Multipart/Encrypted", RFC 1847, October 1995.
1626 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
1627 Requirement Levels", BCP 14, RFC 2119, March 1997.
1629 [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
1630 Cryptographic Message Syntax (CMS)", RFC 4056, June
1631 2005.
1633 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
1634 Syntax Notation One (ASN.1). 1988.
1636 [X.209-88] CCITT. Recommendation X.209: Specification of Basic
1637 Encoding Rules for Abstract Syntax Notation One
1638 (ASN.1). 1988.
1640 [X.509-88] CCITT. Recommendation X.509: The Directory -
1641 Authentication Framework. 1988.
1643 B.2. Informative References
1645 [DHSUB] Zuccherato, R., "Methods for Avoiding the "Small-
1646 Subgroup" Attacks on the Diffie-Hellman Key Agreement
1647 Method for S/MIME", RFC 2785, March 2000.
1649 [MMA] Rescorla, E., "Preventing the Million Message Attack on
1650 Cryptographic Message Syntax", RFC 3218, January 2002.
1652 [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
1653 Version 1.5", RFC 2315, March 1998.
1655 [RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
1656 "Randomness Recommendations for Security", RFC 1750,
1657 December 1994.
1659 [SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA-
1660 224", RFC 3874, September 2004.
1662 [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
1663 and L. Repka, "S/MIME Version 2 Message Specification",
1664 RFC 2311, March 1998.
1666 Appendix C. Acknowledgements
1668 Many thanks go out to the other authors of the S/MIME Version 2
1669 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
1670 Lundblade and Lisa Repka.
1672 A number of the members of the S/MIME Working Group have also worked
1673 very hard and contributed to this document. Any list of people is
1674 doomed to omission, and for that I apologize. In alphabetical order,
1675 the following people stand out in my mind due to the fact that they
1676 made direct contributions to this document.
1678 Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
1679 Gutmann, Paul Hoffman, Russ Housley, William Ottaway, John Pawling,
1680 Jim Schaad
1682 Author's Addresses
1684 Blake Ramsdell
1685 SendMail
1687 Email: ramsdell (at) sendmail (dot) com
1689 Sean Turner
1690 IECA, Inc.
1692 Email: turners (at) ieca (dot) com
1694 Full Copyright Statement
1696 Copyright (C) The IETF Trust (2007).
1698 This document is subject to the rights, licenses and restrictions
1699 contained in BCP 78, and except as set forth therein, the authors
1700 retain all their rights.
1702 This document and the information contained herein are provided on an
1703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1705 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1706 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1710 Intellectual Property
1712 The IETF takes no position regarding the validity or scope of any
1713 Intellectual Property Rights or other rights that might be claimed to
1714 pertain to the implementation or use of the technology described in
1715 this document or the extent to which any license under such rights
1716 might or might not be available; nor does it represent that it has
1717 made any independent effort to identify any such rights. Information
1718 on the procedures with respect to rights in RFC documents can be
1719 found in BCP 78 and BCP 79.
1721 Copies of IPR disclosures made to the IETF Secretariat and any
1722 assurances of licenses to be made available, or the result of an
1723 attempt made to obtain a general license or permission for the use of
1724 such proprietary rights by implementers or users of this
1725 specification can be obtained from the IETF on-line IPR repository at
1726 http://www.ietf.org/ipr.
1728 The IETF invites any interested party to bring to its attention any
1729 copyrights, patents or patent applications, or other proprietary
1730 rights that may cover technology that may be required to implement
1731 this standard. Please address the information to the IETF at ietf-
1732 ipr@ietf.org.
1734 Acknowledgment
1736 Funding for the RFC Editor function is provided by the IETF
1737 Administrative Support Activity (IASA).