draft-ietf-smime-msg-01.txt   draft-ietf-smime-msg-02.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-01.txt Worldtalk draft-ietf-smime-msg-02.txt Worldtalk
January 28, 1998 March 11, 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.
skipping to change at line 58 skipping to change at line 58
1.1 Specification Overview 1.1 Specification Overview
This document describes a protocol for adding cryptographic signature This document describes a protocol for adding cryptographic signature
and encryption services to MIME data. The MIME standard [MIME-SPEC] and encryption services to MIME data. The MIME standard [MIME-SPEC]
provides a general structure for the content type of Internet messages provides a general structure for the content type of Internet messages
and allows extensions for new content type applications. and allows extensions for new content type applications.
This draft defines how to create a MIME body part that has been This draft defines how to create a MIME body part that has been
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. This mime MIME type that can be used to transport those body parts.
draft also defines how to create certification requests that conform
to PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for
transporting those requests.
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 some of the specifications
listed in the following documents: listed in the following documents:
- "PKCS #1: RSA Encryption", [PKCS-1]. - "PKCS #1: RSA Encryption", [PKCS-1].
- "Cryptographic Message Syntax", [CMS] - "Cryptographic Message Syntax", [CMS]
- "PKCS #10: Certification Request Syntax", [PKCS-10].
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 156 skipping to change at line 152
subscribe subscribe
in the body of the message. There is a Web site for the mailing list in the body of the message. There is a Web site for the mailing list
at <http://www.imc.org/ietf-smime/>. at <http://www.imc.org/ietf-smime/>.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content and algorithm CMS allows for a wide variety of options in content and algorithm
support. This section puts forth a number of support requirements and support. This section puts forth a number of support requirements and
recommendations in order to achieve a base level of interoperability recommendations in order to achieve a base level of interoperability
among all S/MIME implementations. among all S/MIME implementations. [CMS] provides additional details
regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.1 DigestAlgorithmIdentifier
Receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD Receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD
support MD5 [MD5] for the purpose of providing backward compatibility support MD5 [MD5] for the purpose of providing backward compatibility
with MD5-digested S/MIME v2 SignedData objects. with MD5-digested S/MIME v2 SignedData objects.
Sending agents SHOULD use SHA-1. Sending agents SHOULD use SHA-1.
2.2 DigestEncryptionAlgorithmIdentifier 2.2 SignatureAlgorithmIdentifier
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].
Receiving agents SHOULD support verification of signatures using RSA Receiving agents SHOULD support verification of signatures using RSA
public key sizes from 512 bits to 1024 bits. public key sizes from 512 bits to 1024 bits.
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
skipping to change at line 189 skipping to change at line 186
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 MUST Sending agents SHOULD support rsaEncryption. If an agent supports
support encryption of symmetric keys with RSA public keys at key sizes rsaEncryption, then it MUST support encryption of symmetric keys with
from 512 bits to 1024 bits. RSA public keys at key sizes from 512 bits to 1024 bits.
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 "data" content type as the content within Sending agents MUST use the "data" content type as the content within
skipping to change at line 426 skipping to change at line 423
not be able to decrypt the message, not be able to decrypt the message,
then the sending agent SHOULD use tripleDES. then the sending agent SHOULD use tripleDES.
2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption 2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
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 not willing to risk that the recipient - and the sending agent is not willing to risk that the recipient
may not be able to decrypt the message, may not be able to decrypt the message,
then the sending agent MUST use RC2/40. then the sending agent SHOULD use RC2/40.
2.6.3 Choosing Weak Encryption 2.6.3 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 451 skipping to change at line 448
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 can decipher the contents of the strongly-
encrypted message simply by decrypting the weakly-encrypted message. 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 PKCS created. S/MIME messages are a combination of MIME bodies and CMS
objects. Several MIME types as well as several PKCS 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 PKCS processing facilities which produces a PKCS object. are given to CMS processing facilities which produces a PKCS object.
The PKCS object is then finally wrapped in MIME. The CMS object is then finally wrapped in MIME.
S/MIME provides one format for enveloped-only data, several formats S/MIME provides one format for enveloped-only data, several formats
for signed-only data, and several formats for signed and enveloped for signed-only data, and several formats for signed and enveloped
data. Several formats are required to accommodate several data. Several formats are required to accommodate several
environments, in particular for signed messages. The criteria for environments, in particular for signed messages. The criteria for
choosing among these formats are also described. choosing among these formats are also described.
The reader of this section is expected to understand MIME as described The reader of this section is expected to understand MIME as described
in [MIME-SPEC] and [MIME-SECURE]. in [MIME-SPEC] and [MIME-SECURE].
skipping to change at line 687 skipping to change at line 684
MIME Type File Extension MIME Type File Extension
application/pkcs7-mime (signedData, .p7m application/pkcs7-mime (signedData, .p7m
envelopedData) envelopedData)
application/pkcs7-mime (degenerate .p7c application/pkcs7-mime (degenerate .p7c
signedData "certs-only" message) signedData "certs-only" message)
application/pkcs7-signature .p7s application/pkcs7-signature .p7s
application/pkcs10 .p10
In addition, the file name SHOULD be limited to eight characters In addition, the file name SHOULD be limited to eight characters
followed by a three letter extension. The eight character filename followed by a three letter extension. The eight character filename
base can be any distinct name; the use of the filename base "smime" base can be any distinct name; the use of the filename base "smime"
SHOULD be used to indicate that the MIME entity is associated with SHOULD be used to indicate that the MIME entity is associated with
S/MIME. S/MIME.
Including a file name serves two purposes. It facilitates easier use Including a file name serves two purposes. It facilitates easier use
of S/MIME objects as files on disk. It also can convey type of S/MIME objects as files on disk. It also can convey type
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
skipping to change at line 719 skipping to change at line 714
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. signing it.
Step 1. The MIME entity to be enveloped is prepared according to Step 1. The MIME entity to be enveloped is prepared according to
section 3.1. section 3.1.
Step 2. The MIME entity and other required data is processed into a Step 2. The MIME entity and other required data is processed into a
CMS object of type envelopedData. CMS object of type envelopedData. In addition to encrypting a copy of
the content-encryption key for each recipient, a copy of the content
encryption key SHOULD be encrypted for the originator and included in
the envelopedData (see CMS Section 6).
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 enveloped-only messages is "enveloped- The smime-type parameter for enveloped-only messages is "enveloped-
data". The file extension for this type of message is ".p7m". data". The file extension for this type of message is ".p7m".
A sample message would be: A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
skipping to change at line 925 skipping to change at line 923
Step 1. The certificates are made available to the CMS generating Step 1. The certificates are made available to the CMS generating
process which creates a CMS object of type signedData. The contentInfo process which creates a CMS object of type signedData. The contentInfo
and signerInfos fields must be empty. and signerInfos fields must be empty.
Step 2. The CMS signedData object is enclosed in an application/pkcs7- Step 2. The CMS signedData object is enclosed in an application/pkcs7-
mime MIME entity mime MIME entity
The smime-type parameter for a certs-only message is "certs-only". The smime-type parameter for a certs-only message is "certs-only".
The file extension for this type of message is ".p7c". The file extension for this type of message is ".p7c".
3.7 Creating a Registration Request 3.7 Registration Requests
A typical application which allows a user to generate cryptographic
information has to submit that information to a certification
authority, who transforms it into a certificate. PKCS #10 describes a
syntax for certification requests. The application/pkcs10 body type
MUST be used to transfer a PKCS #10 certification request.
The details of certification requests and the process of obtaining a
certificate are beyond the scope of this draft. Instead, only the
format of data used in application/pkcs10 is defined.
3.7.1 Format of the application/pkcs10 Body
PKCS #10 defines the ASN.1 type CertificationRequest for use in
submitting a certification request. Therefore, when the MIME content
type application/pkcs10 is used, the body MUST be a
CertificationRequest, encoded using the Basic Encoding Rules (BER).
Although BER is specified, instead of the more restrictive DER, a
typical application will use DER since the CertificationRequest's
CertificationRequestInfo has to be DER-encoded in order to be signed.
A robust application SHOULD output DER, but allow BER or DER on input.
Data produced by BER or DER is 8-bit, but many transports are limited
to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding
SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be used
with application/pkcs10, although any 7-bit transfer encoding may
work.
3.7.2 Sending and Receiving an application/pkcs10 Body Part
For sending a certificate-signing request, the application/pkcs10
message format MUST be used to convey a PKCS #10 certificate-signing
request. Note that for sending certificates and CRLs messages without
any signed content, the application/pkcs7-mime message format MUST be
used to convey a degenerate CMS signedData "certs-only" message.
To send an application/pkcs10 body, the application generates the
cryptographic information for the user. The details of the
cryptographic information are beyond the scope of this draft.
Step 1. The cryptographic information is placed within a PKCS #10
CertificationRequest.
Step 2. The CertificationRequest is encoded according to BER or DER
(typically, DER).
Step 3. As a typical step, the DER-encoded CertificationRequest is
also base64 encoded so that it is 7-bit data suitable for transfer in
SMTP. This then becomes the body of an application/pkcs10 body part.
The result might look like this:
Content-Type: application/pkcs10; name=smime.p10 A sending agent that signs messages MUST have a certificate for the
Content-Transfer-Encoding: base64 signature so that a receiving agent can verify the signature. There
Content-Disposition: attachment; filename=smime.p10 are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette,
and so on.
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H with certificate authorities using an application/pkcs10 body part.
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 The IETF's PKIX Working Group is preparing another method for
0GhIGfHfQbnj756YT64V requesting certificates; however, that work was not finished at the
time of this draft. S/MIME v3 does not specify how to request a
certificate, but instead mandates that every sending agent already has
a certificate.
A typical application only needs to send a certification request. It S/MIME v3 does not specify the details of certificate management, but
is a certification authority that has to receive and process the instead mandates that every sending agent already has a certificate.
request. The steps for recovering the CertificationRequest from the Standardization of certificate management is being pursued separately
message are straightforward but are not presented here. The procedures in the IETF. S/MIME v2 specified a non-standard technology for
for processing the certification request are beyond the scope of this certificate management.
document.
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.
The file suffix in the table below comes from the "name" parameter in The file suffix in the table below comes from the "name" parameter in
the content-type header, or the "filename" parameter on the content- the content-type header, or the "filename" parameter on the content-
disposition header. These parameters that give the file suffix are not disposition header. These parameters that give the file suffix are not
listed below as part of the parameter section. listed below as part of the parameter section.
MIME type: application/pkcs7-mime MIME type: application/pkcs7-mime
parameters: any parameters: any
file suffix: any file suffix: any
MIME type: application/pkcs10
parameters: any
file suffix: any
MIME type: multipart/signed MIME type: multipart/signed
parameters: protocol="application/pkcs7-signature" parameters: protocol="application/pkcs7-signature"
file suffix: any file suffix: any
MIME type: application/mime MIME type: application/mime
parameters: content-type="multipart/signed"; parameters: content-type="multipart/signed";
protocol="application/pkcs7-signature" protocol="application/pkcs7-signature"
file suffix: any file suffix: any
MIME type: application/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, aps, p7c, p10 file suffix: p7m, p7s, aps, p7c
4. Certificate Processing 4. 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 draft does not cover how S/MIME agents handle envelopes. This draft 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 a different or rejected. S/MIME certification issues are covered in a different
document. document.
skipping to change at line 1110 skipping to change at line 1056
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: The syntax for SMIMECapability is:
SMIMECapability ::= SEQUENCE { SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER, capabilityID OBJECT IDENTIFIER,
parameters OPTIONAL ANY DEFINED BY capabilityID } parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability SMIMECapabilities ::= SEQUENCE OF SMIMECapability
The syntax for SMIMEEncryptionKeyPreference is: 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) encryptionAlgorithm(3) {iso(1) member-body(2) us(840) rsadsi(113549)
2} encryptionAlgorithm(3) 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.
skipping to change at line 1154 skipping to change at line 1100
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 ::=
{iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}
sha-1 OBJECT IDENTIFIER ::= sha-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26} {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2)
26}
A.3 Asymmetric Encryption Algorithms A.3 Asymmetric Encryption Algorithms
rsaEncryption OBJECT IDENTIFIER ::= rsaEncryption 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) pkcs(1) pkcs-1(1) 1}
rsa OBJECT IDENTIFIER ::= rsa OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
id-dsa OBJECT IDENTIFIER ::= id-dsa OBJECT IDENTIFIER ::=
skipping to change at line 1235 skipping to change at line 1182
[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", Internet Draft draft-hoffman-pkcs- [PKCS-1] "PKCS #1: RSA Encryption", Internet Draft draft-hoffman-pkcs-
rsa-encrypt rsa-encrypt
[PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft- [PKCS-7] "PKCS #7: Cryptographic Message Syntax", Internet Draft draft-
hoffman-pkcs-crypt-msg hoffman-pkcs-crypt-msg
[PKCS-10] "PKCS #10: Certification Request Syntax", Internet Draft
draft-hoffman-pkcs-certif-req
[RC2] "Description of the RC2 Encryption Algorithm", Internet Draft [RC2] "Description of the RC2 Encryption Algorithm", Internet Draft
draft-rivest-rc2desc draft-rivest-rc2desc
[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 Message Specification", Internet Draft draft-dusse- [SMIMEV2] "S/MIME Message Specification", Internet Draft draft-dusse-
smime-msg smime-msg
skipping to change at line 1262 skipping to change at line 1206
published. All S/MIME receiving agents SHOULD make every attempt to published. All S/MIME receiving agents SHOULD make every attempt to
interoperate with these earlier implementations of S/MIME. interoperate with these earlier implementations of S/MIME.
C.1 Early MIME Types C.1 Early MIME Types
Some early implementations of S/MIME agents used the following MIME Some early implementations of S/MIME agents used the following MIME
types: types:
application/x-pkcs7-mime application/x-pkcs7-mime
application/x-pkcs7-signature application/x-pkcs7-signature
application/x-pkcs10
In each case, the "x-" subtypes correspond to the subtypes described In each case, the "x-" subtypes correspond to the subtypes described
in this document without the "x-". in this document without the "x-".
C.2 Profiles C.2 Profiles
Early S/MIME documentation had two profiles for encryption: Early S/MIME documentation had two profiles for encryption:
"restricted" and "unrestricted". The difference between these profiles "restricted" and "unrestricted". The difference between these profiles
historically came about due to US Government export regulations, as historically came about due to US Government export regulations, as
described at the end of this section. It is expected that in the described at the end of this section. It is expected that in the
skipping to change at line 1397 skipping to change at line 1340
Additional information: Additional information:
File extension(s): .p7s File extension(s): .p7s
Macintosh File Type Code(s): Macintosh File Type Code(s):
Person & email address to contact for further information: Steve Person & email address to contact for further information: Steve
Dusse, spock@rsa.com Dusse, spock@rsa.com
Intended usage: COMMON Intended usage: COMMON
E.3 application/pkcs10
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs10
MIME media type name: application
MIME subtype name: pkcs10
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use
base64 encoding
Security considerations: Described in [PKCS-10]
Interoperability considerations: Designed to carry digital
certificates formatted with PKCS-10, as described in [PKCS-10]
Published specification: draft-dusse-smime-msg-xx
Applications which use this media type: Secure Internet mail and other
transports where certificates are required.
Additional information:
File extension(s): .p10
Macintosh File Type Code(s):
Person & email address to contact for further information: Steve
Dusse, spock@rsa.com
Intended usage: COMMON
F. Encapsulating Signed Messages for Internet Transport F. 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,
skipping to change at line 1630 skipping to change at line 1538
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.
H. Needed changes H. Needed changes
Need OIDs for Diffie-Hellman We need to document Diffie-Hellman parameters (key lengths, etc.) --
What do we need to do for 4.1 in order to make it Diffie-Hellman? is this a separate draft?
Cert generation in section 4.1 needs to talk about CMP from PKIX.
Perhaps another draft?
Section 4.1 needs to talk about DSS and DH minimum key lengths for
strong crypto
Is [DSS] the correct reference?
Algorithm identifiers need more cleanup
Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference
in their own sections?) in their own sections?)
Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber? Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber?
ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3 ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3, OID cleanup
Section 1.1 -- what documents are needed to implement S/MIME. Should
probably include X9.42, X9.57, etc.
Should we refer to draft-freed-gatesec in section 3.1.3 or elsewhere?
I. Changes from last draft I. Changes from last draft
Changed language in 2.1 to SHOULD instead of MUST support MD5 Fixed language in 2.6.2.4 regarding RC2/40 for "Unknown Capabilities,
Added some acknowledgements No Risk of Failed Decryption" (John Pawling)
Put back section 2.6.1-2.6.3, text from S/MIME v2 Various ASN.1 fixes (Phil Griffin)
Fixed various typos Removed all PKCS #10 / certificate request references (Paul Hoffman)
Added section 2.5.3 for encryption key preference, text from Jim Fixed some PKCS references that needed to be CMS (John Pawling)
Schaad 3.7 is now Registration Requests (Paul Hoffman / Dave Crocker)
Added SMIMEEncryptionKeyPreference to section A, text from Jim Schaad Clarified section 2.3 text regarding RSA public modulus length (John
Changed 2.4 to reflect subset of supported content types from [CMS] Pawling)
Updated section D Added text to 3.3 regarding encryption of content encryption key for
the originator (John Pawling)
Changed section 2.2 title to SignatureAlgorithmIdentifier (John
Pawling)
J. Editor's address J. 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/