draft-ietf-smime-x400wrap-04.txt   draft-ietf-smime-x400wrap-05.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400wrap-04.txt Chris Bonatti, IECA draft-ietf-smime-x400wrap-05.txt Chris Bonatti, IECA
August 27, 2001 Anders Eggen, FFI November 1, 2002 Anders Eggen, FFI
Expires in six months Expires in six months
Securing X.400 Content with S/MIME Securing X.400 Content with S/MIME
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
skipping to change at line 69 skipping to change at line 69
separate requirements and recommendations for how sending agents create separate requirements and recommendations for how sending agents create
outgoing messages. In general, the best strategy is to "be liberal in outgoing messages. In general, the best strategy is to "be liberal in
what you receive and conservative in what you send". Most of the what you receive and conservative in what you send". Most of the
requirements are placed on the handling of incoming messages while the requirements are placed on the handling of incoming messages while the
recommendations are mostly on the creation of outgoing messages. recommendations are mostly on the creation of outgoing messages.
This document does not address transport of CMS-X.400 content. It is This document does not address transport of CMS-X.400 content. It is
assumed that CMS-X.400 content would be transported by Internet mail assumed that CMS-X.400 content would be transported by Internet mail
systems, X.400, or other suitable transport. systems, X.400, or other suitable transport.
This document describes applying security services to the content of
entire X.400 messages, which may or may not be IPMS messages. These
objects can be carried by several means, including SMTP-based mail and
X.400 mail. Note that cooperating S/MIME agents must support common
forms of message content in order to achieve interoperability.
If the CMS objects are sent as parts of an RFC 822 message, a standard
MIXER gateway [MIXER] will most likely choose to encapsulate the
message. This is not likely to be a format that is usable by an X.400
recipient. MIXER is specifically focused on translation between X.420
Interpersonal Messages and non-secure RFC822/MIME messages. The
discussion of security- related body parts in sections 7.3 and 7.4 of
[BODYMAP] is relevant to CMS messages.
Definition of gateway services to support relay of CMS object between
X.400 and SMTP environments is beyond the scope of this document.
1.2 Terminology 1.2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119 "MAY" in this document are to be interpreted as described in RFC 2119
[MUSTSHOULD]. [MUSTSHOULD].
1.3 Definitions 1.3 Definitions
For the purposes of this document, the following definitions apply. For the purposes of this document, the following definitions apply.
skipping to change at line 119 skipping to change at line 136
or both. or both.
1.4 Compatibility with Prior Practice of S/MIME 1.4 Compatibility with Prior Practice of S/MIME
There are believed to be no existing X.400 implementations that support There are believed to be no existing X.400 implementations that support
S/MIME version 2. Further, signed interoperability between X.400 and S/MIME version 2. Further, signed interoperability between X.400 and
MIME systems that support S/MIME version 2 is not believed to be easily MIME systems that support S/MIME version 2 is not believed to be easily
achievable. Therefore backward compatibility with S/MIME version 2 is achievable. Therefore backward compatibility with S/MIME version 2 is
not considered to be a requirement for this document. not considered to be a requirement for this document.
It is a goal of this draft to, if possible, maintain backward
compatibility with existing X.400 implementations that employ S/MIME v3
wrappers.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content and algorithm CMS allows for a wide variety of options in content and algorithm
support. This section puts forth a number of support requirements and support. This section puts forth a number of support requirements and
recommendations in order to achieve a base level of interoperability recommendations in order to achieve a base level of interoperability
among all CMS-X.400 implementations. [CMS] provides additional details among all CMS-X.400 implementations. [CMS] provides additional details
regarding the use of the cryptographic algorithms. regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [SHA1]. Sending and receiving agents MUST support SHA-1 [CMSALG].
2.2 SignatureAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in [DSS]. The Receiving agents MUST support id-dsa defined in [CMSALG]. The
algorithm parameters MUST be absent (not encoded as NULL). algorithm parameters MUST be absent (not encoded as NULL). Receiving
agents MUST support rsaEncryption, defined in [CMSALG].
Receiving agents MAY support rsaEncryption, defined in [PKCS-1].
Sending agents MAY support rsaEncryption. Outgoing messages are signed Sending agents MUST support either id-dsa or rsaEncryption.
with a user's private key.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support rsaEncryption. Incoming Sending and receiving agents MUST support rsaEncryption, defined in
encrypted messages contain symmetric keys which are to be decrypted with [CMSALG].
a user's private key.
Sending and receiving agents MAY support Diffie-Hellman defined in [DH]. Sending and receiving agents SHOULD support Diffie-Hellman defined in
[CMSALG].
2.4 General Syntax 2.4 General Syntax
The general syntax of CMS objects consist of an instance of the The general syntax of CMS objects consist of an instance of the
ContentInfo structure containing one of several defined CMS content ContentInfo structure containing one of several defined CMS content
types. CMS defines multiple content types. Of these, only the SignedData types. CMS defines multiple content types. Of these, only the SignedData
and EnvelopedData content types are used for CMS-X.400. and EnvelopedData content types are used for CMS-X.400.
2.4.1 SignedData Content Type 2.4.1 SignedData Content Type
skipping to change at line 206 skipping to change at line 225
the future. Receiving agents SHOULD handle attributes or values that it the future. Receiving agents SHOULD handle attributes or values that it
does not recognize in a graceful manner. does not recognize in a graceful manner.
Sending agents that include signed attributes that are not listed here Sending agents that include signed attributes that are not listed here
SHOULD display those attributes to the user, so that the user is aware SHOULD display those attributes to the user, so that the user is aware
of all of the data being signed. of all of the data being signed.
2.6 ContentEncryptionAlgorithmIdentifier 2.6 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES]. with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
3. Creating S/MIME Messages 3. Creating S/MIME Messages
This section describes the S/MIME message formats and how they can be This section describes the S/MIME message formats and how they can be
used to secure X.400 contents. The S/MIME messages are a combination of used to secure X.400 contents. The S/MIME messages are a combination of
X.400 contents and CMS objects (i.e., a ContentInfo structure containing X.400 contents and CMS objects (i.e., a ContentInfo structure containing
one of the CMS-defined content types). The X.400 content and other data, one of the CMS-defined content types). The X.400 content and other data,
such as certificates and algorithm identifiers, are given to CMS such as certificates and algorithm identifiers, are given to CMS
processing facilities which produces a CMS object. This document also processing facilities which produces a CMS object. This document also
describes how nested, secured S/MIME messages should be formatted when describes how nested, secured S/MIME messages should be formatted when
skipping to change at line 277 skipping to change at line 296
converting a portion of the content from one EIT to another. converting a portion of the content from one EIT to another.
This document describes how S/MIME CMS is used to secure the content This document describes how S/MIME CMS is used to secure the content
part of X.400 messages. part of X.400 messages.
3.2 Creating a Signed-only Message with X.400 Content 3.2 Creating a Signed-only Message with X.400 Content
The SignedData format as described in the Cryptographic Message Syntax The SignedData format as described in the Cryptographic Message Syntax
[CMS] MUST be used for signing of X.400 contents. [CMS] MUST be used for signing of X.400 contents.
The protected X.400 content MUST be placed in the SignedData The X.400 content to be protected MUST be placed in the SignedData
encapContentInfo eContent field. Note that this X.400 content SHOULD encapContentInfo eContent field. Note that this X.400 content SHOULD
maintain the encoding defined by the content type, but SHOULD NOT be maintain the encoding defined by the content type, but SHOULD NOT be
MIME wrapped. The object identifier for content type of the protected MIME wrapped. The object identifier for the content type of the
X.400 content MUST be placed in the SignedData encapContentInfo protected X.400 content MUST be placed in the SignedData
eContentType field. encapContentInfo eContentType field.
The signedData object is encapsulated by a ContentInfo SEQUENCE with a The signedData object is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData. The resulting CMS object MAY optionally be contentType of id-signedData.
wrapped in a MIME encoding.
Note that if SMTP [SMTP] is used to transport the resulting signed-only Note that if SMTP [SMTP] is used to transport the resulting signed-only
message then the optional MIME encoding SHOULD be used. If binary message then the optional MIME encoding SHOULD be used. If binary
transports such as X.400 are used then the optional MIME encoding SHOULD transports such as X.400 are used then the optional MIME encoding SHOULD
NOT be used. NOT be used.
There are many reasons for this requirement. An outer MIME wrapper There are many reasons for this requirement. An outer MIME wrapper
should not be used in X.400. Further, there are places where X.400 should not be used in X.400. Further, there are places where X.400
systems will interact with SMTP/MIME systems where the outer MIME systems will interact with SMTP/MIME systems where the outer MIME
wrapper might be necessary. Because this wrapping is outside the wrapper might be necessary. Because this wrapping is outside the
security wrappers, whatever gateway system that is bridging the gap security wrappers, whatever gateway system that is bridging the gap
between the two systems will be smart enough to apply or remove the between the two systems will be smart enough to apply or remove the
outer MIME wrapper as appropriate. outer MIME wrapper as appropriate.
3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport
The signedData object MAY optionally be wrapped in MIME to dynamically The signedData object MAY optionally be wrapped in MIME. This allows
support 7-bit transport. In this case the application/pkcs7-mime type as the system to support 7-bit transport when required. This outer MIME
defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used wrapper MAY be dynamically added or removed throughout the delivery path
with the following parameters: since it is out the signature and encryption wrappers. In this case the
application/pkcs7-mime type as defined in S/MIME Version 3 Message
Specification [MSG] SHOULD be used with the following parameters:
Content-Type: application/pkcs7-mime; smime-type=signed-x400 Content-Type: application/pkcs7-mime; smime-type=signed-x400
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit If the application/pkcs7-mime MIME type is used to support 7-bit
transport, the steps to create this format are: transport, the steps to create this format are:
Step 1. The X.400 content to be signed is ASN.1 encoded. Step 1. The X.400 content to be signed is ASN.1 encoded.
Step 2. The ASN.1 encoded X.400 content and other required data is Step 2. The ASN.1 encoded X.400 content and other required data is
skipping to change at line 338 skipping to change at line 358
This section describes the format for enveloping an X.400 content This section describes the format for enveloping an X.400 content
without signing it. It is important to note that sending enveloped but without signing it. It is important to note that sending enveloped but
not signed messages does not provide for data integrity. It is possible not signed messages does not provide for data integrity. It is possible
to replace ciphertext in such a way that the processed message will to replace ciphertext in such a way that the processed message will
still be valid, but the meaning is altered. still be valid, but the meaning is altered.
The EnvelopedData format as described in [CMS] is used for The EnvelopedData format as described in [CMS] is used for
confidentiality of the X.400 contents. confidentiality of the X.400 contents.
The protected X.400 content MUST be placed in the EnvelopedData The X.400 content to be protected MUST be placed in the EnvelopedData
encryptedContentInfo encryptedContent field. Note that this X.400 encryptedContentInfo encryptedContent field. Note that this X.400
content SHOULD maintain the encoding defined by the content type, but content SHOULD maintain the encoding defined by the content type, but
SHOULD NOT be MIME wrapped. The object identifier for content type of SHOULD NOT be MIME wrapped. The object identifier for content type of
the protected X.400 content MUST be placed in the EnvelopedData the protected X.400 content MUST be placed in the EnvelopedData
encryptedContentInfo contentType field. encryptedContentInfo contentType field.
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with The envelopedData object is encapsulated by a ContentInfo SEQUENCE with
a contentType of id-envelopedData. The resulting CMS object MAY a contentType of id-envelopedData.
optionally be wrapped in a MIME encoding.
Note that if SMTP is used to transport the resulting enveloped-only Note that if SMTP is used to transport the resulting enveloped-only
message then the optional MIME encoding SHOULD be used. If other binary message then the optional MIME encoding SHOULD be used. If other binary
transport (e.g., X.400) is used then the optional MIME encoding SHOULD transport (e.g., X.400) is used then the optional MIME encoding SHOULD
NOT be used. NOT be used.
3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport
The envelopedData object MAY optionally be wrapped in MIME to The envelopedData object MAY optionally be wrapped in MIME. This allows
dynamically support 7-bit transport. In this case, the the system to support 7-bit transport when required. This outer MIME
application/pkcs7-mime type as defined in S/MIME Version 3 Message wrapper MAY be dynamically added or removed throughout the delivery path
since it is out the signature and encryption wrappers. In this case,
the application/pkcs7-mime type as defined in S/MIME Version 3 Message
Specification [MSG] SHOULD be used with the following parameters: Specification [MSG] SHOULD be used with the following parameters:
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 Content-Type: application/pkcs7-mime; smime-type=enveloped-x400
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit If the application/pkcs7-mime MIME type is used to support 7-bit
transport, the steps to create this format are: transport, the steps to create this format are:
Step 1. The X.400 content to be enveloped is ASN.1 encoded. Step 1. The X.400 content to be enveloped is ASN.1 encoded.
skipping to change at line 397 skipping to change at line 418
encrypted-only CMS objects may be nested. encrypted-only CMS objects may be nested.
When nesting is used, backwards compatibility with S/MIME version 2 When nesting is used, backwards compatibility with S/MIME version 2
requires that each layer of the nested message are identified with the requires that each layer of the nested message are identified with the
OID id-data, and when id-data is used a MIME wrapper is required. This OID id-data, and when id-data is used a MIME wrapper is required. This
can potentially lead to an enormous amount of overhead and should be can potentially lead to an enormous amount of overhead and should be
avoided. Because S/MIME version 2 compatibility is of no concern, avoided. Because S/MIME version 2 compatibility is of no concern,
implementations SHOULD directly encode the encapsulated object as the implementations SHOULD directly encode the encapsulated object as the
eContent of the current structure. eContent of the current structure.
MIME wrapping to support 7-bit transport, is optional and need only be MIME wrapping to support 7-bit transport is optional and need only be
used around the outermost CMS structure. In this case, the used around the outermost CMS structure. In this case, the
application/pkcs7 content type MUST be used. application/pkcs7 content type MUST be used.
An S/MIME implementation MUST be able to receive and process arbitrarily An S/MIME implementation MUST be able to receive and process arbitrarily
nested CMS structures within reasonable resource limits of the recipient nested CMS structures within reasonable resource limits of the recipient
computer. computer.
3.4.1 Creating a Triple Wrapped Message With an X.400 Content 3.4.1 Creating a Triple Wrapped Message With an X.400 Content
The Enhanced Security Services for S/MIME [ESS] document provides The Enhanced Security Services for S/MIME [ESS] document provides
skipping to change at line 419 skipping to change at line 440
provides an example of how a triple-wrapped S/MIME message is formatted provides an example of how a triple-wrapped S/MIME message is formatted
using application/pkcs7-mime for the signatures. using application/pkcs7-mime for the signatures.
This section explains how an X.400 content may be conveyed within a This section explains how an X.400 content may be conveyed within a
Triple Wrapped Message because S/MIME version 2 compatibility is of no Triple Wrapped Message because S/MIME version 2 compatibility is of no
concern: concern:
Step 1. Start with the X.400 content (called the "original content"). Step 1. Start with the X.400 content (called the "original content").
The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped.
Step 2. Place the protected ASN.1 encoded X.400 content in the Step 2. Place the ASN.1 encoded X.400 content to be protected in the
SignedData encapContentInfo eContent field. Add any attributes SignedData encapContentInfo eContent field. Add any attributes
that are to be signed. that are to be signed.
Step 3. Sign the result of step 2 (the original content). The SignedData Step 3. Sign the result of step 2 (the original content). The SignedData
encapContentInfo eContentType MUST contain the object identifier of the encapContentInfo eContentType MUST contain the object identifier of the
X.400 content. X.400 content.
Step 4. Encrypt the result of step 3 as a single block. The Step 4. Encrypt the result of step 3 as a single block. The
EnvelopedData encryptedContentInfo contentType MUST be set to EnvelopedData encryptedContentInfo contentType MUST be set to
id-signedData. This is called the "encrypted body". id-signedData. This is called the "encrypted body".
skipping to change at line 454 skipping to change at line 475
that appropriate to the innermost protection layer. that appropriate to the innermost protection layer.
In some instances, an smime-type will be created that only reflects one In some instances, an smime-type will be created that only reflects one
security service (such as certs-only, which is only for signed). security service (such as certs-only, which is only for signed).
However, as new layers are wrapped, this smime-type SHOULD be propagated However, as new layers are wrapped, this smime-type SHOULD be propagated
upwards. Thus if a certs-only message were to be encrypted, or wrapped upwards. Thus if a certs-only message were to be encrypted, or wrapped
in a new SignedData structure, the smime-type of certs-only should be in a new SignedData structure, the smime-type of certs-only should be
propagated up to the next MIME wrapper. In other words, the innermost propagated up to the next MIME wrapper. In other words, the innermost
type is reflected outwards. type is reflected outwards.
3.5 Carrying Plaintext X.400 Content in SMTP
While the objectives of this draft focus on protecting X.400 content
with CMS wrappers, it is a reality that users do not generally send
all message using security. It therefore stands to reason that a
means to carry non-secured X.400 content over the chosen transport
system must be seemlessly provided. While transporting X.400 content
in an X.400 system is trivial, carrying X.400 content in SMTP
requires additional definition.
Content-Type: application/x400-content; content-type =
1*DIGIT *( "." 1*DIGIT)
where the content-type parmeter value is either a single integer (for
a built-in content-type) or an OID in dotted notation (for an extended
content-type).
4. Use of Certificates 4. Use of Certificates
4.1 Certificate Enrollment 4.1 Certificate Enrollment
S/MIME v3 does not specify how to get a certificate from a certificate S/MIME v3 does not specify how to get a certificate from a certificate
authority, but instead mandates that every sending agent already has a authority, but instead mandates that every sending agent already has a
certificate. The PKIX Working Group has, at the time of this writing, certificate. The PKIX Working Group has, at the time of this writing,
produced two separate standards for certificate enrollment: CMP (RFC produced two separate standards for certificate enrollment: CMP (RFC
2510) and CMC (RFC 2792). 2510) and CMC (RFC 2792).
4.2 Certificate Processing 4.2 Certificate Processing
A receiving agent MUST provide some certificate retrieval mechanism in A receiving agent MUST provide some certificate retrieval mechanism in
order to gain access to certificates for recipients of digital order to gain access to certificates for recipients of digital
envelopes. This document does not cover how S/MIME agents handle envelopes. This document does not cover how S/MIME agents handle
certificates, only what they do after a certificate has been validated certificates, only what they do after a certificate has been validated
or rejected. S/MIME certification issues are covered in [CERT3]. or rejected. S/MIME certification issues are covered in [CERT31].
At a minimum, for initial S/MIME deployment, a user agent could At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving and that recipient's certificate in a signed return message. Receiving and
sending agents SHOULD also provide a mechanism to allow a user to "store sending agents SHOULD also provide a mechanism to allow a user to "store
and protect" certificates for correspondents in such a way so as to and protect" certificates for correspondents in such a way so as to
guarantee their later retrieval. guarantee their later retrieval.
4.3. Certificate Name Use for X.400 Content
End-entity certificates used in the context of this draft 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 5. Security Considerations
This entire document discusses security. Additional security issues are This entire document discusses security. Additional security issues are
identified in section 5 of [MSG], section 6 of [ESS] and the Security identified in section 5 of [MSG], section 6 of [ESS] and the Security
Considerations section of [CMS]. Considerations section of [CMS].
A. References A. References
[3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of A.1 Normative References
Operation", American National Standards Institute, 1998.
[CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[DES] ANSI X3.106, "American National Standard for Information Systems- [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Data Link Encryption," American National Standards Institute, 1983. Handling", Internet-Draft draft-ietf-smime-rfc2632bis.
[DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft
June 1999. draft-ietf-smime-rfc2630bis.
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet-
Draft draft-ietf-smime-cmsalg
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. Internet-Draft draft-ietf-smime-rfc2633bis.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC 2119, March 1997.
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC
2437, October 1998.
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce, 31
May 1994.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April, 2001.
[TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in [TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in
X.400", work in progress (will progress with this document). X.400", work in progress (will progress with this document).
[X.400] ITU-T X.400 Series of Recommendations, Information technology [X.400] ITU-T X.400 Series of Recommendations, Information technology
- Message Handling Systems (MHS). X.400: System and Service Overview; - Message Handling Systems (MHS). X.400: System and Service Overview;
X.402: Overall Architecture; X.411: Message Transfer System: Abstract X.402: Overall Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal Messaging Service Definition and Procedures; X.420: Interpersonal Messaging
System; 1996. System; 1996.
A.2 Non-normative References
[BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and
RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC 2119, March 1997.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April, 2001.
B. Editor's Address B. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
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
 End of changes. 

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