draft-ietf-lamps-rfc5751-bis-02.txt   draft-ietf-lamps-rfc5751-bis-03.txt 
LAMPS J. Schaad LAMPS 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: May 2, 2017 S. Turner Expires: August 27, 2017 S. Turner
sn3rd sn3rd
October 29, 2016 February 23, 2017
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification Message Specification
draft-ietf-lamps-rfc5751-bis-02 draft-ietf-lamps-rfc5751-bis-03
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 4.0. S/MIME provides a consistent way to send and (S/MIME) version 4.0. 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.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 May 2, 2017. This Internet-Draft will expire on August 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 41 skipping to change at page 2, line 41
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . 7 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 7
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 . . . . . . . . . 8 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 8
1.7. Changes since S/MIME v3.2 . . . . . . . . . . . . . . . . 9 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 9 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 11 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12
2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 12
2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 12
2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 12
2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 12
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 12 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13
2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13
2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 13 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14
2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 16
2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 17
2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 17
2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 18 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 19
2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 19
3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 19
3.1. Preparing the MIME Entity for Signing, Enveloping, or 3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing . . . . . . . . . . . . . . . . . . . . . . . 19 Compressing . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 21 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22
3.1.3. Transfer Encoding for Signing Using multipart/signed 22 3.1.3. Transfer Encoding for Signing Using multipart/signed 22
3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 23
3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 24
3.2.1. The name and filename Parameters . . . . . . . . . . 24 3.2.1. The name and filename Parameters . . . . . . . . . . 25
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 25 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 26 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27
3.4. Creating an Authenticated Enveloped-Only Message . . . . 27 3.4. Creating an Authenticated Enveloped-Only Message . . . . 27
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 28 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 28 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29
3.5.2. Signing Using application/pkcs7-mime with SignedData 28 3.5.2. Signing Using application/pkcs7-mime with SignedData 30
3.5.3. Signing Using the multipart/signed Format . . . . . . 29 3.5.3. Signing Using the multipart/signed Format . . . . . . 31
3.6. Creating a Compressed-Only Message . . . . . . . . . . . 31 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 34
3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 32 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 34
3.8. Creating a Certificate Management Message . . . . . . . . 33 3.8. Creating a Certificate Management Message . . . . . . . . 35
3.9. Registration Requests . . . . . . . . . . . . . . . . . . 33 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 36
3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 34 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 36
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 34 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 36
4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 34 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 37
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 35 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 37
4.3. Signature Verification . . . . . . . . . . . . . . . . . 35 4.3. Signature Verification . . . . . . . . . . . . . . . . . 37
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 36 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 36 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38
5.2. Media Type for application/pkcs7-signature . . . . . . . 37 5.2. Media Type for application/pkcs7-signature . . . . . . . 39
5.3. Register authEnvelopedData smime-type . . . . . . . . . . 38 5.3. Register authEnvelopedData smime-type . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. Normative References . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . 44
7.2. Informative References . . . . . . . . . . . . . . . . . 46 7.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51
Appendix B. Historic Mail Considerations . . . . . . . . . . . . 51 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 51 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 51 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 53 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 54 B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56
Appendix C. Moving S/MIME v2 Message Specification to Historic Appendix C. Moving S/MIME v2 Message Specification to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 54 Status . . . . . . . . . . . . . . . . . . . . . . . 56
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 54 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging cryptographic security services for electronic messaging
applications: authentication, message integrity and non-repudiation applications: authentication, message integrity and non-repudiation
of origin (using digital signatures), and data confidentiality (using of origin (using digital signatures), and data confidentiality (using
encryption). As a supplementary service, S/MIME provides for message encryption). As a supplementary service, S/MIME provides for message
skipping to change at page 7, line 24 skipping to change at page 7, line 24
requirement, it will remain at least a SHOULD or a SHOULD-. requirement, it will remain at least a SHOULD or a SHOULD-.
1.4. Compatibility with Prior Practice of S/MIME 1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 4.0 agents ought to attempt to have the greatest S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in inclusive and RFC 5035 [SMIMEv3], S/MIME version 3.1 is described in
RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1], and
S/MIME version 3.2 is described in [SMIMEv3.2]. RFC 2311 also has S/MIME version 3.2 is described in [SMIMEv3.2]. [RFC2311] also has
historical information about the development of S/MIME. historical information about the development of S/MIME.
1.5. Changes from S/MIME v3 to S/MIME v3.1 1.5. Changes from S/MIME v3 to S/MIME v3.1
The RSA public key algorithm was changed to a MUST implement key The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to wrapping algorithm, and the Diffie-Hellman (DH) algorithm changed to
a SHOULD implement. a SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD The AES symmetric encryption algorithm has been included as a SHOULD
implement. implement.
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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. Section 7: Moved references from Appendix B to this section. Updated
Updated references. Added informational references to SMIMEv2, references. Added informational references to SMIMEv2, SMIMEv3, and
SMIMEv3, and SMIMEv3.1. SMIMEv3.1.
Appendix C: Added Appendix B to move S/MIME v2 to Historic status. Appendix C: Added Appendix C to move S/MIME v2 to Historic status.
1.7. Changes since S/MIME v3.2 1.7. Changes for S/MIME v4.0
- Add the use of AuthEnvelopedData, including defining and - Add the use of AuthEnvelopedData, including defining and
registering an smime-type value (Section 2.4.4 and Section 3.4). registering an smime-type value (Section 2.4.4 and Section 3.4).
- Update the content encryption algorithms (Section 2.7): Add - Update the content encryption algorithms (Section 2.7 and
AES-256 GCM , remove AES-192 CBC, mark tripleDES as historic. Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove
AES-192 CBC, mark tripleDES as historic.
- Update the set of signature algorithms (Section 2.2: Add EdDSA and
ECDSA, mark DSA as historic
- Update the set of digest algorithms (Section 2.1: Add SHA-512,
mark SHA-1 as historic.
- Update the size of keys to be used for RSA encryption and RSA
signing (Section 4).
- Create Appendix B which deals with considerations for dealing with - Create Appendix B which deals with considerations for dealing with
historic email messages. historic email messages.
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
skipping to change at page 10, line 14 skipping to change at page 10, line 24
digest attribute of the signed attributes. It is RECOMMENDED that digest attribute of the signed attributes. It is RECOMMENDED that
the algorithm used for digesting the body of the message be of the algorithm used for digesting the body of the message be of
similar or greater strength than the signature algorithm. similar or greater strength than the signature algorithm.
Sending and Receiving agents: Sending and Receiving agents:
- MUST support SHA-256. - MUST support SHA-256.
- MUST support SHA-512. - MUST support SHA-512.
[RFC5754] provides the details for using these algorithms with S/ [RFC5754] provides the details for using these algorithms with
MIME. S/MIME.
2.2. SignatureAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
Receiving agents: Receiving agents:
- MUST support ECDSA with curve P-256 and SHA-256. - MUST support ECDSA with curve P-256 and SHA-256.
- MUST support EdDSA with curve 25519 using PureEdDSA mode. - MUST support EdDSA with curve 25519 using PureEdDSA mode.
- MUST- support RSA with SHA-256. - MUST- support RSA with SHA-256.
skipping to change at page 10, line 47 skipping to change at page 11, line 9
- MUST- support RSA with SHA-256. - MUST- support RSA with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using the pre-hash mode. - MUST NOT support EdDSA using the pre-hash mode.
Both ECDSA and EdDSA are included in the list of required algorithms Both ECDSA and EdDSA are included in the list of required algorithms
for political reasons. NIST is unable to provide the seeds that were for political reasons. NIST is unable to provide the seeds that were
used to create their standardized curves, this means that there is a used to create their standardized curves, this means that there is a
section of the community which believes that there might be a section of the community which believes that there might be a
backdoor to these curves. The EdDSA curves were created in response backdoor to these curves. The EdDSA curves were, in part, created in
to this feeling. However, there are still significant sections of response to this feeling. However, there are still significant
the industry which need to have NIST approved algorithms. For this sections of the industry which need to have NIST approved algorithms.
reason, both sets of curves are represented in the recieving agent For this reason, both sets of curves are represented in the recieving
list, but there is only a requirement for curve in the sending agent agent list, but there is only a requirement for curve in the sending
list. agent list.
See Section 4.1 for information on key size and algorithm references. See Section 4.1 for information on key size and algorithm references.
2.3. KeyEncryptionAlgorithmIdentifier 2.3. KeyEncryptionAlgorithmIdentifier
Receiving and sending agents: Receiving and sending agents:
- MUST support ECDH ephemeral-static mode for P-256, as specified in - MUST support ECDH ephemeral-static mode for P-256, as specified in
[RFC5753]. [RFC5753].
skipping to change at page 23, line 17 skipping to change at page 23, line 30
[RFC1847] prohibits an agent from changing the transfer encoding of [RFC1847] prohibits an agent from changing the transfer encoding of
the first part of a multipart/signed message. If a compliant agent the first part of a multipart/signed message. If a compliant agent
that cannot transmit 8-bit or binary data encounters a that cannot transmit 8-bit or binary data encounters a
multipart/signed message with 8-bit or binary data in the first part, multipart/signed message with 8-bit or binary data in the first part,
it would have to return the message to the sender as undeliverable. it would have to return the message to the sender as undeliverable.
3.1.4. Sample Canonical MIME Entity 3.1.4. Sample Canonical MIME Entity
This example shows a multipart/mixed message with full transfer This example shows a multipart/mixed message with full transfer
encoding. This message contains a text part and an attachment. The encoding. This message contains a text part and an attachment. The
sample message text includes characters that are not US-ASCII and sample message text includes characters that are not ASCII and thus
thus need to be transfer encoded. Though not shown here, the end of need to be transfer encoded. Though not shown here, the end of each
each line is <CR><LF>. The line ending of the MIME headers, the line is <CR><LF>. The line ending of the MIME headers, the text, and
text, and the transfer encoded parts, all MUST be <CR><LF>. the transfer encoded parts, all MUST be <CR><LF>.
Note that this example is not of an S/MIME message. Note that this example is not of an S/MIME message.
Content-Type: multipart/mixed; boundary=bar Content-Type: multipart/mixed; boundary=bar
--bar --bar
Content-Type: text/plain; charset=iso-8859-1 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
=A1Hola Michael! =A1Hola Michael!
How do you like the new S/MIME specification? How do you like the new S/MIME specification?
It's generally a good idea to encode lines that begin with It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater- From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature. than (>) sign, thus invalidating the signature.
Also, in some cases it might be desirable to encode any =20 Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20 trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20 that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20 a gateway that modifies such whitespace (like BITNET). =20
--bar --bar
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI= HOxEa44b+EI=
--bar-- --bar--
3.2. The application/pkcs7-mime Media Type 3.2. The application/pkcs7-mime Media Type
The application/pkcs7-mime media type is used to carry CMS content The application/pkcs7-mime media type is used to carry CMS content
types including EnvelopedData, SignedData, and CompressedData. The types including EnvelopedData, SignedData, and CompressedData. The
details of constructing these entities are described in subsequent details of constructing these entities are described in subsequent
sections. This section describes the general characteristics of the sections. This section describes the general characteristics of the
application/pkcs7-mime media type. application/pkcs7-mime media type.
The carried CMS object always contains a MIME entity that is prepared The carried CMS object always contains a MIME entity that is prepared
skipping to change at page 26, line 18 skipping to change at page 26, line 45
3. If no common string is assigned, then the common string of 3. If no common string is assigned, then the common string of
"OID.<oid>" is recommended (for example, "OID.<oid>" is recommended (for example,
"OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC). "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC).
It is explicitly intended that this field be a suitable hint for mail It is explicitly intended that this field be a suitable hint for mail
client applications to indicate whether a message is "signed", client applications to indicate whether a message is "signed",
"authEnveloped" or "enveloped" without having to tunnel into the CMS "authEnveloped" or "enveloped" without having to tunnel into the CMS
payload. payload.
A registry for additional smime-type parameter values has been
defined in [RFC7114].
3.3. Creating an Enveloped-Only Message 3.3. Creating an 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 enveloped without signing it. It is important to note that sending enveloped
but not signed messages does not provide for data integrity. It is but not signed messages does not provide for data integrity. It is
possible to replace ciphertext in such a way that the processed possible to replace ciphertext in such a way that the processed
message will still be valid, but the meaning can be altered. message will still be valid, but the meaning can be altered.
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.
skipping to change at page 27, line 5 skipping to change at page 27, line 34
object. object.
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for enveloped-only messages is "enveloped- The smime-type parameter for enveloped-only messages is "enveloped-
data". The file extension for this type of message is ".p7m". data". The file extension for this type of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; Content-Type: application/pkcs7-mime; name=smime.p7m;
name=smime.p7m smime-type=enveloped-data
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEwdDYXJ
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H sUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGIiJi2lsGPcP
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eCbWx8+MDFbbpXadC
0GhIGfHfQbnj756YT64V DgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ipdSJuNnkVY4/M652jKKHR
LFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAgtaMXpRwZRNYAgDsiSf8Z9P43
LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=
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. Authenticated enveloped messages provide without signing it. Authenticated enveloped messages provide
confidentiality and integrity. It is important to note that sending confidentiality and integrity. It is important to note that sending
authenticated enveloped messages does not provide for authentication authenticated enveloped messages does not provide for authentication
when using S/MIME. It is possible to replace ciphertext in such a when using S/MIME. It is possible to replace ciphertext in such a
way that the processed message will still be valid, but the meaning way that the processed message will still be valid, but the meaning
can be altered. However this is substantially more difficult than it can be altered. However this is substantially more difficult than it
skipping to change at page 28, line 6 skipping to change at page 29, line 6
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for authenticated enveloped-only messages is The smime-type parameter for authenticated enveloped-only messages is
"authEnvelopedData". The file extension for this type of message is "authEnvelopedData". The file extension for this type of message is
".p7m". ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=authEnvelopedData; Content-Type: application/pkcs7-mime; smime-type=authEnvelopedData;
name=smime.p7m name=smime.p7m
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1
0GhIGfHfQbnj756YT64V Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg
vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq
BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y
Cb8rOy8+55106newEJohC/aDgWbJhrMKzSOwa7JraXOV3HXD3NvKbl665dRx
vmDwSCNaLCRU5q8/AxQx2SvnAbM+JKcEfC/VFdd4SiHNiUECAApLku2rMi5B
WrhW/FXmx9d+cjum2BRwB3wj0q1wajdB0/kVRbQwg697dnlYyUog4vpJERjr
7KAkawZx1RMHaM18wgZjUNpCBXFS3chQi9mTBp2i2Hf5iZ8OOtTx+rCQUmI6
Jhy03vdcPCCARBjn3v0d3upZYDZddMA41CB9fKnnWFjadV1KpYwv80tqsEfx
Vo0lJQ5VtJ8MHJiBpLVKadRIZ4iH2ULC0JtN5mXE1SrFKh7cqbJ4+7nqSRL3
oBTud3rX41DGshOjpqcYHT4sqYlgZkc6dp0g1+hF1p3cGmjHdpysV2NVSUev
ghHbvSqhIsXFzRSWKiZOigmlkv3R5LnjpYyP4brM62Jl7y0qborvV4dNMz7m
D+5YxSlH0KAe8z6TT3LHuQdN7QCkFoiUSCaNhpAFaakkGIpqcqLhpOK4lXxt
kptCG93eUwNCcTxtx6bXufPR5TUHohvZvfeqMp42kL37FJC/A8ZHoOxXy8+X
X5QYxCQNuofWlvnIWv0Nr8w65x6lgVjPYmd/cHwzQKBTBMXN6pBud/PZL5zF
tw3QHlQkBR+UflMWZKeN9L0KdQ27mQlCo5gQS85aifxoiiA2v9+0hxZw91rP
IW4D+GS7oMMoKj8ZNyCJJsyf5smRZ+WxeBoolb3+TiGcBBCsRnfe6noLZiFO
6Zeu2ZwE
3.5. Creating a Signed-Only Message 3.5. Creating a Signed-Only Message
There are two formats for signed messages defined for S/MIME: There are two formats for signed messages defined for S/MIME:
- application/pkcs7-mime with SignedData. - application/pkcs7-mime with SignedData.
- multipart/signed. - multipart/signed.
In general, the multipart/signed form is preferred for sending, and In general, the multipart/signed form is preferred for sending, and
skipping to change at page 29, line 22 skipping to change at page 31, line 5
Step 4. The ContentInfo object is inserted into an Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity. application/pkcs7-mime MIME entity.
The smime-type parameter for messages using application/pkcs7-mime The smime-type parameter for messages using application/pkcs7-mime
with SignedData is "signed-data". The file extension for this type with SignedData is "signed-data". The file extension for this type
of message is ".p7m". of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=signed-data; Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m name=smime.p7m
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBwGgIAQ
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH eDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMCAQICAgDIMA
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh kGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMTEwNDlaFw0zOTEyM
6YT64V0GhIGfHfQbnj75 zEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsGByqGSM44BAEwggEeAoGB
AIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0h+DNbzREjR/p+vpKGJL+HZMMg
23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOoi1TxP7AHCEdNXYjDw7Wz41UIddU5dh
DEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4kemGkVmuBPG2o+4NyErYov3k80CgYAmONAUi
TKqOfs+bdlLWWpMdiM5BAI1XPLLGjDDHlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oI
Xks+kPht6pzJIYo7dhTpzi5dowfNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/
Cve3RUP+YdMLRgUpgObo2OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9
k0hmd1dRMSPUNbb+VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNH
u8Iv2YUgFxirGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwG
A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0
gvEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgRRBbG
ljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIzjYNqtT1na
79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT
UwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFzeXle3YI5SKSBer/sAhQ
mCq7s/CTFHOEjgASeUjbMpx5g6A==
3.5.3. Signing Using the multipart/signed Format 3.5.3. Signing Using the multipart/signed Format
This format is a clear-signing format. Recipients without any S/MIME This format is a clear-signing format. Recipients without any S/MIME
or CMS processing facilities are able to view the message. It makes or CMS processing facilities are able to view the message. It makes
use of the multipart/signed media type described in [RFC1847]. The use of the multipart/signed media type described in [RFC1847]. The
multipart/signed media type has two parts. The first part contains multipart/signed media type has two parts. The first part contains
the MIME entity that is signed; the second part contains the the MIME entity that is signed; the second part contains the
"detached signature" CMS SignedData object in which the "detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent. encapContentInfo eContent field is absent.
skipping to change at page 31, line 14 skipping to change at page 33, line 14
(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"; micalg=SHA1;
micalg=sha-1; boundary=boundary42 boundary="----=_NextBoundry____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature"
--boundary42 This is a multi-part message in MIME format.
Content-Type: text/plain
This is a clear-signed message. ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
--boundary42 This is some sample content.
Content-Type: application/pkcs7-signature; name=smime.p7s ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21
Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M
7GhIGfHfYT64VQbnj756 IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz
SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE
/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8
baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP
VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2
RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr
d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu
OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp
2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j
BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3
jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ
IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG
DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG
f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
--boundary42-- ------=_NextBoundry____Fri,_06_Sep_2002_00:25:21--
The content that is digested (the first part of the multipart/signed) The content that is digested (the first part of the multipart/signed)
consists of the bytes: consists of the bytes:
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e
6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 74 65 6e 74 2e 0d 0a
67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
3.6. Creating a Compressed-Only Message 3.6. Creating a Compressed-Only Message
This section describes the format for compressing a MIME entity. This section describes the format for compressing a MIME entity.
Please note that versions of S/MIME prior to version 3.1 did not Please note that versions of S/MIME prior to version 3.1 did not
specify any use of CompressedData, and will not recognize it. The specify any use of CompressedData, and will not recognize it. The
use of a capability to indicate the ability to receive CompressedData use of a capability to indicate the ability to receive CompressedData
is described in [RFC3274] and is the preferred method for is described in [RFC3274] and is the preferred method for
compatibility. compatibility.
skipping to change at page 32, line 27 skipping to change at page 34, line 39
The smime-type parameter for compressed-only messages is "compressed- The smime-type parameter for compressed-only messages is "compressed-
data". The file extension for this type of message is ".p7z". data". The file extension for this type of message is ".p7z".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=compressed-data; Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z name=smime.p7z
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z Content-Disposition: attachment; filename=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 eNoLycgsVgCi4vzcVIXixNyCnFSF5Py8ktS8Ej0AlCkKVA==
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
3.7. Multiple Operations 3.7. Multiple Operations
The signed-only, enveloped-only, and compressed-only MIME formats can The signed-only, enveloped-only, and compressed-only MIME formats can
be nested. This works because these formats are all MIME entities be nested. This works because these formats are all MIME entities
that encapsulate other MIME entities. that encapsulate other MIME entities.
An S/MIME implementation MUST be able to receive and process An S/MIME implementation MUST be able to receive and process
arbitrarily nested S/MIME within reasonable resource limits of the arbitrarily nested S/MIME within reasonable resource limits of the
recipient computer. recipient computer.
skipping to change at page 40, line 39 skipping to change at page 42, line 39
If a sending agent is sending the same message using different If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel might be able to determine the contents of the strongly channel might be able to determine the contents of the strongly
encrypted message by decrypting the weakly encrypted version. In encrypted message by decrypting the weakly encrypted version. In
other words, a sender SHOULD NOT send a copy of a message using other words, a sender SHOULD NOT send a copy of a message using
weaker cryptography than they would use for the original of the weaker cryptography than they would use for the original of the
message. message.
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it. This is
one of the reasons for moving from EnvelopedData to AuthEnvelopedData
as the authenticated encryption algorithms provide the authentication
without needing the SignedData layer.
If an implementation is concerned about compliance with National If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
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.
skipping to change at page 42, line 5 skipping to change at page 44, line 7
Even when all of the preconditions are met and origination of a Even when all of the preconditions are met and origination of a
message is established by the use of an authenticated encryption message is established by the use of an authenticated encryption
algorithm, users need to be aware that there is no way to prove this 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 to a third party. This is because either of the parties can
successfully create the message (or just alter the content) based on 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 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 origination is always built on a presumption that "I did not send
this message to myself." this message to myself."
All of the authenticated encryption algorithms in this document use
counter mode for the encryption portion of the algorithm. This means
that the length of the plain text will always be known as the cipher
text length and the plain text length are always the same. This
information can enable passive observers to infer information based
solely on the length of the message. Applications for which this is
a significant problem need to provide some type of padding algorithm
so that the length of the message does not provide this information.
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 42, line 44 skipping to change at page 45, line 8
[I-D.ietf-curdle-cms-ecdh-new-curves] [I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key Housley, R., "Use of the Elliptic Curve Diffie-Hellamn Key
Agreement Algorithm with X25519 and X448 in the Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", draft-ietf-curdle- Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
cms-ecdh-new-curves-01 (work in progress), September 2016. cms-ecdh-new-curves-01 (work in progress), September 2016.
[I-D.ietf-curdle-cms-eddsa-signatures] [I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-00 (work in progress), September 2016. signatures-03 (work in progress), January 2017.
[I-D.ietf-lamps-rfc5750-bis] [I-D.ietf-lamps-rfc5750-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/ MIME) Version Multipurpose Internet Mail Extensions (S/ MIME) Version
3.2 Certificate Handling", draft-ietf-lamps-rfc5750-bis-00 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-01
(work in progress), August 2016. (work in progress), October 2016.
[MIME-SPEC] [MIME-SPEC]
"MIME Message Specifications". "MIME Message Specifications".
This is the set of documents that define how to use MIME. This is the set of documents that define how to use MIME.
This set of documents is [RFC2045], [RFC2046], [RFC2047], This set of documents is [RFC2045], [RFC2046], [RFC2047],
[RFC2049], [RFC4288], and [RFC4289]. [RFC2049], [RFC4288], and [RFC4289].
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
skipping to change at page 47, line 38 skipping to change at page 49, line 46
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004, RFC 3851, DOI 10.17487/RFC3851, July 2004,
<http://www.rfc-editor.org/info/rfc3851>. <http://www.rfc-editor.org/info/rfc3851>.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, DOI 10.17487/RFC3852, July 2004, RFC 3852, DOI 10.17487/RFC3852, July 2004,
<http://www.rfc-editor.org/info/rfc3852>. <http://www.rfc-editor.org/info/rfc3852>.
[RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134,
DOI 10.17487/RFC4134, July 2005,
<http://www.rfc-editor.org/info/rfc4134>.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, Hashes in Internet Protocols", RFC 4270,
DOI 10.17487/RFC4270, November 2005, DOI 10.17487/RFC4270, November 2005,
<http://www.rfc-editor.org/info/rfc4270>. <http://www.rfc-editor.org/info/rfc4270>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
skipping to change at page 48, line 25 skipping to change at page 50, line 39
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>. <http://www.rfc-editor.org/info/rfc6194>.
[RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic [RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
Curve Diffie-Hellman Key Agreement in Cryptographic Curve Diffie-Hellman Key Agreement in Cryptographic
Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June Message Syntax", RFC 6278, DOI 10.17487/RFC6278, June
2011, <http://www.rfc-editor.org/info/rfc6278>. 2011, <http://www.rfc-editor.org/info/rfc6278>.
[RFC7114] Leiba, B., "Creation of a Registry for smime-type
Parameter Values", RFC 7114, DOI 10.17487/RFC7114, January
2014, <http://www.rfc-editor.org/info/rfc7114>.
[RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N., [RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
Cipher Suites for Transport Layer Security (TLS)", Cipher Suites for Transport Layer Security (TLS)",
RFC 7905, DOI 10.17487/RFC7905, June 2016, RFC 7905, DOI 10.17487/RFC7905, June 2016,
<http://www.rfc-editor.org/info/rfc7905>. <http://www.rfc-editor.org/info/rfc7905>.
[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],
skipping to change at page 54, line 39 skipping to change at page 57, line 12
it is recommended that RFC 2311 [SMIMEv2] be moved to Historic it is recommended that RFC 2311 [SMIMEv2] be moved to Historic
status. status.
Appendix D. Acknowledgments Appendix D. Acknowledgments
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 v4.0. v3.2 or v4.0.
Some of the examples in this document were stolen from [RFC4134].
Thanks go the the people who wrote and verified the examples in that
document.
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 various versions of 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,
and John Pawling. and John Pawling.
 End of changes. 55 change blocks. 
136 lines changed or deleted 215 lines changed or added

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