draft-ietf-smime-ess-00.txt   draft-ietf-smime-ess-01.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-00.txt Internet Mail Consortium draft-ietf-smime-ess-01.txt Internet Mail Consortium
November 18, 1997 January 4, 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.
skipping to change at line 41 skipping to change at line 41
Security Protocol [MSP], but are useful in many other environments, Security Protocol [MSP], 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 2 [SMIME2] and The services described here are extensions to S/MIME version 2 [SMIME2] and
S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME
version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number
of the services require mechanisms described in Cryptographic Message of the services require mechanisms described in Cryptographic Message
Syntax [CMS]. Syntax [CMS]. The format of the messages are described in ASN.1:1988
[ASN1-1988] with the modification that BMPString and UniversalString
types from ASN.1:1994 [ASN1-1994] are used in the descriptions.
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
skipping to change at line 63 skipping to change at line 65
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
signed and encrypted message must be signed, then encrypted, and then message must be signed, then encrypted, and then processed by other agents
processed by other agents that have to be authenticated by the final that have to be authenticated by the final recipient (i.e. via an outer
recipient. signature).
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 authenticated attributes can be used for
access control to the inner body. Requests for signed receipts by the access control to the inner body. Requests for signed receipts by the
originator are carried in the inside signature as well. originator are carried in the inside signature as well.
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including confidentiality of
skipping to change at line 217 skipping to change at line 220
contentType either no contentType either no
counterSignature either no counterSignature either no
encapsulatedContentType either no encapsulatedContentType either no
messageDigest either yes messageDigest either yes
mlExpansionHistory outer only yes mlExpansionHistory outer only yes
receiptRequest inner only yes receiptRequest inner only yes
signingTime either yes signingTime either yes
smimeCapabilities either yes smimeCapabilities either yes
securityLabel either yes securityLabel either yes
If a counterSignature attribute is present, then it MUST be included in the
unauthenticated attributes. It MUST NOT be included in the authenticated
attributes.
Note that the inner and outer signatures are for different senders, so that Note that the inner and outer signatures are for different senders, so that
the same attribute in the two signatures could lead to very different the same attribute in the two signatures could lead to very different
consequences. consequences.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
identifier assigned to the message. EncapsulatedContentType is an attribute identifier assigned to the message. EncapsulatedContentType is an attribute
used to carry the content type of the encapsulated content. These used to carry the content type of the encapsulated content. These
attributes are needed in addition to the fields carried in the attributes are needed in addition to the fields carried in the
receiptRequest attribute. receiptRequest attribute.
1.4 Object Identifiers 1.4 Object Identifiers
The object identifiers for many of the objects described in this draft are The object identifiers for many of the objects described in this draft are
found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>. found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>.
When this draft moves to standards track within the IETF, it is intended When this draft moves to standards track within the IETF, it is intended
that the IANA will maintain this registry. that the IANA will maintain this registry.
2. Signed Receipts 2. Signed Receipts
Returning a signed receipt provides proof of delivery to the originator of Returning a signed receipt provides to the originator proof of delivery of
a message and allows the originator to demonstrate to a third party that a message, and allows the originator to demonstrate to a third party that
the recipient received the message. This receipt is bound to the original the recipient was able to verify the signature of the original message.
message through the signature; consequently, this service may be requested This receipt is bound to the original message through the signature;
only if a message is signed. The receipt sender may optionally also encrypt consequently, this service may be requested only if a message is signed.
a receipt to provide confidentiality between the receipt sender and the The receipt sender may optionally also encrypt a receipt to provide
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 authenticatedAttributes 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.
skipping to change at line 277 skipping to change at line 284
3. Recipient receives message and determines if there is a valid signature 3. Recipient receives message and determines if there is a valid signature
and receipt request in the message (Section 2.3). and receipt request in the message (Section 2.3).
4. Recipient creates a signed receipt (Section 2.4). 4. Recipient creates a signed receipt (Section 2.4).
5. Recipient transmits the resulting signed receipt message to the sender 5. Recipient transmits the resulting signed receipt message to the sender
(Section 2.5). (Section 2.5).
6. Sender receives the message and validates that it contains a signed 6. Sender receives the message and validates that it contains a signed
receipt for the original message (Section 2.6). This validation relies on receipt for the original message (Section 2.6). This validation relies on
the sender having kept a digest value of the original message (Section 2.7) the sender having retained either a copy of the original message or
or a copy of the original message. information extracted from the original message.
The ASN.1 syntax for the receipt request is given in Section 2.8; the ASN.1 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
syntax for the receipt is given in Section 2.9. 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 authenticatedAttributes of
a SignerInfo. A sender requests receipts by placing a receiptRequest a SignerInfo.
attribute in the authenticated attributes of a signerInfo as follows:
A ReceiptRequest attribute MUST NOT be included in the attributes of a
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
receipt.
A sender requests receipts by placing a receiptRequest attribute in the
authenticated attributes of a signerInfo as follows:
1. A receiptRequest data structure is created. 1. A receiptRequest data structure is created.
2. The encapsulated content type is optionally noted in the 2. The encapsulated content type is optionally noted in the
encapsulatedContentType field. encapsulatedContentType field.
3. A signed content identifier for the message is created and assigned to 3. 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.
skipping to change at line 329 skipping to change at line 343
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having SignedData object may include multiple SignerInfos, each SignerInfo having
a receiptRequest attribute. For example, an originator can send a signed a 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 conatin 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
The sending agent MUST retain one or both of the following items to support
the validation of signed receipts returned by the recipients.
- the original signedData object requesting the signed receipt
- the message signature digest value used to generate the original
signedData signerInfo signature value and the digest value of the
Receipt content containing values included in the original signedData
object. If signed receipts are requested from multiple recipients, then
retaining these digest values is a performance enhancement because the
sending agent can reuse the saved values when verifying each returned
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 authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to which it verifies a signature in the innermost signedData object to
determine if a receipt is requested. This may result in the receiving agent determine if a receipt is requested. This may result in the receiving agent
processing multiple receiptRequest attributes included in a single processing multiple receiptRequest attributes included in a single
SignedData object. Because all receiptRequest attributes in a SignedData SignedData object. Because all receiptRequest attributes in a SignedData
object must be identical, the receiving application fully processes (as object must be identical, the receiving application fully processes (as
skipping to change at line 353 skipping to change at line 382
encounters in a SignerInfo that it can verify, and it then ensures that all encounters in a SignerInfo that it can verify, and it then ensures that all
other receiptRequests are identical to the first one encountered. other receiptRequests are identical to the first one encountered.
If a receiptRequest attribute is absent from the authenticated attributes, If a receiptRequest attribute is absent from the authenticated attributes,
then a signed receipt has not been requested from any of the message then a signed receipt has not been requested from any of the message
recipients and MUST NOT be created. If a receiptRequest attribute is recipients and MUST NOT be created. If a receiptRequest attribute is
present in the authenticated attributes, then a signed receipt has been present in the authenticated attributes, then a signed receipt has been
requested from some or all of the message recipients. Note that in some requested from some or all of the message recipients. Note that in some
cases, a receiving agent might receive two almost-identical messages, one cases, a receiving agent might receive two almost-identical messages, one
with a receipt request and the other without one. In this case, the with a receipt request and the other without one. In this case, the
receiving agent may choose whether or not to send a receipt. receiving agent SHOULD send a signed receipt for the message that requests
a signed receipt.
If a receiptRequest attribute is present in the authenticated attributes, If a receiptRequest attribute is present in the authenticated attributes,
the following process SHOULD be used to determine if a message recipient the following process SHOULD be used to determine if a message recipient
has been requested to return a signed receipt. has been requested to return a signed receipt.
1. If an mlExpansionHistory attribute is present in the outermost 1. If an mlExpansionHistory attribute is present in the outermost
signedData block, do one of the following two steps, based on the absence signedData block, do one of the following two steps, based on the absence
or presence of mlReceiptPolicy: or presence of mlReceiptPolicy:
1.1. If an mlReceiptPolicy value is absent from the last MLData 1.1. If an mlReceiptPolicy value is absent from the last MLData
skipping to change at line 386 skipping to change at line 416
be created. be created.
1.2.2. If the mlReceiptPolicy value is insteadOf or 1.2.2. If the mlReceiptPolicy value is insteadOf or
inAdditionTo, the processing software SHOULD examine the inAdditionTo, the processing software SHOULD examine the
receiptsFrom value from the receiptRequest attribute to receiptsFrom value from the receiptRequest attribute to
determine if a receipt should be created and returned. If a determine if a receipt should be created and returned. If a
receipt is created, the insteadOf and inAdditionTo fields receipt is created, the insteadOf and inAdditionTo fields
identify entities that SHOULD be sent the receipt instead of identify entities that SHOULD be sent the receipt instead of
or in addition to the originator. or in addition to the originator.
2. If the receiptsFrom value of the receiptRequest attribute is allOrNone, 2. If the receiptsFrom value of the receiptRequest attribute is
do one of the following three steps based on the value of allOrNone. allOrFirstTier,
do one of the following two steps based on the value of allOrFirstTier.
2.1. If the value of allOrNone is noReceipt, then a signed
receipt MUST NOT be created.
2.2. If the value of allOrNone is allReceipts, then a signed 2.1. If the value of allOrFirstTier is allReceipts, then a signed
receipt SHOULD be created. receipt SHOULD be created.
2.3. If the value of allOrNone is firstTierRecipients, do one of 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
the following two steps based on the presence of an the following two steps based on the presence of an
mlExpansionHistory attribute: mlExpansionHistory attribute:
2.3.1. If an mlExpansionHistory attribute is present, then 2.2.1. If an mlExpansionHistory attribute is present, then
this recipient is not a first tier recipient and a signed this recipient is not a first tier recipient and a signed
receipt MUST NOT be created. receipt MUST NOT be created.
2.3.2. If an mlExpansionHistory attribute is not present, 2.2.2. If an mlExpansionHistory attribute is not present,
then a signed receipt SHOULD be created. then a signed receipt SHOULD be created.
3. If the receiptsFrom value of the receiptRequest attribute is a 3. If the receiptsFrom value of the receiptRequest attribute is a
receiptList: receiptList:
3.1. If receiptList contains one of the GeneralNames of the 3.1. If receiptList contains one of the GeneralNames of the
recipient, then a signed receipt should be created. recipient, then a signed receipt should be created.
3.2. If receiptList does not contain one of the GeneralNames of 3.2. If receiptList does not contain one of the GeneralNames of
the recipient, then a signed receipt MUST NOT be created. the recipient, then a signed receipt MUST NOT be created.
skipping to change at line 425 skipping to change at line 453
A flow chart for the above steps to be executed for each signerInfo for A flow chart for the above steps to be executed for each signerInfo for
which the receiving agent verifies the signature would be: which the receiving agent verifies the signature would be:
0. Receipt Request attribute present? 0. Receipt Request attribute present?
YES -> 1. YES -> 1.
NO -> STOP NO -> STOP
1. Has mlExpansionHistory? 1. Has mlExpansionHistory?
YES -> 1.1. YES -> 1.1.
NO -> 2. NO -> 2.
1.1. mlReceiptPolicy absent? 1.1. mlReceiptPolicy absent?
YES -> examine receiptRequest, then -> 2. YES -> 2.
NO -> 1.2. NO -> 1.2.
1.2. Pick based on value of mlReceiptPolicy. 1.2. Pick based on value of mlReceiptPolicy.
none -> 1.2.1. none -> 1.2.1.
insteadOf or inAdditionTo -> 1.2.2. insteadOf or inAdditionTo -> 1.2.2.
1.2.1. Use ML's policy, then -> STOP 1.2.1. Use ML's policy, then -> STOP
1.2.2. Examine receiptsFrom for name, determine if a receipt 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
should be created, create it if required, then -> STOP. create it if required, send it to recipients designated by
2. Is value of receiptsFrom allOrNone. mlReceiptPolicy, then -> STOP.
YES -> Pick based on value of allOrNone. 2. Is value of receiptsFrom allOrFirstTier?
noReceipt -> 2.1. YES -> Pick based on value of allOrFirstTier.
allReceipts -> 2.2. allReceipts -> 2.1.
firstTierRecipients -> 2.3. firstTierRecipients -> 2.2.
NO -> 3. NO -> 3.
2.1. STOP. 2.1. Create a receipt, then -> STOP.
2.2. Create a receipt, then -> STOP. 2.2. Has mlExpansionHistory?
2.3. Has mlExpansionHistory? YES -> 2.2.1.
YES -> 2.3.1. NO -> 2.2.2.
NO -> 2.3.2. 2.2.1. STOP.
2.3.1. STOP. 2.2.2. Create a receipt, then -> STOP.
2.3.2. Create a receipt, then -> STOP.
3. Is receiptsFrom value of receiptRequest a receiptList? 3. Is receiptsFrom value of receiptRequest a receiptList?
YES -> 3.1. YES -> 3.1.
NO -> STOP. NO -> STOP.
3.1. Does receiptList contain the recipient? 3.1. Does receiptList contain the recipient?
YES -> Create a receipt, then -> STOP. YES -> Create a receipt, then -> STOP.
NO -> 3.2. NO -> 3.2.
3.2. STOP. 3.2. STOP.
2.4 Receipt Creation 2.4 Signed Receipt Creation
A signed receipt is created as follows: A signed receipt is a signedData object encapsulating a Receipt content
(also called a "signedData/Receipt"). Signed receipts are created as follows:
1. The signature of the original message is validated. A receipt MUST NOT 1. The signature of the original signedData signerInfo that includes the
be created for a message with an invalid signature. receiptRequest authenticated attribute MUST be successfully verified before
creating the signedData/Receipt.
1.1. The ASN.1 DER encoded content of the original signedData object is
digested as described in [CMS]. The resulting digest value is then
compared with the value of the messageDigest attribute included in the
authenticatedAttributes of the original signedData signerInfo. If these
digest values are different, then the signature verification process
fails and the signedData/Receipt MUST NOT be created.
1.2. The ASN.1 DER encoded authenticatedAttributes (including
messageDigest, receiptRequest and, possibly, other authenticated
attributes) in the original signedData signerInfo are digested as
described in [CMS]. The resulting digest value, called msgSigDigest, is
then used to verify the signature of the original signedData
signerInfo. If the signature verification fails, then the
signedData/Receipt MUST NOT be created.
2. A Receipt structure is created. 2. A Receipt structure is created.
2.1. The value of the version field is set to 1. 2.1. The value of the Receipt version field is set to 1.
2.2. The encapsulatedContentType and signedContentIdentifier 2.2. The encapsulatedContentType and signedContentIdentifier
values are copied from the SignerInfo's receiptRequest values are copied from the original signedData signerInfo
attribute to the corresponding fields in the Receipt structure. receiptRequest attribute into the corresponding fields in the
Receipt structure.
2.3. The signatureValue (i.e. digital signature or MAC) from the 2.3. The signature value from the original signedData signerInfo
original message SignerInfo structure is copied to the that includes the receiptRequest attribute is copied into the
originatorSignatureValue field in the receipt structure. originatorSignatureValue field in the Receipt structure.
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 concatenated to the end of the ASN.1 encoded original message 4. D1 is digested. The resulting digest value is included as the
content to produce a data stream, D2. The "ASN.1 encoded original message messageDigest attribute in the authenticatedAttributes of the signerInfo
content" is the data composing the SignedData contentInfo content ANY. For which will eventually contain the signedData/Receipt signature value.
example, if SignedData is being used to sign MIME-encapsulated data, then
the signedData ContentInfo content ANY field will include a Data content
type (i.e. OCTET STRING). In that case, the "ASN.1 encoded original message
content" is the DER encoded value of the Data OCTET STRING. The Data OCTET
STRING tag and length octets are not included in the hashing.
5. D2 is digested to produce a digest value, H2, for the receipt. 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
signature of the original signedData signerInfo is included as the
msgSigDigest attribute in the authenticatedAttributes of the signerInfo
which will eventually contain the signedData/Receipt signature value.
6. The Receipt structure MUST be directly included within a SignedData 6. A contentType attribute including the id-ct-receipt OID MUST be created
structure using H2 as the message digest to be signed. This results in a and added to the authenticated attributes of the signerInfo which will
single ASN.1 encoded object composed of a SignedData including the Receipt eventually contain the signedData/Receipt signature value.
content type. The Receipt MUST NOT be encapsulated in a MIME header or any
other header prior to being encoded as part of the SignedData object.
6.1. A contentHints attribute is created and SHOULD be added to 7. A signingTime attribute indicating the time that the signedData/Receipt
the SignerInfo structure's authenticated attributes. is signed SHOULD be created and added to the authenticated attributes of
the signerInfo which will eventually contain the signedData/Receipt
signature value. Other attributes (except receiptRequest) may be added to
the authenticatedAttributes of the signerInfo.
The signed message that contains the signed receipt SHOULD have a 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
signingTime attribute so that the recipient knows when the receipt was and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
created. as described in CMS, Section 5.3. The resulting digest value is used to
calculate the signature value which is then included in the
signedData/Receipt signerInfo.
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData contentInfo content ANY field. The id-ct-receipt OID MUST be
included in the signedData contentInfo contentType. This results in a
single ASN.1 encoded object composed of a signedData including the Receipt
content. The Data 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 signedData object.
10. If the signedData/Receipt is to be encrypted within an envelopedData
object, then an outer signedData object MUST be created that encapsulates
the envelopedData object, and a contentHints attribute with contentType set
to the id-ct-receipt OID MUST be included in the outer signedData
SignerInfo authenticatedAttributes. When a receiving agent process the
outer signedData object, the presence of the id-ct-receipt OID in the
contentHints contentType indicates that a signedData/Receipt is encrypted
within the envelopedData object encapsulated by the outer signedData.
2.4.1 MLExpansionHistory Attributes and Receipts
An MLExpansionHistory attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content. This
is true because when a SignedData/Receipt is sent to an MLA for
distribution, then the MLA must always encapsulate the received
SignedData/Receipt in an outer SignedData in which the MLA will include the
MLExpansionHistory attribute. The MLA cannot change the
authenticatedAttributes of the received SignedData/Receipt object, so it
can't add the 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. If the receiptsTo is present in the Receipt Request attribute, then the 1. If the receiptsTo is present in the receiptRequest attribute, then the
software initiates the sequence of recipients with the value(s) of software initiates the sequence of recipients with the value(s) of
receiptsTo; otherwise, the software initiates the sequence of recipients receiptsTo; otherwise, the software initiates the sequence of recipients
with the signer (that is, the originator) of the SignerInfo that includes with the signer (that is, the originator) of the SignerInfo that includes
the Receipt Request attribute. the receiptRequest attribute.
2. If the MlExpansionHistory attribute is present in the outer SignedData 2. If the MlExpansionHistory attribute is present in the outer SignedData
block, and the last MLData contains an MLReceiptPolicy value of insteadOf, block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
then the software replaces the sequence of recipients with the value(s) of then the software replaces the sequence of recipients with the value(s) of
insteadOf. insteadOf.
3. If the MlExpansionHistory attribute is present in the outer SignedData 3. If the MlExpansionHistory attribute is present in the outer SignedData
block and the last MLData contains an MLReceiptPolicy value of block and the last MLData contains an MLReceiptPolicy value of
inAdditionTo, then the software adds the value(s) of inAdditionTo to the inAdditionTo, then the software adds the value(s) of inAdditionTo to the
sequence of recipients. sequence of recipients.
2.6 Receipt Validation 2.6. Signed Receipt Validation
A receipt is validated as follows: A signed receipt is communicated as a single ASN.1 encoded object composed
of a signedData object directly including a Receipt content. It is
identified by the presence of the id-ct-receipt OID in the contentInfo
contentType value of the signedData object including the Receipt content.
1. The signed receipt is communicated as a single ASN.1 encoded object A signedData/Receipt is validated as follows:
composed of a SignedData directly including a Receipt content type. ASN.1
decode the signedData object including the Receipt.
2. Retrieve the encapsulatedContentType and signedContentIdentifier values 1. ASN.1 decode the signedData object including the Receipt content.
from the Receipt data structure to identify the message being receipted.
3. Acquire H2 based on the message identification information. 2. Extract the encapsulatedContentType, signedContentIdentifier, and
originatorSignatureValue from the decoded Receipt structure to identify the
original signedData signerInfo that requested the signedData/Receipt.
3.1. If H2 has been saved locally, it must be located and 3. Acquire the message signature digest value calculated by the sender to
retrieved. generate the signature value included in the original signedData signerInfo
that requested the signedData/Receipt.
3.2. If H2 has not been saved, the original message must be 3.1. If the sender-calculated message signature digest value has been
located and H2 must be recreated from the original message and saved locally by the sender, it must be located and retrieved.
related information as described in the "Receipt Digest Value"
section.
4. Obtain the alleged receipt signature value from the receipt's 3.2. If it has not been saved, then it must be re-calculated based on
signatureValue field and validate the signature using the retrieved the original signedData content and authenticatedAttributes as
signature value and H2, the calculated hash value. described in [CMS].
[More is needed here or in an appendix detailing how to do this for each 4. The message signature digest value calculated by the sender is then
kind of signature.] compared with the value of the msgSigDigest authenticatedAttribute included
in the signedData/Receipt signerInfo. If these digest values are identical,
then that proves that the message signature digest value calculated by the
recipient based on the received original signedData object is the same as
that calculated by the sender. This proves that the recipient received
exactly the same original signedData content and authenticatedAttributes as
sent by the sender because that is the only way that the recipient could
have calculated the same message signature digest value as calculated by the
sender. If the digest values are different, then the signedData/Receipt
signature verification process fails.
2.7 Receipt Digest Value 5. Acquire the digest value calculated by the sender for the Receipt
content constructed by the sender (including the encapsulatedContentType,
signedContentIdentifier, and signature value that were included in the
original signedData signerInfo that requested the signedData/Receipt).
The requester of a signed receipt must retain either the message for which 5.1. If the sender-calculated Receipt content digest value has been
a receipt is being requested, or a receipt digest value (hash value) saved locally by the sender, it must be located and retrieved.
derived from the message for later receipt validation. Retaining the digest
value usually requires less local storage than retaining a message because
digest values typically contain fewer bytes than the messages they are
derived from.
Message content and message identity information are used to calculate a 5.2. If it has not been saved, then it must be re-calculated. As
receipt digest value as follows: described in section 2.4 above, step 2, create a Receipt structure
including the encapsulatedContentType, signedContentIdentifier and
signature value that were included in the original signedData
signerInfo that requested 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 content digest value.
1. The encapsulated content type, signed content identifier, and encrypted 6. The Receipt content digest value calculated by the sender is then
digest value (signature value) derived from the message content are copied compared with the value of the messageDigest authenticatedAttribute included
from the SignerInfo including the receiptRequest into a Receipt structure. in the signedData/Receipt signerInfo. If these digest values are identical,
The Receipt structure version field is set to 1. then that proves that the values included in the Receipt content by the
recipient are identical to those that were included in the original
signedData signerInfo that requested the signedData/Receipt. This proves
that the recipient received the original signedData signed by the sender,
because that is the only way that the recipient could have obtained the
original signedData signerInfo signature value for inclusion in the Receipt
content. If the digest values are different, then the signedData/Receipt
signature verification process fails.
2. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1, 7. The ASN.1 DER encoded authenticatedAttributes of the signedData/Receipt
as described in the "Receipt Creation" section. signerInfo are digested as described in [CMS].
3. D1 is concatenated to the end of the ASN.1 encoded original message 8. The resulting digest value is then used to verify the signature value
content to produce a data stream, D2. included in the signedData/Receipt signerInfo. If the signature
verification is successful, then that proves the integrity of the
signedData/receipt signerInfo authenticatedAttributes and authenticates the
identity of the signer of the signedData/Receipt signerInfo. Note that the
authenticatedAttributes include the recipient-calculated Receipt content
digest value (messageDigest attribute) and recipient-calculated message
signature digest value (msgSigDigest attribute). Therefore, the
aforementioned comparison of the sender-generated and recipient-generated
digest values combined with the successful signedData/Receipt signature
verification proves that the recipient received the exact original
signedData content and authenticatedAttributes (proven by msgSigDigest
attribute) that were signed by the sender of the original signedData object
(proven by messageDigest attribute). If the signature verification fails,
then the signedData/Receipt signature verification process fails.
4. D2 is digested to produce a digest value, H2, for the receipt. The signature verification process for each signature algorithm that is
used in conjunction with the CMS protocol is specific to the algorithm.
These processes are described in documents specific to the algorithms.
2.8 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 authenticated attributes
associated with a signed message. associated with a signed message.
receiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
encapsulatedContentType EncapsulatedContentType OPTIONAL, encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) OF GeneralNames OPTIONAL }
OF GeneralNames OPTIONAL }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING
The encapsulatedContentType field identifies the content type of the The encapsulatedContentType field identifies the content type of the
original message. In BuiltinContentType, the values of 0 and 1 have been original message. In BuiltinContentType, the values of 0 and 1 have been
deprecated and SHOULD NOT be used. deprecated and SHOULD NOT be used.
EncapsulatedContentType ::= CHOICE { EncapsulatedContentType ::= CHOICE {
built-in BuiltinContentType, built-in BuiltinContentType,
external ExternalContentType, external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype } externalWithSubtype ExternalContentWithSubtype }
BuiltinContentType ::= [APPLICATION 6] INTEGER { BuiltinContentType ::= [APPLICATION 6] INTEGER {
-- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0), unidentified (0),
external (1), external (1),
interpersonal-messaging-1984 (2), interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22), interpersonal-messaging-1988 (22),
edi-messaging (35), edi-messaging (35),
voice-messaging (40)} (0..ub-built-in-content-type) voice-messaging (40)} (0..ub-built-in-content-type)
ub-built-in-content-type INTEGER ::= 32767 ub-built-in-content-type INTEGER ::= 32767
ExternalContentType ::= OBJECT IDENTIFIER ExternalContentType ::= OBJECT IDENTIFIER
ExternalContentWithSubtype ::= SEQUENCE { ExternalContentWithSubtype ::= SEQUENCE {
external ExternalContentType, external ExternalContentType,
subtype INTEGER } subtype INTEGER }
A signedContentIdentifier MUST be created by the message originator when A signedContentIdentifier MUST be created by the message originator when
creating a receipt request. To ensure global uniqueness, the minimal creating a receipt request. To ensure global uniqueness, the minimal
skipping to change at line 621 skipping to change at line 735
A signedContentIdentifier MUST be created by the message originator when A signedContentIdentifier MUST be created by the message originator when
creating a receipt request. To ensure global uniqueness, the minimal creating a receipt request. To ensure global uniqueness, the minimal
signedContentIdentifier SHOULD contain a concatenation of user-specific signedContentIdentifier SHOULD contain a concatenation of user-specific
identification information (such as a user name or public keying material identification information (such as a user name or public keying material
identification information), a GeneralizedTime string, and a random number. identification information), a GeneralizedTime string, and a random number.
The receiptsFrom field is used by the originator to specify the recipients The receiptsFrom field is used by the originator to specify the recipients
requested to return a signed receipt. A CHOICE is provided to allow requested to return a signed receipt. A CHOICE is provided to allow
specification of: specification of:
- no receipts are requested
- receipts from all recipients are requested - receipts from all recipients are requested
- receipts from first tier (recipients that did not receive the - receipts from first tier (recipients that did not receive the
message as members of a mailing list) recipients are requested message as members of a mailing list) recipients are requested
- receipts from a specific list of recipients are requested - receipts from a specific list of recipients are requested
ReceiptsFrom ::= CHOICE { ReceiptsFrom ::= CHOICE {
allOrNone [0] AllOrNone, allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrNone ::= INTEGER { AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
noReceipt (0), allReceipts (0),
allReceipts (1), firstTierRecipients (1) }
firstTierRecipients (2) }
The receiptsTo field is used by the originator to identify the user(s) to The receiptsTo field is used by the originator to identify the user(s) to
whom the identified recipient should send signed receipts. Use the field whom the identified recipient should send signed receipts. Use the field
only if receipts must be sent to users other than, or in addition to, the only if receipts must be sent to users other than, or in addition to, the
originator. If the receiptsTo field is used to designate recipients in originator. If the receiptsTo field is used to designate recipients in
addition to the originator, then the originator's name(s) MUST be included addition to the originator, then the originator's name(s) MUST be included
in the receiptsTo list. in the receiptsTo list.
2.9 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, receipt. The receipt Receipts are represented using a new content type, Receipt. The Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
Receipt := SEQUENCE { Receipt ::= SEQUENCE {
version Version, version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL, encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier OCTET STRING, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
The version field defines the syntax version number, which is 1 for this The version field defines the syntax version number, which is 1 for this
version of the standard. version of the standard.
The encapsulatedContentType and signedContentIdentifier fields are copied The encapsulatedContentType and signedContentIdentifier fields are copied
from the receiptRequest attribute of the SignerInfo contained within the from the receiptRequest attribute of the SignerInfo contained within the
message being receipted, and are used to link the receipt to the original message being receipted, and are used to link the receipt to the original
signed message. The originatorSignatureValue field contains the signed message. The originatorSignatureValue field contains the
signatureValue copied from the SignerInfo requesting the signed receipt. signatureValue copied from the SignerInfo requesting the signed receipt.
2.10 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
contentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription DirectoryString [ ub-conDesc } OPTIONAL, contentDescription DirectoryString OPTIONAL,
receipt BOOLEAN DEFAULT FALSE } contentType OID }
ub-conDesc INTEGER ::= 128
DirectoryString { INTEGER : maxSize } ::= CHOICE { DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)), teletexString TeletexString (SIZE (1..maxSize)),
printableString PrintableString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)),
bmpString BMPString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..maxSize)),
universalString UniversalString (SIZE (1..maxSize)) } universalString UniversalString (SIZE (1..maxSize)) }
Messages that contain a signed receipt MUST include this attribute with the The contentDescription field may be used to provide information that the
receipt value set to TRUE. The contentDescription field may be used to recipient may use to select protected messages for processing, such as a
provide information that the recipient may use to select protected messages message subject. If this field is set, then the attribute is expected to
for processing, such as a message subject. appear on the signedData object enclosing an encrypted data object and not
on the inner signedData object.
Messages which contain a signed data wrapped around an encrypted data
object, thus masking the inner content type of the message, SHOULD include
a content hint attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion
of the content hints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints
attribute with contentType set to the id-ct-receipt OID MUST be included in
the outer signedData SignerInfo authenticatedAttributes.
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
skipping to change at line 713 skipping to change at line 835
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 authenticated
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 recevied message and determines whether or not the recipinet 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 authenticatedAttributes field of a SignerInfo block. The
security label attribute MUST NOT be included in the unauthenticated security label attribute MUST NOT be included in the unauthenticated
attributes. Integrity and authentication security services MUST be applied attributes. Integrity and authentication security services MUST be applied
to the security label, therefore it MUST be included as an authenticated to the security label, therefore it MUST be included as an authenticated
attribute, if used. This causes the security label attribute to be part of attribute, if used. This causes the security label attribute to be part of
skipping to change at line 759 skipping to change at line 881
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 authenticatedAttributes. Therefore, a single
SignedData object may include multiple security labels, each SignerInfo SignedData object may include multiple security labels, each SignerInfo
having a securityLabel attribute. For example, an originator can send a having a securityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. Not all of the SignerInfos need to other containing an RSA signature. Not all of the SignerInfos need to
include security labels, but in all of the SignerInfos that do conatin include security labels, but in all of the SignerInfos that do contain
security labels, the security labels MUST be identical. security labels, the security labels MUST be identical.
A recipient SHOULD process a securityLabel attribute only if the recipient A recipient SHOULD process a securityLabel attribute only if the recipient
can verify the signature of the SignerInfo which covers the securityLabel can verify the signature of the SignerInfo which covers the securityLabel
attribute. A recipient SHOULD NOT use a security label that the recipient attribute. A recipient SHOULD NOT use a security label that the recipient
cannot authenticate. cannot authenticate.
3.1.2 Processing Security Labels 3.1.2 Processing Security Labels
A receiving agent that processes security labels MUST process the A receiving agent that processes security labels MUST process the
skipping to change at line 793 skipping to change at line 915
securityLabel security-policy-identifier value, it SHOULD stop processing securityLabel security-policy-identifier value, it SHOULD stop processing
the message and indicate an error. the message and indicate an error.
3.2 Syntax of securityLabel 3.2 Syntax of securityLabel
The securityLabel syntax is copied directly from [MTSABS] ASN.1 module. The securityLabel syntax is copied directly from [MTSABS] ASN.1 module.
(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
::=".) Further, the securityLabel syntax is identical to that used in ::=".) Further, the securityLabel syntax is identical to that used in
[MSP4] and [ACP120]. [MSP4] and [ACP120].
securityLabel ::= SET { SecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark PrivacyMark OPTIONAL, privacy-mark PrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER { SecurityClassification ::= INTEGER {
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
skipping to change at line 822 skipping to change at line 944
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER, type [0] OBJECT IDENTIFIER,
value [1] ANY -- defined by type} value [1] ANY -- defined by type
}
-Note: The aforementioned SecurityCategory syntax produces identical --Note: The aforementioned SecurityCategory syntax produces identical
-hex encodings as the following SecurityCategory syntax that is --hex encodings as the following SecurityCategory syntax that is
-documented in the X.411 specification: --documented in the X.411 specification:
- --
-SecurityCategory ::= SEQUENCE { --SecurityCategory ::= SEQUENCE {
- type [0] SECURITY-CATEGORY, -- type [0] SECURITY-CATEGORY,
- value [1] ANY DEFINED BY type } -- value [1] ANY DEFINED BY type }
- --
-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
3.3 Security Label Components 3.3 Security Label Components
This section gives more detail on the the various components of the This section gives more detail on the the various components of the
securityLabel syntax. securityLabel syntax.
3.3.1 Security Policy Identifier 3.3.1 Security Policy Identifier
A security policy is a set of criteria for the provision of security A security policy is a set of criteria for the provision of security
services. The securityLabel security-policy-identifier is used to identify services. The securityLabel security-policy-identifier is used to identify
skipping to change at line 1051 skipping to change at line 1174
security label associated with an encapsulated SignedData object. This may security label associated with an encapsulated SignedData object. This may
include decrypting an EnvelopedData object to determine if an encapsulated include decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a securityLabel attribute. SignedData object includes a securityLabel attribute.
Each MLA that processes the message creates its own mlExpansionHistory and Each MLA that processes the message creates its own mlExpansionHistory and
adds it to the sequence of mlExpansionHistory attributes already in the adds it to the sequence of mlExpansionHistory attributes already in the
message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA
that previously processed the message. Each MLA copies the sequence of that previously processed the message. Each MLA copies the sequence of
mlExpansionHistory attributes created by the MLAs that previously processed mlExpansionHistory attributes created by the MLAs that previously processed
the message into the newly constructed expanded message, and adds its own the message into the newly constructed expanded message, and adds its own
mlExpansionHistory as the last element of the sequence. mlExpansionHistory as the last element of the sequence. Section 4.3
provides more details regarding adding information to an existing
mLExpansionHistory attribute.
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.1 Processing for EnvelopedData 4.2.1 Processing for EnvelopedData
1. The MLA locates its own RecipientInfo and uses the information it 1. The MLA locates its own RecipientInfo and uses the information it
skipping to change at line 1079 skipping to change at line 1204
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.2 Processing for SignedData 4.2.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 PKCS #7 message that has been signed. That place depending on the type of CMS message that has been signed. That
is, it needs to know the type of data at the next inner layer, which may or is, it needs to know the type of data at the next inner layer, which may or
may not be the innermost layer. may 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 authenticated
mlExpansionHistory attribute the MLA checks for an expansion loop as mlExpansionHistory attribute the MLA checks for an expansion loop as
described in the "Detecting Mail List Expansion Loops" section. described in the "Detecting Mail List Expansion Loops" section.
skipping to change at line 1133 skipping to change at line 1258
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.
3.3. If the signed data is not EnvelopedData or SignedData: 3.3. If the signed data is not EnvelopedData or SignedData:
3.3.1. The MLA encapsulates the received signedData object in an 3.3.1. The MLA encapsulates the received signedData object in an
SignedData object, and adds an mlExpansionHistory attribute to the outer SignedData object, and adds an mlExpansionHistory attribute
outer SignedData object containing the current ML expansion to the outer SignedData object containing the current ML expansion
information as described in the "Mail List Expansion" section. information as described in the "Mail List Expansion" section.
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to mail
list members to complete MLA processing. list members to complete MLA processing.
A flow chart for the above steps would be: A flow chart for the above steps would be:
1. Has a valid signature? 1. Has a valid signature?
YES -> 2. YES -> 2.
NO -> STOP. NO -> STOP.
skipping to change at line 1162 skipping to change at line 1287
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 3.2.1. Strip outermost SignedData layer, note value of
mlExpansionHistory, then -> 3.2.2. mlExpansionHistory, 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. Add mlExpansionHistory. Was there an old mlExpansionHistory? 3.2.3. Add mlExpansionHistory. 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. Is the signed data EnvelopedData or SignedData? 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
YES -> 4. attribute, then -> 4.
NO -> Encapsulate in a SignedData layer and add a
mlExpansionHistory attribute.
4. Sign message, deliver it, STOP. 4. Sign message, deliver it, STOP.
4.2.3 Processing for data 4.2.3 Processing for data
1. The MLA encapsulates the message in a SignedData layer, and adds an 1. The MLA encapsulates the message in a SignedData layer, and adds an
mlExpansionHistory attribute containing the current ML expansion mlExpansionHistory attribute containing the current ML expansion
information as described in the "Mail List Expansion" section. information as described in the "Mail List Expansion" section.
2. The MLA signs the new message and delivers the updated message to mail 2. 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.3 Mail List Expansion History Syntax 4.3 Mail List Agent Recipt Policy Processing
If a mailing list (B) is a member of another mailing list (A), list B often
needs to propagate forward the mailing list receipt policy of A. As a
general rule, a mailing list should be conservative in propagating forward
the mailing list receipt policy because the ultimate recipient need only
process the last item in the ML expansion history. The MLA builds the
expansion history to meet this requirement.
The following table describes the outcome of the union of mailing list A's
policy (the rows in the table) and mailing list B's policy (the columns in
the table).
| B's policy
A's policy | none insteadOf inAdditionTo missing
-------------------------------------------------------------------------
none | none none none none
insteadOf | none insteadOf(B) insteadOf(A+B) insteadOf(A)
inAdditionTo | none insteadOf(B) inAdditionTo(A+B) inAditionTo(A)
missing | none insteadOf(B) inAddtionTo(B) missing
The interesting cases are combining insteadOf with inAddtionTo. The rest of
the cases either substitute in B's policy or propagate forward A's policy.
4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
there are more than ub-ml-expansion-hsitory mailing lists in the sequence, there are more than ub-ml-expansion-hsitory mailing lists in the sequence,
the processing agent should return an error. the processing agent should return an error.
MLExpansionHistory ::= SEQUENCE (SIZE (1..ub-ml-expansion-history)) MLExpansionHistory ::= SEQUENCE
OF MLData (SIZE (1..ub-ml-expansion-history)) OF MLData
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has MLData contains the expansion history describing each MLA that has
processed a message. As an MLA distributes a message to members of an ML, processed a message. As an MLA distributes a message to members of an ML,
the MLA records its unique identifier, date and time of expansion, and the MLA records its unique identifier, date and time of expansion, and
receipt policy in an MLData structure. receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, -- From PKCS #7
subjectKeyIdentifier KeyIdentifier }
KeyIdentifier ::= OCTET STRING
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 return of a signed receipt. However, if the originator of the the return of a signed receipt. However, if the originator of the
message has not requested a signed receipt, the MLA cannot request a message has not requested a signed receipt, the MLA cannot request a
signed receipt. signed receipt.
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 one of three possibilities: receipts MUST NOT be returned can be one of three possibilities: receipts MUST NOT be returned
(none); receipts should be returned to an alternate list of (none); receipts should be returned to an alternate list of
recipients, instead of to the originator (insteadOf); or receipts recipients, instead of to the originator (insteadOf); or receipts
should be returned to a list of recipients in addition to the should be returned to a list of recipients in addition to the
originator (inAdditionTo). originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) OF GeneralNames,
OF GeneralNames, inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo)) OF GeneralNames }
inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo))
OF GeneralNames }
ub-insteadOf INTEGER ::= 16 ub-insteadOf INTEGER ::= 16
ub-inAdditionTo INTEGER ::= 16 ub-inAdditionTo INTEGER ::= 16
5. Security Considerations 5. Security Considerations
This entire document discusses security. This entire document discusses security.
A. References A. ASN.1 Module
ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS)
EntityIdentifier, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
-- X.509
GeneralNames FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services
-- Section 2.7
ReceiptRequest ::= SEQUENCE {
encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) OF GeneralNames OPTIONAL }
ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING
EncapsulatedContentType ::= CHOICE {
built-in BuiltinContentType,
external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype }
BuiltinContentType ::= [APPLICATION 6] INTEGER {
-- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0),
external (1),
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22),
edi-messaging (35),
voice-messaging (40)} (0..ub-built-in-content-type)
ub-built-in-content-type INTEGER ::= 32767
ExternalContentType ::= OBJECT IDENTIFIER
ExternalContentWithSubtype ::= SEQUENCE {
external ExternalContentType,
subtype INTEGER }
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
-- Section 2.8
Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
-- Section 2.9
ContentHints ::= SEQUENCE {
contentDescription DirectoryString OPTIONAL,
contentType OID }
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)),
printableString PrintableString (SIZE (1..maxSize)),
bmpString BMPString (SIZE (1..maxSize)),
universalString UniversalString (SIZE (1..maxSize)) }
-- Section 3.2
SecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL,
privacy-mark PrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length))
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
-- Section 4.4
MLExpansionHistory ::= SEQUENCE
(SIZE (1..ub-ml-expansion-history)) OF MLData
ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) OF GeneralNames,
inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo)) OF GeneralNames }
ub-insteadOf INTEGER ::= 16
ub-inAdditionTo INTEGER ::= 16
END -- of ExtendedSecurityServices
B. References
[ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120 [ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120
Communication Security Protocol (CSP) Specification. Communication Security Protocol (CSP) Specification.
[ASN1-1988] Recommendation X.208: Specification of Abstract Syntax Notation
One (ASN.1)
[ASN1-1994] Recommendation X.680: Specification of Abstract Syntax Notation
One (ASN.1)
[CMS] Cryptographic Message Syntax, Internet Draft draft-ietf-smime-cms-xx. [CMS] Cryptographic Message Syntax, Internet Draft draft-ietf-smime-cms-xx.
[MSP4] Secure Data Network System (SDNS) Message Security Protocol (MSP) [MSP4] Secure Data Network System (SDNS) Message Security Protocol (MSP)
4.0, Specification SDN.701, Revision A, 1997-02-06. 4.0, Specification SDN.701, Revision A, 1997-02-06.
[MTSABS] 1988 International Telecommunication Union (ITU) Data [MTSABS] 1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message Transfer System: Communication Networks Message Handling Systems: Message Transfer System:
Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
Recommendation X.411; MTSAbstractService {joint-iso-ccitt mhs-motis(6) Recommendation X.411; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)} mts(3) modules(0) mts-abstract-service(1)}
skipping to change at line 1256 skipping to change at line 1562
draft-hoffman-pkcs-crypt-msg-xx. draft-hoffman-pkcs-crypt-msg-xx.
[SMIME2] "S/MIME Version 2 Message Specification", Internet Draft [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft
draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling", draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling",
Internet Draft draft-dusse-smime-cert-xx. Internet Draft draft-dusse-smime-cert-xx.
[SMIME3] "S/MIME Version 3 Message Specification", Internet Draft [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling", draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
Internet Draft draft-ietf-smime-cert-xx. Internet Draft draft-ietf-smime-cert-xx.
B. Acknowledgements C. Acknowledgements
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:
Bengt Ackzell Bengt Ackzell
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
Jim Schaad Jim Schaad
Phillip Griffin Phillip Griffin
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
C. Open Issues D. Open Issues
There is a desire for a single ASN.1 module that collects all the ASN.1
from the whole document.
There is apparently two ASN.1:1994 types (BMPString and UniversalString) in
the draft, leading to invalid ASN.1.
2.4: Includes hashing the authenticatedAttributes included in the 1.3.4: OIDs for contentIdentifier and encapsulatedContentType attributes
SignerInfo containing the receipt signature value included in the are needed.
SignedData/Receipt. Also state that a SignedData/Receipt is not allowed to
include receiptRequest or MLExpansionHistory attributes.
2.6: Examples are needed. 2.4: An OID for msgSigDigest is needed. It will be an OCTET STRING.
3.2: An OID for the securityLabel attribute is needed. 3.2: An OID for the securityLabel attribute is needed.
5: The security considerations section needs to be fleshed out, including E. Changes from draft-ietf-smime-ess-00 to draft-ietf-smime-ess-01
discussions of what happens if receiving clients don't check things very
well.
D. Changes from Draft -00 to Draft -01
Changed the file name of the draft from "draft-hoffman-smime-ess" to
"draft-ietf-smime-ess".
Made the following capitalization changes throughout:
ContentHints -> contentHints
ReceiptRequest -> receiptRequest
SecurityLabel -> securityLabel
1.1.1: removed last sentence of first paragraph.
1.2: Added to the last paragraph: As defined in [PKCS7-1.5] and [CMS], each
SignedData and EnvelopedData object MUST be encapsulated by a ContentInfo
SEQUENCE.
1.3.1: Changed "A signed receipt may be requested in any signed body part."
to "...any SignedData object."
1.3.2: Changed the beginning of the first sentence from "A security label
in authenticated attributes may also be included in the outer SignedData
block..." to "A security label may also be included in the authenticated
attributes of the outer SignedData block...".
1.3.3: Changed last sentence to "In all cases, the agent adds or updates an
mlExpansionHistory attribute to document the agent's processing, and
ultimately adds or replaces the outer signature on the message to be
distributed."
1.3.4: Changed "SignerInfo" to "SignedData" in the first sentence.
1.3.4: Changed ContentIdentifier to contentIdentifier and
EncapsulatedContentType to encapsulatedContentType to reference the
to-be-defined OIDs. Also alphabatized the table and added:
counterSignature either no
contentType either no
messageDigest either yes
1.4: Added this as a new section. Also, throughout the draft, removed Fixed typos: "recevied" and "recipinet".
definitions of OIDs in this draft that are actually on the OIDs page at
IMC.
2.2: Added to the first paragraph: "Only one receiptRequest attribute can Reformatted a lot of the ASN.1 to conform with CMS.
be included in the authenticatedAttributes of a SignerInfo." Also changed
"signed message" to "SignerInfo" in the last sentence.
2.2.1: This section is new and adds new functionality from the previous 1: Added note about ASN.1 formatting and differences from ASN.1:1988.
draft. It should be read carefully, and additional wordsmithing is
encouraged.
2.3: Made large additions to the first paragraph. In the first bullet, 1.3.4: Added note that counterSignature must be in authenticated attributes
changed "outermost authenticatedAttributes block" to "outermost signedData if present.
block". Also changed the lead-in paragraph to the flow chart. Also fixed
2.3.1 and 2.3.2 in the flow chart to match the text.
2.4: Changed bullet 2.2 to have the values copied from the "SignerInfo's 2: Changed first sentence to be clearer about what a return receipt in ESS
receiptRequest" instead of the "original message's receiptRequest". In means.
bullet 2.3, changed "protectionValue" to "signatureValue".
2.6: Bullet 4, changed "protectionValue" to "signatureValue". 2.1: Simplified second sentence of step 6.
2.7: Changed the first sentence in bullet 1 to read "The encapsulated 2.2: Made it clear that UA must not requrest a signed receipt for a signed
content type, signed content identifier, and encrypted digest value receipt.
(signature value) derived from the message content are copied from the
SignerInfo including the receiptRequest into a Receipt structure." Added
the reference to the receipt creation section in bullet 3.
2.8: Change the definition of signedContentIdentifier from OCTET STRING to 2.2.2: Added this section to specify what a sending agent must have in
ContentIdentifier. order to validate signed receipts.
2.9: Replaced the last paragraph with better wording. 2.3: Made it clear that an MUA should send a signed receipt when requested.
Also changed allOrNone to allOrFirstTier in step 2, and removed old step
2.1, and fixed the flow chart for these changes.
2.10: Changed the defintion of ContentHints to include { ub-conDesc } 2.4: This entire section was replaced so that the chain of digests includes
more authenticated information.
3.1: Changed "signed message" to "signedData object" in the first 2.4.1: Added this section to specify that MLExpansionHistory attributes
paragraph. can't be wrapped around Receipt bodies.
3.1.1: In the first paragraph, changed "SignedData" to "SignerInfo". In the 2.5: Replaced "Receipt Request" with "receiptRequest" in step 1.
third paragraph, changed "signed message" to "signedData object". Also
added long paragraphs at the end of this section describing multiple
SignerInfos and what to do with them; this is new material that should be
carefully scrutinized.
3.1.2: The section "Processing Security Labels" was also called 3.1.1 in 2.6: Replaced this entire section. Also foisted off the signature
the previous draft; renumbered it. Also, changed and added most of the text verification process on the documents for each algorithm.
of the section.
3.2: Added the second sentence of the first paragraph, which was moved from 2.7: This section was folded into the new 2.6. Thus, old 2.8 (Receipt
Appendix A. Also fixed the ub-xxx ASN.1 defintions to include INTEGER. Request Syntax), 2.9 (Receipt Syntax), and 2.10 (Content Hints) were
renumbered to be 2.7 (Receipt Request Syntax), 2.8 (Receipt Syntax), and
2.9 (Content Hints).
4.1: Added to the end of the second paragraph: "Only one MLExpansionHistory 2.8 (old): Changed "receiptRequest ::= SEQUENCE" to "ReceiptRequest ::=
attribute can be included in the authenticatedAttributes of a SignerInfo." SEQUENCE". Also, changed the first componenet of Receipts From to
Also added all the text starting with "There can be multiple....", which allOrFirstTier, and changed that definition. Also removed " - no receipts
describes how to handle multiple SignerInfos and what to do with them. This are requested" from list after defintion.
is new material and should be checked carefully.
4.2: In the first paragraph, changed "signedData block" to "signerInfo 2.10: (old) Added sentences about ContentHints, and changed MUST to SHOULD
block" and added the last two sentences. Added definitions of with an explanation and example. Also, changed "contentHints ::= SEQUENCE"
EntityIdentifier and KeyIdentifier. to "ContentHints ::= SEQUENCE". Also changed the structure of ContentHints
significantly and added more information about the new contentType.
4.2.1: Bullet 1, removed "record". Bullet 3.3.1, fixed the wording to be 3.2: Changed "securityLabel ::= SET" to "SecurityLabel ::= SET".
more accruate.
4.2.3: Removed "digestedData". 4.2.2: Changed "PKCS #7 message" to "CMS message". Also, in bullet 3.3.1,
made it clear that the encapsulation happens as an outer signature. Also
fixed step 3.3 in the flow chart.
A: Updated the reference for [ACP120]. Moved the sentence from [MTSABS] to 4.3: Added this entire section, and renumbered old 4.3 (Mail List Expansion
Section 3.2. History Syntax) to 4.4.
B: Gave John Pawling more direct credit for all his hard work. A: Added this section and renumbered the other appendicies.
E. 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/