draft-ietf-smime-ess-10.txt   draft-ietf-smime-ess-11.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-10.txt Internet Mail Consortium draft-ietf-smime-ess-11.txt Internet Mail Consortium
November 12, 1998 February 26, 1999
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 Internet-Drafts are working documents of the Internet Engineering
of the Internet Engineering Task Force (IETF), its areas, and its working Task Force (IETF), its areas, and its working groups. Note that
groups. Note that other groups may also distribute working documents as 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
may be updated, replaced, or obsoleted by other documents at any time. It months and may be updated, replaced, or obsoleted by other
is inappropriate to use Internet-Drafts as reference material or to cite documents at any time. It is inappropriate to use Internet-
them other than as "work in progress." Drafts as reference material or to cite them other than as
"work in progress."
To learn the current status of any Internet-Draft, please check the To view the list Internet-Draft Shadow Directories, see
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/shadow.html.
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West This document is an Internet-Draft and is in full conformance
Coast). with all provisions of Section 10 of RFC2026.
1. Introduction 1. Introduction
This document describes three optional security service extensions for This document describes four optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message S/MIME. The services are:
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
- signed receipts - signed receipts
- security labels - security labels
- secure mailing lists - secure mailing lists
- signing certificates
The first three of these services provide functionality that is similar to
the Message Security Protocol [MSP4], but are useful in many other
environments, particularly business and finance. Signing certificates are
useful in any environment where certificates might be transmitted with
signed messages.
The services described here are extensions to S/MIME version 3 ([MSG] and The services described here are extensions to S/MIME version 3 ([MSG] and
[CERT]), and some of them can also be added to S/MIME version 2 [SMIME2]. [CERT]), 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 The 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, to 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 some of the extensions will cause messages created by an S/MIME version 3
sender to be unreadable by an S/MIME version 2 recipient. sender to be unreadable by an S/MIME version 2 recipient.
This document describes both the procedures and the attributes needed for This document describes both the procedures and the attributes needed for
the three services. Note that some of the attributes described in this the three services. Note that some of the attributes described in this
document are quite useful in other contexts and should be considered when document are quite useful in other contexts and should be considered when
extending S/MIME or other CMS applications. extending S/MIME or other CMS applications.
The format of the messages are described in ASN.1:1988 [ASN1-1988]. The format of the messages are described in ASN.1:1988 [ASN1-1988].
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple wrapped"
skipping to change at line 295 skipping to change at line 300
agent will modify the data that was hashed to form that outer signature. In agent will modify the data that was hashed to form that outer signature. In
all cases, the agent adds or updates an mlExpansionHistory attribute to all cases, the agent adds or updates an mlExpansionHistory attribute to
document the agent's processing, and ultimately adds or replaces the outer document the agent's processing, and ultimately adds or replaces the outer
signature on the message to be distributed. signature on the message to be distributed.
1.3.4 Placement of Attributes 1.3.4 Placement of Attributes
Certain attributes should be placed in the inner or outer SignedData Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be message; some attributes can be in either. Further, some attributes must be
signed, while signing is optional for others, and some attributes must not signed, while signing is optional for others, and some attributes must not
be signed. The following table summarizes the recommendation of this be signed. ESS defines several types of attributes. ContentHints and
profile. In the OID column, [ESS] indicates that the attribute is defined ContentIdentifier MAY appear in any list of attributes. contentReference,
in this document. equivalentLabel, eSSSecurityLabel and mlExpansionHistory MUST be carried in
a SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
msgSigDigest, receiptRequest and signingCertificate MUST be carried in a
SignedAttributes, and MUST NOT be carried in a AuthAttributes,
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
The following table summarizes the recommendation of this profile. In the
OID column, [ESS] indicates that the attribute is defined in this document.
| |Inner or | | |Inner or |
Attribute |OID |outer |Signed Attribute |OID |outer |Signed
------------------|----------------------------- |----------|-------- ------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
skipping to change at line 319 skipping to change at line 332
messageDigest |id-messageDigest [CMS] |either |MUST messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
signingTime |id-signingTime [CMS] |either |MUST signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption- sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attributes and defines CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs as
unsignedAttributes as a SET OF Attributes. ESS defines the contentHints, a SET OF Attribute. ESS defines the contentHints, contentIdentifier,
contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest,
receiptRequest, contentReference and equivalentLabels attribute types. A contentReference, equivalentLabels and signingCertificate attribute types.
signerInfo MUST NOT include multiple instances of any of the attribute A signerInfo MUST NOT include multiple instances of any of the attribute
types defined in ESS. Later sections of ESS specify further restrictions types defined in ESS. Later sections of ESS specify further restrictions
that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel
attribute types. attribute types.
CMS defines the syntax for the signed and unsigned attributes as CMS defines the syntax for the signed and unsigned attributes as
"attrValues SET OF AttributeValue". For all of the attribute types defined "attrValues SET OF AttributeValue". For all of the attribute types defined
in ESS, if the attribute type is present in a signerInfo, then it MUST only in ESS, if the attribute type is present in a signerInfo, then it MUST only
include a single instance of AttributeValue. In other words, there MUST NOT include a single instance of AttributeValue. In other words, there MUST NOT
be zero or multiple instances of AttributeValue present in the attrValues be zero, or multiple, instances of AttributeValue present in the attrValues
SET OF AttributeValue. SET OF AttributeValue.
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
unsigned attributes. It MUST NOT be included in the signed attributes. The unsigned attributes. It MUST NOT be included in the signed attributes. The
only attributes that are allowed in a counterSignature attribute are only attributes that are allowed in a counterSignature attribute are
counterSignature, messageDigest, signingTime, and signingCertificate. counterSignature, messageDigest, signingTime, and signingCertificate.
Note that the inner and outer signatures are usually those of different Note that the inner and outer signatures are usually those of different
senders. Because of this, the same attribute in the two signatures could senders. Because of this, the same attribute in the two signatures could
lead to very different consequences. lead to very different consequences.
The macValue attribute defined in [CMS] is only used in authenticatedData,
never in signedData.
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 Required and Optional Attributes 1.4 Required and Optional Attributes
Some security gateways sign messages that pass through them. If the message 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 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. 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, 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 the gateway can sign the message by inserting a signerInfo into the
signedData block. signedData block.
The main advantage of a gateway adding a signerInfo instead of wrapping the 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 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 the gateway wrapped the message. The main disadvantage is that the gateway
must check for the presence of certain attributes in the other signerInfos must check for the presence of certain attributes in the other signerInfos
and duplicate those attributes. and either omit or copy those attributes.
If a gateway or other processor adds a signerInfo to an existing signedData If a gateway or other processor adds a signerInfo to an existing signedData
block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes
from other signerInfos. This helps ensure that the recipient will process from other signerInfos. This helps ensure that the recipient will process
those attributes in a signerInfo that it can verify. those attributes in a signerInfo that it can verify.
Note that someone may in the future define an attribute that must be 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 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 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 doesn't copy that attribute will cause every message with that attribute to
skipping to change at line 438 skipping to change at line 448
receipt for the original message (Section 2.6). This validation relies on receipt for the original message (Section 2.6). This validation relies on
the sender having retained either a copy of the original message or the sender having retained either a copy of the original message or
information extracted from the original message. information extracted from the original message.
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
syntax for the receipt is given in Section 2.8. syntax for the receipt is given in Section 2.8.
Note that a sending agent SHOULD remember when it has sent a receipt so Note that a sending agent SHOULD remember when it has sent a receipt so
that it can avoid re-sending a receipt each time it processes the message. that it can avoid re-sending a receipt each time it processes the message.
A receipt request can indicate that receipts be sent to many places, not
just to the sender (in fact, the receipt request might indicate that the
receipts should not even go to the sender). In order to verify a receipt,
the recipient of the receipt must be the originator or a recipient of the
original message. Thus, the sender SHOULD NOT request that receipts be sent
to anyone who does not have an exact copy of the message.
2.2 Receipt Request Creation 2.2 Receipt Request Creation
Multi-layer S/MIME messages may contain multiple SignedData layers. Multi-layer S/MIME messages may contain multiple SignedData layers.
However, receipts may be requested only for the innermost SignedData layer However, receipts may be requested only for the innermost SignedData layer
in a multi-layer S/MIME message, such as a triple wrapped message. Only one in a multi-layer S/MIME message, such as a triple wrapped message. Only one
receiptRequest attribute can be included in the signedAttributes of a receiptRequest attribute can be included in the signedAttributes of a
SignerInfo. SignerInfo.
A ReceiptRequest attribute MUST NOT be included in the attributes of a A ReceiptRequest attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content. In SignerInfo in a SignedData object that encapsulates a Receipt content. In
skipping to change at line 466 skipping to change at line 483
2. A signed content identifier for the message is created and assigned to 2. A signed content identifier for the message is created and assigned to
the signedContentIdentifier field. The signedContentIdentifier is used to the signedContentIdentifier field. The signedContentIdentifier is used to
associate the signed receipt with the message requesting the signed associate the signed receipt with the message requesting the signed
receipt. receipt.
3. The entities requested to return a signed receipt are noted in the 3. The entities requested to return a signed receipt are noted in the
receiptsFrom field. receiptsFrom field.
4. The message originator MUST populate the receiptsTo field with a 4. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed GeneralNames for each entity to whom the recipient should send the signed
receipt. If the message originator wants the recipient to send the signed receipt. If the message originator wants the recipient to send the signed
receipt to the originator, then the originator MUST include a GeneralNames receipt to the originator, then the originator MUST include a GeneralNames
for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
GeneralNames represents an entity. There may be multiple GeneralName GeneralNames represents an entity. There may be multiple GeneralName
instances in each GeneralNames. At a minimum, the message originator MUST instances in each GeneralNames. At a minimum, the message originator MUST
populate each entity's GeneralNames with the address to which the signed populate each entity's GeneralNames with the address to which the signed
receipt should be sent. Optionally, the message originator MAY also receipt should be sent. Optionally, the message originator MAY also
populate each entity's GeneralNames with other GeneralName instances (such populate each entity's GeneralNames with other GeneralName instances (such
as directoryName). as directoryName).
5. The completed receiptRequest attribute is placed in the signedAttributes 5. The completed receiptRequest attribute is placed in the signedAttributes
field of the SignerInfo object. field of the SignerInfo object.
2.2.1 Multiple Receipt Requests 2.2.1 Multiple Receipt Requests
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 signedAttributes. Therefore, a single SignedData SignerInfo may include signedAttributes. Therefore, a single SignedData
skipping to change at line 783 skipping to change at line 800
sequence of recipients. sequence of recipients.
2.6. Signed Receipt Validation 2.6. Signed Receipt Validation
A signed receipt is communicated as a single ASN.1 encoded object composed A signed receipt is communicated as a single ASN.1 encoded object composed
of a signedData object directly including a Receipt content. It is of a signedData object directly including a Receipt content. It is
identified by the presence of the id-ct-receipt object identifier in the identified by the presence of the id-ct-receipt object identifier in the
encapContentInfo eContentType value of the signedData object including the encapContentInfo eContentType value of the signedData object including the
Receipt content. Receipt content.
Although receipients are not supposed to send more than one signed receipt,
receiving agents SHOULD be able to accept multiple signed receipts from a
recipient.
A signedData/Receipt is validated as follows: A signedData/Receipt is validated as follows:
1. ASN.1 decode the signedData object including the Receipt content. 1. ASN.1 decode the signedData object including the Receipt content.
2. Extract the contentType, signedContentIdentifier, and 2. Extract the contentType, signedContentIdentifier, and
originatorSignatureValue from the decoded Receipt structure to identify the originatorSignatureValue from the decoded Receipt structure to identify the
original signedData signerInfo that requested the signedData/Receipt. original signedData signerInfo that requested the signedData/Receipt.
3. Acquire the message signature digest value calculated by the sender to 3. Acquire the message signature digest value calculated by the sender to
generate the signature value included in the original signedData signerInfo generate the signature value included in the original signedData signerInfo
skipping to change at line 912 skipping to change at line 933
-- formerly "allOrNone [0]AllOrNone" -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0), allReceipts (0),
firstTierRecipients (1) } firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to The receiptsTo field is used by the originator to identify the user(s) to
whom the identified recipient should send signed receipts. The message whom the identified recipient should send signed receipts. The message
originator MUST populate the receiptsTo field with a GeneralNames for each originator MUST populate the receiptsTo field with a GeneralNames for each
entity to whom the recipient should send the signed receipt. If the message entity to whom the recipient should send the signed receipt. If the message
originator wants the recipient to send the signed receipt to the originator wants the recipient to send the signed receipt to the
originator, then the originator MUST include a GeneralNames for itself in originator, then the originator MUST include a GeneralNames for itself in
the receiptsTo field. the receiptsTo field.
2.8 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, Receipt. The Receipt Receipts are represented using a new content type, Receipt. The Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version ESSVersion,
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}
ESSVersion ::= INTEGER { v1(1) }
The version field defines the syntax version number, which is 1 for this The version field defines the syntax version number, which is 1 for this
version of the standard. version of the standard.
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 UTF8String (SIZE (1..MAX)) OPTIONAL, contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  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. The (SIZE (1..MAX)) construct constrains on the inner signedData object. The (SIZE (1..MAX)) construct constrains
the sequence to have at least one entry. MAX indicates the upper bound is the sequence to have at least one entry. MAX indicates the upper bound is
skipping to change at line 970 skipping to change at line 993
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 signedAttributes. be included in the outer signedData SignerInfo signedAttributes.
2.10  Message Signature Digest Attribute 2.10 Message Signature Digest Attribute
The msgSigDigest attribute can only be used in the signed attributes of a The msgSigDigest attribute can only be used in the signed attributes of a
signed receipt. It contains the digest of the ASN.1 DER encoded signed receipt. It contains the digest of the ASN.1 DER encoded
signedAttributes included in the original signedData that requested the signedAttributes included in the original signedData that requested the
signed receipt. Only one msgSigDigest attribute can appear in an signed signed receipt. Only one msgSigDigest attribute can appear in an signed
attributes set. It is defined as follows: attributes set. It is defined as follows:
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}
2.11 Signed Content Reference Attribute 2.11 Signed Content Reference Attribute
The contentReference attribute is a link from one SignedData to another. It The contentReference attribute is a link from one SignedData to another. It
skipping to change at line 1016 skipping to change at line 1039
a set of security information regarding the sensitivity of the content that a set of security information regarding the sensitivity of the content that
is protected by S/MIME encapsulation. is protected by S/MIME encapsulation.
"Authorization" is the act of granting rights and/or privileges to users "Authorization" is the act of granting rights and/or privileges to users
permitting them access to an object. "Access control" is a means of permitting them access to an object. "Access control" is a means of
enforcing these authorizations. The sensitivity information in a security enforcing these authorizations. The sensitivity information in a security
label can be compared with a user's authorizations to determine if the user label can be compared with a user's authorizations to determine if the user
is allowed to access the content that is protected by S/MIME encapsulation. is allowed to access the content that is protected by S/MIME encapsulation.
Security labels may be used for other purposes such as a source of routing Security labels may be used for other purposes such as a source of routing
information. The labels are often priority based ("secret", "confidential", information. The labels often describe ranked levels ("secret",
"restricted", and so on) or role-based, describing which kind of people can "confidential", "restricted", and so on) or are role-based, describing
see the information ("patient's health-care team", "medical billing which kind of people can see the information ("patient's health-care team",
agents", "unrestricted", and so on). "medical billing agents", "unrestricted", and so on).
3.1 Security Label Processing Rules 3.1 Security Label Processing Rules
A sending agent may include a security label attribute in the signed A sending agent may include a security label attribute in the signed
attributes of a signedData object. A receiving agent examines the security attributes of a signedData object. A receiving agent examines the security
label on a received message and determines whether or not the recipient is label on a received message and determines whether or not the recipient is
allowed to see the contents of the message. allowed to see the contents of the message.
3.1.1 Adding Security Labels 3.1.1 Adding Security Labels
skipping to change at line 1129 skipping to change at line 1152
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)),
    utf8String   UTF8String (SIZE (1..MAX)) utf8String UTF8String (SIZE (1..MAX))
} }
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 {
skipping to change at line 1641 skipping to change at line 1664
not be the innermost layer. not be the innermost layer.
1. The MLA verifies the signature value found in the outermost SignedData 1. The MLA verifies the signature value found in the outermost SignedData
layer associated with the signed data. MLA processing of the message layer associated with the signed data. MLA processing of the message
terminates if the message signature is invalid. terminates if the message signature is invalid.
2. If the outermost SignedData layer includes an signed mlExpansionHistory 2. If the outermost SignedData layer includes an signed mlExpansionHistory
attribute, the MLA checks for an expansion loop as described in the attribute, the MLA checks for an expansion loop as described in the
"Detecting Mail List Expansion Loops" section, then go to step 3. If the "Detecting Mail List Expansion Loops" section, then go to step 3. If the
outermost SignedData layer does not include an signed mlExpansionHistory outermost SignedData layer does not include an signed mlExpansionHistory
attribute, go directly to step 4. attribute, the MLA signs the whole message (including this outermost
SignedData layer that doesn't have an mlExpansionHistory attribute), and
delivers the updated message to mail list members to complete MLA
processing.
3. Determine the type of the data that has been signed. That is, look at 3. Determine the type of the data that has been signed. That is, look at
the type of data on the layer just below the SignedData, which may or may the type of data on the layer just below the SignedData, which may or may
not be the "innermost" layer. Based on the type of data, perform either not be the "innermost" layer. Based on the type of data, perform either
step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
types). types).
3.1. If the signed data is EnvelopedData, the MLA performs expansion 3.1. If the signed data is EnvelopedData, the MLA performs expansion
processing of the encrypted message as described previously. Note that processing of the encrypted message as described previously. Note that
this process invalidates the signature value in the outermost this process invalidates the signature value in the outermost
skipping to change at line 1669 skipping to change at line 1695
remembering the value of the mlExpansionHistory and all other remembering the value of the mlExpansionHistory and all other
signed attributes in that layer, if present. signed attributes in that layer, if present.
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
encapsulates the expanded encrypted message in a new outermost encapsulates the expanded encrypted message in a new outermost
SignedData layer. On the other hand, if the signed data is SignedData layer. On the other hand, if the signed data is
SignedData (from step 3.2), the MLA encapsulates the signed data in SignedData (from step 3.2), the MLA encapsulates the signed data in
a new outermost SignedData layer. a new outermost SignedData layer.
3.2.3. The outermost signedData layer created by the MLA replaces 3.2.3. The outermost signedData layer created by the MLA replaces
the original outermost signedData layer. The MLA MUST create an the original outermost signedData layer. The MLA MUST create an
signed attribute list for the new outermost signedData layer which signed attribute list for the new outermost signedData layer which
MUST include each signed attribute present in the original MUST include each signed attribute present in the original
outermost signedData layer, unless the MLA explicitly replaces one outermost signedData layer, unless the MLA explicitly replaces one
or more particular attributes with new value. A special case is the or more particular attributes with new value. A special case is the
mlExpansionHistory attribute. The MLA MUST add an mlExpansionHistory attribute. The MLA MUST add an
mlExpansionHistory signed attribute to the outer signedData layer mlExpansionHistory signed attribute to the outer signedData layer
as follows: as follows:
3.2.3.1. If the original outermost SignedData layer included an 3.2.3.1. If the original outermost SignedData layer included an
mlExpansionHistory attribute, the attribute's value is copied mlExpansionHistory attribute, the attribute's value is copied
and updated with the current ML expansion information as and updated with the current ML expansion information as
described in the "Mail List Expansion" section. described in the "Mail List Expansion" section.
3.2.3.2. If the original outermost SignedData layer did not 3.2.3.2. If the original outermost SignedData layer did not
include an mlExpansionHistory attribute, a new attribute value include an mlExpansionHistory attribute, a new attribute value
skipping to change at line 1705 skipping to change at line 1731
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to mail
list members to complete MLA processing. list members to complete MLA processing.
A flow chart for the above steps would be: A flow chart for the above steps would be:
1. Has a valid signature? 1. Has a valid signature?
YES -> 2. YES -> 2.
NO -> STOP. NO -> STOP.
2. Does outermost SignedData layer contain mlExpansionHistory? 2. Does outermost SignedData layer contain mlExpansionHistory?
YES -> Check it, then -> 3. YES -> Check it, then -> 3.
NO -> 4. NO -> Sign message (including outermost SignedData that
3. Check type of data just below outermost doesn't have mlExpansionHistory), deliver it, STOP.
SignedData. 3. Check type of data just below outermost SignedData.
EnvelopedData -> 3.1. EnvelopedData -> 3.1.
SignedData -> 3.2. SignedData -> 3.2.
all others -> 3.3. all others -> 3.3.
3.1. Expand the encrypted message, then -> 3.2. 3.1. Expand the encrypted message, then -> 3.2.
3.2. -> 3.2.1. 3.2. -> 3.2.1.
3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
and other signed attributes, then -> 3.2.2. and other signed attributes, then -> 3.2.2.
3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.2. Encapsulate in new signature, then -> 3.2.3.
3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
YES -> copy the old mlExpansionHistory values, then -> 4. YES -> copy the old mlExpansionHistory values, then -> 4.
skipping to change at line 1761 skipping to change at line 1787
missing | none insteadOf(B) inAdditionTo(B) missing missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
4.4 Mail List Expansion History Syntax 4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
there are more than ub-ml-expansion-history mailing lists in the sequence, there are more than ub-ml-expansion-history mailing lists in the sequence,
the receiving agent should provide notification of the error to a human the receiving agent should provide notification of the error to a human
mail list administrator. The mail list administrator is responsible for mail list administrator. The mail list administrator is responsible for
correcting the overflow condition. correcting the overflow condition.
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has MLData contains the expansion history describing each MLA that has
processed a message. As an MLA distributes a message to members of an ML, processed a message. As an MLA distributes a message to members of an ML,
the MLA records its unique identifier, date and time of expansion, and the MLA records its unique identifier, date and time of expansion, and
receipt policy in an MLData structure. receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE { EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier } subjectKeyIdentifier SubjectKeyIdentifier }
The receipt policy of the ML can withdraw the originator's request for the The receipt policy of the ML can withdraw the originator's request for the
return of a signed receipt. However, if the originator of the message has return of a signed receipt. However, if the originator of the message has
not requested a signed receipt, the MLA cannot request a signed receipt. In not requested a signed receipt, the MLA cannot request a signed receipt. In
skipping to change at line 1840 skipping to change at line 1865
Explicit certificate policies can also be used as part of a signature Explicit certificate policies can also be used as part of a signature
verification process. If a signer desires to state an explicit certificate verification process. If a signer desires to state an explicit certificate
policy that should be used when validating the signature, that policy needs policy that should be used when validating the signature, that policy needs
to be cryptographically bound into the signing process. The methods to be cryptographically bound into the signing process. The methods
described in this section allows for a set of certificate policy statements described in this section allows for a set of certificate policy statements
to be listed as part of the signing certificate attribute. to be listed as part of the signing certificate attribute.
5.1. Attack Descriptions 5.1. Attack Descriptions
At least three different attacks can be launched against a possible At least three different attacks can be launched against a possible
signature verification process by changing the certificate or certficates signature verification process by replacing the certificate or certficates
used in the signature verification process. used in the signature verification process.
5.1.1 Substitution Attack Description 5.1.1 Substitution Attack Description
The first attack deals with simple substitution of one certificate for The first attack deals with simple substitution of one certificate for
another certificate. In this attack, the issuer and serial number in the another certificate. In this attack, the issuer and serial number in the
SignerInfo is modified to refer to a new certificate. This new certificate SignerInfo is modified to refer to a new certificate. This new certificate
is used during the signature verification process. is used during the signature verification process.
The first version of this attack is a simple denial of service attack where The first version of this attack is a simple denial of service attack where
skipping to change at line 1977 skipping to change at line 2002
certs SEQUENCE OF ESSCertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 } smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature. The encoding of the MUST be the certificate used to verify the signature. The encoding of the
ESSCertID for this certificate SHOULD NOT include the issuerSerial because ESSCertID for this certificate SHOULD include the issuerSerial field. If
the issuerAndSerialNumber is already present in the SignerInfo. The other constraints ensure that issuerAndSerialNumber will be present in the
certificate identified is used during the signature verification process. SignerInfo, the issuerSerial field MAY be omitted. The certificate
If the hash of the certificate does not match the certificate used to identified is used during the signature verification process. If the hash
verify the signature, the signature MUST be considered invalid. of the certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of ESSCertIDs, the If more than one certificate is present in the sequence of ESSCertIDs, the
certificates after the first one limit the set of attribute certificates certificates after the first one limit the set of authorization
that are used during signature validation. The issuerSerial SHOULD be certificates that are used during signature validation. Authorization
present in these certificates, unless the client who is validating the certificates can be either attribute certificates or normal certificates.
signature is expected to have easy access to all the certificates required The issuerSerial SHOULD be present in these certificates, unless the client
for validation. If only the signing certificate is present in the sequence. who is validating the signature is expected to have easy access to all the
there are no restrictions on the set of attribute certificates used in certificates required for validation. If only the signing certificate is
validating the signature. present in the sequence, there are no restrictions on the set of
authorization certificates used in validating the signature.
The sequence of policy information terms identifies those certificate The sequence of policy information terms identifies those certificate
policies that the signer asserts apply to the certificate, and under which policies that the signer asserts apply to the certificate, and under which
the certificate should be relied upon. This value suggests a policy value the certificate should be relied upon. This value suggests a policy value
to be used in the relying party's certification path validation. to be used in the relying party's certification path validation.
If present, the SigningCertificate attribute MUST be a signed attribute; it If present, the SigningCertificate attribute MUST be a signed attribute; it
MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
Attribute. A SignerInfo MUST NOT include multiple instances of the Attribute. A SignerInfo MUST NOT include multiple instances of the
SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A attributes to include attrValues SET OF AttributeValue. A
SigningCertificate attribute MUST include only a single instance of SigningCertificate attribute MUST include only a single instance of
AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
5.4.1 Certificate Identification 5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue. CMS has The best way to identify certificates is an often-discussed issue. [CERT]
imposed a restriction for SignedData objects that the issuer DN must be has imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. The issuer/serial number pair is present in all signing certificates. The issuer/serial number pair is
therefore sufficient to identify the correct signing certificate. This therefore sufficient to identify the correct signing certificate. This
information is already present, as part of the SignerInfo object, and information is already present, as part of the SignerInfo object, and
duplication of this information would be unfortunate. A hash of the entire duplication of this information would be unfortunate. A hash of the entire
certificate serves the same function (allowing the receiver to verify that certificate serves the same function (allowing the receiver to verify that
the same certificate is being used as when the message was signed), is the same certificate is being used as when the message was signed), is
smaller, and permits a detection of the simple substitution attacks. smaller, and permits a detection of the simple substitution attacks.
Attribute certificates do not have an issuer/serial number pair represented Attribute certificates do not have an issuer/serial number pair represented
anywhere in a SignerInfo object. When an attribute certificate is not anywhere in a SignerInfo object. When an attribute certificate is not
skipping to change at line 2052 skipping to change at line 2079
information. information.
When encoding IssuerSerial, serialNumber is the serial number that uniquely When encoding IssuerSerial, serialNumber is the serial number that uniquely
identifies the certificate. For non-attribute certificates, the issuer MUST identifies the certificate. For non-attribute certificates, the issuer MUST
contain only the issuer name from the certificate encoded in the contain only the issuer name from the certificate encoded in the
directoryName choice of GeneralNames. For attribute certificates, the directoryName choice of GeneralNames. For attribute certificates, the
issuer MUST contain the issuer name field from the attribute certificate. issuer MUST contain the issuer name field from the attribute certificate.
6. Security Considerations 6. Security Considerations
This entire document discusses security. All security considerations from [CMS] and [SMIME3] apply to applications
that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not send
back a reply if it cannot validate the signature. Similarly, if there
conflicting receipt requests in a message, the recipient must not send back
receipts, since an attacker may have inserted the conflicting request.
Sending a signed receipt to an unvalidated sender can expose information
about the recipient that it may not want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to prevent a
passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a
security label to a message will prevent recipients from viewing messages
the sender doesn't want them to view. It is expected that there will be
many S/MIME clients that will not understand security labels but will still
display a labelled message to a recipient.
A receiving agent that processes security labels must handle the content of
the messages carefully. If the agent decides not to show the message to the
intended recipient after processing the security label, the agent must take
care that the recipient does not accidentally see the content at a later
time. For example, if an error response sent to the originator contains the
content that was hidden from the recipient, and that error response bounces
back to the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message will
have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to an
attacker if that attacker has a signature that can be validated by the
recipient. The attack consists of intercepting the original message and
adding a mLData attribute that says that a receipt should be sent to the
attacker in addition to whoever else was going to get the receipt.
Mailing lists that encrypt their content may be targets for
denial-of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite
easy to subscribe one encrypted mailing list to another, thereby setting up
an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles for
the the adaptive chosen ciphertext attack described in [CMS]. MLAs should
notify an administrator if a large number of undecryptable messages are
received.
When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously
known to be valid, or certificates that have come from a signed
SigningCertificate attribute. Otherwise, the attacks described in Section 5
can cause the receiver to possibly think a signature is valid when it is
not.
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
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
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)}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax -- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1) PolicyInformation FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)} mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- X.509 -- X.509
skipping to change at line 2121 skipping to change at line 2200
-- formerly "allOrNone [0]AllOrNone" -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0), allReceipts (0),
firstTierRecipients (1) } firstTierRecipients (1) }
-- Section 2.8 -- Section 2.8
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version ESSVersion,
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}
ESSVersion ::= INTEGER { v1(1) }
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
  contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  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}
skipping to change at line 2179 skipping to change at line 2260
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)),
    utf8String   UTF8String (SIZE (1..MAX)) utf8String UTF8String (SIZE (1..MAX))
} }
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 {
skipping to change at line 2228 skipping to change at line 2309
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE { EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier } subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
skipping to change at line 2315 skipping to change at line 2395
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:
Andrew Farrell Andrew Farrell
Bancroft Scott Bancroft Scott
Bengt Ackzell Bengt Ackzell
Bill Flanigan Bill Flanigan
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
Darren Harter
David Kemp David Kemp
Denis Pinkas Denis Pinkas
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Changes from draft-ietf-smime-ess-09 to draft-ietf-smime-ess-10 D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11
Numerous small clarifications throughout. 1: Added wording about signing certificates (Section 5) to the
introduction.
Changed the [SMIME3] reference to [CERT] and [MSG]. 1.3.4: Added the sentence at the end of the first paragraph.
1: Added paragraph about usefulness of attributes for other 1.3.4: Removed the macValue description because it was removed from CMS.
purposes. Also added reference to [MUSTSHOULD].
1.3.4: Added note about [ESS]. 1.4: Second paragraph, replaced second sentence to indicate that some
attributes might have to be omitted.
2.3: Added explanation at the end of the first paragraph about why 2.1: Added paragraph at the end of this section saying that you shouldn't
you might get more than one receipt request. Also changed "conflict" request that receipts be sent to people who don't have the original
to "are not the same" in the second paragraph. message.
2.9, 3.2: Added parentheses around SIZE declarations. Also in Appendix 2.6: Added paragraph near beginning about accepting more than one signed
A. receipt.
4.2.3.2: Changed step 2 to say that if mlExpansionHistory isn't found, 2.8: Changed Version to ESSVersion and defined it as:
skip to step 4. Also updated the flow chart.
5.4: Filled in the TBD of the id-aa-signingCertificate OID. Also in ESSVersion ::= INTEGER { v1(1) }
Appendix A.
A: Fixed some bugs in the headers caused by typos. 3: Clarified the last paragraph to indicate ranked levels.
4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was
not found, you sign that whole message and stop.
4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]"
5.1: Changed "changing" to "replacing".
5.4: The paragraph beginning "The first certificate..." was changed to
reflect the addition of the SKI to the SignerInfo. The paragraph beginning
"If more than..." was changed to allow authorization certificates that are
not attribute certificates.
5.4.1: Changed "CMS" to "[CERT]" for the reference.
6: Entire section is new.
E. Editor's Address E. 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
(831) 426-9827 (831) 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/