draft-ietf-smime-ess-02.txt   draft-ietf-smime-ess-03.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-02.txt Internet Mail Consortium draft-ietf-smime-ess-03.txt Internet Mail Consortium
February 16, 1998 March 1, 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 37
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 [MSP], but are useful in many other environments, Security Protocol [MSP], but are useful in many other environments,
particularly business and finance. The services are: particularly business and finance. The services are:
- signed receipts - signed receipts
- security labels - security labels
- secure mailing lists - secure mailing lists
The services described here are extensions to S/MIME version 2 [SMIME2] and The services described here are extensions to S/MIME version 3 [SMIME3],
S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME and some of them can also be added to S/MIME version 2 [SMIME2]. The
version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number extensions described here will not cause an S/MIME version 3 recipient to
of the services require mechanisms described in Cryptographic Message be unable to read messages from an S/MIME version 2 sender. However, some
Syntax [CMS]. The format of the messages are described in ASN.1:1988 of the extensions will cause messages created by an S/MIME version 3 sender
[ASN1-1988] with the modification that BMPString and UniversalString to be unreadable by an S/MIME version 2 recipient.
types from ASN.1:1994 [ASN1-1994] are used in the descriptions.
The format of the messages are described in ASN.1:1988 [ASN1-1988] with the
modification that UTF8String from ASN.1:1994 [ASN1-1994] is used in the
descriptions.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
skipping to change at line 64 skipping to change at line 68
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple wrapped"
message. A triple wrapped message is one that has been signed, then message. A triple wrapped message is one that has been signed, then
encrypted, then signed again. The signers of the inner and outer signatures encrypted, then signed again. The signers of the inner and outer signatures
may be different entities or the same entity. Note that the S/MIME may be different entities or the same entity. Note that the S/MIME
specification does not limit the number of nested encapsulations, so there specification does not limit the number of nested encapsulations, so there
may be more than three wrappings. may be more than three wrappings.
1.1.1 Purpose of Triple Wrapping 1.1.1 Purpose of Triple Wrapping
Not all messages need to be triple wrapped. Triple wrapping is used when a Not all messages need to be triple wrapped. Triple wrapping is used when a
message must be signed, then encrypted, and then processed by other agents message must be signed, then encrypted, and then have authenticated
that have to be authenticated by the final recipient (i.e. via an outer attributes bound to the encrypted body. Outer attributes may be added or
signature). removed by the message originator or intermediate agents, and may be
authenticated by intermediate agents or the final recipient.
The inside signature is used for content integrity, non-repudiation with The inside signature is used for content integrity, non-repudiation with
proof of origin, and binding attributes (such as a security label) to the proof of origin, and binding attributes (such as a security label) to the
original content. These attributes go from the originator to the recipient, original content. These attributes go from the originator to the recipient,
regardless of the number of intermediate entities such as mail list agents regardless of the number of intermediate entities such as mail list agents
that process the message. The authenticated attributes can be used for that process the message. The authenticated attributes can be used for
access control to the inner body. Requests for signed receipts by the access control to the inner body. Requests for signed receipts by the
originator are carried in the inside signature as well. originator are carried in the inside signature as well.
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including confidentiality of
the attributes that are carried in the inside signature. the attributes that are carried in the inside signature.
The outside signature provides authentication and integrity for information The outside signature provides authentication and integrity for information
skipping to change at line 86 skipping to change at line 92
The encrypted body provides confidentiality, including confidentiality of The encrypted body provides confidentiality, including confidentiality of
the attributes that are carried in the inside signature. the attributes that are carried in the inside signature.
The outside signature provides authentication and integrity for information The outside signature provides authentication and integrity for information
that is processed hop-by-hop, where each hop is an intermediate entity such that is processed hop-by-hop, where each hop is an intermediate entity such
as a mail list agent. The outer signature binds attributes (such as a as a mail list agent. The outer signature binds attributes (such as a
security label) to the encrypted body. These attributes can be used for security label) to the encrypted body. These attributes can be used for
access control and routing decisions. access control and routing decisions.
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 Content-type
headers, such as "Content-type: text/plain". An exception to this MIME
encapsulation rule is that a signed receipt is not put in MIME headers.
exception to this MIME encapsulation rule is that a signed receipt is not 3. Sign the result of step 2 (the inner MIME headers and the original
put in MIME headers. content). The SignedData structure is encapsulated by a ContentInfo
SEQUENCE with a contentType of data. If the structure you create in step 4
is multipart/signed, the eContent is missing; if the structure you create
in step 4 is application/pkcs7-mime, the eContent is the result of step 2
above.
3. Sign the result of step 2 (the MIME headers and the original content), 4. Add an appropriate MIME construct to the signed message from step 3 as
creating a signed messsage that includes MIME headers. The resulting defined in [SMIME3]. The resulting message 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) - If you are signing using multipart/signed, the MIME construct added
as a single block, turning it into another (larger) application/pkcs7-mime consists of a Content-type of multipart/signed with parameters, the
body part, and add the appropriate MIME headers. The application/pkcs7-mime boundary, the result of step 2 above, the boundary, a Content-type of
body part is called the "encrypted body". application/pkcs7-signature, optional MIME headers (such as
Content-transfer-encoding and Content-disposition), and a body part that is
the result of step 3 above.
5. Sign the result of step 4 (the MIME headers and the encrypted body) as a - If you are instead signing using application/pkcs7-mime, the MIME
single block, turning it into another (even larger) message that includes construct added consists of a Content-type of application/pkcs7-mime with
MIME headers. This message is called the "outside signature". parameters, optional MIME headers (such as Content-transfer-encoding and
Content-disposition), and the result of step 3 above.
6. The result of step 5 (the MIME headers and the outside signature) is the 5. Encrypt the result of step 4 as a single block, turning it into an
triple wrapped message. application/pkcs7-mime object. The EnvelopedData structure is encapsulated
by a ContentInfo SEQUENCE with a contentType of data. This is called the
"encrypted body".
6. Add the appropriate MIME headers: a Content-type of
application/pkcs7-mime with parameters, and optional MIME headers such as
Content-transfer-encoding and Content-disposition.
7. Using the same logic as in step 3 above, sign the result of step 6 (the
MIME headers and the encrypted body) as a single block
8. Using the same logic as in step 4 above, add an appropriate MIME
construct to the signed message from step 7. The resulting message is
called the "outside signature", and is also the triple wrapped message.
1.2 Format of a Triple Wrapped Message 1.2 Format of a Triple Wrapped Message
A triple wrapped message has eleven layers of encapsulation. Starting from A triple wrapped message has many layers of encapsulation. The structure
the innermost layer and working outwards, the layers are: differs based on the choice of format for the signed portions of the
message. Because of the way that MIME encapsulates data, the layers do not
appear in order, and the notion of "layers" becomes vague.
Original content ("Hello, world!") There is no need to use the multipart/signed format in an inner signature
MIME entity because it is known that the recipient is able to process S/MIME messages
ContentInfo: data type (because they decrypted the middle wrapper). A sending agent might choose
Inner SignedData block to use the multipart/signed format in the outer layer so that a non-S/MIME
MIME entity agent could see that the next inner layer is encrypted; however, this is
ContentInfo: data type not of great value, since all it shows the recipient is that the rest of
EnvelopedData block the message is unreadable. Because many sending agents always use
MIME entity multipart/signed structures, all receiving agents MUST be able to interpret
ContentInfo: data type either multipart/signed or application/pkcs7-mime signature structures.
Outer SignedData block
MIME entity
Note that both the inner and outer signed blocks use the SignedData The format of a triple wrapped message that uses multipart/signed for
construct of S/MIME. As defined in [PKCS7-1.5] and [CMS], each SignedData both signatures is:
and EnvelopedData object MUST be encapsulated by a ContentInfo SEQUENCE.
There is no purpose to use the multipart/signed format in inner case [step 8] Content-type: multipart/signed;
because it is known that the recipient is known to be able to process [step 8] protocol="application/pkcs7-signature";
S/MIME messages (because they decrypted the middle wrapper). There may be a [step 8] boundary=outerboundary
purpose in using multipart/signed in the outer layer, but only so that a [step 8]
non-S/MIME agent could see that the next inner layer is encrypted. However, [step 8] --outerboundary
this is not of great value, since all it shows the recipient is that he or [step 6] Content-type: application/pkcs7-mime; )
she wouldn't have been able to read the message anyways. [step 6] smime-type=enveloped-data )
[step 6] )
[step 4] Content-type: multipart/signed; | )
[step 4] protocol="application/pkcs7-signature"; | )
[step 4] boundary=innerboundary | )
[step 4] | )
[step 4] --innerboundary | )
[step 2] Content-type: text/plain % | )
[step 2] % | )
[step 1] Original content % | )
[step 4] | )
[step 4] --innerboundary | )
[step 4] Content-type: application/pkcs7-signature | )
[step 4] | )
[step 3] SignedData block (eContent is missing) | )
[step 6]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] SignedData block
% = These lines are what the inner signature is computed over.
| = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over.
The format of a triple wrapped message that uses application/pkcs7-mime for
the outer signature is:
[step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data
[step 8]
[step 6] Content-type: application/pkcs7-mime; )
[step 6] smime-type=enveloped-data; )
[step 6] )
[step 4] Content-type: application/pkcs7-mime; | )
[step 4] smime-type=signed-data | )
[step 4] | )
[step 3] SignedData block (eContent is present) $ | )
[step 6]
[step 7] SignedData block !
$ = This SignedData block is opaque and contains the ASN.1 encoded result
of step 2 as well as control information.
| = These lines are what is encrypted in step 5. This encrypted result
is opaque and is a part of an EnvelopedData block.
) = These lines are what the outer signature is computed over.
! = This SignedData block is opaque and contains the ASN.1 encoded result
of step 6 as well as control information.
1.3 Security Services and Triple Wrapping 1.3 Security Services and Triple Wrapping
The three security services described in this document are used with triple The three security services described in this document are used with triple
wrapped messages in different ways. This section briefly describes the wrapped messages in different ways. This section briefly describes the
relationship of each service with triple wrapping; the other sections of relationship of each service with triple wrapping; the other sections of
the document go into greater detail. the document go into greater detail.
1.3.1 Signed Receipts and Triple Wrapping 1.3.1 Signed Receipts and Triple Wrapping
skipping to change at line 181 skipping to change at line 256
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. An label attribute can only be used in an authenticatedAttributes block. An
eSSSsecurityLabel attribute MUST NOT be used in an EnvelopedData or eSSSecurityLabel 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
agent's processing, and ultimately adds or replaces the outer signature on agent's processing, and ultimately adds or replaces the outer signature on
the message to be distributed. the message to be distributed.
1.3.4 Placement of Attributes 1.3.4 Placement of Attributes
Certain attributes should be placed in the inner or outer SignedData Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be message; some attributes can be in either. Further, some attributes must be
authenticated, while authentication is optional for others. The following authenticated, while authentication is optional for others. The following
skipping to change at line 206 skipping to change at line 281
agent's processing, and ultimately adds or replaces the outer signature on agent's processing, and ultimately adds or replaces the outer signature on
the message to be distributed. the message to be distributed.
1.3.4 Placement of Attributes 1.3.4 Placement of Attributes
Certain attributes should be placed in the inner or outer SignedData Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be message; some attributes can be in either. Further, some attributes must be
authenticated, while authentication is optional for others. The following authenticated, while authentication is optional for others. The following
table summarizes the recommendation of this profile. table summarizes the recommendation of this profile.
Attribute Inner or outer MUST BE authenticated | |Inner or |MUST be
contentHints either no Attribute |OID |outer |authenticated
contentIdentifier either no ------------------|-----------------------------|----------|-------------
contentType either no contentHints |id-aa-contentHint [ESS] |either |no
counterSignature either no contentIdentifier |id-aa-contentIdentifier [ESS]|either |no
encapsulatedContentType either no contentType |id-contentType [CMS] |either |yes
messageDigest either yes counterSignature |id-countersignature [CMS] |either |MUST NOT
mlExpansionHistory outer only yes eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes
receiptRequest inner only yes messageDigest |id-messageDigest [CMS] |either |yes
signingTime either yes msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes
smimeCapabilities either yes mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes
essSecurityLabel either yes receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes
signingTime |id-signingTime [CMS] |either |yes
smimeCapabilities |sMIMECapabilities [MSG] |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.
used to carry the content type of the encapsulated content.
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 [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be
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.
1.5 Criticality of Attributes
Authenticated attributes can be marked as critical. In this specification,
the only attribute which MUST be marked as critical is eSSSecurityLabel.
Note that marking any attribute as critical will make the message
unreadable to S/MIME v2 recipients. Because of this, a sending agent should
only mark attributes critical if necessary for the agent's application, and
at the risk of preventing an S/MIME v2 recipient from verifying (or
possibly even being able to read) the message.
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.
2.1 Signed Receipt Concepts 2.1 Signed Receipt Concepts
The originator of a message may request a signed receipt from the message's The originator of a message may request a signed receipt from the message's
recipients. The request is indicated by adding a receiptRequest attribute recipients. The request is indicated by adding a receiptRequest attribute
to the authenticatedAttributes field of the SignerInfo object for which the to the authenticatedAttributes field of the SignerInfo object for which the
receipt is requested. The receiving user agent software SHOULD receipt is requested. The receiving user agent software SHOULD
automatically create a signed receipt when requested to do so, and return automatically create a signed receipt when requested to do so, and return
skipping to change at line 308 skipping to change at line 397
A ReceiptRequest attribute MUST NOT be included in the attributes of a A ReceiptRequest attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content. In SignerInfo in a SignedData object that encapsulates a Receipt content. In
other words, the user agent MUST NOT request a signed receipt for a signed other words, the user agent MUST NOT request a signed receipt for a signed
receipt. receipt.
A sender requests receipts by placing a receiptRequest attribute in the A sender requests receipts by placing a receiptRequest attribute in the
authenticated attributes of a signerInfo as follows: authenticated attributes of a signerInfo as follows:
1. A receiptRequest data structure is created. 1. A receiptRequest data structure is created.
2. The encapsulated content type is optionally noted in the 2. A signed content identifier for the message is created and assigned to
encapsulatedContentType field.
3. A signed content identifier for the message is created and assigned to
the signedContentIdentifier field. The signedContentIdentifier is used to the signedContentIdentifier field. The signedContentIdentifier is used to
associate the signed receipt with the message requesting the signed associate the signed receipt with the message requesting the signed
receipt. receipt.
4. The entities requested to return a signed receipt are noted in the 3. The entities requested to return a signed receipt are noted in the
receiptsFrom field. receiptsFrom field.
5. If receipts are to be returned to entities other than or in addition to 4. The message originator MUST populate the receiptsTo field with a
the message originator, a list of receipt recipients is assigned to the GeneralNames for each entity to whom the recipient should send the signed
receiptsTo field. The originator's name(s) MUST be included in the
receiptsTo list if receipt recipients in addition to the originator are
requested.
6. The completed receiptRequest attribute is placed in the receipt. If the message originator wants the recipient to send the signed
receipt to the originator, then the originator MUST include a GeneralNames
for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
GeneralNames represents an entity. There may be multiple GeneralName
instances in each GeneralNames. At a minimum, the message originator MUST
populate each entity's GeneralNames with the address to which the signed
receipt should be sent. Optionally, the message originator MAY also
populate each entity's GeneralNames with other GeneralName instances (such
as directoryName).
5. The completed receiptRequest attribute is placed in the
authenticatedAttributes field of the SignerInfo object. authenticatedAttributes field of the SignerInfo object.
2.2.1 Multiple Receipt Requests 2.2.1 Multiple Receipt Requests
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having SignedData object may include multiple SignerInfos, each SignerInfo having
a receiptRequest attribute. For example, an originator can send a signed a receiptRequest attribute. For example, an originator can send a signed
message with two SignerInfos, one containing a DSS signature, the other message with two SignerInfos, one containing a DSS signature, the other
containing an RSA signature. containing an RSA signature.
skipping to change at line 379 skipping to change at line 472
Because all receiptRequest attributes in a SignedData object must be Because all receiptRequest attributes in a SignedData object must be
identical, the receiving application fully processes (as described in the identical, the receiving application fully processes (as described in the
following paragraphs) the first receiptRequest that it encounters in a following paragraphs) the first receiptRequest that it encounters in a
SignerInfo that it can verify, and it then ensures that all other SignerInfo that it can verify, and it then ensures that all other
receiptRequests are identical to the first one encountered. If receiptRequests are identical to the first one encountered. If
ReceiptRequests which conflict are present, then the processing software ReceiptRequests which conflict are present, then the processing software
MUST NOT return any receipt. 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 receipt MUST be returned if any signature containing a a signed receipt. A receipt SHOULD be returned if any signature containing
receipt request can be validated, even if other signatures containing the a receipt request can be validated, even if other signatures containing the
same receipt request cannot be validated. 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:
skipping to change at line 512 skipping to change at line 605
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 values are 2.2. The original signedData encapContentInfo eContentType object
copied from the original signedData signerInfo receiptRequest attribute identifier is copied into the Receipt contentType.
into the corresponding fields in the Receipt structure.
2.3. The signature value from the original signedData signerInfo that 2.3. The original signedData signerInfo receiptRequest
includes the receiptRequest attribute is copied into the signedContentIdentifier is copied into the Receipt
originatorSignatureValue field in the Receipt structure. signedContentIdentifier.
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
skipping to change at line 549 skipping to change at line 640
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 object the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
identifier MUST be included in the signedData contentInfo contentType. This id-ct-receipt object identifier MUST be included in the signedData
results in a single ASN.1 encoded object composed of a signedData including encapContentInfo eContent. This results in a single ASN.1 encoded object
the Receipt content. The Data content type MUST NOT be used. The Receipt composed of a signedData including the Receipt content. The Data content
content MUST NOT be encapsulated in a MIME header or any other header prior type MUST NOT be used. The Receipt content MUST NOT be encapsulated in a
to being encoded as part of the signedData object. MIME header or any other header prior to being encoded as part of the
signedData object.
10. If the signedData/Receipt is to be encrypted within an envelopedData 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 object identifier MUST be included in the outer to the id-ct-receipt object identifier MUST be included in the outer
signedData SignerInfo authenticatedAttributes. When a receiving agent signedData SignerInfo authenticatedAttributes. When a receiving agent
processes the outer signedData object, the presence of the id-ct-receipt processes the outer signedData object, the presence of the id-ct-receipt
OID in the contentHints contentType indicates that a signedData/Receipt is OID in the contentHints contentType indicates that a signedData/Receipt is
encrypted within the envelopedData object encapsulated by the outer encrypted within the envelopedData object encapsulated by the outer
signedData. signedData.
skipping to change at line 585 skipping to change at line 677
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. The receiptsTo field must be present in the receiptRequest attribute. 1. The receiptsTo field must be present in the receiptRequest attribute.
The software initiates the sequence of recipients with the value(s) of The software initiates the sequence of recipients with the value(s) of
receiptsTo; otherwise, the software initiates the sequence of recipients receiptsTo.
with the signer (that is, the originator) of the SignerInfo that includes
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 object identifier in the identified by the presence of the id-ct-receipt object identifier in the
contentInfo contentType value of the signedData object including the encapContentInfo eContentType value of the signedData object including the
Receipt content. 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 contentType, signedContentIdentifier, and
originatorSignatureValue from the decoded Receipt structure to identify the originatorSignatureValue from the decoded Receipt structure to identify the
original signedData signerInfo that requested the signedData/Receipt. original signedData signerInfo that requested the signedData/Receipt.
3. Acquire the message signature digest value calculated by the sender to 3. Acquire the message signature digest value calculated by the sender to
generate the signature value included in the original signedData signerInfo generate the signature value included in the original signedData signerInfo
that requested the signedData/Receipt. that requested the signedData/Receipt.
3.1. If the sender-calculated message signature digest value has been 3.1. If the sender-calculated message signature digest value has been
saved locally by the sender, it must be located and retrieved. saved locally by the sender, it must be located and retrieved.
3.2. If it has not been saved, then it must be re-calculated based on 3.2. If it has not been saved, then it must be re-calculated based on
the original signedData content and authenticatedAttributes as the original signedData content and authenticatedAttributes as
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
skipping to change at line 640 skipping to change at line 729
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 have calculated the same message signature digest value as calculated by
the 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 contentType,
signedContentIdentifier, and signature value that were included in the signedContentIdentifier, and signature value that were included in the
original signedData signerInfo that requested the signedData/Receipt). original signedData signerInfo that requested the signedData/Receipt).
5.1. If the sender-calculated Receipt content digest value has been 5.1. If the sender-calculated Receipt content digest value has been
saved locally by the sender, it must be located and retrieved. saved locally by the sender, it must be located and retrieved.
5.2. If it has not been saved, then it must be re-calculated. As 5.2. If it has not been saved, then it must be re-calculated. As
described in section 2.4 above, step 2, create a Receipt structure described in section 2.4 above, step 2, create a Receipt structure
including the encapsulatedContentType, signedContentIdentifier and including the contentType, signedContentIdentifier and signature value
signature value that were included in the original signedData
signerInfo that requested the signed receipt. The Receipt structure is that were included in the original signedData signerInfo that requested
then ASN.1 DER encoded to produce a data stream which is then digested the signed receipt. The Receipt structure is then ASN.1 DER encoded to
to produce the Receipt content digest value. produce a data stream which is then digested 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 compared with the value of the messageDigest authenticatedAttribute
included in the signedData/Receipt signerInfo. If these digest values are included in the signedData/Receipt signerInfo. If these digest values are
identical, then that proves that the values included in the Receipt content identical, then that proves that the values included in the Receipt content
by the 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
skipping to change at line 697 skipping to change at line 787
used in conjunction with the CMS protocol is specific to the algorithm. used in conjunction with the CMS protocol is specific to the algorithm.
These processes are described in documents specific to the algorithms. These processes are described in documents specific to the algorithms.
2.7 Receipt Request Syntax 2.7 Receipt Request Syntax
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
receiptRequest attribute only within the authenticated attributes receiptRequest attribute only within the authenticated attributes
associated with a signed message. associated with a signed message.
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
The encapsulatedContentType field identifies the content type of the
original message. In BuiltinContentType, the values of 0 and 1 have been
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 {
built-in BuiltinContentType,
external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype }
BuiltinContentType ::= [APPLICATION 6] INTEGER {
-- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0),
external (1),
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22),
edi-messaging (35),
voice-messaging (40)} (0..ub-built-in-content-type)
ub-built-in-content-type INTEGER ::= 32767
ExternalContentType ::= OBJECT IDENTIFIER ContentIdentifier ::= OCTET STRING
ExternalContentWithSubtype ::= SEQUENCE { id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
external ExternalContentType, us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
subtype INTEGER }
A signedContentIdentifier MUST be created by the message originator when A signedContentIdentifier MUST be created by the message originator when
creating a receipt request. To ensure global uniqueness, the minimal creating a receipt request. To ensure global uniqueness, the minimal
signedContentIdentifier SHOULD contain a concatenation of user-specific signedContentIdentifier SHOULD contain a concatenation of user-specific
identification information (such as a user name or public keying material identification information (such as a user name or public keying material
identification information), a GeneralizedTime string, and a random number. identification information), a GeneralizedTime string, and a random number.
A contentType attribute including the id-ct-receipt object identifier
must be part of the receipt request.
The receiptsFrom field is used by the originator to specify the recipients The receiptsFrom field is used by the originator to specify the recipients
requested to return a signed receipt. A CHOICE is provided to allow requested to return a signed receipt. A CHOICE is provided to allow
specification of: specification of:
- receipts from all recipients are requested - receipts from all recipients are requested
- receipts from first tier (recipients that did not receive the - receipts from first tier (recipients that did not receive the
message as members of a mailing list) recipients are requested message as members of a mailing list) recipients are requested
- receipts from a specific list of recipients are requested - receipts from a specific list of recipients are requested
ReceiptsFrom ::= CHOICE { ReceiptsFrom ::= CHOICE {
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. The field is whom the identified recipient should send signed receipts. The message
mandatory, and the originator's name(s) MUST be included in the receiptsTo originator MUST populate the receiptsTo field with a GeneralNames for each
list. entity to whom the recipient should send the signed receipt. If the message
originator wants the recipient to send the signed receipt to the
originator, then the originator MUST include a GeneralNames for itself in
the receiptsTo field.
2.8 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, Receipt. The Receipt Receipts are represented using a new content type, Receipt. The Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
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}
The version field defines the syntax version number, which is 1 for this The version field defines the syntax version number, which is 1 for this
version of the standard. version of the standard.
The encapsulatedContentType and signedContentIdentifier fields are copied
from the receiptRequest attribute of the SignerInfo contained within the
message being receipted, and are used to link the receipt to the original
signed message. The originatorSignatureValue field contains the
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 UTF8String SIZE (1..MAX) OPTIONAL,
contentType OBJECT IDENTIFIER } contentType ContentType }
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)) }
The construct "SIZE (1..MAX)" is used in the DirectoryString syntax to id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
constrain each CHOICE to have at least one entry. MAX indicates that the rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
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 envelopedData object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. on the inner signedData object. The SIZE (1..MAX) construct constrains the
sequence to have at least one entry. MAX indicates the upper bound is
unspecified. Implementations are free to choose an upper bound that suits
their environment.
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an envelopedData
object, thus masking the inner content type of the message, SHOULD include object, thus masking the inner content type of the message, SHOULD include
a contentHints attribute, except for the case of the data content type. a contentHints attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion Specific message content types may either force or preclude the inclusion
of the contentHints attribute. For example, when a signedData/Receipt is of the contentHints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints be created that encapsulates the envelopedData object and a contentHints
attribute with contentType set to the id-ct-receipt object identifier MUST attribute with contentType set to the id-ct-receipt object identifier MUST
be included in the outer signedData SignerInfo authenticatedAttributes. be included in the outer signedData SignerInfo authenticatedAttributes.
2.10 Message Signature Digest Attribute
The msgSigDigest attribute can only be used in the authenticated attributes
of a signed receipt. It contains the digest of the ASN.1 DER encoded
authenticatedAttributes included in the original signedData that requested
the signed receipt. Only one msgSigDigest attribute can appear in an
authenticated attributes set. It is defined as follows:
msgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
3. Security Labels 3. Security Labels
This section describes the syntax to be used for security labels that can This section describes the syntax to be used for security labels that can
optionally be associated with S/MIME encapsulated data. A security label is optionally be associated with S/MIME encapsulated data. A security label is
a set of security information regarding the sensitivity of the content that a set of security information regarding the sensitivity of the content that
is protected by S/MIME encapsulation. is protected by S/MIME encapsulation.
"Authorization" is the act of granting rights and/or privileges to users "Authorization" is the act of granting rights and/or privileges to users
permitting them access to an object. "Access control" is a means of permitting them access to an object. "Access control" is a means of
enforcing these authorizations. The sensitivity information in a security enforcing these authorizations. The sensitivity information in a security
skipping to change at line 901 skipping to change at line 977
SignedData object may include multiple security labels, each SignerInfo SignedData object may include multiple security labels, each SignerInfo
having an eSSSecurityLabel 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 an eSSSecurityLabel attribute only if the A recipient SHOULD process an eSSSecurityLabel attribute only if the
recipient can verify the signature of the SignerInfo which covers the recipient can verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient SHOULD NOT use a security label eSSSecurityLabel attribute. A recipient SHOULD NOT use a security label
that the recipient cannot authenticate. that the recipient cannot authenticate. Local security policies should
exist for handling of messages which contain an eSSSecurityLabel attribute
only in SignerInfos which cannot be validated, or which contain multiple
valid SignerInfos where the security labels are not identical.
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
eSSSecurityLabel attribute, if present, in each SignerInfo in the eSSSecurityLabel attribute, if present, in each SignerInfo in the
SignedData object for which it verifies the signature. This may result in SignedData object for which it verifies the signature. This may result in
the receiving agent processing multiple security labels included in a the receiving agent processing multiple security labels included in a
single SignedData object. Because all security labels in a SignedData single SignedData object. Because all security labels in a SignedData
object must be identical, the receiving application processes (such as object must be identical, the receiving application processes (such as
performing access control) on the first eSSSecurityLabel that it encounters performing access control) on the first eSSSecurityLabel that it encounters
skipping to change at line 929 skipping to change at line 1009
eSSSecurityLabel security-policy-identifier value, it SHOULD stop eSSSecurityLabel security-policy-identifier value, it SHOULD stop
processing the message and indicate an error. processing the message and indicate an error.
3.2 Syntax of eSSSecurityLabel 3.2 Syntax of eSSSecurityLabel
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
::=".) Further, the eSSSecurityLabel syntax is compatible with that used in ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
[MSP4]. [MSP4].
The eSSSecurityLabel MUST be marked as critical.
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
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
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String OCTET STRING utf8String UTF8String SIZE (1..MAX)
-- 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 {
skipping to change at line 1016 skipping to change at line 1099
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
eSSSecurityLabel 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, through 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.
There is no universal definition of the rules for using these "basic There is no universal definition of the rules for using these "basic
hierarchy" values. Each organization (or group of organizations) will hierarchy" values. Each organization (or group of organizations) will
define a security policy which documents how the "basic hierarchy" values define a security policy which documents how the "basic hierarchy" values
are used (if at all) and how access control is enforced (if at all) within are used (if at all) and how access control is enforced (if at all) within
their domain. their domain.
skipping to change at line 1040 skipping to change at line 1123
than the US Government "secret" classification. In summary, a security than the US Government "secret" classification. In summary, a security
policy SHOULD NOT use integers 0 through 5 for other than their X.411 policy SHOULD NOT use integers 0 through 5 for other than their X.411
meanings, and SHOULD instead use other values in a hierarchical fashion. meanings, and SHOULD instead use other values in a hierarchical fashion.
Note that the set of valid security-classification values MUST be Note that the set of valid security-classification values MUST be
hierarchical, but these values do not necessarily need to be in ascending hierarchical, but these values do not necessarily need to be in ascending
numerical order. Further, the values do not need to be contiguous. numerical order. Further, the values do not need to be contiguous.
For example, in the Defense Message System 1.0 security policy, the For example, in the Defense Message System 1.0 security policy, the
security-classification value of 11 indicates Sensitive-But-Unclassified security-classification value of 11 indicates Sensitive-But-Unclassified
and 5 indicates top-secret. The hierarchy of sensistivity ranks top-secret and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret
as more sensitive than Sensitive-But-Unclassified even though the numerical as more sensitive than Sensitive-But-Unclassified even though the numerical
value of top-secret is less than Sensitive-But-Unclassified. value of top-secret is less than Sensitive-But-Unclassified.
(Of course, if security-classification values are both hierarchical and in (Of course, if security-classification values are both hierarchical and in
ascending order, a casual reader of the security policy is more likely to ascending order, a casual reader of the security policy is more likely to
understand it.) understand it.)
An example of a security policy that does not use any of the X.411 values An example of a security policy that does not use any of the X.411 values
might be: might be:
10 -- anyone 10 -- anyone
skipping to change at line 1100 skipping to change at line 1183
of a message directs the message to the MLA, which then redistributes the of a message directs the message to the MLA, which then redistributes the
message to the members of the ML. This process offloads the per-recipient message to the members of the ML. This process offloads the per-recipient
processing from individual user agents and allows for more efficient processing from individual user agents and allows for more efficient
management of large MLs. MLs are true message recipients served by MLAs management of large MLs. MLs are true message recipients served by MLAs
that provide cryptographic and expansion services for the mailing list. that provide cryptographic and expansion services for the mailing list.
In addition to cryptographic handling of messages, secure mailing lists In addition to cryptographic handling of messages, secure mailing lists
also have to prevent mail loops. A mail loop is where one mailing list is a also have to prevent mail loops. A mail loop is where one mailing list is a
member of a second mailing list, and the second mailing list is a member of member of a second mailing list, and the second mailing list is a member of
the first. A message will go from one list to the other in a the first. A message will go from one list to the other in a
rapidly-cascading sucession of mail that will be distributed to all other rapidly-cascading succession of mail that will be distributed to all other
members of boths lists. members of both lists.
To prevent mail loops, MLAs use the mlExpansionHistory attribute of the To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
outer signature of a triple wrapped message. The mlExpansionHistory outer signature of a triple wrapped message. The mlExpansionHistory
attribute is essentially a list of every MLA that has processed the attribute is essentially a list of every MLA that has processed the
message. If an MLA sees its own unique entity identifier in the list, it message. If an MLA sees its own unique entity identifier in the list, it
knows that a loop has been formed, and does not send the message to the knows that a loop has been formed, and does not send the message to the
list again. list again.
4.1 Mail List Expansion 4.1 Mail List Expansion
Mail list expansion processing is noted in the value of the Mail list expansion processing is noted in the value of the
mlExpansionHistory attribute, located in the authenticated attributes of mlExpansionHistory attribute, located in the authenticated attributes of
the MLA's SignerInfo block. The MLA creates or updates the authenticated the MLA's SignerInfo block. The MLA creates or updates the authenticated
mlExpansionHistory attribute value each time the MLA expands and signs a mlExpansionHistory attribute value each time the MLA expands and signs a
message for members of a mail list. message for members of a mail list.
The MLA MUST add an MLData record containing the MLA's identification The MLA MUST add an MLData record containing the MLA's identification
information, date and time of expansion, and optional receipt policy to the information, date and time of expansion, and optional receipt policy to the
end of the mail list expansion history sequence. If the mlExpansionHistory end of the mail list expansion history sequence. If the mlExpansionHistory
attribute is absent, then the MLA MUST add the attribute and the current attribute is absent, then the MLA MUST add the attribute and the current
skipping to change at line 1198 skipping to change at line 1281
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.
2. The MLA removes the existing recipientInfos field and replaces it with a 2. The MLA removes the existing recipientInfos field and replaces it with a
new recipientInfos value built from RecipientInfo structures created for new recipientInfos value built from RecipientInfo structures created for
each member of the mailing list. each member of the mailing list. The MLA also removes the existing
originatorInfo field and replaces it with a new originatorInfo value built
from information describing the MLA.
3. The MLA encapsulates the expanded encrypted message in a SignedData 3. The MLA encapsulates the expanded encrypted message in a SignedData
block, adding an mlExpansionHistory attribute as described in the "Mail block, adding an mlExpansionHistory attribute as described in the "Mail
List Expansion" section to document the expansion. List Expansion" section to document the expansion.
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to mail
list members to complete MLA processing. list members to complete MLA processing.
4.2.2 Processing for SignedData 4.2.2 Processing for SignedData
skipping to change at line 1254 skipping to change at line 1329
described in the "Detecting Mail List Expansion Loops" section. described in the "Detecting Mail List Expansion Loops" section.
3. Determine the type of the data that has been signed. That is, look at 3. Determine the type of the data that has been signed. That is, look at
the type of data on the layer just below the SignedData, which may or may the type of data on the layer just below the SignedData, which may or may
not be the "innermost" layer. Based on the type of data, perform either not be the "innermost" layer. Based on the type of data, perform either
step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
types). types).
3.1. If the signed data is EnvelopedData, the MLA performs expansion 3.1. If the signed data is EnvelopedData, the MLA performs expansion
processing of the encrypted message as described previously. Note that processing of the encrypted message as described previously. Note that
this process invalidates the signature value in the outermost this process invalidates the signature value in the outermost
SignedData layer associated with the original encrypted message. SignedData layer associated with the original encrypted message.
Proceed to section 3.2 with the result of the expansion. Proceed to section 3.2 with the result of the expansion.
3.2. If the signed data is SignedData, or is the result of expanding an 3.2. If the signed data is SignedData, or is the result of expanding an
EnvelopedData block in step 3.1: EnvelopedData block in step 3.1:
3.2.1. The MLA strips the existing outermost SignedData layer after 3.2.1. The MLA strips the existing outermost SignedData layer after
remembering the value of the mlExpansionHistory attribute in that remembering the value of the mlExpansionHistory and all other
layer, if one was there. authenticated attributes in that layer, if present.
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
encapsulates the expanded encrypted message in a new outermost encapsulates the expanded encrypted message in a new outermost
SignedData layer. On the other hand, if the signed data is SignedData layer. On the other hand, if the signed data is
SignedData (from step 3.2), the MLA encapsulates the signed data in SignedData (from step 3.2), the MLA encapsulates the signed data in
a new outermost SignedData layer. a new outermost SignedData layer.
3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData 3.2.3. The outermost signedData layer created by the MLA replaces
layer created by the MLA replaces the original outermost SignedData the original outermost signedData layer. The MLA MUST create an
layer. authenticated attribute list for the new outermost signedData layer
which MUST include each authenticated attribute present in the
original outermost signedData layer, unless the MLA explicitly
replaces one or more particular attributes with new value. A
special case is the mlExpansionHistory attribute. The MLA MUST add
an mlExpansionHistory authenticated attribute to the outer
signedData layer as follows:
3.2.3.1. If the original outermost SignedData layer included an 3.2.3.1. If the original outermost SignedData layer included an
mlExpansionHistory attribute, the attribute's value is copied mlExpansionHistory attribute, the attribute's value is copied
and updated with the current ML expansion information as and updated with the current ML expansion information as
described in the "Mail List Expansion" section. described in the "Mail List Expansion" section.
3.2.3.2. If the original outermost SignedData layer did not 3.2.3.2. If the original outermost SignedData layer did not
include an mlExpansionHistory attribute, a new attribute value include an mlExpansionHistory attribute, a new attribute value
is created with the current ML expansion information as is created with the current ML expansion information as
described in the "Mail List Expansion" section. described in the "Mail List Expansion" section.
3.3. If the signed data is not EnvelopedData or SignedData: 3.3. If the signed data is not EnvelopedData or SignedData:
3.3.1. The MLA encapsulates the received signedData object in an 3.3.1. The MLA encapsulates the received signedData object in an
outer SignedData object, and adds an mlExpansionHistory attribute outer SignedData object, and adds an mlExpansionHistory attribute
to the outer SignedData object containing the current ML expansion to the outer SignedData object containing the current ML expansion
information as described in the "Mail List Expansion" section. information as described in the "Mail List Expansion" section.
4. The MLA signs the new message and delivers the updated message to mail 4. The MLA signs the new message and delivers the updated message to mail
skipping to change at line 1312 skipping to change at line 1393
contain mlExpansionHistory? contain mlExpansionHistory?
YES -> Check it, then -> 3. YES -> Check it, then -> 3.
NO -> 3. NO -> 3.
3. Check type of data just below outermost 3. Check type of data just below outermost
SignedData. SignedData.
EnvelopedData -> 3.1. EnvelopedData -> 3.1.
SignedData -> 3.2. SignedData -> 3.2.
all others -> 3.3. all others -> 3.3.
3.1. Expand the encrypted message, then -> 3.2. 3.1. Expand the encrypted message, then -> 3.2.
3.2. -> 3.2.1. 3.2. -> 3.2.1.
3.2.1. Strip outermost SignedData layer, note value of 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
mlExpansionHistory, then -> 3.2.2. and other authenticated attributes, then -> 3.2.2.
3.2.2. Encapsulate in new signature, then -> 3.2.3. 3.2.2. Encapsulate in new signature, then -> 3.2.3.
3.2.3. Add mlExpansionHistory. Was there an old mlExpansionHistory? 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
YES -> copy the old mlExpansionHistory values, then -> 4. YES -> copy the old mlExpansionHistory values, then -> 4.
NO -> create new mlExpansionHistory value, then -> 4. NO -> create new mlExpansionHistory value, then -> 4.
3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
attribute, then -> 4. attribute, then -> 4.
4. Sign message, deliver it, STOP. 4. Sign message, deliver it, STOP.
4.2.3 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.
skipping to change at line 1331 skipping to change at line 1413
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 Signed Recipt Policy Processing 4.3 Mail List Agent Signed Receipt 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
the table). the table).
| B's policy | B's policy
A's policy | none insteadOf inAdditionTo missing A's policy | none insteadOf inAdditionTo missing
------------------------------------------------------------------------- -------------------------------------------------------------------------
none | none none none none none | none none none none
insteadOf | none insteadOf(B) insteadOf(A+B) insteadOf(A) insteadOf | none insteadOf(B) *1 insteadOf(A)
inAdditionTo | none insteadOf(B) inAdditionTo(A+B) inAditionTo(A) inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
missing | none insteadOf(B) inAddtionTo(B) missing missing | none insteadOf(B) inAdditionTo(B) missing
The interesting cases are combining insteadOf with inAddtionTo. The rest of *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
the cases either substitute in B's policy or propagate forward A's policy. *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 return an error. the processing agent should provide notification of the error to a human
mail list administrator. The mail list administrator is responsible for
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)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
MLData contains the expansion history describing each MLA that has MLData contains the expansion history describing each MLA that has
processed a message. As an MLA distributes a message to members of an ML, processed a message. As an MLA distributes a message to members of an ML,
the MLA records its unique identifier, date and time of expansion, and the MLA records its unique identifier, date and time of expansion, and
receipt policy in an MLData structure. receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS] -- EntityIdentifier is imported from [CMS]
skipping to change at line 1379 skipping to change at line 1466
receipt policy in an MLData structure. receipt policy in an MLData structure.
MLData ::= SEQUENCE { MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier, mailListIdentifier EntityIdentifier,
-- EntityIdentifier is imported from [CMS] -- EntityIdentifier is imported from [CMS]
expansionTime GeneralizedTime, expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL } mlReceiptPolicy MLReceiptPolicy OPTIONAL }
The receipt policy of the ML can withdraw the originator's request for The receipt policy of the ML can withdraw the originator's request for
the return of a signed receipt. However, if the originator of the the return of a signed receipt. However, if the originator of the
message has not requested a signed receipt, the MLA cannot request a message has not requested a signed receipt, the MLA cannot request a
signed receipt. signed receipt.
When present, the mlReceiptPolicy specifies a receipt policy that When present, the mlReceiptPolicy specifies a receipt policy that
supersedes the originator's request for signed receipts. The policy supersedes the originator's request for signed receipts. The policy
can be one of three possibilities: receipts MUST NOT be returned can be one of three possibilities: receipts MUST NOT be returned
(none); receipts should be returned to an alternate list of (none); receipts should be returned to an alternate list of
recipients, instead of to the originator (insteadOf); or receipts recipients, instead of to the originator (insteadOf); or receipts
should be returned to a list of recipients in addition to the should be returned to a list of recipients in addition to the
originator (inAdditionTo). originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..ub-insteadOf) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..ub-inAdditionTo) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
ub-insteadOf 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
ExtendedSecurityServices ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
skipping to change at line 1409 skipping to change at line 1492
5. Security Considerations 5. Security Considerations
This entire document discusses security. This entire document discusses security.
A. ASN.1 Module A. ASN.1 Module
ExtendedSecurityServices ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS -- UNIVERSAL type defined in ASN.1 1997 but required for
-- this specification
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
EntityIdentifier, SubjectKeyIdentifier, Version ContentType, EntityIdentifier, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
-- X.509 -- X.509
GeneralNames FROM CertificateExtensions GeneralNames FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services -- Extended Security Services
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains 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 their
-- environment.
-- Section 2.7 -- Section 2.7
ReceiptRequest ::= SEQUENCE { ReceiptRequest ::= SEQUENCE {
encapsulatedContentType EncapsulatedContentType OPTIONAL,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom, receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16 ub-receiptsTo INTEGER ::= 16
ContentIdentifier ::= OCTET STRING id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
EncapsulatedContentType ::= CHOICE {
built-in BuiltinContentType,
external ExternalContentType,
externalWithSubtype ExternalContentWithSubtype }
BuiltinContentType ::= [APPLICATION 6] INTEGER {
-- APPLICATION 6 is used for binary compatibility with X.411
unidentified (0),
external (1),
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22),
edi-messaging (35),
voice-messaging (40)} (0..ub-built-in-content-type)
ub-built-in-content-type INTEGER ::= 32767
ExternalContentType ::= OBJECT IDENTIFIER ContentIdentifier ::= OCTET STRING
ExternalContentWithSubtype ::= SEQUENCE { id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
external ExternalContentType, us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
subtype INTEGER }
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) }
-- Section 2.8 -- Section 2.8
Receipt ::= SEQUENCE { Receipt ::= SEQUENCE {
version Version, -- Version is imported from [CMS] version Version, -- Version is imported from [CMS]
encapsulatedContentType EncapsulatedContentType OPTIONAL, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
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}
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription DirectoryString OPTIONAL, contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
contentType OBJECT IDENTIFIER } contentType OBJECT IDENTIFIER }
DirectoryString ::= CHOICE { id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
teletexString TeletexString (SIZE (1..MAX)), rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
printableString PrintableString (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)), -- Section 2.10
universalString UniversalString (SIZE (1..MAX)) }
MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
-- Section 3.2 -- Section 3.2
ESSSecurityLabel ::= SET { ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL, security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL, privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL } security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
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
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)), pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String OCTET STRING utf8String UTF8String
-- 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 1547 skipping to change at line 1630
--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
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}
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..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..ub-inAdditionTo) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
ub-insteadOf INTEGER ::= 16
ub-inAdditionTo INTEGER ::= 16
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)"
skipping to change at line 1617 skipping to change at line 1699
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
2.4: An OID for msgSigDigest is needed. It will be an OCTET STRING. Should contentHints move to the CMS draft? If it is useful in other types
of specs, not just ESS, there may be a good reason to have it live in
CMS.
E. Changes from draft-ietf-smime-ess-01 to draft-ietf-smime-ess-02 We need to define better how a receiving MLA finds the outer signature that
should have the mlExpansionHistory in it. For instance, a well-formed
triple-wrapped message may pass through a gateway that signs it. We need
wording that says something to the effect of "keep going down through
signatures until you find an mlExpansionHistory attribute, throw away the
higher layers, and process this."
Fixed many typos found by John Pawling. Should mlExpansionHistory have a size of (1..MAX) or should we leave it
as 64?
Changed "SEQUENCE (SIZE (...))" to "SEQUENCE SIZE (...)" in many places in E. Changes from draft-ietf-smime-ess-02 to draft-ietf-smime-ess-03
the ASN.1.
1.1.2: Removed the requirement that the signatures be in Spelled eSSSecurityLabel better in a few places.
application/pkcs7-mime format, and allow either format for both the inner
and outer signatures.
1.2: Changed "eight" to "eleven" because, well, because there are eleven Changed "encapsulatedContentType" to "contentType" throughout the document.
items in the list.
1.3.2: First sentence, made it clear that you can have security labels in Added the OIDs for things that are defined in this draft throughout the text
any SignedData object. and added them to Appendix A.
1.3.4: Last paragraph, removed last sentence because it was confusing. 1: Changed the second paragraph to be clearer about how the extensions
affect interoperability.
2.3: Added sentence at the end of the second paragraph saying what (not) to 1.1.1: Replaced the first paragraph with a clearer one.
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.5: Step 1, made receiptsTo required. 1.1.2: Completely rewritten.
2.7: In ReceiptRequest, receiptsTo is no longer OPTIONAL. Same change made 1.2: Completely rewritten.
in Appendix A. Also changed the wording at the end of this section about
1.3.4: In the table, specified contentType MUST be authenticated. Also
added msgSigDigest. Also added the origin of the OID in the table.
1.4: Changed the wording to say where the OIDs are found.
1.5: Added this section on criticality of attributes.
2.2: Removed step 2 and renumbered the rest of the steps.
2.2, bullet 4: Replaced the entire paragraph to describe that the
receiptsTo field MUST be populated.
2.3: In the third paragraph, changed MUST to SHOULD for sending the signed
receipt.
2.4, bullet 2.2 and 2.3: Revised to no longer include contentType in the
Receipt.
2.4, bullet 9: Changed "contentInfo content ANY" with "encapContentInfo
eContent OCTET STRING".
2.5, bullet 1: Removed wording about what to do if there isn't a
receiptsTo. receiptsTo.
2.7: Added a sentence in the text preceding EncapsulatedContentType 2.6: Changed "contentInfo content ANY" with "encapContentInfo eContent
describing what values to use. OCTET STRING".
2.9: Changed "encrypted data" to "envelopedData" to indicate the type we 2.7: Removed the discussion of what an encapsulatedContentType is. Also
are using. Also changed "signed data" to "signedData". Also changed changed the wording about the receiptsTo to show it is mandatory.
"content hints" to "contentHints". Also removed the optional contentType from the ReceiptRequest.
2.9: Changed "OID" in the ASN.1 to "OBJECT IDENTIFIER". Also changed 2.8: Made the contentType in the Receipt structure non-optional.
"maxSize" to "MAX". Put wording after the ASN.1 about what MAX means here.
Also made these changes in Appendix A.
3.2: Removed the reference to ACP120, and also removed that from the 2.9: Made contentDescription a UTF8String with a SIZE. Updated Appendix A
references appendix. for these changes. Thus, the DirectoryString is deleted.
3.2: Changed "SecurityLabel" to "ESSSecurityLabel", made the privacy mark 2.10: Added this entire section.
"ESSPrivacyMark", and changed that mark to be a choice which allows
utf8String. Made same change in Appendix A. Made many changes to the text
to use this new name.
4.2: Added third paragraph saying that all attributes must be propagated 3.1.1: Added last sentence to last paragraph.
forwards.
B: Added reference to UTF-8. 3.2: Changed the definition of ESSPrivacy mark to use UTF8String and to not
include the optional language tag. Also added the length. Also stated
"The eSSSecurityLabel MUST be marked as critical."
4.2: Removed the paragraph that talked about changing attributes.
4.2.1: In step 2, added that the MLA also replaces the originatorInfo.
4.2.2, bullets 3.2.1 and 3.2.3: Replaced the bullets.
4.3: Made clarifications in the chart. Added two lengthy items to the
chart's legend.
4.4: Changed the sizes insteadOf and inAdditionTo. Also described better
what the processing agent does in case of too many lists being listed.
A: Added the definition of UTF8String at the beginning of the module. Added
ContentType to the list of imports from CMS. Added comment near the
beginning about SIZE (1..MAX). Updated all the changes from above.
F. Editor's Address F. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
(408) 426-9827 (408) 426-9827
phoffman@imc.org phoffman@imc.org
 End of changes. 

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