draft-ietf-smime-ess-04.txt   draft-ietf-smime-ess-05.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-04.txt Internet Mail Consortium draft-ietf-smime-ess-05.txt Internet Mail Consortium
March 12, 1998 April 11, 1998
Expires in six months Expires in six months
Enhanced Security Services for S/MIME Enhanced Security Services for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to cite is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress." them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow the "1id-abstracts.txt" listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
Coast). (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
1. Introduction 1. Introduction
This document describes three optional security service extensions for This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP], but are useful in many other environments, Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are: particularly business and finance. The services are:
- signed receipts - signed receipts
- security labels - security labels
- secure mailing lists - secure mailing lists
The services described here are extensions to S/MIME version 3 [SMIME3], The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender of the extensions will cause messages created by an S/MIME version 3 sender
skipping to change at line 180 skipping to change at line 180
[step 4] boundary=innerboundary | ) [step 4] boundary=innerboundary | )
[step 4] | ) [step 4] | )
[step 4] --innerboundary | ) [step 4] --innerboundary | )
[step 2] Content-type: text/plain % | ) [step 2] Content-type: text/plain % | )
[step 2] % | ) [step 2] % | )
[step 1] Original content % | ) [step 1] Original content % | )
[step 4] | ) [step 4] | )
[step 4] --innerboundary | ) [step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | ) [step 4] Content-type: application/pkcs7-signature | )
[step 4] | ) [step 4] | )
[step 3] inner signedData block (eContent is missing) | ) [step 3] inner SignedData block (eContent is missing) | )
[step 4] | ) [step 4] | )
[step 4] --innerboundary | ) [step 4] --innerboundary-- | )
[step 8] [step 8]
[step 8] --outerboundary [step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature [step 8] Content-type: application/pkcs7-signature
[step 8] [step 8]
[step 7] outer signedData block [step 7] outer SignedData block (eContent is missing)
[step 8] [step 8]
[step 8] --outerboundary [step 8] --outerboundary--
% = These lines are what the inner signature is computed over. % = These lines are what the inner signature is computed over.
| = These lines are what is encrypted in step 5. This encrypted result | = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block. is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over. ) = These lines are what the outer signature is computed over.
The format of a triple wrapped message that uses application/pkcs7-mime for The format of a triple wrapped message that uses application/pkcs7-mime for
the both signatures is: the both signatures is:
[step 8] Content-type: application/pkcs7-mime; [step 8] Content-type: application/pkcs7-mime;
skipping to change at line 300 skipping to change at line 300
------------------|-----------------------------|----------|------------- ------------------|-----------------------------|----------|-------------
contentHints |id-aa-contentHint [ESS] |either |no contentHints |id-aa-contentHint [ESS] |either |no
contentIdentifier |id-aa-contentIdentifier [ESS]|either |no contentIdentifier |id-aa-contentIdentifier [ESS]|either |no
contentType |id-contentType [CMS] |either |yes contentType |id-contentType [CMS] |either |yes
counterSignature |id-countersignature [CMS] |either |MUST NOT counterSignature |id-countersignature [CMS] |either |MUST NOT
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes
messageDigest |id-messageDigest [CMS] |either |yes messageDigest |id-messageDigest [CMS] |either |yes
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes
receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes
signingCertificate|id-ToBeDetermined [CMS] |either |yes
signingTime |id-signingTime [CMS] |either |yes signingTime |id-signingTime [CMS] |either |yes
smimeCapabilities |sMIMECapabilities [MSG] |either |yes smimeCapabilities |sMIMECapabilities [MSG] |either |yes
sMIMEEncryption-
KeyPreference |id-ToBeDetermined [MSG] |either |yes
If a counterSignature attribute is present, then it MUST be included in the If a counterSignature attribute is present, then it MUST be included in the
unauthenticated attributes. It MUST NOT be included in the authenticated unauthenticated attributes. It MUST NOT be included in the authenticated
attributes. attributes.
Note that the inner and outer signatures are for different senders, so that Note that the inner and outer signatures are for different senders, so that
the same attribute in the two signatures could lead to very different the same attribute in the two signatures could lead to very different
consequences. consequences.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
identifier assigned to the message. identifier assigned to the message.
1.4 Object Identifiers 1.4 Required and Optional Attributes
Some security gateways sign messages that pass through them. If the message
is any type other than a signedData type, the gateway has only one way to
sign the message: by wrapping it with a signedData block and MIME headers.
If the message to be signed by the gateway is a signedData message already,
the gateway can sign the message by inserting a signerInfo into the
signedData block.
The main advantage of a gateway adding a signerInfo instead of wrapping the
message in a new signature is that the message doesn't grow as much as if
the gateway wrapped the message. The main disadvantage is that the gateway
must check for the presence of certain attributes in the other signerInfos
and duplicate those attributes.
If a gateway or other processor adds a signerInfo to an existing signedData
block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes
from other signerInfos. This helps ensure that the recipient will process
those attributes in a signerInfo that it can verify.
Note that someone may in the future define an attribute that must be
present in each signerInfo of a signedData block in order for the signature
to be processed. If that happens, a gateway that inserts signerInfos and
doesn't copy that attribute will cause every message with that attribute to
fail when processed by the recipient. For this reason, it is safer to wrap
messages with new signatures than to insert signerInfos.
1.5 Object Identifiers
The object identifiers for many of the objects described in this draft are The object identifiers for many of the objects described in this draft are
found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be
found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>. found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>.
When this draft moves to standards track within the IETF, it is intended When this draft moves to standards track within the IETF, it is intended
that the IANA will maintain this registry. that the IANA will maintain this registry.
1.5 Criticality of Attributes
Authenticated attributes can be marked as critical. In this specification,
the only attribute which MUST be marked as critical is eSSSecurityLabel.
Note that marking any attribute as critical will make the message
unreadable to S/MIME v2 recipients. Because of this, a sending agent should
only mark attributes critical if necessary for the agent's application, and
at the risk of preventing an S/MIME v2 recipient from verifying (or
possibly even being able to read) the message.
2. Signed Receipts 2. Signed Receipts
Returning a signed receipt provides to the originator proof of delivery of Returning a signed receipt provides to the originator proof of delivery of
a message, and allows the originator to demonstrate to a third party that a message, and allows the originator to demonstrate to a third party that
the recipient was able to verify the signature of the original message. the recipient was able to verify the signature of the original message.
This receipt is bound to the original message through the signature; This receipt is bound to the original message through the signature;
consequently, this service may be requested only if a message is signed. consequently, this service may be requested only if a message is signed.
The receipt sender may optionally also encrypt a receipt to provide The receipt sender may optionally also encrypt a receipt to provide
confidentiality between the receipt sender and the receipt recipient. confidentiality between the receipt sender and the receipt recipient.
skipping to change at line 467 skipping to change at line 486
2.3 Receipt Request Processing 2.3 Receipt Request Processing
A receiptRequest is associated only with the SignerInfo object in which the A receiptRequest is associated only with the SignerInfo object in which the
receipt request attribute is directly attached. Processing software SHOULD receipt request attribute is directly attached. Processing software SHOULD
examine the authenticatedAttributes field of each of the SignerInfos for examine the authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to which it verifies a signature in the innermost signedData object to
determine if a receipt is requested. This may result in the receiving agent determine if a receipt is requested. This may result in the receiving agent
processing multiple receiptRequest attributes included in a single processing multiple receiptRequest attributes included in a single
SignedData object. SignedData object.
Because all receiptRequest attributes in a SignedData object must be Before processing a receiptRequest authenticatedAttribute, the receiving
identical, the receiving application fully processes (as described in the agent MUST verify the signature of the SignerInfo which covers the
following paragraphs) the first receiptRequest that it encounters in a receiptRequest attribute. A recipient MUST NOT process a receiptRequest
SignerInfo that it can verify, and it then ensures that all other attribute that has not been verified. Because all receiptRequest attributes
receiptRequests are identical to the first one encountered. If in a SignedData object must be identical, the receiving application fully
ReceiptRequests which conflict are present, then the processing software processes (as described in the following paragraphs) the first
MUST NOT return any receipt. receiptRequest attribute that it encounters in a SignerInfo that it
verifies, and it then ensures that all other receiptRequest attributes in
signerInfos that it verifies are identical to the first one encountered. If
there are verified ReceiptRequest attributes which conflict, then the
processing software MUST NOT return any signed receipt. A signed receipt
SHOULD be returned if any signerInfo containing a receiptRequest attribute
can be validated, even if other signerInfos containing the same
receiptRequest attribute cannot be validated because they are signed using
an algorithm not supported by the receiving agent.
If a receiptRequest attribute is absent from the authenticated attributes, If a receiptRequest attribute is absent from the authenticated attributes,
then a signed receipt has not been requested from any of the message then a signed receipt has not been requested from any of the message
recipients and MUST NOT be created. If a receiptRequest attribute is recipients and MUST NOT be created. If a receiptRequest attribute is
present in the authenticated attributes, then a signed receipt has been present in the authenticated attributes, then a signed receipt has been
requested from some or all of the message recipients. Note that in some requested from some or all of the message recipients. Note that in some
cases, a receiving agent might receive two almost-identical messages, one cases, a receiving agent might receive two almost-identical messages, one
with a receipt request and the other without one. In this case, the with a receipt request and the other without one. In this case, the
receiving agent SHOULD send a signed receipt for the message that requests receiving agent SHOULD send a signed receipt for the message that requests
a signed receipt. A receipt SHOULD be returned if any signature containing a signed receipt.
a receipt request can be validated, even if other signatures containing the
same receipt request cannot be validated.
If a receiptRequest attribute is present in the authenticated attributes, If a receiptRequest attribute is present in the authenticated attributes,
the following process SHOULD be used to determine if a message recipient the following process SHOULD be used to determine if a message recipient
has been requested to return a signed receipt. has been requested to return a signed receipt.
1. If an mlExpansionHistory attribute is present in the outermost 1. If an mlExpansionHistory attribute is present in the outermost
signedData block, do one of the following two steps, based on the absence signedData block, do one of the following two steps, based on the absence
or presence of mlReceiptPolicy: or presence of mlReceiptPolicy:
1.1. If an mlReceiptPolicy value is absent from the last MLData 1.1. If an mlReceiptPolicy value is absent from the last MLData
skipping to change at line 874 skipping to change at line 899
2.9 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL, contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
-- If contentDescription is used, its contents MUST be in UTF8 format
contentType ContentType } contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected to message subject. If this field is set, then the attribute is expected to
appear on the signedData object enclosing an envelopedData object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. If a contentDescription is present, it MUST on the inner signedData object. The SIZE (1..MAX) construct constrains the
be in UTF8 format, as described in [UTF8]. The SIZE (1..MAX) construct sequence to have at least one entry. MAX indicates the upper bound is
constrains the sequence to have at least one entry. MAX indicates the upper unspecified. Implementations are free to choose an upper bound that suits
bound is unspecified. Implementations are free to choose an upper bound their environment.
that suits their environment.
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an envelopedData
object, thus masking the inner content type of the message, SHOULD include object, thus masking the inner content type of the message, SHOULD include
a contentHints attribute, except for the case of the data content type. a contentHints attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion Specific message content types may either force or preclude the inclusion
of the contentHints attribute. For example, when a signedData/Receipt is of the contentHints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints be created that encapsulates the envelopedData object and a contentHints
attribute with contentType set to the id-ct-receipt object identifier MUST attribute with contentType set to the id-ct-receipt object identifier MUST
be included in the outer signedData SignerInfo authenticatedAttributes. be included in the outer signedData SignerInfo authenticatedAttributes.
skipping to change at line 1006 skipping to change at line 1029
signature. This may result in the receiving agent processing multiple signature. This may result in the receiving agent processing multiple
eSSSecurityLabels included in a single SignedData object. Because all eSSSecurityLabels included in a single SignedData object. Because all
eSSSecurityLabels in a SignedData object must be identical, the receiving eSSSecurityLabels in a SignedData object must be identical, the receiving
agent processes (such as performing access control) on the first agent processes (such as performing access control) on the first
eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
then ensures that all other eSSSecurityLabels in signerInfos that it then ensures that all other eSSSecurityLabels in signerInfos that it
verifies are identical to the first one encountered. If the verifies are identical to the first one encountered. If the
eSSSecurityLabels in the signerInfos that it verifies are not all eSSSecurityLabels in the signerInfos that it verifies are not all
identical, then the receiving agent MUST warn the user of this condition. identical, then the receiving agent MUST warn the user of this condition.
Receiving agents SHOULD have a local policy regarding whether or not to
show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing software
does not recognize. If the receiving agent does not recognize the
eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
processing the message and indicate an error.
3.2 Syntax of eSSSecurityLabel 3.2 Syntax of eSSSecurityLabel
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
::=".) Further, the eSSSecurityLabel syntax is compatible with that used in ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
[MSP4]. [MSP4].
The eSSSecurityLabel MUST be marked as critical. This means that any
message with an eSSSecurityLabel will be unreadable to S/MIME v2 clients.
Because of this, a sending agent SHOULD apply an eSSSecurityLabel only if
it needs the services this attribute provides.
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version Version DEFAULT v1, version [0] Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER { SecurityClassification ::= INTEGER {
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString SIZE (1..ub-privacy-mark-length),
-- If pString is used, the ESSSecurityLabel version is set to v1 -- If pString is used, the ESSSecurityLabel version is set to v1
utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX) utf8String UTF8String SIZE (1..MAX)
-- If utf8String is used, its contents MUST be in UTF8 format, and -- If utf8String is used, the ESSSecurityLabel version is set to v2
-- the ESSSecurityLabel version is set to v2
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER, type [0] OBJECT IDENTIFIER,
value [1] ANY -- defined by type value [1] ANY DEFINED BY type -- defined by type
} }
--Note: The aforementioned SecurityCategory syntax produces identical --Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is --hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification: --documented in the X.411 specification:
-- --
--SecurityCategory ::= SEQUENCE { --SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY, -- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type } -- value [1] ANY DEFINED BY type }
-- --
skipping to change at line 1084 skipping to change at line 1108
3.3 Security Label Components 3.3 Security Label Components
This section gives more detail on the the various components of the This section gives more detail on the the various components of the
eSSSecurityLabel syntax. eSSSecurityLabel syntax.
3.3.1 Security Policy Identifier 3.3.1 Security Policy Identifier
A security policy is a set of criteria for the provision of security A security policy is a set of criteria for the provision of security
services. The eSSSecurityLabel security-policy-identifier is used to services. The eSSSecurityLabel security-policy-identifier is used to
identify the security policy in force to which the security label relates. identify the security policy in force to which the security label relates.
It indicates the semantics of the other security label components. Even It indicates the semantics of the other security label components.
though the eSSSecurityLabel security-policy-identifier is an optional
field, all security labels used with S/MIME messages MUST include the
security-policy-identifier.
3.3.2 Security Classification 3.3.2 Security Classification
This specification defines the use of the Security Classification field This specification defines the use of the Security Classification field
exactly as is specified in the X.411 Recommendation, which states in part: exactly as is specified in the X.411 Recommendation, which states in part:
If present, a security-classification may have one of a hierarchical If present, a security-classification may have one of a hierarchical
list of values. The basic security-classification hierarchy is defined list of values. The basic security-classification hierarchy is defined
in this Recommendation, but the use of these values is defined by the in this Recommendation, but the use of these values is defined by the
security-policy in force. Additional values of security-classification, security-policy in force. Additional values of security-classification,
skipping to change at line 1227 skipping to change at line 1248
mlExpansionHistory attribute is present, then the MLA MUST add the current mlExpansionHistory attribute is present, then the MLA MUST add the current
expansion information to the end of the existing MLExpansionHistory expansion information to the end of the existing MLExpansionHistory
sequence. Only one mlExpansionHistory attribute can be included in the sequence. Only one mlExpansionHistory attribute can be included in the
authenticatedAttributes of a SignerInfo. authenticatedAttributes of a SignerInfo.
Note that if the mlExpansionHistory attribute is absent, then the recipient Note that if the mlExpansionHistory attribute is absent, then the recipient
is a first tier message recipient. is a first tier message recipient.
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having SignedData object may include multiple SignerInfos, each SignerInfo having a
a mlExpansionHistory attribute. For example, an originator can send a mlExpansionHistory attribute. For example, an MLA can send a signed message
signed message with two SignerInfos, one containing a DSS signature, the with two SignerInfos, one containing a DSS signature, the other containing
other containing an RSA signature. Not all of the SignerInfos need to an RSA signature.
include mlExpansionHistory attributes, but in all of the SignerInfos that
do contain mlExpansionHistory attributes, the mlExpansionHistory attributes
MUST be identical.
A recipient SHOULD only process an mlExpansionHistory attribute if the If an MLA creates a SignerInfo that includes an mlExpansionHistory
recipient can verify the signature of the SignerInfo which covers the attribute, then all of the SignerInfos created by the MLA for that
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which SignedData object MUST include an mlExpansionHistory attribute, and the
the recipient cannot authenticate. value of each MUST be identical. Note that other agents might later add
SignerInfo attributes to the SignedData block, and those additional
SignerInfos might not include mlExpansionHistory attributes.
When receiving a message that includes an outer SignedData object, a A recipient MUST verify the signature of the SignerInfo which covers the
receiving agent that processes mlExpansionHistory attributes MUST process mlExpansionHistory attribute before processing the mlExpansionHistory, and
the mlExpansionHistory attribute, if present, in each SignerInfo in the MUST NOT process the mlExpansionHistory attribute unless the signature over
SignedData object for which it verifies the signature. This may result in it has been verified. If a SignedData object has more than one SignerInfo
the receiving agent processing multiple mlExpansionHistory attributes that has an mlExpansionHistory attribute, the recipient MUST compare the
included in a single SignedData object. Because all mlExpansionHistory mlExpansionHistory attributes in all the SignerInfos, and MUST NOT process
attributes must be identical, the receiving application processes the first the mlExpansionHistory attribute unless every mlExpansionHistory attribute
mlExpansionHistory attribute that it encounters in a SignerInfo that it can in the SignedData block is identical. If the mlExpansionHistory attributes
verify, and then ensures that all other mlExpansionHistory attributes are in the signerInfos are not all identical, then the receiving agent MUST
identical to the first one encountered. stop processing the message and SHOULD notify the user or MLA administrator
of this error condition. In the mlExpansionHistory processing, SignerInfos
that do not have an mlExpansionHistory attribute are ignored.
4.1.1 Detecting Mail List Expansion Loops 4.1.1 Detecting Mail List Expansion Loops
Prior to expanding a message, the MLA examines the value of any existing Prior to expanding a message, the MLA examines the value of any existing
mail list expansion history attribute to detect an expansion loop. An mail list expansion history attribute to detect an expansion loop. An
expansion loop exists when a message expanded by a specific MLA for a expansion loop exists when a message expanded by a specific MLA for a
specific mail list is redelivered to the same MLA for the same mail list. specific mail list is redelivered to the same MLA for the same mail list.
Expansion loops are detected by examining the mailListIdentifier field of Expansion loops are detected by examining the mailListIdentifier field of
each MLData entry found in the mail list expansion history. If an MLA finds each MLData entry found in the mail list expansion history. If an MLA finds
skipping to change at line 1637 skipping to change at line 1659
A. ASN.1 Module A. ASN.1 Module
ExtendedSecurityServices ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, EntityIdentifier, SubjectKeyIdentifier, Version ContentType, EntityIdentifier, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
-- X.509 -- X.509
GeneralNames FROM CertificateExtensions GeneralNames FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
skipping to change at line 1697 skipping to change at line 1722
contentType ContentType, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL, contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
-- If contentDescription is used, its contents MUST be in UTF8 format
contentType ContentType } contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10 -- Section 2.10
MsgSigDigest ::= OCTET STRING MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
-- Section 3.2 -- Section 3.2
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version Version DEFAULT v1, version [0] Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER { SecurityClassification ::= INTEGER {
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString SIZE (1..ub-privacy-mark-length),
-- If pString is used, the ESSSecurityLabel version is set to v1 -- If pString is used, the ESSSecurityLabel version is set to v1
utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX) utf8String UTF8String SIZE (1..MAX)
-- If utf8String is used, its contents MUST be in UTF8 format, and -- If utf8String is used, the ESSSecurityLabel version is set to v2
-- the ESSSecurityLabel version is set to v2
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER, type [0] OBJECT IDENTIFIER,
value [1] ANY -- defined by type value [1] ANY DEFINED BY type -- defined by type
} }
--Note: The aforementioned SecurityCategory syntax produces identical --Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is --hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification: --documented in the X.411 specification:
-- --
--SecurityCategory ::= SEQUENCE { --SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY, -- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type } -- value [1] ANY DEFINED BY type }
-- --
skipping to change at line 1812 skipping to change at line 1835
[MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP)
4.0", Specification SDN.701, Revision A, 1997-02-06. 4.0", Specification SDN.701, Revision A, 1997-02-06.
[MTSABS] "1988 International Telecommunication Union (ITU) Data [MTSABS] "1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message Transfer System: Communication Networks Message Handling Systems: Message Transfer System:
Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)} mts(3) modules(0) mts-abstract-service(1)}
[PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315.
draft-hoffman-pkcs-crypt-msg-xx.
[SMIME2] "S/MIME Version 2 Message Specification", Internet Draft [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling", "S/MIME Version 2 Certificate Handling", RFC 2312.
Internet Draft draft-dusse-smime-cert-xx.
[SMIME3] "S/MIME Version 3 Message Specification", Internet Draft [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling", draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
Internet Draft draft-ietf-smime-cert-xx. Internet Draft draft-ietf-smime-cert-xx.
[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
C. Acknowledgments C. Acknowledgments
The first draft of this work was prepared by David Solo. John Pawling did a The first draft of this work was prepared by David Solo. John Pawling did a
huge amount of very detailed revision work during the many phases of the huge amount of very detailed revision work during the many phases of the
document. document.
Many other people have contributed hard work to this draft, including: Many other people have contributed hard work to this draft, including:
Bancroft Scott
Bengt Ackzell Bengt Ackzell
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Open Issues D. Open Issues
There is consensus that contentHints should move to the CMS draft. There are two "to be determined" attributes in 1.3.4.
E. Changes from draft-ietf-smime-ess-03 to draft-ietf-smime-ess-04
1. Removed mention of redefining UTF8String.
1.1.2, steps 3 and 5: Reworded these to make them clearer.
1.2 Changed both examples to be (hopefully) clearer. Also added MIME
boundaries that were left out.
2.3, step 2.2: added "in the outer signedData block". Also added to the
flow chart in step 1 and step 2.2.
2.3, flow chart: reworded 1.2.1.
2.4, step 1.1: Removed "ASN.1 DER encoded".
2.4, step 2.2: Reworded this step. E. Changes from draft-ietf-smime-ess-04 to draft-ietf-smime-ess-05
2.4, step 2.4: Added this step. 1.2: Added "(eContent is missing)" to step 7 of the first example.
Also added the terminal "--" on the two closing boundaries.
2.4, step 9: Changed "eContent" to "eContentType". 1.3.4: Added two lines to the table:
signingCertificate|id-ToBeDetermined [CMS] |either |yes
sMIMEEncryption-
KeyPreference |id-ToBeDetermined [MSG] |either |yes
2.4, step 10: added this new step, and renumbered the last step. 1.4: Added this section to discuss cases where gateways insert
signerInfos.
2.7: Removed superfluous sentence in the middle of the section. 1.5 (old): Removed this section because there is no more criticality.
2.9: Changed definition of contentDescription. Added note about UTF8 2.3: Replaced second paragraph, and removed the last sentence from
format. Also updated Appendix A. the third paragraph.
3.1.1: Changed last paragraph to deal with multiple eSSSecurityLabels. 2.8: Changed contentDescription to a UTF8String.
3.1.2: Change two paragraphs to deal with multiple eSSSecurityLabels. 3.1.2: Added third paragraph.
3.2: Added words in the second paragraph about use of eSSSecurityLabel and 3.2: Removed second paragraph (criticality) because it no longer exists in
S/MIME v2 clients. CMS. Change the ESSPrivacyMark second choice back to a "real" UTF8String to
match PKIX part 1. Made the SecurityPolicyIdentifier required (it was
optional before). Changed the value in SecurityCategory to:
value [1] ANY DEFINED BY type -- defined by type
3.2: Changed the second option of the ESSPrivacyMark to be an implicit 3.3.1: Removed the sentence about SecurityPolicyIdentifier being optional.
octet string. Added version number to ESSSecurityLabel. Made same changes
in Appendix A.
4.2: Replaced much of this section with more information about how to find 4.1: Replaced the last three paragraphs with more definitive wording
the outer wrapper. Also renumbered sub-parts of this section. about duplicate mlExpansionHistory attributes.
A: Removed UNIVERSAL 12 definition from top of module. A: Added the definition of UTF8String again to be in alignment with
PKIX part 1.
F. Editor's Address F. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
(408) 426-9827 (408) 426-9827
phoffman@imc.org phoffman@imc.org
 End of changes. 

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