draft-ietf-smime-ess-09.txt   draft-ietf-smime-ess-10.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-09.txt Internet Mail Consortium draft-ietf-smime-ess-10.txt Internet Mail Consortium
October 19, 1998 November 12, 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 36 skipping to change at line 36
1. Introduction 1. Introduction
This document describes three optional security service extensions for This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments, Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are: particularly business and finance. The services are:
- signed receipts - signed receipts
- security labels - security labels
- secure mailing lists - secure mailing lists
The services described here are extensions to S/MIME version 3 [SMIME3], The services described here are extensions to S/MIME version 3 ([MSG] and
and some of them can also be added to S/MIME version 2 [SMIME2]. The [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2].
extensions described here will not cause an S/MIME version 3 recipient to The extensions described here will not cause an S/MIME version 3 recipient
be unable to read messages from an S/MIME version 2 sender. However, some to be unable to read messages from an S/MIME version 2 sender. However,
of the extensions will cause messages created by an S/MIME version 3 sender some of the extensions will cause messages created by an S/MIME version 3
to be unreadable by an S/MIME version 2 recipient. sender to be unreadable by an S/MIME version 2 recipient.
This document describes both the procedures and the attributes needed for
the three services. Note that some of the attributes described in this
document are quite useful in other contexts and should be considered when
extending S/MIME or other CMS applications.
The format of the messages are described in ASN.1:1988 [ASN1-1988]. The format of the messages are described in ASN.1:1988 [ASN1-1988].
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [MUSTSHOULD].
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
skipping to change at line 107 skipping to change at line 116
3. Sign the result of step 2 (the inner MIME headers and the original 3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData encapContentInfo eContentType object identifier content). The SignedData encapContentInfo eContentType object identifier
MUST be id-data. If the structure you create in step 4 is multipart/signed, MUST be id-data. If the structure you create in step 4 is multipart/signed,
then the SignedData encapContentInfo eContent MUST be absent. If the then the SignedData encapContentInfo eContent MUST be absent. If the
structure you create in step 4 is application/pkcs7-mime, then the structure you create in step 4 is application/pkcs7-mime, then the
SignedData encapContentInfo eContent MUST contain the result of step 2 SignedData encapContentInfo eContent MUST contain the result of step 2
above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of id-signedData. with a contentType of id-signedData.
4. Add an appropriate MIME construct to the signed message from step 3 as 4. Add an appropriate MIME construct to the signed message from step 3 as
defined in [SMIME3]. The resulting message is called the "inside defined in [MSG]. The resulting message is called the "inside signature".
signature".
- If you are signing using multipart/signed, the MIME construct added - If you are signing using multipart/signed, the MIME construct added
consists of a Content-type of multipart/signed with parameters, the consists of a Content-type of multipart/signed with parameters, the
boundary, the result of step 2 above, the boundary, a Content-type of boundary, the result of step 2 above, the boundary, a Content-type of
application/pkcs7-signature, optional MIME headers (such as application/pkcs7-signature, optional MIME headers (such as
Content-transfer-encoding and Content-disposition), and a body part that Content-transfer-encoding and Content-disposition), and a body part that
is the result of step 3 above. is the result of step 3 above.
- If you are instead signing using application/pkcs7-mime, the MIME - If you are instead signing using application/pkcs7-mime, the MIME
construct added consists of a Content-type of application/pkcs7-mime construct added consists of a Content-type of application/pkcs7-mime
skipping to change at line 254 skipping to change at line 262
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 signed attributes of any SignedData A security label may be included in the signed attributes of any SignedData
object. A security label attribute may be included in either the inner object. A security label attribute may be included in either the inner
signature, outer signature, or both. signature, outer signature, or both.
The inner security label is used for access control decisions related to The inner security label is used for access control decisions related to
the plaintext original content. The inner signature provides authentication the plaintext original content. The inner signature provides authentication
and cryptographically protects the original signer's security label that is and cryptographically protects the integrity of the original signer's
on the inside body. This strategy facilitates the forwarding of messages security label that is in the inside body. This strategy facilitates the
because the original signer's security label is included in the SignedData forwarding of messages because the original signer's security label is
block which can be forwarded to a third party that can verify the inner included in the SignedData block which can be forwarded to a third party
signature which will cover the inner security label. The confidentiality that can verify the inner signature which will cover the inner security
security service can be applied to the inner security label by encrypting label. The confidentiality security service can be applied to the inner
the entire inner SignedData block within an EnvelopedData block. security label by encrypting the entire inner SignedData block within an
EnvelopedData block.
A security label may also be included in the signed attributes of the outer A security label may also be included in the signed attributes of the outer
SignedData block which will include the sensitivities of the encrypted SignedData block which will include the sensitivities of the encrypted
message. The outer security label is used for access control and routing message. The outer security label is used for access control and routing
decisions related to the encrypted message. Note that a security label decisions related to the encrypted message. Note that a security label
attribute can only be used in an signedAttributes block. An attribute can only be used in an signedAttributes block. An
eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned
attributes. attributes.
1.3.3 Secure Mailing Lists and Triple Wrapping 1.3.3 Secure Mailing Lists and Triple Wrapping
Secure mail list message processing depends on the structure of S/MIME Secure mail list message processing depends on the structure of S/MIME
layers present in the message sent to the mail list agent. The agent never layers present in the message sent to the mail list agent. The mail list
changes the data that was hashed to form the inner signature, if such a agent never changes the data that was hashed to form the inner signature,
signature is present. If an outer signature is present, then the agent will if such a signature is present. If an outer signature is present, then the
modify the data that was hashed to form that outer signature. In all cases, agent will modify the data that was hashed to form that outer signature. In
the agent adds or updates an mlExpansionHistory attribute to document the all cases, the agent adds or updates an mlExpansionHistory attribute to
agent's processing, and ultimately adds or replaces the outer signature on document the agent's processing, and ultimately adds or replaces the outer
the message to be distributed. signature on the message to be distributed.
1.3.4 Placement of Attributes 1.3.4 Placement of Attributes
Certain attributes should be placed in the inner or outer SignedData Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be message; some attributes can be in either. Further, some attributes must be
signed, while signing is optional for others, and some attributes must not signed, while signing is optional for others, and some attributes must not
be signed. The following table summarizes the recommendation of this be signed. The following table summarizes the recommendation of this
profile. profile. In the OID column, [ESS] indicates that the attribute is defined
in this document.
| |Inner or | | |Inner or |
Attribute |OID |outer |Signed Attribute |OID |outer |Signed
------------------|----------------------------- |----------|-------- ------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
skipping to change at line 330 skipping to change at line 340
in ESS, if the attribute type is present in a signerInfo, then it MUST only in ESS, if the attribute type is present in a signerInfo, then it MUST only
include a single instance of AttributeValue. In other words, there MUST NOT include a single instance of AttributeValue. In other words, there MUST NOT
be zero or multiple instances of AttributeValue present in the attrValues be zero or multiple instances of AttributeValue present in the attrValues
SET OF AttributeValue. SET OF AttributeValue.
If a counterSignature attribute is present, then it MUST be included in the If a counterSignature attribute is present, then it MUST be included in the
unsigned attributes. It MUST NOT be included in the signed attributes. The unsigned attributes. It MUST NOT be included in the signed attributes. The
only attributes that are allowed in a counterSignature attribute are only attributes that are allowed in a counterSignature attribute are
counterSignature, messageDigest, signingTime, and signingCertificate. counterSignature, messageDigest, signingTime, and signingCertificate.
Note that the inner and outer signatures are usually for different senders. Note that the inner and outer signatures are usually those of different
The same attribute in the two signatures could lead to very different senders. Because of this, the same attribute in the two signatures could
consequences. lead to very different consequences.
The macValue attribute is only used in authenticatedData, never in The macValue attribute defined in [CMS] is only used in authenticatedData,
signedData. never in signedData.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
identifier assigned to the message. identifier assigned to the message.
1.4 Required and Optional Attributes 1.4 Required and Optional Attributes
Some security gateways sign messages that pass through them. If the message Some security gateways sign messages that pass through them. If the message
is any type other than a signedData type, the gateway has only one way to is any type other than a signedData type, the gateway has only one way to
sign the message: by wrapping it with a signedData block and MIME headers. sign the message: by wrapping it with a signedData block and MIME headers.
If the message to be signed by the gateway is a signedData message already, If the message to be signed by the gateway is a signedData message already,
skipping to change at line 370 skipping to change at line 380
Note that someone may in the future define an attribute that must be Note that someone may in the future define an attribute that must be
present in each signerInfo of a signedData block in order for the signature present in each signerInfo of a signedData block in order for the signature
to be processed. If that happens, a gateway that inserts signerInfos and to be processed. If that happens, a gateway that inserts signerInfos and
doesn't copy that attribute will cause every message with that attribute to doesn't copy that attribute will cause every message with that attribute to
fail when processed by the recipient. For this reason, it is safer to wrap fail when processed by the recipient. For this reason, it is safer to wrap
messages with new signatures than to insert signerInfos. messages with new signatures than to insert signerInfos.
1.5 Object Identifiers 1.5 Object Identifiers
The object identifiers for many of the objects described in this draft are The object identifiers for many of the objects described in this draft are
found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME
found in the registry kept at <http://www.imc.org/ietf-smime/oids.html>. can be found in the registry kept at
When this draft moves to standards track within the IETF, it is intended <http://www.imc.org/ietf-smime/oids.html>. When this draft moves to
that the IANA will maintain this registry. standards track within the IETF, it is intended that the IANA will maintain
this registry.
2. Signed Receipts 2. Signed Receipts
Returning a signed receipt provides to the originator proof of delivery of Returning a signed receipt provides to the originator proof of delivery of
a message, and allows the originator to demonstrate to a third party that a message, and allows the originator to demonstrate to a third party that
the recipient was able to verify the signature of the original message. the recipient was able to verify the signature of the original message.
This receipt is bound to the original message through the signature; This receipt is bound to the original message through the signature;
consequently, this service may be requested only if a message is signed. consequently, this service may be requested only if a message is signed.
The receipt sender may optionally also encrypt a receipt to provide The receipt sender may optionally also encrypt a receipt to provide
confidentiality between the receipt sender and the receipt recipient. confidentiality between the receipt sender and the receipt recipient.
skipping to change at line 424 skipping to change at line 435
(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 retained either a copy of the original message or the sender having retained either a copy of the original message or
information extracted from the original message. information extracted from the original message.
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
syntax for the receipt is given in Section 2.8. syntax for the receipt is given in Section 2.8.
Note that an agent SHOULD remember when it has sent a receipt so that it Note that a sending agent SHOULD remember when it has sent a receipt so
can avoid re-sending a receipt each time it processes the message. that it can avoid re-sending a receipt each time it processes the message.
2.2 Receipt Request Creation 2.2 Receipt Request Creation
Multi-layer S/MIME messages may contain multiple SignedData layers. Multi-layer S/MIME messages may contain multiple SignedData layers.
However, receipts may be requested only for the innermost SignedData layer However, receipts may be requested only for the innermost SignedData layer
in a multi-layer S/MIME message, such as a triple wrapped message. Only one in a multi-layer S/MIME message, such as a triple wrapped message. Only one
receiptRequest attribute can be included in the signedAttributes of a receiptRequest attribute can be included in the signedAttributes of a
SignerInfo. SignerInfo.
A ReceiptRequest attribute MUST NOT be included in the attributes of a A ReceiptRequest attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content. In SignerInfo in a SignedData object that encapsulates a Receipt content. In
other words, the user agent MUST NOT request a signed receipt for a signed other words, the receiving agent MUST NOT request a signed receipt for a
receipt. signed receipt.
A sender requests receipts by placing a receiptRequest attribute in the A sender requests receipts by placing a receiptRequest attribute in the
signed attributes of a signerInfo as follows: signed attributes of a signerInfo as follows:
1. A receiptRequest data structure is created. 1. A receiptRequest data structure is created.
2. A signed content identifier for the message is created and assigned to 2. A signed content identifier for the message is created and assigned to
the signedContentIdentifier field. The signedContentIdentifier is used to the signedContentIdentifier field. The signedContentIdentifier is used to
associate the signed receipt with the message requesting the signed associate the signed receipt with the message requesting the signed
receipt. receipt.
skipping to change at line 501 skipping to change at line 512
- the message signature digest value used to generate the original - the message signature digest value used to generate the original
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 to which the
receipt request attribute is directly attached. Processing software SHOULD receipt request attribute is directly attached. Receiving software SHOULD
examine the signedAttributes field of each of the SignerInfos for which it examine the signedAttributes field of each of the SignerInfos for which it
verifies a signature in the innermost signedData object to determine if a verifies a signature in the innermost signedData object to determine if a
receipt is requested. This may result in the receiving agent processing receipt is requested. This may result in the receiving agent processing
multiple receiptRequest attributes included in a single SignedData object. multiple receiptRequest attributes included in a single SignedData object,
such as requests made from different people who signed the object in
parallel.
Before processing a receiptRequest signedAttribute, the receiving agent Before processing a receiptRequest signedAttribute, the receiving agent
MUST verify the signature of the SignerInfo which covers the receiptRequest MUST verify the signature of the SignerInfo which covers the receiptRequest
attribute. A recipient MUST NOT process a receiptRequest attribute that has attribute. A recipient MUST NOT process a receiptRequest attribute that has
not been verified. Because all receiptRequest attributes in a SignedData not been verified. 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
described in the following paragraphs) the first receiptRequest attribute described in the following paragraphs) the first receiptRequest attribute
that it encounters in a SignerInfo that it verifies, and it then ensures that it encounters in a SignerInfo that it verifies, and it then ensures
that all other receiptRequest attributes in signerInfos that it verifies that all other receiptRequest attributes in signerInfos that it verifies
are identical to the first one encountered. If there are verified are identical to the first one encountered. If there are verified
ReceiptRequest attributes which conflict, then the processing software MUST ReceiptRequest attributes which are not the same, then the processing
NOT return any signed receipt. A signed receipt SHOULD be returned if any software MUST NOT return any signed receipt. A signed receipt SHOULD be
signerInfo containing a receiptRequest attribute can be validated, even if returned if any signerInfo containing a receiptRequest attribute can be
other signerInfos containing the same receiptRequest attribute cannot be validated, even if other signerInfos containing the same receiptRequest
validated because they are signed using an algorithm not supported by the attribute cannot be validated because they are signed using an algorithm
receiving agent. not supported by the receiving agent.
If a receiptRequest attribute is absent from the signed attributes, then a If a receiptRequest attribute is absent from the signed attributes, then a
signed receipt has not been requested from any of the message recipients signed receipt has not been requested from any of the message recipients
and MUST NOT be created. If a receiptRequest attribute is present in the and MUST NOT be created. If a receiptRequest attribute is present in the
signed attributes, then a signed receipt has been requested from some or signed attributes, then a signed receipt has been requested from some or
all of the message recipients. Note that in some cases, a receiving agent all of the message recipients. Note that in some cases, a receiving agent
might receive two almost-identical messages, one with a receipt request and might receive two almost-identical messages, one with a receipt request and
the other without one. In this case, the receiving agent SHOULD send a the other without one. In this case, the receiving agent SHOULD send a
signed receipt for the message that requests a signed receipt. signed receipt for the message that requests a signed receipt.
skipping to change at line 583 skipping to change at line 596
recipient is not a first tier recipient and a signed receipt MUST recipient is not a first tier recipient and a signed receipt MUST
NOT be created. NOT be created.
2.2.2. If an mlExpansionHistory attribute is not present, then a 2.2.2. If an mlExpansionHistory attribute is not present, 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 recipient, 3.1. If receiptList contains one of the GeneralNames of the 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 the 3.2. If receiptList does not contain one of the GeneralNames of 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
skipping to change at line 689 skipping to change at line 702
will eventually contain the signedData/Receipt signature value. will eventually contain the signedData/Receipt signature value.
7. A signingTime attribute indicating the time that the signedData/Receipt 7. A signingTime attribute indicating the time that the signedData/Receipt
is signed SHOULD be created and added to the signed attributes of the is signed SHOULD be created and added to the signed attributes of the
signerInfo which will eventually contain the signedData/Receipt signature signerInfo which will eventually contain the signedData/Receipt signature
value. Other attributes (except receiptRequest) may be added to the value. Other attributes (except receiptRequest) may be added to the
signedAttributes of the signerInfo. signedAttributes of the signerInfo.
8. The signedAttributes (messageDigest, msgSigDigest, contentType and, 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
possibly, others) of the signerInfo are ASN.1 DER encoded and digested as 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 described in [CMS]. The resulting digest value is used to calculate the
calculate the signature value which is then included in the signature value which is then included in the signedData/Receipt
signedData/Receipt signerInfo. signerInfo.
9. The ASN.1 DER encoded Receipt content MUST be directly encoded within 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
id-ct-receipt object identifier MUST be included in the signedData id-ct-receipt object identifier MUST be included in the signedData
encapContentInfo eContentType. This results in a single ASN.1 encoded encapContentInfo eContentType. This results in a single ASN.1 encoded
object composed of a signedData including the Receipt content. The Data object composed of a signedData including the Receipt content. The Data
content type MUST NOT be used. The Receipt content MUST NOT be encapsulated content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
in a MIME header or any other header prior to being encoded as part of the in a MIME header or any other header prior to being encoded as part of the
signedData object. signedData object.
skipping to change at line 717 skipping to change at line 730
11. If the signedData/Receipt is to be encrypted within an envelopedData 11. If the signedData/Receipt is to be encrypted within an envelopedData
object, then an outer signedData object MUST be created that encapsulates object, then an outer signedData object MUST be created that encapsulates
the envelopedData object, and a contentHints attribute with contentType set the envelopedData object, and a contentHints attribute with contentType set
to the id-ct-receipt object identifier MUST be included in the outer to the id-ct-receipt object identifier MUST be included in the outer
signedData SignerInfo signedAttributes. When a receiving agent processes signedData SignerInfo signedAttributes. When a receiving agent processes
the outer signedData object, the presence of the id-ct-receipt OID in the the outer signedData object, the presence of the id-ct-receipt OID in the
contentHints contentType indicates that a signedData/Receipt is encrypted contentHints contentType indicates that a signedData/Receipt is encrypted
within the envelopedData object encapsulated by the outer signedData. within the envelopedData object encapsulated by the outer signedData.
All agents that support the generation of ESS signed receipts MUST provide All sending agents that support the generation of ESS signed receipts MUST
the ability to send encrypted signed receipts (that is, a provide the ability to send encrypted signed receipts (that is, a
signedData/Receipt encapsulated within an envelopedData). The agent MAY signedData/Receipt encapsulated within an envelopedData). The sending agent
send an encrypted signed receipt in response to an MAY send an encrypted signed receipt in response to an
envelopedData-encapsulated signedData requesting a signed receipt. It is a envelopedData-encapsulated signedData requesting a signed receipt. It is a
matter of local policy regarding whether or not the signed receipt should matter of local policy regarding whether or not the signed receipt should
be encrypted. The ESS signed receipt includes the message digest value be encrypted. The ESS signed receipt includes the message digest value
calculated for the original signedData object that requested the signed calculated for the original signedData object that requested the signed
receipt. If the original signedData object was sent encrypted within an receipt. If the original signedData object was sent encrypted within an
envelopedData object and the ESS signed receipt is sent unencrypted, then envelopedData object and the ESS signed receipt is sent unencrypted, then
the message digest value calculated for the original encrypted signedData the message digest value calculated for the original encrypted signedData
object is sent unencrypted. The responder should consider this when object is sent unencrypted. The responder should consider this when
deciding whether or not to encrypt the ESS signed receipt. deciding whether or not to encrypt the ESS signed receipt.
skipping to change at line 932 skipping to change at line 945
2.9 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..MAX) OPTIONAL,   contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  contentType ContentType }   contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected to message subject. If this field is set, then the attribute is expected to
appear on the signedData object enclosing an envelopedData object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. The SIZE (1..MAX) construct constrains the on the inner signedData object. The (SIZE (1..MAX)) construct constrains
sequence to have at least one entry. MAX indicates the upper bound is the sequence to have at least one entry. MAX indicates the upper bound is
unspecified. Implementations are free to choose an upper bound that suits unspecified. Implementations are free to choose an upper bound that suits
their environment. their environment.
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an envelopedData
object, thus masking the inner content type of the message, SHOULD include object, thus masking the inner content type of the message, SHOULD include
a contentHints attribute, except for the case of the data content type. a contentHints attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion Specific message content types may either force or preclude the inclusion
of the contentHints attribute. For example, when a signedData/Receipt is of the contentHints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints be created that encapsulates the envelopedData object and a contentHints
skipping to change at line 1116 skipping to change at line 1129
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
    pString      PrintableString SIZE (1..ub-privacy-mark-length),     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String SIZE (1..MAX)     utf8String   UTF8String (SIZE (1..MAX))
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 1283 skipping to change at line 1296
is present in a signerInfo, all signerInfos in the signedData MUST contain is present in a signerInfo, all signerInfos in the signedData MUST contain
an ESSSecurityLabel and they MUST all be identical. In addition to an an ESSSecurityLabel and they MUST all be identical. In addition to an
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed
attribute. If present, the equivalentLabels attribute MUST include one or attribute. If present, the equivalentLabels attribute MUST include one or
more security labels that are believed by the signer to be semantically more security labels that are believed by the signer to be semantically
equivalent to the ESSSecurityLabel attribute included in the same equivalent to the ESSSecurityLabel attribute included in the same
signerInfo. signerInfo.
All security-policy object identifiers MUST be unique in the set of All security-policy object identifiers MUST be unique in the set of
ESSSecurityLabel and EquivalentLabels security labels. Before using an ESSSecurityLabel and EquivalentLabels security labels. Before using an
EquivalentLabels attribute, an agent MUST ensure that all security-policy EquivalentLabels attribute, a receiving agent MUST ensure that all
OIDs are unique in the security label or labels included in the security-policy OIDs are unique in the security label or labels included in
EquivalentLabels. Once the agent selects the security label (within the the EquivalentLabels. Once the receiving agent selects the security label
EquivalentLabels) to be used for processing, then the security-policy OID (within the EquivalentLabels) to be used for processing, then the
of the selected EquivalentLabels security label MUST be compared with the security-policy OID of the selected EquivalentLabels security label MUST be
ESSSecurityLabel security-policy OID to ensure that they are unique. compared with the ESSSecurityLabel security-policy OID to ensure that they
are unique.
In the case that an ESSSecurityLabel attribute is not included in a In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabels attribute may still be included. For signerInfo, then an EquivalentLabels attribute may still be included. For
example, in the Acme security policy, the absence of an ESSSecurityLabel example, in the Acme security policy, the absence of an ESSSecurityLabel
could be defined to equate to a security label composed of the Acme could be defined to equate to a security label composed of the Acme
security-policy OID and the "unmarked" security-classification. security-policy OID and the "unmarked" security-classification.
Note that equivalentLabels MUST NOT be used to convey security labels that Note that equivalentLabels MUST NOT be used to convey security labels that
are semantically different from the ESSSecurityLabel included in the are semantically different from the ESSSecurityLabel included in the
signerInfos in the signedData. If an entity needs to apply a security label signerInfos in the signedData. If an entity needs to apply a security label
that is semantically different from the ESSSecurityLabel, then it MUST that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the object that encapsulates the signedData object that includes the
ESSSecurityLabel. ESSSecurityLabel.
If present, the equivalentLabels attribute MUST be an signed attribute; it If present, the equivalentLabels attribute MUST be an signed attribute; it
MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET
Attribute. A signerInfo MUST NOT include multiple instances of the OF Attribute. A signerInfo MUST NOT include multiple instances of the
equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A equivalentLabels attributes to include attrValues SET OF AttributeValue. A equivalentLabels
attribute MUST only include a single instance of AttributeValue. There MUST attribute MUST only include a single instance of AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present in the NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue. attrValues SET OF AttributeValue.
3.4.2 Processing Equivalent Labels 3.4.2 Processing Equivalent Labels
A receiving agent SHOULD process the ESSSecurityLabel before processing any A receiving agent SHOULD process the ESSSecurityLabel before processing any
EquivalentLabels. If the policy in the ESSSecurityLabel is understood by EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
skipping to change at line 1624 skipping to change at line 1638
of the layers. Step 3 below specifies that different processing will take of the layers. Step 3 below specifies that different processing will take
place depending on the type of CMS message that has been signed. That is, 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 may it needs to know the type of data at the next inner layer, which may or may
not be the innermost layer. not be the innermost layer.
1. The MLA verifies the signature value found in the outermost SignedData 1. The MLA verifies the signature value found in the outermost SignedData
layer associated with the signed data. MLA processing of the message layer associated with the signed data. MLA processing of the message
terminates if the message signature is invalid. terminates if the message signature is invalid.
2. If the outermost SignedData layer includes an signed mlExpansionHistory 2. If the outermost SignedData layer includes an signed mlExpansionHistory
attribute the MLA checks for an expansion loop as described in the attribute, the MLA checks for an expansion loop as described in the
"Detecting Mail List Expansion Loops" section. "Detecting Mail List Expansion Loops" section, then go to step 3. If the
outermost SignedData layer does not include an signed mlExpansionHistory
attribute, go directly to step 4.
3. Determine the type of the data that has been signed. That is, look at 3. Determine the type of the data that has been signed. That is, look at
the type of data on the layer just below the SignedData, which may or may the type of data on the layer just below the SignedData, which may or may
not be the "innermost" layer. Based on the type of data, perform either not be the "innermost" layer. Based on the type of data, perform either
step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
types). types).
3.1. If the signed data is EnvelopedData, the MLA performs expansion 3.1. If the signed data is EnvelopedData, the MLA performs expansion
processing of the encrypted message as described previously. Note that processing of the encrypted message as described previously. Note that
this process invalidates the signature value in the outermost this process invalidates the signature value in the outermost
skipping to change at line 1687 skipping to change at line 1703
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.
2. Does outermost SignedData layer 2. Does outermost SignedData layer contain mlExpansionHistory?
contain mlExpansionHistory?
YES -> Check it, then -> 3. YES -> Check it, then -> 3.
NO -> 3. NO -> 4.
3. Check type of data just below outermost 3. Check type of data just below outermost
SignedData. SignedData.
EnvelopedData -> 3.1. EnvelopedData -> 3.1.
SignedData -> 3.2. SignedData -> 3.2.
all others -> 3.3. all others -> 3.3.
3.1. Expand the encrypted message, then -> 3.2. 3.1. Expand the encrypted message, then -> 3.2.
3.2. -> 3.2.1. 3.2. -> 3.2.1.
3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
and other signed attributes, then -> 3.2.2. and other signed attributes, then -> 3.2.2.
3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.2. Encapsulate in new signature, then -> 3.2.3.
skipping to change at line 1745 skipping to change at line 1760
inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAdditionTo(B) missing missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
4.4 Mail List Expansion History Syntax 4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
there are more than ub-ml-expansion-history mailing lists in the sequence, there are more than ub-ml-expansion-history mailing lists in the sequence,
the processing agent should provide notification of the error to a human the receiving agent should provide notification of the error to a human
mail list administrator. The mail list administrator is responsible for mail list administrator. The mail list administrator is responsible for
correcting the overflow condition. correcting the overflow condition.
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
skipping to change at line 1794 skipping to change at line 1809
recipients in addition to the originator (inAdditionTo). recipients in addition to the originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
5. Signing Certificate Attribute 5. Signing Certificate Attribute
Concerns have been raised over the fact that the certificate which the Concerns have been raised over the fact that the certificate which the
signer of a [CMS] SignedData object desired to be bound into the signer of a CMS SignedData object desired to be bound into the verification
verification process of the SignedData object is not cryptographically process of the SignedData object is not cryptographically bound into the
bound into the signature itself. This section addresses this issue by signature itself. This section addresses this issue by creating a new
creating a new attribute to be placed in the signed attributes section of a attribute to be placed in the signed attributes section of a SignerInfo
SignerInfo object. object.
This section also presents a description of a set of possible attacks This section also presents a description of a set of possible attacks
dealing with the substitution of one certificate to verify the signature dealing with the substitution of one certificate to verify the signature
for the desired certificate. A set of ways for preventing or addressing for the desired certificate. A set of ways for preventing or addressing
these attacks is presented to deal with the simplest of the attacks. these attacks is presented to deal with the simplest of the attacks.
Attribute certificates can be used as part of a signature verification Attribute certificates can be used as part of a signature verification
process. There is no way in CMS to include the list of attribute process. There is no way in CMS to include the list of attribute
certificates to be used in the verification process. The set of attribute certificates to be used in the verification process. The set of attribute
certificates used in the signature verification process needs to have the certificates used in the signature verification process needs to have the
skipping to change at line 1958 skipping to change at line 1973
The definition of SigningCertificate is The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE { SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> } smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate identifiers The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature. The encoding of the MUST be the certificate used to verify the signature. The encoding of the
ESSCertID for this certificate SHOULD NOT include the issuerSerial because ESSCertID for this certificate SHOULD NOT include the issuerSerial because
the issuerAndSerialNumber is already present in the SignerInfo. The the issuerAndSerialNumber is already present in the SignerInfo. The
certificate identified is used during the signature verification process. certificate identified is used during the signature verification process.
If the hash of the certificate does not match the certificate used to If the hash of the certificate does not match the certificate used to
verify the signature, the signature MUST be considered invalid. verify the signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of ESSCertIDs, the If more than one certificate is present in the sequence of ESSCertIDs, the
skipping to change at line 1993 skipping to change at line 2008
MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
Attribute. A SignerInfo MUST NOT include multiple instances of the Attribute. A SignerInfo MUST NOT include multiple instances of the
SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
attributes to include attrValues SET OF AttributeValue. A attributes to include attrValues SET OF AttributeValue. A
SigningCertificate attribute MUST include only a single instance of SigningCertificate attribute MUST include only a single instance of
AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
5.4.1 Certificate Identification 5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue. [CMS] The best way to identify certificates is an often-discussed issue. CMS has
has imposed a restriction for SignedData objects that the issuer DN must be imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. The issuer/serial number pair is present in all signing certificates. The issuer/serial number pair is
therefore sufficient to identify the correct signing certificate. This therefore sufficient to identify the correct signing certificate. This
information is already present, as part of the SignerInfo object, and information is already present, as part of the SignerInfo object, and
duplication of this information would be unfortunate. A hash of the entire duplication of this information would be unfortunate. A hash of the entire
certificate serves the same function (allowing the receiver to verify that certificate serves the same function (allowing the receiver to verify that
the same certificate is being used as when the message was signed), is the same certificate is being used as when the message was signed), is
smaller, and permits a detection of the simple substitution attacks. smaller, and permits a detection of the simple substitution attacks.
Attribute certificates do not have an issuer/serial number pair represented Attribute certificates do not have an issuer/serial number pair represented
anywhere in a SignerInfo object. When an attribute certificate is not anywhere in a SignerInfo object. When an attribute certificate is not
skipping to change at line 2057 skipping to change at line 2072
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax -- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1 PolicyInformation FROM PKIX1Implicit88 {iso(1)
identified-organization(3)dod(6) internet(1) security(5) identified-organization(3)dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)} mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- X.509 -- X.509
GeneralNames, CertificateSerialNumber, FROM CertificateExtensions GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services -- Extended Security Services
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified. -- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their -- Implementations are free to choose an upper bound that suits their
-- environment. -- environment.
skipping to change at line 2117 skipping to change at line 2132
contentType ContentType, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..MAX) OPTIONAL,   contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
  contentType ContentType }   contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10 -- Section 2.10
MsgSigDigest ::= OCTET STRING MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at line 2164 skipping to change at line 2179
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
    pString      PrintableString SIZE (1..ub-privacy-mark-length),     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String SIZE (1..MAX)     utf8String   UTF8String (SIZE (1..MAX))
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 2235 skipping to change at line 2250
-- Section 5.4 -- Section 5.4
SigningCertificate ::= SEQUENCE { SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> } smime(16) id-aa(2) 12 }
ESSCertID ::= SEQUENCE { ESSCertID ::= SEQUENCE {
certHash Hash, certHash Hash,
issuerSerial IssuerSerial OPTIONAL issuerSerial IssuerSerial OPTIONAL
} }
Hash ::= OCTET STRING -- SHA1 hash of entire certificate Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
skipping to change at line 2259 skipping to change at line 2274
END -- of ExtendedSecurityServices END -- of ExtendedSecurityServices
B. References B. References
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)"
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)"
[CERT] "S/MIME Version 3 Certificate Handling", Internet Draft
draft-ietf-smime-cert-xx.
[CMS] "Cryptographic Message Syntax", Internet Draft [CMS] "Cryptographic Message Syntax", Internet Draft
draft-ietf-smime-cms-xx. draft-ietf-smime-cms-xx.
[MSG] "S/MIME Version 3 Message Specification", Internet Draft
draft-ietf-smime-msg-xx.
[MUSTSHOULD] "Key Words for Use in RFCs to Indicate Requirement Levels",
RFC 2119.
[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", RFC 2315. [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315.
[SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
"S/MIME Version 2 Certificate Handling", RFC 2312. "S/MIME Version 2 Certificate Handling", RFC 2312.
[SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
Internet Draft draft-ietf-smime-cert-xx.
[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
C. Acknowledgments C. Acknowledgments
The first draft of this work was prepared by David Solo. John Pawling did a The first draft of this work was prepared by David Solo. John Pawling did a
huge amount of very detailed revision work during the many phases of the huge amount of very detailed revision work during the many phases of the
document. document.
Many other people have contributed hard work to this draft, including: Many other people have contributed hard work to this draft, including:
Andrew Farrell
Bancroft Scott Bancroft Scott
Bengt Ackzell Bengt Ackzell
Bill Flanigan
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
David Kemp David Kemp
Denis Pinkas
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Changes from draft-ietf-smime-ess-08 to draft-ietf-smime-ess-09 D. Changes from draft-ietf-smime-ess-09 to draft-ietf-smime-ess-10
5: Many small changes from John Pawling. See Numerous small clarifications throughout.
<http://www.imc.org/ietf-smime/mail-archive/2206.html>. Also changed
CertID to ESSCertID.
A: Copied the new ASN.1 from 5 (whoops!). Put in an import of Changed the [SMIME3] reference to [CERT] and [MSG].
PolicyInformation from PKIX, and an import of CertificateSerialNumber from
the CertificateExtensions module. 1: Added paragraph about usefulness of attributes for other
purposes. Also added reference to [MUSTSHOULD].
1.3.4: Added note about [ESS].
2.3: Added explanation at the end of the first paragraph about why
you might get more than one receipt request. Also changed "conflict"
to "are not the same" in the second paragraph.
2.9, 3.2: Added parentheses around SIZE declarations. Also in Appendix
A.
4.2.3.2: Changed step 2 to say that if mlExpansionHistory isn't found,
skip to step 4. Also updated the flow chart.
5.4: Filled in the TBD of the id-aa-signingCertificate OID. Also in
Appendix A.
A: Fixed some bugs in the headers caused by typos.
E. Editor's Address E. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
(831) 426-9827 (831) 426-9827
phoffman@imc.org phoffman@imc.org
 End of changes. 

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