idnits 2.17.1
draft-ietf-smime-ess-00.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-27) 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 1419 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 258 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
** There are 29 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 130: '...lopedData object MUST be encapsulated ...'
RFC 2119 keyword, line 150: '...request MUST be in the inside signatur...'
RFC 2119 keyword, line 182: '...yLabel attribute MUST NOT be used in a...'
RFC 2119 keyword, line 203: '...Inner or outer MUST BE authenticated...'
RFC 2119 keyword, line 248: '...e receiving user agent software SHOULD...'
(62 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 208 has weird spacing: '...entType eithe...'
-- 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 (November 18, 1997) is 9657 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 1247 looks like a reference
-- Missing reference section? 'SMIME3' on line 1251 looks like a reference
-- Missing reference section? 'CMS' on line 1304 looks like a reference
-- Missing reference section? 'APPLICATION 6' on line 596 looks like a
reference
-- Missing reference section? '0' on line 1216 looks like a reference
-- Missing reference section? '1' on line 1217 looks like a reference
-- Missing reference section? 'MTSABS' on line 1397 looks like a reference
-- Missing reference section? 'MSP4' on line 1235 looks like a reference
-- Missing reference section? 'ACP120' on line 1397 looks like a reference
-- Missing reference section? '2' on line 1219 looks like a reference
Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 13 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-00.txt Internet Mail Consortium
3 November 18, 1997
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].
42 This draft is being discussed on the ''ietf-smime'' mailing list. To
43 subscribe, send a message to:
44 ietf-smime-request@imc.org
45 with the single word
46 subscribe
47 in the body of the message. There is a Web site for the mailing list at
48 .
50 1.1 Triple Wrapping
52 Some of the features of each service use the concept of a "triple wrapped"
53 message. A triple wrapped message is one that has been signed, then
54 encrypted, then signed again. The signers of the inner and outer signatures
55 may be different entities or the same entity. Note that the S/MIME
56 specification does not limit the number of nested encapsulations, so there
57 may be more than three wrappings.
59 1.1.1 Purpose of Triple Wrapping
61 Not all messages need to be triple wrapped. Triple wrapping is used when a
62 signed and encrypted message must be signed, then encrypted, and then
63 processed by other agents that have to be authenticated by the final
64 recipient.
66 The inside signature is used for content integrity, non-repudiation with
67 proof of origin, and binding attributes (such as a security label) to the
68 original content. These attributes go from the originator to the recipient,
69 regardless of the number of intermediate entities such as mail list agents
70 that process the message. The authenticated attributes can be used for
71 access control to the inner body. Requests for signed receipts by the
72 originator are carried in the inside signature as well.
74 The encrypted body provides confidentiality, including confidentiality of
75 the attributes that are carried in the inside signature.
77 The outside signature provides authentication and integrity for information
78 that is processed hop-by-hop, where each hop is an intermediate entity such
79 as a mail list agent. The outer signature binds attributes (such as a
80 security label) to the encrypted body. These attributes can be used for
81 access control and routing decisions.
83 1.1.2 Steps for Triple Wrapping
85 The steps to create a triple wrapped message are:
87 1. Start with a message body, called the "original content".
89 2. Encapsulate the original content with the appropriate MIME headers. An
90 exception to this MIME encapsulation rule is that a signed receipt is not
91 put in MIME headers.
93 3. Sign the result of step 2 (the MIME headers and the original content),
94 turning it into a application/pkcs7-mime body part, and add the appropriate
95 MIME headers. The application/pkcs7-mime body part is called the "inside
96 signature".
98 4. Encrypt the result of step 3 (the MIME headers and the inside signature)
99 as a single block, turning it into another (larger) application/pkcs7-mime
100 body part, and add the appropriate MIME headers. The application/pkcs7-mime
101 body part is called the "encrypted body".
103 5. Sign the result of step 4 (the MIME headers and the encrypted body) as a
104 single block, turning it into another (even larger) application/pkcs7-mime
105 body part, and add the appropriate MIME headers. The application/pkcs7-mime
106 body part is called the "outside signature".
108 6. The result of step 5 (the MIME headers and the outside signature) is the
109 triple wrapped message.
111 1.2 Format of a Triple Wrapped Message
113 A triple wrapped message has eight layers of encapsulation. Starting from
114 the innermost layer and working outwards, the layers are:
116 Original content ("Hello, world!")
117 MIME entity
118 ContentInfo: data type
119 Inner SignedData block
120 MIME entity
121 ContentInfo: data type
122 EnvelopedData block
123 MIME entity
124 ContentInfo: data type
125 Outer SignedData block
126 MIME entity
128 Note that both the inner and outer signed blocks use the SignedData
129 construct of S/MIME. As defined in [PKCS7-1.5] and [CMS], each SignedData
130 and EnvelopedData object MUST be encapsulated by a ContentInfo SEQUENCE.
131 There is no purpose to use the multipart/signed format in inner case
132 because it is known that the recipient is known to be able to process
133 S/MIME messages (because they decrypted the middle wrapper). There may be a
134 purpose in using multipart/signed in the outer layer, but only so that a
135 non-S/MIME agent could see that the next inner layer is encrypted. However,
136 this is not of great value, since all it shows the recipient is that he or
137 she wouldn't have been able to read the message anyways.
139 1.3 Security Services and Triple Wrapping
141 The three security services described in this document are used with triple
142 wrapped messages in different ways. This section briefly describes the
143 relationship of each service with triple wrapping; the other sections of
144 the document go into greater detail.
146 1.3.1 Signed Receipts and Triple Wrapping
148 A signed receipt may be requested in any SignedData object. However, if a
149 signed receipt is requested for a triple wrapped message, the receipt
150 request MUST be in the inside signature, not in the outside signature. A
151 secure mailing list agent may change the receipt policy in the outside
152 signature of a triple wrapped message when that message is processed by the
153 mailing list.
155 Note: the signed receipts and receipt requests described in this draft
156 differ from those described in the work done by the IETF Receipt
157 Notification Working Group. The output of that Working Group, when
158 finished, is not expected to work well with triple wrapped messages as
159 described in this document.
161 1.3.2 Security Labels and Triple Wrapping
163 A security label may be included in the authenticated attributes of a
164 SignedData object. A security label attribute may be included in either the
165 inner signature, outer signature, or both.
167 The inner security label is used for access control decisions related to
168 the plaintext original content. The inner signature provides authentication
169 and cryptographically protects the original signer's security label that is
170 on the inside body. This strategy facilitates the forwarding of messages
171 because the original signer's security label is included in the SignedData
172 block which can be forwarded to a third party that can verify the inner
173 signature which will cover the inner security label. The confidentiality
174 security service can be applied to the inner security label by encrypting
175 the entire inner SignedData block within an EnvelopedData block.
177 A security label may also be included in the authenticated attributes of
178 the outer SignedData block which will include the sensitivities of the
179 encrypted message. The outer security label is used for access control and
180 routing decisions related to the encrypted message. Note that a security
181 label attribute can only be used in an authenticatedAttributes block. A
182 securityLabel attribute MUST NOT be used in an EnvelopedData or
183 unauthenticated attributes.
185 1.3.3 Secure Mailing Lists and Triple Wrapping
187 Secure mail list message processing depends on the structure of S/MIME
188 layers present in the message sent to the mail list agent. The agent never
189 changes the data that was hashed to form the inner signature, if such a
190 signature is present. If an outer signature is present, then the agent will
191 modify the data that was hashed to form that outer signature. In all cases,
192 the agent adds or updates an mlExpansionHistory attribute to document the
193 agent's processing, and ultimately adds or replaces the outer signature on
194 the message to be distributed.
196 1.3.4 Placement of Attributes
198 Certain attributes should be placed in the inner or outer SignedData
199 message; some attributes can be in either. Further, some attributes must be
200 authenticated, while authentication is optional for others. The following
201 table summarizes the recommendation of this profile.
203 Attribute Inner or outer MUST BE authenticated
204 contentHints either no
205 contentIdentifier either no
206 contentType either no
207 counterSignature either no
208 encapsulatedContentType either no
209 messageDigest either yes
210 mlExpansionHistory outer only yes
211 receiptRequest inner only yes
212 signingTime either yes
213 smimeCapabilities either yes
214 securityLabel either yes
216 Note that the inner and outer signatures are for different senders, so that
217 the same attribute in the two signatures could lead to very different
218 consequences.
220 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
221 identifier assigned to the message. EncapsulatedContentType is an attribute
222 used to carry the content type of the encapsulated content. These
223 attributes are needed in addition to the fields carried in the
224 receiptRequest attribute.
226 1.4 Object Identifiers
228 The object identifiers for many of the objects described in this draft are
229 found in the registry kept at .
230 When this draft moves to standards track within the IETF, it is intended
231 that the IANA will maintain this registry.
233 2. Signed Receipts
235 Returning a signed receipt provides proof of delivery to the originator of
236 a message and allows the originator to demonstrate to a third party that
237 the recipient received the message. This receipt is bound to the original
238 message through the signature; consequently, this service may be requested
239 only if a message is signed. The receipt sender may optionally also encrypt
240 a receipt to provide confidentiality between the receipt sender and the
241 receipt recipient.
243 2.1 Signed Receipt Concepts
245 The originator of a message may request a signed receipt from the message's
246 recipients. The request is indicated by adding a receiptRequest attribute
247 to the authenticatedAttributes field of the SignerInfo object for which the
248 receipt is requested. The receiving user agent software SHOULD
249 automatically create a signed receipt when requested to do so, and return
250 the receipt in accordance with mailing list expansion options, local
251 security policies, and configuration options.
253 Because receipts involve the interaction of two parties, the terminology
254 can sometimes be confusing. In this section, the "sender" is the agent that
255 sent the original message that included a request for a receipt. The
256 "receiver" is the party that received that message and generated the
257 receipt.
259 The steps in a typical transaction are:
261 1. Sender creates a signed message including a receipt request attribute
262 (Section 2.2).
264 2. Sender transmits the resulting message to the recipient or recipients.
266 3. Recipient receives message and determines if there is a valid signature
267 and receipt request in the message (Section 2.3).
269 4. Recipient creates a signed receipt (Section 2.4).
271 5. Recipient transmits the resulting signed receipt message to the sender
272 (Section 2.5).
274 6. Sender receives the message and validates that it contains a signed
275 receipt for the original message (Section 2.6). This validation relies on
276 the sender having kept a digest value of the original message (Section 2.7)
277 or a copy of the original message.
279 The ASN.1 syntax for the receipt request is given in Section 2.8; the ASN.1
280 syntax for the receipt is given in Section 2.9.
282 Note that an agent SHOULD remember when it has sent a receipt so that it
283 can avoid re-sending a receipt each time it processes the message.
285 2.2 Receipt Request Creation
287 Multi-layer S/MIME messages may contain multiple SignedData layers.
288 However, receipts may be requested only for the innermost SignedData layer
289 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
290 receiptRequest attribute can be included in the authenticatedAttributes of
291 a SignerInfo. A sender requests receipts by placing a receiptRequest
292 attribute in the authenticated attributes of a signerInfo as follows:
294 1. A receiptRequest data structure is created.
296 2. The encapsulated content type is optionally noted in the
297 encapsulatedContentType field.
299 3. A signed content identifier for the message is created and assigned to
300 the signedContentIdentifier field. The signedContentIdentifier is used to
301 associate the signed receipt with the message requesting the signed
302 receipt.
304 4. The entities requested to return a signed receipt are noted in the
305 receiptsFrom field.
307 5. If receipts are to be returned to entities other than or in addition to
308 the message originator, a list of receipt recipients is assigned to the
309 receiptsTo field. The originator's name(s) MUST be included in the
310 receiptsTo list if receipt recipients in addition to the originator are
311 requested.
313 6. The completed receiptRequest attribute is placed in the
314 authenticatedAttributes field of the SignerInfo object.
316 2.2.1 Multiple Receipt Requests
318 There can be multiple SignerInfos within a SignedData object, and each
319 SignerInfo may include authenticatedAttributes. Therefore, a single
320 SignedData object may include multiple SignerInfos, each SignerInfo having
321 a receiptRequest attribute. For example, an originator can send a signed
322 message with two SignerInfos, one containing a DSS signature, the other
323 containing an RSA signature.
325 Each recipient SHOULD return only one signed receipt.
327 Not all of the SignerInfos need to include receipt requests, but in all of
328 the SignerInfos that do conatin receipt requests, the receipt requests MUST
329 be identical.
331 2.3 Receipt Request Processing
333 A receiptRequest is associated only with the SignerInfo object in which the
334 receipt request attribute is directly attached. Processing software SHOULD
335 examine the authenticatedAttributes field of each of the SignerInfos for
336 which it verifies a signature in the innermost signedData object to
337 determine if a receipt is requested. This may result in the receiving agent
338 processing multiple receiptRequest attributes included in a single
339 SignedData object. Because all receiptRequest attributes in a SignedData
340 object must be identical, the receiving application fully processes (as
341 described in the following paragraphs) the first receiptRequest that it
342 encounters in a SignerInfo that it can verify, and it then ensures that all
343 other receiptRequests are identical to the first one encountered.
345 If a receiptRequest attribute is absent from the authenticated attributes,
346 then a signed receipt has not been requested from any of the message
347 recipients and MUST NOT be created. If a receiptRequest attribute is
348 present in the authenticated attributes, then a signed receipt has been
349 requested from some or all of the message recipients. Note that in some
350 cases, a receiving agent might receive two almost-identical messages, one
351 with a receipt request and the other without one. In this case, the
352 receiving agent may choose whether or not to send a receipt.
354 If a receiptRequest attribute is present in the authenticated attributes,
355 the following process SHOULD be used to determine if a message recipient
356 has been requested to return a signed receipt.
358 1. If an mlExpansionHistory attribute is present in the outermost
359 signedData block, do one of the following two steps, based on the absence
360 or presence of mlReceiptPolicy:
362 1.1. If an mlReceiptPolicy value is absent from the last MLData
363 element, a Mail List receipt policy has not been specified and
364 the processing software SHOULD examine the receiptRequest
365 attribute value to determine if a receipt should be created and
366 returned.
368 1.2. If an mlReceiptPolicy value is present in the last MLData
369 element, do one of the following two steps, based on the value
370 of mlReceiptPolicy:
372 1.2.1. If the mlReceiptPolicy value is none, then the
373 receipt policy of the Mail List supersedes the originator's
374 request for a signed receipt and a signed receipt MUST NOT
375 be created.
377 1.2.2. If the mlReceiptPolicy value is insteadOf or
378 inAdditionTo, the processing software SHOULD examine the
379 receiptsFrom value from the receiptRequest attribute to
380 determine if a receipt should be created and returned. If a
381 receipt is created, the insteadOf and inAdditionTo fields
382 identify entities that SHOULD be sent the receipt instead of
383 or in addition to the originator.
385 2. If the receiptsFrom value of the receiptRequest attribute is allOrNone,
386 do one of the following three steps based on the value of allOrNone.
388 2.1. If the value of allOrNone is noReceipt, then a signed
389 receipt MUST NOT be created.
391 2.2. If the value of allOrNone is allReceipts, then a signed
392 receipt SHOULD be created.
394 2.3. If the value of allOrNone is firstTierRecipients, do one of
395 the following two steps based on the presence of an
396 mlExpansionHistory attribute:
398 2.3.1. If an mlExpansionHistory attribute is present, then
399 this recipient is not a first tier recipient and a signed
400 receipt MUST NOT be created.
402 2.3.2. If an mlExpansionHistory attribute is not present,
403 then a signed receipt SHOULD be created.
405 3. If the receiptsFrom value of the receiptRequest attribute is a
406 receiptList:
408 3.1. If receiptList contains one of the GeneralNames of the
409 recipient, then a signed receipt should be created.
411 3.2. If receiptList does not contain one of the GeneralNames of
412 the recipient, then a signed receipt MUST NOT be created.
414 A flow chart for the above steps to be executed for each signerInfo for
415 which the receiving agent verifies the signature would be:
417 0. Receipt Request attribute present?
418 YES -> 1.
419 NO -> STOP
420 1. Has mlExpansionHistory?
421 YES -> 1.1.
422 NO -> 2.
423 1.1. mlReceiptPolicy absent?
424 YES -> examine receiptRequest, then -> 2.
425 NO -> 1.2.
426 1.2. Pick based on value of mlReceiptPolicy.
427 none -> 1.2.1.
428 insteadOf or inAdditionTo -> 1.2.2.
429 1.2.1. Use ML's policy, then -> STOP
430 1.2.2. Examine receiptsFrom for name, determine if a receipt
431 should be created, create it if required, then -> STOP.
432 2. Is value of receiptsFrom allOrNone.
433 YES -> Pick based on value of allOrNone.
434 noReceipt -> 2.1.
435 allReceipts -> 2.2.
436 firstTierRecipients -> 2.3.
437 NO -> 3.
438 2.1. STOP.
439 2.2. Create a receipt, then -> STOP.
440 2.3. Has mlExpansionHistory?
441 YES -> 2.3.1.
442 NO -> 2.3.2.
443 2.3.1. STOP.
444 2.3.2. Create a receipt, then -> STOP.
445 3. Is receiptsFrom value of receiptRequest a receiptList?
446 YES -> 3.1.
447 NO -> STOP.
448 3.1. Does receiptList contain the recipient?
449 YES -> Create a receipt, then -> STOP.
450 NO -> 3.2.
451 3.2. STOP.
453 2.4 Receipt Creation
455 A signed receipt is created as follows:
457 1. The signature of the original message is validated. A receipt MUST NOT
458 be created for a message with an invalid signature.
460 2. A Receipt structure is created.
462 2.1. The value of the version field is set to 1.
464 2.2. The encapsulatedContentType and signedContentIdentifier
465 values are copied from the SignerInfo's receiptRequest
466 attribute to the corresponding fields in the Receipt structure.
468 2.3. The signatureValue (i.e. digital signature or MAC) from the
469 original message SignerInfo structure is copied to the
470 originatorSignatureValue field in the receipt structure.
472 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
474 4. D1 is concatenated to the end of the ASN.1 encoded original message
475 content to produce a data stream, D2. The "ASN.1 encoded original message
476 content" is the data composing the SignedData contentInfo content ANY. For
477 example, if SignedData is being used to sign MIME-encapsulated data, then
478 the signedData ContentInfo content ANY field will include a Data content
479 type (i.e. OCTET STRING). In that case, the "ASN.1 encoded original message
480 content" is the DER encoded value of the Data OCTET STRING. The Data OCTET
481 STRING tag and length octets are not included in the hashing.
483 5. D2 is digested to produce a digest value, H2, for the receipt.
485 6. The Receipt structure MUST be directly included within a SignedData
486 structure using H2 as the message digest to be signed. This results in a
487 single ASN.1 encoded object composed of a SignedData including the Receipt
488 content type. The Receipt MUST NOT be encapsulated in a MIME header or any
489 other header prior to being encoded as part of the SignedData object.
491 6.1. A contentHints attribute is created and SHOULD be added to
492 the SignerInfo structure's authenticated attributes.
494 The signed message that contains the signed receipt SHOULD have a
495 signingTime attribute so that the recipient knows when the receipt was
496 created.
498 2.5 Determining the Recipients of the Signed Receipt
500 If a signed receipt was created by the process described in the sections
501 above, then the software MUST use the following process to determine to
502 whom the signed receipt should be sent.
504 1. If the receiptsTo is present in the Receipt Request attribute, then the
505 software initiates the sequence of recipients with the value(s) of
506 receiptsTo; otherwise, the software initiates the sequence of recipients
507 with the signer (that is, the originator) of the SignerInfo that includes
508 the Receipt Request attribute.
510 2. If the MlExpansionHistory attribute is present in the outer SignedData
511 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
512 then the software replaces the sequence of recipients with the value(s) of
513 insteadOf.
515 3. If the MlExpansionHistory attribute is present in the outer SignedData
516 block and the last MLData contains an MLReceiptPolicy value of
517 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
518 sequence of recipients.
520 2.6 Receipt Validation
522 A receipt is validated as follows:
524 1. The signed receipt is communicated as a single ASN.1 encoded object
525 composed of a SignedData directly including a Receipt content type. ASN.1
526 decode the signedData object including the Receipt.
528 2. Retrieve the encapsulatedContentType and signedContentIdentifier values
529 from the Receipt data structure to identify the message being receipted.
531 3. Acquire H2 based on the message identification information.
533 3.1. If H2 has been saved locally, it must be located and
534 retrieved.
536 3.2. If H2 has not been saved, the original message must be
537 located and H2 must be recreated from the original message and
538 related information as described in the "Receipt Digest Value"
539 section.
541 4. Obtain the alleged receipt signature value from the receipt's
542 signatureValue field and validate the signature using the retrieved
543 signature value and H2, the calculated hash value.
545 [More is needed here or in an appendix detailing how to do this for each
546 kind of signature.]
548 2.7 Receipt Digest Value
550 The requester of a signed receipt must retain either the message for which
551 a receipt is being requested, or a receipt digest value (hash value)
552 derived from the message for later receipt validation. Retaining the digest
553 value usually requires less local storage than retaining a message because
554 digest values typically contain fewer bytes than the messages they are
555 derived from.
557 Message content and message identity information are used to calculate a
558 receipt digest value as follows:
560 1. The encapsulated content type, signed content identifier, and encrypted
561 digest value (signature value) derived from the message content are copied
562 from the SignerInfo including the receiptRequest into a Receipt structure.
563 The Receipt structure version field is set to 1.
565 2. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1,
566 as described in the "Receipt Creation" section.
568 3. D1 is concatenated to the end of the ASN.1 encoded original message
569 content to produce a data stream, D2.
571 4. D2 is digested to produce a digest value, H2, for the receipt.
573 2.8 Receipt Request Syntax
575 A receiptRequest attribute value has ASN.1 type receiptRequest. Use the
576 receiptRequest attribute only within the authenticated attributes
577 associated with a signed message.
579 receiptRequest ::= SEQUENCE {
580 encapsulatedContentType EncapsulatedContentType OPTIONAL,
581 signedContentIdentifier ContentIdentifier,
582 receiptsFrom ReceiptsFrom,
583 receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo))
584 OF GeneralNames OPTIONAL }
585 ub-receiptsTo INTEGER ::= 16
587 The encapsulatedContentType field identifies the content type of the
588 original message. In BuiltinContentType, the values of 0 and 1 have been
589 deprecated and SHOULD NOT be used.
591 EncapsulatedContentType ::= CHOICE {
592 built-in BuiltinContentType,
593 external ExternalContentType,
594 externalWithSubtype ExternalContentWithSubtype }
596 BuiltinContentType ::= [APPLICATION 6] INTEGER {
597 unidentified (0),
598 external (1),
599 interpersonal-messaging-1984 (2),
600 interpersonal-messaging-1988 (22),
601 edi-messaging (35),
602 voice-messaging (40)} (0..ub-built-in-content-type)
603 ub-built-in-content-type INTEGER ::= 32767
605 ExternalContentType ::= OBJECT IDENTIFIER
607 ExternalContentWithSubtype ::= SEQUENCE {
608 external ExternalContentType,
609 subtype INTEGER }
611 A signedContentIdentifier MUST be created by the message originator when
612 creating a receipt request. To ensure global uniqueness, the minimal
613 signedContentIdentifier SHOULD contain a concatenation of user-specific
614 identification information (such as a user name or public keying material
615 identification information), a GeneralizedTime string, and a random number.
617 The receiptsFrom field is used by the originator to specify the recipients
618 requested to return a signed receipt. A CHOICE is provided to allow
619 specification of:
620 - no receipts are requested
621 - receipts from all recipients are requested
622 - receipts from first tier (recipients that did not receive the
623 message as members of a mailing list) recipients are requested
624 - receipts from a specific list of recipients are requested
626 ReceiptsFrom ::= CHOICE {
627 allOrNone [0] AllOrNone,
628 receiptList [1] SEQUENCE OF GeneralNames }
630 AllOrNone ::= INTEGER {
631 noReceipt (0),
632 allReceipts (1),
633 firstTierRecipients (2) }
635 The receiptsTo field is used by the originator to identify the user(s) to
636 whom the identified recipient should send signed receipts. Use the field
637 only if receipts must be sent to users other than, or in addition to, the
638 originator. If the receiptsTo field is used to designate recipients in
639 addition to the originator, then the originator's name(s) MUST be included
640 in the receiptsTo list.
642 2.9 Receipt Syntax
644 Receipts are represented using a new content type, receipt. The receipt
645 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
646 within a SignedData message.
648 Receipt := SEQUENCE {
649 version Version,
650 encapsulatedContentType EncapsulatedContentType OPTIONAL,
651 signedContentIdentifier OCTET STRING,
652 originatorSignatureValue OCTET STRING }
654 The version field defines the syntax version number, which is 1 for this
655 version of the standard.
657 The encapsulatedContentType and signedContentIdentifier fields are copied
658 from the receiptRequest attribute of the SignerInfo contained within the
659 message being receipted, and are used to link the receipt to the original
660 signed message. The originatorSignatureValue field contains the
661 signatureValue copied from the SignerInfo requesting the signed receipt.
663 2.10 Content Hints
665 Many applications find it useful to have information that describes the
666 innermost signed content of a multi-layer message available on the
667 outermost signature layer. The contentHints attribute provides such
668 information.
670 Content-hints attribute values have ASN.1 type contentHints.
672 contentHints ::= SEQUENCE {
673 contentDescription DirectoryString [ ub-conDesc } OPTIONAL,
674 receipt BOOLEAN DEFAULT FALSE }
676 ub-conDesc INTEGER ::= 128
678 DirectoryString { INTEGER : maxSize } ::= CHOICE {
679 teletexString TeletexString (SIZE (1..maxSize)),
680 printableString PrintableString (SIZE (1..maxSize)),
681 bmpString BMPString (SIZE (1..maxSize)),
682 universalString UniversalString (SIZE (1..maxSize)) }
684 Messages that contain a signed receipt MUST include this attribute with the
685 receipt value set to TRUE. The contentDescription field may be used to
686 provide information that the recipient may use to select protected messages
687 for processing, such as a message subject.
689 3. Security Labels
691 This section describes the syntax to be used for security labels that can
692 optionally be associated with S/MIME encapsulated data. A security label is
693 a set of security information regarding the sensitivity of the content that
694 is protected by S/MIME encapsulation.
696 "Authorization" is the act of granting rights and/or privileges to users
697 permitting them access to an object. "Access control" is a means of
698 enforcing these authorizations. The sensitivity information in a security
699 label can be compared with a user's authorizations to determine if the user
700 is allowed to access the content that is protected by S/MIME encapsulation.
702 Security labels may be used for other purposes such as a source of routing
703 information. The labels are often priority based ("secret", "confidential",
704 "restricted", and so on) or role-based, describing which kind of people can
705 see the information ("patient's health-care team", "medical billing
706 agents", "unrestricted", and so on).
708 3.1 Security Label Processing Rules
710 A sending agent may include a security label attribute in the authenticated
711 attributes of a signedData object. A receiving agent examines the security
712 label on a recevied message and determines whether or not the recipinet is
713 allowed to see the contents of the message.
715 3.1.1 Adding Security Labels
717 A sending agent that is using security labels MUST put the security label
718 attribute in the authenticatedAttributes field of a SignerInfo block. The
719 security label attribute MUST NOT be included in the unauthenticated
720 attributes. Integrity and authentication security services MUST be applied
721 to the security label, therefore it MUST be included as an authenticated
722 attribute, if used. This causes the security label attribute to be part of
723 the data that is hashed to form the SignerInfo signature value. A
724 SignerInfo block MUST NOT have more than one security label authenticated
725 attribute.
727 When there are multiple SignedData blocks applied to a message, a security
728 label attribute may be included in either the inner signature, outer
729 signature, or both. A security label authenticated attribute may be
730 included in a authenticatedAttributes field within the inner SignedData
731 block. The inner security label will include the sensitivities of the
732 original content and will be used for access control decisions related to
733 the plaintext encapsulated content. The inner signature provides
734 authentication of the inner security label and cryptographically protects
735 the original signer's inner security label of the original content.
737 When the originator signs the plaintext content and authenticated
738 attributes, the inner security label is bound to the plaintext content. An
739 intermediate entity cannot change the inner security label without
740 invalidating the inner signature. The confidentiality security service can
741 be applied to the inner security label by encrypting the entire inner
742 signedData object within an EnvelopedData block.
744 A security label authenticated attribute may also be included in a
745 authenticatedAttributes field within the outer SignedData block. The outer
746 security label will include the sensitivities of the encrypted message and
747 will be used for access control decisions related to the encrypted message
748 and for routing decisions. The outer signature provides authentication of
749 the outer security label (as well as for the encapsulated content which may
750 include nested S/MIME messages).
752 There can be multiple SignerInfos within a SignedData object, and each
753 SignerInfo may include authenticatedAttributes. Therefore, a single
754 SignedData object may include multiple security labels, each SignerInfo
755 having a securityLabel attribute. For example, an originator can send a
756 signed message with two SignerInfos, one containing a DSS signature, the
757 other containing an RSA signature. Not all of the SignerInfos need to
758 include security labels, but in all of the SignerInfos that do conatin
759 security labels, the security labels MUST be identical.
761 A recipient SHOULD process a securityLabel attribute only if the recipient
762 can verify the signature of the SignerInfo which covers the securityLabel
763 attribute. A recipient SHOULD NOT use a security label that the recipient
764 cannot authenticate.
766 3.1.2 Processing Security Labels
768 A receiving agent that processes security labels MUST process the
769 securityLabel attribute, if present, in each SignerInfo in the SignedData
770 object for which it verifies the signature. This may result in the
771 receiving agent processing multiple security labels included in a single
772 SignedData object. Because all security labels in a SignedData object must
773 be identical, the receiving application processes (such as performing
774 access control) on the first securityLabel that it encounters in a
775 SignerInfo that it can verify, and then ensures that all other
776 securityLabels are identical to the first one encountered.
778 A receiving agent that processes security labels SHOULD have a local policy
779 about whether or not to show the inner content of an incoming messages that
780 has a security label with a security policy identifier that the processing
781 software does not recognize. If the receiving agent does not recognize the
782 securityLabel security-policy-identifier value, it SHOULD stop processing
783 the message and indicate an error.
785 3.2 Syntax of securityLabel
787 The securityLabel syntax is copied directly from [MTSABS] ASN.1 module.
788 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
789 ::=".) Further, the securityLabel syntax is identical to that used in
790 [MSP4] and [ACP120].
792 securityLabel ::= SET {
793 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
794 security-classification SecurityClassification OPTIONAL,
795 privacy-mark PrivacyMark OPTIONAL,
796 security-categories SecurityCategories OPTIONAL }
798 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
800 SecurityClassification ::= INTEGER {
801 unmarked (0),
802 unclassified (1),
803 restricted (2),
804 confidential (3),
805 secret (4),
806 top-secret (5) } (0..ub-integer-options)
808 ub-integer-options INTEGER ::= 256
810 PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length))
812 ub-privacy-mark-length INTEGER ::= 128
814 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
815 SecurityCategory
817 ub-security-categories INTEGER ::= 64
819 SecurityCategory ::= SEQUENCE {
820 type [0] OBJECT IDENTIFIER,
821 value [1] ANY -- defined by type}
823 -Note: The aforementioned SecurityCategory syntax produces identical
824 -hex encodings as the following SecurityCategory syntax that is
825 -documented in the X.411 specification:
826 -
827 -SecurityCategory ::= SEQUENCE {
828 - type [0] SECURITY-CATEGORY,
829 - value [1] ANY DEFINED BY type }
830 -
831 -SECURITY-CATEGORY MACRO ::=
832 -BEGIN
833 -TYPE NOTATION ::= type | empty
834 -VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
835 -END
837 3.3 Security Label Components
839 This section gives more detail on the the various components of the
840 securityLabel syntax.
842 3.3.1 Security Policy Identifier
844 A security policy is a set of criteria for the provision of security
845 services. The securityLabel security-policy-identifier is used to identify
846 the security policy in force to which the security label relates. It
847 indicates the semantics of the other security label components. Even though
848 the securityLabel security-policy-identifier is an optional field, all
849 security labels used with S/MIME messages MUST include the
850 security-policy-identifier.
852 3.3.2 Security Classification
854 This specification defines the use of the Security Classification field
855 exactly as is specified in the X.411 Recommendation, which states in part:
857 If present, a security-classification may have one of a hierarchical
858 list of values. The basic security-classification hierarchy is defined
859 in this Recommendation, but the use of these values is defined by the
860 security-policy in force. Additional values of security-classification,
861 and their position in the hierarchy, may also be defined by a
862 security-policy as a local matter or by bilateral agreement. The basic
863 security-classification hierarchy is, in ascending order: unmarked,
864 unclassified, restricted, confidential, secret, top-secret.
866 This means that the security policy in force (identified by the
867 securityLabel security-policy-identifier) defines the
868 SecurityClassification integer values and their meanings.
870 An organization can develop its own security policy that defines the
871 SecurityClassification INTEGER values and their meanings. However, the
872 general interpretation of the X.411 specification is that the values of 0
873 thru 5 are reserved for the "basic hierarchy" values of unmarked,
874 unclassified, restricted, confidential, secret, and top-secret. Note that
875 X.411 does not provide the rules for how these values are used to label
876 data and how access control is performed using these values.
878 There is no universal definition of the rules for using these "basic
879 hierarchy" values. Each organization (or group of organizations) will
880 define a security policy which documents how the "basic hierarchy" values
881 are used (if at all) and how access control is enforced (if at all) within
882 their domain.
884 Therefore, the security-classification value MUST be accompanied by a
885 security-policy-identifier value to define the rules for its use. For
886 example, a company's "secret" classification may convey a different meaning
887 than the US Government "secret" classification. In summary, a security
888 policy SHOULD NOT use integers 0 through 5 for other than their X.411
889 meanings, and SHOULD instead use other values in a hierarchical fashion.
891 Note that the set of valid security-classification values MUST be
892 hierarchical, but these values do not necessarily need to be in ascending
893 numerical order. Further, the values do not need to be contiguous.
895 For example, in the Defense Message System 1.0 security policy, the
896 security-classification value of 11 indicates Sensitive-But-Unclassified
897 and 5 indicates top-secret. The hierarchy of sensistivity ranks top-secret
898 as more sensitive than Sensitive-But-Unclassified even though the numerical
899 value of top-secret is less than Sensitive-But-Unclassified.
901 (Of course, if security-classification values are both hierarchical and in
902 ascending order, a casual reader of the security policy is more likely to
903 understand it.)
905 An example of a security policy that does not use any of the X.411 values
906 might be:
907 10 -- anyone
908 15 -- Morgan Corporation and its contractors
909 20 -- Morgan Corporation employees
910 25 -- Morgan Corporation board of directors
912 An example of a security policy that uses part of the X.411 hierarchy might
913 be:
914 0 -- unmarked
915 1 -- unclassified, can be read by everyone
916 2 -- restricted to Timberwolf Productions staff
917 6 -- can only be read to Timberwolf Productions executives
919 3.3.3 Privacy Mark
921 If present, the securityLabel privacy-mark is not used for access control.
922 The content of the securityLabel privacy-mark may be defined by the
923 security policy in force (identified by the securityLabel
924 security-policy-identifier) which may define a list of values to be used.
925 Alternately, the value may be determined by the originator of the
926 security-label.
928 3.3.4 Security Categories
930 If present, the securityLabel security-categories provide further
931 granularity for the sensitivity of the message. The security policy in
932 force (identified by the securityLabel security-policy-identifier) is used
933 to indicate the syntaxes that are allowed to be present in the
934 securityLabel security-categories. Alternately, the security-categories and
935 their values may be defined by bilateral agreement.
937 4. Mail List Management
939 Sending agents must create recipient-specific data structures for each
940 recipient of an encrypted message. This process can impair performance for
941 messages sent to a large number of recipients. Thus, Mail List Agents
942 (MLAs) that can take a single message and perform the recipient-specific
943 encryption for every recipient are often desired.
945 An MLA appears to the message originator as a normal message recipient, but
946 the MLA acts as a message expansion point for a Mail List (ML). The sender
947 of a message directs the message to the MLA, which then redistributes the
948 message to the members of the ML. This process offloads the per-recipient
949 processing from individual user agents and allows for more efficient
950 management of large MLs. MLs are true message recipients served by MLAs
951 that provide cryptographic and expansion services for the mailing list.
953 In addition to cryptographic handling of messages, secure mailing lists
954 also have to prevent mail loops. A mail loop is where one mailing list is a
955 member of a second mailing list, and the second mailing list is a member of
956 the first. A message will go from one list to the other in a
957 rapidly-cascading sucession of mail that will be distributed to all other
958 members of boths lists.
960 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
961 outer signature of a triple wrapped message. The mlExpansionHistory
962 attribute is essentially a list of every MLA that has processed the
963 message. If an MLA sees its own unique entity identifier in the list, it
964 knows that a loop has been formed, and does not send the message to the
965 list again.
967 4.1 Mail List Expansion
969 Mail list expansion processing is noted in the value of the
970 mlExpansionHistory attribute, located in the authenticated attributes of
971 the MLA's SignerInfo block. The MLA creates or updates the authenticated
972 mlExpansionHistory attribute value each time the MLA expands and signs a
973 message for members of a mail list.
975 The MLA MUST add an MLData record containing the MLA's identification
976 information, date and time of expansion, and optional receipt policy to the
977 end of the mail list expansion history sequence. If the mlExpansionHistory
978 attribute is absent, then the MLA MUST add the attribute and the current
979 expansion becomes the first element of the sequence. If the
980 mlExpansionHistory attribute is present, then the MLA MUST add the current
981 expansion information to the end of the existing MLExpansionHistory
982 sequence. Only one mlExpansionHistory attribute can be included in the
983 authenticatedAttributes of a SignerInfo.
985 Note that if the mlExpansionHistory attribute is absent, then the recipient
986 is a first tier message recipient.
988 There can be multiple SignerInfos within a SignedData object, and each
989 SignerInfo may include authenticatedAttributes. Therefore, a single
990 SignedData object may include multiple SignerInfos, each SignerInfo having
991 a mlExpansionHistory attribute. For example, an originator can send a
992 signed message with two SignerInfos, one containing a DSS signature, the
993 other containing an RSA signature. Not all of the SignerInfos need to
994 include mlExpansionHistory attributes, but in all of the SignerInfos that
995 do conatin mlExpansionHistory attributes, the mlExpansionHistory attributes
996 MUST be identical.
998 A recipient SHOULD only process an mlExpansionHistory attribute if the
999 recipient can verify the signature of the SignerInfo which covers the
1000 attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
1001 the recipient cannot authenticate.
1003 When receiving a message that includes an outer SignedData object, a
1004 receiving agent that processes mlExpansionHistory attributes MUST process
1005 the mlExpansionHistory attribute, if present, in each SignerInfo in the
1006 SignedData object for which it verifies the signature. This may result in
1007 the receiving agent processing multiple mlExpansionHistory attributes
1008 included in a single SignedData object. Because all mlExpansionHistory
1009 attributes must be identical, the receiving application processes the first
1010 mlExpansionHistory attribute that it encounters in a SignerInfo that it can
1011 verify, and then ensures that all other mlExpansionHistory attributes are
1012 identical to the first one encountered.
1014 4.1.1 Detecting Mail List Expansion Loops
1016 Prior to expanding a message, the MLA examines the value of any existing
1017 mail list expansion history attribute to detect an expansion loop. An
1018 expansion loop exists when a message expanded by a specific MLA for a
1019 specific mail list is redelivered to the same MLA for the same mail list.
1021 Expansion loops are detected by examining the mailListIdentifier field of
1022 each MLData entry found in the mail list expansion history. If an MLA finds
1023 its own identification information, then the MLA must discontinue expansion
1024 processing and should provide warning of an expansion loop to a human mail
1025 list administrator. The mail list administrator is responsible for
1026 correcting the loop condition.
1028 4.2 Mail List Agent Processing
1030 MLA message processing depends on the structure of S/MIME layers found in
1031 the processed message. In all cases, the MLA ultimately signs the message
1032 and adds or updates an mlExpansionHistory attribute to document MLA
1033 processing. In all cases, the MLA may need to perform access control before
1034 distributing the message to mail list members if the message contains a
1035 SignedData block and an associated securityLabel attribute. If a
1036 securityLabel authenticated attribute is used for access control, then the
1037 signature of the signerInfo block including the securityLabel authenticated
1038 attribute MUST be verified before using the security label. The MLA should
1039 continue parsing the MIME-encapsulated message to determine if there is a
1040 security label associated with an encapsulated SignedData object. This may
1041 include decrypting an EnvelopedData object to determine if an encapsulated
1042 SignedData object includes a securityLabel attribute.
1044 Each MLA that processes the message creates its own mlExpansionHistory and
1045 adds it to the sequence of mlExpansionHistory attributes already in the
1046 message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA
1047 that previously processed the message. Each MLA copies the sequence of
1048 mlExpansionHistory attributes created by the MLAs that previously processed
1049 the message into the newly constructed expanded message, and adds its own
1050 mlExpansionHistory as the last element of the sequence.
1052 The processing used depends on the type of the outermost layer of the
1053 message. There are three cases for the type of the outermost data:
1054 - EnvelopedData
1055 - SignedData
1056 - data
1058 4.2.1 Processing for EnvelopedData
1060 1. The MLA locates its own RecipientInfo and uses the information it
1061 contains to obtain the message key.
1063 2. The MLA removes the existing recipientInfos field and replaces it with a
1064 new recipientInfos value built from RecipientInfo structures created for
1065 each member of the mailing list.
1067 3. The MLA encapsulates the expanded encrypted message in a SignedData
1068 block, adding an mlExpansionHistory attribute as described in the "Mail
1069 List Expansion" section to document the expansion.
1071 4. The MLA signs the new message and delivers the updated message to mail
1072 list members to complete MLA processing.
1074 4.2.2 Processing for SignedData
1076 MLA processing of multi-layer messages depends on the type of data in each
1077 of the layers. Step 3 below specifies that different processing will take
1078 place depending on the type of PKCS #7 message that has been signed. That
1079 is, it needs to know the type of data at the next inner layer, which may or
1080 may not be the innermost layer.
1082 1. The MLA verifies the signature value found in the outermost SignedData
1083 layer associated with the signed data. MLA processing of the message
1084 terminates if the message signature is invalid.
1086 2. If the outermost SignedData layer includes an authenticated
1087 mlExpansionHistory attribute the MLA checks for an expansion loop as
1088 described in the "Detecting Mail List Expansion Loops" section.
1090 3. Determine the type of the data that has been signed. That is, look at
1091 the type of data on the layer just below the SignedData, which may or may
1092 not be the "innermost" layer. Based on the type of data, perform either
1093 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1094 types).
1096 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1097 processing of the encrypted message as described previously. Note that
1098 this process invalidates the signature value in the outermost
1099 SignedData layer associated with the original encrypted message.
1100 Proceed to section 3.2 with the result of the expansion.
1102 3.2. If the signed data is SignedData, or is the result of expanding an
1103 EnvelopedData block in step 3.1:
1105 3.2.1. The MLA strips the existing outermost SignedData layer after
1106 remembering the value of the mlExpansionHistory attribute in that
1107 layer, if one was there.
1109 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1110 encapsulates the expanded encrypted message in a new outermost
1111 SignedData layer. On the other hand, if the signed data is
1112 SignedData (from step 3.2), the MLA encapsulates the signed data in
1113 a new outermost SignedData layer.
1115 3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData
1116 layer created by the MLA replaces the original outermost SignedData
1117 layer.
1119 3.2.3.1. If the original outermost SignedData layer included an
1120 mlExpansionHistory attribute, the attribute's value is copied
1121 and updated with the current ML expansion information as
1122 described in the "Mail List Expansion" section.
1124 3.2.3.2. If the original outermost SignedData layer did not
1125 include an mlExpansionHistory attribute, a new attribute value
1126 is created with the current ML expansion information as
1127 described in the "Mail List Expansion" section.
1129 3.3. If the signed data is not EnvelopedData or SignedData:
1131 3.3.1. The MLA encapsulates the received signedData object in an
1132 SignedData object, and adds an mlExpansionHistory attribute to the
1133 outer SignedData object containing the current ML expansion
1134 information as described in the "Mail List Expansion" section.
1136 4. The MLA signs the new message and delivers the updated message to mail
1137 list members to complete MLA processing.
1139 A flow chart for the above steps would be:
1141 1. Has a valid signature?
1142 YES -> 2.
1143 NO -> STOP.
1144 2. Does outermost SignedData layer
1145 contain mlExpansionHistory?
1146 YES -> Check it, then -> 3.
1147 NO -> 3.
1148 3. Check type of data just below outermost
1149 SignedData.
1150 EnvelopedData -> 3.1.
1151 SignedData -> 3.2.
1152 all others -> 3.3.
1153 3.1. Expand the encrypted message, then -> 3.2.
1154 3.2. -> 3.2.1.
1155 3.2.1. Strip outermost SignedData layer, note value of
1156 mlExpansionHistory, then -> 3.2.2.
1157 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1158 3.2.3. Add mlExpansionHistory. Was there an old mlExpansionHistory?
1159 YES -> copy the old mlExpansionHistory values, then -> 4.
1160 NO -> create new mlExpansionHistory value, then -> 4.
1161 3.3. Is the signed data EnvelopedData or SignedData?
1162 YES -> 4.
1163 NO -> Encapsulate in a SignedData layer and add a
1164 mlExpansionHistory attribute.
1165 4. Sign message, deliver it, STOP.
1167 4.2.3 Processing for data
1169 1. The MLA encapsulates the message in a SignedData layer, and adds an
1170 mlExpansionHistory attribute containing the current ML expansion
1171 information as described in the "Mail List Expansion" section.
1173 2. The MLA signs the new message and delivers the updated message to mail
1174 list members to complete MLA processing.
1176 4.3 Mail List Expansion History Syntax
1178 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1179 there are more than ub-ml-expansion-hsitory mailing lists in the sequence,
1180 the processing agent should return an error.
1182 MLExpansionHistory ::= SEQUENCE (SIZE (1..ub-ml-expansion-history))
1183 OF MLData
1184 ub-ml-expansion-history INTEGER ::= 64
1186 MLData contains the expansion history describing each MLA that has
1187 processed a message. As an MLA distributes a message to members of an ML,
1188 the MLA records its unique identifier, date and time of expansion, and
1189 receipt policy in an MLData structure.
1191 MLData ::= SEQUENCE {
1192 mailListIdentifier EntityIdentifier,
1193 expansionTime GeneralizedTime,
1194 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1196 EntityIdentifier ::= CHOICE {
1197 issuerAndSerialNumber IssuerAndSerialNumber, -- From PKCS #7
1198 subjectKeyIdentifier KeyIdentifier }
1200 KeyIdentifier ::= OCTET STRING
1202 The receipt policy of the ML can withdraw the originator's request for
1203 the return of a signed receipt. However, if the originator of the
1204 message has not requested a signed receipt, the MLA cannot request a
1205 signed receipt.
1207 When present, the mlReceiptPolicy specifies a receipt policy that
1208 supersedes the originator's request for signed receipts. The policy
1209 can be one of three possibilities: receipts MUST NOT be returned
1210 (none); receipts should be returned to an alternate list of
1211 recipients, instead of to the originator (insteadOf); or receipts
1212 should be returned to a list of recipients in addition to the
1213 originator (inAdditionTo).
1215 MLReceiptPolicy ::= CHOICE {
1216 none [0] NULL,
1217 insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf))
1218 OF GeneralNames,
1219 inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo))
1220 OF GeneralNames }
1221 ub-insteadOf INTEGER ::= 16
1222 ub-inAdditionTo INTEGER ::= 16
1224 5. Security Considerations
1226 This entire document discusses security.
1228 A. References
1230 [ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120
1231 Communication Security Protocol (CSP) Specification.
1233 [CMS] Cryptographic Message Syntax, Internet Draft draft-ietf-smime-cms-xx.
1235 [MSP4] Secure Data Network System (SDNS) Message Security Protocol (MSP)
1236 4.0, Specification SDN.701, Revision A, 1997-02-06.
1238 [MTSABS] 1988 International Telecommunication Union (ITU) Data
1239 Communication Networks Message Handling Systems: Message Transfer System:
1240 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
1241 Recommendation X.411; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
1242 mts(3) modules(0) mts-abstract-service(1)}
1244 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft
1245 draft-hoffman-pkcs-crypt-msg-xx.
1247 [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft
1248 draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling",
1249 Internet Draft draft-dusse-smime-cert-xx.
1251 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
1252 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
1253 Internet Draft draft-ietf-smime-cert-xx.
1255 B. Acknowledgements
1257 The first draft of this work was prepared by David Solo. John Pawling did a
1258 huge amount of very detailed revision work during the many phases of the
1259 document.
1261 Many other people have contributed hard work to this draft, including:
1262 Bengt Ackzell
1263 Blake Ramsdell
1264 Carlisle Adams
1265 Jim Schaad
1266 Phillip Griffin
1267 Russ Housley
1268 Scott Hollenbeck
1269 Steve Dusse
1271 C. Open Issues
1273 There is a desire for a single ASN.1 module that collects all the ASN.1
1274 from the whole document.
1276 There is apparently two ASN.1:1994 types (BMPString and UniversalString) in
1277 the draft, leading to invalid ASN.1.
1279 2.4: Includes hashing the authenticatedAttributes included in the
1280 SignerInfo containing the receipt signature value included in the
1281 SignedData/Receipt. Also state that a SignedData/Receipt is not allowed to
1282 include receiptRequest or MLExpansionHistory attributes.
1284 2.6: Examples are needed.
1286 3.2: An OID for the securityLabel attribute is needed.
1288 5: The security considerations section needs to be fleshed out, including
1289 discussions of what happens if receiving clients don't check things very
1290 well.
1292 D. Changes from Draft -00 to Draft -01
1294 Changed the file name of the draft from "draft-hoffman-smime-ess" to
1295 "draft-ietf-smime-ess".
1297 Made the following capitalization changes throughout:
1298 ContentHints -> contentHints
1299 ReceiptRequest -> receiptRequest
1300 SecurityLabel -> securityLabel
1302 1.1.1: removed last sentence of first paragraph.
1304 1.2: Added to the last paragraph: As defined in [PKCS7-1.5] and [CMS], each
1305 SignedData and EnvelopedData object MUST be encapsulated by a ContentInfo
1306 SEQUENCE.
1308 1.3.1: Changed "A signed receipt may be requested in any signed body part."
1309 to "...any SignedData object."
1311 1.3.2: Changed the beginning of the first sentence from "A security label
1312 in authenticated attributes may also be included in the outer SignedData
1313 block..." to "A security label may also be included in the authenticated
1314 attributes of the outer SignedData block...".
1316 1.3.3: Changed last sentence to "In all cases, the agent adds or updates an
1317 mlExpansionHistory attribute to document the agent's processing, and
1318 ultimately adds or replaces the outer signature on the message to be
1319 distributed."
1321 1.3.4: Changed "SignerInfo" to "SignedData" in the first sentence.
1323 1.3.4: Changed ContentIdentifier to contentIdentifier and
1324 EncapsulatedContentType to encapsulatedContentType to reference the
1325 to-be-defined OIDs. Also alphabatized the table and added:
1326 counterSignature either no
1327 contentType either no
1328 messageDigest either yes
1330 1.4: Added this as a new section. Also, throughout the draft, removed
1331 definitions of OIDs in this draft that are actually on the OIDs page at
1332 IMC.
1334 2.2: Added to the first paragraph: "Only one receiptRequest attribute can
1335 be included in the authenticatedAttributes of a SignerInfo." Also changed
1336 "signed message" to "SignerInfo" in the last sentence.
1338 2.2.1: This section is new and adds new functionality from the previous
1339 draft. It should be read carefully, and additional wordsmithing is
1340 encouraged.
1342 2.3: Made large additions to the first paragraph. In the first bullet,
1343 changed "outermost authenticatedAttributes block" to "outermost signedData
1344 block". Also changed the lead-in paragraph to the flow chart. Also fixed
1345 2.3.1 and 2.3.2 in the flow chart to match the text.
1347 2.4: Changed bullet 2.2 to have the values copied from the "SignerInfo's
1348 receiptRequest" instead of the "original message's receiptRequest". In
1349 bullet 2.3, changed "protectionValue" to "signatureValue".
1351 2.6: Bullet 4, changed "protectionValue" to "signatureValue".
1353 2.7: Changed the first sentence in bullet 1 to read "The encapsulated
1354 content type, signed content identifier, and encrypted digest value
1355 (signature value) derived from the message content are copied from the
1356 SignerInfo including the receiptRequest into a Receipt structure." Added
1357 the reference to the receipt creation section in bullet 3.
1359 2.8: Change the definition of signedContentIdentifier from OCTET STRING to
1360 ContentIdentifier.
1362 2.9: Replaced the last paragraph with better wording.
1364 2.10: Changed the defintion of ContentHints to include { ub-conDesc }
1366 3.1: Changed "signed message" to "signedData object" in the first
1367 paragraph.
1369 3.1.1: In the first paragraph, changed "SignedData" to "SignerInfo". In the
1370 third paragraph, changed "signed message" to "signedData object". Also
1371 added long paragraphs at the end of this section describing multiple
1372 SignerInfos and what to do with them; this is new material that should be
1373 carefully scrutinized.
1375 3.1.2: The section "Processing Security Labels" was also called 3.1.1 in
1376 the previous draft; renumbered it. Also, changed and added most of the text
1377 of the section.
1379 3.2: Added the second sentence of the first paragraph, which was moved from
1380 Appendix A. Also fixed the ub-xxx ASN.1 defintions to include INTEGER.
1382 4.1: Added to the end of the second paragraph: "Only one MLExpansionHistory
1383 attribute can be included in the authenticatedAttributes of a SignerInfo."
1384 Also added all the text starting with "There can be multiple....", which
1385 describes how to handle multiple SignerInfos and what to do with them. This
1386 is new material and should be checked carefully.
1388 4.2: In the first paragraph, changed "signedData block" to "signerInfo
1389 block" and added the last two sentences. Added definitions of
1390 EntityIdentifier and KeyIdentifier.
1392 4.2.1: Bullet 1, removed "record". Bullet 3.3.1, fixed the wording to be
1393 more accruate.
1395 4.2.3: Removed "digestedData".
1397 A: Updated the reference for [ACP120]. Moved the sentence from [MTSABS] to
1398 Section 3.2.
1400 B: Gave John Pawling more direct credit for all his hard work.
1402 E. Editor's Address
1404 Paul Hoffman
1405 Internet Mail Consortium
1406 127 Segre Place
1407 Santa Cruz, CA 95060
1408 (408) 426-9827
1409 phoffman@imc.org