< draft-schaad-rfc5751-bis-00.txt   draft-schaad-rfc5751-bis-01.txt >
SPASM J. Schaad SPASM J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: RFC5751 (if approved) B. Ramsdell Obsoletes: RFC5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: October 29, 2016 S. Turner Expires: January 9, 2017 S. Turner
IECA, Inc. IECA, Inc.
April 27, 2016 July 8, 2016
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5
Message Specification Message Specification
draft-schaad-rfc5751-bis-00 draft-schaad-rfc5751-bis-01
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.5. S/MIME provides a consistent way to send and (S/MIME) version 3.5. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication, receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin. message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to Encryption provides data confidentiality. Compression can be used to
reduce data size. This document obsoletes RFC 5751. reduce data size. This document obsoletes RFC 5751.
Contributing to this document
The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at <https://github.com/
spasm-wg/smime>. Instructions are on that page as well. Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the SPASM mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 29, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Overview . . . . . . . . . . . . . . . . . 4 1.1. Specification Overview . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Conventions Used in This Document . . . . . . . . . . . . 6 1.3. Conventions Used in This Document . . . . . . . . . . . . 6
1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 6 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 6
1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 7
1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 7 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 7
1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9 1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 9 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 9
skipping to change at page 3, line 13 skipping to change at page 3, line 22
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 18 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 18
3.1. Preparing the MIME Entity for Signing, Enveloping, or 3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing . . . . . . . . . . . . . . . . . . . . . . . 19 Compressing . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 20 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 20
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21
3.1.3. Transfer Encoding for Signing Using multipart/signed 21 3.1.3. Transfer Encoding for Signing Using multipart/signed 21
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 22 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 22
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 23
3.2.1. The name and filename Parameters . . . . . . . . . . 24 3.2.1. The name and filename Parameters . . . . . . . . . . 24
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 26 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 25
3.4. Creating an Authenticated Enveloped-Only Message . . . . 26 3.4. Creating an Authenticated Enveloped-Only Message . . . . 26
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 27
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 27 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 27
3.5.2. Signing Using application/pkcs7-mime with SignedData 28 3.5.2. Signing Using application/pkcs7-mime with SignedData 28
3.5.3. Signing Using the multipart/signed Format . . . . . . 29 3.5.3. Signing Using the multipart/signed Format . . . . . . 28
3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31
3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 32 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 31
3.8. Creating a Certificate Management Message . . . . . . . . 33 3.8. Creating a Certificate Management Message . . . . . . . . 32
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 33 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 33
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 33
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 35 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 34
4.3. Signature Verification . . . . . . . . . . . . . . . . . 35 4.3. Signature Verification . . . . . . . . . . . . . . . . . 35
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 36 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 35
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 35
5.2. Media Type for application/pkcs7-signature . . . . . . . 37 5.2. Media Type for application/pkcs7-signature . . . . . . . 36
5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 44 7.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 47 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 47
Appendix B. Moving S/MIME v2 Message Specification to Historic Appendix B. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 49 Status . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 49 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
skipping to change at page 8, line 45 skipping to change at page 8, line 45
Section 4.1: Updated RSA and DSA key size discussion. Moved last Section 4.1: Updated RSA and DSA key size discussion. Moved last
four sentences to security considerations. Updated reference to four sentences to security considerations. Updated reference to
randomness requirements for security. randomness requirements for security.
Section 5: Added IANA registration templates to update media type Section 5: Added IANA registration templates to update media type
registry to point to this document as opposed to RFC 2311. registry to point to this document as opposed to RFC 2311.
Section 6: Updated security considerations. Section 6: Updated security considerations.
Section 7: Moved references from Appendix B to this section. Updated Section 7 : Moved references from Appendix B to this section.
references. Added informational references to SMIMEv2, SMIMEv3, and Updated references. Added informational references to SMIMEv2,
SMIMEv3.1. SMIMEv3, and SMIMEv3.1.
Appendix B: Added Appendix B to move S/MIME v2 to Historic status. Appendix B: Added Appendix B to move S/MIME v2 to Historic status.
1.7. Changes since S/MIME v3.2 1.7. Changes since S/MIME v3.2
- Add the use of AuthEnvelopedData, including defining and - Add the use of AuthEnvelopedData, including defining and
registering an smime-type value. registering an smime-type value (Section 2.4.4 and Section 3.4).
- Add the use of AES-GCM. - Add the use of AES-GCM (Section 2.7).
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content, attributes, and CMS allows for a wide variety of options in content, attributes, and
algorithm support. This section puts forth a number of support algorithm support. This section puts forth a number of support
requirements and recommendations in order to achieve a base level of requirements and recommendations in order to achieve a base level of
interoperability among all S/MIME implementations. [RFC3370] and interoperability among all S/MIME implementations. [RFC3370] and
[RFC5754] provides additional details regarding the use of the [RFC5754] provides additional details regarding the use of the
cryptographic algorithms. [ESS] provides additional details cryptographic algorithms. [ESS] provides additional details
regarding the use of additional attributes. regarding the use of additional attributes.
skipping to change at page 11, line 8 skipping to change at page 11, line 8
Note that S/MIME v3.1 clients might only implement key encryption and Note that S/MIME v3.1 clients might only implement key encryption and
decryption using the rsaEncryption algorithm. Note that S/MIME v3 decryption using the rsaEncryption algorithm. Note that S/MIME v3
clients might only implement key encryption and decryption using the clients might only implement key encryption and decryption using the
Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only Diffie-Hellman algorithm. Also note that S/MIME v2 clients are only
capable of decrypting content-encryption keys using the rsaEncryption capable of decrypting content-encryption keys using the rsaEncryption
algorithm. algorithm.
2.4. General Syntax 2.4. General Syntax
There are several CMS content types. Of these, only the Data, There are several CMS content types. Of these, only the Data,
SignedData, EnvelopedData, and CompressedData content types are SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
currently used for S/MIME. content types are currently used for S/MIME.
2.4.1. Data Content Type 2.4.1. Data Content Type
Sending agents MUST use the id-data content type identifier to Sending agents MUST use the id-data content type identifier to
identify the "inner" MIME message content. For example, when identify the "inner" MIME message content. For example, when
applying a digital signature to MIME data, the CMS SignedData applying a digital signature to MIME data, the CMS SignedData
encapContentInfo eContentType MUST include the id-data object encapContentInfo eContentType MUST include the id-data object
identifier and the media type MUST be stored in the SignedData identifier and the media type MUST be stored in the SignedData
encapContentInfo eContent OCTET STRING (unless the sending agent is encapContentInfo eContent OCTET STRING (unless the sending agent is
using multipart/signed, in which case the eContent is absent, per using multipart/signed, in which case the eContent is absent, per
skipping to change at page 13, line 10 skipping to change at page 13, line 10
The signing-time attribute is used to convey the time that a message The signing-time attribute is used to convey the time that a message
was signed. The time of signing will most likely be created by a was signed. The time of signing will most likely be created by a
message originator and therefore is only as trustworthy as the message originator and therefore is only as trustworthy as the
originator. originator.
Sending agents MUST encode signing time through the year 2049 as Sending agents MUST encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later MUST be encoded as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
interpret the year field (YY) as follows: interpret the year field (YY) as follows:
If YY is greater than or equal to 50, the year is interpreted as If YY is greater than or equal to 50, the year is interpreted as
19YY; if YY is less than 50, the year is interpreted as 20YY. 19YY; if YY is less than 50, the year is interpreted as 20YY.
Receiving agents MUST be able to process signing-time attributes that Receiving agents MUST be able to process signing-time attributes that
are encoded in either UTCTime or GeneralizedTime. are encoded in either UTCTime or GeneralizedTime.
2.5.2. SMIME Capabilities Attribute 2.5.2. SMIME Capabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such The SMIMECapabilities attribute includes signature algorithms (such
as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
CBC"), authenticated symmetric algorithms (such as "AES-GCM") and key CBC"), authenticated symmetric algorithms (such as "AES-GCM") and key
encipherment algorithms (such as "rsaEncryption"). There are also encipherment algorithms (such as "rsaEncryption"). There are also
skipping to change at page 18, line 5 skipping to change at page 17, line 51
2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME 2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME
If the following two conditions are met: If the following two conditions are met:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, and of the recipient, and
- the sending agent has no knowledge of the version of S/MIME of the - the sending agent has no knowledge of the version of S/MIME of the
recipient, recipient,
then the sending agent SHOULD use AES-128 because it is a stronger then the sending agent SHOULD use AES-128 CBC because it is a
algorithm and is required by S/MIME v3.2. If the sending agent stronger algorithm and is required by S/MIME v3.2. If the sending
chooses not to use AES-128 in this step, it SHOULD use tripleDES. agent chooses not to use AES-128 CBC in this step, it SHOULD use
tripleDES.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 40-bit keys are considered by many to be weak All algorithms that use 40-bit keys are considered by many to be weak
encryption. A sending agent that is controlled by a human SHOULD encryption. A sending agent that is controlled by a human SHOULD
allow a human sender to determine the risks of sending data using a allow a human sender to determine the risks of sending data using a
weak encryption algorithm before sending the data, and possibly allow weak encryption algorithm before sending the data, and possibly allow
the human to use a stronger encryption method such as tripleDES or the human to use a stronger encryption method such as tripleDES or
AES. AES.
skipping to change at page 24, line 33 skipping to change at page 24, line 27
3.2.1. The name and filename Parameters 3.2.1. The name and filename Parameters
For the application/pkcs7-mime, sending agents SHOULD emit the For the application/pkcs7-mime, sending agents SHOULD emit the
optional "name" parameter to the Content-Type field for compatibility optional "name" parameter to the Content-Type field for compatibility
with older systems. Sending agents SHOULD also emit the optional with older systems. Sending agents SHOULD also emit the optional
Content-Disposition field [RFC2138] with the "filename" parameter. Content-Disposition field [RFC2138] with the "filename" parameter.
If a sending agent emits the above parameters, the value of the If a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension: parameters SHOULD be a file name with the appropriate extension:
Media Type File Extension Media Type File
application/pkcs7-mime (SignedData, EnvelopedData) .p7m Extension
application/pkcs7-mime (degenerate SignedData .p7c application/pkcs7-mime (SignedData, EnvelopedData) .p7m
certificate management message) application/pkcs7-mime (degenerate SignedData certificate .p7c
application/pkcs7-mime (CompressedData) .p7z management message)
application/pkcs7-signature (SignedData) .p7s application/pkcs7-mime (CompressedData) .p7z
application/pkcs7-signature (SignedData) .p7s
In addition, the file name SHOULD be limited to eight characters In addition, the file name SHOULD be limited to eight characters
followed by a three-letter extension. The eight-character filename followed by a three-letter extension. The eight-character filename
base can be any distinct name; the use of the filename base "smime" base can be any distinct name; the use of the filename base "smime"
SHOULD be used to indicate that the MIME entity is associated with SHOULD be used to indicate that the MIME entity is associated with
S/MIME. S/MIME.
Including a file name serves two purposes. It facilitates easier use Including a file name serves two purposes. It facilitates easier use
of S/MIME objects as files on disk. It also can convey type of S/MIME objects as files on disk. It also can convey type
information across gateways. When a MIME entity of type information across gateways. When a MIME entity of type
skipping to change at page 25, line 20 skipping to change at page 25, line 15
the file extensions. the file extensions.
3.2.2. The smime-type Parameter 3.2.2. The smime-type Parameter
The application/pkcs7-mime content type defines the optional "smime- The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with about the security applied (signed or enveloped) along with
information about the contained content. This specification defines information about the contained content. This specification defines
the following smime-types. the following smime-types.
Name CMS Type Inner Content Name CMS Type Inner Content
enveloped-data EnvelopedData id-data enveloped-data EnvelopedData id-data
signed-data SignedData id-data signed-data SignedData id-data
certs-only SignedData id-data certs-only SignedData id-data
compressed-data CompressedData id-data compressed-data CompressedData id-data
authEnvelopedData AuthEnvelopedData id-data authEnvelopedData AuthEnvelopedData id-data
In order for consistency to be obtained with future specifications, In order for consistency to be obtained with future specifications,
the following guidelines SHOULD be followed when assigning a new the following guidelines SHOULD be followed when assigning a new
smime-type parameter. smime-type parameter.
1. If both signing and encryption can be applied to the content, 1. If both signing and encryption can be applied to the content,
then two values for smime-type SHOULD be assigned "signed-*" and then two values for smime-type SHOULD be assigned "signed-*" and
"enveloped-*". If one operation can be assigned, then this can "enveloped-*". If one operation can be assigned, then this can
be omitted. Thus, since "certs-only" can only be signed, be omitted. Thus, since "certs-only" can only be signed,
"signed-" is omitted. "signed-" is omitted.
skipping to change at page 26, line 47 skipping to change at page 26, line 39
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V 0GhIGfHfQbnj756YT64V
3.4. Creating an Authenticated Enveloped-Only Message 3.4. Creating an Authenticated Enveloped-Only Message
This section describes the format for enveloping a MIME entity This section describes the format for enveloping a MIME entity
without signing it. It is important to note that sending without signing it. Authenticated enveloped messages provide
authenticated enveloped but not signed messages does not provide for confidentiality and integrity. It is important to note that sending
authentication or non-repudiation. It is possible to replace authenticated enveloped messages does not provide for authentication
ciphertext in such a way that the processed message will still be when using S/MIME. It is possible to replace ciphertext in such a
valid, but the meaning can be altered. way that the processed message will still be valid, but the meaning
can be altered. However this is substantially more difficult than it
is for an enveloped-only message as the
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
Section 3.1. Section 3.1.
Step 2. The MIME entity and other required data is processed into a Step 2. The MIME entity and other required data is processed into a
CMS object of type AuthEnvelopedData. In addition to CMS object of type AuthEnvelopedData. In addition to
encrypting a copy of the content-encryption key for each encrypting a copy of the content-encryption key for each
recipient, a copy of the content-encryption key SHOULD be recipient, a copy of the content-encryption key SHOULD be
encrypted for the originator and included in the encrypted for the originator and included in the
AuthEnvelopedData (see [RFC5083]). AuthEnvelopedData (see [RFC5083]).
skipping to change at page 30, line 13 skipping to change at page 30, line 8
MUST be quoted. MUST be quoted.
The micalg parameter allows for one-pass processing when the The micalg parameter allows for one-pass processing when the
signature is being verified. The value of the micalg parameter is signature is being verified. The value of the micalg parameter is
dependent on the message digest algorithm(s) used in the calculation dependent on the message digest algorithm(s) used in the calculation
of the Message Integrity Check. If multiple message digest of the Message Integrity Check. If multiple message digest
algorithms are used, they MUST be separated by commas per [MIME- algorithms are used, they MUST be separated by commas per [MIME-
SECURE]. The values to be placed in the micalg parameter SHOULD be SECURE]. The values to be placed in the micalg parameter SHOULD be
from the following: from the following:
Algorithm Value Used Algorithm Value Used
MD5 md5
MD5 md5 SHA-1 sha-1
SHA-1 sha-1 SHA-224 sha-224
SHA-224 sha-224 SHA-256 sha-256
SHA-256 sha-256 SHA-384 sha-384
SHA-384 sha-384 SHA-512 sha-512
SHA-512 sha-512 Any other (defined separately in algorithm profile or "unknown" if
Any other (defined separately in algorithm profile or "unknown" not defined)
if not defined)
(Historical note: some early implementations of S/MIME emitted and (Historical note: some early implementations of S/MIME emitted and
expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a micalg Receiving agents SHOULD be able to recover gracefully from a micalg
parameter value that they do not recognize. Future names for this parameter value that they do not recognize. Future names for this
parameter will be consistent with the IANA "Hash Function Textual parameter will be consistent with the IANA "Hash Function Textual
Names" registry. Names" registry.
3.5.3.3. Sample multipart/signed Message 3.5.3.3. Sample multipart/signed Message
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha-1; boundary=boundary42 micalg=sha-1; boundary=boundary42
--boundary42 --boundary42
Content-Type: text/plain Content-Type: text/plain
This is a clear-signed message. This is a clear-signed message.
--boundary42 --boundary42
skipping to change at page 34, line 10 skipping to change at page 33, line 36
type information, and it becomes a bit difficult to identify S/MIME type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an or not a message is an S/MIME message. A message is considered an
S/MIME message if it matches any of the criteria listed below. S/MIME message if it matches any of the criteria listed below.
The file suffix in the table below comes from the "name" parameter in The file suffix in the table below comes from the "name" parameter in
the Content-Type header field, or the "filename" parameter on the the Content-Type header field, or the "filename" parameter on the
Content-Disposition header field. These parameters that give the Content-Disposition header field. These parameters that give the
file suffix are not listed below as part of the parameter section. file suffix are not listed below as part of the parameter section.
Media type: application/pkcs7-mime Media type parameters file
parameters: any suffix
file suffix: any application/pkcs7-mime any any
multipart/signed protocol="application/pkcs7-signature" any
Media type: multipart/signed application/octet- any p7m,
parameters: protocol="application/pkcs7-signature" stream p7s,
file suffix: any p7c,
p7z
Media type: application/octet-stream
parameters: any
file suffix: p7m, p7s, p7c, p7z
4. Certificate Processing 4. Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital in order to gain access to certificates for recipients of digital
envelopes. This specification does not cover how S/MIME agents envelopes. This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been handle certificates, only what they do after a certificate has been
validated or rejected. S/MIME certificate issues are covered in validated or rejected. S/MIME certificate issues are covered in
[RFC5750]. [RFC5750].
skipping to change at page 41, line 7 skipping to change at page 40, line 7
If messaging environments make use of the fact that a message is If messaging environments make use of the fact that a message is
signed to change the behavior of message processing (examples would signed to change the behavior of message processing (examples would
be running rules or UI display hints), without first verifying that be running rules or UI display hints), without first verifying that
the message is actually signed and knowing the state of the the message is actually signed and knowing the state of the
signature, this can lead to incorrect handling of the message. signature, this can lead to incorrect handling of the message.
Visual indicators on messages may need to have the signature Visual indicators on messages may need to have the signature
validation code checked periodically if the indicator is supposed to validation code checked periodically if the indicator is supposed to
give information on the current status of a message. give information on the current status of a message.
Many people assume that the use of an authenticated encryption
algorithm is all that is needed to be in a situtation where the
sender of the message will be authenticated. In almost all cases
this is not a correct statement. There are a number of preconditions
that need to hold for an authenticated encryption algorithm to
provide this service:
- The starting key must be bound to a single entity. The use of a
group key only would allow for the statement that a message was
sent by one of the entities that held the key but will not
identify a specific entity.
- The message must have exactly one sender and one recipient.
Having more than one recipient would allow for the second
recipient to create a message that the first recipient would
believe is from the sender by stripping them as a recipient from
the message.
- A direct path needs to exist from the starting key to the key used
as the content encryption key (CEK) which guarantees that no third
party could have seen the resulting CEK. This means that one
needs to be using an algorithm that is called a "Direct
Encryption" or a "Direct Key Agreement" algorithm in other
contexts. This means that the starting key is used directly as
the CEK key, or that the starting key is used to create a secret
which then is transformed into the CEK via a KDF step.
S/MIME implementations almost universally use ephemeral-static rather
than static-static key agreement and do not use a pre-existing shared
secret when doing encryption, this means that the first precondition
is not met. There is a document [RFC6278] which defined how to use
static-static key agreement with CMS so that is readably doable.
Currently, all S/MIME key agreement methods derive a KEK and wrap a
CEK. This violates the third precondition above. New key key
agreement algorithms that directly created the CEK without creating
an intervening KEK would need to be defined.
Even when all of the preconditions are met and origination of a
message is established by the use of an authenticated encryption
algorithm, users need to be aware that there is no way to prove this
to a third party. This is because either of the parties can
successfully create the message (or just alter the content) based on
the fact that the CEK is going to be known to both parties. Thus the
origination is always built on a presumption that "I did not send
this message to myself."
7. References 7. References
7.1. Normative References 7.1. Normative References
[ASN.1] "Information Technology - Abstract Syntax Notation [ASN.1] "Information Technology - Abstract Syntax Notation
(ASN.1)". (ASN.1)".
ASN.1 syntax consists of the following references [X.680], ASN.1 syntax consists of the following references [X.680],
[X.681], [X.682], and [X.683]. [X.681], [X.682], and [X.683].
skipping to change at page 46, line 24 skipping to change at page 46, line 20
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
<http://www.rfc-editor.org/info/rfc5750>. <http://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
Curve Diffie-Hellman Key Agreement in Cryptographic
Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June
2011, <http://www.rfc-editor.org/info/rfc6278>.
[SMIMEv2] "S/MIME version v2". [SMIMEv2] "S/MIME version v2".
This group of documents represents S/MIME version 2. This This group of documents represents S/MIME version 2. This
set of documents are [RFC2311], [RFC2312], [RFC2313], set of documents are [RFC2311], [RFC2312], [RFC2313],
[RFC2314], and [RFC2315]. [RFC2314], and [RFC2315].
[SMIMEv3] "S/MIME version 3". [SMIMEv3] "S/MIME version 3".
This group of documents represents S/MIME version 3. This This group of documents represents S/MIME version 3. This
set of documents are [RFC2630], [RFC2631], [RFC2632], set of documents are [RFC2630], [RFC2631], [RFC2632],
skipping to change at page 49, line 25 skipping to change at page 49, line 25
Many thanks go out to the other authors of the S/MIME version 2 Many thanks go out to the other authors of the S/MIME version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1, Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1,
v3.2 or v3.5. v3.2 or v3.5.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind because they made direct the following people stand out in my mind because they made direct
contributions to this document: contributions to various versions of this document:
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
John Pawling, and Jim Schaad. and John Pawling.
Authors' Addresses Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Blake Ramsdell Blake Ramsdell
Brute Squad Labs, Inc. Brute Squad Labs, Inc.
 End of changes. 28 change blocks. 
69 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/