draft-ietf-smime-x400wrap-02.txt   draft-ietf-smime-x400wrap-03.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400wrap-02.txt Chris Bonatti, IECA draft-ietf-smime-x400wrap-03.txt Chris Bonatti, IECA
May 2, 2001 Anders Eggen, FFI July 19, 2001 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 103 skipping to change at line 103
8-bit data: Text data with lines less than 998 characters, and where 8-bit data: Text data with lines less than 998 characters, and where
none of the characters are NULL characters. <CR> and <LF> occur only as none of the characters are NULL characters. <CR> and <LF> occur only as
part of a <CR><LF> end of line delimiter. part of a <CR><LF> end of line delimiter.
Binary data: Arbitrary data. Binary data: Arbitrary data.
Transfer Encoding: A reversible transformation made on data so 8-bit or Transfer Encoding: A reversible transformation made on data so 8-bit or
binary data may be sent via a channel that only transmits 7-bit data. binary data may be sent via a channel that only transmits 7-bit data.
Receiving agent: software that interprets and processes S/MIME CMS Receiving agent: Software that interprets and processes S/MIME CMS
objects objects.
Sending agent: software that creates S/MIME CMS objects. Sending agent: Software that creates S/MIME CMS objects.
S/MIME agent: user software that is a receiving agent, a sending agent, S/MIME agent: User software that is a receiving agent, a sending agent,
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.
skipping to change at line 139 skipping to change at line 139
Sending and receiving agents MUST support SHA-1 [SHA1]. Sending and receiving agents MUST support SHA-1 [SHA1].
2.2 SignatureAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in [DSS]. The Sending and receiving agents MUST support id-dsa defined in [DSS]. The
algorithm parameters MUST be absent (not encoded as NULL). algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents MAY support rsaEncryption, defined in [PKCS-1]. Receiving agents MAY support rsaEncryption, defined in [PKCS-1].
Sending agents MAY support rsaEncryption. Outgoing messages are signed Sending agents MAY support rsaEncryption. Outgoing messages are signed
with a user's private key. The size of the private key is determined with a user's private key.
during key generation.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support Diffie-Hellman defined in Sending and receiving agents MUST support rsaEncryption. Incoming
[DH]. encrypted messages contain symmetric keys which are to be decrypted with
a user's private key.
Receiving agents MAY support rsaEncryption. Incoming encrypted messages
contain symmetric keys which are to be decrypted with a user's private
key. The size of the private key is determined during key generation.
Sending agents MAY support rsaEncryption. Sending and receiving agents MAY support Diffie-Hellman defined in [DH].
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
Sending agents MUST use the signedData content type to apply a digital Sending agents MUST use the signedData content type to apply a digital
signature to a message or, in a degenerate case where there is no signature to a message or, in a degenerate case where there is no
signature information, to convey certificates. signature information, to convey certificates.
2.4.2 EnvelopedData Content Type 2.4.2 EnvelopedData Content Type
This content type is used to apply privacy protection to a message. A Senders MUST use the envelopedData content type to apply privacy
sender needs to have access to a public key for each intended message protection to a message. A sender needs to have access to a public key
recipient to use this service. This content type does not provide for each intended message recipient to use this service. This content
authentication. type does not provide authentication.
2.5 Attribute SignerInfo Type 2.5 Attribute SignerInfo Type
The SignerInfo type allows the inclusion of unsigned and signed The SignerInfo type allows the inclusion of unsigned and signed
attributes to be included along with a signature. attributes to be included along with a signature.
Receiving agents MUST be able to handle zero or one instance of each of Receiving agents MUST be able to handle zero or one instance of each of
the signed attributes listed here. Sending agents SHOULD generate one the signed attributes listed here. Sending agents SHOULD generate one
instance of each of the following signed attributes in each CMS-X400 instance of each of the following signed attributes in each CMS-X400
message: message:
skipping to change at line 194 skipping to change at line 190
- sMIMEEncryptionKeyPreference - sMIMEEncryptionKeyPreference
Requirements for processing of these attributes MUST be in accordance Requirements for processing of these attributes MUST be in accordance
with the S/MIME Message Specification [MSG]. Handling of the signingTime with the S/MIME Message Specification [MSG]. Handling of the signingTime
attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the
sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG].
Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with
clause 2.5.3 of [MSG]. clause 2.5.3 of [MSG].
Further, receiving agents SHOULD be able to handle zero or one instance Further, receiving agents SHOULD be able to handle zero or one instance
in the signed attributes of the signingCertificate attribute. in the signed attributes of the signingCertificate attribute [ESS].
Sending agents SHOULD generate one instance of the signingCertificate Sending agents SHOULD generate one instance of the signingCertificate
signed attribute in each CMS-X400 message. signed attribute in each CMS-X400 message.
Additional attributes and values for these attributes may be defined in Additional attributes and values for these attributes may be defined in
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.
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 then a used to secure X.400 contents. The S/MIME messages are a combination of
combination of X.400 contents and CMS objects (i.e., a ContentInfo X.400 contents and CMS objects (i.e., a ContentInfo structure containing
structure containing one of the CMS-defined content types). The X.400 one of the CMS-defined content types). The X.400 content and other data,
content and other data, such as certificates and algorithm identifiers, such as certificates and algorithm identifiers, are given to CMS
are given to CMS processing facilities which produces a CMS object. This processing facilities which produces a CMS object. This document also
document also describes how nested, secured S/MIME messages should be describes how nested, secured S/MIME messages should be formatted when
formatted when encapsulating an X.400 content, and provides an example encapsulating an X.400 content, and provides an example of how a
of how a triple-wrapped S/MIME message over X.400 content should be triple-wrapped S/MIME message over X.400 content should be created if
created if backwards compatibility with S/MIME version 2 is of no backwards compatibility with S/MIME version 2 is of no concern.
concern.
S/MIME provides one format for enveloped-only data, several formats for S/MIME provides one format for enveloped-only data, several formats for
signed-only data, and several formats for signed and enveloped data. signed-only data, and several formats for signed and enveloped data. The
Several formats are required to accommodate several environments, in different formats are required to accommodate several environments, in
particular for signed messages. Only one of these signed formats is particular for signed messages. Only one of these signed formats is
applicable to X.400. applicable to X.400.
Note that canonicalization is not required for X.400 content, and a Note that canonicalization is not required for X.400 content because it
"detached signature" form is not possible. These dramatically simplify is a binary rather than text encoding, and only the "embedded" content
the description of S/MIME productions. version is used. These dramatically simplify the description of S/MIME
productions.
The reader of this section is expected to understand X.400 as described The reader of this section is expected to understand X.400 as described
in [X.400] and S/MIME as described in [CMS] and [ESS]. in [X.400] and S/MIME as described in [CMS] and [ESS].
3.1 The X.400 Message Structure 3.1 The X.400 Message Structure
This section reviews the X.400 message format. An X.400 message has two This section reviews the X.400 message format. An X.400 message has two
parts, the envelope and the content, as described in X.402 [X.400]: parts, the envelope and the content, as described in X.402 [X.400]:
Envelope -- An information object whose composition varies from one Envelope -- An information object whose composition varies from one
transmittal step to another and that variously identifies the message's transmittal step to another and that variously identifies the message's
originator and potential recipients, documents its previous conveyance originator and potential recipients, documents its previous conveyance
and directs its subsequent conveyance by the Message Transfer System and directs its subsequent conveyance by the Message Transfer System
(MTS), and characterizes its content. (MTS), and characterizes its content.
Content -- The content is the piece of information that the originating Content -- The content is the piece of information that the originating
User Agent wants to be delivered to one or more recipients. The MTS User Agent wants to be delivered to one or more recipients. The MTS
neither examines nor modifies the content, except for conversion, during neither examines nor modifies the content, except for conversion, during
its conveyance of the message. its conveyance of the message. MTS conversion is not applicable to the
scenario of this draft because such conversion is incompatible with CMS
protection mechanisms.
One piece of information borne by the envelope identifies the type of One piece of information borne by the envelope identifies the type of
the content. The content type is an identifier (an ASN.1 OID or Integer) the content. The content type is an identifier (an ASN.1 OID or Integer)
that denotes the syntax and semantics of the content overall. This that denotes the syntax and semantics of the content overall. This
identifier enables the MTS to determine the message's deliverability to identifier enables the MTS to determine the message's deliverability to
particular users, and enables User Agents and Message Stores to particular users, and enables User Agents and Message Stores to
interpret and process the content. interpret and process the content.
Another piece of information borne by the envelope identifies the types Another piece of information borne by the envelope identifies the types
of encoded information represented in the content. An encoded of encoded information represented in the content. An encoded
skipping to change at line 274 skipping to change at line 272
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 then be placed in the SignedData The protected X.400 content MUST be placed in the SignedData
encapContentInfo eContent field. Note that this X.400 content SHOULD encapContentInfo eContent field. The eContent field MUST either (a)
maintain the encoding defined by the content type, but SHOULD NOT be contain the contentType OID and MUST NOT be MIME-wrapped or (b) contain
MIME wrapped. The object identifier for content type of the protected the id-data OID and a MIME-wrapped content. The object identifier for
X.400 content MUST be placed in the SignedData encapContentInfo content type of the protected X.400 content MUST be placed in the
eContentType field. The resulting signedData object MAY optionally be SignedData encapContentInfo eContentType field.
wrapped in a MIME encoding.
The signedData object is encapsulated by a ContentInfo SEQUENCE with The signedData object is encapsulated by a ContentInfo SEQUENCE with a
a contentType of id-signedData. contentType of id-signedData. The resulting CMS object MAY optionally be
wrapped in a MIME encoding.
Note that if SMTP is used to transport the resulting signed-only message Note that if SMTP [SMTP] used to transport the resulting signed-only
then the optional MIME encoding SHOULD be used. If other 8-bit message then the optional MIME encoding SHOULD be used. If binary
transports (e.g., 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.
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 to dynamically
support 7-bit transport. In this case the application/pkcs7-mime type as support 7-bit transport. In this case the application/pkcs7-mime type as
defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used
with the following parameters: with the following parameters:
Content-Type: application/pkcs7-mime; smime-type=signed-data Content-Type: application/pkcs7-mime; smime-type=signed-data
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
processed into a CMS object of type SignedData. processed into a CMS object of type SignedData. The SignedData structure
is encapsulated by a ContentInfo SEQUENCE with a contentType of
id-signedData.
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME Step 3. The CMS object is inserted into an application/pkcs7-mime MIME
entity. entity.
The smime-type parameter for messages using application/pkcs7-mime with The smime-type parameter for messages using application/pkcs7-mime with
SignedData is "signed-x400". SignedData is "signed-x400" as defined in [TRANSPORT].
3.3 Creating an Enveloped-only Message with X.400 Content 3.3 Creating an Enveloped-only Message with X.400 Content
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 may be altered. still be valid, but the meaning is altered.
The EnvelopedData format as described in [CMS] may be used for privacy of The EnvelopedData format as described in [CMS] is used for
the X.400 contents. confidentiality of the X.400 contents.
The protected X.400 content MUST be placed in the EnvelopedData The protected X.400 content 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. The resulting envelopedData encryptedContentInfo contentType field.
object MAY optionally be wrapped in a MIME encoding.
The envelopedData object is encapsulated by a ContentInfo SEQUENCE The envelopedData object is encapsulated by a ContentInfo SEQUENCE with
with a contentType of id-envelopedData. a contentType of id-envelopedData. The resulting CMS object MAY
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 8-bit 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 to
dynamically support 7-bit transport. In this case the dynamically support 7-bit transport. In this case, the
application/pkcs7-mime type as defined in S/MIME Version 3 Message 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-data 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.
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
processed into a CMS object of type EnvelopedData. In addition to processed into a CMS object of type EnvelopedData. In addition to
encrypting a copy of the content-encryption key for each recipient, a encrypting a copy of the content-encryption key for each recipient, a
copy of the content encryption key SHOULD be encrypted for the copy of the content encryption key SHOULD be encrypted for the
originator and included in the envelopedData (see CMS Section 6). originator and included in the EnvelopedData (see CMS Section 6). The
EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-envelopedData.
Step 3. Optionally the CMS object may be inserted into an Step 3. The CMS object is inserted into an application/pkcs7-mime MIME
application/pkcs7-mime MIME entity to allow for 7-bit transport. entity to allow for 7-bit transport.
If the application/pkcs7-mime MIME entity is used, the smime-type If the application/pkcs7-mime MIME entity is used, the smime-type
parameter for enveloped-only messages is "enveloped-x400". parameter for enveloped-only messages is "enveloped-x400" as defined in
[TRANSPORT].
3.4 Nested CMS Structures 3.4 Nested CMS Structures
To achieve signing and enveloping, any of the signed-only and To achieve signing and enveloping, any of the signed-only and
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. If S/MIME version 2 compatibility is of no concern, avoided. Because S/MIME version 2 compatibility is of no concern,
implementations should use id-ct-contentInfo to circumvent the MIME implementations SHOULD directly encode the encapsulated object as the
wrappers. 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
examples of how nested, secured S/MIME messages are formatted. ESS examples of how nested, secured S/MIME messages are formatted. ESS
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 if 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 protected ASN.1 encoded X.400 content in the
SignedData encapContentInfo eContent field. Add any attributes to be SignedData encapContentInfo eContent field. Add any attributes
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. The SignedData structure is encapsulated by a ContentInfo X.400 content.
SEQUENCE with a contentType of id-signedData.
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-ct-contentInfo. This is called the "encrypted body". The id-signedData. This is called the "encrypted body".
EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-envelopedData.
Step 5. Using the same logic as in step 2 and 3 above, sign the result Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 5 (the encrypted body) as a single block. The SignedData of step 4 (the encrypted body) as a single block. The SignedData
structure is encapsulated by a ContentInfo SEQUENCE with a contentType encapContentInfo eContentType MUST be set to id-envelopedData. The outer
of id-signedData. SignedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.
Step 6. The resulting message is called the "outer signature", and is Step 6. The resulting message is called the "outer signature", and is
also the triple wrapped message. also the triple wrapped message.
MIME wrapping to support 7 bit transport, is optional and MUST only be MIME wrapping to support 7-bit transport, is optional and MUST only be
used around the outermost CMS structure. In this case, the used around the outermost CMS structure. In this case, the
application/pkcs7-mime content type MUST be used. application/pkcs7-mime content type MUST be used. The smime-type
in the case of adding a MIME wrapper MUST be consistent with
that appropriate to the innermost protection layer.
3.6 Certificate Enrollment In some instances, an smime-type will be created that only reflects one
security service (such as certs-only, which is only for signed).
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
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
type is reflected outwards.
4. Use of Certificates
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 of the IETF has, at the time of this certificate. The PKIX Working Group has, at the time of this writing,
writing, produced two separate standards for certificate enrollment: produced two separate standards for certificate enrollment: CMP (RFC
CMP (RFC 2510) and CMC(RFC 2792). 2510) and CMC (RFC 2792).
4. 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 [CERT3].
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
skipping to change at line 488 skipping to change at line 501
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC 2119, March 1997. Requirement Levels", BCP14, RFC 2119, March 1997.
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC
2437, October 1998. 2437, October 1998.
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce, 31 Institute of Standards and Technology, U.S. Department of Commerce, 31
May 1994. May 1994.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April, 2001.
[TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in
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.
B. Differences between version -01 and -02 B. Editor's Address
None; the draft was resubmitted to keep it alive.
C. 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
IECA, Inc. IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA
bonattic@ieca.com bonattic@ieca.com
Anders Eggen Anders Eggen
Forsvarets Forskningsinstitutt Forsvarets Forskningsinstitutt
Postboks 25 Postboks 25
2027 Kjeller, Norway 2027 Kjeller, Norway
anders.eggen@ffi.no anders.eggen@ffi.no
 End of changes. 

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