draft-ietf-smime-rfc2633bis-01.txt   draft-ietf-smime-rfc2633bis-02.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2633bis-01.txt Brute Squad Labs draft-ietf-smime-rfc2633bis-02.txt Brute Squad Labs
June 30, 2002 October 30, 2002
Expires December 30, 2002 Expires April 30, 2003
S/MIME Version 3.1 Message Specification S/MIME Version 3.1 Message Specification
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 283 skipping to change at line 283
GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST
interpret the year field (YY) as follows: interpret the year field (YY) as follows:
if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is greater than or equal to 50, the year is interpreted as 19YY;
if YY is less than 50, the year is interpreted as 20YY. if YY is less than 50, the year is interpreted as 20YY.
2.5.2 SMIMECapabilities Attribute 2.5.2 SMIMECapabilities Attribute
The SMIMECapabilities attribute includes signature algorithms (such as The SMIMECapabilities attribute includes signature algorithms (such as
"sha1WithRSAEncryption"), symmetric algorithms (such as "DES-EDE3- "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-EDE3-
CBC"), and key encipherment algorithms (such as "rsaEncryption"). It CBC"), and key encipherment algorithms (such as "rsaEncryption").
also includes a non-algorithm capability which is the preference for There are also several identifiers which indicate support for other
signedData. The SMIMECapabilities were designed to be flexible and optional features such as binary encoding and compression. The
extensible so that, in the future, a means of identifying other SMIMECapabilities were designed to be flexible and extensible so that,
capabilities and preferences such as certificates can be added in a in the future, a means of identifying other capabilities and
way that will not cause current clients to break. preferences such as certificates can be added in a way that will not
cause current clients to break.
If present, the SMIMECapabilities attribute MUST be a SignedAttribute; If present, the SMIMECapabilities attribute MUST be a SignedAttribute;
it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a
SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT
include multiple instances of the SMIMECapabilities attribute. CMS include multiple instances of the SMIMECapabilities attribute. CMS
defines the ASN.1 syntax for Attribute to include attrValues SET OF defines the ASN.1 syntax for Attribute to include attrValues SET OF
AttributeValue. A SMIMECapabilities attribute MUST only include a AttributeValue. A SMIMECapabilities attribute MUST only include a
single instance of AttributeValue. There MUST NOT be zero or multiple single instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF instances of AttributeValue present in the attrValues SET OF
AttributeValue. AttributeValue.
skipping to change at line 593 skipping to change at line 594
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 processed, 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.
[TBD] 2822 header protection In order to protect outer, non-content related message headers (for
instance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in
order to apply S/MIME security services to these headers. It is up to
the receiving client to decide how to present these "inner" headers
along with the unprotected "outer" headers.
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.
The exact details of canonicalization depend on the actual MIME type The exact details of canonicalization depend on the actual MIME type
skipping to change at line 646 skipping to change at line 652
securing only 7-bit MIME entities, even for enveloped data that are securing only 7-bit MIME entities, even for enveloped data that are
not exposed to the transport, is that it allows the MIME entity to be not exposed to the transport, is that it allows the MIME entity to be
handled in any environment without changing it. For example, a trusted handled in any environment without changing it. For example, a trusted
gateway might remove the envelope, but not the signature, of a gateway might remove the envelope, but not the signature, of a
message, and then forward the signed message on to the end recipient message, and then forward the signed message on to the end recipient
so that they can verify the signatures directly. If the transport so that they can verify the signatures directly. If the transport
internal to the site is not 8-bit clean, such as on a wide-area internal to the site is not 8-bit clean, such as on a wide-area
network with a single mail gateway, verifying the signature will not network with a single mail gateway, verifying the signature will not
be possible unless the original MIME entity was only 7-bit data. be possible unless the original MIME entity was only 7-bit data.
S/MIME implementations which "know" that all intended recipient(s) are
capable of handling inner (all but the outermost) binary MIME objects
SHOULD NOT use 7-bit transfer encoding for the inner entities since
this would unnecessarily expand the message size. Implementations MAY
"know" that recipient implementations are capable of handling inner
binary MIME entities either by interpreting the
id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
agreement, or by other means.
If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability in unknown for any of the intended
recipients, S/MIME implementations SHOULD use transfer encoding
described in section 3.1.3 for all MIME entities they secure.
3.1.3 Transfer Encoding for Signing Using multipart/signed 3.1.3 Transfer Encoding for Signing Using multipart/signed
If a multipart/signed entity is EVER to be transmitted over the If a multipart/signed entity is EVER to be transmitted over the
standard Internet SMTP infrastructure or other transport that is standard Internet SMTP infrastructure or other transport that is
constrained to 7-bit text, it MUST have transfer encoding applied so constrained to 7-bit text, it MUST have transfer encoding applied so
that it is represented as 7-bit text. MIME entities that are 7-bit that it is represented as 7-bit text. MIME entities that are 7-bit
data already need no transfer encoding. Entities such as 8-bit text data already need no transfer encoding. Entities such as 8-bit text
and binary data can be encoded with quoted-printable or base-64 and binary data can be encoded with quoted-printable or base-64
transfer encoding. transfer encoding.
skipping to change at line 765 skipping to change at line 785
a sending agent emits the above parameters, the value of the a sending agent emits the above parameters, the value of the
parameters SHOULD be a file name with the appropriate extension: parameters SHOULD be a file name with the appropriate extension:
MIME Type File Extension MIME Type File Extension
Application/pkcs7-mime (signedData, envelopedData) .p7m Application/pkcs7-mime (signedData, envelopedData) .p7m
Application/pkcs7-mime (degenerate signedData .p7c Application/pkcs7-mime (degenerate signedData .p7c
certificate management message) certificate management message)
Application/pkcs7-mime (compressedData) .p7z
Application/pkcs7-signature .p7s Application/pkcs7-signature .p7s
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
skipping to change at line 796 skipping to change at line 818
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 specification defines the following about the contained content. This specification defines the following
smime- types. smime- types.
Name Security Inner Content Name CMS type Inner Content
enveloped-data EnvelopedData id-data enveloped-data EnvelopedData id-data
signed-data SignedData id-data signed-data SignedData id-data
cert-management SignedData none certs-only SignedData none
compressed-data CompressedData id-data
In order that consistency can be obtained with future, the following In order that consistency can be obtained with future, the following
guidelines should be followed when assigning a new smime-type guidelines should be followed when assigning a new smime-type
parameter. parameter.
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 two values for smime-type SHOULD be assigned "signed-*" and
"encrypted- *". If one operation can be assigned then this may be "encrypted- *". If one operation can be assigned then this may be
omitted. Thus since "cert-management" can only be signed, "signed-" is omitted. Thus since "certs-only" can only be signed, "signed-" is
omitted. 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 (for example, "OID.1.3.6.1.5.5.7.6.1" would "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would
be DES40). be DES40).
3.3 Creating an Enveloped-only Message 3.3 Creating an Enveloped-only Message
skipping to change at line 1009 skipping to change at line 1033
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.5 Signing and Encrypting 3.5 Creating an Compressed-only Message
To achieve signing and enveloping, any of the signed-only and This section describes the format for compressing a MIME entity.
encrypted-only MIME formats listed above may be nested. This is Please note that versions of S/MIME prior to 3.1 did not specify any
allowed because the above formats are all MIME entities, and because use of compressedData, and will not recognize it. The use of a
they all secure MIME entities. capability to indicate the ability to receive compressedData is
described in [CMSCOMPR] and is the preferred method for compatibility.
Step 1. The MIME entity to be enveloped is prepared according to
section 3.1.
Step 2. The MIME entity and other required data is processed into a
CMS object of type compressedData.
Step 3. The compressedData object is wrapped in a CMS ContentInfo
object.
Step 4. The ContentInfo object is inserted into an
application/pkcs7-mime MIME entity.
The smime-type parameter for compressed-only messages is "compressed-
data". The file extension for this type of message is ".p7z".
A sample message would be:
Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
3.6 Multiple Operations
Any of the signed-only, compressed-only and encrypted-only MIME
formats listed above may be nested. This is allowed because the above
formats are all MIME entities, and because they all secure MIME
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 apply any of the signing, encrypting and compressing
message first. It is up to the implementor and the user to choose. operations in any order. It is up to the implementor and the user to
When signing first, the signatories are then securely obscured by the choose. When signing first, the signatories are then securely obscured
enveloping. When enveloping first the signatories are exposed, but it by the enveloping. When enveloping first the signatories are exposed,
is possible to verify signatures without removing the enveloping. This but it is possible to verify signatures without removing the
may be useful in an environment were automatic signature verification enveloping. This may be useful in an environment were automatic
is desired, as no private key material is required to verify a signature verification is desired, as no private key material is
signature. required to verify a signature.
There are security ramifications to choosing whether to sign first or There are security ramifications to choosing whether to sign first or
encrypt first. A recipient of a message that is encrypted and then encrypt first. A recipient of a message that is encrypted and then
signed can validate that the encrypted block was unaltered, but cannot signed can validate that the encrypted block was unaltered, but cannot
determine any relationship between the signer and the unencrypted determine any relationship between the signer and the unencrypted
contents of the message. A recipient of a message that is signed-then- contents of the message. A recipient of a message that is signed-then-
encrypted can assume that the signed message itself has not been encrypted can assume that the signed message itself has not been
altered, but that a careful attacker may have changed the altered, but that a careful attacker may have changed the
unauthenticated portions of the encrypted message. unauthenticated portions of the encrypted message.
3.6 Creating a Certificate Management Message When using compression, the only guidance we will give here is to not
compress encrypted data, since this will not yield significant
compression.
3.7 Creating a Certificate Management Message
The certificate management message or MIME entity is used to transport The certificate management message or MIME entity is used to transport
certificates and/or certificate revocation lists, such as in response certificates and/or certificate revocation lists, such as in response
to a registration request. to a registration request.
Step 1. The certificates and/or certificate revocation lists are made Step 1. The certificates and/or certificate revocation lists are made
available to the CMS generating process which creates a CMS object of available to the CMS generating process which creates a CMS object of
type signedData. The signedData encapContentInfo eContent field MUST type signedData. The signedData encapContentInfo eContent field MUST
be absent and signerInfos field MUST be empty. be absent and signerInfos field MUST be empty.
Step 2. The signedData object is wrapped in a CMS ContentInfo Step 2. The signedData object is wrapped in a CMS ContentInfo
object. object.
Step 3. The ContentInfo object is enclosed in an application/pkcs7- Step 3. The ContentInfo object is enclosed in an application/pkcs7-
mime MIME entity mime MIME entity
The smime-type parameter for a certificate management message is The smime-type parameter for a certificate management message is
"cert-management". The file extension for this type of message is "certs-only". The file extension for this type of message is ".p7c".
".p7c".
Please note that in prior versions of S/MIME, the smime-type parameter
was set to "certs-only" for messages that contained only certificates
and/or certificate revocation lists. The new use of "cert-management"
is meant to clarify the semantic that both certificates and
certificate revocation lists might be found in these messages.
Receiving implementations SHOULD accept "certs-only" and
"cert-management" and treat them equivalently (that is, both could
contain certificates and/or certificate revocation lists).
3.7 Registration Requests 3.8 Registration Requests
A sending agent that signs messages MUST have a certificate for the A sending agent that signs messages MUST have a certificate for the
signature so that a receiving agent can verify the signature. There signature so that a receiving agent can verify the signature. There
are many ways of getting certificates, such as through an exchange are many ways of getting certificates, such as through an exchange
with a certificate authority, through a hardware token or diskette, with a certificate authority, through a hardware token or diskette,
and so on. and so on.
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part. with certificate authorities using an application/pkcs10 body part.
The IETF's PKIX Working Group is preparing another method for The IETF's PKIX Working Group is preparing another method for
requesting certificates; however, that work was not finished at the requesting certificates; however, that work was not finished at the
time of this specification. S/MIME v3 does not specify how to request time of this specification. S/MIME v3 does not specify how to request
a certificate, but instead mandates that every sending agent already a certificate, but instead mandates that every sending agent already
has a certificate. Standardization of certificate management is being has a certificate. Standardization of certificate management is being
pursued separately in the IETF. pursued separately in the IETF.
3.8 Identifying an S/MIME Message 3.9 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-
skipping to change at line 1109 skipping to change at line 1162
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/octet-stream MIME type: application/octet-stream
parameters: any parameters: any
file suffix: p7m, p7s, p7c file suffix: p7m, p7s, p7c, p7z
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 specification does not cover how S/MIME agents handle envelopes. This specification 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 1239 skipping to change at line 1292
-- prefered encryption certificate. -- prefered encryption certificate.
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} 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] SubjectKeyIdentifier subjectAltKeyIdentifier [2] SubjectKeyIdentifier
} }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list the OIDs to be used with S/MIME V3 -- The following list the OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [CMSALG] -- Signature Algorithms Not Found in [CMSALG]
-- --
-- md2WithRSAEncryption OBJECT IDENTIFIER ::= -- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2} -- 2}
-- --
-- Other Signed Attributes -- Other Signed Attributes
-- --
skipping to change at line 1265 skipping to change at line 1328
END END
B. References B. References
[CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft [CERT31] "S/MIME Version 3.1 Certificate Handling", Internet Draft
draft-ietf-smime-rfc2632bis draft-ietf-smime-rfc2632bis
[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", RFC 3369
rfc2630bis
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370
Draft draft-ietf-smime-cmsalg
[CMSCOMPR] "Compressed Data Content Type for Cryptographic Message
Syntax (CMS)", RFC 3274
[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
[ESS] "Enhanced Security Services for S/MIME", Internet draft, draft- [ESS] "Enhanced Security Services for S/MIME", RFC 2634
ietf-smime-ess-*.txt.
[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
2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC
2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5:
Conformance Criteria and Examples", RFC 2049 Conformance Criteria and Examples", RFC 2049
[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
skipping to change at line 1311 skipping to change at line 1374
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 217-C
16451 Redmond Way 16451 Redmond Way
Redmond, WA 98052-4482 Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@brutesquadlabs.com
E. Changes from last draft E. Changes from last draft
Changed draft to specification in lots of places (Russ Housley) Reverted cert-management to certs-only for the MIME type, and removed
related backward compatibility statements (Jim Schaad, Russ Housley)
Privacy changed to data confidentiality (Russ Housley)
Added section 1.5 for changes since S/MIME v3.0 (Russ Housley)
Blown bulleted list in section 2.5 (Russ Housley, Jim Schaad)
Yanked reference to timestamping service in section 2.5.1 (Russ
Housley)
Yanked OIDs found in [CMSALG] (Russ Housley)
Attempt at better English for first sentence of section 2.4.1 (Jim Binary encoding changes (Tony Capel)
Schaad)
Crazy English in section 1.1 3rd paragraph is probably worse (Piers Updated references to CMS, CMSALG and ESS to point to RFCs (Blake
Chivers) Ramsdell)
Various other language clarifications (Piers Chivers) Added message/rfc822 language to section 3.1 (Blake Ramsdell)
Hammered on section 3.6 for "certificate management" vs. "certs-only" Added compressed data language (new section 3.5, modifications to
(William Ottaway) section 3.6, new smime-type and file extension) (Blake Ramsdell)
 End of changes. 

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