draft-ietf-smime-msg-06.txt   draft-ietf-smime-msg-07.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-06.txt Worldtalk draft-ietf-smime-msg-07.txt Worldtalk
December 14, 1998 March 31, 1999
Expires in six months Expires September 30, 1999
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 and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute 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
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
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 179 skipping to change at line 181
Sending and receiving agents MUST support id-dsa defined in [DSS]. Sending and receiving agents MUST support id-dsa defined in [DSS].
The algorithm parameters MUST be absent (not encoded as NULL). The algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1]. Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1].
Sending agents SHOULD support rsaEncryption. Outgoing messages are Sending agents SHOULD support rsaEncryption. Outgoing messages are
signed with a user's private key. The size of the private key is signed with a user's private key. The size of the private key is
determined during key generation. determined during key generation.
Note that S/MIME v2 clients are only capable of verifying digital
signatures using the rsaEncryption algorithm.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support Diffie-Hellman defined in Sending and receiving agents MUST support Diffie-Hellman defined in
[DH]. [DH].
Receiving agents SHOULD support rsaEncryption. Incoming encrypted Receiving agents SHOULD support rsaEncryption. Incoming encrypted
messages contain symmetric keys which are to be decrypted with a messages contain symmetric keys which are to be decrypted with a
user's private key. The size of the private key is determined during user's private key. The size of the private key is determined during
key generation. key generation.
Sending agents SHOULD support rsaEncryption. Sending agents SHOULD support rsaEncryption.
Note that S/MIME v2 clients are only capable of decrypting content
encryption keys using the rsaEncryption algorithm.
2.4 General Syntax 2.4 General Syntax
CMS defines multiple content types. Of these, only the Data, CMS defines multiple content types. Of these, only the Data,
SignedData, and EnvelopedData content types are currently used for SignedData, and EnvelopedData content types are currently used for
S/MIME. S/MIME.
2.4.1 Data Content Type 2.4.1 Data Content Type
Sending agents MUST use the id-data content type identifier to Sending agents MUST use the id-data content type identifier to
indicate the message content which has had security services applied indicate the message content which has had security services applied
to it. For example, when applying a digital signature to MIME data, to it. For example, when applying a digital signature to MIME data,
the CMS signedData encapContentInfo eContentType MUST include the id- the CMS signedData encapContentInfo eContentType MUST include the id-
data object identifier and the MIME content MUST be stored in the data object identifier and the MIME content MUST be stored in the
SignedData encapContentInfo eContent OCTET STRING. As another SignedData encapContentInfo eContent OCTET STRING (unless the sending
example, when applying encryption to MIME data, the CMS EnvelopedData agent is using multipart/signed, in which case the eContent is absent,
per section 3.4.3 of this document). As another example, when
applying encryption to MIME data, the CMS EnvelopedData
encryptedContentInfo ContentType MUST include the id-data object encryptedContentInfo ContentType MUST include the id-data object
identifier and the encrypted MIME content MUST be stored in the identifier and the encrypted MIME content MUST be stored in the
envelopedData encryptedContentInfo encryptedContent OCTET STRING. envelopedData encryptedContentInfo encryptedContent OCTET STRING.
2.4.2 SignedData Content Type 2.4.2 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.
skipping to change at line 237 skipping to change at line 247
Receiving agents MUST be able to handle zero or one instance of each Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes listed here. Sending agents SHOULD generate of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each S/MIME one instance of each of the following signed attributes in each S/MIME
message: message:
- signingTime (section 2.5.1 in this document) - signingTime (section 2.5.1 in this document)
- sMIMECapabilities (section 2.5.2 in this document) - sMIMECapabilities (section 2.5.2 in this document)
- sMIMEEncryptionKeyPreference (section 2.5.3 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
Further, receiving agents SHOULD be able to handle zero or one Further, receiving agents SHOULD be able to handle zero or one
instance of each of the signed attributes listed here. instance in the signed attributes of the signingCertificate attribute
- receiptRequest (section 2 in [ESS]) (section 5 in [ESS]).
- signingCertificate (section 5 in [ESS])
Sending agents SHOULD generate one instance of the signingCertificate Sending agents SHOULD generate one instance of the signingCertificate
signed attribute in each S/MIME message. signed attribute in each S/MIME message.
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 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
skipping to change at line 312 skipping to change at line 321
In the case of symmetric algorithms, the associated parameters for the In the case of symmetric algorithms, the associated parameters for the
OID MUST specify all of the parameters necessary to differentiate OID MUST specify all of the parameters necessary to differentiate
between two instances of the same algorithm. For instance, the number between two instances of the same algorithm. For instance, the number
of rounds and block size for RC5 must be specified in addition to the of rounds and block size for RC5 must be specified in addition to the
key length. key length.
There is a list of OIDs (OIDs Used with S/MIME) that is centrally There is a list of OIDs (OIDs Used with S/MIME) that is centrally
maintained and is separate from this draft. The list of OIDs is maintained and is separate from this draft. The list of OIDs is
maintained by the Internet Mail Consortium at <http://www.imc.org/ietf- maintained by the Internet Mail Consortium at <http://www.imc.org/ietf-
smime/oids.html>. smime/oids.html>. Note that all OIDs associated with the MUST and
SHOULD implement algorithms are included in section A of this
document.
The OIDs that correspond to algorithms SHOULD use the same OID as the The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is actual algorithm, except in the case where the algorithm usage is
ambiguous from the OID. For instance, in an earlier draft, ambiguous from the OID. For instance, in an earlier draft,
rsaEncryption was ambiguous because it could refer to either a rsaEncryption was ambiguous because it could refer to either a
signature algorithm or a key encipherment algorithm. In the event that signature algorithm or a key encipherment algorithm. In the event that
an OID is ambiguous, it needs to be arbitrated by the maintainer of an OID is ambiguous, it needs to be arbitrated by the maintainer of
the registered SMIMECapabilities list as to which type of algorithm the registered SMIMECapabilities list as to which type of algorithm
will use the OID, and a new OID MUST be allocated under the will use the OID, and a new OID MUST be allocated under the
smimeCapabilities OID to satisfy the other use of the OID. smimeCapabilities OID to satisfy the other use of the OID.
skipping to change at line 398 skipping to change at line 409
- Or use some other method of determining the user's 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 key. If a X.509 key management certificate is not found, then
encryption cannot be done with the signer of the message. If multiple 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 X.509 key management certificates are found, the S/MIME agent can make
an arbitrary choice between them. an arbitrary choice between them.
2.6 SignerIdentifier SignerInfo Type 2.6 SignerIdentifier SignerInfo Type
S/MIME v3 requires the use of SignerInfo version 1, that is the S/MIME v3 requires the use of SignerInfo version 1, that is the
issuerAndSerialNumber CHOICE must be used for SignerIdentifier. issuerAndSerialNumber CHOICE MUST be used for SignerIdentifier.
2.7 ContentEncryptionAlgorithmIdentifier 2.7 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.7.1 Deciding Which Encryption Method To Use 2.7.1 Deciding Which Encryption Method To Use
skipping to change at line 505 skipping to change at line 516
method such as tripleDES. method such as tripleDES.
2.7.3 Multiple Recipients 2.7.3 Multiple Recipients
If a sending agent is composing an encrypted message to a group of If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients recipients where the encryption capabilities of some of the recipients
do not overlap, the sending agent is forced to send more than one do not overlap, the sending agent is forced to send more than one
message. It should be noted that if the sending agent chooses to send message. It should be noted that if the sending agent chooses to send
a message encrypted with a strong algorithm, and then send the same a message encrypted with a strong algorithm, and then send the same
message encrypted with a weak algorithm, someone watching the message encrypted with a weak algorithm, someone watching the
communications channel can decipher the contents of the strongly- communications channel may be able to learn the contents of the
encrypted message simply by decrypting the weakly-encrypted message. strongly-encrypted message simply by decrypting the weakly-encrypted
message.
3. Creating S/MIME Messages 3. Creating S/MIME Messages
This section describes the S/MIME message formats and how they are This section describes the S/MIME message formats and how they are
created. S/MIME messages are a combination of MIME bodies and CMS created. S/MIME messages are a combination of MIME bodies and CMS
objects. Several MIME types as well as several CMS objects are used. objects. Several MIME types as well as several CMS objects are used.
The data to be secured is always a canonical MIME entity. The MIME The data to be secured is always a canonical MIME entity. The MIME
entity and other data, such as certificates and algorithm identifiers, entity and other data, such as certificates and algorithm identifiers,
are given to CMS processing facilities which produces a CMS object. are given to CMS processing facilities which produces a CMS object.
The CMS object is then finally wrapped in MIME. The Enhanced Security The CMS object is then finally wrapped in MIME. The Enhanced Security
skipping to change at line 681 skipping to change at line 693
Content-Type: multipart/mixed; boundary=bar Content-Type: multipart/mixed; boundary=bar
--bar --bar
Content-Type: text/plain; charset=iso-8859-1 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
=A1Hola Michael! =A1Hola Michael!
How do you like the new S/MIME specification? How do you like the new S/MIME specification?
I agree. It's generally a good idea to encode lines that begin with I agree. It's generally a good idea to encode lines that begin
with
From=20because some mail transport agents will insert a greater- From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature. than (>) sign, thus invalidating the signature.
Also, in some cases it might be desirable to encode any =20 Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20 trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20 that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20 a gateway that modifies such whitespace (like BITNET). =20
--bar --bar
Content-Type: image/jpeg Content-Type: image/jpeg
skipping to change at line 768 skipping to change at line 781
information across gateways. When a MIME entity of type information across gateways. When a MIME entity of type
application/pkcs7-mime (for example) arrives at a gateway that has no application/pkcs7-mime (for example) arrives at a gateway that has no
special knowledge of S/MIME, it will default the entity's MIME type to special knowledge of S/MIME, it will default the entity's MIME type to
application/octet-stream and treat it as a generic attachment, thus application/octet-stream and treat it as a generic attachment, thus
losing the type information. However, the suggested filename for an losing the type information. However, the suggested filename for an
attachment is often carried across a gateway. This often allows the attachment is often carried across a gateway. This often allows the
receiving systems to determine the appropriate application to hand the receiving systems to determine the appropriate application to hand the
attachment off to, in this case a stand-alone S/MIME processing attachment off to, in this case a stand-alone S/MIME processing
application. Note that this mechanism is provided as a convenience for application. Note that this mechanism is provided as a convenience for
implementations in certain environments. A proper S/MIME implementations in certain environments. A proper S/MIME
implementation MUST use the MIME types and MUST not rely on the file implementation MUST use the MIME types and MUST NOT rely on the file
extensions. extensions.
3.2.2 The smime-type parameter 3.2.2 The smime-type parameter
The application/pkcs7-mime content type defines the optional "smime- The application/pkcs7-mime content type defines the optional "smime-
type" parameter. The intent of this parameter is to convey details type" parameter. The intent of this parameter is to convey details
about the security applied (signed or enveloped) along with infomation about the security applied (signed or enveloped) along with infomation
about the contained content. This draft defines the following smime- about the contained content. This draft defines the following smime-
types. types.
skipping to change at line 800 skipping to change at line 813
1. If both signing and encryption can be applied to the content, then 1. If both signing and encryption can be applied to the content, then
two values for smime-type SHOULD be assigned "signed-*" and "encrypted- two values for smime-type SHOULD be assigned "signed-*" and "encrypted-
*". If one operation can be assigned then this may be omitted. Thus *". If one operation can be assigned then this may be omitted. Thus
since "certs-only" can only be signed, "signed-" is omitted. since "certs-only" can only be signed, "signed-" is omitted.
2. A common string for a content oid should be assigned. We use "data" 2. A common string for a content oid should be assigned. We use "data"
for the id-data content OID when MIME is the inner content. for the id-data content OID when MIME is the inner content.
3. If no common string is assigned. Then the common string of 3. If no common string is assigned. Then the common string of
"OID.<oid>" is recommended. "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would
be DES40).
3.3 Creating an Enveloped-only Message 3.3 Creating an Enveloped-only Message
This section describes the format for enveloping a MIME entity without This section describes the format for enveloping a MIME entity without
signing it. It is important to note that sending enveloped but not signing it. It is important to note that sending enveloped but not
signed messages does not provide for data integrity. It is possible to signed messages does not provide for data integrity. It is possible to
replace ciphertext in such a way that the processed message will still replace ciphertext in such a way that the processed message will still
be valid, but the meaning may be altered. be valid, but the meaning may be altered.
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
skipping to change at line 1093 skipping to change at line 1107
sending agents SHOULD also provide a mechanism to allow a user to sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
4.1 Key Pair Generation 4.1 Key Pair Generation
If an S/MIME agent needs to generate a key pair, then the S/MIME agent If an S/MIME agent needs to generate a key pair, then the S/MIME agent
or some related administrative utility or function MUST be capable of or some related administrative utility or function MUST be capable of
generating separate DH and DSS public/private key pairs on behalf of generating separate DH and DSS public/private key pairs on behalf of
the user. Each key pair MUST be generated from a good source of non- the user. Each key pair MUST be generated from a good source of non-
deterministic random input and the private key MUST be protected in a deterministic random input [RANDOM] and the private key MUST be
secure fashion. protected in a secure fashion.
If an S/MIME agent needs to generate a key pair, then the S/MIME agent If an S/MIME agent needs to generate a key pair, then the S/MIME agent
or some related administrative utility or function SHOULD generate RSA or some related administrative utility or function SHOULD generate RSA
key pairs. key pairs.
A user agent SHOULD generate RSA key pairs at a minimum key size of A user agent SHOULD generate RSA key pairs at a minimum key size of
768 bits. A user agent MUST NOT generate RSA key pairs less than 512 768 bits. A user agent MUST NOT generate RSA key pairs less than 512
bits long. Creating keys longer than 1024 bits may cause some older bits long. Creating keys longer than 1024 bits may cause some older
S/MIME receiving agents to not be able to verify signatures, but gives S/MIME receiving agents to not be able to verify signatures, but gives
better security and is therefore valuable. A receiving agent SHOULD be better security and is therefore valuable. A receiving agent SHOULD be
skipping to change at line 1143 skipping to change at line 1157
with a key of a particular size. Further, it is quite difficult to with a key of a particular size. Further, it is quite difficult to
determine the cost of a failed decryption if a recipient cannot decode determine the cost of a failed decryption if a recipient cannot decode
a message. Thus, choosing between different key sizes (or choosing a message. Thus, choosing between different key sizes (or choosing
whether to just use plaintext) is also impossible. However, decisions whether to just use plaintext) is also impossible. However, decisions
based on these criteria are made all the time, and therefore this based on these criteria are made all the time, and therefore this
draft gives a framework for using those estimates in choosing draft gives a framework for using those estimates in choosing
algorithms. algorithms.
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 may be able to determine the contents of the strongly-
by decrypting the weakly-encrypted version. In other words, a sender encrypted message by decrypting the weakly-encrypted version. In other
should not send a copy of a message using weaker cryptography than words, a sender should not send a copy of a message using weaker
they would use for the original of the message. cryptography than they would use for the original of the message.
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it.
A. Object Identifiers and Syntax A. ASN.1 Module
SecureMimeMessageV3
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };
-- id-aa is the arc with all new authenticated and unauthenticated
attributes
-- produced the by S/MIME Working Group
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
-- S/MIME Capabilities provides a method of broadcasting the symetric
capabilities
-- understood. Algorithms should be ordered by preference and
grouped
by type
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
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
-- Encryption Key Preference provides a method of broadcasting the
prefered
-- encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE { SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber, issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier, receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] KeyIdentifier subjectAltKeyIdentifier [2] SubjectKeyIdentifier
} }
A.1 Content Encryption Algorithms -- The Content Encryption Algorithms defined for SMIME are:
RC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 2}
For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:
RC2-CBC parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING (8)}
For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion -- Triple-DES is the manditory algorithm with CBCParameter being the
values are 160, 120, 58 respectively. parameters
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) 7} encryptionAlgorithm(3) 7}
For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:
CBCParameter ::= IV CBCParameter ::= IV
where IV ::= OCTET STRING -- 8 octets. IV ::= OCTET STRING (SIZE (8..8))
A.2 Digest Algorithms
md5 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}
sha-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2)
26}
A.3 Asymmetric Encryption Algorithms -- RC2 (or compatable) is an optional algorithm w/ RC2-CBC-paramter
as the
parameter
rsaEncryption OBJECT IDENTIFIER ::= rC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} {iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 2}
rsa OBJECT IDENTIFIER ::= -- For the effective-key-bits (key size) greater than 32 and less than
{joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} -- 256, the RC2-CBC algorithm parameters are encoded as:
id-dsa OBJECT IDENTIFIER ::= RC2-CBC-parameter ::= SEQUENCE {
{iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } rc2ParameterVersion INTEGER,
iv IV}
A.4 Signature Algorithms -- For the effective-key-bits of 40, 64, and 128, the
rc2ParameterVersion
-- values are 160, 120, 58 respectively.
md2WithRSAEncryption OBJECT IDENTIFIER ::= -- The following list the OIDs to be used with S/MIME V3
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}
md5WithRSAEncryption OBJECT IDENTIFIER ::= -- Digest Algorithms:
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}
sha-1WithRSAEncryption OBJECT IDENTIFIER ::= -- md5 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} -- {iso(1) member-body(2) us(840) rsadsi(113549)
digestAlgorithm(2) 5}
id-dsa-with-sha1 OBJECT IDENTIFIER ::= -- sha-1 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3} --- {iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2)
-- 26}
A.5 Signed Attributes -- Asymmetric Encryption Algorithms
--
-- rsaEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
1}
--
-- rsa OBJECT IDENTIFIER ::=
-- {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
--
-- id-dsa OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
signingTime OBJECT IDENTIFIER ::= -- Signature Algorithms
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} --
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
2}
--
-- md5WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
4}
--
-- sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
5}
--
-- id-dsa-with-sha1 OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}
smimeCapabilities OBJECT IDENTIFIER ::= -- Other Signed Attributes
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} --
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
5}
-- See [CMS] for a description of how to encode the attribute
value.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= END
{id-aa 11}
B. References B. References
[3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of [3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of
Operation", American National Standards Institute, 1998. Operation", American National Standards Institute, 1998.
[CERT3] "S/MIME Version 3 Certificate Handling", Internet Draft draft- [CERT3] "S/MIME Version 3 Certificate Handling", Internet Draft draft-
ietf-smime-cert-*.txt. ietf-smime-cert-*.txt.
[CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in- [CHARSETS] Character sets assigned by IANA. See <ftp://ftp.isi.edu/in-
skipping to change at line 1257 skipping to change at line 1322
[CMS] "Cryptographic Message Syntax", Internet Draft draft-ietf-smime- [CMS] "Cryptographic Message Syntax", Internet Draft draft-ietf-smime-
cms-*.txt. cms-*.txt.
[CONTDISP] "Communicating Presentation Information in Internet [CONTDISP] "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header Field", RFC 2183 Messages: The Content-Disposition Header Field", RFC 2183
[DES] ANSI X3.106, "American National Standard for Information Systems- [DES] ANSI X3.106, "American National Standard for Information Systems-
Data Link Encryption," American National Standards Institute, 1983. Data Link Encryption," American National Standards Institute, 1983.
[DH] ANSI X9.42 TBD [DH] "Diffie-Hellman Key Agreement Method", Internet Draft draft-ietf-
smime-x942-*.txt
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994.
[ESS] "Enhanced Security Services for S/MIME", Internet draft, draft- [ESS] "Enhanced Security Services for S/MIME", Internet draft, draft-
ietf-smime-ess-*.txt. ietf-smime-ess-*.txt.
[MD5] "The MD5 Message Digest Algorithm", RFC 1321 [MD5] "The MD5 Message Digest Algorithm", RFC 1321
[MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of
Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC
skipping to change at line 1282 skipping to change at line 1348
[MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and [MIME-SECURE] "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847 Multipart/Encrypted", RFC 1847
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
[PKCS-1] "PKCS #1: RSA Encryption Version 1.5", RFC 2313 [PKCS-1] "PKCS #1: RSA Encryption Version 1.5", RFC 2313
[PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315 [PKCS-7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315
[RANDOM] "Randomness Recommendations for Security", RFC 1750
[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. Acknowledgements C. Acknowledgements
This document is largely derived from [SMIMEV2] written by Steve <TBD>
Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa
Repka.
Significant comments and additions were made by John Pawling and Jim
Schaad.
D. Changes from last draft D. Changes from last draft
Changed section 2.5 to clarify signed attributes handling (Paul Clarified section 2.4.1 in the case of multipart/signed (eContent is
Hoffman) absent in that case) (Jim Schaad)
Changed [3DES] reference (Russ Housley) Removed receipt request attribute from section 2.5 (Jim Schaad)
Clarified 3.1.1 regarding canonicalization by the sending agent vs. Capitalized MUST for use of the issuerAndSerialNumber CHOICE in
the S/MIME part (Bill Flanigan, Paul Hoffman) section 2.6 (Jim Schaad)
Various small language changes (Bill Flanigan, Paul Hoffman) Capitalized NOT in section 3.2.1 regarding reliance on file extensions
Changed [DSS] reference to FIPS 186 (Bill Flanigan) (Jim Schaad)
Added section 3.2.2 for smime-type clarification (Jim Schaad) Changed [DH] reference to refer to draft-ietf-smime-x942-*.txt (Jim
Added definitions for "agents" (Bill Flanigan, Paul Hoffman) Schaad)
Inserted section 2.6 for SignerIdentifier (WG consensus) Replaced section A with ASN.1 module (Jim Schaad)
Rewording of 2.7.3 to explain that the content of the strongly-
encrypted message can be learned by decrypting the weaker message
(Russ Housley)
Provided example OID. string for new smime-type values in section
3.2.2 (Russ Housley)
Rewording of section 5 regarding sending two messages with different
levels of encryption (Russ Housley)
Added [RANDOM] reference in section 4.1 and to section B (Russ
Housley)
Explained in section 2.5.2 that section A contains all of the MUST and
SHOULD OIDs (Russ Housley)
Added language to 2.2 and 2.3 about S/MIME v2 clients only have
rsaEncryption (Paul Hoffman)
F. Editor's address F. Edito'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/