draft-ietf-smime-msg-04.txt   draft-ietf-smime-msg-05.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-msg-04.txt Worldtalk draft-ietf-smime-msg-05.txt Worldtalk
May 4, 1998 August 6, 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 165 skipping to change at line 165
Sending and receiving agents MUST support SHA-1 [SHA1]. Receiving Sending and receiving agents MUST support SHA-1 [SHA1]. Receiving
agents SHOULD support MD5 [MD5] for the purpose of providing backward agents SHOULD support MD5 [MD5] for the purpose of providing backward
compatibility with MD5-digested S/MIME v2 SignedData objects. compatibility with MD5-digested S/MIME v2 SignedData objects.
2.2 SignatureAlgorithmIdentifier 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
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
determined during key generation. determined during key generation.
2.3 KeyEncryptionAlgorithmIdentifier 2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support Diffie-Hellman defined in Sending and receiving agents MUST support 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. If an agent supports Sending agents SHOULD support rsaEncryption.
rsaEncryption, then it MUST support encryption of symmetric keys with
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 id-data content type identifier to Sending agents MUST use the id-data content type identifier to
skipping to change at line 220 skipping to change at line 216
2.4.3 EnvelopedData Content Type 2.4.3 EnvelopedData Content Type
This content type is used to apply privacy protection to a message. A This content type is used to apply privacy protection to a message. A
sender needs to have access to a public key for each sender needs to have access to a public key for each
intended message recipient to use this service. This content type does intended message recipient to use this service. This content type does
not provide authentication. not provide authentication.
2.5 Attribute SignerInfo Type 2.5 Attribute SignerInfo Type
The SignerInfo type allows the inclusion of unauthenticated and The SignerInfo type allows the inclusion of unsigned and signed
authenticated attributes to be included along with a signature. attributes to be included along with a signature.
Receiving agents MUST be able to handle zero or one instance of each Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes described in this section. of the signed attributes described in this section.
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
skipping to change at line 265 skipping to change at line 261
The SMIMECapabilities attribute includes signature algorithms (such as The SMIMECapabilities attribute includes signature algorithms (such as
"md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and "md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and
key encipherment algorithms (such as "rsaEncryption"). It also key encipherment algorithms (such as "rsaEncryption"). It also
includes a non-algorithm capability which is the preference for includes a non-algorithm capability which is the preference for
signedData. The SMIMECapabilities were designed to be flexible and signedData. The SMIMECapabilities were designed to be flexible and
extensible so that, in the future, a means of identifying other extensible so that, in the future, a means of identifying other
capabilities and preferences such as certificates can be added in a capabilities and preferences such as certificates can be added in a
way that will not cause current clients to break. way that will not cause current clients to break.
If present, the SMIMECapabilities attribute MUST be a SignedAttribute;
it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a
SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT
include multiple instances of the SMIMECapabilities attribute. CMS
defines the ASN.1 syntax for Attribute to include attrValues SET OF
AttributeValue. A SMIMECapabilities attribute MUST only include a
single instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF
AttributeValue.
The semantics of the SMIMECapabilites attribute specify a partial list The semantics of the SMIMECapabilites attribute specify a partial list
as to what the client announcing the SMIMECapabilites can support. A as to what the client announcing the SMIMECapabilites can support. A
client does not have to list every capability it supports, and client does not have to list every capability it supports, and
probably should not list all its capabilities so that the capabilities probably should not list all its capabilities so that the capabilities
list doesn't get too long. In an SMIMECapabilities attribute, the OIDs list doesn't get too long. In an SMIMECapabilities attribute, the OIDs
are listed in order of their preference, but SHOULD be logically are listed in order of their preference, but SHOULD be logically
separated along the lines of their categories (signature algorithms, separated along the lines of their categories (signature algorithms,
symmetric algorithms, key encipherment algorithms, etc.) symmetric algorithms, key encipherment algorithms, etc.)
The structure of the SMIMECapabilities attribute is to facilitate The structure of the SMIMECapabilities attribute is to facilitate
skipping to change at line 323 skipping to change at line 329
The encryption key preference attribute allows for the signer to The encryption key preference attribute allows for the signer to
unambiguously describe which of the certificates issued to the signer unambiguously describe which of the certificates issued to the signer
should be used when sending encrypted content. This attribute allows should be used when sending encrypted content. This attribute allows
for the signer to state a preference, but not a requirement, as to the for the signer to state a preference, but not a requirement, as to the
certificate to be used. This attribute is designed to enhance certificate to be used. This attribute is designed to enhance
behavior for interoperating with those clients which use separate keys behavior for interoperating with those clients which use separate keys
for encryption and signing. This attribute is used to convey to the for encryption and signing. This attribute is used to convey to the
receiver which of the certificates should be used for encrypting the receiver which of the certificates should be used for encrypting the
session key. session key.
If present, the SMIMEEncryptionKeyPreference attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines
SignedAttributes as a SET OF Attribute. The SignedAttributes in a
signerInfo MUST NOT include multiple instances of the
SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax
for Attribute to include attrValues SET OF AttributeValue. A
SMIMEEncryptionKeyPreference attribute MUST only include a single
instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF
AttributeValue.
The sending agent SHOULD include the referenced certificate in the set The sending agent SHOULD include the referenced certificate in the set
of certificates included in the signed message if this attribute is of certificates included in the signed message if this attribute is
used. The certificate may be omitted if it has been previously made used. The certificate may be omitted if it has been previously made
available to the receiving agent. Sending agents SHOULD use this available to the receiving agent. Sending agents SHOULD use this
attribute if the commonly used or preferred encryption certificate is attribute if the commonly used or preferred encryption certificate is
not the same as the certificate used to sign the message. not the same as the certificate used to sign the message.
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
skipping to change at line 535 skipping to change at line 552
Step 1. The MIME entity is prepared according to the local conventions Step 1. The MIME entity is prepared according to the local conventions
Step 2. The leaf parts of the MIME entity are converted to canonical Step 2. The leaf parts of the MIME entity are converted to canonical
form form
Step 3. Appropriate transfer encoding is applied to the leaves of the Step 3. Appropriate transfer encoding is applied to the leaves of the
MIME entity MIME entity
When an S/MIME message is received, the security services on the When an S/MIME message is received, the security services on the
message are removed, and the result is the MIME entity. That MIME message are processed, and the result is the MIME entity. That MIME
entity is typically passed to a MIME-capable user agent where, it is entity is typically passed to a MIME-capable user agent where, it is
further decoded and presented to the user or receiving application. further decoded and presented to the user or receiving application.
3.1.1 Canonicalization 3.1.1 Canonicalization
Each MIME entity MUST be converted to a canonical form that is Each MIME entity MUST be converted to a canonical form that is
uniquely and unambiguously representable in the environment where the uniquely and unambiguously representable in the environment where the
signature is created and the environment where the signature will be signature is created and the environment where the signature will be
verified. MIME entities MUST be canonicalized for enveloping as well verified. MIME entities MUST be canonicalized for enveloping as well
as signing. as signing.
skipping to change at line 643 skipping to change at line 660
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 736 skipping to change at line 754
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.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. It is important to note that sending enveloped but not
signed messages does not provide for data integrity. It is possible to
replace ciphertext in such a way that the processed message will still
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
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. In addition to encrypting a copy of CMS object of type envelopedData. In addition to encrypting a copy of
the content-encryption key for each recipient, a copy of the content the content-encryption key for each recipient, a copy of the content
encryption key SHOULD be encrypted for the originator and included in encryption key SHOULD be encrypted for the originator and included in
the envelopedData (see CMS Section 6). the envelopedData (see CMS Section 6).
skipping to change at line 912 skipping to change at line 933
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--
3.4.3.4 Encapsulating multipart/signed Messages
Some mail gateways will split or alter a multipart/signed message in
ways that might invalidate the signature. Sending agents that create
multipart/signed messages may encapsulate those messages using the
application/mime construct [APP-MIME], as described in Appendix F.
3.5 Signing and Encrypting 3.5 Signing and Encrypting
To achieve signing and enveloping, any of the signed-only and To achieve signing and enveloping, any of the signed-only and
encrypted-only formats may be nested. This is allowed because the encrypted-only formats may be nested. This is allowed because the
above formats are all MIME entities, and because they all secure MIME above formats are all MIME entities, and because they all secure MIME
entities. entities.
An S/MIME implementation MUST be able to receive and process An S/MIME implementation MUST be able to receive and process
arbitrarily nested S/MIME within reasonable resource limits of the arbitrarily nested S/MIME within reasonable resource limits of the
recipient computer. recipient computer.
It is possible to either sign a message first, or to envelope the It is possible to either sign a message first, or to envelope the
message first. It is up to the implementor and the user to choose. message first. It is up to the implementor and the user to choose.
When signing first, the signatories are then securely obscured by the When signing first, the signatories are then securely obscured by the
enveloping. When enveloping first the signatories are exposed, but it enveloping. When enveloping first the signatories are exposed, but it
is possible to verify signatures without removing the enveloping. This is possible to verify signatures without removing the enveloping. This
may be useful in an environment were automatic signature verification may be useful in an environment were automatic signature verification
is desired, as no private key material is required to verify a is desired, as no private key material is required to verify a
signature. signature.
There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but cannot
determine any relationship between the signer and the unencrypted
contents of the message. A recipient of a message that is signed-then-
encrypted can assume that the signed message itself has not been
altered, but that a careful attacker may have changed the
unauthenticated portions of the encrypted message.
3.6 Creating a Certificates-only Message 3.6 Creating a Certificates-only Message
The certificates only message or MIME entity is used to transport The certificates only message or MIME entity is used to transport
certificates, such as in response to a registration request. This certificates, such as in response to a registration request. This
format can also be used to convey CRLs. format can also be used to convey CRLs.
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 signedData process which creates a CMS object of type signedData. The signedData
encapContentInfo eContent field MUST be absent and signerInfos field encapContentInfo eContent field MUST be absent and signerInfos field
MUST be empty. MUST be empty.
skipping to change at line 995 skipping to change at line 1018
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: 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
parameters: content-type="multipart/signed";
protocol="application/pkcs7-signature"
file suffix: any
MIME type: application/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, aps, p7c file suffix: p7m, p7s, 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 [CERT3]. or rejected. S/MIME certification issues are covered in [CERT3].
At a minimum, for initial S/MIME deployment, a user agent could At a minimum, for initial S/MIME deployment, a user agent could
skipping to change at line 1080 skipping to change at line 1098
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 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.
Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it.
A. Object Identifiers and Syntax A. Object Identifiers and Syntax
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
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.
DES-EDE3-CBC OBJECT IDENTIFIER ::= DES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) {iso(1) member-body(2) us(840) rsadsi(113549)
7} encryptionAlgorithm(3) 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 ::=
{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 1161 skipping to change at line 1184
{iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3} {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}
A.5 Signed Attributes A.5 Signed Attributes
signingTime OBJECT IDENTIFIER ::= signingTime OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
smimeCapabilities OBJECT IDENTIFIER ::= smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
id-aa-encrypKeyPref OBJECT IDENTIFIER ::=
{id-aa 11}
B. References B. References
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[APP-MIME] "Wrapping MIME Objects: Application/MIME", Internet Draft
draft-crocker-wrap-*.txt.
[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-
notes/iana/assignments/character-sets>. notes/iana/assignments/character-sets>.
[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
skipping to change at line 1219 skipping to change at line 1242
[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. Encapsulating Signed Messages for Internet Transport C. Acknowledgements
The rationale behind the multiple formats for signing has to do with
the MIME subtype defaulting rules of the application and multipart top-
level types, and the behavior of currently deployed gateways and mail
user agents.
Ideally, the multipart/signed format would be the only format used
because it provides a truly backwards compatible way to sign MIME
entities. In a pure MIME environment with very capable user agents,
this would be possible. The world, however, is more complex than this.
One problem with the multipart/signed format occurs with gateways to
non-MIME environments. In these environments, the gateway will
generally not be S/MIME aware, will not recognize the multipart/signed
type, and will default its treatment to multipart/mixed as is
prescribed by the MIME standard. The real problem occurs when the
gateway also applies conversions to the MIME structure of the original
message that is being signed and is contained in the first part of the
multipart/signed structure, such as the gateway converting text and
attachments to the local format. Because the signature is over the
MIME structure of the original message, but the original message is
now decomposed and transformed, the signature cannot be verified.
Because MIME encoding of a particular set of body parts can be done in
many different ways, there is no way to reconstruct the original MIME
entity over which the signature was computed.
A similar problem occurs when an attempt is made to combine an
existing user agent with a stand-alone S/MIME facility. Typical user
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
MIME entities available to "viewer" applications. This user agent
behavior is not required by the MIME standard and thus not widely
implemented. The result is that it is impossible for most user agents
to hand off the entire multipart/signed entity to a stand-alone
application.
C.1 Solutions to the Problem
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
MIME type of application/octet-stream and treated as a single opaque
entity. That is, the message will be treated as an attachment of
unknown type, converted into the local representation for an
attachment and thus can be made available to an S/MIME facility
completely intact. A similar result is achieved when a user agent
similarly treats the application/pkcs7-mime MIME entity as a simple
leaf node of the MIME structure and makes it available to viewer
applications.
Another way to work around these problems is to encapsulate the
multipart/signed MIME entity in a MIME entity of type
application/mime. The result is similar to that obtained using
application/pkcs7-mime. When the application/mime entity arrives at a
gateway that does not recognize it, its type will be defaulted to
application/octet-stream and it will be treated as a single opaque
entity. A similar situation will happen with a receiving client that
does not recognize the entity. It will usually be treated as a file
attachment. It can then be made available to the S/MIME facility.
The major difference between the two alternatives (application/pkcs7-
mime or multipart/signed wrapped with application/mime ) is when the
S/MIME facility opens the attachment. In the latter case, the S/MIME
agent will find a multipart/signed entity rather than a BER encoded
CMS object. Considering the two representations abstractly, the only
difference is syntax.
Application/mime is a general mechanism for encapsulating MIME, and in
particular delaying its interpretation until it can be done in the
appropriate environment or at the request of the user. The
application/mime specification does not permit a user agent to
automatically interpret the encapsulated MIME unless it can be
processed entirely and properly. The parameters to the
application/mime entity give the type of the encapsulated entity so it
can be determined whether or not the entity can be processed before it
is expanded.
Application/mime is a general encapsulation mechanism that can be
built into a gateway or user agent, allowing expansion of the
encapsulated entity under user control. Because it is a general
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
messages based on their local facilities and choices. It provides
exactly the same advantages that the application/pkcs7-mime with
signedData does. It also has the added benefit of allowing expansion
in non-S/MIME environments and expansion under the recipient's
control.
C.2 Encapsulation Using application/mime
In some cases, multipart/signed entities are automatically decomposed
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
unverifiable. In order to prevent such decomposition until the MIME
entity can be processed in a proper S/MIME environment, a
multipart/signed entity may be encapsulated in an application/mime
entity.
All S/MIME implementations SHOULD be able to generate and receive
application/mime encapsulations of multipart/signed entities which
have their signature of type application/pkcs7-mime. In particular, on
receipt of a MIME entity of type application/mime with the type
parameter "multipart/signed" and the protocol parameter
"application/pkcs7-mime", a receiving agent SHOULD be able to process
the entity correctly. This is required even if the local environment
has facilities for processing application/mime because
application/mime requires that the encapsulated entity only be
processed on request of the user, or if processing software can
process the entity completely and correctly. In this case, an S/MIME
facility can always process the entity completely and SHOULD do so.
The steps to create an application/mime encapsulation of a
multipart/signed entity are:
Step 1. Prepare a multipart/signed message as described in section
3.4.3.2
Step 2. Insert the multipart/signed entity into an application/mime
according to [APP-MIME]. This requires that the parameters of the
multipart/signed entity be included as parameters on the
application/mime entity.
Note that messages using application/mime are subject to the same
encoding rules as message/* and multipart/* types. The encoding of the
application/mime part MUST NOT be binary.
In addition, the application/mime entity SHOULD have a name parameter
giving a file name ending with ".aps". It SHOULD also have a content-
disposition parameter with the same filename. The ".aps" extension
SHOULD be used exclusively for application/mime encapsulated
multipart/signed entities containing a signature of type
application/pkcs7-signature. This is necessary so that the receiving
agent can correctly dispatch to software that verifies S/MIME
signatures in environments where the MIME type and parameters have
been lost or can't be used for such dispatch. Basically, the file
extension becomes the sole carrier of type information.
A sample application/mime encapsulation of a signed message might be:
Content-type: application/mime; content-type="multipart/signed";
protocol="application/pkcs7-signature";
micalg=sha1; name=smime.aps
Content-disposition: attachment; filename=smime.aps
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
This is a very short clear-signed message. However, at least you
can read it!
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--
C.3 Encapsulation in an Non-MIME Environment
While this document primarily addresses the Internet, it is useful to
compose and receive S/MIME secured messages in non-MIME environments.
This is particularly the case when it is desired that security be
implemented end-to-end. Other discussion here addresses the receipt of
S/MIME messages in non-MIME environments. Here the composition of
multipart/signed entities is addressed.
When a message is to be sent in such an environment, the
multipart/signed entity is created as described above. That entity is
then treated as an opaque stream of bits and added to the message as
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
receiving agent.
When this message arrives in a MIME environment, it is likely to have
a MIME type of application/octet-stream, with MIME parameters giving
the filename for the attachment. If the intervening gateway has
carried the file type, it will end in ".aps" and be recognized as an
S/MIME message.
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.
E. Needed changes D. Changes from last draft
4.1 keylengths for RSA need to move to CMS
Should SMIMEEncryptionKeyPreference move to CMS?
2.5.3.1 to determine the "same subject name" should this be a check
against the subject DN, or both the DN and the subjectAltName
extension?
Should most of appendix A be in CMS?
F. Changes from last draft
Changed "Status of this memo" paragraph to reflect new IETF text (Paul SMIMECapabilities and SMIMEEncryptionKeyPreference clarified to be
Hoffman) only single-instance, signed attributes (John Pawling)
Removed PKCS #1 from 1.1 (this will be covered in CMS) Removed keylength specifications for RSA signing and encryption (to be
Removed 2.6.1.4 and changed 2.6.1.3 (Jim Schaad and Paul Hoffman) moved to CMS section 12) (John Pawling)
Added 2.5.3.1 (Selection of Recipient Key Management Certificate) (Jim Slight wording changes in section 3.1 (security layers being "removed"
Schaad) changed to "processed") (Paul Hoffman and offline comments)
Yanked appendix C (MIME type registration) (Paul Hoffman) Added data integrity risks for enveloped-only data in section 3.3 and
Fixed duplicate sentence in 3.7 (Jim Schaad) section 5 (Paul Hoffman and offline comments)
Added language to 2.5 to explain that other attributes should be Fixed a typo in CBCParameter (Paul Hoffman)
displayed to the user (Paul Hoffman) Changed a reference to authenticated attributes to be signed
attributes (John Pawling)
Removed application/mime (Paul Hoffman)
G. Editor's address F. 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/