used for signing but not encrypting S/MIME messages. If the
certificate contains a key usage extension indicating digital
signature, but no extended key usage extension then the certificate
may also be used to sign but not encrypt S/MIME messages.
If the extended key usage extension is present in the certificate
then interpersonal message S/MIME receiving agents MUST check that it
contains either the emailProtection or the anyExtendedKeyUsage OID as
defined in [KEYM]. S/MIME uses other than interpersonal messaging
MAY require the explicit presence of the extended key usage extension
or other OIDs to be present in the extension or both.
5. Security Considerations
All of the security issues faced by any cryptographic application
must be faced by a 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 other program, there is no single way
to handle such failures. Just because the methods to handle the
failures has 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:
- no Internet mail addresses in a certificate matches 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
- 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 to decide what to do if the check
fails.
At the Selected Areas in Cryptography ’95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find
collisions [RC95]. Collisions occur when one can find two different
messages that generate the same message digest. A checksum operation
in MD2 is the only remaining obstacle to the success of the attack.
For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as
the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value.
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
recent revoked certificates, which 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. Unless it is from a
trusted agent, this time MUST NOT be the SigningTime attribute found
in an S/MIME message. For most sending agents, the SigningTime
attribute could be deliberately set to direct the receiving agent to
check a CRL that could have out-of-date revocation status for a
certificate, or cause an improper result when checking the Validity
field of a certificate.
A. References
A.1. Normative References
[ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[CMS] Housely, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[KEYM] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[KEYMALG] 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, April 2002.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
November 2000.
[RFC-2822], Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[SMIME-MSG] Ramsdell, B., Ed., "S/MIME Version 3.1 Message
Specification", RFC 3851, July 2004.
[x.208-88] ITU-T. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
A.2. Informative References
[CERTV2] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
"S/MIME Version 2 Certificate Handling", RFC 2312, March
1998.
[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
Standard", November 1993.
[RC95] Rogier, N. and Chauvaud, P., "The compression function
of MD2 is not collision free," Presented at Selected
Areas in Cryptography ’95, May 1995.
[SECLABEL] Nicolls, W., "Implementing Company Classification Policy
with the S/MIME Security Label", RFC 3114, May 2002.
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
Information technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and
services.
[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
Information technology - Open Systems Interconnection -
The Directory: Models.
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection -
The Directory: Authentication framework.
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
Information technology - Open Systems Interconnection -
The Directory: Selected attribute types.
B. Acknowledgements
Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn’t
be a v3.
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 due to the fact that they
made direct contributions to this document.
Bill Flanigan
Trevor Freeman
Elliott Ginsburg
Paul Hoffman
Russ Housley
David P. Kemp
Michael Myers
John Pawling
Denis Pinkas
Jim Schaad
C. Editor’s Address
Blake Ramsdell
Sendmail, Inc.
704 228th Ave NE #775
Sammamish, WA 98074
EMail: blake@sendmail.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.