4.3. Certificate Name Use for X.400 Content
End-entity certificates used in the context of this document MAY
contain an X.400 address as described in [X.400]. The address must
be in the form of an "ORAddress". The X.400 address SHOULD be in the
subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
Sending agents SHOULD make the originator address in the X.400
content (e.g., the "originator" field in P22) match an X.400 address
in the signer’s certificate.
Receiving agents MUST recognize X.400 addresses in the subjectAltName
field.
Receiving agents SHOULD check that the originator address in the
X.400 content matches an X.400 address in the signer’s certificate,
if X.400 addresses are present in the certificate and an originator
address is available in the content. A receiving agent SHOULD
provide some explicit alternate processing of the message if this
comparison fails, which may be to display a message that shows the
recipient the addresses in the certificate or other certificate
details.
The subject alternative name extension is used in S/MIME as the
preferred means to convey the X.400 address(es) that correspond to
the entity for this certificate. Any X.400 addresses present MUST be
encoded using the x400Address CHOICE of the GeneralName type. Since
the SubjectAltName type is a SEQUENCE OF GeneralName, multiple X.400
addresses MAY be present.
5. Security Considerations
This specification introduces no new security concerns to the CMS or
S/MIME models. Security issues are identified in section 5 of [MSG],
section 6 of [ESS] and the Security Considerations section of [CMS].
6. References
6.1. Normative References
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMSAES] Schaad, J., "Use of the AES Encryption Algorithm in
CMS", RFC 3565, July 2003.
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[ESS] Hoffman, P., Editor "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TRANSPORT] Hoffman, P. and C. Bonatti, "Transporting
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Objects in X.400", RFC 3855, July 2004.
[X.400] ITU-T X.400 Series of Recommendations, Information
technology - Message Handling Systems (MHS). X.400:
System and Service Overview; X.402: Overall
Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal
Messaging System; 1996.
6.2. Informative References
[BODYMAP] Alvestrand, H., Ed., "Mapping between X.400 and RFC-
822/MIME Message Bodies", RFC 2157, January 1998.
[MIXER] Kille, S., Ed., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC
2156, January 1998.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April, 2001.
7. Editors’ Addresses
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
EMail: phoffman@imc.org
Chris Bonatti
IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA
EMail: bonattic@ieca.com
Anders Eggen
Forsvarets Forskningsinstitutt
Postboks 25
2027 Kjeller, Norway
EMail: anders.eggen@ffi.no
8. 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.