idnits 2.17.1
draft-ietf-smime-ess-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-24) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
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
Internet-Drafts being working documents.
** 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 1676 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 297 instances of too long lines in the document, the longest
one being 5 characters in excess of 72.
** There are 39 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 132: '...lopedData object MUST be encapsulated ...'
RFC 2119 keyword, line 153: '...request MUST be in the inside signatur...'
RFC 2119 keyword, line 185: '...yLabel attribute MUST NOT be used in a...'
RFC 2119 keyword, line 206: '...Inner or outer MUST BE authenticated...'
RFC 2119 keyword, line 219: '...present, then it MUST be included in t...'
(84 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 211 has weird spacing: '...entType eithe...'
== Line 1316 has weird spacing: '... | none inst...'
== Line 1317 has weird spacing: '... | none inst...'
== Line 1318 has weird spacing: '... | none inst...'
-- 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 (January 4, 1998) is 9607 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? 'MSP' on line 30 looks like a reference
-- Missing reference section? 'SMIME2' on line 1553 looks like a reference
-- Missing reference section? 'SMIME3' on line 1557 looks like a reference
-- Missing reference section? 'CMS' on line 1539 looks like a reference
-- Missing reference section? 'ASN1-1988' on line 1533 looks like a
reference
-- Missing reference section? 'ASN1-1994' on line 1536 looks like a
reference
-- Missing reference section? 'APPLICATION 6' on line 1410 looks like a
reference
-- Missing reference section? '0' on line 1518 looks like a reference
-- Missing reference section? '1' on line 1519 looks like a reference
-- Missing reference section? 'MTSABS' on line 1544 looks like a reference
-- Missing reference section? 'MSP4' on line 1541 looks like a reference
-- Missing reference section? 'ACP120' on line 1530 looks like a reference
-- Missing reference section? '2' on line 1520 looks like a reference
Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 15 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-01.txt Internet Mail Consortium
3 January 4, 1998
4 Expires in six months
6 Enhanced Security Services for S/MIME
8 Status of this memo
10 This document is an Internet-Draft. Internet-Drafts are working documents
11 of the Internet Engineering Task Force (IETF), its areas, and its working
12 groups. Note that other groups may also distribute working documents as
13 Internet-Drafts.
15 Internet-Drafts are draft documents valid for a maximum of six months and
16 may be updated, replaced, or obsoleted by other documents at any time. It
17 is inappropriate to use Internet-Drafts as reference material or to cite
18 them other than as "work in progress."
20 To learn the current status of any Internet-Draft, please check the
21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
23 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
24 Coast).
26 1. Introduction
28 This document describes three optional security service extensions for
29 S/MIME. These services provide functionality that is similar to the Message
30 Security Protocol [MSP], but are useful in many other environments,
31 particularly business and finance. The services are:
32 - signed receipts
33 - security labels
34 - secure mailing lists
36 The services described here are extensions to S/MIME version 2 [SMIME2] and
37 S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME
38 version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number
39 of the services require mechanisms described in Cryptographic Message
40 Syntax [CMS]. The format of the messages are described in ASN.1:1988
41 [ASN1-1988] with the modification that BMPString and UniversalString
42 types from ASN.1:1994 [ASN1-1994] are used in the descriptions.
44 This draft is being discussed on the ''ietf-smime'' mailing list. To
45 subscribe, send a message to:
46 ietf-smime-request@imc.org
47 with the single word
48 subscribe
49 in the body of the message. There is a Web site for the mailing list at
50 .
52 1.1 Triple Wrapping
54 Some of the features of each service use the concept of a "triple wrapped"
55 message. A triple wrapped message is one that has been signed, then
56 encrypted, then signed again. The signers of the inner and outer signatures
57 may be different entities or the same entity. Note that the S/MIME
58 specification does not limit the number of nested encapsulations, so there
59 may be more than three wrappings.
61 1.1.1 Purpose of Triple Wrapping
63 Not all messages need to be triple wrapped. Triple wrapping is used when a
64 message must be signed, then encrypted, and then processed by other agents
65 that have to be authenticated by the final recipient (i.e. via an outer
66 signature).
68 The inside signature is used for content integrity, non-repudiation with
69 proof of origin, and binding attributes (such as a security label) to the
70 original content. These attributes go from the originator to the recipient,
71 regardless of the number of intermediate entities such as mail list agents
72 that process the message. The authenticated attributes can be used for
73 access control to the inner body. Requests for signed receipts by the
74 originator are carried in the inside signature as well.
76 The encrypted body provides confidentiality, including confidentiality of
77 the attributes that are carried in the inside signature.
79 The outside signature provides authentication and integrity for information
80 that is processed hop-by-hop, where each hop is an intermediate entity such
81 as a mail list agent. The outer signature binds attributes (such as a
82 security label) to the encrypted body. These attributes can be used for
83 access control and routing decisions.
85 1.1.2 Steps for Triple Wrapping
87 The steps to create a triple wrapped message are:
89 1. Start with a message body, called the "original content".
91 2. Encapsulate the original content with the appropriate MIME headers. An
92 exception to this MIME encapsulation rule is that a signed receipt is not
93 put in MIME headers.
95 3. Sign the result of step 2 (the MIME headers and the original content),
96 turning it into a application/pkcs7-mime body part, and add the appropriate
97 MIME headers. The application/pkcs7-mime body part is called the "inside
98 signature".
100 4. Encrypt the result of step 3 (the MIME headers and the inside signature)
101 as a single block, turning it into another (larger) application/pkcs7-mime
102 body part, and add the appropriate MIME headers. The application/pkcs7-mime
103 body part is called the "encrypted body".
105 5. Sign the result of step 4 (the MIME headers and the encrypted body) as a
106 single block, turning it into another (even larger) application/pkcs7-mime
107 body part, and add the appropriate MIME headers. The application/pkcs7-mime
108 body part is called the "outside signature".
110 6. The result of step 5 (the MIME headers and the outside signature) is the
111 triple wrapped message.
113 1.2 Format of a Triple Wrapped Message
115 A triple wrapped message has eight layers of encapsulation. Starting from
116 the innermost layer and working outwards, the layers are:
118 Original content ("Hello, world!")
119 MIME entity
120 ContentInfo: data type
121 Inner SignedData block
122 MIME entity
123 ContentInfo: data type
124 EnvelopedData block
125 MIME entity
126 ContentInfo: data type
127 Outer SignedData block
128 MIME entity
130 Note that both the inner and outer signed blocks use the SignedData
131 construct of S/MIME. As defined in [PKCS7-1.5] and [CMS], each SignedData
132 and EnvelopedData object MUST be encapsulated by a ContentInfo SEQUENCE.
134 There is no purpose to use the multipart/signed format in inner case
135 because it is known that the recipient is known to be able to process
136 S/MIME messages (because they decrypted the middle wrapper). There may be a
137 purpose in using multipart/signed in the outer layer, but only so that a
138 non-S/MIME agent could see that the next inner layer is encrypted. However,
139 this is not of great value, since all it shows the recipient is that he or
140 she wouldn't have been able to read the message anyways.
142 1.3 Security Services and Triple Wrapping
144 The three security services described in this document are used with triple
145 wrapped messages in different ways. This section briefly describes the
146 relationship of each service with triple wrapping; the other sections of
147 the document go into greater detail.
149 1.3.1 Signed Receipts and Triple Wrapping
151 A signed receipt may be requested in any SignedData object. However, if a
152 signed receipt is requested for a triple wrapped message, the receipt
153 request MUST be in the inside signature, not in the outside signature. A
154 secure mailing list agent may change the receipt policy in the outside
155 signature of a triple wrapped message when that message is processed by the
156 mailing list.
158 Note: the signed receipts and receipt requests described in this draft
159 differ from those described in the work done by the IETF Receipt
160 Notification Working Group. The output of that Working Group, when
161 finished, is not expected to work well with triple wrapped messages as
162 described in this document.
164 1.3.2 Security Labels and Triple Wrapping
166 A security label may be included in the authenticated attributes of a
167 SignedData object. A security label attribute may be included in either the
168 inner signature, outer signature, or both.
170 The inner security label is used for access control decisions related to
171 the plaintext original content. The inner signature provides authentication
172 and cryptographically protects the original signer's security label that is
173 on the inside body. This strategy facilitates the forwarding of messages
174 because the original signer's security label is included in the SignedData
175 block which can be forwarded to a third party that can verify the inner
176 signature which will cover the inner security label. The confidentiality
177 security service can be applied to the inner security label by encrypting
178 the entire inner SignedData block within an EnvelopedData block.
180 A security label may also be included in the authenticated attributes of
181 the outer SignedData block which will include the sensitivities of the
182 encrypted message. The outer security label is used for access control and
183 routing decisions related to the encrypted message. Note that a security
184 label attribute can only be used in an authenticatedAttributes block. A
185 securityLabel attribute MUST NOT be used in an EnvelopedData or
186 unauthenticated attributes.
188 1.3.3 Secure Mailing Lists and Triple Wrapping
190 Secure mail list message processing depends on the structure of S/MIME
191 layers present in the message sent to the mail list agent. The agent never
192 changes the data that was hashed to form the inner signature, if such a
193 signature is present. If an outer signature is present, then the agent will
194 modify the data that was hashed to form that outer signature. In all cases,
195 the agent adds or updates an mlExpansionHistory attribute to document the
196 agent's processing, and ultimately adds or replaces the outer signature on
197 the message to be distributed.
199 1.3.4 Placement of Attributes
201 Certain attributes should be placed in the inner or outer SignedData
202 message; some attributes can be in either. Further, some attributes must be
203 authenticated, while authentication is optional for others. The following
204 table summarizes the recommendation of this profile.
206 Attribute Inner or outer MUST BE authenticated
207 contentHints either no
208 contentIdentifier either no
209 contentType either no
210 counterSignature either no
211 encapsulatedContentType either no
212 messageDigest either yes
213 mlExpansionHistory outer only yes
214 receiptRequest inner only yes
215 signingTime either yes
216 smimeCapabilities either yes
217 securityLabel either yes
219 If a counterSignature attribute is present, then it MUST be included in the
220 unauthenticated attributes. It MUST NOT be included in the authenticated
221 attributes.
223 Note that the inner and outer signatures are for different senders, so that
224 the same attribute in the two signatures could lead to very different
225 consequences.
227 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
228 identifier assigned to the message. EncapsulatedContentType is an attribute
229 used to carry the content type of the encapsulated content. These
230 attributes are needed in addition to the fields carried in the
231 receiptRequest attribute.
233 1.4 Object Identifiers
235 The object identifiers for many of the objects described in this draft are
236 found in the registry kept at .
237 When this draft moves to standards track within the IETF, it is intended
238 that the IANA will maintain this registry.
240 2. Signed Receipts
242 Returning a signed receipt provides to the originator proof of delivery of
243 a message, and allows the originator to demonstrate to a third party that
244 the recipient was able to verify the signature of the original message.
245 This receipt is bound to the original message through the signature;
246 consequently, this service may be requested only if a message is signed.
247 The receipt sender may optionally also encrypt a receipt to provide
248 confidentiality between the receipt sender and the receipt recipient.
250 2.1 Signed Receipt Concepts
252 The originator of a message may request a signed receipt from the message's
253 recipients. The request is indicated by adding a receiptRequest attribute
254 to the authenticatedAttributes field of the SignerInfo object for which the
255 receipt is requested. The receiving user agent software SHOULD
256 automatically create a signed receipt when requested to do so, and return
257 the receipt in accordance with mailing list expansion options, local
258 security policies, and configuration options.
260 Because receipts involve the interaction of two parties, the terminology
261 can sometimes be confusing. In this section, the "sender" is the agent that
262 sent the original message that included a request for a receipt. The
263 "receiver" is the party that received that message and generated the
264 receipt.
266 The steps in a typical transaction are:
268 1. Sender creates a signed message including a receipt request attribute
269 (Section 2.2).
271 2. Sender transmits the resulting message to the recipient or recipients.
273 3. Recipient receives message and determines if there is a valid signature
274 and receipt request in the message (Section 2.3).
276 4. Recipient creates a signed receipt (Section 2.4).
278 5. Recipient transmits the resulting signed receipt message to the sender
279 (Section 2.5).
281 6. Sender receives the message and validates that it contains a signed
282 receipt for the original message (Section 2.6). This validation relies on
283 the sender having retained either a copy of the original message or
284 information extracted from the original message.
286 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
287 syntax for the receipt is given in Section 2.8.
289 Note that an agent SHOULD remember when it has sent a receipt so that it
290 can avoid re-sending a receipt each time it processes the message.
292 2.2 Receipt Request Creation
294 Multi-layer S/MIME messages may contain multiple SignedData layers.
295 However, receipts may be requested only for the innermost SignedData layer
296 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
297 receiptRequest attribute can be included in the authenticatedAttributes of
298 a SignerInfo.
300 A ReceiptRequest attribute MUST NOT be included in the attributes of a
301 SignerInfo in a SignedData object that encapsulates a Receipt content. In
302 other words, the user agent MUST NOT request a signed receipt for a signed
303 receipt.
305 A sender requests receipts by placing a receiptRequest attribute in the
306 authenticated attributes of a signerInfo as follows:
308 1. A receiptRequest data structure is created.
310 2. The encapsulated content type is optionally noted in the
311 encapsulatedContentType field.
313 3. A signed content identifier for the message is created and assigned to
314 the signedContentIdentifier field. The signedContentIdentifier is used to
315 associate the signed receipt with the message requesting the signed
316 receipt.
318 4. The entities requested to return a signed receipt are noted in the
319 receiptsFrom field.
321 5. If receipts are to be returned to entities other than or in addition to
322 the message originator, a list of receipt recipients is assigned to the
323 receiptsTo field. The originator's name(s) MUST be included in the
324 receiptsTo list if receipt recipients in addition to the originator are
325 requested.
327 6. The completed receiptRequest attribute is placed in the
328 authenticatedAttributes field of the SignerInfo object.
330 2.2.1 Multiple Receipt Requests
332 There can be multiple SignerInfos within a SignedData object, and each
333 SignerInfo may include authenticatedAttributes. Therefore, a single
334 SignedData object may include multiple SignerInfos, each SignerInfo having
335 a receiptRequest attribute. For example, an originator can send a signed
336 message with two SignerInfos, one containing a DSS signature, the other
337 containing an RSA signature.
339 Each recipient SHOULD return only one signed receipt.
341 Not all of the SignerInfos need to include receipt requests, but in all of
342 the SignerInfos that do contain receipt requests, the receipt requests MUST
343 be identical.
345 2.2.2 Information Needed to Validate Signed Receipts
347 The sending agent MUST retain one or both of the following items to support
348 the validation of signed receipts returned by the recipients.
350 - the original signedData object requesting the signed receipt
352 - the message signature digest value used to generate the original
353 signedData signerInfo signature value and the digest value of the
354 Receipt content containing values included in the original signedData
355 object. If signed receipts are requested from multiple recipients, then
356 retaining these digest values is a performance enhancement because the
357 sending agent can reuse the saved values when verifying each returned
358 signed receipt.
360 2.3 Receipt Request Processing
362 A receiptRequest is associated only with the SignerInfo object in which the
363 receipt request attribute is directly attached. Processing software SHOULD
364 examine the authenticatedAttributes field of each of the SignerInfos for
365 which it verifies a signature in the innermost signedData object to
366 determine if a receipt is requested. This may result in the receiving agent
367 processing multiple receiptRequest attributes included in a single
368 SignedData object. Because all receiptRequest attributes in a SignedData
369 object must be identical, the receiving application fully processes (as
370 described in the following paragraphs) the first receiptRequest that it
371 encounters in a SignerInfo that it can verify, and it then ensures that all
372 other receiptRequests are identical to the first one encountered.
374 If a receiptRequest attribute is absent from the authenticated attributes,
375 then a signed receipt has not been requested from any of the message
376 recipients and MUST NOT be created. If a receiptRequest attribute is
377 present in the authenticated attributes, then a signed receipt has been
378 requested from some or all of the message recipients. Note that in some
379 cases, a receiving agent might receive two almost-identical messages, one
380 with a receipt request and the other without one. In this case, the
381 receiving agent SHOULD send a signed receipt for the message that requests
382 a signed receipt.
384 If a receiptRequest attribute is present in the authenticated attributes,
385 the following process SHOULD be used to determine if a message recipient
386 has been requested to return a signed receipt.
388 1. If an mlExpansionHistory attribute is present in the outermost
389 signedData block, do one of the following two steps, based on the absence
390 or presence of mlReceiptPolicy:
392 1.1. If an mlReceiptPolicy value is absent from the last MLData
393 element, a Mail List receipt policy has not been specified and
394 the processing software SHOULD examine the receiptRequest
395 attribute value to determine if a receipt should be created and
396 returned.
398 1.2. If an mlReceiptPolicy value is present in the last MLData
399 element, do one of the following two steps, based on the value
400 of mlReceiptPolicy:
402 1.2.1. If the mlReceiptPolicy value is none, then the
403 receipt policy of the Mail List supersedes the originator's
404 request for a signed receipt and a signed receipt MUST NOT
405 be created.
407 1.2.2. If the mlReceiptPolicy value is insteadOf or
408 inAdditionTo, the processing software SHOULD examine the
409 receiptsFrom value from the receiptRequest attribute to
410 determine if a receipt should be created and returned. If a
411 receipt is created, the insteadOf and inAdditionTo fields
412 identify entities that SHOULD be sent the receipt instead of
413 or in addition to the originator.
415 2. If the receiptsFrom value of the receiptRequest attribute is
416 allOrFirstTier,
417 do one of the following two steps based on the value of allOrFirstTier.
419 2.1. If the value of allOrFirstTier is allReceipts, then a signed
420 receipt SHOULD be created.
422 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
423 the following two steps based on the presence of an
424 mlExpansionHistory attribute:
426 2.2.1. If an mlExpansionHistory attribute is present, then
427 this recipient is not a first tier recipient and a signed
428 receipt MUST NOT be created.
430 2.2.2. If an mlExpansionHistory attribute is not present,
431 then a signed receipt SHOULD be created.
433 3. If the receiptsFrom value of the receiptRequest attribute is a
434 receiptList:
436 3.1. If receiptList contains one of the GeneralNames of the
437 recipient, then a signed receipt should be created.
439 3.2. If receiptList does not contain one of the GeneralNames of
440 the recipient, then a signed receipt MUST NOT be created.
442 A flow chart for the above steps to be executed for each signerInfo for
443 which the receiving agent verifies the signature would be:
445 0. Receipt Request attribute present?
446 YES -> 1.
447 NO -> STOP
448 1. Has mlExpansionHistory?
449 YES -> 1.1.
450 NO -> 2.
451 1.1. mlReceiptPolicy absent?
452 YES -> 2.
453 NO -> 1.2.
454 1.2. Pick based on value of mlReceiptPolicy.
455 none -> 1.2.1.
456 insteadOf or inAdditionTo -> 1.2.2.
457 1.2.1. Use ML's policy, then -> STOP
458 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
459 create it if required, send it to recipients designated by
460 mlReceiptPolicy, then -> STOP.
461 2. Is value of receiptsFrom allOrFirstTier?
462 YES -> Pick based on value of allOrFirstTier.
463 allReceipts -> 2.1.
464 firstTierRecipients -> 2.2.
465 NO -> 3.
466 2.1. Create a receipt, then -> STOP.
467 2.2. Has mlExpansionHistory?
468 YES -> 2.2.1.
469 NO -> 2.2.2.
470 2.2.1. STOP.
471 2.2.2. Create a receipt, then -> STOP.
472 3. Is receiptsFrom value of receiptRequest a receiptList?
473 YES -> 3.1.
474 NO -> STOP.
475 3.1. Does receiptList contain the recipient?
476 YES -> Create a receipt, then -> STOP.
477 NO -> 3.2.
478 3.2. STOP.
480 2.4 Signed Receipt Creation
482 A signed receipt is a signedData object encapsulating a Receipt content
483 (also called a "signedData/Receipt"). Signed receipts are created as follows:
485 1. The signature of the original signedData signerInfo that includes the
486 receiptRequest authenticated attribute MUST be successfully verified before
487 creating the signedData/Receipt.
489 1.1. The ASN.1 DER encoded content of the original signedData object is
490 digested as described in [CMS]. The resulting digest value is then
491 compared with the value of the messageDigest attribute included in the
492 authenticatedAttributes of the original signedData signerInfo. If these
493 digest values are different, then the signature verification process
494 fails and the signedData/Receipt MUST NOT be created.
496 1.2. The ASN.1 DER encoded authenticatedAttributes (including
497 messageDigest, receiptRequest and, possibly, other authenticated
498 attributes) in the original signedData signerInfo are digested as
499 described in [CMS]. The resulting digest value, called msgSigDigest, is
500 then used to verify the signature of the original signedData
501 signerInfo. If the signature verification fails, then the
502 signedData/Receipt MUST NOT be created.
504 2. A Receipt structure is created.
506 2.1. The value of the Receipt version field is set to 1.
508 2.2. The encapsulatedContentType and signedContentIdentifier
509 values are copied from the original signedData signerInfo
510 receiptRequest attribute into the corresponding fields in the
511 Receipt structure.
513 2.3. The signature value from the original signedData signerInfo
514 that includes the receiptRequest attribute is copied into the
515 originatorSignatureValue field in the Receipt structure.
517 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
519 4. D1 is digested. The resulting digest value is included as the
520 messageDigest attribute in the authenticatedAttributes of the signerInfo
521 which will eventually contain the signedData/Receipt signature value.
523 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
524 signature of the original signedData signerInfo is included as the
525 msgSigDigest attribute in the authenticatedAttributes of the signerInfo
526 which will eventually contain the signedData/Receipt signature value.
528 6. A contentType attribute including the id-ct-receipt OID MUST be created
529 and added to the authenticated attributes of the signerInfo which will
530 eventually contain the signedData/Receipt signature value.
532 7. A signingTime attribute indicating the time that the signedData/Receipt
533 is signed SHOULD be created and added to the authenticated attributes of
534 the signerInfo which will eventually contain the signedData/Receipt
535 signature value. Other attributes (except receiptRequest) may be added to
536 the authenticatedAttributes of the signerInfo.
538 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
539 and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
540 as described in CMS, Section 5.3. The resulting digest value is used to
541 calculate the signature value which is then included in the
542 signedData/Receipt signerInfo.
544 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
545 the signedData contentInfo content ANY field. The id-ct-receipt OID MUST be
546 included in the signedData contentInfo contentType. This results in a
547 single ASN.1 encoded object composed of a signedData including the Receipt
548 content. The Data content type MUST NOT be used. The Receipt content MUST
549 NOT be encapsulated in a MIME header or any other header prior to being
550 encoded as part of the signedData object.
552 10. If the signedData/Receipt is to be encrypted within an envelopedData
553 object, then an outer signedData object MUST be created that encapsulates
554 the envelopedData object, and a contentHints attribute with contentType set
555 to the id-ct-receipt OID MUST be included in the outer signedData
556 SignerInfo authenticatedAttributes. When a receiving agent process the
557 outer signedData object, the presence of the id-ct-receipt OID in the
558 contentHints contentType indicates that a signedData/Receipt is encrypted
559 within the envelopedData object encapsulated by the outer signedData.
561 2.4.1 MLExpansionHistory Attributes and Receipts
563 An MLExpansionHistory attribute MUST NOT be included in the attributes of a
564 SignerInfo in a SignedData object that encapsulates a Receipt content. This
565 is true because when a SignedData/Receipt is sent to an MLA for
566 distribution, then the MLA must always encapsulate the received
567 SignedData/Receipt in an outer SignedData in which the MLA will include the
568 MLExpansionHistory attribute. The MLA cannot change the
569 authenticatedAttributes of the received SignedData/Receipt object, so it
570 can't add the MLExpansionHistory to the SignedData/Receipt.
572 2.5 Determining the Recipients of the Signed Receipt
574 If a signed receipt was created by the process described in the sections
575 above, then the software MUST use the following process to determine to
576 whom the signed receipt should be sent.
578 1. If the receiptsTo is present in the receiptRequest attribute, then the
579 software initiates the sequence of recipients with the value(s) of
580 receiptsTo; otherwise, the software initiates the sequence of recipients
581 with the signer (that is, the originator) of the SignerInfo that includes
582 the receiptRequest attribute.
584 2. If the MlExpansionHistory attribute is present in the outer SignedData
585 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
586 then the software replaces the sequence of recipients with the value(s) of
587 insteadOf.
589 3. If the MlExpansionHistory attribute is present in the outer SignedData
590 block and the last MLData contains an MLReceiptPolicy value of
591 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
592 sequence of recipients.
594 2.6. Signed Receipt Validation
596 A signed receipt is communicated as a single ASN.1 encoded object composed
597 of a signedData object directly including a Receipt content. It is
598 identified by the presence of the id-ct-receipt OID in the contentInfo
599 contentType value of the signedData object including the Receipt content.
601 A signedData/Receipt is validated as follows:
603 1. ASN.1 decode the signedData object including the Receipt content.
605 2. Extract the encapsulatedContentType, signedContentIdentifier, and
606 originatorSignatureValue from the decoded Receipt structure to identify the
607 original signedData signerInfo that requested the signedData/Receipt.
609 3. Acquire the message signature digest value calculated by the sender to
610 generate the signature value included in the original signedData signerInfo
611 that requested the signedData/Receipt.
613 3.1. If the sender-calculated message signature digest value has been
614 saved locally by the sender, it must be located and retrieved.
616 3.2. If it has not been saved, then it must be re-calculated based on
617 the original signedData content and authenticatedAttributes as
618 described in [CMS].
620 4. The message signature digest value calculated by the sender is then
621 compared with the value of the msgSigDigest authenticatedAttribute included
622 in the signedData/Receipt signerInfo. If these digest values are identical,
623 then that proves that the message signature digest value calculated by the
624 recipient based on the received original signedData object is the same as
625 that calculated by the sender. This proves that the recipient received
626 exactly the same original signedData content and authenticatedAttributes as
627 sent by the sender because that is the only way that the recipient could
628 have calculated the same message signature digest value as calculated by the
629 sender. If the digest values are different, then the signedData/Receipt
630 signature verification process fails.
632 5. Acquire the digest value calculated by the sender for the Receipt
633 content constructed by the sender (including the encapsulatedContentType,
634 signedContentIdentifier, and signature value that were included in the
635 original signedData signerInfo that requested the signedData/Receipt).
637 5.1. If the sender-calculated Receipt content digest value has been
638 saved locally by the sender, it must be located and retrieved.
640 5.2. If it has not been saved, then it must be re-calculated. As
641 described in section 2.4 above, step 2, create a Receipt structure
642 including the encapsulatedContentType, signedContentIdentifier and
643 signature value that were included in the original signedData
644 signerInfo that requested the signed receipt. The Receipt structure is
645 then ASN.1 DER encoded to produce a data stream which is then digested
646 to produce the Receipt content digest value.
648 6. The Receipt content digest value calculated by the sender is then
649 compared with the value of the messageDigest authenticatedAttribute included
650 in the signedData/Receipt signerInfo. If these digest values are identical,
651 then that proves that the values included in the Receipt content by the
652 recipient are identical to those that were included in the original
653 signedData signerInfo that requested the signedData/Receipt. This proves
654 that the recipient received the original signedData signed by the sender,
655 because that is the only way that the recipient could have obtained the
656 original signedData signerInfo signature value for inclusion in the Receipt
657 content. If the digest values are different, then the signedData/Receipt
658 signature verification process fails.
660 7. The ASN.1 DER encoded authenticatedAttributes of the signedData/Receipt
661 signerInfo are digested as described in [CMS].
663 8. The resulting digest value is then used to verify the signature value
664 included in the signedData/Receipt signerInfo. If the signature
665 verification is successful, then that proves the integrity of the
666 signedData/receipt signerInfo authenticatedAttributes and authenticates the
667 identity of the signer of the signedData/Receipt signerInfo. Note that the
668 authenticatedAttributes include the recipient-calculated Receipt content
669 digest value (messageDigest attribute) and recipient-calculated message
670 signature digest value (msgSigDigest attribute). Therefore, the
671 aforementioned comparison of the sender-generated and recipient-generated
672 digest values combined with the successful signedData/Receipt signature
673 verification proves that the recipient received the exact original
674 signedData content and authenticatedAttributes (proven by msgSigDigest
675 attribute) that were signed by the sender of the original signedData object
676 (proven by messageDigest attribute). If the signature verification fails,
677 then the signedData/Receipt signature verification process fails.
679 The signature verification process for each signature algorithm that is
680 used in conjunction with the CMS protocol is specific to the algorithm.
681 These processes are described in documents specific to the algorithms.
683 2.7 Receipt Request Syntax
685 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
686 receiptRequest attribute only within the authenticated attributes
687 associated with a signed message.
689 ReceiptRequest ::= SEQUENCE {
690 encapsulatedContentType EncapsulatedContentType OPTIONAL,
691 signedContentIdentifier ContentIdentifier,
692 receiptsFrom ReceiptsFrom,
693 receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) OF GeneralNames OPTIONAL }
695 ub-receiptsTo INTEGER ::= 16
697 ContentIdentifier ::= OCTET STRING
699 The encapsulatedContentType field identifies the content type of the
700 original message. In BuiltinContentType, the values of 0 and 1 have been
701 deprecated and SHOULD NOT be used.
703 EncapsulatedContentType ::= CHOICE {
704 built-in BuiltinContentType,
705 external ExternalContentType,
706 externalWithSubtype ExternalContentWithSubtype }
708 BuiltinContentType ::= [APPLICATION 6] INTEGER {
709 -- APPLICATION 6 is used for binary compatibility with X.411
710 unidentified (0),
711 external (1),
712 interpersonal-messaging-1984 (2),
713 interpersonal-messaging-1988 (22),
714 edi-messaging (35),
715 voice-messaging (40)} (0..ub-built-in-content-type)
717 ub-built-in-content-type INTEGER ::= 32767
719 ExternalContentType ::= OBJECT IDENTIFIER
721 ExternalContentWithSubtype ::= SEQUENCE {
722 external ExternalContentType,
723 subtype INTEGER }
725 A signedContentIdentifier MUST be created by the message originator when
726 creating a receipt request. To ensure global uniqueness, the minimal
727 signedContentIdentifier SHOULD contain a concatenation of user-specific
728 identification information (such as a user name or public keying material
729 identification information), a GeneralizedTime string, and a random number.
731 The receiptsFrom field is used by the originator to specify the recipients
732 requested to return a signed receipt. A CHOICE is provided to allow
733 specification of:
734 - receipts from all recipients are requested
735 - receipts from first tier (recipients that did not receive the
736 message as members of a mailing list) recipients are requested
737 - receipts from a specific list of recipients are requested
739 ReceiptsFrom ::= CHOICE {
740 allOrFirstTier [0] AllOrFirstTier,
741 -- formerly "allOrNone [0]AllOrNone"
742 receiptList [1] SEQUENCE OF GeneralNames }
744 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
745 allReceipts (0),
746 firstTierRecipients (1) }
748 The receiptsTo field is used by the originator to identify the user(s) to
749 whom the identified recipient should send signed receipts. Use the field
750 only if receipts must be sent to users other than, or in addition to, the
751 originator. If the receiptsTo field is used to designate recipients in
752 addition to the originator, then the originator's name(s) MUST be included
753 in the receiptsTo list.
755 2.8 Receipt Syntax
757 Receipts are represented using a new content type, Receipt. The Receipt
758 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
759 within a SignedData message.
761 Receipt ::= SEQUENCE {
762 version Version, -- Version is imported from [CMS]
763 encapsulatedContentType EncapsulatedContentType OPTIONAL,
764 signedContentIdentifier ContentIdentifier,
765 originatorSignatureValue OCTET STRING }
767 The version field defines the syntax version number, which is 1 for this
768 version of the standard.
770 The encapsulatedContentType and signedContentIdentifier fields are copied
771 from the receiptRequest attribute of the SignerInfo contained within the
772 message being receipted, and are used to link the receipt to the original
773 signed message. The originatorSignatureValue field contains the
774 signatureValue copied from the SignerInfo requesting the signed receipt.
776 2.9 Content Hints
778 Many applications find it useful to have information that describes the
779 innermost signed content of a multi-layer message available on the
780 outermost signature layer. The contentHints attribute provides such
781 information.
783 Content-hints attribute values have ASN.1 type contentHints.
785 ContentHints ::= SEQUENCE {
786 contentDescription DirectoryString OPTIONAL,
787 contentType OID }
789 DirectoryString ::= CHOICE {
790 teletexString TeletexString (SIZE (1..maxSize)),
791 printableString PrintableString (SIZE (1..maxSize)),
792 bmpString BMPString (SIZE (1..maxSize)),
793 universalString UniversalString (SIZE (1..maxSize)) }
795 The contentDescription field may be used to provide information that the
796 recipient may use to select protected messages for processing, such as a
797 message subject. If this field is set, then the attribute is expected to
798 appear on the signedData object enclosing an encrypted data object and not
799 on the inner signedData object.
801 Messages which contain a signed data wrapped around an encrypted data
802 object, thus masking the inner content type of the message, SHOULD include
803 a content hint attribute, except for the case of the data content type.
804 Specific message content types may either force or preclude the inclusion
805 of the content hints attribute. For example, when a signedData/Receipt is
806 encrypted within an envelopedData object, an outer signedData object MUST
807 be created that encapsulates the envelopedData object and a contentHints
808 attribute with contentType set to the id-ct-receipt OID MUST be included in
809 the outer signedData SignerInfo authenticatedAttributes.
811 3. Security Labels
813 This section describes the syntax to be used for security labels that can
814 optionally be associated with S/MIME encapsulated data. A security label is
815 a set of security information regarding the sensitivity of the content that
816 is protected by S/MIME encapsulation.
818 "Authorization" is the act of granting rights and/or privileges to users
819 permitting them access to an object. "Access control" is a means of
820 enforcing these authorizations. The sensitivity information in a security
821 label can be compared with a user's authorizations to determine if the user
822 is allowed to access the content that is protected by S/MIME encapsulation.
824 Security labels may be used for other purposes such as a source of routing
825 information. The labels are often priority based ("secret", "confidential",
826 "restricted", and so on) or role-based, describing which kind of people can
827 see the information ("patient's health-care team", "medical billing
828 agents", "unrestricted", and so on).
830 3.1 Security Label Processing Rules
832 A sending agent may include a security label attribute in the authenticated
833 attributes of a signedData object. A receiving agent examines the security
834 label on a received message and determines whether or not the recipient is
835 allowed to see the contents of the message.
837 3.1.1 Adding Security Labels
839 A sending agent that is using security labels MUST put the security label
840 attribute in the authenticatedAttributes field of a SignerInfo block. The
841 security label attribute MUST NOT be included in the unauthenticated
842 attributes. Integrity and authentication security services MUST be applied
843 to the security label, therefore it MUST be included as an authenticated
844 attribute, if used. This causes the security label attribute to be part of
845 the data that is hashed to form the SignerInfo signature value. A
846 SignerInfo block MUST NOT have more than one security label authenticated
847 attribute.
849 When there are multiple SignedData blocks applied to a message, a security
850 label attribute may be included in either the inner signature, outer
851 signature, or both. A security label authenticated attribute may be
852 included in a authenticatedAttributes field within the inner SignedData
853 block. The inner security label will include the sensitivities of the
854 original content and will be used for access control decisions related to
855 the plaintext encapsulated content. The inner signature provides
856 authentication of the inner security label and cryptographically protects
857 the original signer's inner security label of the original content.
859 When the originator signs the plaintext content and authenticated
860 attributes, the inner security label is bound to the plaintext content. An
861 intermediate entity cannot change the inner security label without
862 invalidating the inner signature. The confidentiality security service can
863 be applied to the inner security label by encrypting the entire inner
864 signedData object within an EnvelopedData block.
866 A security label authenticated attribute may also be included in a
867 authenticatedAttributes field within the outer SignedData block. The outer
868 security label will include the sensitivities of the encrypted message and
869 will be used for access control decisions related to the encrypted message
870 and for routing decisions. The outer signature provides authentication of
871 the outer security label (as well as for the encapsulated content which may
872 include nested S/MIME messages).
874 There can be multiple SignerInfos within a SignedData object, and each
875 SignerInfo may include authenticatedAttributes. Therefore, a single
876 SignedData object may include multiple security labels, each SignerInfo
877 having a securityLabel attribute. For example, an originator can send a
878 signed message with two SignerInfos, one containing a DSS signature, the
879 other containing an RSA signature. Not all of the SignerInfos need to
880 include security labels, but in all of the SignerInfos that do contain
881 security labels, the security labels MUST be identical.
883 A recipient SHOULD process a securityLabel attribute only if the recipient
884 can verify the signature of the SignerInfo which covers the securityLabel
885 attribute. A recipient SHOULD NOT use a security label that the recipient
886 cannot authenticate.
888 3.1.2 Processing Security Labels
890 A receiving agent that processes security labels MUST process the
891 securityLabel attribute, if present, in each SignerInfo in the SignedData
892 object for which it verifies the signature. This may result in the
893 receiving agent processing multiple security labels included in a single
894 SignedData object. Because all security labels in a SignedData object must
895 be identical, the receiving application processes (such as performing
896 access control) on the first securityLabel that it encounters in a
897 SignerInfo that it can verify, and then ensures that all other
898 securityLabels are identical to the first one encountered.
900 A receiving agent that processes security labels SHOULD have a local policy
901 about whether or not to show the inner content of an incoming messages that
902 has a security label with a security policy identifier that the processing
903 software does not recognize. If the receiving agent does not recognize the
904 securityLabel security-policy-identifier value, it SHOULD stop processing
905 the message and indicate an error.
907 3.2 Syntax of securityLabel
909 The securityLabel syntax is copied directly from [MTSABS] ASN.1 module.
910 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
911 ::=".) Further, the securityLabel syntax is identical to that used in
912 [MSP4] and [ACP120].
914 SecurityLabel ::= SET {
915 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
916 security-classification SecurityClassification OPTIONAL,
917 privacy-mark PrivacyMark OPTIONAL,
918 security-categories SecurityCategories OPTIONAL }
920 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
922 SecurityClassification ::= INTEGER {
923 unmarked (0),
924 unclassified (1),
925 restricted (2),
926 confidential (3),
927 secret (4),
928 top-secret (5) } (0..ub-integer-options)
930 ub-integer-options INTEGER ::= 256
932 PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length))
934 ub-privacy-mark-length INTEGER ::= 128
936 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
937 SecurityCategory
939 ub-security-categories INTEGER ::= 64
941 SecurityCategory ::= SEQUENCE {
942 type [0] OBJECT IDENTIFIER,
943 value [1] ANY -- defined by type
944 }
946 --Note: The aforementioned SecurityCategory syntax produces identical
947 --hex encodings as the following SecurityCategory syntax that is
948 --documented in the X.411 specification:
949 --
950 --SecurityCategory ::= SEQUENCE {
951 -- type [0] SECURITY-CATEGORY,
952 -- value [1] ANY DEFINED BY type }
953 --
954 --SECURITY-CATEGORY MACRO ::=
955 --BEGIN
956 --TYPE NOTATION ::= type | empty
957 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
958 --END
960 3.3 Security Label Components
962 This section gives more detail on the the various components of the
963 securityLabel syntax.
965 3.3.1 Security Policy Identifier
967 A security policy is a set of criteria for the provision of security
968 services. The securityLabel security-policy-identifier is used to identify
969 the security policy in force to which the security label relates. It
970 indicates the semantics of the other security label components. Even though
971 the securityLabel security-policy-identifier is an optional field, all
972 security labels used with S/MIME messages MUST include the
973 security-policy-identifier.
975 3.3.2 Security Classification
977 This specification defines the use of the Security Classification field
978 exactly as is specified in the X.411 Recommendation, which states in part:
980 If present, a security-classification may have one of a hierarchical
981 list of values. The basic security-classification hierarchy is defined
982 in this Recommendation, but the use of these values is defined by the
983 security-policy in force. Additional values of security-classification,
984 and their position in the hierarchy, may also be defined by a
985 security-policy as a local matter or by bilateral agreement. The basic
986 security-classification hierarchy is, in ascending order: unmarked,
987 unclassified, restricted, confidential, secret, top-secret.
989 This means that the security policy in force (identified by the
990 securityLabel security-policy-identifier) defines the
991 SecurityClassification integer values and their meanings.
993 An organization can develop its own security policy that defines the
994 SecurityClassification INTEGER values and their meanings. However, the
995 general interpretation of the X.411 specification is that the values of 0
996 thru 5 are reserved for the "basic hierarchy" values of unmarked,
997 unclassified, restricted, confidential, secret, and top-secret. Note that
998 X.411 does not provide the rules for how these values are used to label
999 data and how access control is performed using these values.
1001 There is no universal definition of the rules for using these "basic
1002 hierarchy" values. Each organization (or group of organizations) will
1003 define a security policy which documents how the "basic hierarchy" values
1004 are used (if at all) and how access control is enforced (if at all) within
1005 their domain.
1007 Therefore, the security-classification value MUST be accompanied by a
1008 security-policy-identifier value to define the rules for its use. For
1009 example, a company's "secret" classification may convey a different meaning
1010 than the US Government "secret" classification. In summary, a security
1011 policy SHOULD NOT use integers 0 through 5 for other than their X.411
1012 meanings, and SHOULD instead use other values in a hierarchical fashion.
1014 Note that the set of valid security-classification values MUST be
1015 hierarchical, but these values do not necessarily need to be in ascending
1016 numerical order. Further, the values do not need to be contiguous.
1018 For example, in the Defense Message System 1.0 security policy, the
1019 security-classification value of 11 indicates Sensitive-But-Unclassified
1020 and 5 indicates top-secret. The hierarchy of sensistivity ranks top-secret
1021 as more sensitive than Sensitive-But-Unclassified even though the numerical
1022 value of top-secret is less than Sensitive-But-Unclassified.
1024 (Of course, if security-classification values are both hierarchical and in
1025 ascending order, a casual reader of the security policy is more likely to
1026 understand it.)
1028 An example of a security policy that does not use any of the X.411 values
1029 might be:
1030 10 -- anyone
1031 15 -- Morgan Corporation and its contractors
1032 20 -- Morgan Corporation employees
1033 25 -- Morgan Corporation board of directors
1035 An example of a security policy that uses part of the X.411 hierarchy might
1036 be:
1037 0 -- unmarked
1038 1 -- unclassified, can be read by everyone
1039 2 -- restricted to Timberwolf Productions staff
1040 6 -- can only be read to Timberwolf Productions executives
1042 3.3.3 Privacy Mark
1044 If present, the securityLabel privacy-mark is not used for access control.
1045 The content of the securityLabel privacy-mark may be defined by the
1046 security policy in force (identified by the securityLabel
1047 security-policy-identifier) which may define a list of values to be used.
1048 Alternately, the value may be determined by the originator of the
1049 security-label.
1051 3.3.4 Security Categories
1053 If present, the securityLabel security-categories provide further
1054 granularity for the sensitivity of the message. The security policy in
1055 force (identified by the securityLabel security-policy-identifier) is used
1056 to indicate the syntaxes that are allowed to be present in the
1057 securityLabel security-categories. Alternately, the security-categories and
1058 their values may be defined by bilateral agreement.
1060 4. Mail List Management
1062 Sending agents must create recipient-specific data structures for each
1063 recipient of an encrypted message. This process can impair performance for
1064 messages sent to a large number of recipients. Thus, Mail List Agents
1065 (MLAs) that can take a single message and perform the recipient-specific
1066 encryption for every recipient are often desired.
1068 An MLA appears to the message originator as a normal message recipient, but
1069 the MLA acts as a message expansion point for a Mail List (ML). The sender
1070 of a message directs the message to the MLA, which then redistributes the
1071 message to the members of the ML. This process offloads the per-recipient
1072 processing from individual user agents and allows for more efficient
1073 management of large MLs. MLs are true message recipients served by MLAs
1074 that provide cryptographic and expansion services for the mailing list.
1076 In addition to cryptographic handling of messages, secure mailing lists
1077 also have to prevent mail loops. A mail loop is where one mailing list is a
1078 member of a second mailing list, and the second mailing list is a member of
1079 the first. A message will go from one list to the other in a
1080 rapidly-cascading sucession of mail that will be distributed to all other
1081 members of boths lists.
1083 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
1084 outer signature of a triple wrapped message. The mlExpansionHistory
1085 attribute is essentially a list of every MLA that has processed the
1086 message. If an MLA sees its own unique entity identifier in the list, it
1087 knows that a loop has been formed, and does not send the message to the
1088 list again.
1090 4.1 Mail List Expansion
1092 Mail list expansion processing is noted in the value of the
1093 mlExpansionHistory attribute, located in the authenticated attributes of
1094 the MLA's SignerInfo block. The MLA creates or updates the authenticated
1095 mlExpansionHistory attribute value each time the MLA expands and signs a
1096 message for members of a mail list.
1098 The MLA MUST add an MLData record containing the MLA's identification
1099 information, date and time of expansion, and optional receipt policy to the
1100 end of the mail list expansion history sequence. If the mlExpansionHistory
1101 attribute is absent, then the MLA MUST add the attribute and the current
1102 expansion becomes the first element of the sequence. If the
1103 mlExpansionHistory attribute is present, then the MLA MUST add the current
1104 expansion information to the end of the existing MLExpansionHistory
1105 sequence. Only one mlExpansionHistory attribute can be included in the
1106 authenticatedAttributes of a SignerInfo.
1108 Note that if the mlExpansionHistory attribute is absent, then the recipient
1109 is a first tier message recipient.
1111 There can be multiple SignerInfos within a SignedData object, and each
1112 SignerInfo may include authenticatedAttributes. Therefore, a single
1113 SignedData object may include multiple SignerInfos, each SignerInfo having
1114 a mlExpansionHistory attribute. For example, an originator can send a
1115 signed message with two SignerInfos, one containing a DSS signature, the
1116 other containing an RSA signature. Not all of the SignerInfos need to
1117 include mlExpansionHistory attributes, but in all of the SignerInfos that
1118 do conatin mlExpansionHistory attributes, the mlExpansionHistory attributes
1119 MUST be identical.
1121 A recipient SHOULD only process an mlExpansionHistory attribute if the
1122 recipient can verify the signature of the SignerInfo which covers the
1123 attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
1124 the recipient cannot authenticate.
1126 When receiving a message that includes an outer SignedData object, a
1127 receiving agent that processes mlExpansionHistory attributes MUST process
1128 the mlExpansionHistory attribute, if present, in each SignerInfo in the
1129 SignedData object for which it verifies the signature. This may result in
1130 the receiving agent processing multiple mlExpansionHistory attributes
1131 included in a single SignedData object. Because all mlExpansionHistory
1132 attributes must be identical, the receiving application processes the first
1133 mlExpansionHistory attribute that it encounters in a SignerInfo that it can
1134 verify, and then ensures that all other mlExpansionHistory attributes are
1135 identical to the first one encountered.
1137 4.1.1 Detecting Mail List Expansion Loops
1139 Prior to expanding a message, the MLA examines the value of any existing
1140 mail list expansion history attribute to detect an expansion loop. An
1141 expansion loop exists when a message expanded by a specific MLA for a
1142 specific mail list is redelivered to the same MLA for the same mail list.
1144 Expansion loops are detected by examining the mailListIdentifier field of
1145 each MLData entry found in the mail list expansion history. If an MLA finds
1146 its own identification information, then the MLA must discontinue expansion
1147 processing and should provide warning of an expansion loop to a human mail
1148 list administrator. The mail list administrator is responsible for
1149 correcting the loop condition.
1151 4.2 Mail List Agent Processing
1153 MLA message processing depends on the structure of S/MIME layers found in
1154 the processed message. In all cases, the MLA ultimately signs the message
1155 and adds or updates an mlExpansionHistory attribute to document MLA
1156 processing. In all cases, the MLA may need to perform access control before
1157 distributing the message to mail list members if the message contains a
1158 SignedData block and an associated securityLabel attribute. If a
1159 securityLabel authenticated attribute is used for access control, then the
1160 signature of the signerInfo block including the securityLabel authenticated
1161 attribute MUST be verified before using the security label. The MLA should
1162 continue parsing the MIME-encapsulated message to determine if there is a
1163 security label associated with an encapsulated SignedData object. This may
1164 include decrypting an EnvelopedData object to determine if an encapsulated
1165 SignedData object includes a securityLabel attribute.
1167 Each MLA that processes the message creates its own mlExpansionHistory and
1168 adds it to the sequence of mlExpansionHistory attributes already in the
1169 message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA
1170 that previously processed the message. Each MLA copies the sequence of
1171 mlExpansionHistory attributes created by the MLAs that previously processed
1172 the message into the newly constructed expanded message, and adds its own
1173 mlExpansionHistory as the last element of the sequence. Section 4.3
1174 provides more details regarding adding information to an existing
1175 mLExpansionHistory attribute.
1177 The processing used depends on the type of the outermost layer of the
1178 message. There are three cases for the type of the outermost data:
1179 - EnvelopedData
1180 - SignedData
1181 - data
1183 4.2.1 Processing for EnvelopedData
1185 1. The MLA locates its own RecipientInfo and uses the information it
1186 contains to obtain the message key.
1188 2. The MLA removes the existing recipientInfos field and replaces it with a
1189 new recipientInfos value built from RecipientInfo structures created for
1190 each member of the mailing list.
1192 3. The MLA encapsulates the expanded encrypted message in a SignedData
1193 block, adding an mlExpansionHistory attribute as described in the "Mail
1194 List Expansion" section to document the expansion.
1196 4. The MLA signs the new message and delivers the updated message to mail
1197 list members to complete MLA processing.
1199 4.2.2 Processing for SignedData
1201 MLA processing of multi-layer messages depends on the type of data in each
1202 of the layers. Step 3 below specifies that different processing will take
1203 place depending on the type of CMS message that has been signed. That
1204 is, it needs to know the type of data at the next inner layer, which may or
1205 may not be the innermost layer.
1207 1. The MLA verifies the signature value found in the outermost SignedData
1208 layer associated with the signed data. MLA processing of the message
1209 terminates if the message signature is invalid.
1211 2. If the outermost SignedData layer includes an authenticated
1212 mlExpansionHistory attribute the MLA checks for an expansion loop as
1213 described in the "Detecting Mail List Expansion Loops" section.
1215 3. Determine the type of the data that has been signed. That is, look at
1216 the type of data on the layer just below the SignedData, which may or may
1217 not be the "innermost" layer. Based on the type of data, perform either
1218 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1219 types).
1221 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1222 processing of the encrypted message as described previously. Note that
1223 this process invalidates the signature value in the outermost
1224 SignedData layer associated with the original encrypted message.
1225 Proceed to section 3.2 with the result of the expansion.
1227 3.2. If the signed data is SignedData, or is the result of expanding an
1228 EnvelopedData block in step 3.1:
1230 3.2.1. The MLA strips the existing outermost SignedData layer after
1231 remembering the value of the mlExpansionHistory attribute in that
1232 layer, if one was there.
1234 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1235 encapsulates the expanded encrypted message in a new outermost
1236 SignedData layer. On the other hand, if the signed data is
1237 SignedData (from step 3.2), the MLA encapsulates the signed data in
1238 a new outermost SignedData layer.
1240 3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData
1241 layer created by the MLA replaces the original outermost SignedData
1242 layer.
1244 3.2.3.1. If the original outermost SignedData layer included an
1245 mlExpansionHistory attribute, the attribute's value is copied
1246 and updated with the current ML expansion information as
1247 described in the "Mail List Expansion" section.
1249 3.2.3.2. If the original outermost SignedData layer did not
1250 include an mlExpansionHistory attribute, a new attribute value
1251 is created with the current ML expansion information as
1252 described in the "Mail List Expansion" section.
1254 3.3. If the signed data is not EnvelopedData or SignedData:
1256 3.3.1. The MLA encapsulates the received signedData object in an
1257 outer SignedData object, and adds an mlExpansionHistory attribute
1258 to the outer SignedData object containing the current ML expansion
1259 information as described in the "Mail List Expansion" section.
1261 4. The MLA signs the new message and delivers the updated message to mail
1262 list members to complete MLA processing.
1264 A flow chart for the above steps would be:
1266 1. Has a valid signature?
1267 YES -> 2.
1268 NO -> STOP.
1269 2. Does outermost SignedData layer
1270 contain mlExpansionHistory?
1271 YES -> Check it, then -> 3.
1272 NO -> 3.
1273 3. Check type of data just below outermost
1274 SignedData.
1275 EnvelopedData -> 3.1.
1276 SignedData -> 3.2.
1277 all others -> 3.3.
1278 3.1. Expand the encrypted message, then -> 3.2.
1279 3.2. -> 3.2.1.
1280 3.2.1. Strip outermost SignedData layer, note value of
1281 mlExpansionHistory, then -> 3.2.2.
1282 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1283 3.2.3. Add mlExpansionHistory. Was there an old mlExpansionHistory?
1284 YES -> copy the old mlExpansionHistory values, then -> 4.
1285 NO -> create new mlExpansionHistory value, then -> 4.
1286 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
1287 attribute, then -> 4.
1288 4. Sign message, deliver it, STOP.
1290 4.2.3 Processing for data
1292 1. The MLA encapsulates the message in a SignedData layer, and adds an
1293 mlExpansionHistory attribute containing the current ML expansion
1294 information as described in the "Mail List Expansion" section.
1296 2. The MLA signs the new message and delivers the updated message to mail
1297 list members to complete MLA processing.
1299 4.3 Mail List Agent Recipt Policy Processing
1301 If a mailing list (B) is a member of another mailing list (A), list B often
1302 needs to propagate forward the mailing list receipt policy of A. As a
1303 general rule, a mailing list should be conservative in propagating forward
1304 the mailing list receipt policy because the ultimate recipient need only
1305 process the last item in the ML expansion history. The MLA builds the
1306 expansion history to meet this requirement.
1308 The following table describes the outcome of the union of mailing list A's
1309 policy (the rows in the table) and mailing list B's policy (the columns in
1310 the table).
1312 | B's policy
1313 A's policy | none insteadOf inAdditionTo missing
1314 -------------------------------------------------------------------------
1315 none | none none none none
1316 insteadOf | none insteadOf(B) insteadOf(A+B) insteadOf(A)
1317 inAdditionTo | none insteadOf(B) inAdditionTo(A+B) inAditionTo(A)
1318 missing | none insteadOf(B) inAddtionTo(B) missing
1320 The interesting cases are combining insteadOf with inAddtionTo. The rest of
1321 the cases either substitute in B's policy or propagate forward A's policy.
1323 4.4 Mail List Expansion History Syntax
1325 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1326 there are more than ub-ml-expansion-hsitory mailing lists in the sequence,
1327 the processing agent should return an error.
1329 MLExpansionHistory ::= SEQUENCE
1330 (SIZE (1..ub-ml-expansion-history)) OF MLData
1332 ub-ml-expansion-history INTEGER ::= 64
1334 MLData contains the expansion history describing each MLA that has
1335 processed a message. As an MLA distributes a message to members of an ML,
1336 the MLA records its unique identifier, date and time of expansion, and
1337 receipt policy in an MLData structure.
1339 MLData ::= SEQUENCE {
1340 mailListIdentifier EntityIdentifier,
1341 -- EntityIdentifier is imported from [CMS]
1342 expansionTime GeneralizedTime,
1343 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1345 The receipt policy of the ML can withdraw the originator's request for
1346 the return of a signed receipt. However, if the originator of the
1347 message has not requested a signed receipt, the MLA cannot request a
1348 signed receipt.
1350 When present, the mlReceiptPolicy specifies a receipt policy that
1351 supersedes the originator's request for signed receipts. The policy
1352 can be one of three possibilities: receipts MUST NOT be returned
1353 (none); receipts should be returned to an alternate list of
1354 recipients, instead of to the originator (insteadOf); or receipts
1355 should be returned to a list of recipients in addition to the
1356 originator (inAdditionTo).
1358 MLReceiptPolicy ::= CHOICE {
1359 none [0] NULL,
1360 insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) OF GeneralNames,
1361 inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo)) OF GeneralNames }
1363 ub-insteadOf INTEGER ::= 16
1365 ub-inAdditionTo INTEGER ::= 16
1367 5. Security Considerations
1369 This entire document discusses security.
1371 A. ASN.1 Module
1373 ExtendedSecurityServices
1374 { iso(1) member-body(2) us(840) rsadsi(113549)
1375 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
1377 DEFINITIONS IMPLICIT TAGS ::=
1378 BEGIN
1380 IMPORTS
1382 -- Cryptographic Message Syntax (CMS)
1383 EntityIdentifier, SubjectKeyIdentifier, Version
1384 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
1385 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
1387 -- X.509
1388 GeneralNames FROM CertificateExtensions
1389 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
1391 -- Extended Security Services
1393 -- Section 2.7
1395 ReceiptRequest ::= SEQUENCE {
1396 encapsulatedContentType EncapsulatedContentType OPTIONAL,
1397 signedContentIdentifier ContentIdentifier,
1398 receiptsFrom ReceiptsFrom,
1399 receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) OF GeneralNames OPTIONAL }
1401 ub-receiptsTo INTEGER ::= 16
1403 ContentIdentifier ::= OCTET STRING
1405 EncapsulatedContentType ::= CHOICE {
1406 built-in BuiltinContentType,
1407 external ExternalContentType,
1408 externalWithSubtype ExternalContentWithSubtype }
1410 BuiltinContentType ::= [APPLICATION 6] INTEGER {
1411 -- APPLICATION 6 is used for binary compatibility with X.411
1412 unidentified (0),
1413 external (1),
1414 interpersonal-messaging-1984 (2),
1415 interpersonal-messaging-1988 (22),
1416 edi-messaging (35),
1417 voice-messaging (40)} (0..ub-built-in-content-type)
1419 ub-built-in-content-type INTEGER ::= 32767
1421 ExternalContentType ::= OBJECT IDENTIFIER
1423 ExternalContentWithSubtype ::= SEQUENCE {
1424 external ExternalContentType,
1425 subtype INTEGER }
1427 ReceiptsFrom ::= CHOICE {
1428 allOrFirstTier [0] AllOrFirstTier,
1429 -- formerly "allOrNone [0]AllOrNone"
1430 receiptList [1] SEQUENCE OF GeneralNames }
1432 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
1433 allReceipts (0),
1434 firstTierRecipients (1) }
1436 -- Section 2.8
1438 Receipt ::= SEQUENCE {
1439 version Version, -- Version is imported from [CMS]
1440 encapsulatedContentType EncapsulatedContentType OPTIONAL,
1441 signedContentIdentifier ContentIdentifier,
1442 originatorSignatureValue OCTET STRING }
1444 -- Section 2.9
1446 ContentHints ::= SEQUENCE {
1447 contentDescription DirectoryString OPTIONAL,
1448 contentType OID }
1450 DirectoryString ::= CHOICE {
1451 teletexString TeletexString (SIZE (1..maxSize)),
1452 printableString PrintableString (SIZE (1..maxSize)),
1453 bmpString BMPString (SIZE (1..maxSize)),
1454 universalString UniversalString (SIZE (1..maxSize)) }
1456 -- Section 3.2
1458 SecurityLabel ::= SET {
1459 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
1460 security-classification SecurityClassification OPTIONAL,
1461 privacy-mark PrivacyMark OPTIONAL,
1462 security-categories SecurityCategories OPTIONAL }
1464 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1466 SecurityClassification ::= INTEGER {
1467 unmarked (0),
1468 unclassified (1),
1469 restricted (2),
1470 confidential (3),
1471 secret (4),
1472 top-secret (5) } (0..ub-integer-options)
1474 ub-integer-options INTEGER ::= 256
1476 PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length))
1478 ub-privacy-mark-length INTEGER ::= 128
1480 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1481 SecurityCategory
1483 ub-security-categories INTEGER ::= 64
1485 SecurityCategory ::= SEQUENCE {
1486 type [0] OBJECT IDENTIFIER,
1487 value [1] ANY -- defined by type
1488 }
1490 --Note: The aforementioned SecurityCategory syntax produces identical
1491 --hex encodings as the following SecurityCategory syntax that is
1492 --documented in the X.411 specification:
1493 --
1494 --SecurityCategory ::= SEQUENCE {
1495 -- type [0] SECURITY-CATEGORY,
1496 -- value [1] ANY DEFINED BY type }
1497 --
1498 --SECURITY-CATEGORY MACRO ::=
1499 --BEGIN
1500 --TYPE NOTATION ::= type | empty
1501 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1502 --END
1504 -- Section 4.4
1506 MLExpansionHistory ::= SEQUENCE
1507 (SIZE (1..ub-ml-expansion-history)) OF MLData
1509 ub-ml-expansion-history INTEGER ::= 64
1511 MLData ::= SEQUENCE {
1512 mailListIdentifier EntityIdentifier,
1513 -- EntityIdentifier is imported from [CMS]
1514 expansionTime GeneralizedTime,
1515 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1517 MLReceiptPolicy ::= CHOICE {
1518 none [0] NULL,
1519 insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) OF GeneralNames,
1520 inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo)) OF GeneralNames }
1522 ub-insteadOf INTEGER ::= 16
1524 ub-inAdditionTo INTEGER ::= 16
1526 END -- of ExtendedSecurityServices
1528 B. References
1530 [ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120
1531 Communication Security Protocol (CSP) Specification.
1533 [ASN1-1988] Recommendation X.208: Specification of Abstract Syntax Notation
1534 One (ASN.1)
1536 [ASN1-1994] Recommendation X.680: Specification of Abstract Syntax Notation
1537 One (ASN.1)
1539 [CMS] Cryptographic Message Syntax, Internet Draft draft-ietf-smime-cms-xx.
1541 [MSP4] Secure Data Network System (SDNS) Message Security Protocol (MSP)
1542 4.0, Specification SDN.701, Revision A, 1997-02-06.
1544 [MTSABS] 1988 International Telecommunication Union (ITU) Data
1545 Communication Networks Message Handling Systems: Message Transfer System:
1546 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
1547 Recommendation X.411; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
1548 mts(3) modules(0) mts-abstract-service(1)}
1550 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft
1551 draft-hoffman-pkcs-crypt-msg-xx.
1553 [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft
1554 draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling",
1555 Internet Draft draft-dusse-smime-cert-xx.
1557 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
1558 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
1559 Internet Draft draft-ietf-smime-cert-xx.
1561 C. Acknowledgements
1563 The first draft of this work was prepared by David Solo. John Pawling did a
1564 huge amount of very detailed revision work during the many phases of the
1565 document.
1567 Many other people have contributed hard work to this draft, including:
1568 Bengt Ackzell
1569 Blake Ramsdell
1570 Carlisle Adams
1571 Jim Schaad
1572 Phillip Griffin
1573 Russ Housley
1574 Scott Hollenbeck
1575 Steve Dusse
1577 D. Open Issues
1579 1.3.4: OIDs for contentIdentifier and encapsulatedContentType attributes
1580 are needed.
1582 2.4: An OID for msgSigDigest is needed. It will be an OCTET STRING.
1584 3.2: An OID for the securityLabel attribute is needed.
1586 E. Changes from draft-ietf-smime-ess-00 to draft-ietf-smime-ess-01
1588 Fixed typos: "recevied" and "recipinet".
1590 Reformatted a lot of the ASN.1 to conform with CMS.
1592 1: Added note about ASN.1 formatting and differences from ASN.1:1988.
1594 1.3.4: Added note that counterSignature must be in authenticated attributes
1595 if present.
1597 2: Changed first sentence to be clearer about what a return receipt in ESS
1598 means.
1600 2.1: Simplified second sentence of step 6.
1602 2.2: Made it clear that UA must not requrest a signed receipt for a signed
1603 receipt.
1605 2.2.2: Added this section to specify what a sending agent must have in
1606 order to validate signed receipts.
1608 2.3: Made it clear that an MUA should send a signed receipt when requested.
1609 Also changed allOrNone to allOrFirstTier in step 2, and removed old step
1610 2.1, and fixed the flow chart for these changes.
1612 2.4: This entire section was replaced so that the chain of digests includes
1613 more authenticated information.
1615 2.4.1: Added this section to specify that MLExpansionHistory attributes
1616 can't be wrapped around Receipt bodies.
1618 2.5: Replaced "Receipt Request" with "receiptRequest" in step 1.
1620 2.6: Replaced this entire section. Also foisted off the signature
1621 verification process on the documents for each algorithm.
1623 2.7: This section was folded into the new 2.6. Thus, old 2.8 (Receipt
1624 Request Syntax), 2.9 (Receipt Syntax), and 2.10 (Content Hints) were
1625 renumbered to be 2.7 (Receipt Request Syntax), 2.8 (Receipt Syntax), and
1626 2.9 (Content Hints).
1628 2.8 (old): Changed "receiptRequest ::= SEQUENCE" to "ReceiptRequest ::=
1629 SEQUENCE". Also, changed the first componenet of Receipts From to
1630 allOrFirstTier, and changed that definition. Also removed " - no receipts
1631 are requested" from list after defintion.
1633 2.10: (old) Added sentences about ContentHints, and changed MUST to SHOULD
1634 with an explanation and example. Also, changed "contentHints ::= SEQUENCE"
1635 to "ContentHints ::= SEQUENCE". Also changed the structure of ContentHints
1636 significantly and added more information about the new contentType.
1638 3.2: Changed "securityLabel ::= SET" to "SecurityLabel ::= SET".
1640 4.2.2: Changed "PKCS #7 message" to "CMS message". Also, in bullet 3.3.1,
1641 made it clear that the encapsulation happens as an outer signature. Also
1642 fixed step 3.3 in the flow chart.
1644 4.3: Added this entire section, and renumbered old 4.3 (Mail List Expansion
1645 History Syntax) to 4.4.
1647 A: Added this section and renumbered the other appendicies.
1649 F. Editor's Address
1651 Paul Hoffman
1652 Internet Mail Consortium
1653 127 Segre Place
1654 Santa Cruz, CA 95060
1655 (408) 426-9827
1656 phoffman@imc.org