1. Introduction
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].
1.1. Triple Wrapping
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.
1.1.1. Purpose of Triple Wrapping
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.
1.1.2. Steps for Triple Wrapping
The steps to create a triple wrapped message are:
- Start with a message body, called the "original content".
- 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.
- Sign the result of step 2 (the inner MIME headers and the original content). The SignedData encapContentInfo eContentType object identifier MUST be id-data. If the structure you create in step 4 is multipart/signed, then the SignedData encapContentInfo eContent MUST be absent. If the structure you create in step 4 is application/pkcs7-mime, then the SignedData encapContentInfo eContent MUST contain the result of step 2 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
-
Add an appropriate MIME construct to the signed message from step 3 as defined in [MSG]. The resulting message is called the "inside signature".
- 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.
- Encrypt the result of step 4 as a single block, turning it into an application/pkcs7-mime object. The EnvelopedData encryptedContentInfo contentType MUST be id-data. The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is called the "encrypted body".
- 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.
- 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
- . 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
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.
1.3. Security Services and Triple Wrapping
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.
1.3.1. Signed Receipts and Triple Wrapping
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.
1.3.2. Security Labels and Triple Wrapping
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.
1.3.3. Secure Mailing Lists and Triple Wrapping
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.
1.3.4. Placement of Attributes
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.
1.4. Required and Optional Attributes
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.
1.5. Object Identifiers
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.