|
Network Working Group Request for Comments: 2634 Category: Standards Track |
P. Hoffman, Editor Internet Mail Consortium June 1999 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (1999). All Rights Reserved.
This document describes four optional security service extensions for S/MIME. The services are:
- signed receipts
- security labels
- secure mailing lists
- signing certificates
The first three of these services provide functionality that is similar to the Message Security Protocol [MSP4], but are useful in many other environments, particularly business and finance. Signing certificates are useful in any environment where certificates might be transmitted with signed messages.
The services described here are extensions to S/MIME version 3 ([MSG] and [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2]. The extensions described here will not cause an S/MIME version 3 recipient to be unable to read messages from an S/MIME version 2 sender. However, some of the extensions will cause messages created by an S/MIME version 3 sender to be unreadable by an S/MIME version 2 recipient.
This document describes both the procedures and the attributes needed for the four services. Note that some of the attributes described in this document are quite useful in other contexts and should be considered when extending S/MIME or other CMS applications.
The format of the messages are described in ASN.1:1988 [ASN1-1988].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD].
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 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 specification does not limit the number of nested encapsulations, so there may be more than three wrappings.
Not all messages need to be triple wrapped. Triple wrapping is used when a message must be signed, then encrypted, and then have signed attributes bound to the encrypted body. Outer attributes may be added or removed by the message originator or intermediate agents, and may be signed by intermediate agents or the final recipient.
The inside signature is used for content integrity, non-repudiation with proof of origin, and binding attributes (such as a security label) to the original content. These attributes go from the originator to the recipient, regardless of the number of intermediate entities such as mail list agents that process the message. The signed attributes can be used for access control to the inner body. Requests for signed receipts by the originator are carried in the inside signature as well.
The encrypted body provides confidentiality, including
confidentiality of the attributes that are carried in the inside
signature.
The outside signature provides authentication and integrity for information 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 security label) to the encrypted body. These attributes can be used for access control and routing decisions.
The steps to create a triple wrapped message are:
- If you are signing using multipart/signed, the MIME construct
added consists of a Content-type of multipart/signed with
parameters, the boundary, the result of step 2 above, the
boundary, a Content-type of application/pkcs7-signature,
optional MIME headers (such asContent-transfer-encoding and
Content-disposition), and a body part that is the result of
step 3 above.
- If you are instead signing using application/pkcs7-mime, the MIME
construct added consists of a Content-type of
application/pkcs7-mime with parameters, optional MIME headers
(such as Content-transfer-encoding and Content-disposition), and
the result of step 3 above.
A triple wrapped message has many layers of encapsulation. The structure 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.
There is no need to use the multipart/signed format in an inner
signature because it is known that the recipient is able to process
S/MIME messages (because they decrypted the middle wrapper). A
sending agent might choose to use the multipart/signed format in the
outer layer so that a non-S/MIME agent could see that the next inner
layer is encrypted; however, this is not of great value, since all it
shows the recipient is that the rest of the message is unreadable.
Because many sending agents always use multipart/signed structures,
all receiving agents MUST be able to interpret either
multipart/signed or application/pkcs7-mime signature structures.
The format of a triple wrapped message that uses multipart/signed for both signatures is:
[step 8] Content-type: multipart/signed;
[step 8] protocol="application/pkcs7-signature"; [step 8] boundary=outerboundary [step 8] [step 8] --outerboundary [step 6] Content-type: application/pkcs7-mime; ) [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] inner SignedData block (eContent is missing) | )
[step 4] | )
[step 4] --innerboundary-- | )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] outer SignedData block (eContent is missing)
[step 8]
[step 8] --outerboundary--
% = 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 both signatures is:
[step 8] Content-type: application/pkcs7-mime;
[step 8] smime-type=signed-data
[step 8]
[step 7] outer SignedData block (eContent is present) O
[step 6] Content-type: application/pkcs7-mime; ) O
[step 6] smime-type=enveloped-data; ) O
[step 6] ) O
[step 4] Content-type: application/pkcs7-mime; | ) O
[step 4] smime-type=signed-data | ) O
[step 4] | ) O
[step 3] inner SignedData block (eContent is present) I | ) O
[step 2] Content-type: text/plain I | ) O
[step 2] I | ) O
[step 1] Original content I | ) O
I = These lines are the inner SignedData block, which 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.
O = These lines are the outer SignedData block, which is opaque and
contains the ASN.1 encoded result of step 6 as well as control
information.
The first three security services described in this document are used with triple wrapped messages in different ways. This section briefly describes the relationship of each service with triple wrapping; the other sections of the document go into greater detail.
A signed receipt may be requested in any SignedData object. However, if a signed receipt is requested for a triple wrapped message, the receipt request MUST be in the inside signature, not in the outside signature. A secure mailing list agent may change the receipt policy in the outside signature of a triple wrapped message when that message is processed by the mailing list.
Note: the signed receipts and receipt requests described in this memo differ from those described in the work done by the IETF Receipt Notification Working Group. The output of that Working Group, when finished, is not expected to work well with triple wrapped messages as described in this document.
A security label may be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both.
The inner security label is used for access control decisions related to the plaintext original content. The inner signature provides authentication and cryptographically protects the integrity of the original signer's security label that is in the inside body. This strategy facilitates the forwarding of messages 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 signature which will cover the inner security label. The confidentiality security service can be applied to the inner security label by encrypting the entire inner SignedData block within an EnvelopedData block.
A security label may also be included in the signed attributes of the outer SignedData block which will include the sensitivities of the encrypted message. The outer security label is used for access control and routing decisions related to the encrypted message. Note
that a security label attribute can only be used in a
signedAttributes block. An eSSSecurityLabel attribute MUST NOT be
used in an EnvelopedData or unsigned attributes.
Secure mail list message processing depends on the structure of S/MIME layers present in the message sent to the mail list agent. The mail list agent never 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 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 agent's processing, and ultimately adds or replaces the outer signature on the message to be distributed.
Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes
must be signed, while signing is optional for others, and some
attributes must not be signed. ESS defines several types of
attributes. ContentHints and ContentIdentifier MAY appear in any
list of attributes. contentReference, equivalentLabel,
eSSSecurityLabel and mlExpansionHistory MUST be carried in a
SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
msgSigDigest, receiptRequest and signingCertificate MUST be carried
in a SignedAttributes, and MUST NOT be carried in a AuthAttributes,
UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
The following table summarizes the recommendation of this profile. In the OID column, [ESS] indicates that the attribute is defined in this document.
| |Inner or |
Attribute |OID |outer |Signed
------------------|----------------------------- |----------|--------
contentHints |id-aa-contentHint [ESS] |either |MAY
contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
contentReference |id-aa-contentReference [ESS] |either |MUST
contentType |id-contentType [CMS] |either |MUST
counterSignature |id-countersignature [CMS] |either |MUST NOT
equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
messageDigest |id-messageDigest [CMS] |either |MUST
msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
signingTime |id-signingTime [CMS] |either |MUST
smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
sMIMEEncryption-
KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
CMS defines signedAttrs as a SET OF Attribute and defines
unsignedAttrs as a SET OF Attribute. ESS defines the contentHints,
contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
receiptRequest, contentReference, equivalentLabels and
signingCertificate attribute types. A signerInfo MUST NOT include
multiple instances of any of the attribute types defined in ESS.
Later sections of ESS specify further restrictions that apply to the
receiptRequest, mlExpansionHistory and eSSecurityLabel attribute
types.
CMS defines the syntax for the signed and unsigned attributes as "attrValues SET OF AttributeValue". For all of the attribute types defined in ESS, if the attribute type is present in a signerInfo, then it MUST only include a single instance of AttributeValue. In other words, there MUST NOT be zero, or multiple, instances of AttributeValue present in the attrValues SET OF AttributeValue.
If a counterSignature attribute is present, then it MUST be included
in the unsigned attributes. It MUST NOT be included in the signed
attributes. The only attributes that are allowed in a
counterSignature attribute are counterSignature, messageDigest,
signingTime, and signingCertificate.
Note that the inner and outer signatures are usually those of different senders. Because of this, the same attribute in the two signatures could lead to very different consequences.
ContentIdentifier is an attribute (OCTET STRING) used to carry a unique identifier assigned to the message.
Some security gateways sign messages that pass through them. If the message is any type other than a signedData type, the gateway has only one way to sign the message: by wrapping it with a signedData block and MIME headers. If the message to be signed by the gateway is a signedData message already, the gateway can sign the message by inserting a signerInfo into the signedData block.
The main advantage of a gateway adding a signerInfo instead of wrapping the message in a new signature is that the message doesn't grow as much as if the gateway wrapped the message. The main disadvantage is that the gateway must check for the presence of certain attributes in the other signerInfos and either omit or copy those attributes.
If a gateway or other processor adds a signerInfo to an existing signedData block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes from other signerInfos. This helps ensure that the recipient will process those attributes in a signerInfo that it can verify.
Note that someone may in the future define an attribute that must be present in each signerInfo of a signedData block in order for the signature to be processed. If that happens, a gateway that inserts signerInfos and doesn't copy that attribute will cause every message with that attribute to fail when processed by the recipient. For this reason, it is safer to wrap messages with new signatures than to insert signerInfos.
The object identifiers for many of the objects described in this memo are found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME can be found in the registry kept at
<http://www.imc.org/ietf-smime/oids.html>. When this memo moves to standards track within the IETF, it is intended that the IANA will maintain this registry.
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 the recipient was able to verify the signature of the original message. This receipt is bound to the original message through the signature; consequently, this service may be requested only if a message is signed. The receipt sender may optionally also encrypt a receipt to provide confidentiality between the receipt sender and the receipt recipient.
The originator of a message may request a signed receipt from the message's recipients. The request is indicated by adding a receiptRequest attribute to the signedAttributes field of the SignerInfo object for which the receipt is requested. The receiving user agent software SHOULD automatically create a signed receipt when requested to do so, and return the receipt in accordance with mailing list expansion options, local security policies, and configuration options.
Because receipts involve the interaction of two parties, the terminology can sometimes be confusing. In this section, the "sender" is the agent that sent the original message that included a request for a receipt. The "receiver" is the party that received that message and generated the receipt.
The steps in a typical transaction are:
The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 syntax for the receipt is given in Section 2.8.
Note that a sending agent SHOULD remember when it has sent a receipt so that it can avoid re-sending a receipt each time it processes the message.
A receipt request can indicate that receipts be sent to many places, not just to the sender (in fact, the receipt request might indicate that the receipts should not even go to the sender). In order to verify a receipt, the recipient of the receipt must be the originator or a recipient of the original message. Thus, the sender SHOULD NOT request that receipts be sent to anyone who does not have an exact copy of the message.
Multi-layer S/MIME messages may contain multiple SignedData layers. However, receipts may be requested only for the innermost SignedData layer in a multi-layer S/MIME message, such as a triple wrapped message. Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo.
A ReceiptRequest attribute MUST NOT be included in the attributes of a SignerInfo in a SignedData object that encapsulates a Receipt content. In other words, the receiving agent MUST NOT request a signed receipt for a signed receipt.
A sender requests receipts by placing a receiptRequest attribute in the signed attributes of a signerInfo as follows:
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
Each recipient SHOULD return only one signed receipt.
Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.
The sending agent MUST retain one or both of the following items to support the validation of signed receipts returned by the recipients.
- the original signedData object requesting the signed receipt
- the message signature digest value used to generate the original
signedData signerInfo signature value and the digest value of the
Receipt content containing values included in the original
signedData object. If signed receipts are requested from multiple
recipients, then retaining these digest values is a performance
enhancement because the sending agent can reuse the saved values
when verifying each returned signed receipt.
A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.
Before processing a receiptRequest signedAttribute, the receiving
agent MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a
receiptRequest attribute that has not been verified. Because all
receiptRequest attributes in a SignedData object must be identical,
the receiving application fully processes (as described in the
following paragraphs) the first receiptRequest attribute that it
encounters in a SignerInfo that it verifies, and it then ensures that
all other receiptRequest attributes in signerInfos that it verifies
are identical to the first one encountered. If there are verified
ReceiptRequest attributes which are not the same, then the processing
software MUST NOT return any signed receipt. A signed receipt SHOULD
be returned if any signerInfo containing a receiptRequest attribute
can be validated, even if other signerInfos containing the same
receiptRequest attribute cannot be validated because they are signed
using an algorithm not supported by the receiving agent.
If a receiptRequest attribute is absent from the signed attributes, then a signed receipt has not been requested from any of the message recipients and MUST NOT be created. If a receiptRequest attribute is present in the signed attributes, then a signed receipt has been requested from some or all of the message recipients. Note that in some cases, a receiving agent might receive two almost-identical messages, one with a receipt request and the other without one. In this case, the receiving agent SHOULD send a signed receipt for the message that requests a signed receipt.
If a receiptRequest attribute is present in the signed attributes, the following process SHOULD be used to determine if a message recipient has been requested to return a signed receipt.
A flow chart for the above steps to be executed for each signerInfo for which the receiving agent verifies the signature would be:
A signed receipt is a signedData object encapsulating a Receipt content (also called a "signedData/Receipt"). Signed receipts are created as follows:
All sending agents that support the generation of ESS signed receipts MUST provide the ability to send encrypted signed receipts (that is, a signedData/Receipt encapsulated within an envelopedData). The sending agent MAY send an encrypted signed receipt in response to an envelopedData-encapsulated signedData requesting a signed receipt. It is a matter of local policy regarding whether or not the signed receipt should be encrypted. The ESS signed receipt includes the message digest value calculated for the original signedData object that requested the signed receipt. If the original signedData object was sent encrypted within an envelopedData object and the ESS signed receipt is sent unencrypted, then the message digest value calculated for the original encrypted signedData object is sent unencrypted. The responder should consider this when deciding whether or not to encrypt the ESS signed receipt.
An MLExpansionHistory attribute MUST NOT be included in the
attributes of a SignerInfo in a SignedData object that encapsulates a
Receipt content. This is true because when a SignedData/Receipt is
sent to an MLA for distribution, then the MLA must always encapsulate
the received SignedData/Receipt in an outer SignedData in which the
MLA will include the MLExpansionHistory attribute. The MLA cannot
change the signedAttributes of the received SignedData/Receipt
object, so it can't add the MLExpansionHistory to the
SignedData/Receipt.
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 whom the signed receipt should be sent.
A signed receipt is communicated as a single ASN.1 encoded object composed of a signedData object directly including a Receipt content. It is identified by the presence of the id-ct-receipt object identifier in the encapContentInfo eContentType value of the signedData object including the Receipt content.
Although recipients are not supposed to send more than one signed receipt, receiving agents SHOULD be able to accept multiple signed receipts from a recipient.
A signedData/Receipt is validated as follows:
original signedData object is the same as that calculated by the sender. This proves that the recipient received exactly the same original signedData content and signedAttributes as sent by the sender because that is the only way that the recipient could have calculated the same message signature digest value as calculated by the sender. If the digest values are different, then the signedData/Receipt signature verification process fails.
signerInfo. Note that the signedAttributes include the recipient-calculated Receipt content digest value (messageDigest attribute) and recipient-calculated message signature digest value (msgSigDigest attribute). Therefore, the aforementioned comparison of the sender-generated and recipient-generated digest values combined with the successful signedData/Receipt signature verification proves that the recipient received the exact original signedData content and signedAttributes (proven by msgSigDigest attribute) that were signed by the sender of the original signedData object (proven by messageDigest attribute). If the signature verification fails, then the signedData/Receipt signature verification process fails.
The signature verification process for each signature algorithm that is used in conjunction with the CMS protocol is specific to the algorithm. These processes are described in documents specific to the algorithms.
A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the receiptRequest attribute only within the signed attributes associated with a signed message.
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16
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}
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
A signedContentIdentifier MUST be created by the message originator when creating a receipt request. To ensure global uniqueness, the minimal signedContentIdentifier SHOULD contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.
The receiptsFrom field is used by the originator to specify the recipients requested to return a signed receipt. A CHOICE is provided to allow specification of:
- receipts from all recipients are requested
- receipts from first tier (recipients that did not receive the
message as members of a mailing list) recipients are requested
- receipts from a specific list of recipients are requested
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to whom the identified recipient should send signed receipts. The message originator MUST populate the receiptsTo field with a GeneralNames for each 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.
Receipts are represented using a new content type, Receipt. The Receipt content type shall have ASN.1 type Receipt. Receipts must be encapsulated within a SignedData message.
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
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}
ESSVersion ::= INTEGER { v1(1) }
The version field defines the syntax version number, which is 1 for this version of the standard.
Many applications find it useful to have information that describes the innermost signed content of a multi-layer message available on the outermost signature layer. The contentHints attribute provides such information.
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that
the 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 appear on the signedData object enclosing an
envelopedData object and not 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 object, thus masking the inner content type of the message, SHOULD include a contentHints attribute, except for the case of the data content type. Specific message content types may either force or preclude the inclusion of the contentHints attribute. For example, when a signedData/Receipt is encrypted within an envelopedData object, an outer signedData object MUST be created that encapsulates the envelopedData object and a contentHints attribute with contentType set to the id-ct-receipt object identifier MUST be included in the outer signedData SignerInfo signedAttributes.
The msgSigDigest attribute can only be used in the signed attributes of a signed receipt. It contains the digest of the ASN.1 DER encoded signedAttributes included in the original signedData that requested the signed receipt. Only one msgSigDigest attribute can appear in a signed 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}
The contentReference attribute is a link from one SignedData to
another. It may be used to link a reply to the original message to
which it refers, or to incorporate by reference one SignedData into
another. The first SignedData MUST include a contentIdentifier signed
attribute, which SHOULD be constructed as specified in section 2.7.
The second SignedData links to the first by including a
ContentReference signed attribute containing the content type,
content identifier, and signature value from the first SignedData.
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
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 a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation.
"Authorization" is the act of granting rights and/or privileges to users permitting them access to an object. "Access control" is a means of enforcing these authorizations. The sensitivity information in a security label can be compared with a user's authorizations to determine if the user is allowed to access the content that is protected by S/MIME encapsulation.
Security labels may be used for other purposes such as a source of
routing information. The labels often describe ranked levels
("secret", "confidential", "restricted", and so on) or are role-
based, describing which kind of people can see the information
("patient's health-care team", "medical billing agents",
"unrestricted", and so on).
A sending agent may include a security label attribute in the signed attributes of a signedData object. A receiving agent examines the security label on a received message and determines whether or not the recipient is allowed to see the contents of the message.
A sending agent that is using security labels MUST put the security label attribute in the signedAttributes field of a SignerInfo block. The security label attribute MUST NOT be included in the unsigned attributes. Integrity and authentication security services MUST be applied to the security label, therefore it MUST be included as a signed attribute, if used. This causes the security label attribute to be part of the data that is hashed to form the SignerInfo signature value. A SignerInfo block MUST NOT have more than one security label signed attribute.
When there are multiple SignedData blocks applied to a message, a security label attribute may be included in either the inner signature, outer signature, or both. A security label signed attribute may be included in a signedAttributes field within the inner SignedData block. The inner security label will include the sensitivities of the original content and will be used for access control decisions related to the plaintext encapsulated content. The inner signature provides authentication of the inner security label and cryptographically protects the original signer's inner security label of the original content.
When the originator signs the plaintext content and signed attributes, the inner security label is bound to the plaintext content. An intermediate entity cannot change the inner security label without invalidating the inner signature. The confidentiality security service can be applied to the inner security label by encrypting the entire inner signedData object within an EnvelopedData block.
A security label signed attribute may also be included in a signedAttributes field within the outer SignedData block. The outer security label will include the sensitivities of the encrypted
message and will be used for access control decisions related to the encrypted message and for routing decisions. The outer signature provides authentication of the outer security label (as well as for the encapsulated content which may include nested S/MIME messages).
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple eSSSecurityLabels, each SignerInfo having an eSSSecurityLabel attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. If any of the SignerInfos included in a SignedData object include an eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData object MUST include an eSSSecurityLabel attribute and the value of each MUST be identical.
Before processing an eSSSecurityLabel signedAttribute, the receiving agent MUST verify the signature of the SignerInfo which covers the eSSSecurityLabel attribute. A recipient MUST NOT process an eSSSecurityLabel attribute that has not been verified.
A receiving agent MUST process the eSSSecurityLabel attribute, if present, in each SignerInfo in the SignedData object for which it verifies the signature. This may result in the receiving agent processing multiple eSSSecurityLabels included in a single SignedData object. Because all eSSSecurityLabels in a SignedData object must be identical, the receiving agent processes (such as performing access control) on the first eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and then ensures that all other eSSSecurityLabels in signerInfos that it verifies are identical to the first one encountered. If the eSSSecurityLabels in the signerInfos that it verifies are not all identical, then the receiving agent MUST warn the user of this condition.
Receiving agents SHOULD have a local policy regarding whether or not to show the inner content of a signedData object that includes an eSSSecurityLabel security-policy-identifier that the processing software does not recognize. If the receiving agent does not recognize the eSSSecurityLabel security-policy-identifier value, then it SHOULD stop processing the message and indicate an error.
The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. (The MTSAbstractService module begins with "DEFINITIONS
IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is
compatible with that used in [MSP4].
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark 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
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
-- --SECURITY-CATEGORY MACRO ::=
--BEGIN --TYPE NOTATION ::= type | empty --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
This section gives more detail on the the various components of the eSSSecurityLabel syntax.
A security policy is a set of criteria for the provision of security services. The eSSSecurityLabel security-policy-identifier is used to identify the security policy in force to which the security label relates. It indicates the semantics of the other security label components.
This specification defines the use of the Security Classification field exactly as is specified in the X.411 Recommendation, which states in part:
If present, a security-classification may have one of a
hierarchical list of values. The basic security-classification
hierarchy is defined in this Recommendation, but the use of these
values is defined by the security-policy in force. Additional
values of security-classification, and their position in the
hierarchy, may also be defined by a security-policy as a local
matter or by bilateral agreement. The basic security-
classification hierarchy is, in ascending order: unmarked,
unclassified, restricted, confidential, secret, top-secret.
This means that the security policy in force (identified by the
eSSSecurityLabel security-policy-identifier) defines the
SecurityClassification integer values and their meanings.
An organization can develop its own security policy that defines the SecurityClassification INTEGER values and their meanings. However, the general interpretation of the X.411 specification is that the values of 0 through 5 are reserved for the "basic hierarchy" values
of unmarked, unclassified, restricted, confidential, secret, and top-secret. Note that 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.
There is no universal definition of the rules for using these "basic hierarchy" values. Each organization (or group of organizations) will 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 their domain.
Therefore, the security-classification value MUST be accompanied by a security-policy-identifier value to define the rules for its use. For example, a company's "secret" classification may convey a different meaning than the US Government "secret" classification. In summary, a security 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.
Note that the set of valid security-classification values MUST be hierarchical, but these values do not necessarily need to be in ascending numerical order. Further, the values do not need to be contiguous.
For example, in the Defense Message System 1.0 security policy, the security-classification value of 11 indicates Sensitive-But- Unclassified and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret as more sensitive than Sensitive-But-Unclassified even though the numerical value of top-secret is less than Sensitive-But-Unclassified.
(Of course, if security-classification values are both hierarchical and in ascending order, a casual reader of the security policy is more likely to understand it.)
An example of a security policy that does not use any of the X.411 values might be:
10 -- anyone
15 -- Morgan Corporation and its contractors
20 -- Morgan Corporation employees
25 -- Morgan Corporation board of directors
An example of a security policy that uses part of the X.411 hierarchy might be:
0 -- unmarked
1 -- unclassified, can be read by everyone
2 -- restricted to Timberwolf Productions staff
6 -- can only be read to Timberwolf Productions executives
If present, the eSSSecurityLabel privacy-mark is not used for access control. The content of the eSSSecurityLabel privacy-mark may be defined by the security policy in force (identified by the eSSSecurityLabel security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label.
If present, the eSSSecurityLabel security-categories provide further granularity for the sensitivity of the message. The security policy in force (identified by the eSSSecurityLabel security-policy- identifier) is used to indicate the syntaxes that are allowed to be present in the eSSSecurityLabel security-categories. Alternately, the security-categories and their values may be defined by bilateral agreement.
Because organizations are allowed to define their own security policies, many different security policies will exist. Some organizations may wish to create equivalencies between their security policies with the security policies of other organizations. For example, the Acme Company and the Widget Corporation may reach a bilateral agreement that the "Acme private" security-classification value is equivalent to the "Widget sensitive" security-classification value.
Receiving agents MUST NOT process an equivalentLabels attribute in a
message if the agent does not trust the signer of that attribute to
translate the original eSSSecurityLabel values to the security policy
included in the equivalentLabels attribute. Receiving agents have the
option to process equivalentLabels attributes but do not have to. It
is acceptable for a receiving agent to only process
eSSSecurityLabels. All receiving agents SHOULD recognize
equivalentLabels attributes even if they do not process them.
The EquivalentLabels signed attribute is defined as:
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
As stated earlier, the ESSSecurityLabel contains the sensitivity values selected by the original signer of the signedData. If an ESSSecurityLabel is present in a signerInfo, all signerInfos in the signedData MUST contain an ESSSecurityLabel and they MUST all be identical. In addition to an ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed attribute. If present, the equivalentLabels attribute MUST include one or more security labels that are believed by the signer to be semantically equivalent to the ESSSecurityLabel attribute included in the same signerInfo.
All security-policy object identifiers MUST be unique in the set of
ESSSecurityLabel and EquivalentLabels security labels. Before using
an EquivalentLabels attribute, a receiving agent MUST ensure that all
security-policy OIDs are unique in the security label or labels
included in the EquivalentLabels. Once the receiving agent selects
the security label (within the EquivalentLabels) to be used for
processing, then the security-policy OID of the selected
EquivalentLabels security label MUST be compared with the
ESSSecurityLabel security-policy OID to ensure that they are unique.
In the case that an ESSSecurityLabel attribute is not included in a signerInfo, then an EquivalentLabels attribute may still be included. For example, in the Acme security policy, the absence of an ESSSecurityLabel could be defined to equate to a security label composed of the Acme security-policy OID and the "unmarked" security-classification.
Note that equivalentLabels MUST NOT be used to convey security labels
that are semantically different from the ESSSecurityLabel included in
the signerInfos in the signedData. If an entity needs to apply a
security label that is semantically different from the
ESSSecurityLabel, then it MUST include the sematically different
security label in an outer signedData object that encapsulates the
signedData object that includes the ESSSecurityLabel.
If present, the equivalentLabels attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET OF Attribute. A signerInfo MUST NOT include multiple instances of the equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF
AttributeValue. A equivalentLabels attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
A receiving agent SHOULD process the ESSSecurityLabel before
processing any EquivalentLabels. If the policy in the
ESSSecurityLabel is understood by the receiving agent, it MUST
process that label and MUST ignore all EquivalentLabels.
When processing an EquivalentLabels attribute, the receiving agent MUST validate the signature on the EquivalentLabels attribute. A receiving agent MUST NOT act on an equivalentLabels attribute for which the signature could not be validated, and MUST NOT act on an equivalentLabels attribute unless that attribute is signed by an entity trusted to translate the original eSSSecurityLabel values to the security policy included in the equivalentLabels attribute. Determining who is allowed to specify equivalence mappings is a local policy. If a message has more than one EquivalentLabels attribute, the receiving agent SHOULD process the first one that it reads and validates that contains the security policy of interest to the receiving agent.
Sending agents must create recipient-specific data structures for each recipient of an encrypted message. This process can impair performance for messages sent to a large number of recipients. Thus, Mail List Agents (MLAs) that can take a single message and perform the recipient-specific encryption for every recipient are often desired.
An MLA appears to the message originator as a normal message recipient, but the MLA acts as a message expansion point for a Mail List (ML). The sender 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 processing from individual user agents and allows for more efficient management of large MLs. MLs are true message recipients served by MLAs that provide cryptographic and expansion services for the mailing list.
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 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 rapidly-cascading succession of mail that will be distributed to all other members of both lists.
To prevent mail loops, MLAs use the mlExpansionHistory attribute of
the outer signature of a triple wrapped message. The
mlExpansionHistory 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 knows that a loop has been formed, and
does not send the message to the list again.
Mail list expansion processing is noted in the value of the mlExpansionHistory attribute, located in the signed attributes of the MLA's SignerInfo block. The MLA creates or updates the signed mlExpansionHistory attribute value each time the MLA expands and signs a message for members of a mail list.
The MLA MUST add an MLData record containing the MLA's identification information, date and time of expansion, and optional receipt policy to the end of the mail list expansion history sequence. If the mlExpansionHistory attribute is absent, then the MLA MUST add the attribute and the current expansion becomes the first element of the sequence. If the mlExpansionHistory attribute is present, then the MLA MUST add the current expansion information to the end of the existing MLExpansionHistory sequence. Only one mlExpansionHistory attribute can be included in the signedAttributes of a SignerInfo.
Note that if the mlExpansionHistory attribute is absent, then the recipient is a first tier message recipient.
There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a mlExpansionHistory attribute. For example, an MLA can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature.
If an MLA creates a SignerInfo that includes an mlExpansionHistory attribute, then all of the SignerInfos created by the MLA for that SignedData object MUST include an mlExpansionHistory attribute, and the value of each MUST be identical. Note that other agents might later add SignerInfo attributes to the SignedData block, and those additional SignerInfos might not include mlExpansionHistory attributes.
A recipient MUST verify the signature of the SignerInfo which covers
the mlExpansionHistory attribute before processing the
mlExpansionHistory, and MUST NOT process the mlExpansionHistory
attribute unless the signature over it has been verified. If a
SignedData object has more than one SignerInfo that has an
mlExpansionHistory attribute, the recipient MUST compare the
mlExpansionHistory attributes in all the SignerInfos that it has
verified, and MUST NOT process the mlExpansionHistory attribute
unless every verified mlExpansionHistory attribute in the SignedData
block is identical. If the mlExpansionHistory attributes in the
verified signerInfos are not all identical, then the receiving agent
MUST stop processing the message and SHOULD notify the user or MLA
administrator of this error condition. In the mlExpansionHistory
processing, SignerInfos that do not have an mlExpansionHistory
attribute are ignored.
Prior to expanding a message, the MLA examines the value of any existing mail list expansion history attribute to detect an expansion loop. An expansion loop exists when a message expanded by a specific MLA for a specific mail list is redelivered to the same MLA for the same mail list.
Expansion loops are detected by examining the mailListIdentifier field of each MLData entry found in the mail list expansion history. If an MLA finds its own identification information, then the MLA must discontinue expansion processing and should provide warning of an expansion loop to a human mail list administrator. The mail list administrator is responsible for correcting the loop condition.
The first few paragraphs of this section provide a high-level description of MLA processing. The rest of the section provides a detailed description of MLA processing.
MLA message processing depends on the structure of the S/MIME layers in the message sent to the MLA for expansion. In addition to sending triple wrapped messages to an MLA, an entity can send other types of messages to an MLA, such as:
- a single wrapped signedData or envelopedData message
- a double wrapped message (such as signed and enveloped, enveloped
and signed, or signed and signed, and so on)
- a quadruple-wrapped message (such as if a well-formed triple
wrapped message was sent through a gateway that added an outer
SignedData layer)
In all cases, the MLA MUST parse all layers of the received message to determine if there are any signedData layers that include an eSSSecurityLabel signedAttribute. This may include decrypting an EnvelopedData layer to determine if an encapsulated SignedData layer includes an eSSSecurityLabel attribute. The MLA MUST fully process each eSSSecurityLabel attribute found in the various signedData layers, including performing access control checks, before distributing the message to the ML members. The details of the access control checks are beyond the scope of this document. The MLA MUST verify the signature of the signerInfo including the eSSSecurityLabel attribute before using it.
In all cases, the MLA MUST sign the message to be sent to the ML members in a new "outer" signedData layer. The MLA MUST add or update an mlExpansionHistory attribute in the "outer" signedData that it creates to document MLA processing. If there was an "outer" signedData layer included in the original message received by the MLA, then the MLA-created "outer" signedData layer MUST include each signed attribute present in the original "outer" signedData layer, unless the MLA explicitly replaces an attribute (such as signingTime or mlExpansionHistory) with a new value.
When an S/MIME message is received by the MLA, the MLA MUST first
determine which received signedData layer, if any, is the "outer"
signedData layer. To identify the received "outer" signedData layer,
the MLA MUST verify the signature and fully process the
signedAttributes in each of the outer signedData layers (working from
the outside in) to determine if any of them either include an
mlExpansionHistory attribute or encapsulate an envelopedData object.
The MLA's search for the "outer" signedData layer is completed when it finds one of the following:
- the "outer" signedData layer that includes an mlExpansionHistory
attribute or encapsulates an envelopedData object
- an envelopedData layer
- the original content (that is, a layer that is neither
envelopedData nor signedData).
If the MLA finds an "outer" signedData layer, then the MLA MUST perform the following steps:
If the MLA finds an "outer" signedData layer that includes an mlExpansionHistory attribute AND the MLA subsequently finds an envelopedData layer buried deeper with the layers of the received message, then the MLA MUST strip off all of the signedData layers down to the envelopedData layer (including stripping off the original "outer" signedData layer) and MUST sign the expanded envelopedData in a new "outer" signedData layer that includes the signedAttributes (unless explicitly replaced) from the original, received "outer" signedData layer.
If the MLA does not find an "outer" signedData layer AND does not find an envelopedData layer, then the MLA MUST sign the original, received message in a new "outer" signedData layer. If the MLA does not find an "outer" signedData AND does find an envelopedData layer then it MUST expand the envelopedData layer, if present, and sign it in a new "outer" signedData layer.
The following examples help explain the rules above:
1) A message (S1(Original Content)) (where S = SignedData) is sent to
the MLA in which the signedData layer does not include an
MLExpansionHistory attribute. The MLA verifies and fully processes
the signedAttributes in S1. The MLA decides that there is not an
original, received "outer" signedData layer since it finds the
original content, but never finds an envelopedData and never finds
an mlExpansionHistory attribute. The MLA calculates a new
signedData layer, S2, resulting in the following message sent to
the ML recipients: (S2(S1(Original Content))). The MLA includes an
mlExpansionHistory attribute in S2.
2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in
which none of the signedData layers includes an MLExpansionHistory
attribute. The MLA verifies and fully processes the
signedAttributes in S3, S2 and S1. The MLA decides that there is
not an original, received "outer" signedData layer since it finds
the original content, but never finds an envelopedData and never
finds an mlExpansionHistory attribute. The MLA calculates a new
signedData layer, S4, resulting in the following
message sent to the ML recipients:
(S4(S3(S2(S1(Original Content))))). The MLA includes an
mlExpansionHistory attribute in S4.
3) A message (E1(S1(Original Content))) (where E = envelopedData) is
sent to the MLA in which S1 does not include an MLExpansionHistory
attribute. The MLA decides that there is not an original,
received "outer" signedData layer since it finds the E1 as the
outer layer. The MLA expands the recipientInformation in E1. The
MLA calculates a new signedData layer, S2, resulting in the
following message sent to the ML recipients:
(S2(E1(S1(Original Content)))). The MLA includes an
mlExpansionHistory attribute in S2.
4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 includes an MLExpansionHistory attribute. The MLA verifies the signature and fully processes the signedAttributes in S2. The MLA finds the mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" signedData. The MLA remembers the signedAttributes included in S2 for later inclusion in the new outer signedData that it applies to the message. The MLA strips off S2. The MLA then expands the recipientInformation in E1 (this invalidates the signature in S2 which is why it was stripped). The nMLA calculates a new signedData layer, S3, resulting in the following message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from S2 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in
which none of the signedData layers include an MLExpansionHistory
attribute. The MLA verifies the signature and fully processes the
signedAttributes in S3 and S2. When the MLA encounters E1, then it
decides that S2 is the "outer" signedData since S2 encapsulates E1.
The MLA remembers the signedAttributes included in S2 for later
inclusion in the new outer signedData that it applies to the
message. The MLA strips off S3 and S2. The MLA then expands the
recipientInformation in E1 (this invalidates the signatures in S3
and S2 which is why they were stripped). The MLA calculates a new
signedData layer, S4, resulting in the following message sent to
the ML recipients: (S4(E1(S1(Original Content)))). The MLA
includes in S4 the attributes from S2 (unless it specifically
replaces an attribute value) and includes a new
mlExpansionHistory attribute.
6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies the signature and fully processes the
signedAttributes in S3. The MLA finds the mlExpansionHistory in S3, so it decides that S3 is the "outer" signedData. The MLA remembers the signedAttributes included in S3 for later inclusion in the new outer signedData that it applies to the message. The MLA keeps on parsing encapsulated layers because it must determine if there are any eSSSecurityLabel attributes contained within. The MLA verifies the signature and fully processes the signedAttributes in S2. When the MLA encounters E1, then it strips off S3 and S2. The MLA then expands the recipientInformation in E1 (this invalidates the signatures in S3 and S2 which is why they were stripped). The MLA calculates a new signedData layer, S4, resulting in the following message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from S3 (unless it specifically replaces an attribute value) including an updated mlExpansionHistory attribute.
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:
- EnvelopedData
- SignedData
- data
MLA processing of multi-layer messages depends on the type of data in each of the layers. Step 3 below specifies that different processing will take place depending on the type of CMS message that has been signed. That is, it needs to know the type of data at the next inner layer, which may or may not be the innermost layer.
hand, if the signed data is SignedData (from step 3.2), the MLA encapsulates the signed data in a new outermost SignedData layer.
A flow chart for the above steps would be:
EnvelopedData -> 3.1.
SignedData -> 3.2.
all others -> 3.3.
If a mailing list (B) is a member of another mailing list (A), list B often needs to propagate forward the mailing list receipt policy of A. As a general rule, a mailing list should be conservative in propagating forward the mailing list receipt policy because the ultimate recipient need only process the last item in the ML expansion history. The MLA builds the expansion history to meet this requirement.
The following table describes the outcome of the union of mailing list A's policy (the rows in the table) and mailing list B's policy (the columns in the table).
| B's policy
-----------------------------------------------------------------------
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
An mlExpansionHistory attribute value has ASN.1 type
MLExpansionHistory. If there are more than ub-ml-expansion-history
mailing lists in the sequence, the receiving 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
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
MLData contains the expansion history describing each MLA that has 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 receipt policy in an MLData structure.
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
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 message has not requested a signed receipt, the MLA cannot request a signed receipt. In the event that a ML's signed receipt policy supersedes the originator's request for signed receipts, such that the originator will not receive any signed receipts, then the MLA MAY inform the originator of that fact.
When present, the mlReceiptPolicy specifies a receipt policy that supersedes the originator's request for signed receipts. The policy can be one of three possibilities: receipts MUST NOT be returned (none); receipts should be returned to an alternate list of recipients, instead of to the originator (insteadOf); or receipts should be returned to a list of recipients in addition to the originator (inAdditionTo).
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
Concerns have been raised over the fact that the certificate which
the signer of a CMS SignedData object desired to be bound into the
verification process of the SignedData object is not
cryptographically bound into the signature itself. This section
addresses this issue by creating a new attribute to be placed in the
signed attributes section of a SignerInfo object.
This section also presents a description of a set of possible attacks dealing with the substitution of one certificate to verify the signature for the desired certificate. A set of ways for preventing or addressing these attacks is presented to deal with the simplest of the attacks.
Authorization information can be used as part of a signature verification process. This information can be carried in either attribute certificates and other public key certificates. The signer needs to have the ability to restrict the set of certificates used in the signature verification process, and information needs to be encoded so that is covered by the signature on the SignedData object. The methods in this section allow for the set of authorization certificates to be listed as part of the signing certificate attribute.
Explicit certificate policies can also be used as part of a signature verification process. If a signer desires to state an explicit certificate policy that should be used when validating the signature, that policy needs to be cryptographically bound into the signing process. The methods described in this section allows for a set of certificate policy statements to be listed as part of the signing certificate attribute.
At least three different attacks can be launched against a possible signature verification process by replacing the certificate or certficates used in the signature verification process.
The first attack deals with simple substitution of one certificate for another certificate. In this attack, the issuer and serial number in the SignerInfo is modified to refer to a new certificate. This new certificate is used during the signature verification process.
The first version of this attack is a simple denial of service attack where an invalid certificate is substituted for the valid certificate. This renders the message unverifiable, as the public key in the certificate no longer matches the private key used to sign the message.
The second version is a substitution of one valid certificate for the original valid certificate where the public keys in the certificates match. This allows the signature to be validated under potentially different certificate constraints than the originator of the message intended.
The second attack deals with a certificate authority (CA) re-issuing the signing certificate (or potentially one of its certificates). This attack may start becoming more frequent as Certificate Authorities reissue their own root certificates, or as certificate authorities change policies in the certificate while reissuing their root certificates. This problem also occurs when cross certificates (with potentially different restrictions) are used in the process of verifying a signature.
The third attack deals with a rogue entity setting up a certificate authority that attempts to duplicate the structure of an existing CA. Specifically, the rogue entity issues a new certificate with the same public keys as the signer used, but signed by the rogue entity's private key.
This document does not attempt to solve all of the above attacks; however, a brief description of responses to each of the attacks is given in this section.
The denial of service attack cannot be prevented. After the certificate identifier has been modified in transit, no verification of the signature is possible. There is also no way to automatically identify the attack because it is indistinguishable from a message corruption.
The substitution of a valid certificate can be responded to in two different manners. The first is to make a blanket statement that the use of the same public key in two different certificates is bad practice and has to be avoided. In practice, there is no practical way to prevent users from getting new certificates with the same public keys, and it should be assumed that they will do this. Section 5.4 provides a new attribute that can be included in the SignerInfo signed attributes. This binds the correct certificate identifier into the signature. This will convert the attack from a potentially successful one to simply a denial of service attack.
A CA should never reissue a certificate with different attributes. Certificate Authorities that do so are following poor practices and cannot be relied on. Using the hash of the certificate as the reference to the certificate prevents this attack for end-entity certificates.
Preventing the attack based on reissuing of CA certificates would require a substantial change to the usage of the signingCertificate attribute presented in section 5.4. It would require that ESSCertIDs would need to be included in the attribute to represent the issuer certificates in the signer's certification path. This presents problems when the relying party is using a cross-certificate as part of its authentication process, and this certificate does not appear
on the list of certificates. The problems outside of a closed PKI make the addition of this information prone to error, possibly causing the rejection of valid chains.
The best method of preventing this attack is to avoid trusting the rogue CA. The use of the hash to identify certificates prevents the use of end-entity certificates from the rogue authority. However the only true way to prevent this attack is to never trust the rogue CA.
Some applications require that additional information be used as part of the signature validation process. In particular, authorization information from attribute certificates and other public key certificates or policy identifiers provide additional information about the abilities and intent of the signer. The signing certificate attribute described in Section 5.4 provides the ability to bind this context information as part of the signature.
Some applications require that authorization information found in attribute certificates and/or other public key certificates be validated. This validation requires that the application be able to find the correct certificates to perform the verification process; however there is no list of the certificates to used in a SignerInfo object. The sender has the ability to include a set of attribute certificates and public key certificates in a SignedData object. The receiver has the ability to retrieve attribute certificates and public key certificates from a directory service. There are some circumstances where the signer may wish to limit the set of certificates that may be used in verifying a signature. It is useful to be able to list the set of certificates the signer wants the recipient to use in validating the signature.
A related aspect of the certificate binding is the issue of multiple certification paths. In some instances, the semantics of a certificate in its use with a message may depend on the Certificate Authorities and policies that apply. To address this issue, the signer may also wish to bind that context under the signature. While this could be done by either signing the complete certification path or a policy ID, only a binding for the policy ID is described here.
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature.
The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 }
The first certificate identified in the sequence of certificate
identifiers MUST be the certificate used to verify the signature. The
encoding of the ESSCertID for this certificate SHOULD include the
issuerSerial field. If other constraints ensure that
issuerAndSerialNumber will be present in the SignerInfo, the
issuerSerial field MAY be omitted. The certificate identified is used
during the signature verification process. If the hash of the
certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of ESSCertIDs, the certificates after the first one limit the set of authorization certificates that are used during signature validation. Authorization certificates can be either attribute certificates or normal certificates. The issuerSerial field (in the ESSCertID structure) SHOULD be present for these certificates, unless the client who is validating the signature is expected to have easy access to all the certificates requred for validation. If only the signing certificate is present in the sequence, there are no restrictions on the set of authorization certificates used in validating the signature.
The sequence of policy information terms identifies those certificate policies that the signer asserts apply to the certificate, and under which the certificate should be relied upon. This value suggests a policy value to be used in the relying party's certification path validation.
If present, the SigningCertificate attribute MUST be a signed attribute; it MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
multiple instances of the SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed attributes to include attrValues SET OF AttributeValue. A SigningCertificate attribute MUST include only a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
The best way to identify certificates is an often-discussed issue. [CERT] has imposed a restriction for SignedData objects that the issuer DN must be present in all signing certificates. The issuer/serial number pair is therefore sufficient to identify the correct signing certificate. This information is already present, as part of the SignerInfo object, and duplication of this information would be unfortunate. A hash of the entire certificate serves the same function (allowing the receiver to verify that the same certificate is being used as when the message was signed), is smaller, and permits a detection of the simple substitution attacks.
Attribute certificates and additional public key certificates containing authorization information do not have an issuer/serial number pair represented anywhere in a SignerInfo object. When an attribute certificate or an additional public key certificate is not included in the SignedData object, it becomes much more difficult to get the correct set of certificates based only on a hash of the certificate. For this reason, these certificates SHOULD be identified by the IssuerSerial object.
This document defines a certificate identifier as:
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
When creating an ESSCertID, the certHash is computed over the entire DER encoded certificate including the signature. The issuerSerial would normally be present unless the value can be inferred from other information.
When encoding IssuerSerial, serialNumber is the serial number that uniquely identifies the certificate. For non-attribute certificates, the issuer MUST contain only the issuer name from the certificate encoded in the directoryName choice of GeneralNames. For attribute certificates, the issuer MUST contain the issuer name field from the attribute certificate.
All security considerations from [CMS] and [SMIME3] apply to applications that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not send back a reply if it cannot validate the signature. Similarly, if there conflicting receipt requests in a message, the recipient must not send back receipts, since an attacker may have inserted the conflicting request. Sending a signed receipt to an unvalidated sender can expose information about the recipient that it may not want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to prevent a passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly process security labels. That is, the sender cannot assume that adding a security label to a message will prevent recipients from viewing messages the sender doesn't want them to view. It is expected that there will be many S/MIME clients that will not understand security labels but will still display a labelled message to a recipient.
A receiving agent that processes security labels must handle the content of the messages carefully. If the agent decides not to show the message to the intended recipient after processing the security label, the agent must take care that the recipient does not accidentally see the content at a later time. For example, if an error response sent to the originator contains the content that was hidden from the recipient, and that error response bounces back to the sender due to addressing errors, the original recipient can possibly see the content since it is unlikely that the bounce message will have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to an attacker if that attacker has a signature that can be validated by the recipient. The attack consists of intercepting the original message and adding a mLData attribute that says that a receipt should be sent to the attacker in addition to whoever else was going to get the receipt.
Mailing lists that encrypt their content may be targets for denial- of-service attacks if they do not use the mailing list management described in Section 4. Using simple RFC822 header spoofing, it is quite easy to subscribe one encrypted mailing list to another, thereby setting up an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles
for the the adaptive chosen ciphertext attack described in [CMS].
MLAs should notify an administrator if a large number of
undecryptable messages are received.
When verifying a signature using certificates that come with a [CMS] message, the recipient should only verify using certificates previously known to be valid, or certificates that have come from a signed SigningCertificate attribute. Otherwise, the attacks described in Section 5 can cause the receiver to possibly think a signature is valid when it is not.
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::=
-- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- X.509
GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- 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.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
-- Section 2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16