idnits 2.17.1
draft-ietf-smime-ess-11.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 2467 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Abstract section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 468 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
** There are 82 instances of lines with control characters in the document.
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 114: '...entInfo eContent MUST be absent. If th...'
RFC 2119 keyword, line 116: '...entInfo eContent MUST contain the resu...'
RFC 2119 keyword, line 138: '...contentType MUST be id-data. The Envel...'
RFC 2119 keyword, line 167: '...receiving agents MUST be able to inter...'
RFC 2119 keyword, line 248: '...request MUST be in the inside signatur...'
(146 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 1772 has weird spacing: '... | none inst...'
== Line 1774 has weird spacing: '... | none none...'
== Line 1775 has weird spacing: '... | none inst...'
== Line 1776 has weird spacing: '... | none inst...'
== Line 1777 has weird spacing: '... | none inst...'
** The document contains RFC2119-like boilerplate, but doesn't seem to
mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but
that reference does not seem to mention RFC 2119 either.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 26, 1999) is 9192 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'MSP4' on line 2366 looks like a reference
-- Missing reference section? 'MSG' on line 2360 looks like a reference
-- Missing reference section? 'CERT' on line 2354 looks like a reference
-- Missing reference section? 'SMIME2' on line 2377 looks like a reference
-- Missing reference section? 'ASN1-1988' on line 2348 looks like a
reference
-- Missing reference section? 'MUSTSHOULD' on line 2363 looks like a
reference
-- Missing reference section? 'ESS' on line 325 looks like a reference
-- Missing reference section? 'CMS' on line 2357 looks like a reference
-- Missing reference section? '0' on line 2317 looks like a reference
-- Missing reference section? '1' on line 2318 looks like a reference
-- Missing reference section? 'MTSABS' on line 2369 looks like a reference
-- Missing reference section? '2' on line 2319 looks like a reference
-- Missing reference section? 'SMIME3' on line 2079 looks like a reference
-- Missing reference section? 'UNIVERSAL 12' on line 2168 looks like a
reference
-- Missing reference section? 'UTF8' on line 2380 looks like a reference
-- Missing reference section? 'ASN1-1994' on line 2351 looks like a
reference
Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Editor: Paul Hoffman
2 draft-ietf-smime-ess-11.txt Internet Mail Consortium
3 February 26, 1999
4 Expires in six months
6 Enhanced Security Services for S/MIME
8 Status of this memo
10 Internet-Drafts are working documents of the Internet Engineering
11 Task Force (IETF), its areas, and its working groups. Note that
12 other groups may also distribute working documents as
13 Internet-Drafts.
15 Internet-Drafts are draft documents valid for a maximum of six
16 months and may be updated, replaced, or obsoleted by other
17 documents at any time. It is inappropriate to use Internet-
18 Drafts as reference material or to cite them other than as
19 "work in progress."
21 To view the list Internet-Draft Shadow Directories, see
22 http://www.ietf.org/shadow.html.
24 This document is an Internet-Draft and is in full conformance
25 with all provisions of Section 10 of RFC2026.
27 1. Introduction
29 This document describes four optional security service extensions for
30 S/MIME. The services are:
31 - signed receipts
32 - security labels
33 - secure mailing lists
34 - signing certificates
35 The first three of these services provide functionality that is similar to
36 the Message Security Protocol [MSP4], but are useful in many other
37 environments, particularly business and finance. Signing certificates are
38 useful in any environment where certificates might be transmitted with
39 signed messages.
41 The services described here are extensions to S/MIME version 3 ([MSG] and
42 [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2].
43 The extensions described here will not cause an S/MIME version 3 recipient
44 to be unable to read messages from an S/MIME version 2 sender. However,
45 some of the extensions will cause messages created by an S/MIME version 3
46 sender to be unreadable by an S/MIME version 2 recipient.
48 This document describes both the procedures and the attributes needed for
49 the three services. Note that some of the attributes described in this
50 document are quite useful in other contexts and should be considered when
51 extending S/MIME or other CMS applications.
53 The format of the messages are described in ASN.1:1988 [ASN1-1988].
55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
57 document are to be interpreted as described in [MUSTSHOULD].
59 This draft is being discussed on the "ietf-smime" mailing list. To
60 subscribe, send a message to:
61 ietf-smime-request@imc.org
62 with the single word
63 subscribe
64 in the body of the message. There is a Web site for the mailing list at
65 .
67 1.1 Triple Wrapping
69 Some of the features of each service use the concept of a "triple wrapped"
70 message. A triple wrapped message is one that has been signed, then
71 encrypted, then signed again. The signers of the inner and outer signatures
72 may be different entities or the same entity. Note that the S/MIME
73 specification does not limit the number of nested encapsulations, so there
74 may be more than three wrappings.
76 1.1.1 Purpose of Triple Wrapping
78 Not all messages need to be triple wrapped. Triple wrapping is used when a
79 message must be signed, then encrypted, and then have signed attributes
80 bound to the encrypted body. Outer attributes may be added or removed by
81 the message originator or intermediate agents, and may be signed by
82 intermediate agents or the final recipient.
84 The inside signature is used for content integrity, non-repudiation with
85 proof of origin, and binding attributes (such as a security label) to the
86 original content. These attributes go from the originator to the recipient,
87 regardless of the number of intermediate entities such as mail list agents
88 that process the message. The signed attributes can be used for access
89 control to the inner body. Requests for signed receipts by the originator
90 are carried in the inside signature as well.
92 The encrypted body provides confidentiality, including confidentiality of
93 the attributes that are carried in the inside signature.
95 The outside signature provides authentication and integrity for information
96 that is processed hop-by-hop, where each hop is an intermediate entity such
97 as a mail list agent. The outer signature binds attributes (such as a
98 security label) to the encrypted body. These attributes can be used for
99 access control and routing decisions.
101 1.1.2 Steps for Triple Wrapping
103 The steps to create a triple wrapped message are:
105 1. Start with a message body, called the "original content".
107 2. Encapsulate the original content with the appropriate MIME Content-type
108 headers, such as "Content-type: text/plain". An exception to this MIME
109 encapsulation rule is that a signed receipt is not put in MIME headers.
111 3. Sign the result of step 2 (the inner MIME headers and the original
112 content). The SignedData encapContentInfo eContentType object identifier
113 MUST be id-data. If the structure you create in step 4 is multipart/signed,
114 then the SignedData encapContentInfo eContent MUST be absent. If the
115 structure you create in step 4 is application/pkcs7-mime, then the
116 SignedData encapContentInfo eContent MUST contain the result of step 2
117 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE
118 with a contentType of id-signedData.
120 4. Add an appropriate MIME construct to the signed message from step 3 as
121 defined in [MSG]. The resulting message is called the "inside signature".
123 - If you are signing using multipart/signed, the MIME construct added
124 consists of a Content-type of multipart/signed with parameters, the
125 boundary, the result of step 2 above, the boundary, a Content-type of
126 application/pkcs7-signature, optional MIME headers (such as
127 Content-transfer-encoding and Content-disposition), and a body part that
128 is the result of step 3 above.
130 - If you are instead signing using application/pkcs7-mime, the MIME
131 construct added consists of a Content-type of application/pkcs7-mime
132 with parameters, optional MIME headers (such as
133 Content-transfer-encoding and Content-disposition), and the result of
134 step 3 above.
136 5. Encrypt the result of step 4 as a single block, turning it into an
137 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
138 contentType MUST be id-data. The EnvelopedData structure is encapsulated by
139 a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
140 called the "encrypted body".
142 6. Add the appropriate MIME headers: a Content-type of
143 application/pkcs7-mime with parameters, and optional MIME headers such as
144 Content-transfer-encoding and Content-disposition.
146 7. Using the same logic as in step 3 above, sign the result of step 6 (the
147 MIME headers and the encrypted body) as a single block
149 8. Using the same logic as in step 4 above, add an appropriate MIME
150 construct to the signed message from step 7. The resulting message is
151 called the "outside signature", and is also the triple wrapped message.
153 1.2 Format of a Triple Wrapped Message
155 A triple wrapped message has many layers of encapsulation. The structure
156 differs based on the choice of format for the signed portions of the
157 message. Because of the way that MIME encapsulates data, the layers do not
158 appear in order, and the notion of "layers" becomes vague.
160 There is no need to use the multipart/signed format in an inner signature
161 because it is known that the recipient is able to process S/MIME messages
162 (because they decrypted the middle wrapper). A sending agent might choose
163 to use the multipart/signed format in the outer layer so that a non-S/MIME
164 agent could see that the next inner layer is encrypted; however, this is
165 not of great value, since all it shows the recipient is that the rest of
166 the message is unreadable. Because many sending agents always use
167 multipart/signed structures, all receiving agents MUST be able to interpret
168 either multipart/signed or application/pkcs7-mime signature structures.
170 The format of a triple wrapped message that uses multipart/signed for both
171 signatures is:
173 [step 8] Content-type: multipart/signed;
174 [step 8] protocol="application/pkcs7-signature";
175 [step 8] boundary=outerboundary
176 [step 8]
177 [step 8] --outerboundary
178 [step 6] Content-type: application/pkcs7-mime; )
179 [step 6] smime-type=enveloped-data )
180 [step 6] )
181 [step 4] Content-type: multipart/signed; | )
182 [step 4] protocol="application/pkcs7-signature"; | )
183 [step 4] boundary=innerboundary | )
184 [step 4] | )
185 [step 4] --innerboundary | )
186 [step 2] Content-type: text/plain % | )
187 [step 2] % | )
188 [step 1] Original content % | )
189 [step 4] | )
190 [step 4] --innerboundary | )
191 [step 4] Content-type: application/pkcs7-signature | )
192 [step 4] | )
193 [step 3] inner SignedData block (eContent is missing) | )
194 [step 4] | )
195 [step 4] --innerboundary-- | )
196 [step 8]
197 [step 8] --outerboundary
198 [step 8] Content-type: application/pkcs7-signature
199 [step 8]
200 [step 7] outer SignedData block (eContent is missing)
201 [step 8]
202 [step 8] --outerboundary--
204 % = These lines are what the inner signature is computed over.
205 | = These lines are what is encrypted in step 5. This encrypted result
206 is opaque and is a part of an EnvelopedData block.
207 ) = These lines are what the outer signature is computed over.
209 The format of a triple wrapped message that uses application/pkcs7-mime for
210 the both signatures is:
212 [step 8] Content-type: application/pkcs7-mime;
213 [step 8] smime-type=signed-data
214 [step 8]
215 [step 7] outer SignedData block (eContent is present) O
216 [step 6] Content-type: application/pkcs7-mime; ) O
217 [step 6] smime-type=enveloped-data; ) O
218 [step 6] ) O
219 [step 4] Content-type: application/pkcs7-mime; | ) O
220 [step 4] smime-type=signed-data | ) O
221 [step 4] | ) O
222 [step 3] inner SignedData block (eContent is present) I | ) O
223 [step 2] Content-type: text/plain I | ) O
224 [step 2] I | ) O
225 [step 1] Original content I | ) O
227 I = These lines are the inner SignedData block, which is opaque and
228 contains the ASN.1 encoded result of step 2 as well as control
229 information.
230 | = These lines are what is encrypted in step 5. This encrypted result
231 is opaque and is a part of an EnvelopedData block.
232 ) = These lines are what the outer signature is computed over.
233 O = These lines are the outer SignedData block, which is opaque and
234 contains the ASN.1 encoded result of step 6 as well as control
235 information.
237 1.3 Security Services and Triple Wrapping
239 The three security services described in this document are used with triple
240 wrapped messages in different ways. This section briefly describes the
241 relationship of each service with triple wrapping; the other sections of
242 the document go into greater detail.
244 1.3.1 Signed Receipts and Triple Wrapping
246 A signed receipt may be requested in any SignedData object. However, if a
247 signed receipt is requested for a triple wrapped message, the receipt
248 request MUST be in the inside signature, not in the outside signature. A
249 secure mailing list agent may change the receipt policy in the outside
250 signature of a triple wrapped message when that message is processed by the
251 mailing list.
253 Note: the signed receipts and receipt requests described in this draft
254 differ from those described in the work done by the IETF Receipt
255 Notification Working Group. The output of that Working Group, when
256 finished, is not expected to work well with triple wrapped messages as
257 described in this document.
259 1.3.2 Security Labels and Triple Wrapping
261 A security label may be included in the signed attributes of any SignedData
262 object. A security label attribute may be included in either the inner
263 signature, outer signature, or both.
265 The inner security label is used for access control decisions related to
266 the plaintext original content. The inner signature provides authentication
267 and cryptographically protects the integrity of the original signer's
268 security label that is in the inside body. This strategy facilitates the
269 forwarding of messages because the original signer's security label is
270 included in the SignedData block which can be forwarded to a third party
271 that can verify the inner signature which will cover the inner security
272 label. The confidentiality security service can be applied to the inner
273 security label by encrypting the entire inner SignedData block within an
274 EnvelopedData block.
276 A security label may also be included in the signed attributes of the outer
277 SignedData block which will include the sensitivities of the encrypted
278 message. The outer security label is used for access control and routing
279 decisions related to the encrypted message. Note that a security label
280 attribute can only be used in an signedAttributes block. An
281 eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned
282 attributes.
284 1.3.3 Secure Mailing Lists and Triple Wrapping
286 Secure mail list message processing depends on the structure of S/MIME
287 layers present in the message sent to the mail list agent. The mail list
288 agent never changes the data that was hashed to form the inner signature,
289 if such a signature is present. If an outer signature is present, then the
290 agent will modify the data that was hashed to form that outer signature. In
291 all cases, the agent adds or updates an mlExpansionHistory attribute to
292 document the agent's processing, and ultimately adds or replaces the outer
293 signature on the message to be distributed.
295 1.3.4 Placement of Attributes
297 Certain attributes should be placed in the inner or outer SignedData
298 message; some attributes can be in either. Further, some attributes must be
299 signed, while signing is optional for others, and some attributes must not
300 be signed. ESS defines several types of attributes. ContentHints and
301 ContentIdentifier MAY appear in any list of attributes. contentReference,
302 equivalentLabel, eSSSecurityLabel and mlExpansionHistory MUST be carried in
303 a SignedAttributes or AuthAttributes type, and MUST NOT be carried in a
304 UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
305 msgSigDigest, receiptRequest and signingCertificate MUST be carried in a
306 SignedAttributes, and MUST NOT be carried in a AuthAttributes,
307 UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type.
309 The following table summarizes the recommendation of this profile. In the
310 OID column, [ESS] indicates that the attribute is defined in this document.
312 | |Inner or |
313 Attribute |OID |outer |Signed
314 ------------------|----------------------------- |----------|--------
315 contentHints |id-aa-contentHint [ESS] |either |MAY
316 contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
317 contentReference |id-aa-contentReference [ESS] |either |MUST
318 contentType |id-contentType [CMS] |either |MUST
319 counterSignature |id-countersignature [CMS] |either |MUST NOT
320 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
321 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
322 messageDigest |id-messageDigest [CMS] |either |MUST
323 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
324 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
325 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
326 signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
327 signingTime |id-signingTime [CMS] |either |MUST
328 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
329 sMIMEEncryption-
330 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
332 CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs as
333 a SET OF Attribute. ESS defines the contentHints, contentIdentifier,
334 eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest,
335 contentReference, equivalentLabels and signingCertificate attribute types.
336 A signerInfo MUST NOT include multiple instances of any of the attribute
337 types defined in ESS. Later sections of ESS specify further restrictions
338 that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel
339 attribute types.
341 CMS defines the syntax for the signed and unsigned attributes as
342 "attrValues SET OF AttributeValue". For all of the attribute types defined
343 in ESS, if the attribute type is present in a signerInfo, then it MUST only
344 include a single instance of AttributeValue. In other words, there MUST NOT
345 be zero, or multiple, instances of AttributeValue present in the attrValues
346 SET OF AttributeValue.
348 If a counterSignature attribute is present, then it MUST be included in the
349 unsigned attributes. It MUST NOT be included in the signed attributes. The
350 only attributes that are allowed in a counterSignature attribute are
351 counterSignature, messageDigest, signingTime, and signingCertificate.
353 Note that the inner and outer signatures are usually those of different
354 senders. Because of this, the same attribute in the two signatures could
355 lead to very different consequences.
357 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
358 identifier assigned to the message.
360 1.4 Required and Optional Attributes
362 Some security gateways sign messages that pass through them. If the message
363 is any type other than a signedData type, the gateway has only one way to
364 sign the message: by wrapping it with a signedData block and MIME headers.
365 If the message to be signed by the gateway is a signedData message already,
366 the gateway can sign the message by inserting a signerInfo into the
367 signedData block.
369 The main advantage of a gateway adding a signerInfo instead of wrapping the
370 message in a new signature is that the message doesn't grow as much as if
371 the gateway wrapped the message. The main disadvantage is that the gateway
372 must check for the presence of certain attributes in the other signerInfos
373 and either omit or copy those attributes.
375 If a gateway or other processor adds a signerInfo to an existing signedData
376 block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes
377 from other signerInfos. This helps ensure that the recipient will process
378 those attributes in a signerInfo that it can verify.
380 Note that someone may in the future define an attribute that must be
381 present in each signerInfo of a signedData block in order for the signature
382 to be processed. If that happens, a gateway that inserts signerInfos and
383 doesn't copy that attribute will cause every message with that attribute to
384 fail when processed by the recipient. For this reason, it is safer to wrap
385 messages with new signatures than to insert signerInfos.
387 1.5 Object Identifiers
389 The object identifiers for many of the objects described in this draft are
390 found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME
391 can be found in the registry kept at
392 . When this draft moves to
393 standards track within the IETF, it is intended that the IANA will maintain
394 this registry.
396 2. Signed Receipts
398 Returning a signed receipt provides to the originator proof of delivery of
399 a message, and allows the originator to demonstrate to a third party that
400 the recipient was able to verify the signature of the original message.
401 This receipt is bound to the original message through the signature;
402 consequently, this service may be requested only if a message is signed.
403 The receipt sender may optionally also encrypt a receipt to provide
404 confidentiality between the receipt sender and the receipt recipient.
406 2.1 Signed Receipt Concepts
408 The originator of a message may request a signed receipt from the message's
409 recipients. The request is indicated by adding a receiptRequest attribute
410 to the signedAttributes field of the SignerInfo object for which the
411 receipt is requested. The receiving user agent software SHOULD
412 automatically create a signed receipt when requested to do so, and return
413 the receipt in accordance with mailing list expansion options, local
414 security policies, and configuration options.
416 Because receipts involve the interaction of two parties, the terminology
417 can sometimes be confusing. In this section, the "sender" is the agent that
418 sent the original message that included a request for a receipt. The
419 "receiver" is the party that received that message and generated the
420 receipt.
422 The steps in a typical transaction are:
424 1. Sender creates a signed message including a receipt request attribute
425 (Section 2.2).
427 2. Sender transmits the resulting message to the recipient or recipients.
429 3. Recipient receives message and determines if there is a valid signature
430 and receipt request in the message (Section 2.3).
432 4. Recipient creates a signed receipt (Section 2.4).
434 5. Recipient transmits the resulting signed receipt message to the sender
435 (Section 2.5).
437 6. Sender receives the message and validates that it contains a signed
438 receipt for the original message (Section 2.6). This validation relies on
439 the sender having retained either a copy of the original message or
440 information extracted from the original message.
442 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
443 syntax for the receipt is given in Section 2.8.
445 Note that a sending agent SHOULD remember when it has sent a receipt so
446 that it can avoid re-sending a receipt each time it processes the message.
448 A receipt request can indicate that receipts be sent to many places, not
449 just to the sender (in fact, the receipt request might indicate that the
450 receipts should not even go to the sender). In order to verify a receipt,
451 the recipient of the receipt must be the originator or a recipient of the
452 original message. Thus, the sender SHOULD NOT request that receipts be sent
453 to anyone who does not have an exact copy of the message.
455 2.2 Receipt Request Creation
457 Multi-layer S/MIME messages may contain multiple SignedData layers.
458 However, receipts may be requested only for the innermost SignedData layer
459 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
460 receiptRequest attribute can be included in the signedAttributes of a
461 SignerInfo.
463 A ReceiptRequest attribute MUST NOT be included in the attributes of a
464 SignerInfo in a SignedData object that encapsulates a Receipt content. In
465 other words, the receiving agent MUST NOT request a signed receipt for a
466 signed receipt.
468 A sender requests receipts by placing a receiptRequest attribute in the
469 signed attributes of a signerInfo as follows:
471 1. A receiptRequest data structure is created.
473 2. A signed content identifier for the message is created and assigned to
474 the signedContentIdentifier field. The signedContentIdentifier is used to
475 associate the signed receipt with the message requesting the signed
476 receipt.
478 3. The entities requested to return a signed receipt are noted in the
479 receiptsFrom field.
481 4. The message originator MUST populate the receiptsTo field with a
482 GeneralNames for each entity to whom the recipient should send the signed
483 receipt. If the message originator wants the recipient to send the signed
484 receipt to the originator, then the originator MUST include a GeneralNames
485 for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
486 GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
487 GeneralNames represents an entity. There may be multiple GeneralName
488 instances in each GeneralNames. At a minimum, the message originator MUST
489 populate each entity's GeneralNames with the address to which the signed
490 receipt should be sent. Optionally, the message originator MAY also
491 populate each entity's GeneralNames with other GeneralName instances (such
492 as directoryName).
494 5. The completed receiptRequest attribute is placed in the signedAttributes
495 field of the SignerInfo object.
497 2.2.1 Multiple Receipt Requests
499 There can be multiple SignerInfos within a SignedData object, and each
500 SignerInfo may include signedAttributes. Therefore, a single SignedData
501 object may include multiple SignerInfos, each SignerInfo having a
502 receiptRequest attribute. For example, an originator can send a signed
503 message with two SignerInfos, one containing a DSS signature, the other
504 containing an RSA signature.
506 Each recipient SHOULD return only one signed receipt.
508 Not all of the SignerInfos need to include receipt requests, but in all of
509 the SignerInfos that do contain receipt requests, the receipt requests MUST
510 be identical.
512 2.2.2 Information Needed to Validate Signed Receipts
514 The sending agent MUST retain one or both of the following items to support
515 the validation of signed receipts returned by the recipients.
517 - the original signedData object requesting the signed receipt
519 - the message signature digest value used to generate the original
520 signedData signerInfo signature value and the digest value of the
521 Receipt content containing values included in the original signedData
522 object. If signed receipts are requested from multiple recipients, then
523 retaining these digest values is a performance enhancement because the
524 sending agent can reuse the saved values when verifying each returned
525 signed receipt.
527 2.3 Receipt Request Processing
529 A receiptRequest is associated only with the SignerInfo object to which the
530 receipt request attribute is directly attached. Receiving software SHOULD
531 examine the signedAttributes field of each of the SignerInfos for which it
532 verifies a signature in the innermost signedData object to determine if a
533 receipt is requested. This may result in the receiving agent processing
534 multiple receiptRequest attributes included in a single SignedData object,
535 such as requests made from different people who signed the object in
536 parallel.
538 Before processing a receiptRequest signedAttribute, the receiving agent
539 MUST verify the signature of the SignerInfo which covers the receiptRequest
540 attribute. A recipient MUST NOT process a receiptRequest attribute that has
541 not been verified. Because all receiptRequest attributes in a SignedData
542 object must be identical, the receiving application fully processes (as
543 described in the following paragraphs) the first receiptRequest attribute
544 that it encounters in a SignerInfo that it verifies, and it then ensures
545 that all other receiptRequest attributes in signerInfos that it verifies
546 are identical to the first one encountered. If there are verified
547 ReceiptRequest attributes which are not the same, then the processing
548 software MUST NOT return any signed receipt. A signed receipt SHOULD be
549 returned if any signerInfo containing a receiptRequest attribute can be
550 validated, even if other signerInfos containing the same receiptRequest
551 attribute cannot be validated because they are signed using an algorithm
552 not supported by the receiving agent.
554 If a receiptRequest attribute is absent from the signed attributes, then a
555 signed receipt has not been requested from any of the message recipients
556 and MUST NOT be created. If a receiptRequest attribute is present in the
557 signed attributes, then a signed receipt has been requested from some or
558 all of the message recipients. Note that in some cases, a receiving agent
559 might receive two almost-identical messages, one with a receipt request and
560 the other without one. In this case, the receiving agent SHOULD send a
561 signed receipt for the message that requests a signed receipt.
563 If a receiptRequest attribute is present in the signed attributes, the
564 following process SHOULD be used to determine if a message recipient has
565 been requested to return a signed receipt.
567 1. If an mlExpansionHistory attribute is present in the outermost
568 signedData block, do one of the following two steps, based on the absence
569 or presence of mlReceiptPolicy:
571 1.1. If an mlReceiptPolicy value is absent from the last MLData
572 element, a Mail List receipt policy has not been specified and the
573 processing software SHOULD examine the receiptRequest attribute value
574 to determine if a receipt should be created and returned.
576 1.2. If an mlReceiptPolicy value is present in the last MLData element,
577 do one of the following two steps, based on the value of
578 mlReceiptPolicy:
580 1.2.1. If the mlReceiptPolicy value is none, then the receipt
581 policy of the Mail List supersedes the originator's request for a
582 signed receipt and a signed receipt MUST NOT be created.
584 1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo,
585 the processing software SHOULD examine the receiptsFrom value from
586 the receiptRequest attribute to determine if a receipt should be
587 created and returned. If a receipt is created, the insteadOf and
588 inAdditionTo fields identify entities that SHOULD be sent the
589 receipt instead of or in addition to the originator.
591 2. If the receiptsFrom value of the receiptRequest attribute is
592 allOrFirstTier, do one of the following two steps based on the value of
593 allOrFirstTier.
595 2.1. If the value of allOrFirstTier is allReceipts, then a signed
596 receipt SHOULD be created.
598 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
599 the following two steps based on the presence of an mlExpansionHistory
600 attribute in an outer signedData block:
602 2.2.1. If an mlExpansionHistory attribute is present, then this
603 recipient is not a first tier recipient and a signed receipt MUST
604 NOT be created.
606 2.2.2. If an mlExpansionHistory attribute is not present, then a
607 signed receipt SHOULD be created.
609 3. If the receiptsFrom value of the receiptRequest attribute is a
610 receiptList:
612 3.1. If receiptList contains one of the GeneralNames of the recipient,
613 then a signed receipt SHOULD be created.
615 3.2. If receiptList does not contain one of the GeneralNames of the
616 recipient, then a signed receipt MUST NOT be created.
618 A flow chart for the above steps to be executed for each signerInfo for
619 which the receiving agent verifies the signature would be:
621 0. Receipt Request attribute present?
622 YES -> 1.
623 NO -> STOP
624 1. Has mlExpansionHistory in outer signedData?
625 YES -> 1.1.
626 NO -> 2.
627 1.1. mlReceiptPolicy absent?
628 YES -> 2.
629 NO -> 1.2.
630 1.2. Pick based on value of mlReceiptPolicy.
631 none -> 1.2.1.
632 insteadOf or inAdditionTo -> 1.2.2.
633 1.2.1. STOP.
634 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
635 create it if required, send it to recipients designated by
636 mlReceiptPolicy, then -> STOP.
637 2. Is value of receiptsFrom allOrFirstTier?
638 YES -> Pick based on value of allOrFirstTier.
639 allReceipts -> 2.1.
640 firstTierRecipients -> 2.2.
641 NO -> 3.
642 2.1. Create a receipt, then -> STOP.
643 2.2. Has mlExpansionHistory in the outer signedData block?
644 YES -> 2.2.1.
645 NO -> 2.2.2.
646 2.2.1. STOP.
647 2.2.2. Create a receipt, then -> STOP.
648 3. Is receiptsFrom value of receiptRequest a receiptList?
649 YES -> 3.1.
650 NO -> STOP.
651 3.1. Does receiptList contain the recipient?
652 YES -> Create a receipt, then -> STOP.
653 NO -> 3.2.
654 3.2. STOP.
656 2.4 Signed Receipt Creation
658 A signed receipt is a signedData object encapsulating a Receipt content
659 (also called a "signedData/Receipt"). Signed receipts are created as
660 follows:
662 1. The signature of the original signedData signerInfo that includes the
663 receiptRequest signed attribute MUST be successfully verified before
664 creating the signedData/Receipt.
666 1.1. The content of the original signedData object is digested as
667 described in [CMS]. The resulting digest value is then compared with
668 the value of the messageDigest attribute included in the
669 signedAttributes of the original signedData signerInfo. If these digest
670 values are different, then the signature verification process fails and
671 the signedData/Receipt MUST NOT be created.
673 1.2. The ASN.1 DER encoded signedAttributes (including messageDigest,
674 receiptRequest and, possibly, other signed attributes) in the original
675 signedData signerInfo are digested as described in [CMS]. The resulting
676 digest value, called msgSigDigest, is then used to verify the signature
677 of the original signedData signerInfo. If the signature verification
678 fails, then the signedData/Receipt MUST NOT be created.
680 2. A Receipt structure is created.
682 2.1. The value of the Receipt version field is set to 1.
684 2.2. The object identifier from the contentType attribute included in
685 the original signedData signerInfo that includes the receiptRequest
686 attribute is copied into the Receipt contentType.
688 2.3. The original signedData signerInfo receiptRequest
689 signedContentIdentifier is copied into the Receipt
690 signedContentIdentifier.
692 2.4. The signature value from the original signedData signerInfo that
693 includes the receiptRequest attribute is copied into the Receipt
694 originatorSignatureValue.
696 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
698 4. D1 is digested. The resulting digest value is included as the
699 messageDigest attribute in the signedAttributes of the signerInfo which
700 will eventually contain the signedData/Receipt signature value.
702 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
703 signature of the original signedData signerInfo is included as the
704 msgSigDigest attribute in the signedAttributes of the signerInfo which will
705 eventually contain the signedData/Receipt signature value.
707 6. A contentType attribute including the id-ct-receipt object identifier
708 MUST be created and added to the signed attributes of the signerInfo which
709 will eventually contain the signedData/Receipt signature value.
711 7. A signingTime attribute indicating the time that the signedData/Receipt
712 is signed SHOULD be created and added to the signed attributes of the
713 signerInfo which will eventually contain the signedData/Receipt signature
714 value. Other attributes (except receiptRequest) may be added to the
715 signedAttributes of the signerInfo.
717 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
718 possibly, others) of the signerInfo are ASN.1 DER encoded and digested as
719 described in [CMS]. The resulting digest value is used to calculate the
720 signature value which is then included in the signedData/Receipt
721 signerInfo.
723 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
724 the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
725 id-ct-receipt object identifier MUST be included in the signedData
726 encapContentInfo eContentType. This results in a single ASN.1 encoded
727 object composed of a signedData including the Receipt content. The Data
728 content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
729 in a MIME header or any other header prior to being encoded as part of the
730 signedData object.
732 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
733 wrapper with the smime-type parameter set to "signed-receipt". This will
734 allow for identification of signed receipts without having to crack the
735 ASN.1 body. The smime-type parameter would still be set as normal in any
736 layer wrapped around this message.
738 11. If the signedData/Receipt is to be encrypted within an envelopedData
739 object, then an outer signedData object MUST be created that encapsulates
740 the envelopedData object, and a contentHints attribute with contentType set
741 to the id-ct-receipt object identifier MUST be included in the outer
742 signedData SignerInfo signedAttributes. When a receiving agent processes
743 the outer signedData object, the presence of the id-ct-receipt OID in the
744 contentHints contentType indicates that a signedData/Receipt is encrypted
745 within the envelopedData object encapsulated by the outer signedData.
747 All sending agents that support the generation of ESS signed receipts MUST
748 provide the ability to send encrypted signed receipts (that is, a
749 signedData/Receipt encapsulated within an envelopedData). The sending agent
750 MAY send an encrypted signed receipt in response to an
751 envelopedData-encapsulated signedData requesting a signed receipt. It is a
752 matter of local policy regarding whether or not the signed receipt should
753 be encrypted. The ESS signed receipt includes the message digest value
754 calculated for the original signedData object that requested the signed
755 receipt. If the original signedData object was sent encrypted within an
756 envelopedData object and the ESS signed receipt is sent unencrypted, then
757 the message digest value calculated for the original encrypted signedData
758 object is sent unencrypted. The responder should consider this when
759 deciding whether or not to encrypt the ESS signed receipt.
761 2.4.1 MLExpansionHistory Attributes and Receipts
763 An MLExpansionHistory attribute MUST NOT be included in the attributes of a
764 SignerInfo in a SignedData object that encapsulates a Receipt content. This
765 is true because when a SignedData/Receipt is sent to an MLA for
766 distribution, then the MLA must always encapsulate the received
767 SignedData/Receipt in an outer SignedData in which the MLA will include the
768 MLExpansionHistory attribute. The MLA cannot change the signedAttributes of
769 the received SignedData/Receipt object, so it can't add the
770 MLExpansionHistory to the SignedData/Receipt.
772 2.5 Determining the Recipients of the Signed Receipt
774 If a signed receipt was created by the process described in the sections
775 above, then the software MUST use the following process to determine to
776 whom the signed receipt should be sent.
778 1. The receiptsTo field must be present in the receiptRequest attribute.
779 The software initiates the sequence of recipients with the value(s) of
780 receiptsTo.
782 2. If the MlExpansionHistory attribute is present in the outer SignedData
783 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
784 then the software replaces the sequence of recipients with the value(s) of
785 insteadOf.
787 3. If the MlExpansionHistory attribute is present in the outer SignedData
788 block and the last MLData contains an MLReceiptPolicy value of
789 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
790 sequence of recipients.
792 2.6. Signed Receipt Validation
794 A signed receipt is communicated as a single ASN.1 encoded object composed
795 of a signedData object directly including a Receipt content. It is
796 identified by the presence of the id-ct-receipt object identifier in the
797 encapContentInfo eContentType value of the signedData object including the
798 Receipt content.
800 Although receipients are not supposed to send more than one signed receipt,
801 receiving agents SHOULD be able to accept multiple signed receipts from a
802 recipient.
804 A signedData/Receipt is validated as follows:
806 1. ASN.1 decode the signedData object including the Receipt content.
808 2. Extract the contentType, signedContentIdentifier, and
809 originatorSignatureValue from the decoded Receipt structure to identify the
810 original signedData signerInfo that requested the signedData/Receipt.
812 3. Acquire the message signature digest value calculated by the sender to
813 generate the signature value included in the original signedData signerInfo
814 that requested the signedData/Receipt.
816 3.1. If the sender-calculated message signature digest value has been
817 saved locally by the sender, it must be located and retrieved.
819 3.2. If it has not been saved, then it must be re-calculated based on
820 the original signedData content and signedAttributes as described in
821 [CMS].
823 4. The message signature digest value calculated by the sender is then
824 compared with the value of the msgSigDigest signedAttribute included in the
825 signedData/Receipt signerInfo. If these digest values are identical, then
826 that proves that the message signature digest value calculated by the
827 recipient based on the received original signedData object is the same as
828 that calculated by the sender. This proves that the recipient received
829 exactly the same original signedData content and signedAttributes as sent
830 by the sender because that is the only way that the recipient could have
831 calculated the same message signature digest value as calculated by the
832 sender. If the digest values are different, then the signedData/Receipt
833 signature verification process fails.
835 5. Acquire the digest value calculated by the sender for the Receipt
836 content constructed by the sender (including the contentType,
837 signedContentIdentifier, and signature value that were included in the
838 original signedData signerInfo that requested the signedData/Receipt).
840 5.1. If the sender-calculated Receipt content digest value has been
841 saved locally by the sender, it must be located and retrieved.
843 5.2. If it has not been saved, then it must be re-calculated. As
844 described in section 2.4 above, step 2, create a Receipt structure
845 including the contentType, signedContentIdentifier and signature value
846 that were included in the original signedData signerInfo that requested
847 the signed receipt. The Receipt structure is then ASN.1 DER encoded to
848 produce a data stream which is then digested to produce the Receipt
849 content digest value.
851 6. The Receipt content digest value calculated by the sender is then
852 compared with the value of the messageDigest signedAttribute included in
853 the signedData/Receipt signerInfo. If these digest values are identical,
854 then that proves that the values included in the Receipt content by the
855 recipient are identical to those that were included in the original
856 signedData signerInfo that requested the signedData/Receipt. This proves
857 that the recipient received the original signedData signed by the sender,
858 because that is the only way that the recipient could have obtained the
859 original signedData signerInfo signature value for inclusion in the Receipt
860 content. If the digest values are different, then the signedData/Receipt
861 signature verification process fails.
863 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
864 signerInfo are digested as described in [CMS].
866 8. The resulting digest value is then used to verify the signature value
867 included in the signedData/Receipt signerInfo. If the signature
868 verification is successful, then that proves the integrity of the
869 signedData/receipt signerInfo signedAttributes and authenticates the
870 identity of the signer of the signedData/Receipt signerInfo. Note that the
871 signedAttributes include the recipient-calculated Receipt content digest
872 value (messageDigest attribute) and recipient-calculated message signature
873 digest value (msgSigDigest attribute). Therefore, the aforementioned
874 comparison of the sender-generated and recipient-generated digest values
875 combined with the successful signedData/Receipt signature verification
876 proves that the recipient received the exact original signedData content
877 and signedAttributes (proven by msgSigDigest attribute) that were signed by
878 the sender of the original signedData object (proven by messageDigest
879 attribute). If the signature verification fails, then the
880 signedData/Receipt signature verification process fails.
882 The signature verification process for each signature algorithm that is
883 used in conjunction with the CMS protocol is specific to the algorithm.
884 These processes are described in documents specific to the algorithms.
886 2.7 Receipt Request Syntax
888 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
889 receiptRequest attribute only within the signed attributes associated with
890 a signed message.
892 ReceiptRequest ::= SEQUENCE {
893 signedContentIdentifier ContentIdentifier,
894 receiptsFrom ReceiptsFrom,
895 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
897 ub-receiptsTo INTEGER ::= 16
899 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
900 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
902 ContentIdentifier ::= OCTET STRING
904 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
905 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
907 A signedContentIdentifier MUST be created by the message originator when
908 creating a receipt request. To ensure global uniqueness, the minimal
909 signedContentIdentifier SHOULD contain a concatenation of user-specific
910 identification information (such as a user name or public keying material
911 identification information), a GeneralizedTime string, and a random number.
913 The receiptsFrom field is used by the originator to specify the recipients
914 requested to return a signed receipt. A CHOICE is provided to allow
915 specification of:
916 - receipts from all recipients are requested
917 - receipts from first tier (recipients that did not receive the
918 message as members of a mailing list) recipients are requested
919 - receipts from a specific list of recipients are requested
921 ReceiptsFrom ::= CHOICE {
922 allOrFirstTier [0] AllOrFirstTier,
923 -- formerly "allOrNone [0]AllOrNone"
924 receiptList [1] SEQUENCE OF GeneralNames }
926 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
927 allReceipts (0),
928 firstTierRecipients (1) }
930 The receiptsTo field is used by the originator to identify the user(s) to
931 whom the identified recipient should send signed receipts. The message
932 originator MUST populate the receiptsTo field with a GeneralNames for each
933 entity to whom the recipient should send the signed receipt. If the message
934 originator wants the recipient to send the signed receipt to the
935 originator, then the originator MUST include a GeneralNames for itself in
936 the receiptsTo field.
938 2.8 Receipt Syntax
940 Receipts are represented using a new content type, Receipt. The Receipt
941 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
942 within a SignedData message.
944 Receipt ::= SEQUENCE {
945 version ESSVersion,
946 contentType ContentType,
947 signedContentIdentifier ContentIdentifier,
948 originatorSignatureValue OCTET STRING }
950 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
951 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
953 ESSVersion ::= INTEGER { v1(1) }
955 The version field defines the syntax version number, which is 1 for this
956 version of the standard.
958 2.9 Content Hints
960 Many applications find it useful to have information that describes the
961 innermost signed content of a multi-layer message available on the
962 outermost signature layer. The contentHints attribute provides such
963 information.
965 Content-hints attribute values have ASN.1 type contentHints.
967 ContentHints ::= SEQUENCE {
968 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
969 contentType ContentType }
971 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
972 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
974 The contentDescription field may be used to provide information that the
975 recipient may use to select protected messages for processing, such as a
976 message subject. If this field is set, then the attribute is expected to
977 appear on the signedData object enclosing an envelopedData object and not
978 on the inner signedData object. The (SIZE (1..MAX)) construct constrains
979 the sequence to have at least one entry. MAX indicates the upper bound is
980 unspecified. Implementations are free to choose an upper bound that suits
981 their environment.
983 Messages which contain a signedData object wrapped around an envelopedData
984 object, thus masking the inner content type of the message, SHOULD include
985 a contentHints attribute, except for the case of the data content type.
986 Specific message content types may either force or preclude the inclusion
987 of the contentHints attribute. For example, when a signedData/Receipt is
988 encrypted within an envelopedData object, an outer signedData object MUST
989 be created that encapsulates the envelopedData object and a contentHints
990 attribute with contentType set to the id-ct-receipt object identifier MUST
991 be included in the outer signedData SignerInfo signedAttributes.
993 2.10 Message Signature Digest Attribute
995 The msgSigDigest attribute can only be used in the signed attributes of a
996 signed receipt. It contains the digest of the ASN.1 DER encoded
997 signedAttributes included in the original signedData that requested the
998 signed receipt. Only one msgSigDigest attribute can appear in an signed
999 attributes set. It is defined as follows:
1001 msgSigDigest ::= OCTET STRING
1003 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1004 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
1006 2.11 Signed Content Reference Attribute
1008 The contentReference attribute is a link from one SignedData to another. It
1009 may be used to link a reply to the original message to which it refers, or
1010 to incorporate by reference one SignedData into another. The first
1011 SignedData MUST include a contentIdentifier signed attribute, which SHOULD
1012 be constructed as specified in section 2.7. The second SignedData links to
1013 the first by including a ContentReference signed attribute containing the
1014 content type, content identifier, and signature value from the first
1015 SignedData.
1017 ContentReference ::= SEQUENCE {
1018 contentType ContentType,
1019 signedContentIdentifier ContentIdentifier,
1020 originatorSignatureValue OCTET STRING }
1022 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1023 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
1025 3. Security Labels
1027 This section describes the syntax to be used for security labels that can
1028 optionally be associated with S/MIME encapsulated data. A security label is
1029 a set of security information regarding the sensitivity of the content that
1030 is protected by S/MIME encapsulation.
1032 "Authorization" is the act of granting rights and/or privileges to users
1033 permitting them access to an object. "Access control" is a means of
1034 enforcing these authorizations. The sensitivity information in a security
1035 label can be compared with a user's authorizations to determine if the user
1036 is allowed to access the content that is protected by S/MIME encapsulation.
1038 Security labels may be used for other purposes such as a source of routing
1039 information. The labels often describe ranked levels ("secret",
1040 "confidential", "restricted", and so on) or are role-based, describing
1041 which kind of people can see the information ("patient's health-care team",
1042 "medical billing agents", "unrestricted", and so on).
1044 3.1 Security Label Processing Rules
1046 A sending agent may include a security label attribute in the signed
1047 attributes of a signedData object. A receiving agent examines the security
1048 label on a received message and determines whether or not the recipient is
1049 allowed to see the contents of the message.
1051 3.1.1 Adding Security Labels
1053 A sending agent that is using security labels MUST put the security label
1054 attribute in the signedAttributes field of a SignerInfo block. The security
1055 label attribute MUST NOT be included in the unsigned attributes. Integrity
1056 and authentication security services MUST be applied to the security label,
1057 therefore it MUST be included as an signed attribute, if used. This causes
1058 the security label attribute to be part of the data that is hashed to form
1059 the SignerInfo signature value. A SignerInfo block MUST NOT have more than
1060 one security label signed attribute.
1062 When there are multiple SignedData blocks applied to a message, a security
1063 label attribute may be included in either the inner signature, outer
1064 signature, or both. A security label signed attribute may be included in a
1065 signedAttributes field within the inner SignedData block. The inner
1066 security label will include the sensitivities of the original content and
1067 will be used for access control decisions related to the plaintext
1068 encapsulated content. The inner signature provides authentication of the
1069 inner security label and cryptographically protects the original signer's
1070 inner security label of the original content.
1072 When the originator signs the plaintext content and signed attributes, the
1073 inner security label is bound to the plaintext content. An intermediate
1074 entity cannot change the inner security label without invalidating the
1075 inner signature. The confidentiality security service can be applied to the
1076 inner security label by encrypting the entire inner signedData object
1077 within an EnvelopedData block.
1079 A security label signed attribute may also be included in a
1080 signedAttributes field within the outer SignedData block. The outer
1081 security label will include the sensitivities of the encrypted message and
1082 will be used for access control decisions related to the encrypted message
1083 and for routing decisions. The outer signature provides authentication of
1084 the outer security label (as well as for the encapsulated content which may
1085 include nested S/MIME messages).
1087 There can be multiple SignerInfos within a SignedData object, and each
1088 SignerInfo may include signedAttributes. Therefore, a single SignedData
1089 object may include multiple eSSSecurityLabels, each SignerInfo having an
1090 eSSSecurityLabel attribute. For example, an originator can send a signed
1091 message with two SignerInfos, one containing a DSS signature, the other
1092 containing an RSA signature. If any of the SignerInfos included in a
1093 SignedData object include an eSSSecurityLabel attribute, then all of the
1094 SignerInfos in that SignedData object MUST include an eSSSecurityLabel
1095 attribute and the value of each MUST be identical.
1097 3.1.2 Processing Security Labels
1099 Before processing an eSSSecurityLabel signedAttribute, the receiving agent
1100 MUST verify the signature of the SignerInfo which covers the
1101 eSSSecurityLabel attribute. A recipient MUST NOT process an
1102 eSSSecurityLabel attribute that has not been verified.
1104 A receiving agent MUST process the eSSSecurityLabel attribute, if present,
1105 in each SignerInfo in the SignedData object for which it verifies the
1106 signature. This may result in the receiving agent processing multiple
1107 eSSSecurityLabels included in a single SignedData object. Because all
1108 eSSSecurityLabels in a SignedData object must be identical, the receiving
1109 agent processes (such as performing access control) on the first
1110 eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
1111 then ensures that all other eSSSecurityLabels in signerInfos that it
1112 verifies are identical to the first one encountered. If the
1113 eSSSecurityLabels in the signerInfos that it verifies are not all
1114 identical, then the receiving agent MUST warn the user of this condition.
1116 Receiving agents SHOULD have a local policy regarding whether or not to
1117 show the inner content of a signedData object that includes an
1118 eSSSecurityLabel security-policy-identifier that the processing software
1119 does not recognize. If the receiving agent does not recognize the
1120 eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
1121 processing the message and indicate an error.
1123 3.2 Syntax of eSSSecurityLabel
1125 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
1126 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
1127 ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
1128 [MSP4].
1130 ESSSecurityLabel ::= SET {
1131 security-policy-identifier SecurityPolicyIdentifier,
1132 security-classification SecurityClassification OPTIONAL,
1133 privacy-mark ESSPrivacyMark OPTIONAL,
1134 security-categories SecurityCategories OPTIONAL }
1136 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1137 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
1139 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1141 SecurityClassification ::= INTEGER {
1142 unmarked (0),
1143 unclassified (1),
1144 restricted (2),
1145 confidential (3),
1146 secret (4),
1147 top-secret (5) } (0..ub-integer-options)
1149 ub-integer-options INTEGER ::= 256
1151 ESSPrivacyMark ::= CHOICE {
1152 pString PrintableString (SIZE (1..ub-privacy-mark-length)),
1153 utf8String UTF8String (SIZE (1..MAX))
1154 }
1156 ub-privacy-mark-length INTEGER ::= 128
1158 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1159 SecurityCategory
1161 ub-security-categories INTEGER ::= 64
1163 SecurityCategory ::= SEQUENCE {
1164 type [0] OBJECT IDENTIFIER,
1165 value [1] ANY DEFINED BY type -- defined by type
1166 }
1168 --Note: The aforementioned SecurityCategory syntax produces identical
1169 --hex encodings as the following SecurityCategory syntax that is
1170 --documented in the X.411 specification:
1171 --
1172 --SecurityCategory ::= SEQUENCE {
1173 -- type [0] SECURITY-CATEGORY,
1174 -- value [1] ANY DEFINED BY type }
1175 --
1176 --SECURITY-CATEGORY MACRO ::=
1177 --BEGIN
1178 --TYPE NOTATION ::= type | empty
1179 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1180 --END
1182 3.3 Security Label Components
1184 This section gives more detail on the the various components of the
1185 eSSSecurityLabel syntax.
1187 3.3.1 Security Policy Identifier
1189 A security policy is a set of criteria for the provision of security
1190 services. The eSSSecurityLabel security-policy-identifier is used to
1191 identify the security policy in force to which the security label relates.
1192 It indicates the semantics of the other security label components.
1194 3.3.2 Security Classification
1196 This specification defines the use of the Security Classification field
1197 exactly as is specified in the X.411 Recommendation, which states in part:
1199 If present, a security-classification may have one of a hierarchical
1200 list of values. The basic security-classification hierarchy is defined
1201 in this Recommendation, but the use of these values is defined by the
1202 security-policy in force. Additional values of security-classification,
1203 and their position in the hierarchy, may also be defined by a
1204 security-policy as a local matter or by bilateral agreement. The basic
1205 security-classification hierarchy is, in ascending order: unmarked,
1206 unclassified, restricted, confidential, secret, top-secret.
1208 This means that the security policy in force (identified by the
1209 eSSSecurityLabel security-policy-identifier) defines the
1210 SecurityClassification integer values and their meanings.
1212 An organization can develop its own security policy that defines the
1213 SecurityClassification INTEGER values and their meanings. However, the
1214 general interpretation of the X.411 specification is that the values of 0
1215 through 5 are reserved for the "basic hierarchy" values of unmarked,
1216 unclassified, restricted, confidential, secret, and top-secret. Note that
1217 X.411 does not provide the rules for how these values are used to label
1218 data and how access control is performed using these values.
1220 There is no universal definition of the rules for using these "basic
1221 hierarchy" values. Each organization (or group of organizations) will
1222 define a security policy which documents how the "basic hierarchy" values
1223 are used (if at all) and how access control is enforced (if at all) within
1224 their domain.
1226 Therefore, the security-classification value MUST be accompanied by a
1227 security-policy-identifier value to define the rules for its use. For
1228 example, a company's "secret" classification may convey a different meaning
1229 than the US Government "secret" classification. In summary, a security
1230 policy SHOULD NOT use integers 0 through 5 for other than their X.411
1231 meanings, and SHOULD instead use other values in a hierarchical fashion.
1233 Note that the set of valid security-classification values MUST be
1234 hierarchical, but these values do not necessarily need to be in ascending
1235 numerical order. Further, the values do not need to be contiguous.
1237 For example, in the Defense Message System 1.0 security policy, the
1238 security-classification value of 11 indicates Sensitive-But-Unclassified
1239 and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret
1240 as more sensitive than Sensitive-But-Unclassified even though the numerical
1241 value of top-secret is less than Sensitive-But-Unclassified.
1243 (Of course, if security-classification values are both hierarchical and in
1244 ascending order, a casual reader of the security policy is more likely to
1245 understand it.)
1247 An example of a security policy that does not use any of the X.411 values
1248 might be:
1249 10 -- anyone
1250 15 -- Morgan Corporation and its contractors
1251 20 -- Morgan Corporation employees
1252 25 -- Morgan Corporation board of directors
1254 An example of a security policy that uses part of the X.411 hierarchy might
1255 be:
1256 0 -- unmarked
1257 1 -- unclassified, can be read by everyone
1258 2 -- restricted to Timberwolf Productions staff
1259 6 -- can only be read to Timberwolf Productions executives
1261 3.3.3 Privacy Mark
1263 If present, the eSSSecurityLabel privacy-mark is not used for access
1264 control. The content of the eSSSecurityLabel privacy-mark may be defined by
1265 the security policy in force (identified by the eSSSecurityLabel
1266 security-policy-identifier) which may define a list of values to be used.
1267 Alternately, the value may be determined by the originator of the
1268 security-label.
1270 3.3.4 Security Categories
1272 If present, the eSSSecurityLabel security-categories provide further
1273 granularity for the sensitivity of the message. The security policy in
1274 force (identified by the eSSSecurityLabel security-policy-identifier) is
1275 used to indicate the syntaxes that are allowed to be present in the
1276 eSSSecurityLabel security-categories. Alternately, the security-categories
1277 and their values may be defined by bilateral agreement.
1279 3.4 Equivalent Security Labels
1281 Because organizations are allowed to define their own security policies,
1282 many different security policies will exist. Some organizations may wish to
1283 create equivalencies between their security policies with the security
1284 policies of other organizations. For example, the Acme Company and the
1285 Widget Corporation may reach a bilateral agreement that the "Acme private"
1286 security-classification value is equivalent to the "Widget sensitive"
1287 security-classification value.
1289 Receiving agents MUST NOT process an equivalentLabels attribute in a
1290 message if the agent does not trust the signer of that attribute to
1291 translate the original eSSSecurityLabel values to the security policy
1292 included in the equivalentLabels attribute. Receiving agents have the
1293 option to process equivalentLabels attributes but do not have to. It is
1294 acceptable for a receiving agent to only process eSSSecurityLabels. All
1295 receiving agents SHOULD recognize equivalentLabels attributes even if they
1296 do not process them.
1298 3.4.1 Creating Equivalent Labels
1300 The EquivalentLabels signed attribute is defined as:
1302 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
1304 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1305 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
1307 As stated earlier, the ESSSecurityLabel contains the sensitivity values
1308 selected by the original signer of the signedData. If an ESSSecurityLabel
1309 is present in a signerInfo, all signerInfos in the signedData MUST contain
1310 an ESSSecurityLabel and they MUST all be identical. In addition to an
1311 ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed
1312 attribute. If present, the equivalentLabels attribute MUST include one or
1313 more security labels that are believed by the signer to be semantically
1314 equivalent to the ESSSecurityLabel attribute included in the same
1315 signerInfo.
1317 All security-policy object identifiers MUST be unique in the set of
1318 ESSSecurityLabel and EquivalentLabels security labels. Before using an
1319 EquivalentLabels attribute, a receiving agent MUST ensure that all
1320 security-policy OIDs are unique in the security label or labels included in
1321 the EquivalentLabels. Once the receiving agent selects the security label
1322 (within the EquivalentLabels) to be used for processing, then the
1323 security-policy OID of the selected EquivalentLabels security label MUST be
1324 compared with the ESSSecurityLabel security-policy OID to ensure that they
1325 are unique.
1327 In the case that an ESSSecurityLabel attribute is not included in a
1328 signerInfo, then an EquivalentLabels attribute may still be included. For
1329 example, in the Acme security policy, the absence of an ESSSecurityLabel
1330 could be defined to equate to a security label composed of the Acme
1331 security-policy OID and the "unmarked" security-classification.
1333 Note that equivalentLabels MUST NOT be used to convey security labels that
1334 are semantically different from the ESSSecurityLabel included in the
1335 signerInfos in the signedData. If an entity needs to apply a security label
1336 that is semantically different from the ESSSecurityLabel, then it MUST
1337 include the sematically different security label in an outer signedData
1338 object that encapsulates the signedData object that includes the
1339 ESSSecurityLabel.
1341 If present, the equivalentLabels attribute MUST be an signed attribute; it
1342 MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET
1343 OF Attribute. A signerInfo MUST NOT include multiple instances of the
1344 equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
1345 attributes to include attrValues SET OF AttributeValue. A equivalentLabels
1346 attribute MUST only include a single instance of AttributeValue. There MUST
1347 NOT be zero or multiple instances of AttributeValue present in the
1348 attrValues SET OF AttributeValue.
1350 3.4.2 Processing Equivalent Labels
1352 A receiving agent SHOULD process the ESSSecurityLabel before processing any
1353 EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
1354 the receiving agent, it MUST process that label and MUST ignore all
1355 EquivalentLabels.
1357 When processing an EquivalentLabels attribute, the receiving agent MUST
1358 validate the signature on the EquivalentLabels attribute. A receiving agent
1359 MUST NOT act on an equivalentLabels attribute for which the signature could
1360 not be validated, and MUST NOT act on an equivalentLabels attribute unless
1361 that attribute is signed by an entity trusted to translate the original
1362 eSSSecurityLabel values to the security policy included in the
1363 equivalentLabels attribute. Determining who is allowed to specify
1364 equivalence mappings is a local policy. If a message has more than one
1365 EquivalentLabels attribute, the receiving agent SHOULD process the first
1366 one that it reads and validates that contains the security policy of
1367 interest to the receiving agent.
1369 4. Mail List Management
1371 Sending agents must create recipient-specific data structures for each
1372 recipient of an encrypted message. This process can impair performance for
1373 messages sent to a large number of recipients. Thus, Mail List Agents
1374 (MLAs) that can take a single message and perform the recipient-specific
1375 encryption for every recipient are often desired.
1377 An MLA appears to the message originator as a normal message recipient, but
1378 the MLA acts as a message expansion point for a Mail List (ML). The sender
1379 of a message directs the message to the MLA, which then redistributes the
1380 message to the members of the ML. This process offloads the per-recipient
1381 processing from individual user agents and allows for more efficient
1382 management of large MLs. MLs are true message recipients served by MLAs
1383 that provide cryptographic and expansion services for the mailing list.
1385 In addition to cryptographic handling of messages, secure mailing lists
1386 also have to prevent mail loops. A mail loop is where one mailing list is a
1387 member of a second mailing list, and the second mailing list is a member of
1388 the first. A message will go from one list to the other in a
1389 rapidly-cascading succession of mail that will be distributed to all other
1390 members of both lists.
1392 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
1393 outer signature of a triple wrapped message. The mlExpansionHistory
1394 attribute is essentially a list of every MLA that has processed the
1395 message. If an MLA sees its own unique entity identifier in the list, it
1396 knows that a loop has been formed, and does not send the message to the
1397 list again.
1399 4.1 Mail List Expansion
1401 Mail list expansion processing is noted in the value of the
1402 mlExpansionHistory attribute, located in the signed attributes of the MLA's
1403 SignerInfo block. The MLA creates or updates the signed mlExpansionHistory
1404 attribute value each time the MLA expands and signs a message for members
1405 of a mail list.
1407 The MLA MUST add an MLData record containing the MLA's identification
1408 information, date and time of expansion, and optional receipt policy to the
1409 end of the mail list expansion history sequence. If the mlExpansionHistory
1410 attribute is absent, then the MLA MUST add the attribute and the current
1411 expansion becomes the first element of the sequence. If the
1412 mlExpansionHistory attribute is present, then the MLA MUST add the current
1413 expansion information to the end of the existing MLExpansionHistory
1414 sequence. Only one mlExpansionHistory attribute can be included in the
1415 signedAttributes of a SignerInfo.
1417 Note that if the mlExpansionHistory attribute is absent, then the recipient
1418 is a first tier message recipient.
1420 There can be multiple SignerInfos within a SignedData object, and each
1421 SignerInfo may include signedAttributes. Therefore, a single SignedData
1422 object may include multiple SignerInfos, each SignerInfo having a
1423 mlExpansionHistory attribute. For example, an MLA can send a signed message
1424 with two SignerInfos, one containing a DSS signature, the other containing
1425 an RSA signature.
1427 If an MLA creates a SignerInfo that includes an mlExpansionHistory
1428 attribute, then all of the SignerInfos created by the MLA for that
1429 SignedData object MUST include an mlExpansionHistory attribute, and the
1430 value of each MUST be identical. Note that other agents might later add
1431 SignerInfo attributes to the SignedData block, and those additional
1432 SignerInfos might not include mlExpansionHistory attributes.
1434 A recipient MUST verify the signature of the SignerInfo which covers the
1435 mlExpansionHistory attribute before processing the mlExpansionHistory, and
1436 MUST NOT process the mlExpansionHistory attribute unless the signature over
1437 it has been verified. If a SignedData object has more than one SignerInfo
1438 that has an mlExpansionHistory attribute, the recipient MUST compare the
1439 mlExpansionHistory attributes in all the SignerInfos that it has verified,
1440 and MUST NOT process the mlExpansionHistory attribute unless every verified
1441 mlExpansionHistory attribute in the SignedData block is identical. If the
1442 mlExpansionHistory attributes in the verified signerInfos are not all
1443 identical, then the receiving agent MUST stop processing the message and
1444 SHOULD notify the user or MLA administrator of this error condition. In the
1445 mlExpansionHistory processing, SignerInfos that do not have an
1446 mlExpansionHistory attribute are ignored.
1448 4.1.1 Detecting Mail List Expansion Loops
1450 Prior to expanding a message, the MLA examines the value of any existing
1451 mail list expansion history attribute to detect an expansion loop. An
1452 expansion loop exists when a message expanded by a specific MLA for a
1453 specific mail list is redelivered to the same MLA for the same mail list.
1455 Expansion loops are detected by examining the mailListIdentifier field of
1456 each MLData entry found in the mail list expansion history. If an MLA finds
1457 its own identification information, then the MLA must discontinue expansion
1458 processing and should provide warning of an expansion loop to a human mail
1459 list administrator. The mail list administrator is responsible for
1460 correcting the loop condition.
1462 4.2 Mail List Agent Processing
1464 The first few paragraphs of this section provide a high-level description
1465 of MLA processing. The rest of the section provides a detailed description
1466 of MLA processing.
1468 MLA message processing depends on the structure of the S/MIME layers in the
1469 message sent to the MLA for expansion. In addition to sending triple
1470 wrapped messages to an MLA, an entity can send other types of messages to
1471 an MLA, such as:
1472 - a single wrapped signedData or envelopedData message
1473 - a double wrapped message (such as signed and enveloped, enveloped and
1474 signed, or signed and signed, and so on)
1475 - a quadruple-wrapped message (such as if a well-formed triple wrapped
1476 message was sent through a gateway that added an outer SignedData layer)
1478 In all cases, the MLA MUST parse all layers of the received message to
1479 determine if there are any signedData layers that include an
1480 eSSSecurityLabel signedAttribute. This may include decrypting an
1481 EnvelopedData layer to determine if an encapsulated SignedData layer
1482 includes an eSSSecurityLabel attribute. The MLA MUST fully process each
1483 eSSSecurityLabel attribute found in the various signedData layers,
1484 including performing access control checks, before distributing the message
1485 to the ML members. The details of the access control checks are beyond the
1486 scope of this document. The MLA MUST verify the signature of the signerInfo
1487 including the eSSSecurityLabel attribute before using it.
1489 In all cases, the MLA MUST sign the message to be sent to the ML members in
1490 a new "outer" signedData layer. The MLA MUST add or update an
1491 mlExpansionHistory attribute in the "outer" signedData that it creates to
1492 document MLA processing. If there was an "outer" signedData layer included
1493 in the original message received by the MLA, then the MLA-created "outer"
1494 signedData layer MUST include each signed attribute present in the
1495 original "outer" signedData layer, unless the MLA explicitly replaces an
1496 attribute (such as signingTime or mlExpansionHistory) with a new value.
1498 When an S/MIME message is received by the MLA, the MLA MUST first determine
1499 which received signedData layer, if any, is the "outer" signedData layer.
1500 To identify the received "outer" signedData layer, the MLA MUST verify the
1501 signature and fully process the signedAttributes in each of the
1502 outer signedData layers (working from the outside in) to determine if any
1503 of them either include an mlExpansionHistory attribute or encapsulate an
1504 envelopedData object.
1506 The MLA's search for the "outer" signedData layer is completed when it
1507 finds one of the following:
1508 - the "outer" signedData layer that includes an mlExpansionHistory
1509 attribute or encapsulates an envelopedData object
1510 - an envelopedData layer
1511 - the original content (that is, a layer that is neither envelopedData nor
1512 signedData).
1514 If the MLA finds an "outer" signedData layer, then the MLA MUST perform
1515 the following steps:
1517 1. Strip off all of the signedData layers that encapsulated the "outer"
1518 signedData layer
1520 2. Strip off the "outer" signedData layer itself (after remembering the
1521 included signedAttributes)
1523 3. Expand the envelopedData (if present)
1525 4. Sign the message to be sent to the ML members in a new "outer"
1526 signedData layer that includes the signedAttributes (unless explicitly
1527 replaced) from the original, received "outer" signedData layer.
1529 If the MLA finds an "outer" signedData layer that includes an
1530 mlExpansionHistory attribute AND the MLA subsequently finds an
1531 envelopedData layer buried deeper with the layers of the received message,
1532 then the MLA MUST strip off all of the signedData layers down to the
1533 envelopedData layer (including stripping off the original "outer"
1534 signedData layer) and MUST sign the expanded envelopedData in a new "outer"
1535 signedData layer that includes the signedAttributes (unless explicitly
1536 replaced) from the original, received "outer" signedData layer.
1538 If the MLA does not find an "outer" signedData layer AND does not find an
1539 envelopedData layer, then the MLA MUST sign the original, received message
1540 in a new "outer" signedData layer. If the MLA does not find an "outer"
1541 signedData AND does find an envelopedData layer then it MUST expand the
1542 envelopedData layer, if present, and sign it in a new "outer" signedData
1543 layer.
1545 4.2.1 Examples of Rule Processing
1547 The following examples help explain the rules above:
1549 1) A message (S1(Original Content)) (where S = SignedData) is sent to the
1550 MLA in which the signedData layer does not include an MLExpansionHistory
1551 attribute. The MLA verifies and fully processes the signedAttributes in S1.
1552 The MLA decides that there is not an original, received "outer" signedData
1553 layer since it finds the original content, but never finds an envelopedData
1554 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1555 signedData layer, S2, resulting in the following message sent to the ML
1556 recipients: (S2(S1(Original Content))). The MLA includes an
1557 mlExpansionHistory attribute in S2.
1559 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which
1560 none of the signedData layers includes an MLExpansionHistory attribute. The
1561 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The
1562 MLA decides that there is not an original, received "outer" signedData
1563 layer since it finds the original content, but never finds an envelopedData
1564 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1565 signedData layer, S4, resulting in the following message sent to the ML
1566 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an
1567 mlExpansionHistory attribute in S4.
1569 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent
1570 to the MLA in which S1 does not include an MLExpansionHistory attribute.
1571 The MLA decides that there is not an original, received "outer" signedData
1572 layer since it finds the E1 as the outer layer. The MLA expands the
1573 recipientInformation in E1. The MLA calculates a new signedData layer, S2,
1574 resulting in the following message sent to the ML recipients:
1575 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory
1576 attribute in S2.
1578 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
1579 includes an MLExpansionHistory attribute. The MLA verifies the signature
1580 and fully processes the signedAttributes in S2. The MLA finds the
1581 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
1582 signedData. The MLA remembers the signedAttributes included in S2 for later
1583 inclusion in the new outer signedData that it applies to the message. The
1584 MLA strips off S2. The MLA then expands the recipientInformation in E1
1585 (this invalidates the signature in S2 which is why it was stripped). The
1586 MLA calculates a new signedData layer, S3, resulting in the following
1587 message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA
1588 includes in S3 the attributes from S2 (unless it specifically replaces an
1589 attribute value) including an updated mlExpansionHistory attribute.
1591 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1592 none of the signedData layers include an MLExpansionHistory attribute. The
1593 MLA verifies the signature and fully processes the signedAttributes in S3
1594 and S2. When the MLA encounters E1, then it decides that S2 is the "outer"
1595 signedData since S2 encapsulates E1. The MLA remembers the signedAttributes
1596 included in S2 for later inclusion in the new outer signedData that it
1597 applies to the message. The MLA strips off S3 and S2. The MLA then expands
1598 the recipientInformation in E1 (this invalidates the signatures in S3 and
1599 S2 which is why they were stripped). The MLA calculates a new signedData
1600 layer, S4, resulting in the following message sent to the ML recipients:
1601 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1602 S2 (unless it specifically replaces an attribute value) and includes a new
1603 mlExpansionHistory attribute.
1605 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1606 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
1607 the signature and fully processes the signedAttributes in S3. The MLA finds
1608 the mlExpansionHistory in S3, so it decides that S3 is the "outer"
1609 signedData. The MLA remembers the signedAttributes included in S3 for later
1610 inclusion in the new outer signedData that it applies to the message. The
1611 MLA keeps on parsing encapsulated layers because it must determine if there
1612 are any eSSSecurityLabel attributes contained within. The MLA verifies the
1613 signature and fully processes the signedAttributes in S2. When the MLA
1614 encounters E1, then it strips off S3 and S2. The MLA then expands the
1615 recipientInformation in E1 (this invalidates the signatures in S3 and S2
1616 which is why they were stripped). The MLA calculates a new signedData
1617 layer, S4, resulting in the following message sent to the ML recipients:
1618 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1619 S3 (unless it specifically replaces an attribute value) including an
1620 updated mlExpansionHistory attribute.
1622 4.2.3 Processing Choices
1624 The processing used depends on the type of the outermost layer of the
1625 message. There are three cases for the type of the outermost data:
1626 - EnvelopedData
1627 - SignedData
1628 - data
1630 4.2.3.1 Processing for EnvelopedData
1632 1. The MLA locates its own RecipientInfo and uses the information it
1633 contains to obtain the message key.
1635 2. The MLA removes the existing recipientInfos field and replaces it with a
1636 new recipientInfos value built from RecipientInfo structures created for
1637 each member of the mailing list. The MLA also removes the existing
1638 originatorInfo field and replaces it with a new originatorInfo value built
1639 from information describing the MLA.
1641 3. The MLA encapsulates the expanded encrypted message in a SignedData
1642 block, adding an mlExpansionHistory attribute as described in the "Mail
1643 List Expansion" section to document the expansion.
1645 4. The MLA signs the new message and delivers the updated message to mail
1646 list members to complete MLA processing.
1648 4.2.3.2 Processing for SignedData
1650 MLA processing of multi-layer messages depends on the type of data in each
1651 of the layers. Step 3 below specifies that different processing will take
1652 place depending on the type of CMS message that has been signed. That is,
1653 it needs to know the type of data at the next inner layer, which may or may
1654 not be the innermost layer.
1656 1. The MLA verifies the signature value found in the outermost SignedData
1657 layer associated with the signed data. MLA processing of the message
1658 terminates if the message signature is invalid.
1660 2. If the outermost SignedData layer includes an signed mlExpansionHistory
1661 attribute, the MLA checks for an expansion loop as described in the
1662 "Detecting Mail List Expansion Loops" section, then go to step 3. If the
1663 outermost SignedData layer does not include an signed mlExpansionHistory
1664 attribute, the MLA signs the whole message (including this outermost
1665 SignedData layer that doesn't have an mlExpansionHistory attribute), and
1666 delivers the updated message to mail list members to complete MLA
1667 processing.
1669 3. Determine the type of the data that has been signed. That is, look at
1670 the type of data on the layer just below the SignedData, which may or may
1671 not be the "innermost" layer. Based on the type of data, perform either
1672 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1673 types).
1675 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1676 processing of the encrypted message as described previously. Note that
1677 this process invalidates the signature value in the outermost
1678 SignedData layer associated with the original encrypted message.
1679 Proceed to section 3.2 with the result of the expansion.
1681 3.2. If the signed data is SignedData, or is the result of expanding an
1682 EnvelopedData block in step 3.1:
1684 3.2.1. The MLA strips the existing outermost SignedData layer after
1685 remembering the value of the mlExpansionHistory and all other
1686 signed attributes in that layer, if present.
1688 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1689 encapsulates the expanded encrypted message in a new outermost
1690 SignedData layer. On the other hand, if the signed data is
1691 SignedData (from step 3.2), the MLA encapsulates the signed data in
1692 a new outermost SignedData layer.
1694 3.2.3. The outermost signedData layer created by the MLA replaces
1695 the original outermost signedData layer. The MLA MUST create an
1696 signed attribute list for the new outermost signedData layer which
1697 MUST include each signed attribute present in the original
1698 outermost signedData layer, unless the MLA explicitly replaces one
1699 or more particular attributes with new value. A special case is the
1700 mlExpansionHistory attribute. The MLA MUST add an
1701 mlExpansionHistory signed attribute to the outer signedData layer
1702 as follows:
1704 3.2.3.1. If the original outermost SignedData layer included an
1705 mlExpansionHistory attribute, the attribute's value is copied
1706 and updated with the current ML expansion information as
1707 described in the "Mail List Expansion" section.
1709 3.2.3.2. If the original outermost SignedData layer did not
1710 include an mlExpansionHistory attribute, a new attribute value
1711 is created with the current ML expansion information as
1712 described in the "Mail List Expansion" section.
1714 3.3. If the signed data is not EnvelopedData or SignedData:
1716 3.3.1. The MLA encapsulates the received signedData object in an
1717 outer SignedData object, and adds an mlExpansionHistory attribute
1718 to the outer SignedData object containing the current ML expansion
1719 information as described in the "Mail List Expansion" section.
1721 4. The MLA signs the new message and delivers the updated message to mail
1722 list members to complete MLA processing.
1724 A flow chart for the above steps would be:
1726 1. Has a valid signature?
1727 YES -> 2.
1728 NO -> STOP.
1729 2. Does outermost SignedData layer contain mlExpansionHistory?
1730 YES -> Check it, then -> 3.
1731 NO -> Sign message (including outermost SignedData that
1732 doesn't have mlExpansionHistory), deliver it, STOP.
1733 3. Check type of data just below outermost SignedData.
1734 EnvelopedData -> 3.1.
1735 SignedData -> 3.2.
1736 all others -> 3.3.
1737 3.1. Expand the encrypted message, then -> 3.2.
1738 3.2. -> 3.2.1.
1739 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
1740 and other signed attributes, then -> 3.2.2.
1741 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1742 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
1743 YES -> copy the old mlExpansionHistory values, then -> 4.
1744 NO -> create new mlExpansionHistory value, then -> 4.
1745 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
1746 attribute, then -> 4.
1747 4. Sign message, deliver it, STOP.
1749 4.2.3.3 Processing for data
1751 1. The MLA encapsulates the message in a SignedData layer, and adds an
1752 mlExpansionHistory attribute containing the current ML expansion
1753 information as described in the "Mail List Expansion" section.
1755 2. The MLA signs the new message and delivers the updated message to mail
1756 list members to complete MLA processing.
1758 4.3 Mail List Agent Signed Receipt Policy Processing
1760 If a mailing list (B) is a member of another mailing list (A), list B often
1761 needs to propagate forward the mailing list receipt policy of A. As a
1762 general rule, a mailing list should be conservative in propagating forward
1763 the mailing list receipt policy because the ultimate recipient need only
1764 process the last item in the ML expansion history. The MLA builds the
1765 expansion history to meet this requirement.
1767 The following table describes the outcome of the union of mailing list A's
1768 policy (the rows in the table) and mailing list B's policy (the columns in
1769 the table).
1771 | B's policy
1772 A's policy | none insteadOf inAdditionTo missing
1773 -------------------------------------------------------------------------
1774 none | none none none none
1775 insteadOf | none insteadOf(B) *1 insteadOf(A)
1776 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
1777 missing | none insteadOf(B) inAdditionTo(B) missing
1779 *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
1780 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
1782 4.4 Mail List Expansion History Syntax
1784 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1785 there are more than ub-ml-expansion-history mailing lists in the sequence,
1786 the receiving agent should provide notification of the error to a human
1787 mail list administrator. The mail list administrator is responsible for
1788 correcting the overflow condition.
1790 MLExpansionHistory ::= SEQUENCE
1791 SIZE (1..ub-ml-expansion-history) OF MLData
1793 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1794 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
1796 ub-ml-expansion-history INTEGER ::= 64
1798 MLData contains the expansion history describing each MLA that has
1799 processed a message. As an MLA distributes a message to members of an ML,
1800 the MLA records its unique identifier, date and time of expansion, and
1801 receipt policy in an MLData structure.
1803 MLData ::= SEQUENCE {
1804 mailListIdentifier EntityIdentifier,
1805 expansionTime GeneralizedTime,
1806 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1808 EntityIdentifier ::= CHOICE {
1809 issuerAndSerialNumber IssuerAndSerialNumber,
1810 subjectKeyIdentifier SubjectKeyIdentifier }
1812 The receipt policy of the ML can withdraw the originator's request for the
1813 return of a signed receipt. However, if the originator of the message has
1814 not requested a signed receipt, the MLA cannot request a signed receipt. In
1815 the event that a ML's signed receipt policy supersedes the originator's
1816 request for signed receipts, such that the originator will not receive any
1817 signed receipts, then the MLA MAY inform the originator of that fact.
1819 When present, the mlReceiptPolicy specifies a receipt policy that
1820 supersedes the originator's request for signed receipts. The policy can be
1821 one of three possibilities: receipts MUST NOT be returned (none); receipts
1822 should be returned to an alternate list of recipients, instead of to the
1823 originator (insteadOf); or receipts should be returned to a list of
1824 recipients in addition to the originator (inAdditionTo).
1826 MLReceiptPolicy ::= CHOICE {
1827 none [0] NULL,
1828 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
1829 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
1831 5. Signing Certificate Attribute
1833 Concerns have been raised over the fact that the certificate which the
1834 signer of a CMS SignedData object desired to be bound into the verification
1835 process of the SignedData object is not cryptographically bound into the
1836 signature itself. This section addresses this issue by creating a new
1837 attribute to be placed in the signed attributes section of a SignerInfo
1838 object.
1840 This section also presents a description of a set of possible attacks
1841 dealing with the substitution of one certificate to verify the signature
1842 for the desired certificate. A set of ways for preventing or addressing
1843 these attacks is presented to deal with the simplest of the attacks.
1845 Attribute certificates can be used as part of a signature verification
1846 process. There is no way in CMS to include the list of attribute
1847 certificates to be used in the verification process. The set of attribute
1848 certificates used in the signature verification process needs to have the
1849 ability for the signer to restrict the set of certificates. This
1850 information needs to be encoded in a manner that is covered by the
1851 signature on the SignedData object. The methods in this section allows for
1852 the set of attribute certificates to be listed as part of the signing
1853 certificate attribute.
1855 Explicit certificate policies can also be used as part of a signature
1856 verification process. If a signer desires to state an explicit certificate
1857 policy that should be used when validating the signature, that policy needs
1858 to be cryptographically bound into the signing process. The methods
1859 described in this section allows for a set of certificate policy statements
1860 to be listed as part of the signing certificate attribute.
1862 5.1. Attack Descriptions
1864 At least three different attacks can be launched against a possible
1865 signature verification process by replacing the certificate or certficates
1866 used in the signature verification process.
1868 5.1.1 Substitution Attack Description
1870 The first attack deals with simple substitution of one certificate for
1871 another certificate. In this attack, the issuer and serial number in the
1872 SignerInfo is modified to refer to a new certificate. This new certificate
1873 is used during the signature verification process.
1875 The first version of this attack is a simple denial of service attack where
1876 an invalid certificate is substituted for the valid certificate. This
1877 renders the message unverifiable, as the public key in the certificate no
1878 longer matches the private key used to sign the message.
1880 The second version is a substitution of one valid certificate for the
1881 original valid certificate where the public keys in the certificates match.
1882 This allows the signature to be validated under potentially different
1883 certificate constraints than the originator of the message intended.
1885 5.1.2 Reissue of Certificate Description
1887 The second attack deals with a certificate authority (CA) re-issuing the
1888 signing certificate (or potentially one of its certificates). This attack
1889 may start becoming more frequent as Certificate Authorities reissue their
1890 own root certificates, or as certificate authorities change policies in the
1891 certificate while reissuing their root certificates. This problem also
1892 occurs when cross certificates (with potentially different restrictions)
1893 are used in the process of verifying a signature.
1895 5.1.3 Rogue Duplicate CA Description
1897 The third attack deals with a rogue entity setting up a certificate
1898 authority that attempts to duplicate the structure of an existing CA.
1899 Specifically, the rogue entity issues a new certificate with the same
1900 public keys as the signer used, but signed by the rogue entity's private
1901 key.
1903 5.2 Attack Responses
1905 This document does not attempt to solve all of the above attacks; however,
1906 a brief description of responses to each of the attacks is given in this
1907 section.
1909 5.2.1 Substitution Attack Response
1911 The denial of service attack cannot be prevented. After the certificate
1912 identifier has been modified in transit, no verification of the signature
1913 is possible. There is also no way to automatically identify the attack
1914 because it is indistinguishable from a message corruption.
1916 The substitution of a valid certificate can be responded to in two
1917 different manners. The first is to make a blanket statement that the use of
1918 the same public key in two different certificates is bad practice and has
1919 to be avoided. In practice, there is no practical way to prevent users from
1920 getting new certificates with the same public keys, and it should be
1921 assumed that they will do this. Section 5.4 provides a new attribute that
1922 can be included in the SignerInfo signed attributes. This binds the correct
1923 certificate identifier into the signature. This will convert the attack
1924 from a potentially successful one to simply a denial of service attack.
1926 5.2.2 Reissue of Certificate Response
1928 A CA should never reissue a certificate with different attributes.
1929 Certificate Authorities that do so are following poor practices and cannot
1930 be relied on. Using the hash of the certificate as the reference to the
1931 certificate prevents this attach for end-entity certificates.
1933 Preventing the attack based on reissuing of CA certificates would require a
1934 substantial change to the usage of the signingCertificate attribute
1935 presented in section 5.4. It would require that ESSCertIDs would need to be
1936 included in the attribute to represent the issuer certificates in the
1937 signer's certification path. This presents problems when the relying party
1938 is using a cross-certificate as part of its authentication process, and
1939 this certificate does not appear on the list of certificates. The problems
1940 outside of a closed PKI make the addition of this information prone to
1941 error, possibly causing the rejection of valid chains.
1943 5.2.3 Rogue Duplicate CA Response
1945 The best method of preventing this attack is to avoid trusting the rogue
1946 CA. The use of the hash to identify certificates prevents the use of
1947 end-entity certificates from the rogue authority. However the only true way
1948 to prevent this attack is to never trust the rogue CA.
1950 5.3 Related Signature Verification Context
1952 Some applications require that additional information be used as part of
1953 the signature validation process. In particular, attribute certificates and
1954 policy identifiers provide additional information about the abilities and
1955 intent of the signer. The signing certificate attribute described in
1956 Section 5.4 provides the ability to bind this context information as part
1957 of the signature.
1959 5.3.1 Attribute Certificates
1961 Some applications require that attribute certificates be validated. This
1962 validation requires that the application be able to find the correct
1963 attribute certificates to perform the verification process; however there
1964 is no list of attribute certificates in a SignerInfo object. The sender has
1965 the ability to include a set of attribute certificates in a SignedData
1966 object. The receiver has the ability to retrieve attribute certificates
1967 from a directory service. There are some circumstances where the signer may
1968 wish to limit the set of attribute certificates that may be used in
1969 verifying a signature. It is useful to be able to list the set of attribute
1970 certificates the signer wants the recipient to use in validating the
1971 signature.
1973 5.3.2 Policy Information
1975 A related aspect of the certificate binding is the issue of multiple
1976 certification paths. In some instances, the semantics of a certificate in
1977 its use with a message may depend on the Certificate Authorities and
1978 policies that apply. To address this issue, the signer may also wish to
1979 bind that context under the signature. While this could be done by either
1980 signing the complete certification path or a policy ID, only a binding for
1981 the policy ID is described here.
1983 5.4 Signing Certificate Attribute Definition
1985 The signing certificate attribute is designed to prevent the simple
1986 substitution and re-issue attacks, and to allow for a restricted set of
1987 attribute certificates to be used in verifying a signature.
1989 The definition of SigningCertificate is
1991 SigningCertificate ::= SEQUENCE {
1992 certs SEQUENCE OF ESSCertID,
1993 policies SEQUENCE OF PolicyInformation OPTIONAL
1994 }
1996 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
1997 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1998 smime(16) id-aa(2) 12 }
2000 The first certificate identified in the sequence of certificate identifiers
2001 MUST be the certificate used to verify the signature. The encoding of the
2002 ESSCertID for this certificate SHOULD include the issuerSerial field. If
2003 other constraints ensure that issuerAndSerialNumber will be present in the
2004 SignerInfo, the issuerSerial field MAY be omitted. The certificate
2005 identified is used during the signature verification process. If the hash
2006 of the certificate does not match the certificate used to verify the
2007 signature, the signature MUST be considered invalid.
2009 If more than one certificate is present in the sequence of ESSCertIDs, the
2010 certificates after the first one limit the set of authorization
2011 certificates that are used during signature validation. Authorization
2012 certificates can be either attribute certificates or normal certificates.
2013 The issuerSerial SHOULD be present in these certificates, unless the client
2014 who is validating the signature is expected to have easy access to all the
2015 certificates required for validation. If only the signing certificate is
2016 present in the sequence, there are no restrictions on the set of
2017 authorization certificates used in validating the signature.
2019 The sequence of policy information terms identifies those certificate
2020 policies that the signer asserts apply to the certificate, and under which
2021 the certificate should be relied upon. This value suggests a policy value
2022 to be used in the relying party's certification path validation.
2024 If present, the SigningCertificate attribute MUST be a signed attribute; it
2025 MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
2026 Attribute. A SignerInfo MUST NOT include multiple instances of the
2027 SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
2028 attributes to include attrValues SET OF AttributeValue. A
2029 SigningCertificate attribute MUST include only a single instance of
2030 AttributeValue. There MUST NOT be zero or multiple instances of
2031 AttributeValue present in the attrValues SET OF AttributeValue.
2033 5.4.1 Certificate Identification
2035 The best way to identify certificates is an often-discussed issue. [CERT]
2036 has imposed a restriction for SignedData objects that the issuer DN must be
2037 present in all signing certificates. The issuer/serial number pair is
2038 therefore sufficient to identify the correct signing certificate. This
2039 information is already present, as part of the SignerInfo object, and
2040 duplication of this information would be unfortunate. A hash of the entire
2041 certificate serves the same function (allowing the receiver to verify that
2042 the same certificate is being used as when the message was signed), is
2043 smaller, and permits a detection of the simple substitution attacks.
2045 Attribute certificates do not have an issuer/serial number pair represented
2046 anywhere in a SignerInfo object. When an attribute certificate is not
2047 included in the SignedData object, it becomes much more difficult to get
2048 the correct set of certificates based only on a hash of the certificate.
2049 For this reason, attribute certificates are identified by the IssuerSerial
2050 object.
2052 This document defines a certificate identifier as:
2054 ESSCertID ::= SEQUENCE {
2055 certHash Hash,
2056 issuerSerial IssuerSerial OPTIONAL
2057 }
2059 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
2061 IssuerSerial ::= SEQUENCE {
2062 issuer GeneralNames,
2063 serialNumber CertificateSerialNumber
2064 }
2066 When creating an ESSCertID, the certHash is computed over the entire DER
2067 encoded certificate including the signature. The issuerSerial would
2068 normally be present unless the value can be inferred from other
2069 information.
2071 When encoding IssuerSerial, serialNumber is the serial number that uniquely
2072 identifies the certificate. For non-attribute certificates, the issuer MUST
2073 contain only the issuer name from the certificate encoded in the
2074 directoryName choice of GeneralNames. For attribute certificates, the
2075 issuer MUST contain the issuer name field from the attribute certificate.
2077 6. Security Considerations
2079 All security considerations from [CMS] and [SMIME3] apply to applications
2080 that use procedures described in this document.
2082 As stated in Section 2.3, a recipient of a receipt request must not send
2083 back a reply if it cannot validate the signature. Similarly, if there
2084 conflicting receipt requests in a message, the recipient must not send back
2085 receipts, since an attacker may have inserted the conflicting request.
2086 Sending a signed receipt to an unvalidated sender can expose information
2087 about the recipient that it may not want to expose to unknown senders.
2089 Senders of receipts should consider encrypting the receipts to prevent a
2090 passive attacker from gleaning information in the receipts.
2092 Senders must not rely on recipients' processing software to correctly
2093 process security labels. That is, the sender cannot assume that adding a
2094 security label to a message will prevent recipients from viewing messages
2095 the sender doesn't want them to view. It is expected that there will be
2096 many S/MIME clients that will not understand security labels but will still
2097 display a labelled message to a recipient.
2099 A receiving agent that processes security labels must handle the content of
2100 the messages carefully. If the agent decides not to show the message to the
2101 intended recipient after processing the security label, the agent must take
2102 care that the recipient does not accidentally see the content at a later
2103 time. For example, if an error response sent to the originator contains the
2104 content that was hidden from the recipient, and that error response bounces
2105 back to the sender due to addressing errors, the original recipient can
2106 possibly see the content since it is unlikely that the bounce message will
2107 have the proper security labels.
2109 A man-in-the-middle attack can cause a recipient to send receipts to an
2110 attacker if that attacker has a signature that can be validated by the
2111 recipient. The attack consists of intercepting the original message and
2112 adding a mLData attribute that says that a receipt should be sent to the
2113 attacker in addition to whoever else was going to get the receipt.
2115 Mailing lists that encrypt their content may be targets for
2116 denial-of-service attacks if they do not use the mailing list management
2117 described in Section 4. Using simple RFC822 header spoofing, it is quite
2118 easy to subscribe one encrypted mailing list to another, thereby setting up
2119 an infinite loop.
2121 Mailing List Agents need to be aware that they can be used as oracles for
2122 the the adaptive chosen ciphertext attack described in [CMS]. MLAs should
2123 notify an administrator if a large number of undecryptable messages are
2124 received.
2126 When verifying a signature using certificates that come with a [CMS]
2127 message, the recipient should only verify using certificates previously
2128 known to be valid, or certificates that have come from a signed
2129 SigningCertificate attribute. Otherwise, the attacks described in Section 5
2130 can cause the receiver to possibly think a signature is valid when it is
2131 not.
2133 A. ASN.1 Module
2135 ExtendedSecurityServices
2136 { iso(1) member-body(2) us(840) rsadsi(113549)
2137 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
2139 DEFINITIONS IMPLICIT TAGS ::=
2140 BEGIN
2142 IMPORTS
2144 -- Cryptographic Message Syntax (CMS)
2145 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
2146 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
2147 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
2149 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
2150 -- 1988 Syntax
2151 PolicyInformation FROM PKIX1Implicit88 {iso(1)
2152 identified-organization(3) dod(6) internet(1) security(5)
2153 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
2155 -- X.509
2156 GeneralNames, CertificateSerialNumber FROM CertificateExtensions
2157 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
2159 -- Extended Security Services
2161 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
2162 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
2163 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
2164 -- have at least one entry. MAX indicates the upper bound is unspecified.
2165 -- Implementations are free to choose an upper bound that suits their
2166 -- environment.
2168 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
2169 -- The contents are formatted as described in [UTF8]
2171 -- Section 2.7
2173 ReceiptRequest ::= SEQUENCE {
2174 signedContentIdentifier ContentIdentifier,
2175 receiptsFrom ReceiptsFrom,
2176 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
2178 ub-receiptsTo INTEGER ::= 16
2180 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2181 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
2183 ContentIdentifier ::= OCTET STRING
2185 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2186 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
2188 ReceiptsFrom ::= CHOICE {
2189 allOrFirstTier [0] AllOrFirstTier,
2190 -- formerly "allOrNone [0]AllOrNone"
2191 receiptList [1] SEQUENCE OF GeneralNames }
2193 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
2194 allReceipts (0),
2195 firstTierRecipients (1) }
2197 -- Section 2.8
2199 Receipt ::= SEQUENCE {
2200 version ESSVersion,
2201 contentType ContentType,
2202 signedContentIdentifier ContentIdentifier,
2203 originatorSignatureValue OCTET STRING }
2205 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2206 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
2208 ESSVersion ::= INTEGER { v1(1) }
2210 -- Section 2.9
2212 ContentHints ::= SEQUENCE {
2213 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
2214 contentType ContentType }
2216 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2217 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
2219 -- Section 2.10
2221 MsgSigDigest ::= OCTET STRING
2223 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2224 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
2226 -- Section 2.11
2228 ContentReference ::= SEQUENCE {
2229 contentType ContentType,
2230 signedContentIdentifier ContentIdentifier,
2231 originatorSignatureValue OCTET STRING }
2233 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2234 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
2236 -- Section 3.2
2238 ESSSecurityLabel ::= SET {
2239 security-policy-identifier SecurityPolicyIdentifier,
2240 security-classification SecurityClassification OPTIONAL,
2241 privacy-mark ESSPrivacyMark OPTIONAL,
2242 security-categories SecurityCategories OPTIONAL }
2244 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2245 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
2247 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
2249 SecurityClassification ::= INTEGER {
2250 unmarked (0),
2251 unclassified (1),
2252 restricted (2),
2253 confidential (3),
2254 secret (4),
2255 top-secret (5) } (0..ub-integer-options)
2257 ub-integer-options INTEGER ::= 256
2259 ESSPrivacyMark ::= CHOICE {
2260 pString PrintableString (SIZE (1..ub-privacy-mark-length)),
2261 utf8String UTF8String (SIZE (1..MAX))
2262 }
2264 ub-privacy-mark-length INTEGER ::= 128
2266 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
2267 SecurityCategory
2269 ub-security-categories INTEGER ::= 64
2271 SecurityCategory ::= SEQUENCE {
2272 type [0] OBJECT IDENTIFIER,
2273 value [1] ANY DEFINED BY type -- defined by type
2274 }
2276 --Note: The aforementioned SecurityCategory syntax produces identical
2277 --hex encodings as the following SecurityCategory syntax that is
2278 --documented in the X.411 specification:
2279 --
2280 --SecurityCategory ::= SEQUENCE {
2281 -- type [0] SECURITY-CATEGORY,
2282 -- value [1] ANY DEFINED BY type }
2283 --
2284 --SECURITY-CATEGORY MACRO ::=
2285 --BEGIN
2286 --TYPE NOTATION ::= type | empty
2287 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
2288 --END
2290 -- Section 3.4
2292 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
2294 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2295 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
2297 -- Section 4.4
2299 MLExpansionHistory ::= SEQUENCE
2300 SIZE (1..ub-ml-expansion-history) OF MLData
2302 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2303 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
2305 ub-ml-expansion-history INTEGER ::= 64
2307 MLData ::= SEQUENCE {
2308 mailListIdentifier EntityIdentifier,
2309 expansionTime GeneralizedTime,
2310 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
2312 EntityIdentifier ::= CHOICE {
2313 issuerAndSerialNumber IssuerAndSerialNumber,
2314 subjectKeyIdentifier SubjectKeyIdentifier }
2316 MLReceiptPolicy ::= CHOICE {
2317 none [0] NULL,
2318 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
2319 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
2321 -- Section 5.4
2323 SigningCertificate ::= SEQUENCE {
2324 certs SEQUENCE OF ESSCertID,
2325 policies SEQUENCE OF PolicyInformation OPTIONAL
2326 }
2328 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
2329 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
2330 smime(16) id-aa(2) 12 }
2332 ESSCertID ::= SEQUENCE {
2333 certHash Hash,
2334 issuerSerial IssuerSerial OPTIONAL
2335 }
2337 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
2339 IssuerSerial ::= SEQUENCE {
2340 issuer GeneralNames,
2341 serialNumber CertificateSerialNumber
2342 }
2344 END -- of ExtendedSecurityServices
2346 B. References
2348 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
2349 Notation One (ASN.1)"
2351 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
2352 Notation One (ASN.1)"
2354 [CERT] "S/MIME Version 3 Certificate Handling", Internet Draft
2355 draft-ietf-smime-cert-xx.
2357 [CMS] "Cryptographic Message Syntax", Internet Draft
2358 draft-ietf-smime-cms-xx.
2360 [MSG] "S/MIME Version 3 Message Specification", Internet Draft
2361 draft-ietf-smime-msg-xx.
2363 [MUSTSHOULD] "Key Words for Use in RFCs to Indicate Requirement Levels",
2364 RFC 2119.
2366 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP)
2367 4.0", Specification SDN.701, Revision A, 1997-02-06.
2369 [MTSABS] "1988 International Telecommunication Union (ITU) Data
2370 Communication Networks Message Handling Systems: Message Transfer System:
2371 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
2372 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
2373 mts(3) modules(0) mts-abstract-service(1)}
2375 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315.
2377 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
2378 "S/MIME Version 2 Certificate Handling", RFC 2312.
2380 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
2382 C. Acknowledgments
2384 The first draft of this work was prepared by David Solo. John Pawling did a
2385 huge amount of very detailed revision work during the many phases of the
2386 document.
2388 Many other people have contributed hard work to this draft, including:
2389 Andrew Farrell
2390 Bancroft Scott
2391 Bengt Ackzell
2392 Bill Flanigan
2393 Blake Ramsdell
2394 Carlisle Adams
2395 Darren Harter
2396 David Kemp
2397 Denis Pinkas
2398 Jim Schaad
2399 Russ Housley
2400 Scott Hollenbeck
2401 Steve Dusse
2403 D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11
2405 1: Added wording about signing certificates (Section 5) to the
2406 introduction.
2408 1.3.4: Added the sentence at the end of the first paragraph.
2410 1.3.4: Removed the macValue description because it was removed from CMS.
2412 1.4: Second paragraph, replaced second sentence to indicate that some
2413 attributes might have to be omitted.
2415 2.1: Added paragraph at the end of this section saying that you shouldn't
2416 request that receipts be sent to people who don't have the original
2417 message.
2419 2.6: Added paragraph near beginning about accepting more than one signed
2420 receipt.
2422 2.8: Changed Version to ESSVersion and defined it as:
2424 ESSVersion ::= INTEGER { v1(1) }
2426 3: Clarified the last paragraph to indicate ranked levels.
2428 4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was
2429 not found, you sign that whole message and stop.
2431 4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]"
2433 5.1: Changed "changing" to "replacing".
2435 5.4: The paragraph beginning "The first certificate..." was changed to
2436 reflect the addition of the SKI to the SignerInfo. The paragraph beginning
2437 "If more than..." was changed to allow authorization certificates that are
2438 not attribute certificates.
2440 5.4.1: Changed "CMS" to "[CERT]" for the reference.
2442 6: Entire section is new.
2444 E. Editor's Address
2446 Paul Hoffman
2447 Internet Mail Consortium
2448 127 Segre Place
2449 Santa Cruz, CA 95060
2450 (831) 426-9827
2451 phoffman@imc.org