draft-ietf-smime-ess-01.txt   draft-ietf-smime-ess-02.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-01.txt Internet Mail Consortium draft-ietf-smime-ess-02.txt Internet Mail Consortium
January 4, 1998 February 16, 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 45 skipping to change at line 44
- 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]. The format of the messages are described in ASN.1:1988 Syntax [CMS]. The format of the messages are described in ASN.1:1988
[ASN1-1988] with the modification that BMPString and UniversalString [ASN1-1988] with the modification that BMPString and UniversalString
types from ASN.1:1994 [ASN1-1994] are used in the descriptions. 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
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple wrapped"
skipping to change at line 93 skipping to change at line 92
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.
1.1.2 Steps for Triple Wrapping 1.1.2 Steps for Triple Wrapping
The steps to create a triple wrapped message are: The steps to create a triple wrapped message are:
1. Start with a message body, called the "original content". 1. Start with a message body, called the "original content".
2. Encapsulate the original content with the appropriate MIME headers. An 2. Encapsulate the original content with the appropriate MIME headers. An
exception to this MIME encapsulation rule is that a signed receipt is not exception to this MIME encapsulation rule is that a signed receipt is not
put in MIME headers. put in MIME headers.
3. Sign the result of step 2 (the MIME headers and the original content), 3. Sign the result of step 2 (the MIME headers and the original content),
turning it into a application/pkcs7-mime body part, and add the appropriate creating a signed messsage that includes MIME headers. The resulting
MIME headers. The application/pkcs7-mime body part is called the "inside message is called the "inside signature".
signature".
4. Encrypt the result of step 3 (the MIME headers and the inside signature) 4. Encrypt the result of step 3 (the MIME headers and the inside signature)
as a single block, turning it into another (larger) application/pkcs7-mime as a single block, turning it into another (larger) application/pkcs7-mime
body part, and add the appropriate MIME headers. The application/pkcs7-mime body part, and add the appropriate MIME headers. The application/pkcs7-mime
body part is called the "encrypted body". body part is called the "encrypted body".
5. Sign the result of step 4 (the MIME headers and the encrypted body) as a 5. Sign the result of step 4 (the MIME headers and the encrypted body) as a
single block, turning it into another (even larger) application/pkcs7-mime single block, turning it into another (even larger) message that includes
body part, and add the appropriate MIME headers. The application/pkcs7-mime MIME headers. This message is called the "outside signature".
body part is called the "outside signature".
6. The result of step 5 (the MIME headers and the outside signature) is the 6. The result of step 5 (the MIME headers and the outside signature) is the
triple wrapped message. triple wrapped message.
1.2 Format of a Triple Wrapped Message 1.2 Format of a Triple Wrapped Message
A triple wrapped message has eight layers of encapsulation. Starting from A triple wrapped message has eleven layers of encapsulation. Starting from
the innermost layer and working outwards, the layers are: the innermost layer and working outwards, the layers are:
Original content ("Hello, world!") Original content ("Hello, world!")
MIME entity MIME entity
ContentInfo: data type ContentInfo: data type
Inner SignedData block Inner SignedData block
MIME entity MIME entity
ContentInfo: data type ContentInfo: data type
EnvelopedData block EnvelopedData block
MIME entity MIME entity
skipping to change at line 167 skipping to change at line 165
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 a A security label may be included in the authenticated attributes of any
SignedData object. A security label attribute may be included in either the SignedData object. A security label attribute may be included in either the
inner signature, outer signature, or both. inner 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
skipping to change at line 183 skipping to change at line 181
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 authenticated attributes of
the outer SignedData block which will include the sensitivities of the the outer SignedData block which will include the sensitivities of the
encrypted message. The outer security label is used for access control and encrypted message. The outer security label is used for access control and
routing decisions related to the encrypted message. Note that a security routing decisions related to the encrypted message. Note that a security
label attribute can only be used in an authenticatedAttributes block. A label attribute can only be used in an authenticatedAttributes block. An
securityLabel attribute MUST NOT be used in an EnvelopedData or eSSSsecurityLabel attribute MUST NOT be used in an EnvelopedData or
unauthenticated attributes. unauthenticated 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
skipping to change at line 218 skipping to change at line 217
contentHints either no contentHints either no
contentIdentifier either no contentIdentifier either no
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 essSecurityLabel either yes
If a counterSignature attribute is present, then it MUST be included in the If a counterSignature attribute is present, then it MUST be included in the
unauthenticated attributes. It MUST NOT be included in the authenticated unauthenticated attributes. It MUST NOT be included in the authenticated
attributes. attributes.
Note that the inner and outer signatures are for different senders, so that Note that the inner and outer signatures are for different senders, so that
the same attribute in the two signatures could lead to very different the same attribute in the two signatures could lead to very different
consequences. consequences.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
identifier assigned to the message. 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.
attributes are needed in addition to the fields carried in the
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
skipping to change at line 364 skipping to change at line 361
signedData signerInfo signature value and the digest value of the signedData signerInfo signature value and the digest value of the
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 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.
object must be identical, the receiving application fully processes (as
described in the following paragraphs) the first receiptRequest that it Because all receiptRequest attributes in a SignedData object must be
encounters in a SignerInfo that it can verify, and it then ensures that all identical, the receiving application fully processes (as described in the
other receiptRequests are identical to the first one encountered. following paragraphs) the first receiptRequest that it encounters in a
SignerInfo that it can verify, and it then ensures that all other
receiptRequests are identical to the first one encountered. If
ReceiptRequests which conflict are present, then the processing software
MUST NOT return any receipt.
If a receiptRequest attribute is absent from the authenticated attributes, If a receiptRequest attribute is absent from the authenticated attributes,
then a signed receipt has not been requested from any of the message then a signed receipt has not been requested from any of the message
recipients and MUST NOT be created. If a receiptRequest attribute is recipients and MUST NOT be created. If a receiptRequest attribute is
present in the authenticated attributes, then a signed receipt has been present in the authenticated attributes, then a signed receipt has been
requested from some or all of the message recipients. Note that in some requested from some or all of the message recipients. Note that in some
cases, a receiving agent might receive two almost-identical messages, one cases, a receiving agent might receive two almost-identical messages, one
with a receipt request and the other without one. In this case, the with a receipt request and the other without one. In this case, the
receiving agent SHOULD send a signed receipt for the message that requests receiving agent SHOULD send a signed receipt for the message that requests
a signed receipt. a signed receipt. A receipt MUST be returned if any signature containing a
receipt request can be validated, even if other signatures containing the
same receipt request cannot be validated.
If a receiptRequest attribute is present in the authenticated attributes, If a receiptRequest attribute is present in the authenticated attributes,
the following process SHOULD be used to determine if a message recipient the following process SHOULD be used to determine if a message recipient
has been requested to return a signed receipt. has been requested to return a signed receipt.
1. If an mlExpansionHistory attribute is present in the outermost 1. If an mlExpansionHistory attribute is present in the outermost
signedData block, do one of the following two steps, based on the absence signedData block, do one of the following two steps, based on the absence
or presence of mlReceiptPolicy: or presence of mlReceiptPolicy:
1.1. If an mlReceiptPolicy value is absent from the last MLData 1.1. If an mlReceiptPolicy value is absent from the last MLData
element, a Mail List receipt policy has not been specified and element, a Mail List receipt policy has not been specified and the
the processing software SHOULD examine the receiptRequest processing software SHOULD examine the receiptRequest attribute value
attribute value to determine if a receipt should be created and to determine if a receipt should be created and returned.
returned.
1.2. If an mlReceiptPolicy value is present in the last MLData 1.2. If an mlReceiptPolicy value is present in the last MLData element,
element, do one of the following two steps, based on the value do one of the following two steps, based on the value of
of mlReceiptPolicy: mlReceiptPolicy:
1.2.1. If the mlReceiptPolicy value is none, then the 1.2.1. If the mlReceiptPolicy value is none, then the receipt
receipt policy of the Mail List supersedes the originator's policy of the Mail List supersedes the originator's request for a
request for a signed receipt and a signed receipt MUST NOT signed receipt and a signed receipt MUST NOT 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,
inAdditionTo, the processing software SHOULD examine the the processing software SHOULD examine the receiptsFrom value from
receiptsFrom value from the receiptRequest attribute to the receiptRequest attribute to determine if a receipt should be
determine if a receipt should be created and returned. If a created and returned. If a receipt is created, the insteadOf and
receipt is created, the insteadOf and inAdditionTo fields inAdditionTo fields identify entities that SHOULD be sent the
identify entities that SHOULD be sent the receipt instead of 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 2. If the receiptsFrom value of the receiptRequest attribute is
allOrFirstTier, allOrFirstTier, do one of the following two steps based on the value of
do one of the following two steps based on the value of allOrFirstTier. allOrFirstTier.
2.1. If the value of allOrFirstTier 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.2. If the value of allOrFirstTier 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
mlExpansionHistory attribute: attribute:
2.2.1. If an mlExpansionHistory attribute is present, then 2.2.1. If an mlExpansionHistory attribute is present, then this
this recipient is not a first tier recipient and a signed recipient is not a first tier recipient and a signed receipt MUST
receipt MUST NOT be created. NOT be created.
2.2.2. If an mlExpansionHistory attribute is not present, 2.2.2. If an mlExpansionHistory attribute is not present, then a
then a signed receipt SHOULD be created. 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,
recipient, then a signed receipt should be created. 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
the recipient, then a signed receipt MUST NOT be created.
recipient, then a signed receipt MUST NOT be created.
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.
skipping to change at line 484 skipping to change at line 486
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 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 follows: (also called a "signedData/Receipt"). Signed receipts are created as
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 authenticated attribute MUST be successfully verified before
creating the signedData/Receipt. creating the signedData/Receipt.
1.1. The ASN.1 DER encoded content of the original signedData object is 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 digested as described in [CMS]. The resulting digest value is then
compared with the value of the messageDigest attribute included in the compared with the value of the messageDigest attribute included in the
authenticatedAttributes of the original signedData signerInfo. If these authenticatedAttributes of the original signedData signerInfo. If these
digest values are different, then the signature verification process digest values are different, then the signature verification process
skipping to change at line 509 skipping to change at line 512
attributes) in the original signedData signerInfo are digested as attributes) in the original signedData signerInfo are digested as
described in [CMS]. The resulting digest value, called msgSigDigest, is described in [CMS]. The resulting digest value, called msgSigDigest, is
then used to verify the signature of the original signedData then used to verify the signature of the original signedData
signerInfo. If the signature verification fails, then the signerInfo. If the signature verification 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 encapsulatedContentType and signedContentIdentifier 2.2. The encapsulatedContentType and signedContentIdentifier values are
values are copied from the original signedData signerInfo copied from the original signedData signerInfo receiptRequest attribute
receiptRequest attribute into the corresponding fields in the into the corresponding fields in the Receipt structure.
Receipt structure.
2.3. The signature value from the original signedData signerInfo 2.3. The signature value from the original signedData signerInfo that
that includes the receiptRequest attribute is copied into the 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 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 authenticatedAttributes of the signerInfo
which will eventually contain the signedData/Receipt signature value. which 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 authenticatedAttributes of the signerInfo
which will eventually contain the signedData/Receipt signature value. which will eventually contain the signedData/Receipt signature value.
6. A contentType attribute including the id-ct-receipt OID MUST be created 6. A contentType attribute including the id-ct-receipt object identifier
and added to the authenticated attributes of the signerInfo which will MUST be created and added to the authenticated attributes of the signerInfo
eventually contain the signedData/Receipt signature value. which 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 authenticated attributes of
the signerInfo which will eventually contain the signedData/Receipt the signerInfo which will eventually contain the signedData/Receipt
signature value. Other attributes (except receiptRequest) may be added to signature value. Other attributes (except receiptRequest) may be added to
the authenticatedAttributes of the signerInfo. the authenticatedAttributes of the signerInfo.
8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
as described in CMS, Section 5.3. The resulting digest value is used to as 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.
skipping to change at line 546 skipping to change at line 549
signature value. Other attributes (except receiptRequest) may be added to signature value. Other attributes (except receiptRequest) may be added to
the authenticatedAttributes of the signerInfo. the authenticatedAttributes of the signerInfo.
8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
as described in CMS, Section 5.3. The resulting digest value is used to as 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 contentInfo content ANY field. The id-ct-receipt OID MUST be the signedData contentInfo content ANY field. The id-ct-receipt object
included in the signedData contentInfo contentType. This results in a identifier MUST be included in the signedData contentInfo contentType. This
single ASN.1 encoded object composed of a signedData including the Receipt results in a single ASN.1 encoded object composed of a signedData including
content. The Data content type MUST NOT be used. The Receipt content MUST the Receipt content. The Data content type MUST NOT be used. The Receipt
NOT be encapsulated in a MIME header or any other header prior to being content MUST NOT be encapsulated in a MIME header or any other header prior
encoded as part of the signedData object. to being encoded as part of the signedData object.
10. If the signedData/Receipt is to be encrypted within an envelopedData 10. 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 OID MUST be included in the outer signedData to the id-ct-receipt object identifier MUST be included in the outer
SignerInfo authenticatedAttributes. When a receiving agent process the signedData SignerInfo authenticatedAttributes. When a receiving agent
outer signedData object, the presence of the id-ct-receipt OID in the processes the outer signedData object, the presence of the id-ct-receipt
contentHints contentType indicates that a signedData/Receipt is encrypted OID in the contentHints contentType indicates that a signedData/Receipt is
within the envelopedData object encapsulated by the outer signedData. encrypted within the envelopedData object encapsulated by the outer
signedData.
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
authenticatedAttributes of the received SignedData/Receipt object, so it authenticatedAttributes of the received SignedData/Receipt object, so it
can't add the MLExpansionHistory to the SignedData/Receipt. 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 receiptRequest attribute, then the 1. The receiptsTo field must be present in the receiptRequest attribute.
software initiates the sequence of recipients with the value(s) of The 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 receiptRequest 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. Signed Receipt Validation 2.6. Signed Receipt Validation
A signed receipt is communicated as a single ASN.1 encoded object composed A signed receipt is communicated as a single ASN.1 encoded object composed
of a signedData object directly including a Receipt content. It is of a signedData object directly including a Receipt content. It is
identified by the presence of the id-ct-receipt OID in the contentInfo identified by the presence of the id-ct-receipt object identifier in the
contentType value of the signedData object including the Receipt content. contentInfo contentType value of the signedData object including the
Receipt content.
A signedData/Receipt is validated as follows: A signedData/Receipt is validated as follows:
1. ASN.1 decode the signedData object including the Receipt content. 1. ASN.1 decode the signedData object including the Receipt content.
2. Extract the encapsulatedContentType, signedContentIdentifier, and 2. Extract the encapsulatedContentType, signedContentIdentifier, and
originatorSignatureValue from the decoded Receipt structure to identify the originatorSignatureValue from the decoded Receipt structure to identify the
original signedData signerInfo that requested the signedData/Receipt. original signedData signerInfo that requested the signedData/Receipt.
3. Acquire the message signature digest value calculated by the sender to 3. Acquire the message signature digest value calculated by the sender to
skipping to change at line 629 skipping to change at line 635
described in [CMS]. described in [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 authenticatedAttribute included
in the signedData/Receipt signerInfo. If these digest values are identical, in the signedData/Receipt signerInfo. If these digest values are identical,
then that proves that the message signature digest value calculated by the then 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 authenticatedAttributes as
sent by the sender because that is the only way that the recipient could 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 have calculated the same message signature digest value as calculated by
sender. If the digest values are different, then the signedData/Receipt the 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 encapsulatedContentType, content constructed by the sender (including the encapsulatedContentType,
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 encapsulatedContentType, signedContentIdentifier and including the encapsulatedContentType, signedContentIdentifier and
signature value that were included in the original signedData signature value that were included in the original signedData
signerInfo that requested the signed receipt. The Receipt structure is signerInfo that requested the signed receipt. The Receipt structure is
then ASN.1 DER encoded to produce a data stream which is then digested then ASN.1 DER encoded to produce a data stream which is then digested
to produce the Receipt content digest value. to produce the Receipt 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 included compared with the value of the messageDigest authenticatedAttribute
in the signedData/Receipt signerInfo. If these digest values are identical, included in the signedData/Receipt signerInfo. If these digest values are
then that proves that the values included in the Receipt content by the identical, then that proves that the values included in the Receipt content
recipient are identical to those that were included in the original by the 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 authenticatedAttributes of the signedData/Receipt
signerInfo are digested as described in [CMS]. signerInfo are digested as described in [CMS].
skipping to change at line 694 skipping to change at line 700
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 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)) OF GeneralNames OPTIONAL } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING 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. Unless the data to be placed in the
encapsulatedContentType field has been profiled to be different in the
present operating environment, the internal content type SHOULD be placed
in the ExternalContentType choice of EncapsulatedContentType.
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 -- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0), unidentified (0),
external (1), external (1),
skipping to change at line 750 skipping to change at line 759
ReceiptsFrom ::= CHOICE { ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier, allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone" -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0), allReceipts (0),
firstTierRecipients (1) } firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to The receiptsTo field is used by the originator to identify the user(s) to
whom the identified recipient should send signed receipts. Use the field whom the identified recipient should send signed receipts. The field is
only if receipts must be sent to users other than, or in addition to, the mandatory, and the originator's name(s) MUST be included in the receiptsTo
originator. If the receiptsTo field is used to designate recipients in list.
addition to the originator, then the originator's name(s) MUST be included
in the receiptsTo list.
2.8 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, Receipt. The Receipt Receipts are represented using a new content type, Receipt. The Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL, encapsulatedContentType EncapsulatedContentType OPTIONAL,
skipping to change at line 780 skipping to change at line 787
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.9 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription DirectoryString OPTIONAL, contentDescription DirectoryString OPTIONAL,
contentType OID } contentType OBJECT IDENTIFIER }
DirectoryString ::= CHOICE { DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)), teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..maxSize)) } universalString UniversalString (SIZE (1..MAX)) }
The construct "SIZE (1..MAX)" is used in the DirectoryString syntax to
constrain each CHOICE to have at least one entry. MAX indicates that the
upper bound is unspecified. Implementations are free to choose an upper
bound that suits their environment.
The contentDescription field may be used to provide information that the The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected to message subject. If this field is set, then the attribute is expected to
appear on the signedData object enclosing an encrypted data object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. on the inner signedData object.
Messages which contain a signed data wrapped around an encrypted data 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 content hint 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 content hints 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 OID MUST be included in attribute with contentType set to the id-ct-receipt object identifier MUST
the outer signedData SignerInfo authenticatedAttributes. 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 878 skipping to change at line 892
authenticatedAttributes field within the outer SignedData block. The outer authenticatedAttributes 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 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 an eSSSecurityLabel 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 contain 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 an eSSSecurityLabel attribute only if the
can verify the signature of the SignerInfo which covers the securityLabel recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use a security label that the recipient eSSSecurityLabel attribute. A recipient SHOULD NOT use a security label
cannot authenticate. that the recipient 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
securityLabel attribute, if present, in each SignerInfo in the SignedData eSSSecurityLabel attribute, if present, in each SignerInfo in the
object for which it verifies the signature. This may result in the SignedData object for which it verifies the signature. This may result in
receiving agent processing multiple security labels included in a single the receiving agent processing multiple security labels included in a
SignedData object. Because all security labels in a SignedData object must single SignedData object. Because all security labels in a SignedData
be identical, the receiving application processes (such as performing object must be identical, the receiving application processes (such as
access control) on the first securityLabel that it encounters in a performing access control) on the first eSSSecurityLabel that it encounters
SignerInfo that it can verify, and then ensures that all other in a SignerInfo that it can verify, and then ensures that all other
securityLabels are identical to the first one encountered. eSSSecurityLabels are identical to the first one encountered.
A receiving agent that processes security labels SHOULD have a local policy A receiving agent that processes security labels SHOULD have a local policy
about whether or not to show the inner content of an incoming messages that about whether or not to show the inner content of an incoming messages that
has a security label with a security policy identifier that the processing has a security label with a security policy identifier that the processing
software does not recognize. If the receiving agent does not recognize the software does not recognize. If the receiving agent does not recognize the
securityLabel security-policy-identifier value, it SHOULD stop processing eSSSecurityLabel security-policy-identifier value, it SHOULD stop
the message and indicate an error. processing the message and indicate an error.
3.2 Syntax of securityLabel 3.2 Syntax of eSSSecurityLabel
The securityLabel syntax is copied 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 securityLabel syntax is identical to that used in ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
[MSP4] and [ACP120]. [MSP4].
SecurityLabel ::= SET { ESSSecurityLabel ::= 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 ESSPrivacyMark 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),
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
PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length)) ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String OCTET STRING
-- If utf8String is used, the contents must be in UTF-8 [UTF8]
}
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,
skipping to change at line 964 skipping to change at line 983
-- --
--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. eSSSecurityLabel syntax.
3.3.1 Security Policy Identifier 3.3.1 Security Policy Identifier
A security policy is a set of criteria for the provision of security A security policy is a set of criteria for the provision of security
services. The securityLabel security-policy-identifier is used to identify services. The eSSSecurityLabel security-policy-identifier is used to
the security policy in force to which the security label relates. It identify the security policy in force to which the security label relates.
indicates the semantics of the other security label components. Even though It indicates the semantics of the other security label components. Even
the securityLabel security-policy-identifier is an optional field, all though the eSSSecurityLabel security-policy-identifier is an optional
security labels used with S/MIME messages MUST include the field, all security labels used with S/MIME messages MUST include the
security-policy-identifier. security-policy-identifier.
3.3.2 Security Classification 3.3.2 Security Classification
This specification defines the use of the Security Classification field This specification defines the use of the Security Classification field
exactly as is specified in the X.411 Recommendation, which states in part: exactly as is specified in the X.411 Recommendation, which states in part:
If present, a security-classification may have one of a hierarchical If present, a security-classification may have one of a hierarchical
list of values. The basic security-classification hierarchy is defined list of values. The basic security-classification hierarchy is defined
in this Recommendation, but the use of these values is defined by the in this Recommendation, but the use of these values is defined by the
security-policy in force. Additional values of security-classification, security-policy in force. Additional values of security-classification,
and their position in the hierarchy, may also be defined by a and their position in the hierarchy, may also be defined by a
security-policy as a local matter or by bilateral agreement. The basic security-policy as a local matter or by bilateral agreement. The basic
security-classification hierarchy is, in ascending order: unmarked, security-classification hierarchy is, in ascending order: unmarked,
unclassified, restricted, confidential, secret, top-secret. unclassified, restricted, confidential, secret, top-secret.
This means that the security policy in force (identified by the This means that the security policy in force (identified by the
securityLabel security-policy-identifier) defines the eSSSecurityLabel security-policy-identifier) defines the
SecurityClassification integer values and their meanings. SecurityClassification integer values and their meanings.
An organization can develop its own security policy that defines the An organization can develop its own security policy that defines the
SecurityClassification INTEGER values and their meanings. However, the SecurityClassification INTEGER values and their meanings. However, the
general interpretation of the X.411 specification is that the values of 0 general interpretation of the X.411 specification is that the values of 0
thru 5 are reserved for the "basic hierarchy" values of unmarked, thru 5 are reserved for the "basic hierarchy" values of unmarked,
unclassified, restricted, confidential, secret, and top-secret. Note that unclassified, restricted, confidential, secret, and top-secret. Note that
X.411 does not provide the rules for how these values are used to label X.411 does not provide the rules for how these values are used to label
data and how access control is performed using these values. data and how access control is performed using these values.
skipping to change at line 1045 skipping to change at line 1064
An example of a security policy that uses part of the X.411 hierarchy might An example of a security policy that uses part of the X.411 hierarchy might
be: be:
0 -- unmarked 0 -- unmarked
1 -- unclassified, can be read by everyone 1 -- unclassified, can be read by everyone
2 -- restricted to Timberwolf Productions staff 2 -- restricted to Timberwolf Productions staff
6 -- can only be read to Timberwolf Productions executives 6 -- can only be read to Timberwolf Productions executives
3.3.3 Privacy Mark 3.3.3 Privacy Mark
If present, the securityLabel privacy-mark is not used for access control. If present, the eSSSecurityLabel privacy-mark is not used for access
The content of the securityLabel privacy-mark may be defined by the control. The content of the eSSSecurityLabel privacy-mark may be defined by
security policy in force (identified by the securityLabel the security policy in force (identified by the eSSSecurityLabel
security-policy-identifier) which may define a list of values to be used. security-policy-identifier) which may define a list of values to be used.
Alternately, the value may be determined by the originator of the Alternately, the value may be determined by the originator of the
security-label. security-label.
3.3.4 Security Categories 3.3.4 Security Categories
If present, the securityLabel 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 securityLabel security-policy-identifier) is used force (identified by the eSSSecurityLabel security-policy-identifier) is
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
securityLabel security-categories. Alternately, the security-categories and eSSSecurityLabel security-categories. Alternately, the security-categories
their values may be defined by bilateral agreement. and their values may be defined by bilateral agreement.
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
skipping to change at line 1119 skipping to change at line 1139
Note that if the mlExpansionHistory attribute is absent, then the recipient Note that if the mlExpansionHistory attribute is absent, then the recipient
is a first tier message recipient. is a first tier message recipient.
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having SignedData object may include multiple SignerInfos, each SignerInfo having
a mlExpansionHistory attribute. For example, an originator can send a a mlExpansionHistory 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 mlExpansionHistory attributes, but in all of the SignerInfos that include mlExpansionHistory attributes, but in all of the SignerInfos that
do conatin mlExpansionHistory attributes, the mlExpansionHistory attributes do contain mlExpansionHistory attributes, the mlExpansionHistory attributes
MUST be identical. MUST be identical.
A recipient SHOULD only process an mlExpansionHistory attribute if the A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate. the recipient cannot authenticate.
When receiving a message that includes an outer SignedData object, a When receiving a message that includes an outer SignedData object, a
receiving agent that processes mlExpansionHistory attributes MUST process receiving agent that processes mlExpansionHistory attributes MUST process
the mlExpansionHistory attribute, if present, in each SignerInfo in the the mlExpansionHistory attribute, if present, in each SignerInfo in the
skipping to change at line 1159 skipping to change at line 1179
list administrator. The mail list administrator is responsible for list administrator. The mail list administrator is responsible for
correcting the loop condition. correcting the loop condition.
4.2 Mail List Agent Processing 4.2 Mail List Agent Processing
MLA message processing depends on the structure of S/MIME layers found in MLA message processing depends on the structure of S/MIME layers found in
the processed message. In all cases, the MLA ultimately signs the message the processed message. In all cases, the MLA ultimately signs the message
and adds or updates an mlExpansionHistory attribute to document MLA and adds or updates an mlExpansionHistory attribute to document MLA
processing. In all cases, the MLA may need to perform access control before processing. In all cases, the MLA may need to perform access control before
distributing the message to mail list members if the message contains a distributing the message to mail list members if the message contains a
SignedData block and an associated securityLabel attribute. If a SignedData block and an associated eSSSecurityLabel attribute. If a
securityLabel authenticated attribute is used for access control, then the eSSSecurityLabel authenticated attribute is used for access control, then
signature of the signerInfo block including the securityLabel authenticated the signature of the signerInfo block including the eSSSecurityLabel
attribute MUST be verified before using the security label. The MLA should authenticated attribute MUST be verified before using the security label.
continue parsing the MIME-encapsulated message to determine if there is a The MLA should continue parsing the MIME-encapsulated message to determine
security label associated with an encapsulated SignedData object. This may if there is a security label associated with an encapsulated SignedData
include decrypting an EnvelopedData object to determine if an encapsulated object. This may include decrypting an EnvelopedData object to determine if
SignedData object includes a securityLabel attribute. an encapsulated SignedData object includes a eSSSecurityLabel 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. Section 4.3 mlExpansionHistory as the last element of the sequence. Section 4.3
provides more details regarding adding information to an existing provides more details regarding adding information to an existing
mLExpansionHistory attribute. mLExpansionHistory attribute.
When the MLA creates the new attribute list for its signature, the MLA
MUST propagate forward each attribute in the old signature, unless the MLA
explicitly replaces the attribute with a new value. An MLA will frequently
encounter attributes, or parts of attributes, which it does not
understand. Attributes such as security labels cannot be removed from
the new signature being created without compromising the security of the
system. Because it is impossible to enumerate the future list of attributes
which have security implicitions, an MLA MUST propagate forward all
attributes which it does not explicity replace.
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
contains to obtain the message key. contains to obtain the message key.
skipping to change at line 1300 skipping to change at line 1331
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 Agent Recipt Policy Processing 4.3 Mail List Agent Signed Recipt Policy Processing
If a mailing list (B) is a member of another mailing list (A), list B often 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 needs to propagate forward the mailing list receipt policy of A. As a
general rule, a mailing list should be conservative in propagating forward general rule, a mailing list should be conservative in propagating forward
the mailing list receipt policy because the ultimate recipient need only the mailing list receipt policy because the ultimate recipient need only
process the last item in the ML expansion history. The MLA builds the process the last item in the ML expansion history. The MLA builds the
expansion history to meet this requirement. expansion history to meet this requirement.
The following table describes the outcome of the union of mailing list A's 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 policy (the rows in the table) and mailing list B's policy (the columns in
skipping to change at line 1327 skipping to change at line 1358
insteadOf | none insteadOf(B) insteadOf(A+B) insteadOf(A) insteadOf | none insteadOf(B) insteadOf(A+B) insteadOf(A)
inAdditionTo | none insteadOf(B) inAdditionTo(A+B) inAditionTo(A) inAdditionTo | none insteadOf(B) inAdditionTo(A+B) inAditionTo(A)
missing | none insteadOf(B) inAddtionTo(B) missing missing | none insteadOf(B) inAddtionTo(B) missing
The interesting cases are combining insteadOf with inAddtionTo. The rest of 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. the cases either substitute in B's policy or propagate forward A's policy.
4.4 Mail List Expansion History Syntax 4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
there are more than ub-ml-expansion-hsitory mailing lists in the sequence, there are more than ub-ml-expansion-history mailing lists in the sequence,
the processing agent should return an error. the processing agent should return an error.
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
(SIZE (1..ub-ml-expansion-history)) 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,
skipping to change at line 1361 skipping to change at line 1393
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)) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..ub-insteadOf) 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. ASN.1 Module A. ASN.1 Module
skipping to change at line 1400 skipping to change at line 1432
{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
-- Section 2.7 -- Section 2.7
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
encapsulatedContentType EncapsulatedContentType OPTIONAL, encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) OF GeneralNames OPTIONAL } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING ContentIdentifier ::= OCTET STRING
EncapsulatedContentType ::= CHOICE { EncapsulatedContentType ::= CHOICE {
built-in BuiltinContentType, built-in BuiltinContentType,
external ExternalContentType, external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype } externalWithSubtype ExternalContentWithSubtype }
skipping to change at line 1449 skipping to change at line 1481
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL, encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription DirectoryString OPTIONAL, contentDescription DirectoryString OPTIONAL,
contentType OID } contentType OBJECT IDENTIFIER }
DirectoryString ::= CHOICE { DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)), teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..maxSize)) } universalString UniversalString (SIZE (1..MAX)) }
-- Section 3.2 -- Section 3.2
SecurityLabel ::= SET { ESSSecurityLabel ::= 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 ESSPrivacyMark 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),
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
PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length)) ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String OCTET STRING
-- If utf8String is used, the contents must be in UTF-8 [UTF8]
}
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
skipping to change at line 1508 skipping to change at line 1545
-- --
--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 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
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS] -- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..ub-insteadOf) 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
END -- of ExtendedSecurityServices END -- of ExtendedSecurityServices
B. References B. References
[ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
Communication Security Protocol (CSP) Specification. Notation One (ASN.1)"
[ASN1-1988] Recommendation X.208: Specification of Abstract Syntax Notation
One (ASN.1)
[ASN1-1994] Recommendation X.680: Specification of Abstract Syntax Notation [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
One (ASN.1) 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)}
[PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft
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.
[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
C. 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
D. Open Issues D. Open Issues
1.3.4: OIDs for contentIdentifier and encapsulatedContentType attributes
are needed.
2.4: An OID for msgSigDigest is needed. It will be an OCTET STRING. 2.4: An OID for msgSigDigest is needed. It will be an OCTET STRING.
3.2: An OID for the securityLabel attribute is needed. E. Changes from draft-ietf-smime-ess-01 to draft-ietf-smime-ess-02
E. Changes from draft-ietf-smime-ess-00 to draft-ietf-smime-ess-01
Fixed typos: "recevied" and "recipinet".
Reformatted a lot of the ASN.1 to conform with CMS.
1: Added note about ASN.1 formatting and differences from ASN.1:1988.
1.3.4: Added note that counterSignature must be in authenticated attributes Fixed many typos found by John Pawling.
if present.
2: Changed first sentence to be clearer about what a return receipt in ESS Changed "SEQUENCE (SIZE (...))" to "SEQUENCE SIZE (...)" in many places in
means. the ASN.1.
2.1: Simplified second sentence of step 6. 1.1.2: Removed the requirement that the signatures be in
application/pkcs7-mime format, and allow either format for both the inner
and outer signatures.
2.2: Made it clear that UA must not requrest a signed receipt for a signed 1.2: Changed "eight" to "eleven" because, well, because there are eleven
receipt. items in the list.
2.2.2: Added this section to specify what a sending agent must have in 1.3.2: First sentence, made it clear that you can have security labels in
order to validate signed receipts. any SignedData object.
2.3: Made it clear that an MUA should send a signed receipt when requested. 1.3.4: Last paragraph, removed last sentence because it was confusing.
Also changed allOrNone to allOrFirstTier in step 2, and removed old step
2.1, and fixed the flow chart for these changes.
2.4: This entire section was replaced so that the chain of digests includes 2.3: Added sentence at the end of the second paragraph saying what (not) to
more authenticated information. do if there are conflicting receipt requests. Also added sentence at the
end of the third paragraph about what to do when some signatures cannot be
validated.
2.4.1: Added this section to specify that MLExpansionHistory attributes 2.5: Step 1, made receiptsTo required.
can't be wrapped around Receipt bodies.
2.5: Replaced "Receipt Request" with "receiptRequest" in step 1. 2.7: In ReceiptRequest, receiptsTo is no longer OPTIONAL. Same change made
in Appendix A. Also changed the wording at the end of this section about
2.6: Replaced this entire section. Also foisted off the signature receiptsTo.
verification process on the documents for each algorithm.
2.7: This section was folded into the new 2.6. Thus, old 2.8 (Receipt 2.7: Added a sentence in the text preceding EncapsulatedContentType
Request Syntax), 2.9 (Receipt Syntax), and 2.10 (Content Hints) were describing what values to use.
renumbered to be 2.7 (Receipt Request Syntax), 2.8 (Receipt Syntax), and
2.9 (Content Hints).
2.8 (old): Changed "receiptRequest ::= SEQUENCE" to "ReceiptRequest ::= 2.9: Changed "encrypted data" to "envelopedData" to indicate the type we
SEQUENCE". Also, changed the first componenet of Receipts From to are using. Also changed "signed data" to "signedData". Also changed
allOrFirstTier, and changed that definition. Also removed " - no receipts "content hints" to "contentHints".
are requested" from list after defintion.
2.10: (old) Added sentences about ContentHints, and changed MUST to SHOULD 2.9: Changed "OID" in the ASN.1 to "OBJECT IDENTIFIER". Also changed
with an explanation and example. Also, changed "contentHints ::= SEQUENCE" "maxSize" to "MAX". Put wording after the ASN.1 about what MAX means here.
to "ContentHints ::= SEQUENCE". Also changed the structure of ContentHints Also made these changes in Appendix A.
significantly and added more information about the new contentType.
3.2: Changed "securityLabel ::= SET" to "SecurityLabel ::= SET". 3.2: Removed the reference to ACP120, and also removed that from the
references appendix.
4.2.2: Changed "PKCS #7 message" to "CMS message". Also, in bullet 3.3.1, 3.2: Changed "SecurityLabel" to "ESSSecurityLabel", made the privacy mark
made it clear that the encapsulation happens as an outer signature. Also "ESSPrivacyMark", and changed that mark to be a choice which allows
fixed step 3.3 in the flow chart. utf8String. Made same change in Appendix A. Made many changes to the text
to use this new name.
4.3: Added this entire section, and renumbered old 4.3 (Mail List Expansion 4.2: Added third paragraph saying that all attributes must be propagated
History Syntax) to 4.4. forwards.
A: Added this section and renumbered the other appendicies. B: Added reference to UTF-8.
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
--Paul Hoffman, Director
--Internet Mail Consortium
 End of changes. 

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