public key certificates using the recommendations specified in the
S/MIME Version 3 Message Specification. The message formats and
S/MIME conformance requirements for certificate exchange are
specified in this document.
This applicability statement does NOT require the use of a
certification authority. The use of a certification authority is
therefore OPTIONAL.
6.2 Long Term Approach
In the long term, additional Internet-EDI standards may be developed
to simplify the process of establishing a trading partnership,
including the third party authentication of trading partners, as well
as attributes of the trading relationship.
7.0 Security Considerations
This entire document is concerned with secure transport of business
to business data, and considers both privacy and authentication
issues.
Extracted from S/MIME Version 2 Message Specification:
40-bit encryption is considered weak by most cryptographers. Using
weak cryptography offers little actual security over sending plain
text. However, other features of S/MIME, such as the specification
of tripleDES or AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is
no cryptography. When feasible, sending and receiving agents should
inform senders and recipients the relative cryptographic strength of
messages.
Extracted from S/MIME Version 2 Certificate Handling:
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 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.
8.0 Acknowledgments
Many thanks go out to the previous authors of the MIME-based Secure
EDI IETF Draft: Mats Jansson.
The authors would like to extend special thanks to Carl Hage, Jun
Ding, Dale Moberg, and Karen Rosenthal for providing the team with
valuable, and very thorough feedback. Without participants like
those cited above, these efforts become hard to complete in a way
useful to the users and implementers of the technology.
In addition, the authors would like to thank Harald Alvestrand, Jim
Galvin, and Roger Fajman for their guidance and input.
9.0 References
[1] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC2045, November 1996.
Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC2049, November 1996.
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC1767,
March 1995.
[3] Resnick, P., "Internet Message Format", RFC2822, April 2001.
[4] Elkins, M., "MIME Security With Pretty Good Privacy (PGP)", RFC
2015, October 1996.
Callas, J., Donnerhacke, L., Finney, H. and R.Thayer "OpenPGP
Message Format", RFC2440, November 1998.
Elkins, M., Del Torto, D., Levien, R. and T. Roessler "MIME
Security with OpenPGP", RFC3156, August 2001.
[5] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC2298, March 1998.
[6] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC1847, October 1995.
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC2821, April
1982.
[8] Ramsdell, B., "S/MIME Version 3 Message Specification;
Cryptographic Message Syntax", RFC2633, June 1999.
Housley, R., "Cryptographic Message Syntax", RFC2630, June
1999.
[9] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC1892,
January 1996.
Appendix IANA Registration Form
A.1 IANA registration of the signed-receipt-protocol content
disposition parameter
Parameter-name: signed-receipt-protocol
Syntax: See section 5.2 of this document
Specification: See section 5.2 of this document
A.2 IANA registration of the signed-receipt-micalg content
disposition parameter
Parameter-name: signed-receipt-micalg
Syntax: See section 5.2 of this document
Specification: See section 5.2 of this document
A.3 IANA registration of the Received-content-MIC MDN extension
field name
Extension field name: Received-content-MIC
Syntax: See section 5.3.1 of this document
Specification: See section 5.3.1 of this document
Authors' Addresses
Terry Harding
Cyclone Commerce
8388 E. Hartford Drive
Scottsdale, Arizona 85255, USA
EMail: tharding@cyclonecommerce.com
Chuck Shih
Gartner Group
251 River Oaks Parkway
San Jose, CA 95134-1913 USA
EMail: chuck.shih@gartner.com
Rik Drummond
Drummond Group
P.O. Box 101567
Ft. Worth, TX 76105 USA
EMail: rik@drummondgroup.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. v This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.