RFC 8550
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
5. IANA Considerations
This document has no IANA actions.6. Security Considerations
All of the security issues faced by any cryptographic application must be faced by an S/MIME agent. Among these issues are protecting the user's private key, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant concerns are listed here. When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or some other program, there is no single way to handle such failures. Just because the methods to handle the failures have not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it. Some of the many places where signature and certificate checking might fail include the following: - no Internet mail addresses in a certificate match the sender of a message, if the certificate contains at least one mail address - no certificate chain leads to a trusted CA - no ability to check the CRL for a certificate is implemented - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly and decide what to do if the check fails.
It is possible for there to be multiple unexpired CRLs for a CA. If
an agent is consulting CRLs for certificate validation, it SHOULD
make sure that the most recently issued CRL for that CA is consulted,
since an S/MIME message sender could deliberately include an older
unexpired CRL in an S/MIME message. This older CRL might not include
recently revoked certificates; this scenario might lead an agent to
accept a certificate that has been revoked in a subsequent CRL.
When determining the time for a certificate validity check, agents
have to be careful to use a reliable time. In most cases, the time
used SHOULD be the current time. Some exceptions to this would be as
follows:
- The time the message was received is stored in a secure manner and
is used at a later time to validate the message.
- The time in a SigningTime attribute is found in a countersignature
attribute [RFC5652] that has been successfully validated.
The signingTime attribute could be deliberately set to a time where
the receiving agent would (1) use a CRL that does not contain a
revocation for the signing certificate or (2) use a certificate that
has expired or is not yet valid. This could be done by either
(1) the sender of the message or (2) an attacker that has compromised
the key of the sender.
In addition to the security considerations identified in [RFC5280],
caution should be taken when processing certificates that have not
first been validated to a trust anchor. Certificates could be
manufactured by untrusted sources for the purpose of mounting denial-
of-service attacks or other attacks. For example, keys selected to
require excessive cryptographic processing, or extensive lists of CRL
Distribution Point (CDP) and/or Authority Information Access (AIA)
addresses in the certificate, could be used to mount denial-of-
service attacks. Similarly, attacker-specified CDP and/or AIA
addresses could be included in fake certificates to allow the
originator to detect receipt of the message even if signature
verification fails.
RSA keys of less than 2048 bits are now considered by many experts to
be cryptographically insecure (due to advances in computing power)
and SHOULD no longer be used to sign certificates or CRLs. Such keys
were previously considered secure, so processing previously received
signed and encrypted mail may require processing certificates or CRLs
signed with 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 accepting certificates and CRLs with
smaller key sizes (e.g., spoofed certificates) versus the costs of
denial of service. If an implementation supports verification of certificates or CRLs generated with RSA and DSA keys of less than 2048 bits, it MUST warn the user. Implementers should consider providing a stronger warning for weak signatures on certificates and CRLs associated with newly received messages than the one provided for certificates and CRLs associated with previously stored messages. Server implementations (e.g., secure mail list servers) where user warnings are not appropriate SHOULD reject messages with weak cryptography. If an implementation is concerned about compliance with National Institute of Standards and Technology (NIST) key size recommendations, then see [SP800-57].7. References
7.1. Reference Conventions
[ESS] refers to [RFC2634] and [RFC5035]. [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and [RFC2315]. [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633], [RFC2634], and [RFC5035]. [SMIMEv3.1] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and [RFC5035]. [SMIMEv3.2] refers to [RFC2634], [RFC5035], [RFC5652], [RFC5750], and [RFC5751]. [SMIMEv4] refers to [RFC2634], [RFC5035], [RFC5652], [RFC8551], and this document.7.2. Normative References
[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>.
[FIPS186-3] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-3, June 2009, <https://csrc.nist.gov/csrc/media/publications/fips/186/3/ archive/2009-06-25/documents/fips_186-3.pdf>. [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>. [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>. [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, <https://www.rfc-editor.org/info/rfc3279>. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <https://www.rfc-editor.org/info/rfc3447>. [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <https://www.rfc-editor.org/info/rfc4055>. [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>. [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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [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>. [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, <https://www.rfc-editor.org/info/rfc5755>. [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, DOI 10.17487/RFC5758, January 2010, <https://www.rfc-editor.org/info/rfc5758>. [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>. [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>. [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized Email Addresses in X.509 Certificates", RFC 8398, DOI 10.17487/RFC8398, May 2018, <https://www.rfc-editor.org/info/rfc8398>. [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[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>. 7.3 Informative References [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax Standard", November 1993. [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>.
[RFC3114] Nicolls, W., "Implementing Company Classification Policy with the S/MIME Security Label", RFC 3114, DOI 10.17487/RFC3114, May 2002, <https://www.rfc-editor.org/info/rfc3114>. [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>. [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>. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>. [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>. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>. [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>. [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>. [X.500] "Information technology - Open Systems Interconnection - The Directory - Part 1: Overview of concepts, models and services", ITU-T Recommendation X.500, ISO/IEC 9594-1:2017.
Appendix A. Historic Considerations
A.1. Signature Algorithms and Key Sizes
There are a number of problems with validating certificates on sufficiently historic messages. For this reason, it is strongly suggested that user agents treat these certificates differently from those on current messages. These problems include the following: - CAs 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. - 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 certificates 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.2] set the lower limit on suggested key sizes for creating and validation at 1024 bits. [SMIMEv3.1] set the lower limit at 768 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 level of any signature that is created with these hash algorithms should also be considered as suspect. 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 support was dropped in [SMIMEv4]. DSA was
dropped as part of a general movement from finite fields to
elliptic curves. Issues related to dealing with non-deterministic
generation of the parameter 'k' have come up (see [RFC6979]).
For 512-bit RSA with SHA-1, see [RFC3279] and [FIPS186-2] without
Change Notice 1; for 512-bit RSA with SHA-256, see [RFC4055] and
[FIPS186-2] without 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 [RFC3279] and [FIPS186-2] without
Change Notice 1; for 512-bit DSA with SHA-256, see [RFC5758] and
[FIPS186-2] without Change Notice 1; for 1024-bit DSA with SHA-1, see
[RFC3279] and [FIPS186-2] with Change Notice 1; and for 1024-bit
through 3072-bit DSA with SHA-256, see [RFC5758] and [FIPS186-3].
The first reference provides the signature algorithm's OID, and the
second provides the signature algorithm's definition.
Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0
(this document) specifications are backward compatible with the
S/MIME v2 Certificate Handling Specification [SMIMEv2], with the
exception of the algorithms (dropped RC2/40 requirement, and added
DSA and RSASSA-PSS requirements). Therefore, RFC 2312 [SMIMEv2] was
moved to Historic status.
Acknowledgements
Many thanks go out to the other authors of the S/MIME v2 Certificate Handling RFC: Steve Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't be a v3, v3.1, v3.2, or v4.0. 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. Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, and Denis Pinkas. The version 4 update to the S/MIME documents was done under the auspices of the LAMPS Working Group.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