draft-ietf-lamps-rfc5751-bis-07.txt   draft-ietf-lamps-rfc5751-bis-08.txt 
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 5751 (if approved) B. Ramsdell Obsoletes: 5751 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: October 15, 2018 S. Turner Expires: November 3, 2018 S. Turner
sn3rd sn3rd
April 13, 2018 May 2, 2018
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-07 draft-ietf-lamps-rfc5751-bis-08
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 15, 2018. This Internet-Draft will expire on November 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 42 skipping to change at page 2, line 42
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 for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 9
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 10
2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 10
2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 11
2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . 13
2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 13
2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 13 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 14
2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14 2.5.2. SMIME Capabilities Attribute . . . . . . . . . . . . 14
2.5.3. Encryption Key Preference Attribute . . . . . . . . . 15 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 16
2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 20 Compressing . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 21
3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 22 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 23
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 . . . . . . . . . . 25 3.2.1. The name and filename Parameters . . . . . . . . . . 25
3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 26
3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 27
3.4. Creating an Authenticated Enveloped-Only Message . . . . 28 3.4. Creating an Authenticated Enveloped-Only Message . . . . 28
3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 29
3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 29
3.5.2. Signing Using application/pkcs7-mime with SignedData 30 3.5.2. Signing Using application/pkcs7-mime with SignedData 30
3.5.3. Signing Using the multipart/signed Format . . . . . . 31 3.5.3. Signing Using the multipart/signed Format . . . . . . 31
skipping to change at page 3, line 47 skipping to change at page 3, line 47
4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 38
4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 38
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 38
5.2. Media Type for application/pkcs7-signature . . . . . . . 39 5.2. Media Type for application/pkcs7-signature . . . . . . . 39
5.3. Register authEnveloped-data smime-type . . . . . . . . . 40 5.3. Register authEnveloped-data smime-type . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. Normative References . . . . . . . . . . . . . . . . . . 44 7.1. Normative References . . . . . . . . . . . . . . . . . . 44
7.2. Informative References . . . . . . . . . . . . . . . . . 48 7.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 52
Appendix B. Historic Mail Considerations . . . . . . . . . . . . 53 Appendix B. Historic Mail Considerations . . . . . . . . . . . . 54
B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54 B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 54
B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54 B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 54
B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56 B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 56
B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 56 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 . . . . . . . . . . . . . . . . . . . . . . . 56 Status . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 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 message
compression. compression.
S/MIME can be used by traditional mail user agents (MUAs) to add S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to cryptographic security services to mail that is sent, and to
interpret cryptographic security services in mail that is received. interpret cryptographic security services in mail that is received.
However, S/MIME is not restricted to mail; it can be used with any However, S/MIME is not restricted to mail; it can be used with any
transport mechanism that transports MIME data, such as HTTP or SIP. transport mechanism that transports MIME data, such as HTTP or SIP.
As such, S/MIME takes advantage of the object-based features of MIME As such, S/MIME takes advantage of the object-based features of MIME
and allows secure messages to be exchanged in mixed-transport and allows secure messages to be exchanged in mixed-transport
systems. systems.
Further, S/MIME can be used in automated message transfer agents that Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet. the encryption of FAX messages sent over the Internet.
This document defines the version 4.0 of the S/MIME Message
specification. As such this document obsoletes version 3.2 of the
S/MIME Message specification [RFC5751].
1.1. Specification Overview 1.1. Specification Overview
This document describes a protocol for adding cryptographic signature This document describes a protocol for adding cryptographic signature
and encryption services to MIME data. The MIME standard [MIME-SPEC] and encryption services to MIME data. The MIME standard [MIME-SPEC]
provides a general structure for the content of Internet messages and provides a general structure for the content of Internet messages and
allows extensions for new content-type-based applications. allows extensions for new content-type-based applications.
This specification defines how to create a MIME body part that has This specification defines how to create a MIME body part that has
been cryptographically enhanced according to the Cryptographic been cryptographically enhanced according to the Cryptographic
Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315]. Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315].
skipping to change at page 6, line 40 skipping to change at page 6, line 44
unauthorized changes to data by ensuring that unauthorized changes to data by ensuring that
changes to the data are detectable. [RFC4949] changes to the data are detectable. [RFC4949]
Data Confidentiality: The property that data is not disclosed to Data Confidentiality: The property that data is not disclosed to
system entities unless they have been authorized system entities unless they have been authorized
to know the data. [RFC4949] to know the data. [RFC4949]
1.3. Conventions Used in This Document 1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
We define the additional requirement levels: We define the additional requirement levels:
SHOULD+ This term means the same as SHOULD. However, the authors SHOULD+ This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD+ will be expect that a requirement marked as SHOULD+ will be
promoted at some future time to be a MUST. promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, the authors SHOULD- This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD- will be demoted expect that a requirement marked as SHOULD- will be demoted
to a MAY in a future version of this document. to a MAY in a future version of this document.
MUST- This term means the same as MUST. However, the authors MUST- This term means the same as MUST. However, the authors
expect that this requirement will no longer be a MUST in a expect that this requirement will no longer be a MUST in a
future document. Although its status will be determined at future document. Although its status will be determined at
a later time, it is reasonable to expect that if a future a later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST- revision of a document alters the status of a MUST-
requirement, it will remain at least a SHOULD or a SHOULD-. requirement, it will remain at least a SHOULD or a SHOULD-.
The term RSA in this document almost always refers to the PKCS#1 v1.5 The term RSA in this document almost always refers to the PKCS#1 v1.5
RSA signature or encryption algorithms even when not qualified as RSA [RFC2313] signature or encryption algorithms even when not
such. There are a couple of places where it refers to the general qualified as such. There are a couple of places where it refers to
RSA cryptographic operation, these can be determined from the context the general RSA cryptographic operation, these can be determined from
where it is used. the context where it is used.
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]. [RFC2311] 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 wrap algorithm, and the Diffie-Hellman (DH) algorithm [RFC2631]
a SHOULD implement. changed to 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.
The RSA public key algorithm was changed to a MUST implement The RSA public key algorithm was changed to a MUST implement
signature algorithm. signature algorithm.
Ambiguous language about the use of "empty" SignedData messages to Ambiguous language about the use of "empty" SignedData messages to
transmit certificates was clarified to reflect that transmission of transmit certificates was clarified to reflect that transmission of
Certificate Revocation Lists is also allowed. Certificate Revocation Lists is also allowed.
skipping to change at page 9, line 36 skipping to change at page 9, line 44
1.7. Changes for S/MIME v4.0 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 and - Update the content encryption algorithms (Section 2.7 and
Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove
AES-192 CBC, mark tripleDES as historic. AES-192 CBC, mark tripleDES as historic.
- Update the set of signature algorithms (Section 2.2): Add EdDSA - Update the set of signature algorithms (Section 2.2): Add Edwards-
and ECDSA, mark DSA as historic curve DSA (EdDSA) and ECDSA, mark DSA as historic
- Update the set of digest algorithms (Section 2.1): Add SHA-512, - Update the set of digest algorithms (Section 2.1): Add SHA-512,
mark SHA-1 as historic. mark SHA-1 as historic.
- Update the size of keys to be used for RSA encryption and RSA - Update the size of keys to be used for RSA encryption and RSA
signing (Section 4). 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.
skipping to change at page 10, line 38 skipping to change at page 10, line 47
There are different sets of requirements placed on receiving and There are different sets of requirements placed on receiving and
sending agents. By having the different requirements, the maximum sending agents. By having the different requirements, the maximum
amount of interoperability is achieved as it allows for specialized amount of interoperability is achieved as it allows for specialized
protection of private key material but maximum signature validation. protection of private key material but maximum signature validation.
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 Pure EdDSA mode
[I-D.ietf-curdle-cms-eddsa-signatures].
- MUST- support RSA PKCS#1 v1.5 with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - . SHOULD support RSASSA-PSS with SHA-256.
Sending agents: Sending agents:
- MUST support at least one of the following algorithms: ECDSA with - MUST support at least one of the following algorithms: ECDSA with
curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA curve P-256 and SHA-256, or EdDSA with curve 25519 using PureEdDSA
mode. mode.
- MUST- support RSA PKCS#1 v1.5 with SHA-256. - MUST- support RSA PKCS#1 v1.5 with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
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 back section of the community which believes that there might be a back
door to these curves. The EdDSA curves were standardized in the IETF door to these curves. The EdDSA curves were standardized in the IETF
in a more transparent method. However, there are still significant in a more transparent method. However, there are still significant
sections of the industry which need to have NIST approved algorithms. sections of the industry which need to have NIST approved algorithms.
For this reason, both sets of curves are represented in the receiving For this reason, both sets of curves are represented in the receiving
agent list, but there is only a requirement for curve in the sending agent list, but there is only a requirement for one curve in the
agent list. This requirement makes sure that maximum sending agent list. This requirement makes sure that maximum
interoperability between receivers and senders will exist. interoperability between receivers and senders will exist.
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 11, line 44 skipping to change at page 11, line 52
- SHOULD+ support RSAES-OAEP, as specified in [RFC3560]. - SHOULD+ support RSAES-OAEP, as specified in [RFC3560].
When ECDH ephemeral-static is used, a key wrap algorithm is also When ECDH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The
underlying encryption functions for the key wrap and content underlying encryption functions for the key wrap and content
encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for
the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm). As both 128 and 256 bit with AES-128 content encryption algorithm). As both 128 and 256 bit
AES modes are mandatory-to-implement as content encryption algorithms AES modes are mandatory-to-implement as content encryption algorithms
(Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST
be supported when ECDH ephemeral-static is used. be supported when ECDH ephemeral-static is used. Recipients MAY
enforce this, but MUST use the weaker of the two as part of any
cryptographic strength computation it might do.
Appendix B provides information on algorithms support in older Appendix B provides information on algorithms support in older
versions of S/MIME. versions of S/MIME.
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, AuthEnvelopedData, and CompressedData SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
content types are currently used for S/MIME. content types are currently used for S/MIME.
skipping to change at page 12, line 37 skipping to change at page 12, line 42
Sending agents MUST use the SignedData content type to apply a Sending agents MUST use the SignedData content type to apply a
digital signature to a message or, in a degenerate case where there digital signature to a message or, in a degenerate case where there
is no signature information, to convey certificates. Applying a is no signature information, to convey certificates. Applying a
signature to a message provides authentication, message integrity, signature to a message provides authentication, message integrity,
and non-repudiation of origin. and non-repudiation of origin.
2.4.3. EnvelopedData Content Type 2.4.3. EnvelopedData Content Type
This content type is used to apply data confidentiality to a message. This content type is used to apply data confidentiality to a message.
A sender needs to have access to a public key for each intended In order to distribute the symmetric key, a sender needs to have
message recipient to use this service. access to a public key for each intended message recipient to use
this service.
2.4.4. AuthEnvelopedData Content Type 2.4.4. AuthEnvelopedData Content Type
This content type is used to apply data confidentiality and message This content type is used to apply data confidentiality and message
integrity to a message. This content type does not provide integrity to a message. This content type does not provide
authentication or non-repudiation. A sender needs to have access to authentication or non-repudiation. In order to distribute the
a public key for each intended message recipient to use this service. symmetric key, a sender needs to have access to a public key for each
intended message recipient to use this service.
2.4.5. CompressedData Content Type 2.4.5. CompressedData Content Type
This content type is used to apply data compression to a message. This content type is used to apply data compression to a message.
This content type does not provide authentication, message integrity, This content type does not provide authentication, message integrity,
non-repudiation, or data confidentiality, and is only used to reduce non-repudiation, or data confidentiality, and is only used to reduce
the message's size. the message's size.
See Section 3.7 for further guidance on the use of this type in See Section 3.7 for further guidance on the use of this type in
conjunction with other CMS types. conjunction with other CMS types.
2.5. Attributes and the SignerInfo Type 2.5. Attributes and the SignerInfo Type
The SignerInfo type allows the inclusion of unsigned and signed The SignerInfo type allows the inclusion of unsigned and signed
attributes along with a signature. attributes along with a signature. These attributes can be required
for processing of message (i.e. Message Digest), information the
signer supplied (i.e. SMIME Capabilities) that should be processed,
or attributes which are not relevant in the current situation (i.e.
mlExpansionList [RFC2634] for mail viewers).
Receiving agents MUST be able to handle zero or one instance of each Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes listed here. Sending agents SHOULD generate of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each one instance of each of the following signed attributes in each
S/MIME message: S/MIME message:
- Signing Time (Section 2.5.1 in this document) - Signing Time (Section 2.5.1 in this document)
- SMIME Capabilities (Section 2.5.2 in this document) - SMIME Capabilities (Section 2.5.2 in this document)
skipping to change at page 13, line 49 skipping to change at page 14, line 17
values that they do not recognize in a graceful manner. values that they do not recognize in a graceful manner.
Interactive sending agents that include signed attributes that are Interactive sending agents that include signed attributes that are
not listed here SHOULD display those attributes to the user, so that not listed here SHOULD display those attributes to the user, so that
the user is aware of all of the data being signed. the user is aware of all of the data being signed.
2.5.1. Signing Time Attribute 2.5.1. Signing Time Attribute
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 signer and therefore is only as trustworthy as that signer.
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
skipping to change at page 19, line 10 skipping to change at page 19, line 25
recipient, recipient,
then the sending agent SHOULD use AES-256 GCM because it is a then the sending agent SHOULD use AES-256 GCM because it is a
stronger algorithm and is required by S/MIME v4.0. If the sending stronger algorithm and is required by S/MIME v4.0. If the sending
agent chooses not to use AES-256 GCM in this step, given the agent chooses not to use AES-256 GCM in this step, given the
presumption is that a client implementing AES-GCM would do both presumption is that a client implementing AES-GCM would do both
AES-256 and AES-128, it SHOULD use AES-128 CBC. AES-256 and AES-128, it SHOULD use AES-128 CBC.
2.7.2. Choosing Weak Encryption 2.7.2. Choosing Weak Encryption
All algorithms that use 112-bit keys are considered by many to be Algorithms such as RC2 are considered to be weak encryption
weak encryption. A sending agent that is controlled by a human algorithms. Algorithms such as TripleDES are not state of the art
SHOULD allow a human sender to determine the risks of sending data and are considered to be weaker algorithms than AES. A sending agent
using a weak encryption algorithm before sending the data, and that is controlled by a human SHOULD allow a human sender to
possibly allow the human to use a stronger encryption method such as determine the risks of sending data using a weaker encryption
AES GCM or AES CBC. algorithm before sending the data, and possibly allow the human to
use a stronger encryption algorithm such as AES GCM or AES CBC even
if there is a possibility that the recipient will not be able to
process that algorithm.
2.7.3. Multiple Recipients 2.7.3. Multiple Recipients
If a sending agent is composing an encrypted message to a group of If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients where the encryption capabilities of some of the
recipients do not overlap, the sending agent is forced to send more recipients do not overlap, the sending agent is forced to send more
than one message. Please note that if the sending agent chooses to than one message. Please note that if the sending agent chooses to
send a message encrypted with a strong algorithm, and then send the send a message encrypted with a strong algorithm, and then send the
same message encrypted with a weak algorithm, someone watching the same message encrypted with a weak algorithm, someone watching the
communications channel could learn the contents of the strongly communications channel could learn the contents of the strongly
skipping to change at page 25, line 23 skipping to change at page 25, line 29
agent to decode the ASN.1 for the object. The Content-Type header agent to decode the ASN.1 for the object. The Content-Type header
field of all application/pkcs7-mime objects SHOULD include the field of all application/pkcs7-mime objects SHOULD include the
optional "smime-type" parameter, as described in the following optional "smime-type" parameter, as described in the following
sections. sections.
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 [RFC2183] 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 Media Type File
Extension Extension
application/pkcs7-mime (SignedData, EnvelopedData, .p7m application/pkcs7-mime (SignedData, EnvelopedData, .p7m
AuthEnvelopedData) AuthEnvelopedData)
application/pkcs7-mime (degenerate SignedData certificate .p7c application/pkcs7-mime (degenerate SignedData certificate .p7c
management message) management message)
application/pkcs7-mime (CompressedData) .p7z application/pkcs7-mime (CompressedData) .p7z
skipping to change at page 28, line 10 skipping to change at page 28, line 10
iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC
bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip
dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA
gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU=
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 data integrity. It is important to note that confidentiality and data integrity. It is important to note that
sending authenticated enveloped messages does not provide for sending authenticated enveloped messages does not provide for proof
origination when using S/MIME. It is possible for a third party to of origination when using S/MIME. It is possible for a third party
replace ciphertext in such a way that the processed message will to replace ciphertext in such a way that the processed message will
still be valid, but the meaning can be altered. However this is still be valid, but the meaning can be altered. However this is
substantially more difficult than it is for an enveloped-only message substantially more difficult than it is for an enveloped-only message
as the algorithm does provide a level of authentication. Any as the algorithm does provide a level of authentication. Any
recipient for whom the message is encrypted can replace it without recipient for whom the message is encrypted can replace it without
detection. detection.
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
skipping to change at page 45, line 16 skipping to change at page 45, line 16
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", Federal Information "Digital Signature Standard (DSS)", Federal Information
Processing Standards Publication 186-4, July 2013. Processing Standards Publication 186-4, July 2013.
[I-D.ietf-curdle-cms-ecdh-new-curves] [I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Housley, R., "Use of the Elliptic Curve Diffie-Hellman 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-10 (work in progress), August 2017. cms-ecdh-new-curves-10 (work in progress), August 2017.
[I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-08 (work in progress), October 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
4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-04 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-05
(work in progress), April 2017. (work in progress), April 2018.
[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], [RFC6838], 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
Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
October 1995, <https://www.rfc-editor.org/info/rfc1847>. October 1995, <https://www.rfc-editor.org/info/rfc1847>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
skipping to change at page 46, line 10 skipping to change at page 46, line 15
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>. <https://www.rfc-editor.org/info/rfc2049>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
"Remote Authentication Dial In User Service (RADIUS)", Presentation Information in Internet Messages: The
RFC 2138, DOI 10.17487/RFC2138, April 1997, Content-Disposition Header Field", RFC 2183,
<https://www.rfc-editor.org/info/rfc2138>. DOI 10.17487/RFC2183, August 1997,
<https://www.rfc-editor.org/info/rfc2183>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>. <https://www.rfc-editor.org/info/rfc2634>.
[RFC3274] Gutmann, P., "Compressed Data Content Type for [RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, Cryptographic Message Syntax (CMS)", RFC 3274,
DOI 10.17487/RFC3274, June 2002, DOI 10.17487/RFC3274, June 2002,
<https://www.rfc-editor.org/info/rfc3274>. <https://www.rfc-editor.org/info/rfc3274>.
skipping to change at page 46, line 48 skipping to change at page 47, line 5
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, Cryptographic Message Syntax (CMS)", RFC 4056,
DOI 10.17487/RFC4056, June 2005, DOI 10.17487/RFC4056, June 2005,
<https://www.rfc-editor.org/info/rfc4056>. <https://www.rfc-editor.org/info/rfc4056>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
December 2005, <https://www.rfc-editor.org/info/rfc4288>.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
<https://www.rfc-editor.org/info/rfc4289>. <https://www.rfc-editor.org/info/rfc4289>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007, DOI 10.17487/RFC5035, August 2007,
<https://www.rfc-editor.org/info/rfc5035>. <https://www.rfc-editor.org/info/rfc5035>.
skipping to change at page 47, line 38 skipping to change at page 47, line 38
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <https://www.rfc-editor.org/info/rfc5753>. 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SMIMEv4.0] [SMIMEv4.0]
"S/MIME version 4.0". "S/MIME version 4.0".
This group of documents represents S/MIME version 4.0. This group of documents represents S/MIME version 4.0.
This set of documents are [RFC2634], This set of documents are [RFC2634],
[I-D.ietf-lamps-rfc5750-bis], [[This Document]], [I-D.ietf-lamps-rfc5750-bis], [[This Document]],
[RFC5652], and [RFC5035]. [RFC5652], and [RFC5035].
[X.680] "Information Technology - Abstract Syntax Notation One [X.680] "Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. ITU-T (ASN.1): Specification of basic notation. ITU-T
Recommendation X.680 (2002)", ITU-T X.680, ISO/ Recommendation X.680 (2002)", ITU-T X.680, ISO/
IEC 8824-1:2008, November 2008. IEC 8824-1:2008, November 2008.
[X.681] "Information Technology - Abstract Syntax Notation One [X.681] "Information Technology - Abstract Syntax Notation One
(ASN.1): Information object specification", ITU-T X.681, (ASN.1): Information object specification", ITU-T X.681,
 End of changes. 36 change blocks. 
58 lines changed or deleted 87 lines changed or added

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