draft-ietf-smime-ess-05.txt   draft-ietf-smime-ess-06.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-05.txt Internet Mail Consortium draft-ietf-smime-ess-06.txt Internet Mail Consortium
April 11, 1998 May 29, 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 view the entire list of current Internet-Drafts, please check To learn the current status of any Internet-Draft, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu Coast).
(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 [MSP4], 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
to be unreadable by an S/MIME version 2 recipient. to be unreadable by an S/MIME version 2 recipient.
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].
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"
message. A triple wrapped message is one that has been signed, then message. A triple wrapped message is one that has been signed, then
encrypted, then signed again. The signers of the inner and outer signatures encrypted, then signed again. The signers of the inner and outer signatures
may be different entities or the same entity. Note that the S/MIME may be different entities or the same entity. Note that the S/MIME
specification does not limit the number of nested encapsulations, so there specification does not limit the number of nested encapsulations, so there
may be more than three wrappings. may be more than three wrappings.
1.1.1 Purpose of Triple Wrapping 1.1.1 Purpose of Triple Wrapping
Not all messages need to be triple wrapped. Triple wrapping is used when a Not all messages need to be triple wrapped. Triple wrapping is used when a
message must be signed, then encrypted, and then have authenticated message must be signed, then encrypted, and then have signed attributes
attributes bound to the encrypted body. Outer attributes may be added or bound to the encrypted body. Outer attributes may be added or removed by
removed by the message originator or intermediate agents, and may be the message originator or intermediate agents, and may be signed by
authenticated by intermediate agents or the final recipient. intermediate agents or the final recipient.
The inside signature is used for content integrity, non-repudiation with The inside signature is used for content integrity, non-repudiation with
proof of origin, and binding attributes (such as a security label) to the proof of origin, and binding attributes (such as a security label) to the
original content. These attributes go from the originator to the recipient, original content. These attributes go from the originator to the recipient,
regardless of the number of intermediate entities such as mail list agents regardless of the number of intermediate entities such as mail list agents
that process the message. The authenticated attributes can be used for that process the message. The signed attributes can be used for access
access control to the inner body. Requests for signed receipts by the control to the inner body. Requests for signed receipts by the originator
originator are carried in the inside signature as well. are carried in the inside signature as well.
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including confidentiality of
the attributes that are carried in the inside signature. the attributes that are carried in the inside signature.
The outside signature provides authentication and integrity for information The outside signature provides authentication and integrity for information
that is processed hop-by-hop, where each hop is an intermediate entity such that is processed hop-by-hop, where each hop is an intermediate entity such
as a mail list agent. The outer signature binds attributes (such as a as a mail list agent. The outer signature binds attributes (such as a
security label) to the encrypted body. These attributes can be used for security label) to the encrypted body. These attributes can be used for
access control and routing decisions. access control and routing decisions.
skipping to change at line 115 skipping to change at line 115
with a contentType of id-signedData. with a contentType of id-signedData.
4. Add an appropriate MIME construct to the signed message from step 3 as 4. Add an appropriate MIME construct to the signed message from step 3 as
defined in [SMIME3]. The resulting message is called the "inside defined in [SMIME3]. The resulting message is called the "inside
signature". signature".
- If you are signing using multipart/signed, the MIME construct added - If you are signing using multipart/signed, the MIME construct added
consists of a Content-type of multipart/signed with parameters, the consists of a Content-type of multipart/signed with parameters, the
boundary, the result of step 2 above, the boundary, a Content-type of boundary, the result of step 2 above, the boundary, a Content-type of
application/pkcs7-signature, optional MIME headers (such as application/pkcs7-signature, optional MIME headers (such as
Content-transfer-encoding and Content-disposition), and a body part that is Content-transfer-encoding and Content-disposition), and a body part that
the result of step 3 above. is the result of step 3 above.
- If you are instead signing using application/pkcs7-mime, the MIME - If you are instead signing using application/pkcs7-mime, the MIME
construct added consists of a Content-type of application/pkcs7-mime with construct added consists of a Content-type of application/pkcs7-mime
parameters, optional MIME headers (such as Content-transfer-encoding and with parameters, optional MIME headers (such as
Content-disposition), and the result of step 3 above. Content-transfer-encoding and Content-disposition), and the result of
step 3 above.
5. Encrypt the result of step 4 as a single block, turning it into an 5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData encryptedContentInfo application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
contentType MUST be id-data. The EnvelopedData structure is encapsulated by contentType MUST be id-data. The EnvelopedData structure is encapsulated by
a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
called the "encrypted body". called the "encrypted body".
6. Add the appropriate MIME headers: a Content-type of 6. Add the appropriate MIME headers: a Content-type of
application/pkcs7-mime with parameters, and optional MIME headers such as application/pkcs7-mime with parameters, and optional MIME headers such as
Content-transfer-encoding and Content-disposition. Content-transfer-encoding and Content-disposition.
skipping to change at line 157 skipping to change at line 158
There is no need to use the multipart/signed format in an inner signature There is no need to use the multipart/signed format in an inner signature
because it is known that the recipient is able to process S/MIME messages because it is known that the recipient is able to process S/MIME messages
(because they decrypted the middle wrapper). A sending agent might choose (because they decrypted the middle wrapper). A sending agent might choose
to use the multipart/signed format in the outer layer so that a non-S/MIME to use the multipart/signed format in the outer layer so that a non-S/MIME
agent could see that the next inner layer is encrypted; however, this is agent could see that the next inner layer is encrypted; however, this is
not of great value, since all it shows the recipient is that the rest of not of great value, since all it shows the recipient is that the rest of
the message is unreadable. Because many sending agents always use the message is unreadable. Because many sending agents always use
multipart/signed structures, all receiving agents MUST be able to interpret multipart/signed structures, all receiving agents MUST be able to interpret
either multipart/signed or application/pkcs7-mime signature structures. either multipart/signed or application/pkcs7-mime signature structures.
The format of a triple wrapped message that uses multipart/signed for The format of a triple wrapped message that uses multipart/signed for both
both signatures is: signatures is:
[step 8] Content-type: multipart/signed; [step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature"; [step 8] protocol="application/pkcs7-signature";
[step 8] boundary=outerboundary [step 8] boundary=outerboundary
[step 8] [step 8]
[step 8] --outerboundary [step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime; ) [step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data ) [step 6] smime-type=enveloped-data )
[step 6] ) [step 6] )
[step 4] Content-type: multipart/signed; | ) [step 4] Content-type: multipart/signed; | )
skipping to change at line 248 skipping to change at line 249
mailing list. mailing list.
Note: the signed receipts and receipt requests described in this draft Note: the signed receipts and receipt requests described in this draft
differ from those described in the work done by the IETF Receipt differ from those described in the work done by the IETF Receipt
Notification Working Group. The output of that Working Group, when Notification Working Group. The output of that Working Group, when
finished, is not expected to work well with triple wrapped messages as finished, is not expected to work well with triple wrapped messages as
described in this document. described in this document.
1.3.2 Security Labels and Triple Wrapping 1.3.2 Security Labels and Triple Wrapping
A security label may be included in the authenticated attributes of any A security label may be included in the signed attributes of any SignedData
SignedData object. A security label attribute may be included in either the object. A security label attribute may be included in either the inner
inner signature, outer signature, or both. signature, outer signature, or both.
The inner security label is used for access control decisions related to The inner security label is used for access control decisions related to
the plaintext original content. The inner signature provides authentication the plaintext original content. The inner signature provides authentication
and cryptographically protects the original signer's security label that is and cryptographically protects the original signer's security label that is
on the inside body. This strategy facilitates the forwarding of messages on the inside body. This strategy facilitates the forwarding of messages
because the original signer's security label is included in the SignedData because the original signer's security label is included in the SignedData
block which can be forwarded to a third party that can verify the inner block which can be forwarded to a third party that can verify the inner
signature which will cover the inner security label. The confidentiality signature which will cover the inner security label. The confidentiality
security service can be applied to the inner security label by encrypting security service can be applied to the inner security label by encrypting
the entire inner SignedData block within an EnvelopedData block. the entire inner SignedData block within an EnvelopedData block.
A security label may also be included in the authenticated attributes of A security label may also be included in the signed attributes of the outer
the outer SignedData block which will include the sensitivities of the SignedData block which will include the sensitivities of the encrypted
encrypted message. The outer security label is used for access control and message. The outer security label is used for access control and routing
routing decisions related to the encrypted message. Note that a security decisions related to the encrypted message. Note that a security label
label attribute can only be used in an authenticatedAttributes block. An attribute can only be used in an signedAttributes block. An
eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned
unauthenticated attributes. attributes.
1.3.3 Secure Mailing Lists and Triple Wrapping 1.3.3 Secure Mailing Lists and Triple Wrapping
Secure mail list message processing depends on the structure of S/MIME Secure mail list message processing depends on the structure of S/MIME
layers present in the message sent to the mail list agent. The agent never layers present in the message sent to the mail list agent. The agent never
changes the data that was hashed to form the inner signature, if such a changes the data that was hashed to form the inner signature, if such a
signature is present. If an outer signature is present, then the agent will signature is present. If an outer signature is present, then the agent will
modify the data that was hashed to form that outer signature. In all cases, modify the data that was hashed to form that outer signature. In all cases,
the agent adds or updates an mlExpansionHistory attribute to document the the agent adds or updates an mlExpansionHistory attribute to document the
agent's processing, and ultimately adds or replaces the outer signature on agent's processing, and ultimately adds or replaces the outer signature on
the message to be distributed. 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
authenticated, while authentication is optional for others. The following signed, while signing is optional for others, and some attributes must not
table summarizes the recommendation of this profile. be signed. The following table summarizes the recommendation of this
profile.
| |Inner or |MUST be | |Inner or |
Attribute |OID |outer |authenticated Attribute |OID |outer |Signed
contentHints |id-aa-contentHint [ESS] |either |no ------------------|-----------------------------|----------|--------
contentIdentifier |id-aa-contentIdentifier [ESS]|either |no contentHints |id-aa-contentHint [ESS] |either |MAY
contentType |id-contentType [CMS] |either |yes contentIdentifier |id-aa-contentIdentifier [ESS]|either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT counterSignature |id-countersignature [CMS] |either |MUST NOT
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |yes eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes messageDigest |id-messageDigest [CMS] |either |MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
signingCertificate|id-ToBeDetermined [CMS] |either |yes receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingTime |id-signingTime [CMS] |either |yes signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |yes smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption- sMIMEEncryption-
KeyPreference |id-ToBeDetermined [MSG] |either |yes KeyPreference |id-TBD [MSG] |either |MUST
CMS defines signedAttrs as a SET OF SignedAttributes and defines
unsignedAttributes as a SET OF UnsignedAttributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory and receiptRequest attribute types. A signerInfo MUST
NOT include multiple instances of any of the attribute types defined in
ESS. Later sections of ESS specify further restrictions that apply to the
receiptRequest, mlExpansionHistory and eSSecurityLabel attribute types.
CMS defines the syntax for the signed and unsigned attributes as
"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
include a single instance of AttributeValue. In other words, there MUST NOT
be zero or multiple instances of AttributeValue present in the attrValues
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
unauthenticated attributes. It MUST NOT be included in the authenticated unsigned attributes. It MUST NOT be included in the signed attributes. The
attributes. only attributes that are allowed in a counterSignature attribute are
counterSignature, messageDigest, signingTime, and signingCertificate.
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.
The macValue attribute 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
skipping to change at line 366 skipping to change at line 388
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.
2.1 Signed Receipt Concepts 2.1 Signed Receipt Concepts
The originator of a message may request a signed receipt from the message's The originator of a message may request a signed receipt from the message's
recipients. The request is indicated by adding a receiptRequest attribute recipients. The request is indicated by adding a receiptRequest attribute
to the authenticatedAttributes field of the SignerInfo object for which the to the signedAttributes field of the SignerInfo object for which the
receipt is requested. The receiving user agent software SHOULD receipt is requested. The receiving user agent software SHOULD
automatically create a signed receipt when requested to do so, and return automatically create a signed receipt when requested to do so, and return
the receipt in accordance with mailing list expansion options, local the receipt in accordance with mailing list expansion options, local
security policies, and configuration options. security policies, and configuration options.
Because receipts involve the interaction of two parties, the terminology Because receipts involve the interaction of two parties, the terminology
can sometimes be confusing. In this section, the "sender" is the agent that can sometimes be confusing. In this section, the "sender" is the agent that
sent the original message that included a request for a receipt. The sent the original message that included a request for a receipt. The
"receiver" is the party that received that message and generated the "receiver" is the party that received that message and generated the
receipt. receipt.
skipping to change at line 409 skipping to change at line 431
syntax for the receipt is given in Section 2.8. syntax for the receipt is given in Section 2.8.
Note that an agent SHOULD remember when it has sent a receipt so that it Note that an agent SHOULD remember when it has sent a receipt so that it
can avoid re-sending a receipt each time it processes the message. can avoid re-sending a receipt each time it processes 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 authenticatedAttributes of receiptRequest attribute can be included in the signedAttributes of a
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
other words, the user agent MUST NOT request a signed receipt for a signed other words, the user agent MUST NOT request a signed receipt for a signed
receipt. receipt.
A sender requests receipts by placing a receiptRequest attribute in the A sender requests receipts by placing a receiptRequest attribute in the
authenticated attributes of a signerInfo as follows: signed attributes of a signerInfo as follows:
1. A receiptRequest data structure is created. 1. A receiptRequest data structure is created.
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.
skipping to change at line 443 skipping to change at line 465
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 5. The completed receiptRequest attribute is placed in the signedAttributes
authenticatedAttributes 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 authenticatedAttributes. Therefore, a single SignerInfo may include signedAttributes. Therefore, a single SignedData
SignedData object may include multiple SignerInfos, each SignerInfo having object may include multiple SignerInfos, each SignerInfo having a
a receiptRequest attribute. For example, an originator can send a signed receiptRequest attribute. For example, an originator can send a signed
message with two SignerInfos, one containing a DSS signature, the other message with two SignerInfos, one containing a DSS signature, the other
containing an RSA signature. containing an RSA signature.
Each recipient SHOULD return only one signed receipt. Each recipient SHOULD return only one signed receipt.
Not all of the SignerInfos need to include receipt requests, but in all of Not all of the SignerInfos need to include receipt requests, but in all of
the SignerInfos that do contain receipt requests, the receipt requests MUST the SignerInfos that do contain receipt requests, the receipt requests MUST
be identical. be identical.
2.2.2 Information Needed to Validate Signed Receipts 2.2.2 Information Needed to Validate Signed Receipts
skipping to change at line 480 skipping to change at line 502
Receipt content containing values included in the original signedData Receipt content containing values included in the original signedData
object. If signed receipts are requested from multiple recipients, then object. If signed receipts are requested from multiple recipients, then
retaining these digest values is a performance enhancement because the retaining these digest values is a performance enhancement because the
sending agent can reuse the saved values when verifying each returned sending agent can reuse the saved values when verifying each returned
signed receipt. signed receipt.
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 signedAttributes field of each of the SignerInfos for which it
which it verifies a signature in the innermost signedData object to verifies a signature in the innermost signedData object to determine if a
determine if a receipt is requested. This may result in the receiving agent receipt is requested. This may result in the receiving agent processing
processing multiple receiptRequest attributes included in a single multiple receiptRequest attributes included in a single SignedData object.
SignedData object.
Before processing a receiptRequest authenticatedAttribute, the receiving Before processing a receiptRequest signedAttribute, the receiving agent
agent MUST verify the signature of the SignerInfo which covers the MUST verify the signature of the SignerInfo which covers the receiptRequest
receiptRequest attribute. A recipient MUST NOT process a receiptRequest attribute. A recipient MUST NOT process a receiptRequest attribute that has
attribute that has not been verified. Because all receiptRequest attributes not been verified. Because all receiptRequest attributes in a SignedData
in a SignedData object must be identical, the receiving application fully object must be identical, the receiving application fully processes (as
processes (as described in the following paragraphs) the first described in the following paragraphs) the first receiptRequest attribute
receiptRequest attribute that it encounters in a SignerInfo that it that it encounters in a SignerInfo that it verifies, and it then ensures
verifies, and it then ensures that all other receiptRequest attributes in that all other receiptRequest attributes in signerInfos that it verifies
signerInfos that it verifies are identical to the first one encountered. If are identical to the first one encountered. If there are verified
there are verified ReceiptRequest attributes which conflict, then the ReceiptRequest attributes which conflict, then the processing software MUST
processing software MUST NOT return any signed receipt. A signed receipt NOT return any signed receipt. A signed receipt SHOULD be returned if any
SHOULD be returned if any signerInfo containing a receiptRequest attribute signerInfo containing a receiptRequest attribute can be validated, even if
can be validated, even if other signerInfos containing the same other signerInfos containing the same receiptRequest attribute cannot be
receiptRequest attribute cannot be validated because they are signed using validated because they are signed using an algorithm not supported by the
an algorithm not supported by the receiving agent. receiving agent.
If a receiptRequest attribute is absent from the authenticated attributes, If a receiptRequest attribute is absent from the signed attributes, then a
then a signed receipt has not been requested from any of the message signed receipt has not been requested from any of the message recipients
recipients and MUST NOT be created. If a receiptRequest attribute is and MUST NOT be created. If a receiptRequest attribute is present in the
present in the authenticated attributes, then a signed receipt has been signed attributes, then a signed receipt has been requested from some or
requested from some or all of the message recipients. Note that in some all of the message recipients. Note that in some cases, a receiving agent
cases, a receiving agent might receive two almost-identical messages, one might receive two almost-identical messages, one with a receipt request and
with a receipt request and the other without one. In this case, the the other without one. In this case, the receiving agent SHOULD send a
receiving agent SHOULD send a signed receipt for the message that requests signed receipt for the message that requests a signed receipt.
a signed receipt.
If a receiptRequest attribute is present in the authenticated attributes, If a receiptRequest attribute is present in the signed attributes, the
the following process SHOULD be used to determine if a message recipient following process SHOULD be used to determine if a message recipient has
has been requested to return a signed receipt. 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
element, a Mail List receipt policy has not been specified and the element, a Mail List receipt policy has not been specified and the
processing software SHOULD examine the receiptRequest attribute value processing software SHOULD examine the receiptRequest attribute value
to determine if a receipt should be created and returned. to determine if a receipt should be created and returned.
skipping to change at line 612 skipping to change at line 632
NO -> 3.2. NO -> 3.2.
3.2. STOP. 3.2. STOP.
2.4 Signed Receipt Creation 2.4 Signed Receipt Creation
A signed receipt is a signedData object encapsulating a Receipt content A signed receipt is a signedData object encapsulating a Receipt content
(also called a "signedData/Receipt"). Signed receipts are created as (also called a "signedData/Receipt"). Signed receipts are created as
follows: follows:
1. The signature of the original signedData signerInfo that includes the 1. The signature of the original signedData signerInfo that includes the
receiptRequest authenticated attribute MUST be successfully verified before receiptRequest signed attribute MUST be successfully verified before
creating the signedData/Receipt. creating the signedData/Receipt.
1.1. The content of the original signedData object is digested as 1.1. The content of the original signedData object is digested as
described in [CMS]. The resulting digest value is then compared with described in [CMS]. The resulting digest value is then compared with
the value of the messageDigest attribute included in the the value of the messageDigest attribute included in the
authenticatedAttributes of the original signedData signerInfo. If these signedAttributes of the original signedData signerInfo. If these digest
digest values are different, then the signature verification process values are different, then the signature verification process fails and
fails and the signedData/Receipt MUST NOT be created. the signedData/Receipt MUST NOT be created.
1.2. The ASN.1 DER encoded authenticatedAttributes (including 1.2. The ASN.1 DER encoded signedAttributes (including messageDigest,
messageDigest, receiptRequest and, possibly, other authenticated receiptRequest and, possibly, other signed attributes) in the original
attributes) in the original signedData signerInfo are digested as signedData signerInfo are digested as described in [CMS]. The resulting
described in [CMS]. The resulting digest value, called msgSigDigest, is digest value, called msgSigDigest, is then used to verify the signature
then used to verify the signature of the original signedData of the original signedData signerInfo. If the signature verification
signerInfo. If the signature verification fails, then the fails, then the signedData/Receipt MUST NOT be created.
signedData/Receipt MUST NOT be created.
2. A Receipt structure is created. 2. A Receipt structure is created.
2.1. The value of the Receipt version field is set to 1. 2.1. The value of the Receipt version field is set to 1.
2.2. The object identifier from the contentType attribute included in 2.2. The object identifier from the contentType attribute included in
the original signedData signerInfo that includes the receiptRequest the original signedData signerInfo that includes the receiptRequest
attribute is copied into the Receipt contentType. attribute is copied into the Receipt contentType.
2.3. The original signedData signerInfo receiptRequest 2.3. The original signedData signerInfo receiptRequest
signedContentIdentifier is copied into the Receipt signedContentIdentifier is copied into the Receipt
signedContentIdentifier. signedContentIdentifier.
2.4. The signature value from the original signedData signerInfo that 2.4. The signature value from the original signedData signerInfo that
includes the receiptRequest attribute is copied into the Receipt includes the receiptRequest attribute is copied into the Receipt
originatorSignatureValue. originatorSignatureValue.
3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1. 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
4. D1 is digested. The resulting digest value is included as the 4. D1 is digested. The resulting digest value is included as the
messageDigest attribute in the authenticatedAttributes of the signerInfo messageDigest attribute in the signedAttributes of the signerInfo which
which will eventually contain the signedData/Receipt signature value. will eventually contain the signedData/Receipt signature value.
5. The digest value (msgSigDigest) calculated in Step 1 to verify the 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
signature of the original signedData signerInfo is included as the signature of the original signedData signerInfo is included as the
msgSigDigest attribute in the authenticatedAttributes of the signerInfo msgSigDigest attribute in the signedAttributes of the signerInfo which will
which will eventually contain the signedData/Receipt signature value. eventually contain the signedData/Receipt signature value.
6. A contentType attribute including the id-ct-receipt object identifier 6. A contentType attribute including the id-ct-receipt object identifier
MUST be created and added to the authenticated attributes of the signerInfo MUST be created and added to the signed attributes of the signerInfo which
which will eventually contain the signedData/Receipt signature value. will eventually contain the signedData/Receipt signature value.
7. A signingTime attribute indicating the time that the signedData/Receipt 7. A signingTime attribute indicating the time that the signedData/Receipt
is signed SHOULD be created and added to the authenticated attributes of is signed SHOULD be created and added to the signed attributes of the
the signerInfo which will eventually contain the signedData/Receipt signerInfo which will eventually contain the signedData/Receipt signature
signature value. Other attributes (except receiptRequest) may be added to value. Other attributes (except receiptRequest) may be added to the
the authenticatedAttributes of the signerInfo. signedAttributes of the signerInfo.
8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested possibly, others) of the signerInfo are ASN.1 DER encoded and digested as
as described in CMS, Section 5.3. The resulting digest value is used to described in CMS, Section 5.3. The resulting digest value is used to
calculate the signature value which is then included in the calculate the signature value which is then included in the
signedData/Receipt signerInfo. signedData/Receipt signerInfo.
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
id-ct-receipt object identifier MUST be included in the signedData id-ct-receipt object identifier MUST be included in the signedData
encapContentInfo eContentType. This results in a single ASN.1 encoded encapContentInfo eContentType. This results in a single ASN.1 encoded
object composed of a signedData including the Receipt content. The Data object composed of a signedData including the Receipt content. The Data
content type MUST NOT be used. The Receipt content MUST NOT be encapsulated content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
in a MIME header or any other header prior to being encoded as part of the in a MIME header or any other header prior to being encoded as part of the
skipping to change at line 692 skipping to change at line 711
10. The signedData/Receipt is then put in an application/pkcs7-mime MIME 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
wrapper with the smime-type parameter set to "signed-receipt". This will wrapper with the smime-type parameter set to "signed-receipt". This will
allow for identification of signed receipts without having to crack the allow for identification of signed receipts without having to crack the
ASN.1 body. The smime-type parameter would still be set as normal in any ASN.1 body. The smime-type parameter would still be set as normal in any
layer wrapped around this message. layer wrapped around this message.
11. If the signedData/Receipt is to be encrypted within an envelopedData 11. If the signedData/Receipt is to be encrypted within an envelopedData
object, then an outer signedData object MUST be created that encapsulates object, then an outer signedData object MUST be created that encapsulates
the envelopedData object, and a contentHints attribute with contentType set the envelopedData object, and a contentHints attribute with contentType set
to the id-ct-receipt object identifier MUST be included in the outer to the id-ct-receipt object identifier MUST be included in the outer
signedData SignerInfo authenticatedAttributes. When a receiving agent signedData SignerInfo signedAttributes. When a receiving agent processes
processes the outer signedData object, the presence of the id-ct-receipt the outer signedData object, the presence of the id-ct-receipt OID in the
OID in the contentHints contentType indicates that a signedData/Receipt is contentHints contentType indicates that a signedData/Receipt is encrypted
encrypted within the envelopedData object encapsulated by the outer within the envelopedData object encapsulated by the outer signedData.
signedData.
All agents that support the generation of ESS signed receipts MUST provide
the ability to send encrypted signed receipts (that is, a
signedData/Receipt encapsulated within an envelopedData). The agent MAY
send an encrypted signed receipt in response to an
envelopedData-encapsulated signedData requesting a signed receipt. It is a
matter of local policy regarding whether or not the signed receipt should
be encrypted. The ESS signed receipt includes the message digest value
calculated for the original signedData object that requested the signed
receipt. If the original signedData object was sent encrypted within an
envelopedData object and the ESS signed receipt is sent unencrypted, then
the message digest value calculated for the original encrypted signedData
object is sent unencrypted. The responder should consider this when
deciding whether or not to encrypt the ESS signed receipt.
2.4.1 MLExpansionHistory Attributes and Receipts 2.4.1 MLExpansionHistory Attributes and Receipts
An MLExpansionHistory attribute MUST NOT be included in the attributes of a An MLExpansionHistory attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content. This SignerInfo in a SignedData object that encapsulates a Receipt content. This
is true because when a SignedData/Receipt is sent to an MLA for is true because when a SignedData/Receipt is sent to an MLA for
distribution, then the MLA must always encapsulate the received distribution, then the MLA must always encapsulate the received
SignedData/Receipt in an outer SignedData in which the MLA will include the SignedData/Receipt in an outer SignedData in which the MLA will include the
MLExpansionHistory attribute. The MLA cannot change the MLExpansionHistory attribute. The MLA cannot change the signedAttributes of
authenticatedAttributes of the received SignedData/Receipt object, so it the received SignedData/Receipt object, so it can't add the
can't add the MLExpansionHistory to the SignedData/Receipt. MLExpansionHistory to the SignedData/Receipt.
2.5 Determining the Recipients of the Signed Receipt 2.5 Determining the Recipients of the Signed Receipt
If a signed receipt was created by the process described in the sections If a signed receipt was created by the process described in the sections
above, then the software MUST use the following process to determine to above, then the software MUST use the following process to determine to
whom the signed receipt should be sent. whom the signed receipt should be sent.
1. The receiptsTo field must be present in the receiptRequest attribute. 1. The receiptsTo field must be present in the receiptRequest attribute.
The software initiates the sequence of recipients with the value(s) of The software initiates the sequence of recipients with the value(s) of
receiptsTo. receiptsTo.
skipping to change at line 753 skipping to change at line 785
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
that requested the signedData/Receipt. that requested the signedData/Receipt.
3.1. If the sender-calculated message signature digest value has been 3.1. If the sender-calculated message signature digest value has been
saved locally by the sender, it must be located and retrieved. saved locally by the sender, it must be located and retrieved.
3.2. If it has not been saved, then it must be re-calculated based on 3.2. If it has not been saved, then it must be re-calculated based on
the original signedData content and authenticatedAttributes as the original signedData content and signedAttributes as described in
described in [CMS]. [CMS].
4. The message signature digest value calculated by the sender is then 4. The message signature digest value calculated by the sender is then
compared with the value of the msgSigDigest authenticatedAttribute included compared with the value of the msgSigDigest signedAttribute included in the
in the signedData/Receipt signerInfo. If these digest values are identical, signedData/Receipt signerInfo. If these digest values are identical, then
then that proves that the message signature digest value calculated by the that proves that the message signature digest value calculated by the
recipient based on the received original signedData object is the same as recipient based on the received original signedData object is the same as
that calculated by the sender. This proves that the recipient received that calculated by the sender. This proves that the recipient received
exactly the same original signedData content and authenticatedAttributes as exactly the same original signedData content and signedAttributes as sent
sent by the sender because that is the only way that the recipient could by the sender because that is the only way that the recipient could have
have calculated the same message signature digest value as calculated by calculated the same message signature digest value as calculated by the
the sender. If the digest values are different, then the signedData/Receipt sender. If the digest values are different, then the signedData/Receipt
signature verification process fails. signature verification process fails.
5. Acquire the digest value calculated by the sender for the Receipt 5. Acquire the digest value calculated by the sender for the Receipt
content constructed by the sender (including the contentType, content constructed by the sender (including the contentType,
signedContentIdentifier, and signature value that were included in the signedContentIdentifier, and signature value that were included in the
original signedData signerInfo that requested the signedData/Receipt). original signedData signerInfo that requested the signedData/Receipt).
5.1. If the sender-calculated Receipt content digest value has been 5.1. If the sender-calculated Receipt content digest value has been
saved locally by the sender, it must be located and retrieved. saved locally by the sender, it must be located and retrieved.
5.2. If it has not been saved, then it must be re-calculated. As 5.2. If it has not been saved, then it must be re-calculated. As
described in section 2.4 above, step 2, create a Receipt structure described in section 2.4 above, step 2, create a Receipt structure
including the contentType, signedContentIdentifier and signature value including the contentType, signedContentIdentifier and signature value
that were included in the original signedData signerInfo that requested that were included in the original signedData signerInfo that requested
the signed receipt. The Receipt structure is then ASN.1 DER encoded to the signed receipt. The Receipt structure is then ASN.1 DER encoded to
produce a data stream which is then digested to produce the Receipt produce a data stream which is then digested to produce the Receipt
content digest value. content digest value.
6. The Receipt content digest value calculated by the sender is then 6. The Receipt content digest value calculated by the sender is then
compared with the value of the messageDigest authenticatedAttribute compared with the value of the messageDigest signedAttribute included in
included in the signedData/Receipt signerInfo. If these digest values are the signedData/Receipt signerInfo. If these digest values are identical,
identical, then that proves that the values included in the Receipt content then that proves that the values included in the Receipt content by the
by the recipient are identical to those that were included in the original recipient are identical to those that were included in the original
signedData signerInfo that requested the signedData/Receipt. This proves signedData signerInfo that requested the signedData/Receipt. This proves
that the recipient received the original signedData signed by the sender, that the recipient received the original signedData signed by the sender,
because that is the only way that the recipient could have obtained the because that is the only way that the recipient could have obtained the
original signedData signerInfo signature value for inclusion in the Receipt original signedData signerInfo signature value for inclusion in the Receipt
content. If the digest values are different, then the signedData/Receipt content. If the digest values are different, then the signedData/Receipt
signature verification process fails. signature verification process fails.
7. The ASN.1 DER encoded authenticatedAttributes of the signedData/Receipt 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
signerInfo are digested as described in [CMS]. signerInfo are digested as described in [CMS].
8. The resulting digest value is then used to verify the signature value 8. The resulting digest value is then used to verify the signature value
included in the signedData/Receipt signerInfo. If the signature included in the signedData/Receipt signerInfo. If the signature
verification is successful, then that proves the integrity of the verification is successful, then that proves the integrity of the
signedData/receipt signerInfo authenticatedAttributes and authenticates the signedData/receipt signerInfo signedAttributes and authenticates the
identity of the signer of the signedData/Receipt signerInfo. Note that the identity of the signer of the signedData/Receipt signerInfo. Note that the
authenticatedAttributes include the recipient-calculated Receipt content signedAttributes include the recipient-calculated Receipt content digest
digest value (messageDigest attribute) and recipient-calculated message value (messageDigest attribute) and recipient-calculated message signature
signature digest value (msgSigDigest attribute). Therefore, the digest value (msgSigDigest attribute). Therefore, the aforementioned
aforementioned comparison of the sender-generated and recipient-generated comparison of the sender-generated and recipient-generated digest values
digest values combined with the successful signedData/Receipt signature combined with the successful signedData/Receipt signature verification
verification proves that the recipient received the exact original proves that the recipient received the exact original signedData content
signedData content and authenticatedAttributes (proven by msgSigDigest and signedAttributes (proven by msgSigDigest attribute) that were signed by
attribute) that were signed by the sender of the original signedData object the sender of the original signedData object (proven by messageDigest
(proven by messageDigest attribute). If the signature verification fails, attribute). If the signature verification fails, then the
then the signedData/Receipt signature verification process fails. signedData/Receipt signature verification process fails.
The signature verification process for each signature algorithm that is The signature verification process for each signature algorithm that is
used in conjunction with the CMS protocol is specific to the algorithm. used in conjunction with the CMS protocol is specific to the algorithm.
These processes are described in documents specific to the algorithms. These processes are described in documents specific to the algorithms.
2.7 Receipt Request Syntax 2.7 Receipt Request Syntax
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
receiptRequest attribute only within the authenticated attributes receiptRequest attribute only within the signed attributes associated with
associated with a signed message. a signed message.
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
skipping to change at line 922 skipping to change at line 954
their environment. 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 signedAttributes.
2.10 Message Signature Digest Attribute 2.10 Message Signature Digest Attribute
The msgSigDigest attribute can only be used in the authenticated attributes The msgSigDigest attribute can only be used in the signed attributes of a
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
authenticatedAttributes included in the original signedData that requested signedAttributes included in the original signedData that requested the
the signed receipt. Only one msgSigDigest attribute can appear in an signed receipt. Only one msgSigDigest attribute can appear in an signed
authenticated 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
The contentReference attribute is a link from one SignedData to another. It
may be used to link a reply to the original message to which it refers, or
to incorporate by reference one SignedData into another. The first
SignedData MUST include a contentIdentifier signed attribute, which SHOULD
be constructed as specified in section 2.7. The second SignedData links to
the first by including a ContentReference signed attribute containing the
content type, content identifier, and signature value from the first
SignedData.
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
3. Security Labels 3. Security Labels
This section describes the syntax to be used for security labels that can This section describes the syntax to be used for security labels that can
optionally be associated with S/MIME encapsulated data. A security label is optionally be associated with S/MIME encapsulated data. A security label is
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
skipping to change at line 958 skipping to change at line 1009
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 are often priority based ("secret", "confidential",
"restricted", and so on) or role-based, describing which kind of people can "restricted", and so on) or role-based, describing which kind of people can
see the information ("patient's health-care team", "medical billing see the information ("patient's health-care team", "medical billing
agents", "unrestricted", and so on). 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 authenticated 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
A sending agent that is using security labels MUST put the security label A sending agent that is using security labels MUST put the security label
attribute in the authenticatedAttributes field of a SignerInfo block. The attribute in the signedAttributes field of a SignerInfo block. The security
security label attribute MUST NOT be included in the unauthenticated label attribute MUST NOT be included in the unsigned attributes. Integrity
attributes. Integrity and authentication security services MUST be applied and authentication security services MUST be applied to the security label,
to the security label, therefore it MUST be included as an authenticated therefore it MUST be included as an signed attribute, if used. This causes
attribute, if used. This causes the security label attribute to be part of the security label attribute to be part of the data that is hashed to form
the data that is hashed to form the SignerInfo signature value. A the SignerInfo signature value. A SignerInfo block MUST NOT have more than
SignerInfo block MUST NOT have more than one security label authenticated one security label signed attribute.
attribute.
When there are multiple SignedData blocks applied to a message, a security When there are multiple SignedData blocks applied to a message, a security
label attribute may be included in either the inner signature, outer label attribute may be included in either the inner signature, outer
signature, or both. A security label authenticated attribute may be signature, or both. A security label signed attribute may be included in a
included in a authenticatedAttributes field within the inner SignedData signedAttributes field within the inner SignedData block. The inner
block. The inner security label will include the sensitivities of the security label will include the sensitivities of the original content and
original content and will be used for access control decisions related to will be used for access control decisions related to the plaintext
the plaintext encapsulated content. The inner signature provides encapsulated content. The inner signature provides authentication of the
authentication of the inner security label and cryptographically protects inner security label and cryptographically protects the original signer's
the original signer's inner security label of the original content. inner security label of the original content.
When the originator signs the plaintext content and authenticated When the originator signs the plaintext content and signed attributes, the
attributes, the inner security label is bound to the plaintext content. An inner security label is bound to the plaintext content. An intermediate
intermediate entity cannot change the inner security label without entity cannot change the inner security label without invalidating the
invalidating the inner signature. The confidentiality security service can inner signature. The confidentiality security service can be applied to the
be applied to the inner security label by encrypting the entire inner inner security label by encrypting the entire inner signedData object
signedData object within an EnvelopedData block. within an EnvelopedData block.
A security label authenticated attribute may also be included in a A security label signed attribute may also be included in a
authenticatedAttributes field within the outer SignedData block. The outer signedAttributes field within the outer SignedData block. The outer
security label will include the sensitivities of the encrypted message and security label will include the sensitivities of the encrypted message and
will be used for access control decisions related to the encrypted message will be used for access control decisions related to the encrypted message
and for routing decisions. The outer signature provides authentication of and for routing decisions. The outer signature provides authentication of
the outer security label (as well as for the encapsulated content which may the outer security label (as well as for the encapsulated content which may
include nested S/MIME messages). include nested S/MIME messages).
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 signedAttributes. Therefore, a single SignedData
SignedData object may include multiple eSSSecurityLabels, each SignerInfo object may include multiple eSSSecurityLabels, each SignerInfo having an
having an eSSSecurityLabel attribute. For example, an originator can send a eSSSecurityLabel attribute. For example, an originator can send a signed
signed message with two SignerInfos, one containing a DSS signature, the message with two SignerInfos, one containing a DSS signature, the other
other containing an RSA signature. If any of the SignerInfos included in a containing an RSA signature. If any of the SignerInfos included in a
SignedData object include an eSSSecurityLabel attribute, then all of the SignedData object include an eSSSecurityLabel attribute, then all of the
SignerInfos in that SignedData object MUST include an eSSSecurityLabel SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical. attribute and the value of each MUST be identical.
3.1.2 Processing Security Labels 3.1.2 Processing Security Labels
Before processing an eSSSecurityLabel authenticatedAttribute, the receiving Before processing an eSSSecurityLabel signedAttribute, the receiving agent
agent MUST verify the signature of the SignerInfo which covers the MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient MUST NOT process an eSSSecurityLabel attribute. A recipient MUST NOT process an
eSSSecurityLabel attribute that has not been verified. eSSSecurityLabel attribute that has not been verified.
A receiving agent MUST process the eSSSecurityLabel attribute, if present, A receiving agent MUST process the eSSSecurityLabel attribute, if present,
in each SignerInfo in the SignedData object for which it verifies the in each SignerInfo in the SignedData object for which it verifies the
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
skipping to change at line 1044 skipping to change at line 1094
processing the message and indicate an error. 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].
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version [0] Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier, 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
skipping to change at line 1067 skipping to change at line 1116
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
utf8String UTF8String SIZE (1..MAX) utf8String UTF8String SIZE (1..MAX)
-- If utf8String is used, 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 {
skipping to change at line 1195 skipping to change at line 1242
3.3.4 Security Categories 3.3.4 Security Categories
If present, the eSSSecurityLabel security-categories provide further If present, the eSSSecurityLabel security-categories provide further
granularity for the sensitivity of the message. The security policy in granularity for the sensitivity of the message. The security policy in
force (identified by the eSSSecurityLabel security-policy-identifier) is force (identified by the eSSSecurityLabel security-policy-identifier) is
used to indicate the syntaxes that are allowed to be present in the used to indicate the syntaxes that are allowed to be present in the
eSSSecurityLabel security-categories. Alternately, the security-categories eSSSecurityLabel security-categories. Alternately, the security-categories
and their values may be defined by bilateral agreement. and their values may be defined by bilateral agreement.
3.4 Equivalent Security Labels
Because organizations are allowed to define their own security policies,
many different security policies will exist. Some organizations may wish to
create equivalencies between their security policies with the security
policies of other organizations. For example, the Acme Company and the
Widget Corporation may reach a bilateral agreement that the "Acme private"
security-classification value is equivalent to the "Widget sensitive"
security-classification value.
Receiving agents will not process an equivalent label in a message if the
agent does not trust the signer of that attribute to specify an equivalent
security policy. Some receiving agents will not process any equivalent
labels at all, and will only process eSSSecurityLabels. All receiving
agents SHOULD recognize equivalent labels even if they do not process them.
3.4.1 Creating Equivalent Labels
The EquivalentLabels signed attribute is defined as:
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
As stated earlier, the ESSSecurityLabel contains the sensitivity values
selected by the original signer of the signedData. If an ESSSecurityLabel
is present in a signerInfo, all signerInfos in the signedData MUST contain
an ESSSecurityLabel and they MUST all be identical. In addition to an
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed
attribute. If present, the equivalentLabels attribute MUST include one or
more security labels that are believed by the signer to be semantically
equivalent to the ESSSecurityLabel attribute included in the same
signerInfo.
All security-policy object identifiers MUST be unique in the set of
ESSSecurityLabel and EquivalentLabels security labels. Before using an
EquivalentLabels attribute, an agent MUST ensure that all security-policy
OIDs are unique in the security label or labels included in the
EquivalentLabels. Once the agent selects the security label (within the
EquivalentLabels) to be used for processing, then the security-policy OID
of the selected EquivalentLabels security label MUST be compared with the
ESSSecurityLabel security-policy OID to ensure that they are unique.
In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabels attribute may still be included. For
example, in the Acme security policy, the absence of an ESSSecurityLabel
could be defined to equate to a security label composed of the Acme
security-policy OID and the "unmarked" security-classification.
Note that equivalentLabels MUST NOT be used to convey security labels that
are semantically different from the ESSSecurityLabel included in the
signerInfos in the signedData. If an entity needs to apply a security label
that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the
ESSSecurityLabel.
If present, the equivalentLabels attribute MUST be an signed attribute; it
MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF
SignedAttribute. A signerInfo MUST NOT include multiple instances of the
equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A equivalentLabels
attribute MUST only include a single instance of AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue.
3.4.2 Processing Equivalent Labels
A receiving agent SHOULD process the ESSSecurityLabel before processing any
EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
the receiving agent, it MUST process that label and MUST ignore all
EquivalentLabels.
When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature on the EquivalentLabels attribute. A receiving agent
MUST NOT act on an EquivalentLabels attribute for which the signature could
not be validated, and MUST NOT act on an EquivalentLabels attribute unless
that attribute is signed by an entity trusted to add or change access
policies. Determining who is allowed to specify equivalence mappings is a
local policy. If a message has more than one EquivalentLabels attribute,
the receiving agent SHOULD process the first one that it reads and
validates.
4. Mail List Management 4. Mail List Management
Sending agents must create recipient-specific data structures for each Sending agents must create recipient-specific data structures for each
recipient of an encrypted message. This process can impair performance for recipient of an encrypted message. This process can impair performance for
messages sent to a large number of recipients. Thus, Mail List Agents messages sent to a large number of recipients. Thus, Mail List Agents
(MLAs) that can take a single message and perform the recipient-specific (MLAs) that can take a single message and perform the recipient-specific
encryption for every recipient are often desired. encryption for every recipient are often desired.
An MLA appears to the message originator as a normal message recipient, but An MLA appears to the message originator as a normal message recipient, but
the MLA acts as a message expansion point for a Mail List (ML). The sender the MLA acts as a message expansion point for a Mail List (ML). The sender
skipping to change at line 1228 skipping to change at line 1359
To prevent mail loops, MLAs use the mlExpansionHistory attribute of the To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
outer signature of a triple wrapped message. The mlExpansionHistory outer signature of a triple wrapped message. The mlExpansionHistory
attribute is essentially a list of every MLA that has processed the attribute is essentially a list of every MLA that has processed the
message. If an MLA sees its own unique entity identifier in the list, it message. If an MLA sees its own unique entity identifier in the list, it
knows that a loop has been formed, and does not send the message to the knows that a loop has been formed, and does not send the message to the
list again. list again.
4.1 Mail List Expansion 4.1 Mail List Expansion
Mail list expansion processing is noted in the value of the Mail list expansion processing is noted in the value of the
mlExpansionHistory attribute, located in the authenticated attributes of mlExpansionHistory attribute, located in the signed attributes of the MLA's
the MLA's SignerInfo block. The MLA creates or updates the authenticated SignerInfo block. The MLA creates or updates the signed mlExpansionHistory
mlExpansionHistory attribute value each time the MLA expands and signs a attribute value each time the MLA expands and signs a message for members
message for members of a mail list. of a mail list.
The MLA MUST add an MLData record containing the MLA's identification The MLA MUST add an MLData record containing the MLA's identification
information, date and time of expansion, and optional receipt policy to the information, date and time of expansion, and optional receipt policy to the
end of the mail list expansion history sequence. If the mlExpansionHistory end of the mail list expansion history sequence. If the mlExpansionHistory
attribute is absent, then the MLA MUST add the attribute and the current attribute is absent, then the MLA MUST add the attribute and the current
expansion becomes the first element of the sequence. If the expansion becomes the first element of the sequence. If the
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. signedAttributes 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 signedAttributes. Therefore, a single SignedData
SignedData object may include multiple SignerInfos, each SignerInfo having a object may include multiple SignerInfos, each SignerInfo having a
mlExpansionHistory attribute. For example, an MLA can send a signed message mlExpansionHistory attribute. For example, an MLA can send a signed message
with two SignerInfos, one containing a DSS signature, the other containing with two SignerInfos, one containing a DSS signature, the other containing
an RSA signature. an RSA signature.
If an MLA creates a SignerInfo that includes an mlExpansionHistory If an MLA creates a SignerInfo that includes an mlExpansionHistory
attribute, then all of the SignerInfos created by the MLA for that attribute, then all of the SignerInfos created by the MLA for that
SignedData object MUST include an mlExpansionHistory attribute, and the SignedData object MUST include an mlExpansionHistory attribute, and the
value of each MUST be identical. Note that other agents might later add value of each MUST be identical. Note that other agents might later add
SignerInfo attributes to the SignedData block, and those additional SignerInfo attributes to the SignedData block, and those additional
SignerInfos might not include mlExpansionHistory attributes. SignerInfos might not include mlExpansionHistory attributes.
A recipient MUST verify the signature of the SignerInfo which covers the A recipient MUST verify the signature of the SignerInfo which covers the
mlExpansionHistory attribute before processing the mlExpansionHistory, and mlExpansionHistory attribute before processing the mlExpansionHistory, and
MUST NOT process the mlExpansionHistory attribute unless the signature over MUST NOT process the mlExpansionHistory attribute unless the signature over
it has been verified. If a SignedData object has more than one SignerInfo it has been verified. If a SignedData object has more than one SignerInfo
that has an mlExpansionHistory attribute, the recipient MUST compare the that has an mlExpansionHistory attribute, the recipient MUST compare the
mlExpansionHistory attributes in all the SignerInfos, and MUST NOT process mlExpansionHistory attributes in all the SignerInfos that it has verified,
the mlExpansionHistory attribute unless every mlExpansionHistory attribute and MUST NOT process the mlExpansionHistory attribute unless every verified
in the SignedData block is identical. If the mlExpansionHistory attributes mlExpansionHistory attribute in the SignedData block is identical. If the
in the signerInfos are not all identical, then the receiving agent MUST mlExpansionHistory attributes in the verified signerInfos are not all
stop processing the message and SHOULD notify the user or MLA administrator identical, then the receiving agent MUST stop processing the message and
of this error condition. In the mlExpansionHistory processing, SignerInfos SHOULD notify the user or MLA administrator of this error condition. In the
that do not have an mlExpansionHistory attribute are ignored. 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 1297 skipping to change at line 1429
4.2 Mail List Agent Processing 4.2 Mail List Agent Processing
The first few paragraphs of this section provide a high-level description The first few paragraphs of this section provide a high-level description
of MLA processing. The rest of the section provides a detailed description of MLA processing. The rest of the section provides a detailed description
of MLA processing. of MLA processing.
MLA message processing depends on the structure of the S/MIME layers in the MLA message processing depends on the structure of the S/MIME layers in the
message sent to the MLA for expansion. In addition to sending triple message sent to the MLA for expansion. In addition to sending triple
wrapped messages to an MLA, an entity can send other types of messages to wrapped messages to an MLA, an entity can send other types of messages to
an MLA, such as: an MLA, such as:
- a single wrapped signedData or envelopedData message - a single wrapped signedData or envelopedData message
- a double wrapped message (such as signed and enveloped, enveloped and - a double wrapped message (such as signed and enveloped, enveloped and
signed, or signed and signed, and so on) signed, or signed and signed, and so on)
- a quadruple-wrapped message (such as if a well-formed triple wrapped - a quadruple-wrapped message (such as if a well-formed triple wrapped
message was sent through a gateway that added an outer SignedData layer) message was sent through a gateway that added an outer SignedData layer)
In all cases, the MLA MUST parse all layers of the received message to In all cases, the MLA MUST parse all layers of the received message to
determine if there are any signedData layers that include an determine if there are any signedData layers that include an
eSSSecurityLabel authenticatedAttribute. This may include decrypting an eSSSecurityLabel signedAttribute. This may include decrypting an
EnvelopedData layer to determine if an encapsulated SignedData layer EnvelopedData layer to determine if an encapsulated SignedData layer
includes an eSSSecurityLabel attribute. The MLA MUST fully process each includes an eSSSecurityLabel attribute. The MLA MUST fully process each
eSSSecurityLabel attribute found in the various signedData layers, eSSSecurityLabel attribute found in the various signedData layers,
including performing access control checks, before distributing the message including performing access control checks, before distributing the message
to the ML members. The details of the access control checks are beyond the to the ML members. The details of the access control checks are beyond the
scope of this document. The MLA MUST verify the signature of the signerInfo scope of this document. The MLA MUST verify the signature of the signerInfo
including the eSSSecurityLabel attribute before using it. including the eSSSecurityLabel attribute before using it.
In all cases, the MLA MUST sign the message to be sent to the ML members in In all cases, the MLA MUST sign the message to be sent to the ML members in
a new "outer" signedData layer. The MLA MUST add or update an a new "outer" signedData layer. The MLA MUST add or update an
mlExpansionHistory attribute in the "outer" signedData that it creates to mlExpansionHistory attribute in the "outer" signedData that it creates to
document MLA processing. If there was an "outer" signedData layer included document MLA processing. If there was an "outer" signedData layer included
in the original message received by the MLA, then the MLA-created "outer" in the original message received by the MLA, then the MLA-created "outer"
signedData layer MUST include each authenticated attribute present in the signedData layer MUST include each signed attribute present in the
original "outer" signedData layer, unless the MLA explicitly replaces an original "outer" signedData layer, unless the MLA explicitly replaces an
attribute (such as signingTime or mlExpansionHistory) with a new value. attribute (such as signingTime or mlExpansionHistory) with a new value.
When an S/MIME message is received by the MLA, the MLA MUST first determine When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer. which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the signature and fully process the signedAttributes in each of the
outer signedData layers (working from the outside in) to determine if any outer signedData layers (working from the outside in) to determine if any
of them either include an mlExpansionHistory attribute or encapsulate an of them either include an mlExpansionHistory attribute or encapsulate an
envelopedData object. envelopedData object.
The MLA's search for the "outer" signedData layer is completed when it The MLA's search for the "outer" signedData layer is completed when it
finds one of the following: finds one of the following:
- the "outer" signedData layer that includes an mlExpansionHistory - the "outer" signedData layer that includes an mlExpansionHistory
attribute or encapsulates an envelopedData object attribute or encapsulates an envelopedData object
- an envelopedData layer - an envelopedData layer
- the original content (that is, a layer that is neither envelopedData nor - the original content (that is, a layer that is neither envelopedData nor
skipping to change at line 1342 skipping to change at line 1473
The MLA's search for the "outer" signedData layer is completed when it The MLA's search for the "outer" signedData layer is completed when it
finds one of the following: finds one of the following:
- the "outer" signedData layer that includes an mlExpansionHistory - the "outer" signedData layer that includes an mlExpansionHistory
attribute or encapsulates an envelopedData object attribute or encapsulates an envelopedData object
- an envelopedData layer - an envelopedData layer
- the original content (that is, a layer that is neither envelopedData nor - the original content (that is, a layer that is neither envelopedData nor
signedData). signedData).
If the MLA finds an "outer" signedData layer, then the MLA MUST perform If the MLA finds an "outer" signedData layer, then the MLA MUST perform
the following steps: the following steps:
1. Strip off all of the signedData layers that encapsulated the "outer" 1. Strip off all of the signedData layers that encapsulated the "outer"
signedData layer signedData layer
2. Strip off the "outer" signedData layer itself (after remembering the 2. Strip off the "outer" signedData layer itself (after remembering the
included authenticatedAttributes) included signedAttributes)
3. Expand the envelopedData (if present) 3. Expand the envelopedData (if present)
4. Sign the message to be sent to the ML members in a new "outer" 4. Sign the message to be sent to the ML members in a new "outer"
signedData layer that includes the authenticatedAttributes (unless signedData layer that includes the signedAttributes (unless explicitly
explicitly replaced) from the original, received "outer" signedData layer. replaced) from the original, received "outer" signedData layer.
If the MLA finds an "outer" signedData layer that includes an If the MLA finds an "outer" signedData layer that includes an
mlExpansionHistory attribute AND the MLA subsequently finds an mlExpansionHistory attribute AND the MLA subsequently finds an
envelopedData layer buried deeper with the layers of the received message, envelopedData layer buried deeper with the layers of the received message,
then the MLA MUST strip off all of the signedData layers down to the then the MLA MUST strip off all of the signedData layers down to the
envelopedData layer (including stripping off the original "outer" envelopedData layer (including stripping off the original "outer"
signedData layer) and MUST sign the expanded envelopedData in a new "outer" signedData layer) and MUST sign the expanded envelopedData in a new "outer"
signedData layer that includes the authenticatedAttributes (unless signedData layer that includes the signedAttributes (unless explicitly
explicitly replaced) from the original, received "outer" signedData layer. replaced) from the original, received "outer" signedData layer.
If the MLA does not find an "outer" signedData layer AND does not find an If the MLA does not find an "outer" signedData layer AND does not find an
envelopedData layer, then the MLA MUST sign the original, received message envelopedData layer, then the MLA MUST sign the original, received message
in a new "outer" signedData layer. If the MLA does not find an "outer" in a new "outer" signedData layer. If the MLA does not find an "outer"
signedData AND does find an envelopedData layer then it MUST expand the signedData AND does find an envelopedData layer then it MUST expand the
envelopedData layer, if present, and sign it in a new "outer" signedData envelopedData layer, if present, and sign it in a new "outer" signedData
layer. layer.
4.2.1 Examples of Rule Processing 4.2.1 Examples of Rule Processing
The following examples help explain the rules above: The following examples help explain the rules above:
1) A message (S1(Original Content)) (where S = SignedData) is sent to the 1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory MLA in which the signedData layer does not include an MLExpansionHistory
attribute. The MLA verifies and fully processes the authenticatedAttributes attribute. The MLA verifies and fully processes the signedAttributes in S1.
in S1. The MLA decides that there is not an original, received "outer" The MLA decides that there is not an original, received "outer" signedData
signedData layer since it finds the original content, but never finds an layer since it finds the original content, but never finds an envelopedData
envelopedData and never finds an mlExpansionHistory attribute. The MLA and never finds an mlExpansionHistory attribute. The MLA calculates a new
calculates a new signedData layer, S2, resulting in the following message signedData layer, S2, resulting in the following message sent to the ML
sent to the ML recipients: (S2(S1(Original Content))). The MLA includes an recipients: (S2(S1(Original Content))). The MLA includes an
mlExpansionHistory attribute in S2. mlExpansionHistory attribute in S2.
2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which
none of the signedData layers includes an MLExpansionHistory attribute. none of the signedData layers includes an MLExpansionHistory attribute. The
The MLA verifies and fully processes the authenticatedAttributes in S3, S2 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The
and S1. The MLA decides that there is not an original, received "outer" MLA decides that there is not an original, received "outer" signedData
signedData layer since it finds the original content, but never finds an layer since it finds the original content, but never finds an envelopedData
envelopedData and never finds an mlExpansionHistory attribute. The MLA and never finds an mlExpansionHistory attribute. The MLA calculates a new
calculates a new signedData layer, S4, resulting in the following message signedData layer, S4, resulting in the following message sent to the ML
sent to the ML recipients: (S4(S3(S2(S1(Original Content))))). The MLA recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an
includes an mlExpansionHistory attribute in S4. mlExpansionHistory attribute in S4.
3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent
to the MLA in which S1 does not include an MLExpansionHistory attribute. to the MLA in which S1 does not include an MLExpansionHistory attribute.
The MLA decides that there is not an original, received "outer" signedData The MLA decides that there is not an original, received "outer" signedData
layer since it finds the E1 as the outer layer. The MLA expands the layer since it finds the E1 as the outer layer. The MLA expands the
recipientInformation in E1. The MLA calculates a new signedData layer, S2, recipientInformation in E1. The MLA calculates a new signedData layer, S2,
resulting in the following message sent to the ML recipients: resulting in the following message sent to the ML recipients:
(S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory
attribute in S2. attribute in S2.
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
includes an MLExpansionHistory attribute. The MLA verifies the signature includes an MLExpansionHistory attribute. The MLA verifies the signature
and fully processes the authenticatedAttributes in S2. The MLA finds the and fully processes the signedAttributes in S2. The MLA finds the
mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
signedData. The MLA remembers the authenticatedAttributes included in S2 signedData. The MLA remembers the signedAttributes included in S2 for later
for later inclusion in the new outer signedData that it applies to the inclusion in the new outer signedData that it applies to the message. The
message. The MLA strips off S2. The MLA then expands the MLA strips off S2. The MLA then expands the recipientInformation in E1
recipientInformation in E1 (this invalidates the signature in S2 which is (this invalidates the signature in S2 which is why it was stripped). The
why it was stripped). The MLA calculates a new signedData layer, S3, MLA calculates a new signedData layer, S3, resulting in the following
resulting in the following message sent to the ML recipients: message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA
(S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from includes in S3 the attributes from S2 (unless it specifically replaces an
S2 (unless it specifically replaces an attribute value) including an updated attribute value) including an updated mlExpansionHistory attribute.
mlExpansionHistory attribute.
5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
none of the signedData layers include an MLExpansionHistory attribute. The none of the signedData layers include an MLExpansionHistory attribute. The
MLA verifies the signature and fully processes the authenticatedAttributes MLA verifies the signature and fully processes the signedAttributes in S3
in S3 and S2. When the MLA encounters E1, then it decides that S2 is the and S2. When the MLA encounters E1, then it decides that S2 is the "outer"
"outer" signedData since S2 encapsulates E1. The MLA remembers the signedData since S2 encapsulates E1. The MLA remembers the signedAttributes
authenticatedAttributes included in S2 for later inclusion in the new outer included in S2 for later inclusion in the new outer signedData that it
signedData that it applies to the message. The MLA strips off S3 and S2. applies to the message. The MLA strips off S3 and S2. The MLA then expands
The MLA then expands the recipientInformation in E1 (this invalidates the the recipientInformation in E1 (this invalidates the signatures in S3 and
signatures in S3 and S2 which is why they were stripped). The MLA calculates S2 which is why they were stripped). The MLA calculates a new signedData
a new signedData layer, S4, resulting in the following message sent to the layer, S4, resulting in the following message sent to the ML recipients:
ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
attributes from S2 (unless it specifically replaces an attribute value) and S2 (unless it specifically replaces an attribute value) and includes a new
includes a new mlExpansionHistory attribute. mlExpansionHistory attribute.
6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA the signature and fully processes the signedAttributes in S3. The MLA finds
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer" the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData. The MLA remembers the authenticatedAttributes included in S3 signedData. The MLA remembers the signedAttributes included in S3 for later
for later inclusion in the new outer signedData that it applies to the inclusion in the new outer signedData that it applies to the message. The
message. The MLA keeps on parsing encapsulated layers because it must MLA keeps on parsing encapsulated layers because it must determine if there
determine if there are any eSSSecurityLabel attributes contained within. are any eSSSecurityLabel attributes contained within. The MLA verifies the
The MLA verifies the signature and fully processes the signature and fully processes the signedAttributes in S2. When the MLA
authenticatedAttributes in S2. When the MLA encounters E1, then it strips encounters E1, then it strips off S3 and S2. The MLA then expands the
off S3 and S2. The MLA then expands the recipientInformation in E1 (this recipientInformation in E1 (this invalidates the signatures in S3 and S2
invalidates the signatures in S3 and S2 which is why they were stripped). which is why they were stripped). The MLA calculates a new signedData
The MLA calculates a new signedData layer, S4, resulting in the following layer, S4, resulting in the following message sent to the ML recipients:
message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
includes in S4 the attributes from S3 (unless it specifically replaces an S3 (unless it specifically replaces an attribute value) including an
attribute value) including an updated mlExpansionHistory attribute. updated mlExpansionHistory attribute.
4.2.3 Processing Choices 4.2.3 Processing Choices
The processing used depends on the type of the outermost layer of the The processing used depends on the type of the outermost layer of the
message. There are three cases for the type of the outermost data: message. There are three cases for the type of the outermost data:
- EnvelopedData - EnvelopedData
- SignedData - SignedData
- data - data
4.2.3.1 Processing for EnvelopedData 4.2.3.1 Processing for EnvelopedData
skipping to change at line 1475 skipping to change at line 1609
block, adding an mlExpansionHistory attribute as described in the "Mail block, adding an mlExpansionHistory attribute as described in the "Mail
List Expansion" section to document the expansion. List Expansion" section to document the expansion.
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.
4.2.3.2 Processing for SignedData 4.2.3.2 Processing for SignedData
MLA processing of multi-layer messages depends on the type of data in each MLA processing of multi-layer messages depends on the type of data in each
of the layers. Step 3 below specifies that different processing will take of the layers. Step 3 below specifies that different processing will take
place depending on the type of CMS message that has been signed. That place depending on the type of CMS message that has been signed. That is,
is, it needs to know the type of data at the next inner layer, which may or it needs to know the type of data at the next inner layer, which may or may
may 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 authenticated 2. If the outermost SignedData layer includes an signed mlExpansionHistory
mlExpansionHistory attribute the MLA checks for an expansion loop as attribute the MLA checks for an expansion loop as described in the
described in the "Detecting Mail List Expansion Loops" section. "Detecting Mail List Expansion Loops" section.
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
SignedData layer associated with the original encrypted message. SignedData layer associated with the original encrypted message.
Proceed to section 3.2 with the result of the expansion. Proceed to section 3.2 with the result of the expansion.
3.2. If the signed data is SignedData, or is the result of expanding an 3.2. If the signed data is SignedData, or is the result of expanding an
EnvelopedData block in step 3.1: EnvelopedData block in step 3.1:
3.2.1. The MLA strips the existing outermost SignedData layer after 3.2.1. The MLA strips the existing outermost SignedData layer after
remembering the value of the mlExpansionHistory and all other remembering the value of the mlExpansionHistory and all other
authenticated 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
authenticated attribute list for the new outermost signedData layer signed attribute list for the new outermost signedData layer which
which MUST include each authenticated attribute present in the MUST include each signed attribute present in the original
original outermost signedData layer, unless the MLA explicitly outermost signedData layer, unless the MLA explicitly replaces one
replaces one or more particular attributes with new value. A or more particular attributes with new value. A special case is the
special case is the mlExpansionHistory attribute. The MLA MUST add mlExpansionHistory attribute. The MLA MUST add an
an mlExpansionHistory authenticated attribute to the outer mlExpansionHistory signed attribute to the outer signedData layer
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
is created with the current ML expansion information as is created with the current ML expansion information as
described in the "Mail List Expansion" section. described in the "Mail List Expansion" section.
skipping to change at line 1559 skipping to change at line 1693
YES -> Check it, then -> 3. YES -> Check it, then -> 3.
NO -> 3. NO -> 3.
3. Check type of data just below outermost 3. Check type of data just below outermost
SignedData. 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 authenticated 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.
NO -> create new mlExpansionHistory value, then -> 4. NO -> create new mlExpansionHistory value, then -> 4.
3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
attribute, then -> 4. attribute, then -> 4.
4. Sign message, deliver it, STOP. 4. Sign message, deliver it, STOP.
4.2.3.3 Processing for data 4.2.3.3 Processing for data
skipping to change at line 1628 skipping to change at line 1762
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] -- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
The receipt policy of the ML can withdraw the originator's request for The receipt policy of the ML can withdraw the originator's request for the
the return of a signed receipt. However, if the originator of the return of a signed receipt. However, if the originator of the message has
message has not requested a signed receipt, the MLA cannot request a not requested a signed receipt, the MLA cannot request a signed receipt. In
signed receipt. the event that a ML's signed receipt policy supersedes the originator's
request for signed receipts, such that the originator will not receive any
signed receipts, then the MLA MAY inform the originator of that fact.
When present, the mlReceiptPolicy specifies a receipt policy that When present, the mlReceiptPolicy specifies a receipt policy that
supersedes the originator's request for signed receipts. The policy supersedes the originator's request for signed receipts. The policy can be
can be one of three possibilities: receipts MUST NOT be returned one of three possibilities: receipts MUST NOT be returned (none); receipts
(none); receipts should be returned to an alternate list of should be returned to an alternate list of recipients, instead of to the
recipients, instead of to the originator (insteadOf); or receipts originator (insteadOf); or receipts should be returned to a list of
should be returned to a list of recipients in addition to the recipients in addition to the originator (inAdditionTo).
originator (inAdditionTo).
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,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
5. Security Considerations 5. Security Considerations
This entire document discusses security. This entire document discusses security.
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};
-- Extended Security Services -- Extended Security Services
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified. -- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their -- Implementations are free to choose an upper bound that suits their
-- environment. -- environment.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
-- Section 2.7 -- Section 2.7
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at line 1735 skipping to change at line 1870
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 2.11
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
-- Section 3.2 -- Section 3.2
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
version [0] Version DEFAULT v1,
security-policy-identifier SecurityPolicyIdentifier, 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
skipping to change at line 1761 skipping to change at line 1905
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
utf8String UTF8String SIZE (1..MAX) utf8String UTF8String SIZE (1..MAX)
-- If utf8String is used, 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 {
skipping to change at line 1792 skipping to change at line 1934
--SecurityCategory ::= SEQUENCE { --SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY, -- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type } -- value [1] ANY DEFINED BY type }
-- --
--SECURITY-CATEGORY MACRO ::= --SECURITY-CATEGORY MACRO ::=
--BEGIN --BEGIN
--TYPE NOTATION ::= type | empty --TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END --END
-- Section 3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
-- Section 4.4 -- Section 4.4
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
skipping to change at line 1857 skipping to change at line 2006
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 Bancroft Scott
Bengt Ackzell Bengt Ackzell
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
David Kemp
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Open Issues D. Open Issues
There are two "to be determined" attributes in 1.3.4. Still need an OID for sMIMEEncryptionKeyPreference in 1.3.4.
E. Changes from draft-ietf-smime-ess-04 to draft-ietf-smime-ess-05
1.2: Added "(eContent is missing)" to step 7 of the first example.
Also added the terminal "--" on the two closing boundaries.
1.3.4: Added two lines to the table: E. Changes from draft-ietf-smime-ess-05 to draft-ietf-smime-ess-06
signingCertificate|id-ToBeDetermined [CMS] |either |yes
sMIMEEncryption-
KeyPreference |id-ToBeDetermined [MSG] |either |yes
1.4: Added this section to discuss cases where gateways insert General: Replaced most instances of "authenticated" with "signed"
signerInfos. because of the change in CMS.
1.5 (old): Removed this section because there is no more criticality. 1.3.4: Changed the last column to be clearer on requirements. Added
information about counterSignature and macValue attributes.
Added the two paragraphs after the table. Also added:
contentReference |id-aa-contentReference [ESS] |either |MUST
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
Removed:
signingCertificate|id-ToBeDetermined [CMS] |either |MUST
so that it will appear in whatever document that defines it.
2.3: Replaced second paragraph, and removed the last sentence from 2.11: Added this section for the ContentReference attribute.
the third paragraph.
2.8: Changed contentDescription to a UTF8String. 2.4: Added the paragraph after step 11.
3.1.2: Added third paragraph. 3.2: Removed the version from ESSSecurityLabel.
3.2: Removed second paragraph (criticality) because it no longer exists in 3.4: Added this section and its subsections for equivalent security labels.
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.3.1: Removed the sentence about SecurityPolicyIdentifier being optional. 4.1: Changed two sentences in last paragraph to make it clear
that one is only looking at the verifyable signerInfos.
4.1: Replaced the last three paragraphs with more definitive wording 4.4: Added a sentence saying that an MLA may tell a sender
about duplicate mlExpansionHistory attributes. that their request for signed receipts has been squashed.
A: Added the definition of UTF8String again to be in alignment with A: Moved the definition of UTF8String down a few lines.
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/