Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: LAMPS

RFC 8551

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification

Pages: 63
Proposed STD
Obsoletes:  5751
Part 5 of 5 – Pages 48 to 63
First   Prev   None

Top   ToC   RFC8551 - Page 48   prevText
7.  References

7.1.  Reference Conventions

   [ASN.1] refers to [X.680], [X.681], [X.682], and [X.683].

   [CMS] refers to [RFC5083] and [RFC5652].

   [ESS] refers to [RFC2634] and [RFC5035].

   [MIME-SPEC] refers to [RFC2045], [RFC2046], [RFC2047], [RFC2049],
   [RFC6838], and [RFC4289].

   [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and
   [RFC2315].

   [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633],
   [RFC2634], and [RFC5035].
Top   ToC   RFC8551 - Page 49
   [SMIMEv3.1] refers to [RFC2634], [RFC5035], [RFC5652], [RFC5750], and
   [RFC5751].

   [SMIMEv3.2] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and
   [RFC5035].

   [SMIMEv4] refers to [RFC2634], [RFC5035], [RFC5652], [RFC8550], and
   this document.

7.2.  Normative References

   [CHARSETS] IANA, "Character sets assigned by IANA",
              <http://www.iana.org/assignments/character-sets>.

   [FIPS186-4]
              National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", Federal Information
              Processing Standards Publication 186-4,
              DOI 10.6028/NIST.FIPS.186-4, July 2013,
              <https://nvlpubs.nist.gov/nistpubs/fips/
              nist.fips.186-4.pdf>.

   [RFC1847]  Galvin, J., Murphy, S., Crocker, S., and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
              October 1995, <https://www.rfc-editor.org/info/rfc1847>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, DOI 10.17487/RFC2047, November 1996,
              <https://www.rfc-editor.org/info/rfc2047>.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
              <https://www.rfc-editor.org/info/rfc2049>.
Top   ToC   RFC8551 - Page 50
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2183]  Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183,
              DOI 10.17487/RFC2183, August 1997,
              <https://www.rfc-editor.org/info/rfc2183>.

   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
              RFC 2634, DOI 10.17487/RFC2634, June 1999,
              <https://www.rfc-editor.org/info/rfc2634>.

   [RFC3274]  Gutmann, P., "Compressed Data Content Type for
              Cryptographic Message Syntax (CMS)", RFC 3274,
              DOI 10.17487/RFC3274, June 2002,
              <https://www.rfc-editor.org/info/rfc3274>.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
              <https://www.rfc-editor.org/info/rfc3370>.

   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
              Algorithm in Cryptographic Message Syntax (CMS)",
              RFC 3560, DOI 10.17487/RFC3560, July 2003,
              <https://www.rfc-editor.org/info/rfc3560>.

   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
              <https://www.rfc-editor.org/info/rfc3565>.

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
              <https://www.rfc-editor.org/info/rfc4289>.

   [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
              Cryptographic Message Syntax (CMS)", RFC 4056,
              DOI 10.17487/RFC4056, June 2005,
              <https://www.rfc-editor.org/info/rfc4056>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.
Top   ToC   RFC8551 - Page 51
   [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
              Authenticated-Enveloped-Data Content Type", RFC 5083,
              DOI 10.17487/RFC5083, November 2007,
              <https://www.rfc-editor.org/info/rfc5083>.

   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, DOI 10.17487/RFC5084, November 2007,
              <https://www.rfc-editor.org/info/rfc5084>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753,
              January 2010, <https://www.rfc-editor.org/info/rfc5753>.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754,
              January 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>.

   [RFC8418]  Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
              Agreement Algorithm with X25519 and X448 in the
              Cryptographic Message Syntax (CMS)", RFC 8418,
              DOI 10.17487/RFC8418, August 2018,
              <https://www.rfc-editor.org/info/rfc8418>.

   [RFC8419]  Housley, R., "Use of Edwards-Curve Digital Signature
              Algorithm (EdDSA) Signatures in the Cryptographic Message
              Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419,
              August 2018, <https://www.rfc-editor.org/info/rfc8419>.

   [RFC8550]  Schaad, J., Ramsdell, B., and S. Turner,
              "Secure/Multipurpose Internet Mail Extensions (S/MIME)
              Version 4.0 Certificate Handling", RFC 8550,
              DOI 10.17487/RFC8550, April 2019,
              <https://www.rfc-editor.org/info/rfc8550>.
Top   ToC   RFC8551 - Page 52
   [X.680]    "Information Technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation", ITU-T
              Recommendation X.680, ISO/IEC 8824-1:2015, August 2015,
              <https://www.itu.int/rec/T-REC-X.680>.

   [X.681]    "Information Technology - Abstract Syntax Notation One
              (ASN.1): Information object specification", ITU-T
              Recommendation X.681, ISO/IEC 8824-2:2015, August 2015,
              <https://www.itu.int/rec/T-REC-X.681>.

   [X.682]    "Information Technology - Abstract Syntax Notation One
              (ASN.1): Constraint specification", ITU-T
              Recommendation X.682, ISO/IEC 8824-3:2015, August 2015,
              <https://www.itu.int/rec/T-REC-X.682>.

   [X.683]    "Information Technology - Abstract Syntax Notation One
              (ASN.1): Parameterization of ASN.1 specifications", ITU-T
              Recommendation X.683, ISO/IEC 8824-4:2015, August 2015,
              <https://www.itu.int/rec/T-REC-X.683>.

   [X.690]    "Information Technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015,
              August 2015, <https://www.itu.int/rec/T-REC-X.690>.

7.3.  Informative References

   [Efail]    Poddebniak, D., Dresen, C., Muller, J., Ising, F.,
              Schinzel, S., Friedberger, S., Somorovsky, J., and J.
              Schwenk, "Efail: Breaking S/MIME and OpenPGP Email
              Encryption using Exfiltration Channels",
              UsenixSecurity 2018, August 2018,
              <https://www.usenix.org/system/files/conference/
              usenixsecurity18/sec18-poddebniak.pdf>.

   [FIPS186-2]
              National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS) (also with Change
              Notice 1)", Federal Information Processing Standards
              Publication 186-2, January 2000,
              <https://csrc.nist.gov/publications/detail/fips/186/2/
              archive/2000-01-27>.

   [RFC1866]  Berners-Lee, T. and D. Connolly, "Hypertext Markup
              Language - 2.0", RFC 1866, DOI 10.17487/RFC1866,
              November 1995, <https://www.rfc-editor.org/info/rfc1866>.
Top   ToC   RFC8551 - Page 53
   [RFC2268]  Rivest, R., "A Description of the RC2(r) Encryption
              Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998,
              <https://www.rfc-editor.org/info/rfc2268>.

   [RFC2311]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
              L. Repka, "S/MIME Version 2 Message Specification",
              RFC 2311, DOI 10.17487/RFC2311, March 1998,
              <https://www.rfc-editor.org/info/rfc2311>.

   [RFC2312]  Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
              "S/MIME Version 2 Certificate Handling", RFC 2312, DOI
              10.17487/RFC2312, March 1998,
              <https://www.rfc-editor.org/info/rfc2312>.

   [RFC2313]  Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
              RFC 2313, DOI 10.17487/RFC2313, March 1998,
              <https://www.rfc-editor.org/info/rfc2313>.

   [RFC2314]  Kaliski, B., "PKCS #10: Certification Request Syntax
              Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
              <https://www.rfc-editor.org/info/rfc2314>.

   [RFC2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax
              Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
              <https://www.rfc-editor.org/info/rfc2315>.

   [RFC2630]  Housley, R., "Cryptographic Message Syntax", RFC 2630,
              DOI 10.17487/RFC2630, June 1999,
              <https://www.rfc-editor.org/info/rfc2630>.

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, DOI 10.17487/RFC2631, June 1999,
              <https://www.rfc-editor.org/info/rfc2631>.

   [RFC2632]  Ramsdell, B., Ed., "S/MIME Version 3 Certificate
              Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,
              <https://www.rfc-editor.org/info/rfc2632>.

   [RFC2633]  Ramsdell, B., Ed., "S/MIME Version 3 Message
              Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
              <https://www.rfc-editor.org/info/rfc2633>.

   [RFC2785]  Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
              Attacks on the Diffie-Hellman Key Agreement Method for
              S/MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000,
              <https://www.rfc-editor.org/info/rfc2785>.
Top   ToC   RFC8551 - Page 54
   [RFC3218]  Rescorla, E., "Preventing the Million Message Attack on
              Cryptographic Message Syntax", RFC 3218,
              DOI 10.17487/RFC3218, January 2002,
              <https://www.rfc-editor.org/info/rfc3218>.

   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 3766, DOI 10.17487/RFC3766, April 2004,
              <https://www.rfc-editor.org/info/rfc3766>.

   [RFC3850]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Certificate Handling",
              RFC 3850, DOI 10.17487/RFC3850, July 2004,
              <https://www.rfc-editor.org/info/rfc3850>.

   [RFC3851]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, DOI 10.17487/RFC3851, July 2004,
              <https://www.rfc-editor.org/info/rfc3851>.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, DOI 10.17487/RFC3852, July 2004,
              <https://www.rfc-editor.org/info/rfc3852>.

   [RFC4134]  Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134,
              DOI 10.17487/RFC4134, July 2005,
              <https://www.rfc-editor.org/info/rfc4134>.

   [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC 4270,
              DOI 10.17487/RFC4270, November 2005,
              <https://www.rfc-editor.org/info/rfc4270>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC5035]  Schaad, J., "Enhanced Security Services (ESS) Update:
              Adding CertID Algorithm Agility", RFC 5035, DOI
              10.17487/RFC5035, August 2007,
              <https://www.rfc-editor.org/info/rfc5035>.

   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Certificate
              Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
              <https://www.rfc-editor.org/info/rfc5750>.
Top   ToC   RFC8551 - Page 55
   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, DOI 10.17487/RFC5751,
              January 2010, <https://www.rfc-editor.org/info/rfc5751>.

   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              RFC 6151, DOI 10.17487/RFC6151, March 2011,
              <https://www.rfc-editor.org/info/rfc6151>.

   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
              Considerations for the SHA-0 and SHA-1 Message-Digest
              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
              <https://www.rfc-editor.org/info/rfc6194>.

   [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
              for the Cryptographic Message Syntax (CMS) and the Public
              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
              DOI 10.17487/RFC6268, July 2011,
              <https://www.rfc-editor.org/info/rfc6268>.

   [RFC6278]  Herzog, J. and R. Khazan, "Use of Static-Static Elliptic
              Curve Diffie-Hellman Key Agreement in Cryptographic
              Message Syntax", RFC 6278, DOI 10.17487/RFC6278,
              June 2011, <https://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, <https://www.rfc-editor.org/info/rfc7114>.

   [RFC7905]  Langley, A., Chang, W., Mavrogiannopoulos, N.,
              Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
              Cipher Suites for Transport Layer Security (TLS)",
              RFC 7905, DOI 10.17487/RFC7905, June 2016,
              <https://www.rfc-editor.org/info/rfc7905>.

   [SP800-56A]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography", NIST Special
              Publication 800-56A Revision 2,
              DOI 10.6028/NIST.SP.800-56Ar2, May 2013,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Ar2.pdf>.
Top   ToC   RFC8551 - Page 56
   [SP800-57] National Institute of Standards and Technology (NIST),
              "Recommendation for Key Management - Part 1: General",
              NIST Special Publication 800-57 Revision 4,
              DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r4.pdf>.

   [TripleDES]
              Tuchman, W., "Hellman Presents No Shortcut Solutions to
              the DES", IEEE Spectrum v. 16, n. 7, pp. 40-41,
              DOI 10.1109/MSPEC.1979.6368160, July 1979.
Top   ToC   RFC8551 - Page 57
Appendix A.  ASN.1 Module

   Note: The ASN.1 module contained herein is unchanged from RFC 5751
   [SMIMEv2] and RFC 3851 [SMIMEv3.1], with the exception of a change to
   the preferBinaryInside ASN.1 comment in RFC 3851 [SMIMEv3.1].  If a
   module is needed that is compatible with current ASN.1 standards, one
   can be found in [RFC6268].  This module uses the 1988 version
   of ASN.1.

   SecureMimeMessageV3dot1

     { iso(1) member-body(2) us(840) rsadsi(113549)
            pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   IMPORTS

   -- Cryptographic Message Syntax [CMS]
      SubjectKeyIdentifier, IssuerAndSerialNumber,
      RecipientKeyIdentifier
          FROM  CryptographicMessageSyntax
                { iso(1) member-body(2) us(840) rsadsi(113549)
                  pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };

   -- id-aa is the arc with all new authenticated and unauthenticated
   -- attributes produced by the S/MIME Working Group.

   id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
           rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}

   -- S/MIME Capabilities provides a method of broadcasting the
   -- symmetric capabilities understood.  Algorithms SHOULD be ordered
   -- by preference and grouped by type.

   smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}

   SMIMECapability ::= SEQUENCE {
      capabilityID OBJECT IDENTIFIER,
      parameters ANY DEFINED BY capabilityID OPTIONAL }

   SMIMECapabilities ::= SEQUENCE OF SMIMECapability

   -- Encryption Key Preference provides a method of broadcasting the
   -- preferred encryption certificate.
Top   ToC   RFC8551 - Page 58
   id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

   SMIMEEncryptionKeyPreference ::= CHOICE {
      issuerAndSerialNumber   [0] IssuerAndSerialNumber,
      receipentKeyId          [1] RecipientKeyIdentifier,
      subjectAltKeyIdentifier [2] SubjectKeyIdentifier
   }

   -- "receipentKeyId" is spelled incorrectly but is kept for
   -- historical reasons.

   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
           rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

   id-cap  OBJECT IDENTIFIER ::= { id-smime 11 }

   -- The preferBinaryInside OID indicates an ability to receive
   -- messages with binary encoding inside the CMS wrapper.
   -- The preferBinaryInside attribute's value field is ABSENT.

   id-cap-preferBinaryInside  OBJECT IDENTIFIER ::= { id-cap 1 }

   -- The following is a list of OIDs to be used with S/MIME v3.

   -- Signature Algorithms Not Found in [RFC3370], [RFC5754], [RFC4056],
   -- and [RFC3560]

   --
   -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
   --    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
   --     2}

   --
   -- Other Signed Attributes
   --
   -- signingTime OBJECT IDENTIFIER ::=
   --    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   --     5}
   --    See [CMS] for a description of how to encode the attribute
   --    value.

   SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
   --        (RC2 Key Length (number of bits))

   END
Top   ToC   RFC8551 - Page 59
Appendix B.  Historic Mail Considerations

   Over the course of updating the S/MIME specifications, the set of
   recommended algorithms has been modified each time the documents have
   been updated.  This means that if a user has historic emails and
   their user agent has been updated to only support the current set of
   recommended algorithms, some of those old emails will no longer be
   accessible.  It is strongly suggested that user agents implement some
   of the following algorithms for dealing with historic emails.

   This appendix contains a number of references to documents that have
   been obsoleted or replaced.  This is intentional, as the updated
   documents often do not have the same information in them.

B.1.  DigestAlgorithmIdentifier

   The following algorithms have been called out for some level of
   support by previous S/MIME specifications:

   -  SHA-1 was dropped in [SMIMEv4].  SHA-1 is no longer considered to
      be secure, as it is no longer collision resistant.  The IETF
      statement on SHA-1 can be found in [RFC6194], but it is out of
      date relative to the most recent advances.

   -  MD5 was dropped in [SMIMEv4].  MD5 is no longer considered to be
      secure, as it is no longer collision resistant.  Details can be
      found in [RFC6151].

B.2.  Signature Algorithms

   There are a number of problems with validating signatures on
   sufficiently historic messages.  For this reason, it is strongly
   suggested that user agents treat these signatures differently from
   those on current messages.  These problems include the following:

   -  Certification authorities are not required to keep certificates on
      a CRL beyond one update after a certificate has expired.  This
      means that unless CRLs are cached as part of the message it is not
      always possible to check to see if a certificate has been revoked.
      The same problems exist with Online Certificate Status Protocol
      (OCSP) responses, as they may be based on a CRL rather than on the
      certificate database.
Top   ToC   RFC8551 - Page 60
   -  RSA and DSA keys of less than 2048 bits are now considered by many
      experts to be cryptographically insecure (due to advances in
      computing power).  Such keys were previously considered secure, so
      the processing of historic signed messages will often result in
      the use of weak keys.  Implementations that wish to support
      previous versions of S/MIME or process old messages need to
      consider the security risks that result from smaller key sizes
      (e.g., spoofed messages) versus the costs of denial of service.

      [SMIMEv3.1] set the lower limit on suggested key sizes for
      creating and validation at 1024 bits.  Prior to that, the lower
      bound on key sizes was 512 bits.

   -  Hash functions used to validate signatures on historic messages
      may no longer be considered to be secure (see below).  While there
      are not currently any known practical pre-image or second
      pre-image attacks against MD5 or SHA-1, the fact that they are no
      longer considered to be collision resistant implies that the
      security levels of the signatures are generally considered
      suspect.  If a message is known to be historic and it has been in
      the possession of the client for some time, then it might still be
      considered to be secure.

   -  The previous two issues apply to the certificates used to validate
      the binding of the public key to the identity that signed the
      message as well.

   The following algorithms have been called out for some level of
   support by previous S/MIME specifications:

   -  RSA with MD5 was dropped in [SMIMEv4].  MD5 is no longer
      considered to be secure, as it is no longer collision resistant.
      Details can be found in [RFC6151].

   -  RSA and DSA with SHA-1 were dropped in [SMIMEv4].  SHA-1 is no
      longer considered to be secure, as it is no longer collision
      resistant.  The IETF statement on SHA-1 can be found in [RFC6194],
      but it is out of date relative to the most recent advances.

   -  DSA with SHA-256 was dropped in [SMIMEv4].  DSA has been replaced
      by elliptic curve versions.
Top   ToC   RFC8551 - Page 61
   As requirements for "mandatory to implement" have changed over time,
   some issues have been created that can cause interoperability
   problems:

   -  S/MIME v2 clients are only required to verify digital signatures
      using the rsaEncryption algorithm with SHA-1 or MD5 and might not
      implement id-dsa-with-sha1 or id-dsa at all.

   -  S/MIME v3 clients might only implement signing or signature
      verification using id-dsa-with-sha1 and might also use id-dsa as
      an AlgorithmIdentifier in this field.

   -  Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1
      and rsaEncryption and might not implement sha256WithRSAEncryption.

   NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to
   id-dsa-with-sha1.

   For 512-bit RSA with SHA-1, see [RFC3370] and [FIPS186-2] without
   Change Notice 1; for 512-bit RSA with SHA-256, see [RFC5754] and
   [FIPS186-2] without Change Notice 1; and for 1024-bit through
   2048-bit RSA with SHA-256, see [RFC5754] and [FIPS186-2] with Change
   Notice 1.  The first reference provides the signature algorithm's
   OID, and the second provides the signature algorithm's definition.

   For 512-bit DSA with SHA-1, see [RFC3370] and [FIPS186-2] without
   Change Notice 1; for 512-bit DSA with SHA-256, see [RFC5754] and
   [FIPS186-2] without Change Notice 1; for 1024-bit DSA with SHA-1, see
   [RFC3370] and [FIPS186-2] with Change Notice 1; and for 1024-bit and
   above DSA with SHA-256, see [RFC5754] and [FIPS186-4].  The first
   reference provides the signature algorithm's OID, and the second
   provides the signature algorithm's definition.

B.3.  ContentEncryptionAlgorithmIdentifier

   The following algorithms have been called out for some level of
   support by previous S/MIME specifications:

   -  RC2/40 [RFC2268] was dropped in [SMIMEv3.2].  The algorithm is
      known to be insecure and, if supported, should only be used to
      decrypt existing email.

   -  DES EDE3 CBC [TripleDES], also known as "tripleDES", was dropped
      in [SMIMEv4].  This algorithm is removed from the list of
      supported algorithms because (1) it has a 64-bit block size and
      (2) it offers less than 128 bits of security.  This algorithm
      should be supported only to decrypt existing email; it should not
      be used to encrypt new emails.
Top   ToC   RFC8551 - Page 62
B.4.  KeyEncryptionAlgorithmIdentifier

   The following algorithms have been called out for some level of
   support by previous S/MIME specifications:

   -  DH ephemeral-static mode, as specified in [RFC3370] and
      [SP800-57], was dropped in [SMIMEv4].

   -  RSA key sizes have been increased over time.  Decrypting old mail
      with smaller key sizes is reasonable; however, new mail should use
      the updated key sizes.

   For 1024-bit DH, see [RFC3370].  For 1024-bit and larger DH, see
   [SP800-56A]; regardless, use the KDF, which is from X9.42, specified
   in [RFC3370].

Appendix C.  Moving S/MIME v2 Message Specification to Historic Status

   The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2]
   specifications are backward compatible with the S/MIME v2 Message
   Specification [SMIMEv2], with the exception of the algorithms
   (dropped RC2/40 requirement and added DSA and RSASSA-PSS
   requirements).  Therefore, RFC 2311 [SMIMEv2] was moved to Historic
   status.

Acknowledgements

   Many thanks go out to the other authors of the S/MIME version 2
   Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
   Lundblade, and Lisa Repka.  Without v2, there wouldn't be a v3, v3.1,
   v3.2, or v4.0.

   Some of the examples in this document were copied from [RFC4134].
   Thanks go to 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
   very hard and contributed to this document.  Any list of people is
   doomed to omission, and for that I apologize.  In alphabetical order,
   the following people stand out in my mind because they made direct
   contributions to this document:

   Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
   Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
   and John Pawling.

   The version 4 update to the S/MIME documents was done under the
   auspices of the LAMPS Working Group.
Top   ToC   RFC8551 - Page 63
Authors' Addresses

   Jim Schaad
   August Cellars

   Email: ietf@augustcellars.com


   Blake Ramsdell
   Brute Squad Labs, Inc.

   Email: blaker@gmail.com


   Sean Turner
   sn3rd

   Email: sean@sn3rd.com