draft-ietf-smime-msg-03.txt   draft-ietf-smime-msg-04.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-03.txt Worldtalk draft-ietf-smime-msg-04.txt Worldtalk
March 24, 1998 May 4, 1998
Expires in six months Expires in six months
S/MIME Version 3 Message Specification S/MIME Version 3 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
(US West Coast).
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications: cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption). digital signatures) and privacy and data security (using encryption).
skipping to change at line 67 skipping to change at line 66
cryptographically enhanced according to CMS [CMS], which is derived cryptographically enhanced according to CMS [CMS], which is derived
from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7- from PKCS #7 [PKCS-7]. This draft also defines the application/pkcs7-
mime MIME type that can be used to transport those body parts. mime MIME type that can be used to transport those body parts.
This draft also discusses how to use the multipart/signed MIME type This draft also discusses how to use the multipart/signed MIME type
defined in [MIME-SECURE] to transport S/MIME signed messages. This defined in [MIME-SECURE] to transport S/MIME signed messages. This
draft also defines the application/pkcs7-signature MIME type, which is draft also defines the application/pkcs7-signature MIME type, which is
also used to transport S/MIME signed messages. also used to transport S/MIME signed messages.
In order to create S/MIME messages, an agent has to follow In order to create S/MIME messages, an agent has to follow
specifications in this draft, as well as some of the specifications specifications in this draft, as well as the specifications listed in
listed in the following documents: the Cryptographic Message Syntax [CMS].
- "PKCS #1: RSA Encryption", [PKCS-1].
- "Cryptographic Message Syntax", [CMS]
Throughout this draft, there are requirements and recommendations made Throughout this draft, there are requirements and recommendations made
for how receiving agents handle incoming messages. There are separate for how receiving agents handle incoming messages. There are separate
requirements and recommendations for how sending agents create 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.
The separation for requirements on receiving agents and sending agents The separation for requirements on receiving agents and sending agents
skipping to change at line 239 skipping to change at line 235
Sending agents SHOULD be able to generate one instance of each of the Sending agents SHOULD be able to generate one instance of each of the
signed attributes described in this section, and SHOULD include the signed attributes described in this section, and SHOULD include the
signing time and SMIMECapabilities attribute in each signed message signing time and SMIMECapabilities attribute in each signed message
sent. sent.
Additional attributes and values for these attributes may be defined Additional attributes and values for these attributes may be defined
in the future. Receiving agents SHOULD handle attributes or values in the future. Receiving agents SHOULD handle attributes or values
that it does not recognize in a graceful manner. that it does not recognize in a graceful manner.
Sending agents that include attributes that are not listed here SHOULD
display those attributes to the user, so that the user is aware of all
of the data being signed.
2.5.1 Signing-Time Attribute 2.5.1 Signing-Time Attribute
The signing-time attribute is used to convey the time that a message The signing-time attribute is used to convey the time that a message
was signed. Until there are trusted timestamping services, the time of was signed. Until there are trusted timestamping services, the time of
signing will most likely be created by a message originator and signing will most likely be created by a message originator and
therefore is only as trustworthy as the originator. therefore is only as trustworthy as the originator.
Sending agents MUST encode signing time through the year 2049 as Sending agents MUST encode signing time through the year 2049 as
UTCTime; signing times in 2050 or later MUST be encoded as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime. When the UTCTime CHOICE is used, agents MUST GeneralizedTime. When the UTCTime CHOICE is used, agents MUST
skipping to change at line 339 skipping to change at line 339
Receiving agents SHOULD store the preference data if the signature on Receiving agents SHOULD store the preference data if the signature on
the message is valid and the signing time is greater than the the message is valid and the signing time is greater than the
currently stored value. (As with the SMIMECapabilities, the clock currently stored value. (As with the SMIMECapabilities, the clock
skew should be checked and the data not used if the skew is to great.) skew should be checked and the data not used if the skew is to great.)
Receiving agents SHOULD respect the senders encryption key preference Receiving agents SHOULD respect the senders encryption key preference
attribute if possible. This however represents only a preference and attribute if possible. This however represents only a preference and
the receiving agent may use any certificate in replying to the sender the receiving agent may use any certificate in replying to the sender
that is valid. that is valid.
2.5.3.1 Selection of Recipient Key Management Certificate
In order to determine the key management certificate to be used when
sending a CMS envelopedData message for a particular recipient, the
following steps SHOULD be followed:
- If an SMIMEEncryptionKeyPreference attribute is found in a
signedData object received from the desired recipient, this identifies
the X.509 certificate that should be used as the X.509 key management
certificate for the recipient.
- If an SMIMEEncryptionKeyPreference attribute is not found in a
signedData object received from the desired recipient, the set of
X.509 certificates should be searched for a X.509 certificate with the
same subject name as the signing X.509 certificate which can be used
for key management.
- Or use some other method of determining the user's key management
key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If multiple
X.509 key management certificates are found, the S/MIME agent can make
an arbitrary choice between them.
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" [3DES] [DES].
Receiving agents SHOULD support encryption and decryption using the Receiving agents SHOULD support encryption and decryption using the
RC2 [RC2] or a compatible algorithm at a key size of 40 bits, RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40". hereinafter called "RC2/40".
2.6.1 Deciding Which Encryption Method To Use 2.6.1 Deciding Which Encryption Method To Use
skipping to change at line 416 skipping to change at line 439
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent has received at least one message from the - and the sending agent has received at least one message from the
recipient, recipient,
- and the last encrypted message received from the recipient had a - and the last encrypted message received from the recipient had a
trusted signature on it, trusted signature on it,
then the outgoing message SHOULD use the same encryption algorithm as then the outgoing message SHOULD use the same encryption algorithm as
was used on the last signed and encrypted message received from the was used on the last signed and encrypted message received from the
recipient. recipient.
2.6.1.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption 2.6.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME
If: If:
- the sending agent has no knowledge of the encryption capabilities - the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent is willing to risk that the recipient may - and the sending agent has no knowledge of the version of S/MIME
not be able to decrypt the message,
then the sending agent SHOULD use tripleDES.
2.6.1.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
If:
- the sending agent has no knowledge of the encryption capabilities
of the recipient, of the recipient,
- and the sending agent is not willing to risk that the recipient then the sending agent SHOULD use tripleDES because it is a stronger
may not be able to decrypt the message, algorithm and is required by S/MIME v3. If the sending agent chooses
then the sending agent SHOULD use RC2/40. not to use tripleDES in this step, it SHOULD use RC2/40.
2.6.2 Choosing Weak Encryption 2.6.2 Choosing Weak Encryption
Like all algorithms that use 40 bit keys, RC2/40 is considered by many Like all algorithms that use 40 bit keys, RC2/40 is considered by many
to be weak encryption. A sending agent that is controlled by a human to be weak encryption. A sending agent that is controlled by a human
SHOULD allow a human sender to determine the risks of sending data SHOULD allow a human sender to determine the risks of sending data
using RC2/40 or a similarly weak encryption algorithm before sending using RC2/40 or a similarly weak encryption algorithm before sending
the data, and possibly allow the human to use a stronger encryption the data, and possibly allow the human to use a stronger encryption
method such as tripleDES. method such as tripleDES.
skipping to change at line 954 skipping to change at line 970
are many ways of getting certificates, such as through an exchange are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette, with a certificate authority, through a hardware token or diskette,
and so on. and so on.
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part. with certificate authorities using an application/pkcs10 body part.
The IETF's PKIX Working Group is preparing another method for The IETF's PKIX Working Group is preparing another method for
requesting certificates; however, that work was not finished at the requesting certificates; however, that work was not finished at the
time of this draft. S/MIME v3 does not specify how to request a time of this draft. S/MIME v3 does not specify how to request a
certificate, but instead mandates that every sending agent already has certificate, but instead mandates that every sending agent already has
a certificate. a certificate. Standardization of certificate management is being
pursued separately in the IETF.
S/MIME v3 does not specify the details of certificate management, but
instead mandates that every sending agent already has a certificate.
Standardization of certificate management is being pursued separately
in the IETF.
3.8 Identifying an S/MIME Message 3.8 Identifying an S/MIME Message
Because S/MIME takes into account interoperation in non-MIME Because S/MIME takes into account interoperation in non-MIME
environments, several different mechanisms are employed to carry the environments, several different mechanisms are employed to carry the
type information, and it becomes a bit difficult to identify S/MIME type information, and it becomes a bit difficult to identify S/MIME
messages. The following table lists criteria for determining whether messages. The following table lists criteria for determining whether
or not a message is an S/MIME message. A message is considered an or not a message is an S/MIME message. A message is considered an
S/MIME message if it matches any below. S/MIME message if it matches any below.
skipping to change at line 1070 skipping to change at line 1082
If a sending agent is sending the same message using different If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications strengths of cryptography, an attacker watching the communications
channel can determine the contents of the strongly-encrypted message channel can determine the contents of the strongly-encrypted message
by decrypting the weakly-encrypted version. In other words, a sender by decrypting the weakly-encrypted version. In other words, a sender
should not send a copy of a message using weaker cryptography than should not send a copy of a message using weaker cryptography than
they would use for the original of the message. they would use for the original of the message.
A. Object Identifiers and Syntax A. Object Identifiers and Syntax
The syntax for SMIMECapability is:
SMIMECapability ::= SEQUENCE { SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER, capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL } parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability SMIMECapabilities ::= SEQUENCE OF SMIMECapability
The syntax for SMIMEEncryptionKeyPreference is:
SMIMEEncryptionKeyPreference ::= CHOICE { SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber, issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier, receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] KeyIdentifier subjectAltKeyIdentifier [2] KeyIdentifier
} }
A.1 Content Encryption Algorithms A.1 Content Encryption Algorithms
RC2-CBC OBJECT IDENTIFIER ::= RC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3)
encryptionAlgorithm(3) 2} 2}
For the effective-key-bits (key size) greater than 32 and less than For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as: 256, the RC2-CBC algorithm parameters are encoded as:
RC2-CBC parameter ::= SEQUENCE { RC2-CBC parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER, rc2ParameterVersion INTEGER,
iv OCTET STRING (8)} iv OCTET STRING (8)}
For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. values are 160, 120, 58 respectively.
DES-EDE3-CBC OBJECT IDENTIFIER ::= DES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3)
encryptionAlgorithm(3) 7} 7}
For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as: For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:
CBCParameter :: IV CBCParameter :: IV
where IV ::= OCTET STRING -- 8 octets. where IV ::= OCTET STRING -- 8 octets.
A.2 Digest Algorithms A.2 Digest Algorithms
md5 OBJECT IDENTIFIER ::= md5 OBJECT IDENTIFIER ::=
skipping to change at line 1211 skipping to change at line 1219
[PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315 [PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268 [RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute
of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May
1994. 1994.
[SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311 [SMIMEV2] "S/MIME Version 2 Message Specification", RFC 2311
C. Request for New MIME Subtypes C. Encapsulating Signed Messages for Internet Transport
C.1 application/pkcs7-mime
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mime
MIME media type name: application
MIME subtype name: pkcs7-mime
Required parameters: none
Optional parameters: name, filename, smime-type
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry data formatted with
PKCS-7, as described in [PKCS-7]
Published specification: draft-dusse-smime-msg-xx
Applications which use this media type: Secure Internet mail and other
secure data transports.
Additional information:
File extension(s): .p7m and .p7c
Macintosh File Type Code(s):
Person & email address to contact for further information: Steve
Dusse, spock@rsa.com
Intended usage: COMMON
C.2 application/pkcs7-signature
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-signature
MIME media type name: application
MIME subtype name: pkcs7-signature
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry digital signatures
with PKCS-7, as described in [PKCS-7]
Published specification: draft-dusse-smime-msg-xx
Applications which use this media type: Secure Internet mail and other
secure data transports.
Additional information:
File extension(s): .p7s
Macintosh File Type Code(s):
Person & email address to contact for further information: Steve
Dusse, spock@rsa.com
Intended usage: COMMON
D. Encapsulating Signed Messages for Internet Transport
The rationale behind the multiple formats for signing has to do with The rationale behind the multiple formats for signing has to do with
the MIME subtype defaulting rules of the application and multipart top- the MIME subtype defaulting rules of the application and multipart top-
level types, and the behavior of currently deployed gateways and mail level types, and the behavior of currently deployed gateways and mail
user agents. user agents.
Ideally, the multipart/signed format would be the only format used Ideally, the multipart/signed format would be the only format used
because it provides a truly backwards compatible way to sign MIME because it provides a truly backwards compatible way to sign MIME
entities. In a pure MIME environment with very capable user agents, entities. In a pure MIME environment with very capable user agents,
this would be possible. The world, however, is more complex than this. this would be possible. The world, however, is more complex than this.
skipping to change at line 1319 skipping to change at line 1255
A similar problem occurs when an attempt is made to combine an A similar problem occurs when an attempt is made to combine an
existing user agent with a stand-alone S/MIME facility. Typical user existing user agent with a stand-alone S/MIME facility. Typical user
agents do not have the ability to make a multipart sub-entity agents do not have the ability to make a multipart sub-entity
available to a stand-alone application in the same way they make leaf available to a stand-alone application in the same way they make leaf
MIME entities available to "viewer" applications. This user agent MIME entities available to "viewer" applications. This user agent
behavior is not required by the MIME standard and thus not widely behavior is not required by the MIME standard and thus not widely
implemented. The result is that it is impossible for most user agents implemented. The result is that it is impossible for most user agents
to hand off the entire multipart/signed entity to a stand-alone to hand off the entire multipart/signed entity to a stand-alone
application. application.
D.1 Solutions to the Problem C.1 Solutions to the Problem
To work around these two problems, the application/pkcs7-mime type can To work around these two problems, the application/pkcs7-mime type can
be used. When going through a gateway, it will be defaulted to the be used. When going through a gateway, it will be defaulted to the
MIME type of application/octet-stream and treated as a single opaque MIME type of application/octet-stream and treated as a single opaque
entity. That is, the message will be treated as an attachment of entity. That is, the message will be treated as an attachment of
unknown type, converted into the local representation for an unknown type, converted into the local representation for an
attachment and thus can be made available to an S/MIME facility attachment and thus can be made available to an S/MIME facility
completely intact. A similar result is achieved when a user agent completely intact. A similar result is achieved when a user agent
similarly treats the application/pkcs7-mime MIME entity as a simple similarly treats the application/pkcs7-mime MIME entity as a simple
leaf node of the MIME structure and makes it available to viewer leaf node of the MIME structure and makes it available to viewer
skipping to change at line 1370 skipping to change at line 1306
built into a gateway or user agent, allowing expansion of the built into a gateway or user agent, allowing expansion of the
encapsulated entity under user control. Because it is a general encapsulated entity under user control. Because it is a general
mechanism, it is in many cases more likely to be available than an mechanism, it is in many cases more likely to be available than an
S/MIME facility. Thus, it enables users to expand or to verify signed S/MIME facility. Thus, it enables users to expand or to verify signed
messages based on their local facilities and choices. It provides messages based on their local facilities and choices. It provides
exactly the same advantages that the application/pkcs7-mime with exactly the same advantages that the application/pkcs7-mime with
signedData does. It also has the added benefit of allowing expansion signedData does. It also has the added benefit of allowing expansion
in non-S/MIME environments and expansion under the recipient's in non-S/MIME environments and expansion under the recipient's
control. control.
D.2 Encapsulation Using application/mime C.2 Encapsulation Using application/mime
In some cases, multipart/signed entities are automatically decomposed In some cases, multipart/signed entities are automatically decomposed
in such a way as to make computing the hash of the first part, the in such a way as to make computing the hash of the first part, the
signed part, impossible; in such a situation, the signature becomes signed part, impossible; in such a situation, the signature becomes
unverifiable. In order to prevent such decomposition until the MIME unverifiable. In order to prevent such decomposition until the MIME
entity can be processed in a proper S/MIME environment, a entity can be processed in a proper S/MIME environment, a
multipart/signed entity may be encapsulated in an application/mime multipart/signed entity may be encapsulated in an application/mime
entity. entity.
All S/MIME implementations SHOULD be able to generate and receive All S/MIME implementations SHOULD be able to generate and receive
skipping to change at line 1448 skipping to change at line 1384
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756 7GhIGfHfYT64VQbnj756
--boundary42-- --boundary42--
D.3 Encapsulation in an Non-MIME Environment C.3 Encapsulation in an Non-MIME Environment
While this document primarily addresses the Internet, it is useful to While this document primarily addresses the Internet, it is useful to
compose and receive S/MIME secured messages in non-MIME environments. compose and receive S/MIME secured messages in non-MIME environments.
This is particularly the case when it is desired that security be This is particularly the case when it is desired that security be
implemented end-to-end. Other discussion here addresses the receipt of implemented end-to-end. Other discussion here addresses the receipt of
S/MIME messages in non-MIME environments. Here the composition of S/MIME messages in non-MIME environments. Here the composition of
multipart/signed entities is addressed. multipart/signed entities is addressed.
When a message is to be sent in such an environment, the When a message is to be sent in such an environment, the
multipart/signed entity is created as described above. That entity is multipart/signed entity is created as described above. That entity is
skipping to change at line 1470 skipping to change at line 1406
an attachment. It must have a file name that ends with ".aps", as this an attachment. It must have a file name that ends with ".aps", as this
is the sole mechanism for recognizing it as an S/MIME message by the is the sole mechanism for recognizing it as an S/MIME message by the
receiving agent. receiving agent.
When this message arrives in a MIME environment, it is likely to have When this message arrives in a MIME environment, it is likely to have
a MIME type of application/octet-stream, with MIME parameters giving a MIME type of application/octet-stream, with MIME parameters giving
the filename for the attachment. If the intervening gateway has the filename for the attachment. If the intervening gateway has
carried the file type, it will end in ".aps" and be recognized as an carried the file type, it will end in ".aps" and be recognized as an
S/MIME message. S/MIME message.
E. Acknowledgements D. Acknowledgements
This document is largely derived from [SMIMEV2] written by Steve This document is largely derived from [SMIMEV2] written by Steve
Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa
Repka. Repka.
Significant comments and additions were made by John Pawling and Jim Significant comments and additions were made by John Pawling and Jim
Schaad. Schaad.
F. Needed changes E. Needed changes
Section 1.1 -- what documents are needed to implement S/MIME. Should 4.1 keylengths for RSA need to move to CMS
probably include X9.42, X9.57, etc. Should SMIMEEncryptionKeyPreference move to CMS?
Should we refer to draft-freed-gatesec in section 3.1.3 or elsewhere? 2.5.3.1 to determine the "same subject name" should this be a check
Section 2.6.1.x -- I want to discuss this some more. against the subject DN, or both the DN and the subjectAltName
Add a section for selecting the encrypting certificate for a extension?
particular recipient (doesn't belong in 2.6) Should most of appendix A be in CMS?
SMIMEEncryptionKeyPreference -- what implication do current
discussions have about this?
smimeVersion capability?
Section 4.1 -- keylengths for non-RSA keypair generation language
needed.
G. Changes from last draft F. Changes from last draft
Fixed section 2.6 numbering (Jim Schaad) Changed "Status of this memo" paragraph to reflect new IETF text (Paul
Sending agents MUST SHA-1 (used to be SHOULD) (John Pawling) Hoffman)
Redid 2.4.1 (use of id-data) (John Pawling) Removed PKCS #1 from 1.1 (this will be covered in CMS)
Removed SHOULD implication for encryption key preference (Jim Schaad) Removed 2.6.1.4 and changed 2.6.1.3 (Jim Schaad and Paul Hoffman)
Clarified language regarding year interpretation in signing-time (John Added 2.5.3.1 (Selection of Recipient Key Management Certificate) (Jim
Pawling) Schaad)
Removed willywaggling text in 2.6 (Paul Hoffman) Yanked appendix C (MIME type registration) (Paul Hoffman)
PKCS to CMS changes (John Pawling) Fixed duplicate sentence in 3.7 (Jim Schaad)
Clarification in section 3.2 (John Pawling, Jim Schaad) Added language to 2.5 to explain that other attributes should be
Various "and SignedData" to "with SignedData" changes (John Pawling) displayed to the user (Paul Hoffman)
Various terminology clarifications (John Pawling)
micalg language cleanup for multiple digests in 3.4.3.2 (Jim Schaad)
Removed editorial language about v2 from 3.7 (John Pawling)
Fixed references for [PKCS-1], [PKCS-7] and [RC2] to point to RFCs
(Blake Ramsdell)
Updated other references (John Pawling)
Removed appendix (that's funny) D (John Pawling)
H. Editor's address G. Editor's address
Blake Ramsdell Blake Ramsdell
Worldtalk Worldtalk
13122 NE 20th St., Suite C 13122 NE 20th St., Suite C
Bellevue, WA 98005 Bellevue, WA 98005
(425) 882-8861 (425) 882-8861
blaker@deming.com blaker@deming.com
 End of changes. 

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