draft-ietf-smime-x400transport-08.txt   draft-ietf-smime-x400transport-09.txt 
S/MIME Working Group S/MIME Working Group
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400transport-08.txt Chris Bonatti, IECA draft-ietf-smime-x400transport-09.txt Chris Bonatti, IECA
June 29, 2003 August 8, 2003
Expires December 29, 2003 Expires February 8, 2004
Transporting S/MIME Objects in X.400 Transporting S/MIME Objects in X.400
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at line 363 skipping to change at line 363
conjunction with CMS objects. Services affecting conversion of the conjunction with CMS objects. Services affecting conversion of the
content, expansion of Distribution Lists (DLs), and message redirection content, expansion of Distribution Lists (DLs), and message redirection
can interact badly with services provided by the "EnvelopedData" and can interact badly with services provided by the "EnvelopedData" and
"SignedData" CMS content types. "SignedData" CMS content types.
2.6.1 MTS Conversion Services 2.6.1 MTS Conversion Services
MTS conversion is not applicable to the scenario of this draft because MTS conversion is not applicable to the scenario of this draft because
such conversion is incompatible with CMS protection mechanisms. X.400 such conversion is incompatible with CMS protection mechanisms. X.400
systems that implement conversion services should generally be unable to systems that implement conversion services should generally be unable to
attempt conversion of CMS content types because those type do not attempt conversion of CMS content types because those types do not
conform to X.420 structure rules. Nevertheless, when transporting CMS conform to X.420 structure rules. Nevertheless, when transporting CMS
objects within an X.400 environment, the Conversion Prohibition service objects within an X.400 environment, the Conversion Prohibition service
SHOULD be selected. SHOULD be selected.
2.6.2 Message Redirection Services 2.6.2 Message Redirection Services
X.400 message redirection services can have an indirect impact on the X.400 message redirection services can have an indirect impact on the
application of the CMS "EnvelopedData" content type. Several different application of the CMS "EnvelopedData" content type. Several different
forms of redirection are possible in X.400, including: forms of redirection are possible in X.400, including:
skipping to change at line 389 skipping to change at line 389
may share the same problem. An auto-forwarding implementation that may share the same problem. An auto-forwarding implementation that
removes the EnvelopedData and reapplies it for the forwarded recipient removes the EnvelopedData and reapplies it for the forwarded recipient
is not affected by this problem. The normal case is that the private key is not affected by this problem. The normal case is that the private key
is not available when the human user is not present, thus decryption is is not available when the human user is not present, thus decryption is
not possible. However, if the private key is present, forwarding can be not possible. However, if the private key is present, forwarding can be
used instead. used instead.
When the "EnvelopedData" content type is used to protect message When the "EnvelopedData" content type is used to protect message
contents, an instance of RecipientInfo is needed for each recipient and contents, an instance of RecipientInfo is needed for each recipient and
alternate recipient in order to ensure the desired access to the alternate recipient in order to ensure the desired access to the
message. A RecipeintInfo for the originator is a good practice just in message. A RecipientInfo for the originator is a good practice just in
case the MTS returns the whole message. case the MTS returns the whole message.
In the event that ORAR is used, the originator is aware of the identity In the event that ORAR is used, the originator is aware of the identity
of the alternate recipient and SHOULD include a corresponding of the alternate recipient and SHOULD include a corresponding
RecipientInfo element. For other forms of redirection (including RecipientInfo element. For other forms of redirection (including
non-security-aware auto-forwarding) the alternate recipient must either non-security-aware auto-forwarding) the alternate recipient must either
have access to the intended recipient's keys (not recommended) or must have access to the intended recipient's keys (not recommended) or must
relay the message to the intended recipient by other means. relay the message to the intended recipient by other means.
2.6.3 DL Expansion 2.6.3 DL Expansion
skipping to change at line 470 skipping to change at line 470
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
Chris Bonatti Chris Bonatti
IECA, Inc. IECA, Inc.
15309 Turkey Foot Road 15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA Darnestown, MD 20878-3640 USA
bonattic@ieca.com bonattic@ieca.com
draft-ietf-smime-x400transport-06.txt expires November 1, 2003. draft-ietf-smime-x400transport-09.txt expires February 8, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/