idnits 2.17.1
draft-ietf-smime-ess-04.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-26) 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 1916 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 350 instances of too long lines in the document, the longest
one being 4 characters in excess of 72.
** There are 25 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 100: '...entInfo eContent MUST be absent. If th...'
RFC 2119 keyword, line 102: '...entInfo eContent MUST contain the resu...'
RFC 2119 keyword, line 124: '...contentType MUST be id-data. The Envel...'
RFC 2119 keyword, line 153: '...receiving agents MUST be able to inter...'
RFC 2119 keyword, line 234: '...request MUST be in the inside signatur...'
(104 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 1568 has weird spacing: '... | none inst...'
== Line 1570 has weird spacing: '... | none none...'
== Line 1571 has weird spacing: '... | none inst...'
== Line 1572 has weird spacing: '... | none inst...'
== Line 1573 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 (March 12, 1998) is 9542 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? 'SMIME3' on line 1818 looks like a reference
-- Missing reference section? 'SMIME2' on line 1814 looks like a reference
-- Missing reference section? 'ASN1-1988' on line 1793 looks like a
reference
-- Missing reference section? 'ESS' on line 298 looks like a reference
-- Missing reference section? 'CMS' on line 1799 looks like a reference
-- Missing reference section? 'MSG' on line 300 looks like a reference
-- Missing reference section? '0' on line 1785 looks like a reference
-- Missing reference section? '1' on line 1786 looks like a reference
-- Missing reference section? 'UTF8' on line 1822 looks like a reference
-- Missing reference section? 'MTSABS' on line 1805 looks like a reference
-- Missing reference section? 'MSP4' on line 1802 looks like a reference
-- Missing reference section? '2' on line 1787 looks like a reference
-- Missing reference section? 'ASN1-1994' on line 1796 looks like a
reference
Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 16 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-04.txt Internet Mail Consortium
3 March 12, 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 3 [SMIME3],
37 and some of them can also be added to S/MIME version 2 [SMIME2]. The
38 extensions described here will not cause an S/MIME version 3 recipient to
39 be unable to read messages from an S/MIME version 2 sender. However, some
40 of the extensions will cause messages created by an S/MIME version 3 sender
41 to be unreadable by an S/MIME version 2 recipient.
43 The format of the messages are described in ASN.1:1988 [ASN1-1988].
45 This draft is being discussed on the "ietf-smime" mailing list. To
46 subscribe, send a message to:
47 ietf-smime-request@imc.org
48 with the single word
49 subscribe
50 in the body of the message. There is a Web site for the mailing list at
51 .
53 1.1 Triple Wrapping
55 Some of the features of each service use the concept of a "triple wrapped"
56 message. A triple wrapped message is one that has been signed, then
57 encrypted, then signed again. The signers of the inner and outer signatures
58 may be different entities or the same entity. Note that the S/MIME
59 specification does not limit the number of nested encapsulations, so there
60 may be more than three wrappings.
62 1.1.1 Purpose of Triple Wrapping
64 Not all messages need to be triple wrapped. Triple wrapping is used when a
65 message must be signed, then encrypted, and then have authenticated
66 attributes bound to the encrypted body. Outer attributes may be added or
67 removed by the message originator or intermediate agents, and may be
68 authenticated by intermediate agents or the final recipient.
70 The inside signature is used for content integrity, non-repudiation with
71 proof of origin, and binding attributes (such as a security label) to the
72 original content. These attributes go from the originator to the recipient,
73 regardless of the number of intermediate entities such as mail list agents
74 that process the message. The authenticated attributes can be used for
75 access control to the inner body. Requests for signed receipts by the
76 originator are carried in the inside signature as well.
78 The encrypted body provides confidentiality, including confidentiality of
79 the attributes that are carried in the inside signature.
81 The outside signature provides authentication and integrity for information
82 that is processed hop-by-hop, where each hop is an intermediate entity such
83 as a mail list agent. The outer signature binds attributes (such as a
84 security label) to the encrypted body. These attributes can be used for
85 access control and routing decisions.
87 1.1.2 Steps for Triple Wrapping
89 The steps to create a triple wrapped message are:
91 1. Start with a message body, called the "original content".
93 2. Encapsulate the original content with the appropriate MIME Content-type
94 headers, such as "Content-type: text/plain". An exception to this MIME
95 encapsulation rule is that a signed receipt is not put in MIME headers.
97 3. Sign the result of step 2 (the inner MIME headers and the original
98 content). The SignedData encapContentInfo eContentType object identifier
99 MUST be id-data. If the structure you create in step 4 is multipart/signed,
100 then the SignedData encapContentInfo eContent MUST be absent. If the
101 structure you create in step 4 is application/pkcs7-mime, then the
102 SignedData encapContentInfo eContent MUST contain the result of step 2
103 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE
104 with a contentType of id-signedData.
106 4. Add an appropriate MIME construct to the signed message from step 3 as
107 defined in [SMIME3]. The resulting message is called the "inside
108 signature".
110 - If you are signing using multipart/signed, the MIME construct added
111 consists of a Content-type of multipart/signed with parameters, the
112 boundary, the result of step 2 above, the boundary, a Content-type of
113 application/pkcs7-signature, optional MIME headers (such as
114 Content-transfer-encoding and Content-disposition), and a body part that is
115 the result of step 3 above.
117 - If you are instead signing using application/pkcs7-mime, the MIME
118 construct added consists of a Content-type of application/pkcs7-mime with
119 parameters, optional MIME headers (such as Content-transfer-encoding and
120 Content-disposition), and the result of step 3 above.
122 5. Encrypt the result of step 4 as a single block, turning it into an
123 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
124 contentType MUST be id-data. The EnvelopedData structure is encapsulated by
125 a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
126 called the "encrypted body".
128 6. Add the appropriate MIME headers: a Content-type of
129 application/pkcs7-mime with parameters, and optional MIME headers such as
130 Content-transfer-encoding and Content-disposition.
132 7. Using the same logic as in step 3 above, sign the result of step 6 (the
133 MIME headers and the encrypted body) as a single block
135 8. Using the same logic as in step 4 above, add an appropriate MIME
136 construct to the signed message from step 7. The resulting message is
137 called the "outside signature", and is also the triple wrapped message.
139 1.2 Format of a Triple Wrapped Message
141 A triple wrapped message has many layers of encapsulation. The structure
142 differs based on the choice of format for the signed portions of the
143 message. Because of the way that MIME encapsulates data, the layers do not
144 appear in order, and the notion of "layers" becomes vague.
146 There is no need to use the multipart/signed format in an inner signature
147 because it is known that the recipient is able to process S/MIME messages
148 (because they decrypted the middle wrapper). A sending agent might choose
149 to use the multipart/signed format in the outer layer so that a non-S/MIME
150 agent could see that the next inner layer is encrypted; however, this is
151 not of great value, since all it shows the recipient is that the rest of
152 the message is unreadable. Because many sending agents always use
153 multipart/signed structures, all receiving agents MUST be able to interpret
154 either multipart/signed or application/pkcs7-mime signature structures.
156 The format of a triple wrapped message that uses multipart/signed for
157 both signatures is:
159 [step 8] Content-type: multipart/signed;
160 [step 8] protocol="application/pkcs7-signature";
161 [step 8] boundary=outerboundary
162 [step 8]
163 [step 8] --outerboundary
164 [step 6] Content-type: application/pkcs7-mime; )
165 [step 6] smime-type=enveloped-data )
166 [step 6] )
167 [step 4] Content-type: multipart/signed; | )
168 [step 4] protocol="application/pkcs7-signature"; | )
169 [step 4] boundary=innerboundary | )
170 [step 4] | )
171 [step 4] --innerboundary | )
172 [step 2] Content-type: text/plain % | )
173 [step 2] % | )
174 [step 1] Original content % | )
175 [step 4] | )
176 [step 4] --innerboundary | )
177 [step 4] Content-type: application/pkcs7-signature | )
178 [step 4] | )
179 [step 3] inner signedData block (eContent is missing) | )
180 [step 4] | )
181 [step 4] --innerboundary | )
182 [step 8]
183 [step 8] --outerboundary
184 [step 8] Content-type: application/pkcs7-signature
185 [step 8]
186 [step 7] outer signedData block
187 [step 8]
188 [step 8] --outerboundary
190 % = These lines are what the inner signature is computed over.
191 | = These lines are what is encrypted in step 5. This encrypted result
192 is opaque and is a part of an EnvelopedData block.
193 ) = These lines are what the outer signature is computed over.
195 The format of a triple wrapped message that uses application/pkcs7-mime for
196 the both signatures is:
198 [step 8] Content-type: application/pkcs7-mime;
199 [step 8] smime-type=signed-data
200 [step 8]
201 [step 7] outer SignedData block (eContent is present) O
202 [step 6] Content-type: application/pkcs7-mime; ) O
203 [step 6] smime-type=enveloped-data; ) O
204 [step 6] ) O
205 [step 4] Content-type: application/pkcs7-mime; | ) O
206 [step 4] smime-type=signed-data | ) O
207 [step 4] | ) O
208 [step 3] inner SignedData block (eContent is present) I | ) O
209 [step 2] Content-type: text/plain I | ) O
210 [step 2] I | ) O
211 [step 1] Original content I | ) O
213 I = These lines are the inner SignedData block, which is opaque and
214 contains the ASN.1 encoded result of step 2 as well as control
215 information.
216 | = These lines are what is encrypted in step 5. This encrypted result
217 is opaque and is a part of an EnvelopedData block.
218 ) = These lines are what the outer signature is computed over.
219 O = These lines are the outer SignedData block, which is opaque and
220 contains the ASN.1 encoded result of step 6 as well as control
221 information.
223 1.3 Security Services and Triple Wrapping
225 The three security services described in this document are used with triple
226 wrapped messages in different ways. This section briefly describes the
227 relationship of each service with triple wrapping; the other sections of
228 the document go into greater detail.
230 1.3.1 Signed Receipts and Triple Wrapping
232 A signed receipt may be requested in any SignedData object. However, if a
233 signed receipt is requested for a triple wrapped message, the receipt
234 request MUST be in the inside signature, not in the outside signature. A
235 secure mailing list agent may change the receipt policy in the outside
236 signature of a triple wrapped message when that message is processed by the
237 mailing list.
239 Note: the signed receipts and receipt requests described in this draft
240 differ from those described in the work done by the IETF Receipt
241 Notification Working Group. The output of that Working Group, when
242 finished, is not expected to work well with triple wrapped messages as
243 described in this document.
245 1.3.2 Security Labels and Triple Wrapping
247 A security label may be included in the authenticated attributes of any
248 SignedData object. A security label attribute may be included in either the
249 inner signature, outer signature, or both.
251 The inner security label is used for access control decisions related to
252 the plaintext original content. The inner signature provides authentication
253 and cryptographically protects the original signer's security label that is
254 on the inside body. This strategy facilitates the forwarding of messages
255 because the original signer's security label is included in the SignedData
256 block which can be forwarded to a third party that can verify the inner
257 signature which will cover the inner security label. The confidentiality
258 security service can be applied to the inner security label by encrypting
259 the entire inner SignedData block within an EnvelopedData block.
261 A security label may also be included in the authenticated attributes of
262 the outer SignedData block which will include the sensitivities of the
263 encrypted message. The outer security label is used for access control and
264 routing decisions related to the encrypted message. Note that a security
265 label attribute can only be used in an authenticatedAttributes block. An
266 eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or
267 unauthenticated attributes.
269 1.3.3 Secure Mailing Lists and Triple Wrapping
271 Secure mail list message processing depends on the structure of S/MIME
272 layers present in the message sent to the mail list agent. The agent never
273 changes the data that was hashed to form the inner signature, if such a
274 signature is present. If an outer signature is present, then the agent will
275 modify the data that was hashed to form that outer signature. In all cases,
276 the agent adds or updates an mlExpansionHistory attribute to document the
277 agent's processing, and ultimately adds or replaces the outer signature on
278 the message to be distributed.
280 1.3.4 Placement of Attributes
282 Certain attributes should be placed in the inner or outer SignedData
283 message; some attributes can be in either. Further, some attributes must be
284 authenticated, while authentication is optional for others. The following
285 table summarizes the recommendation of this profile.
287 | |Inner or |MUST be
288 Attribute |OID |outer |authenticated
289 ------------------|-----------------------------|----------|-------------
290 contentHints |id-aa-contentHint [ESS] |either |no
291 contentIdentifier |id-aa-contentIdentifier [ESS]|either |no
292 contentType |id-contentType [CMS] |either |yes
293 counterSignature |id-countersignature [CMS] |either |MUST NOT
294 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |yes
295 messageDigest |id-messageDigest [CMS] |either |yes
296 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|yes
297 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|yes
298 receiptRequest |id-aa-receiptRequest [ESS] |inner only|yes
299 signingTime |id-signingTime [CMS] |either |yes
300 smimeCapabilities |sMIMECapabilities [MSG] |either |yes
302 If a counterSignature attribute is present, then it MUST be included in the
303 unauthenticated attributes. It MUST NOT be included in the authenticated
304 attributes.
306 Note that the inner and outer signatures are for different senders, so that
307 the same attribute in the two signatures could lead to very different
308 consequences.
310 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
311 identifier assigned to the message.
313 1.4 Object Identifiers
315 The object identifiers for many of the objects described in this draft are
316 found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be
317 found in the registry kept at .
318 When this draft moves to standards track within the IETF, it is intended
319 that the IANA will maintain this registry.
321 1.5 Criticality of Attributes
323 Authenticated attributes can be marked as critical. In this specification,
324 the only attribute which MUST be marked as critical is eSSSecurityLabel.
326 Note that marking any attribute as critical will make the message
327 unreadable to S/MIME v2 recipients. Because of this, a sending agent should
328 only mark attributes critical if necessary for the agent's application, and
329 at the risk of preventing an S/MIME v2 recipient from verifying (or
330 possibly even being able to read) the message.
332 2. Signed Receipts
334 Returning a signed receipt provides to the originator proof of delivery of
335 a message, and allows the originator to demonstrate to a third party that
336 the recipient was able to verify the signature of the original message.
337 This receipt is bound to the original message through the signature;
338 consequently, this service may be requested only if a message is signed.
339 The receipt sender may optionally also encrypt a receipt to provide
340 confidentiality between the receipt sender and the receipt recipient.
342 2.1 Signed Receipt Concepts
344 The originator of a message may request a signed receipt from the message's
345 recipients. The request is indicated by adding a receiptRequest attribute
346 to the authenticatedAttributes field of the SignerInfo object for which the
347 receipt is requested. The receiving user agent software SHOULD
348 automatically create a signed receipt when requested to do so, and return
349 the receipt in accordance with mailing list expansion options, local
350 security policies, and configuration options.
352 Because receipts involve the interaction of two parties, the terminology
353 can sometimes be confusing. In this section, the "sender" is the agent that
354 sent the original message that included a request for a receipt. The
355 "receiver" is the party that received that message and generated the
356 receipt.
358 The steps in a typical transaction are:
360 1. Sender creates a signed message including a receipt request attribute
361 (Section 2.2).
363 2. Sender transmits the resulting message to the recipient or recipients.
365 3. Recipient receives message and determines if there is a valid signature
366 and receipt request in the message (Section 2.3).
368 4. Recipient creates a signed receipt (Section 2.4).
370 5. Recipient transmits the resulting signed receipt message to the sender
371 (Section 2.5).
373 6. Sender receives the message and validates that it contains a signed
374 receipt for the original message (Section 2.6). This validation relies on
375 the sender having retained either a copy of the original message or
376 information extracted from the original message.
378 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
379 syntax for the receipt is given in Section 2.8.
381 Note that an agent SHOULD remember when it has sent a receipt so that it
382 can avoid re-sending a receipt each time it processes the message.
384 2.2 Receipt Request Creation
386 Multi-layer S/MIME messages may contain multiple SignedData layers.
387 However, receipts may be requested only for the innermost SignedData layer
388 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
389 receiptRequest attribute can be included in the authenticatedAttributes of
390 a SignerInfo.
392 A ReceiptRequest attribute MUST NOT be included in the attributes of a
393 SignerInfo in a SignedData object that encapsulates a Receipt content. In
394 other words, the user agent MUST NOT request a signed receipt for a signed
395 receipt.
397 A sender requests receipts by placing a receiptRequest attribute in the
398 authenticated attributes of a signerInfo as follows:
400 1. A receiptRequest data structure is created.
402 2. A signed content identifier for the message is created and assigned to
403 the signedContentIdentifier field. The signedContentIdentifier is used to
404 associate the signed receipt with the message requesting the signed
405 receipt.
407 3. The entities requested to return a signed receipt are noted in the
408 receiptsFrom field.
410 4. The message originator MUST populate the receiptsTo field with a
411 GeneralNames for each entity to whom the recipient should send the signed
412 receipt. If the message originator wants the recipient to send the signed
413 receipt to the originator, then the originator MUST include a GeneralNames
414 for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
415 GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
416 GeneralNames represents an entity. There may be multiple GeneralName
417 instances in each GeneralNames. At a minimum, the message originator MUST
418 populate each entity's GeneralNames with the address to which the signed
419 receipt should be sent. Optionally, the message originator MAY also
420 populate each entity's GeneralNames with other GeneralName instances (such
421 as directoryName).
423 5. The completed receiptRequest attribute is placed in the
424 authenticatedAttributes field of the SignerInfo object.
426 2.2.1 Multiple Receipt Requests
428 There can be multiple SignerInfos within a SignedData object, and each
429 SignerInfo may include authenticatedAttributes. Therefore, a single
430 SignedData object may include multiple SignerInfos, each SignerInfo having
431 a receiptRequest attribute. For example, an originator can send a signed
432 message with two SignerInfos, one containing a DSS signature, the other
433 containing an RSA signature.
435 Each recipient SHOULD return only one signed receipt.
437 Not all of the SignerInfos need to include receipt requests, but in all of
438 the SignerInfos that do contain receipt requests, the receipt requests MUST
439 be identical.
441 2.2.2 Information Needed to Validate Signed Receipts
443 The sending agent MUST retain one or both of the following items to support
444 the validation of signed receipts returned by the recipients.
446 - the original signedData object requesting the signed receipt
448 - the message signature digest value used to generate the original
449 signedData signerInfo signature value and the digest value of the
450 Receipt content containing values included in the original signedData
451 object. If signed receipts are requested from multiple recipients, then
452 retaining these digest values is a performance enhancement because the
453 sending agent can reuse the saved values when verifying each returned
454 signed receipt.
456 2.3 Receipt Request Processing
458 A receiptRequest is associated only with the SignerInfo object in which the
459 receipt request attribute is directly attached. Processing software SHOULD
460 examine the authenticatedAttributes field of each of the SignerInfos for
461 which it verifies a signature in the innermost signedData object to
462 determine if a receipt is requested. This may result in the receiving agent
463 processing multiple receiptRequest attributes included in a single
464 SignedData object.
466 Because all receiptRequest attributes in a SignedData object must be
467 identical, the receiving application fully processes (as described in the
468 following paragraphs) the first receiptRequest that it encounters in a
469 SignerInfo that it can verify, and it then ensures that all other
470 receiptRequests are identical to the first one encountered. If
471 ReceiptRequests which conflict are present, then the processing software
472 MUST NOT return any receipt.
474 If a receiptRequest attribute is absent from the authenticated attributes,
475 then a signed receipt has not been requested from any of the message
476 recipients and MUST NOT be created. If a receiptRequest attribute is
477 present in the authenticated attributes, then a signed receipt has been
478 requested from some or all of the message recipients. Note that in some
479 cases, a receiving agent might receive two almost-identical messages, one
480 with a receipt request and the other without one. In this case, the
481 receiving agent SHOULD send a signed receipt for the message that requests
482 a signed receipt. A receipt SHOULD be returned if any signature containing
483 a receipt request can be validated, even if other signatures containing the
484 same receipt request cannot be validated.
486 If a receiptRequest attribute is present in the authenticated attributes,
487 the following process SHOULD be used to determine if a message recipient
488 has been requested to return a signed receipt.
490 1. If an mlExpansionHistory attribute is present in the outermost
491 signedData block, do one of the following two steps, based on the absence
492 or presence of mlReceiptPolicy:
494 1.1. If an mlReceiptPolicy value is absent from the last MLData
495 element, a Mail List receipt policy has not been specified and the
496 processing software SHOULD examine the receiptRequest attribute value
497 to determine if a receipt should be created and returned.
499 1.2. If an mlReceiptPolicy value is present in the last MLData element,
500 do one of the following two steps, based on the value of
501 mlReceiptPolicy:
503 1.2.1. If the mlReceiptPolicy value is none, then the receipt
504 policy of the Mail List supersedes the originator's request for a
505 signed receipt and a signed receipt MUST NOT be created.
507 1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo,
508 the processing software SHOULD examine the receiptsFrom value from
509 the receiptRequest attribute to determine if a receipt should be
510 created and returned. If a receipt is created, the insteadOf and
511 inAdditionTo fields identify entities that SHOULD be sent the
512 receipt instead of or in addition to the originator.
514 2. If the receiptsFrom value of the receiptRequest attribute is
515 allOrFirstTier, do one of the following two steps based on the value of
516 allOrFirstTier.
518 2.1. If the value of allOrFirstTier is allReceipts, then a signed
519 receipt SHOULD be created.
521 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
522 the following two steps based on the presence of an mlExpansionHistory
523 attribute in an outer signedData block:
525 2.2.1. If an mlExpansionHistory attribute is present, then this
526 recipient is not a first tier recipient and a signed receipt MUST
527 NOT be created.
529 2.2.2. If an mlExpansionHistory attribute is not present, then a
530 signed receipt SHOULD be created.
532 3. If the receiptsFrom value of the receiptRequest attribute is a
533 receiptList:
535 3.1. If receiptList contains one of the GeneralNames of the recipient,
536 then a signed receipt should be created.
538 3.2. If receiptList does not contain one of the GeneralNames of the
539 recipient, then a signed receipt MUST NOT be created.
541 A flow chart for the above steps to be executed for each signerInfo for
542 which the receiving agent verifies the signature would be:
544 0. Receipt Request attribute present?
545 YES -> 1.
546 NO -> STOP
547 1. Has mlExpansionHistory in outer signedData?
548 YES -> 1.1.
549 NO -> 2.
550 1.1. mlReceiptPolicy absent?
551 YES -> 2.
552 NO -> 1.2.
553 1.2. Pick based on value of mlReceiptPolicy.
554 none -> 1.2.1.
555 insteadOf or inAdditionTo -> 1.2.2.
556 1.2.1. STOP.
557 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
558 create it if required, send it to recipients designated by
559 mlReceiptPolicy, then -> STOP.
560 2. Is value of receiptsFrom allOrFirstTier?
561 YES -> Pick based on value of allOrFirstTier.
562 allReceipts -> 2.1.
563 firstTierRecipients -> 2.2.
564 NO -> 3.
565 2.1. Create a receipt, then -> STOP.
566 2.2. Has mlExpansionHistory in the outer signedData block?
567 YES -> 2.2.1.
568 NO -> 2.2.2.
569 2.2.1. STOP.
570 2.2.2. Create a receipt, then -> STOP.
571 3. Is receiptsFrom value of receiptRequest a receiptList?
572 YES -> 3.1.
573 NO -> STOP.
574 3.1. Does receiptList contain the recipient?
575 YES -> Create a receipt, then -> STOP.
576 NO -> 3.2.
577 3.2. STOP.
579 2.4 Signed Receipt Creation
581 A signed receipt is a signedData object encapsulating a Receipt content
582 (also called a "signedData/Receipt"). Signed receipts are created as
583 follows:
585 1. The signature of the original signedData signerInfo that includes the
586 receiptRequest authenticated attribute MUST be successfully verified before
587 creating the signedData/Receipt.
589 1.1. The content of the original signedData object is digested as
590 described in [CMS]. The resulting digest value is then compared with
591 the value of the messageDigest attribute included in the
592 authenticatedAttributes of the original signedData signerInfo. If these
593 digest values are different, then the signature verification process
594 fails and the signedData/Receipt MUST NOT be created.
596 1.2. The ASN.1 DER encoded authenticatedAttributes (including
597 messageDigest, receiptRequest and, possibly, other authenticated
598 attributes) in the original signedData signerInfo are digested as
599 described in [CMS]. The resulting digest value, called msgSigDigest, is
600 then used to verify the signature of the original signedData
601 signerInfo. If the signature verification fails, then the
602 signedData/Receipt MUST NOT be created.
604 2. A Receipt structure is created.
606 2.1. The value of the Receipt version field is set to 1.
608 2.2. The object identifier from the contentType attribute included in
609 the original signedData signerInfo that includes the receiptRequest
610 attribute is copied into the Receipt contentType.
612 2.3. The original signedData signerInfo receiptRequest
613 signedContentIdentifier is copied into the Receipt
614 signedContentIdentifier.
616 2.4. The signature value from the original signedData signerInfo that
617 includes the receiptRequest attribute is copied into the Receipt
618 originatorSignatureValue.
620 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
622 4. D1 is digested. The resulting digest value is included as the
623 messageDigest attribute in the authenticatedAttributes of the signerInfo
624 which will eventually contain the signedData/Receipt signature value.
626 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
627 signature of the original signedData signerInfo is included as the
628 msgSigDigest attribute in the authenticatedAttributes of the signerInfo
629 which will eventually contain the signedData/Receipt signature value.
631 6. A contentType attribute including the id-ct-receipt object identifier
632 MUST be created and added to the authenticated attributes of the signerInfo
633 which will eventually contain the signedData/Receipt signature value.
635 7. A signingTime attribute indicating the time that the signedData/Receipt
636 is signed SHOULD be created and added to the authenticated attributes of
637 the signerInfo which will eventually contain the signedData/Receipt
638 signature value. Other attributes (except receiptRequest) may be added to
639 the authenticatedAttributes of the signerInfo.
641 8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
642 and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
643 as described in CMS, Section 5.3. The resulting digest value is used to
644 calculate the signature value which is then included in the
645 signedData/Receipt signerInfo.
647 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
648 the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
649 id-ct-receipt object identifier MUST be included in the signedData
650 encapContentInfo eContentType. This results in a single ASN.1 encoded
651 object composed of a signedData including the Receipt content. The Data
652 content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
653 in a MIME header or any other header prior to being encoded as part of the
654 signedData object.
656 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
657 wrapper with the smime-type parameter set to "signed-receipt". This will
658 allow for identification of signed receipts without having to crack the
659 ASN.1 body. The smime-type parameter would still be set as normal in any
660 layer wrapped around this message.
662 11. If the signedData/Receipt is to be encrypted within an envelopedData
663 object, then an outer signedData object MUST be created that encapsulates
664 the envelopedData object, and a contentHints attribute with contentType set
665 to the id-ct-receipt object identifier MUST be included in the outer
666 signedData SignerInfo authenticatedAttributes. When a receiving agent
667 processes the outer signedData object, the presence of the id-ct-receipt
668 OID in the contentHints contentType indicates that a signedData/Receipt is
669 encrypted within the envelopedData object encapsulated by the outer
670 signedData.
672 2.4.1 MLExpansionHistory Attributes and Receipts
674 An MLExpansionHistory attribute MUST NOT be included in the attributes of a
675 SignerInfo in a SignedData object that encapsulates a Receipt content. This
676 is true because when a SignedData/Receipt is sent to an MLA for
677 distribution, then the MLA must always encapsulate the received
678 SignedData/Receipt in an outer SignedData in which the MLA will include the
679 MLExpansionHistory attribute. The MLA cannot change the
680 authenticatedAttributes of the received SignedData/Receipt object, so it
681 can't add the MLExpansionHistory to the SignedData/Receipt.
683 2.5 Determining the Recipients of the Signed Receipt
685 If a signed receipt was created by the process described in the sections
686 above, then the software MUST use the following process to determine to
687 whom the signed receipt should be sent.
689 1. The receiptsTo field must be present in the receiptRequest attribute.
690 The software initiates the sequence of recipients with the value(s) of
691 receiptsTo.
693 2. If the MlExpansionHistory attribute is present in the outer SignedData
694 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
695 then the software replaces the sequence of recipients with the value(s) of
696 insteadOf.
698 3. If the MlExpansionHistory attribute is present in the outer SignedData
699 block and the last MLData contains an MLReceiptPolicy value of
700 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
701 sequence of recipients.
703 2.6. Signed Receipt Validation
705 A signed receipt is communicated as a single ASN.1 encoded object composed
706 of a signedData object directly including a Receipt content. It is
707 identified by the presence of the id-ct-receipt object identifier in the
708 encapContentInfo eContentType value of the signedData object including the
709 Receipt content.
711 A signedData/Receipt is validated as follows:
713 1. ASN.1 decode the signedData object including the Receipt content.
715 2. Extract the contentType, signedContentIdentifier, and
716 originatorSignatureValue from the decoded Receipt structure to identify the
717 original signedData signerInfo that requested the signedData/Receipt.
719 3. Acquire the message signature digest value calculated by the sender to
720 generate the signature value included in the original signedData signerInfo
721 that requested the signedData/Receipt.
723 3.1. If the sender-calculated message signature digest value has been
724 saved locally by the sender, it must be located and retrieved.
726 3.2. If it has not been saved, then it must be re-calculated based on
727 the original signedData content and authenticatedAttributes as
728 described in [CMS].
730 4. The message signature digest value calculated by the sender is then
731 compared with the value of the msgSigDigest authenticatedAttribute included
732 in the signedData/Receipt signerInfo. If these digest values are identical,
733 then that proves that the message signature digest value calculated by the
734 recipient based on the received original signedData object is the same as
735 that calculated by the sender. This proves that the recipient received
736 exactly the same original signedData content and authenticatedAttributes as
737 sent by the sender because that is the only way that the recipient could
738 have calculated the same message signature digest value as calculated by
739 the sender. If the digest values are different, then the signedData/Receipt
740 signature verification process fails.
742 5. Acquire the digest value calculated by the sender for the Receipt
743 content constructed by the sender (including the contentType,
744 signedContentIdentifier, and signature value that were included in the
745 original signedData signerInfo that requested the signedData/Receipt).
747 5.1. If the sender-calculated Receipt content digest value has been
748 saved locally by the sender, it must be located and retrieved.
750 5.2. If it has not been saved, then it must be re-calculated. As
751 described in section 2.4 above, step 2, create a Receipt structure
752 including the contentType, signedContentIdentifier and signature value
753 that were included in the original signedData signerInfo that requested
754 the signed receipt. The Receipt structure is then ASN.1 DER encoded to
755 produce a data stream which is then digested to produce the Receipt
756 content digest value.
758 6. The Receipt content digest value calculated by the sender is then
759 compared with the value of the messageDigest authenticatedAttribute
760 included in the signedData/Receipt signerInfo. If these digest values are
761 identical, then that proves that the values included in the Receipt content
762 by the recipient are identical to those that were included in the original
763 signedData signerInfo that requested the signedData/Receipt. This proves
764 that the recipient received the original signedData signed by the sender,
765 because that is the only way that the recipient could have obtained the
766 original signedData signerInfo signature value for inclusion in the Receipt
767 content. If the digest values are different, then the signedData/Receipt
768 signature verification process fails.
770 7. The ASN.1 DER encoded authenticatedAttributes of the signedData/Receipt
771 signerInfo are digested as described in [CMS].
773 8. The resulting digest value is then used to verify the signature value
774 included in the signedData/Receipt signerInfo. If the signature
775 verification is successful, then that proves the integrity of the
776 signedData/receipt signerInfo authenticatedAttributes and authenticates the
777 identity of the signer of the signedData/Receipt signerInfo. Note that the
778 authenticatedAttributes include the recipient-calculated Receipt content
779 digest value (messageDigest attribute) and recipient-calculated message
780 signature digest value (msgSigDigest attribute). Therefore, the
781 aforementioned comparison of the sender-generated and recipient-generated
782 digest values combined with the successful signedData/Receipt signature
783 verification proves that the recipient received the exact original
784 signedData content and authenticatedAttributes (proven by msgSigDigest
785 attribute) that were signed by the sender of the original signedData object
786 (proven by messageDigest attribute). If the signature verification fails,
787 then the signedData/Receipt signature verification process fails.
789 The signature verification process for each signature algorithm that is
790 used in conjunction with the CMS protocol is specific to the algorithm.
791 These processes are described in documents specific to the algorithms.
793 2.7 Receipt Request Syntax
795 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
796 receiptRequest attribute only within the authenticated attributes
797 associated with a signed message.
799 ReceiptRequest ::= SEQUENCE {
800 signedContentIdentifier ContentIdentifier,
801 receiptsFrom ReceiptsFrom,
802 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
804 ub-receiptsTo INTEGER ::= 16
806 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
807 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
809 ContentIdentifier ::= OCTET STRING
811 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
812 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
814 A signedContentIdentifier MUST be created by the message originator when
815 creating a receipt request. To ensure global uniqueness, the minimal
816 signedContentIdentifier SHOULD contain a concatenation of user-specific
817 identification information (such as a user name or public keying material
818 identification information), a GeneralizedTime string, and a random number.
820 The receiptsFrom field is used by the originator to specify the recipients
821 requested to return a signed receipt. A CHOICE is provided to allow
822 specification of:
823 - receipts from all recipients are requested
824 - receipts from first tier (recipients that did not receive the
825 message as members of a mailing list) recipients are requested
826 - receipts from a specific list of recipients are requested
828 ReceiptsFrom ::= CHOICE {
829 allOrFirstTier [0] AllOrFirstTier,
830 -- formerly "allOrNone [0]AllOrNone"
831 receiptList [1] SEQUENCE OF GeneralNames }
833 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
834 allReceipts (0),
835 firstTierRecipients (1) }
837 The receiptsTo field is used by the originator to identify the user(s) to
838 whom the identified recipient should send signed receipts. The message
839 originator MUST populate the receiptsTo field with a GeneralNames for each
840 entity to whom the recipient should send the signed receipt. If the message
841 originator wants the recipient to send the signed receipt to the
842 originator, then the originator MUST include a GeneralNames for itself in
843 the receiptsTo field.
845 2.8 Receipt Syntax
847 Receipts are represented using a new content type, Receipt. The Receipt
848 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
849 within a SignedData message.
851 Receipt ::= SEQUENCE {
852 version Version, -- Version is imported from [CMS]
853 contentType ContentType,
854 signedContentIdentifier ContentIdentifier,
855 originatorSignatureValue OCTET STRING }
857 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
858 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
860 The version field defines the syntax version number, which is 1 for this
861 version of the standard.
863 2.9 Content Hints
865 Many applications find it useful to have information that describes the
866 innermost signed content of a multi-layer message available on the
867 outermost signature layer. The contentHints attribute provides such
868 information.
870 Content-hints attribute values have ASN.1 type contentHints.
872 ContentHints ::= SEQUENCE {
873 contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL,
874 -- If contentDescription is used, its contents MUST be in UTF8 format
875 contentType ContentType }
877 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
878 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
880 The contentDescription field may be used to provide information that the
881 recipient may use to select protected messages for processing, such as a
882 message subject. If this field is set, then the attribute is expected to
883 appear on the signedData object enclosing an envelopedData object and not
884 on the inner signedData object. If a contentDescription is present, it MUST
885 be in UTF8 format, as described in [UTF8]. The SIZE (1..MAX) construct
886 constrains the sequence to have at least one entry. MAX indicates the upper
887 bound is unspecified. Implementations are free to choose an upper bound
888 that suits their environment.
890 Messages which contain a signedData object wrapped around an envelopedData
891 object, thus masking the inner content type of the message, SHOULD include
892 a contentHints attribute, except for the case of the data content type.
893 Specific message content types may either force or preclude the inclusion
894 of the contentHints attribute. For example, when a signedData/Receipt is
895 encrypted within an envelopedData object, an outer signedData object MUST
896 be created that encapsulates the envelopedData object and a contentHints
897 attribute with contentType set to the id-ct-receipt object identifier MUST
898 be included in the outer signedData SignerInfo authenticatedAttributes.
900 2.10 Message Signature Digest Attribute
902 The msgSigDigest attribute can only be used in the authenticated attributes
903 of a signed receipt. It contains the digest of the ASN.1 DER encoded
904 authenticatedAttributes included in the original signedData that requested
905 the signed receipt. Only one msgSigDigest attribute can appear in an
906 authenticated attributes set. It is defined as follows:
908 msgSigDigest ::= OCTET STRING
910 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
911 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
913 3. Security Labels
915 This section describes the syntax to be used for security labels that can
916 optionally be associated with S/MIME encapsulated data. A security label is
917 a set of security information regarding the sensitivity of the content that
918 is protected by S/MIME encapsulation.
920 "Authorization" is the act of granting rights and/or privileges to users
921 permitting them access to an object. "Access control" is a means of
922 enforcing these authorizations. The sensitivity information in a security
923 label can be compared with a user's authorizations to determine if the user
924 is allowed to access the content that is protected by S/MIME encapsulation.
926 Security labels may be used for other purposes such as a source of routing
927 information. The labels are often priority based ("secret", "confidential",
928 "restricted", and so on) or role-based, describing which kind of people can
929 see the information ("patient's health-care team", "medical billing
930 agents", "unrestricted", and so on).
932 3.1 Security Label Processing Rules
934 A sending agent may include a security label attribute in the authenticated
935 attributes of a signedData object. A receiving agent examines the security
936 label on a received message and determines whether or not the recipient is
937 allowed to see the contents of the message.
939 3.1.1 Adding Security Labels
941 A sending agent that is using security labels MUST put the security label
942 attribute in the authenticatedAttributes field of a SignerInfo block. The
943 security label attribute MUST NOT be included in the unauthenticated
944 attributes. Integrity and authentication security services MUST be applied
945 to the security label, therefore it MUST be included as an authenticated
946 attribute, if used. This causes the security label attribute to be part of
947 the data that is hashed to form the SignerInfo signature value. A
948 SignerInfo block MUST NOT have more than one security label authenticated
949 attribute.
951 When there are multiple SignedData blocks applied to a message, a security
952 label attribute may be included in either the inner signature, outer
953 signature, or both. A security label authenticated attribute may be
954 included in a authenticatedAttributes field within the inner SignedData
955 block. The inner security label will include the sensitivities of the
956 original content and will be used for access control decisions related to
957 the plaintext encapsulated content. The inner signature provides
958 authentication of the inner security label and cryptographically protects
959 the original signer's inner security label of the original content.
961 When the originator signs the plaintext content and authenticated
962 attributes, the inner security label is bound to the plaintext content. An
963 intermediate entity cannot change the inner security label without
964 invalidating the inner signature. The confidentiality security service can
965 be applied to the inner security label by encrypting the entire inner
966 signedData object within an EnvelopedData block.
968 A security label authenticated attribute may also be included in a
969 authenticatedAttributes field within the outer SignedData block. The outer
970 security label will include the sensitivities of the encrypted message and
971 will be used for access control decisions related to the encrypted message
972 and for routing decisions. The outer signature provides authentication of
973 the outer security label (as well as for the encapsulated content which may
974 include nested S/MIME messages).
976 There can be multiple SignerInfos within a SignedData object, and each
977 SignerInfo may include authenticatedAttributes. Therefore, a single
978 SignedData object may include multiple eSSSecurityLabels, each SignerInfo
979 having an eSSSecurityLabel attribute. For example, an originator can send a
980 signed message with two SignerInfos, one containing a DSS signature, the
981 other containing an RSA signature. If any of the SignerInfos included in a
982 SignedData object include an eSSSecurityLabel attribute, then all of the
983 SignerInfos in that SignedData object MUST include an eSSSecurityLabel
984 attribute and the value of each MUST be identical.
986 3.1.2 Processing Security Labels
988 Before processing an eSSSecurityLabel authenticatedAttribute, the receiving
989 agent MUST verify the signature of the SignerInfo which covers the
990 eSSSecurityLabel attribute. A recipient MUST NOT process an
991 eSSSecurityLabel attribute that has not been verified.
993 A receiving agent MUST process the eSSSecurityLabel attribute, if present,
994 in each SignerInfo in the SignedData object for which it verifies the
995 signature. This may result in the receiving agent processing multiple
996 eSSSecurityLabels included in a single SignedData object. Because all
997 eSSSecurityLabels in a SignedData object must be identical, the receiving
998 agent processes (such as performing access control) on the first
999 eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
1000 then ensures that all other eSSSecurityLabels in signerInfos that it
1001 verifies are identical to the first one encountered. If the
1002 eSSSecurityLabels in the signerInfos that it verifies are not all
1003 identical, then the receiving agent MUST warn the user of this condition.
1005 3.2 Syntax of eSSSecurityLabel
1007 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
1008 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
1009 ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
1010 [MSP4].
1012 The eSSSecurityLabel MUST be marked as critical. This means that any
1013 message with an eSSSecurityLabel will be unreadable to S/MIME v2 clients.
1014 Because of this, a sending agent SHOULD apply an eSSSecurityLabel only if
1015 it needs the services this attribute provides.
1017 ESSSecurityLabel ::= SET {
1018 version Version DEFAULT v1,
1019 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
1020 security-classification SecurityClassification OPTIONAL,
1021 privacy-mark ESSPrivacyMark OPTIONAL,
1022 security-categories SecurityCategories OPTIONAL }
1024 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1025 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
1027 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1029 SecurityClassification ::= INTEGER {
1030 unmarked (0),
1031 unclassified (1),
1032 restricted (2),
1033 confidential (3),
1034 secret (4),
1035 top-secret (5) } (0..ub-integer-options)
1037 ub-integer-options INTEGER ::= 256
1039 ESSPrivacyMark ::= CHOICE {
1040 pString PrintableString (SIZE (1..ub-privacy-mark-length)),
1041 -- If pString is used, the ESSSecurityLabel version is set to v1
1042 utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX)
1043 -- If utf8String is used, its contents MUST be in UTF8 format, and
1044 -- the ESSSecurityLabel version is set to v2
1045 }
1047 ub-privacy-mark-length INTEGER ::= 128
1049 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1050 SecurityCategory
1052 ub-security-categories INTEGER ::= 64
1054 SecurityCategory ::= SEQUENCE {
1055 type [0] OBJECT IDENTIFIER,
1056 value [1] ANY -- defined by type
1057 }
1059 --Note: The aforementioned SecurityCategory syntax produces identical
1060 --hex encodings as the following SecurityCategory syntax that is
1061 --documented in the X.411 specification:
1062 --
1063 --SecurityCategory ::= SEQUENCE {
1064 -- type [0] SECURITY-CATEGORY,
1065 -- value [1] ANY DEFINED BY type }
1066 --
1067 --SECURITY-CATEGORY MACRO ::=
1068 --BEGIN
1069 --TYPE NOTATION ::= type | empty
1070 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1071 --END
1073 3.3 Security Label Components
1075 This section gives more detail on the the various components of the
1076 eSSSecurityLabel syntax.
1078 3.3.1 Security Policy Identifier
1080 A security policy is a set of criteria for the provision of security
1081 services. The eSSSecurityLabel security-policy-identifier is used to
1082 identify the security policy in force to which the security label relates.
1083 It indicates the semantics of the other security label components. Even
1084 though the eSSSecurityLabel security-policy-identifier is an optional
1085 field, all security labels used with S/MIME messages MUST include the
1086 security-policy-identifier.
1088 3.3.2 Security Classification
1090 This specification defines the use of the Security Classification field
1091 exactly as is specified in the X.411 Recommendation, which states in part:
1093 If present, a security-classification may have one of a hierarchical
1094 list of values. The basic security-classification hierarchy is defined
1095 in this Recommendation, but the use of these values is defined by the
1096 security-policy in force. Additional values of security-classification,
1097 and their position in the hierarchy, may also be defined by a
1098 security-policy as a local matter or by bilateral agreement. The basic
1099 security-classification hierarchy is, in ascending order: unmarked,
1100 unclassified, restricted, confidential, secret, top-secret.
1102 This means that the security policy in force (identified by the
1103 eSSSecurityLabel security-policy-identifier) defines the
1104 SecurityClassification integer values and their meanings.
1106 An organization can develop its own security policy that defines the
1107 SecurityClassification INTEGER values and their meanings. However, the
1108 general interpretation of the X.411 specification is that the values of 0
1109 through 5 are reserved for the "basic hierarchy" values of unmarked,
1110 unclassified, restricted, confidential, secret, and top-secret. Note that
1111 X.411 does not provide the rules for how these values are used to label
1112 data and how access control is performed using these values.
1114 There is no universal definition of the rules for using these "basic
1115 hierarchy" values. Each organization (or group of organizations) will
1116 define a security policy which documents how the "basic hierarchy" values
1117 are used (if at all) and how access control is enforced (if at all) within
1118 their domain.
1120 Therefore, the security-classification value MUST be accompanied by a
1121 security-policy-identifier value to define the rules for its use. For
1122 example, a company's "secret" classification may convey a different meaning
1123 than the US Government "secret" classification. In summary, a security
1124 policy SHOULD NOT use integers 0 through 5 for other than their X.411
1125 meanings, and SHOULD instead use other values in a hierarchical fashion.
1127 Note that the set of valid security-classification values MUST be
1128 hierarchical, but these values do not necessarily need to be in ascending
1129 numerical order. Further, the values do not need to be contiguous.
1131 For example, in the Defense Message System 1.0 security policy, the
1132 security-classification value of 11 indicates Sensitive-But-Unclassified
1133 and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret
1134 as more sensitive than Sensitive-But-Unclassified even though the numerical
1135 value of top-secret is less than Sensitive-But-Unclassified.
1137 (Of course, if security-classification values are both hierarchical and in
1138 ascending order, a casual reader of the security policy is more likely to
1139 understand it.)
1141 An example of a security policy that does not use any of the X.411 values
1142 might be:
1143 10 -- anyone
1144 15 -- Morgan Corporation and its contractors
1145 20 -- Morgan Corporation employees
1146 25 -- Morgan Corporation board of directors
1148 An example of a security policy that uses part of the X.411 hierarchy might
1149 be:
1150 0 -- unmarked
1151 1 -- unclassified, can be read by everyone
1152 2 -- restricted to Timberwolf Productions staff
1153 6 -- can only be read to Timberwolf Productions executives
1155 3.3.3 Privacy Mark
1157 If present, the eSSSecurityLabel privacy-mark is not used for access
1158 control. The content of the eSSSecurityLabel privacy-mark may be defined by
1159 the security policy in force (identified by the eSSSecurityLabel
1160 security-policy-identifier) which may define a list of values to be used.
1161 Alternately, the value may be determined by the originator of the
1162 security-label.
1164 3.3.4 Security Categories
1166 If present, the eSSSecurityLabel security-categories provide further
1167 granularity for the sensitivity of the message. The security policy in
1168 force (identified by the eSSSecurityLabel security-policy-identifier) is
1169 used to indicate the syntaxes that are allowed to be present in the
1170 eSSSecurityLabel security-categories. Alternately, the security-categories
1171 and their values may be defined by bilateral agreement.
1173 4. Mail List Management
1175 Sending agents must create recipient-specific data structures for each
1176 recipient of an encrypted message. This process can impair performance for
1177 messages sent to a large number of recipients. Thus, Mail List Agents
1178 (MLAs) that can take a single message and perform the recipient-specific
1179 encryption for every recipient are often desired.
1181 An MLA appears to the message originator as a normal message recipient, but
1182 the MLA acts as a message expansion point for a Mail List (ML). The sender
1183 of a message directs the message to the MLA, which then redistributes the
1184 message to the members of the ML. This process offloads the per-recipient
1185 processing from individual user agents and allows for more efficient
1186 management of large MLs. MLs are true message recipients served by MLAs
1187 that provide cryptographic and expansion services for the mailing list.
1189 In addition to cryptographic handling of messages, secure mailing lists
1190 also have to prevent mail loops. A mail loop is where one mailing list is a
1191 member of a second mailing list, and the second mailing list is a member of
1192 the first. A message will go from one list to the other in a
1193 rapidly-cascading succession of mail that will be distributed to all other
1194 members of both lists.
1196 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
1197 outer signature of a triple wrapped message. The mlExpansionHistory
1198 attribute is essentially a list of every MLA that has processed the
1199 message. If an MLA sees its own unique entity identifier in the list, it
1200 knows that a loop has been formed, and does not send the message to the
1201 list again.
1203 4.1 Mail List Expansion
1205 Mail list expansion processing is noted in the value of the
1206 mlExpansionHistory attribute, located in the authenticated attributes of
1207 the MLA's SignerInfo block. The MLA creates or updates the authenticated
1208 mlExpansionHistory attribute value each time the MLA expands and signs a
1209 message for members of a mail list.
1211 The MLA MUST add an MLData record containing the MLA's identification
1212 information, date and time of expansion, and optional receipt policy to the
1213 end of the mail list expansion history sequence. If the mlExpansionHistory
1214 attribute is absent, then the MLA MUST add the attribute and the current
1215 expansion becomes the first element of the sequence. If the
1216 mlExpansionHistory attribute is present, then the MLA MUST add the current
1217 expansion information to the end of the existing MLExpansionHistory
1218 sequence. Only one mlExpansionHistory attribute can be included in the
1219 authenticatedAttributes of a SignerInfo.
1221 Note that if the mlExpansionHistory attribute is absent, then the recipient
1222 is a first tier message recipient.
1224 There can be multiple SignerInfos within a SignedData object, and each
1225 SignerInfo may include authenticatedAttributes. Therefore, a single
1226 SignedData object may include multiple SignerInfos, each SignerInfo having
1227 a mlExpansionHistory attribute. For example, an originator can send a
1228 signed message with two SignerInfos, one containing a DSS signature, the
1229 other containing an RSA signature. Not all of the SignerInfos need to
1230 include mlExpansionHistory attributes, but in all of the SignerInfos that
1231 do contain mlExpansionHistory attributes, the mlExpansionHistory attributes
1232 MUST be identical.
1234 A recipient SHOULD only process an mlExpansionHistory attribute if the
1235 recipient can verify the signature of the SignerInfo which covers the
1236 attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
1237 the recipient cannot authenticate.
1239 When receiving a message that includes an outer SignedData object, a
1240 receiving agent that processes mlExpansionHistory attributes MUST process
1241 the mlExpansionHistory attribute, if present, in each SignerInfo in the
1242 SignedData object for which it verifies the signature. This may result in
1243 the receiving agent processing multiple mlExpansionHistory attributes
1244 included in a single SignedData object. Because all mlExpansionHistory
1245 attributes must be identical, the receiving application processes the first
1246 mlExpansionHistory attribute that it encounters in a SignerInfo that it can
1247 verify, and then ensures that all other mlExpansionHistory attributes are
1248 identical to the first one encountered.
1250 4.1.1 Detecting Mail List Expansion Loops
1252 Prior to expanding a message, the MLA examines the value of any existing
1253 mail list expansion history attribute to detect an expansion loop. An
1254 expansion loop exists when a message expanded by a specific MLA for a
1255 specific mail list is redelivered to the same MLA for the same mail list.
1257 Expansion loops are detected by examining the mailListIdentifier field of
1258 each MLData entry found in the mail list expansion history. If an MLA finds
1259 its own identification information, then the MLA must discontinue expansion
1260 processing and should provide warning of an expansion loop to a human mail
1261 list administrator. The mail list administrator is responsible for
1262 correcting the loop condition.
1264 4.2 Mail List Agent Processing
1266 The first few paragraphs of this section provide a high-level description
1267 of MLA processing. The rest of the section provides a detailed description
1268 of MLA processing.
1270 MLA message processing depends on the structure of the S/MIME layers in the
1271 message sent to the MLA for expansion. In addition to sending triple
1272 wrapped messages to an MLA, an entity can send other types of messages to
1273 an MLA, such as:
1275 - a single wrapped signedData or envelopedData message
1276 - a double wrapped message (such as signed and enveloped, enveloped and
1277 signed, or signed and signed, and so on)
1278 - a quadruple-wrapped message (such as if a well-formed triple wrapped
1279 message was sent through a gateway that added an outer SignedData layer)
1281 In all cases, the MLA MUST parse all layers of the received message to
1282 determine if there are any signedData layers that include an
1283 eSSSecurityLabel authenticatedAttribute. This may include decrypting an
1284 EnvelopedData layer to determine if an encapsulated SignedData layer
1285 includes an eSSSecurityLabel attribute. The MLA MUST fully process each
1286 eSSSecurityLabel attribute found in the various signedData layers,
1287 including performing access control checks, before distributing the message
1288 to the ML members. The details of the access control checks are beyond the
1289 scope of this document. The MLA MUST verify the signature of the signerInfo
1290 including the eSSSecurityLabel attribute before using it.
1292 In all cases, the MLA MUST sign the message to be sent to the ML members in
1293 a new "outer" signedData layer. The MLA MUST add or update an
1294 mlExpansionHistory attribute in the "outer" signedData that it creates to
1295 document MLA processing. If there was an "outer" signedData layer included
1296 in the original message received by the MLA, then the MLA-created "outer"
1297 signedData layer MUST include each authenticated attribute present in the
1298 original "outer" signedData layer, unless the MLA explicitly replaces an
1299 attribute (such as signingTime or mlExpansionHistory) with a new value.
1301 When an S/MIME message is received by the MLA, the MLA MUST first determine
1302 which received signedData layer, if any, is the "outer" signedData layer.
1303 To identify the received "outer" signedData layer, the MLA MUST verify the
1304 signature and fully process the authenticatedAttributes in each of the
1305 outer signedData layers (working from the outside in) to determine if any
1306 of them either include an mlExpansionHistory attribute or encapsulate an
1307 envelopedData object.
1309 The MLA's search for the "outer" signedData layer is completed when it
1310 finds one of the following:
1311 - the "outer" signedData layer that includes an mlExpansionHistory
1312 attribute or encapsulates an envelopedData object
1313 - an envelopedData layer
1314 - the original content (that is, a layer that is neither envelopedData nor
1315 signedData).
1317 If the MLA finds an "outer" signedData layer, then the MLA MUST perform
1318 the following steps:
1319 1. Strip off all of the signedData layers that encapsulated the "outer"
1320 signedData layer
1321 2. Strip off the "outer" signedData layer itself (after remembering the
1322 included authenticatedAttributes)
1323 3. Expand the envelopedData (if present)
1324 4. Sign the message to be sent to the ML members in a new "outer"
1325 signedData layer that includes the authenticatedAttributes (unless
1326 explicitly replaced) from the original, received "outer" signedData layer.
1328 If the MLA finds an "outer" signedData layer that includes an
1329 mlExpansionHistory attribute AND the MLA subsequently finds an
1330 envelopedData layer buried deeper with the layers of the received message,
1331 then the MLA MUST strip off all of the signedData layers down to the
1332 envelopedData layer (including stripping off the original "outer"
1333 signedData layer) and MUST sign the expanded envelopedData in a new "outer"
1334 signedData layer that includes the authenticatedAttributes (unless
1335 explicitly replaced) from the original, received "outer" signedData layer.
1337 If the MLA does not find an "outer" signedData layer AND does not find an
1338 envelopedData layer, then the MLA MUST sign the original, received message
1339 in a new "outer" signedData layer. If the MLA does not find an "outer"
1340 signedData AND does find an envelopedData layer then it MUST expand the
1341 envelopedData layer, if present, and sign it in a new "outer" signedData
1342 layer.
1344 4.2.1 Examples of Rule Processing
1346 The following examples help explain the rules above:
1348 1) A message (S1(Original Content)) (where S = SignedData) is sent to the
1349 MLA in which the signedData layer does not include an MLExpansionHistory
1350 attribute. The MLA verifies and fully processes the authenticatedAttributes
1351 in S1. The MLA decides that there is not an original, received "outer"
1352 signedData layer since it finds the original content, but never finds an
1353 envelopedData and never finds an mlExpansionHistory attribute. The MLA
1354 calculates a new signedData layer, S2, resulting in the following message
1355 sent to the ML recipients: (S2(S1(Original Content))). The MLA includes an
1356 mlExpansionHistory attribute in S2.
1358 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which
1359 none of the signedData layers includes an MLExpansionHistory attribute.
1360 The MLA verifies and fully processes the authenticatedAttributes in S3, S2
1361 and S1. The MLA decides that there is not an original, received "outer"
1362 signedData layer since it finds the original content, but never finds an
1363 envelopedData and never finds an mlExpansionHistory attribute. The MLA
1364 calculates a new signedData layer, S4, resulting in the following message
1365 sent to the ML recipients: (S4(S3(S2(S1(Original Content))))). The MLA
1366 includes an mlExpansionHistory attribute in S4.
1368 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent
1369 to the MLA in which S1 does not include an MLExpansionHistory attribute.
1370 The MLA decides that there is not an original, received "outer" signedData
1371 layer since it finds the E1 as the outer layer. The MLA expands the
1372 recipientInformation in E1. The MLA calculates a new signedData layer, S2,
1373 resulting in the following message sent to the ML recipients:
1374 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory
1375 attribute in S2.
1377 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
1378 includes an MLExpansionHistory attribute. The MLA verifies the signature
1379 and fully processes the authenticatedAttributes in S2. The MLA finds the
1380 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
1381 signedData. The MLA remembers the authenticatedAttributes included in S2
1382 for later inclusion in the new outer signedData that it applies to the
1383 message. The MLA strips off S2. The MLA then expands the
1384 recipientInformation in E1 (this invalidates the signature in S2 which is
1385 why it was stripped). The MLA calculates a new signedData layer, S3,
1386 resulting in the following message sent to the ML recipients:
1387 (S3(E1(S1(Original Content)))). The MLA includes in S3 the attributes from
1388 S2 (unless it specifically replaces an attribute value) including an updated
1389 mlExpansionHistory attribute.
1391 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1392 none of the signedData layers include an MLExpansionHistory attribute. The
1393 MLA verifies the signature and fully processes the authenticatedAttributes
1394 in S3 and S2. When the MLA encounters E1, then it decides that S2 is the
1395 "outer" signedData since S2 encapsulates E1. The MLA remembers the
1396 authenticatedAttributes included in S2 for later inclusion in the new outer
1397 signedData that it applies to the message. The MLA strips off S3 and S2.
1398 The MLA then expands the recipientInformation in E1 (this invalidates the
1399 signatures in S3 and S2 which is why they were stripped). The MLA calculates
1400 a new signedData layer, S4, resulting in the following message sent to the
1401 ML recipients: (S4(E1(S1(Original Content)))). The MLA includes in S4 the
1402 attributes from S2 (unless it specifically replaces an attribute value) and
1403 includes a new mlExpansionHistory attribute.
1405 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1406 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
1407 the signature and fully processes the authenticatedAttributes in S3. The MLA
1408 finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
1409 signedData. The MLA remembers the authenticatedAttributes included in S3
1410 for later inclusion in the new outer signedData that it applies to the
1411 message. The MLA keeps on parsing encapsulated layers because it must
1412 determine if there are any eSSSecurityLabel attributes contained within.
1413 The MLA verifies the signature and fully processes the
1414 authenticatedAttributes in S2. When the MLA encounters E1, then it strips
1415 off S3 and S2. The MLA then expands the recipientInformation in E1 (this
1416 invalidates the signatures in S3 and S2 which is why they were stripped).
1417 The MLA calculates a new signedData layer, S4, resulting in the following
1418 message sent to the ML recipients: (S4(E1(S1(Original Content)))). The MLA
1419 includes in S4 the attributes from S3 (unless it specifically replaces an
1420 attribute value) including an updated mlExpansionHistory attribute.
1422 4.2.3 Processing Choices
1424 The processing used depends on the type of the outermost layer of the
1425 message. There are three cases for the type of the outermost data:
1426 - EnvelopedData
1427 - SignedData
1428 - data
1430 4.2.3.1 Processing for EnvelopedData
1432 1. The MLA locates its own RecipientInfo and uses the information it
1433 contains to obtain the message key.
1435 2. The MLA removes the existing recipientInfos field and replaces it with a
1436 new recipientInfos value built from RecipientInfo structures created for
1437 each member of the mailing list. The MLA also removes the existing
1438 originatorInfo field and replaces it with a new originatorInfo value built
1439 from information describing the MLA.
1441 3. The MLA encapsulates the expanded encrypted message in a SignedData
1442 block, adding an mlExpansionHistory attribute as described in the "Mail
1443 List Expansion" section to document the expansion.
1445 4. The MLA signs the new message and delivers the updated message to mail
1446 list members to complete MLA processing.
1448 4.2.3.2 Processing for SignedData
1450 MLA processing of multi-layer messages depends on the type of data in each
1451 of the layers. Step 3 below specifies that different processing will take
1452 place depending on the type of CMS message that has been signed. That
1453 is, it needs to know the type of data at the next inner layer, which may or
1454 may not be the innermost layer.
1456 1. The MLA verifies the signature value found in the outermost SignedData
1457 layer associated with the signed data. MLA processing of the message
1458 terminates if the message signature is invalid.
1460 2. If the outermost SignedData layer includes an authenticated
1461 mlExpansionHistory attribute the MLA checks for an expansion loop as
1462 described in the "Detecting Mail List Expansion Loops" section.
1464 3. Determine the type of the data that has been signed. That is, look at
1465 the type of data on the layer just below the SignedData, which may or may
1466 not be the "innermost" layer. Based on the type of data, perform either
1467 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1468 types).
1470 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1471 processing of the encrypted message as described previously. Note that
1472 this process invalidates the signature value in the outermost
1473 SignedData layer associated with the original encrypted message.
1474 Proceed to section 3.2 with the result of the expansion.
1476 3.2. If the signed data is SignedData, or is the result of expanding an
1477 EnvelopedData block in step 3.1:
1479 3.2.1. The MLA strips the existing outermost SignedData layer after
1480 remembering the value of the mlExpansionHistory and all other
1481 authenticated attributes in that layer, if present.
1483 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1484 encapsulates the expanded encrypted message in a new outermost
1485 SignedData layer. On the other hand, if the signed data is
1486 SignedData (from step 3.2), the MLA encapsulates the signed data in
1487 a new outermost SignedData layer.
1489 3.2.3. The outermost signedData layer created by the MLA replaces
1490 the original outermost signedData layer. The MLA MUST create an
1491 authenticated attribute list for the new outermost signedData layer
1492 which MUST include each authenticated attribute present in the
1493 original outermost signedData layer, unless the MLA explicitly
1494 replaces one or more particular attributes with new value. A
1495 special case is the mlExpansionHistory attribute. The MLA MUST add
1496 an mlExpansionHistory authenticated attribute to the outer
1497 signedData layer as follows:
1499 3.2.3.1. If the original outermost SignedData layer included an
1500 mlExpansionHistory attribute, the attribute's value is copied
1501 and updated with the current ML expansion information as
1502 described in the "Mail List Expansion" section.
1504 3.2.3.2. If the original outermost SignedData layer did not
1505 include an mlExpansionHistory attribute, a new attribute value
1506 is created with the current ML expansion information as
1507 described in the "Mail List Expansion" section.
1509 3.3. If the signed data is not EnvelopedData or SignedData:
1511 3.3.1. The MLA encapsulates the received signedData object in an
1512 outer SignedData object, and adds an mlExpansionHistory attribute
1513 to the outer SignedData object containing the current ML expansion
1514 information as described in the "Mail List Expansion" section.
1516 4. The MLA signs the new message and delivers the updated message to mail
1517 list members to complete MLA processing.
1519 A flow chart for the above steps would be:
1521 1. Has a valid signature?
1522 YES -> 2.
1523 NO -> STOP.
1524 2. Does outermost SignedData layer
1525 contain mlExpansionHistory?
1526 YES -> Check it, then -> 3.
1527 NO -> 3.
1528 3. Check type of data just below outermost
1529 SignedData.
1530 EnvelopedData -> 3.1.
1531 SignedData -> 3.2.
1532 all others -> 3.3.
1533 3.1. Expand the encrypted message, then -> 3.2.
1534 3.2. -> 3.2.1.
1535 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
1536 and other authenticated attributes, then -> 3.2.2.
1537 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1538 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
1539 YES -> copy the old mlExpansionHistory values, then -> 4.
1540 NO -> create new mlExpansionHistory value, then -> 4.
1541 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
1542 attribute, then -> 4.
1543 4. Sign message, deliver it, STOP.
1545 4.2.3.3 Processing for data
1547 1. The MLA encapsulates the message in a SignedData layer, and adds an
1548 mlExpansionHistory attribute containing the current ML expansion
1549 information as described in the "Mail List Expansion" section.
1551 2. The MLA signs the new message and delivers the updated message to mail
1552 list members to complete MLA processing.
1554 4.3 Mail List Agent Signed Receipt Policy Processing
1556 If a mailing list (B) is a member of another mailing list (A), list B often
1557 needs to propagate forward the mailing list receipt policy of A. As a
1558 general rule, a mailing list should be conservative in propagating forward
1559 the mailing list receipt policy because the ultimate recipient need only
1560 process the last item in the ML expansion history. The MLA builds the
1561 expansion history to meet this requirement.
1563 The following table describes the outcome of the union of mailing list A's
1564 policy (the rows in the table) and mailing list B's policy (the columns in
1565 the table).
1567 | B's policy
1568 A's policy | none insteadOf inAdditionTo missing
1569 -------------------------------------------------------------------------
1570 none | none none none none
1571 insteadOf | none insteadOf(B) *1 insteadOf(A)
1572 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
1573 missing | none insteadOf(B) inAdditionTo(B) missing
1575 *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
1576 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
1578 4.4 Mail List Expansion History Syntax
1580 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1581 there are more than ub-ml-expansion-history mailing lists in the sequence,
1582 the processing agent should provide notification of the error to a human
1583 mail list administrator. The mail list administrator is responsible for
1584 correcting the overflow condition.
1586 MLExpansionHistory ::= SEQUENCE
1587 SIZE (1..ub-ml-expansion-history) OF MLData
1589 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1590 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
1592 ub-ml-expansion-history INTEGER ::= 64
1594 MLData contains the expansion history describing each MLA that has
1595 processed a message. As an MLA distributes a message to members of an ML,
1596 the MLA records its unique identifier, date and time of expansion, and
1597 receipt policy in an MLData structure.
1599 MLData ::= SEQUENCE {
1600 mailListIdentifier EntityIdentifier,
1601 -- EntityIdentifier is imported from [CMS]
1602 expansionTime GeneralizedTime,
1603 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1605 The receipt policy of the ML can withdraw the originator's request for
1606 the return of a signed receipt. However, if the originator of the
1607 message has not requested a signed receipt, the MLA cannot request a
1608 signed receipt.
1610 When present, the mlReceiptPolicy specifies a receipt policy that
1611 supersedes the originator's request for signed receipts. The policy
1612 can be one of three possibilities: receipts MUST NOT be returned
1613 (none); receipts should be returned to an alternate list of
1614 recipients, instead of to the originator (insteadOf); or receipts
1615 should be returned to a list of recipients in addition to the
1616 originator (inAdditionTo).
1618 MLReceiptPolicy ::= CHOICE {
1619 none [0] NULL,
1620 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
1621 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
1623 5. Security Considerations
1625 This entire document discusses security.
1627 A. ASN.1 Module
1629 ExtendedSecurityServices
1630 { iso(1) member-body(2) us(840) rsadsi(113549)
1631 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
1633 DEFINITIONS IMPLICIT TAGS ::=
1634 BEGIN
1636 IMPORTS
1638 -- Cryptographic Message Syntax (CMS)
1639 ContentType, EntityIdentifier, SubjectKeyIdentifier, Version
1640 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
1641 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
1643 -- X.509
1644 GeneralNames FROM CertificateExtensions
1645 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
1647 -- Extended Security Services
1649 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
1650 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
1651 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
1652 -- have at least one entry. MAX indicates the upper bound is unspecified.
1653 -- Implementations are free to choose an upper bound that suits their
1654 -- environment.
1656 -- Section 2.7
1658 ReceiptRequest ::= SEQUENCE {
1659 signedContentIdentifier ContentIdentifier,
1660 receiptsFrom ReceiptsFrom,
1661 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
1663 ub-receiptsTo INTEGER ::= 16
1665 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1666 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
1668 ContentIdentifier ::= OCTET STRING
1670 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1671 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
1673 ReceiptsFrom ::= CHOICE {
1674 allOrFirstTier [0] AllOrFirstTier,
1675 -- formerly "allOrNone [0]AllOrNone"
1676 receiptList [1] SEQUENCE OF GeneralNames }
1678 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
1679 allReceipts (0),
1680 firstTierRecipients (1) }
1682 -- Section 2.8
1684 Receipt ::= SEQUENCE {
1685 version Version, -- Version is imported from [CMS]
1686 contentType ContentType,
1687 signedContentIdentifier ContentIdentifier,
1688 originatorSignatureValue OCTET STRING }
1690 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
1691 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
1693 -- Section 2.9
1695 ContentHints ::= SEQUENCE {
1696 contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL,
1697 -- If contentDescription is used, its contents MUST be in UTF8 format
1698 contentType ContentType }
1700 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
1701 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
1703 -- Section 2.10
1705 MsgSigDigest ::= OCTET STRING
1707 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1708 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
1710 -- Section 3.2
1712 ESSSecurityLabel ::= SET {
1713 version Version DEFAULT v1,
1714 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
1715 security-classification SecurityClassification OPTIONAL,
1716 privacy-mark ESSPrivacyMark OPTIONAL,
1717 security-categories SecurityCategories OPTIONAL }
1719 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1720 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
1722 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1724 SecurityClassification ::= INTEGER {
1725 unmarked (0),
1726 unclassified (1),
1727 restricted (2),
1728 confidential (3),
1729 secret (4),
1730 top-secret (5) } (0..ub-integer-options)
1732 ub-integer-options INTEGER ::= 256
1734 ESSPrivacyMark ::= CHOICE {
1735 pString PrintableString (SIZE (1..ub-privacy-mark-length)),
1736 -- If pString is used, the ESSSecurityLabel version is set to v1
1737 utf8String [0] IMPLICIT OCTET STRING SIZE (1..MAX)
1738 -- If utf8String is used, its contents MUST be in UTF8 format, and
1739 -- the ESSSecurityLabel version is set to v2
1740 }
1742 ub-privacy-mark-length INTEGER ::= 128
1744 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1745 SecurityCategory
1747 ub-security-categories INTEGER ::= 64
1749 SecurityCategory ::= SEQUENCE {
1750 type [0] OBJECT IDENTIFIER,
1751 value [1] ANY -- defined by type
1752 }
1754 --Note: The aforementioned SecurityCategory syntax produces identical
1755 --hex encodings as the following SecurityCategory syntax that is
1756 --documented in the X.411 specification:
1757 --
1758 --SecurityCategory ::= SEQUENCE {
1759 -- type [0] SECURITY-CATEGORY,
1760 -- value [1] ANY DEFINED BY type }
1761 --
1762 --SECURITY-CATEGORY MACRO ::=
1763 --BEGIN
1764 --TYPE NOTATION ::= type | empty
1765 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1766 --END
1768 -- Section 4.4
1770 MLExpansionHistory ::= SEQUENCE
1771 SIZE (1..ub-ml-expansion-history) OF MLData
1773 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1774 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
1776 ub-ml-expansion-history INTEGER ::= 64
1778 MLData ::= SEQUENCE {
1779 mailListIdentifier EntityIdentifier,
1780 -- EntityIdentifier is imported from [CMS]
1781 expansionTime GeneralizedTime,
1782 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1784 MLReceiptPolicy ::= CHOICE {
1785 none [0] NULL,
1786 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
1787 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
1789 END -- of ExtendedSecurityServices
1791 B. References
1793 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
1794 Notation One (ASN.1)"
1796 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
1797 Notation One (ASN.1)"
1799 [CMS] "Cryptographic Message Syntax", Internet Draft
1800 draft-ietf-smime-cms-xx.
1802 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP)
1803 4.0", Specification SDN.701, Revision A, 1997-02-06.
1805 [MTSABS] "1988 International Telecommunication Union (ITU) Data
1806 Communication Networks Message Handling Systems: Message Transfer System:
1807 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
1808 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
1809 mts(3) modules(0) mts-abstract-service(1)}
1811 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft
1812 draft-hoffman-pkcs-crypt-msg-xx.
1814 [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft
1815 draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling",
1816 Internet Draft draft-dusse-smime-cert-xx.
1818 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
1819 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
1820 Internet Draft draft-ietf-smime-cert-xx.
1822 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
1824 C. Acknowledgments
1826 The first draft of this work was prepared by David Solo. John Pawling did a
1827 huge amount of very detailed revision work during the many phases of the
1828 document.
1830 Many other people have contributed hard work to this draft, including:
1831 Bengt Ackzell
1832 Blake Ramsdell
1833 Carlisle Adams
1834 Jim Schaad
1835 Russ Housley
1836 Scott Hollenbeck
1837 Steve Dusse
1839 D. Open Issues
1841 There is consensus that contentHints should move to the CMS draft.
1843 E. Changes from draft-ietf-smime-ess-03 to draft-ietf-smime-ess-04
1845 1. Removed mention of redefining UTF8String.
1847 1.1.2, steps 3 and 5: Reworded these to make them clearer.
1849 1.2 Changed both examples to be (hopefully) clearer. Also added MIME
1850 boundaries that were left out.
1852 2.3, step 2.2: added "in the outer signedData block". Also added to the
1853 flow chart in step 1 and step 2.2.
1855 2.3, flow chart: reworded 1.2.1.
1857 2.4, step 1.1: Removed "ASN.1 DER encoded".
1859 2.4, step 2.2: Reworded this step.
1861 2.4, step 2.4: Added this step.
1863 2.4, step 9: Changed "eContent" to "eContentType".
1865 2.4, step 10: added this new step, and renumbered the last step.
1867 2.7: Removed superfluous sentence in the middle of the section.
1869 2.9: Changed definition of contentDescription. Added note about UTF8
1870 format. Also updated Appendix A.
1872 3.1.1: Changed last paragraph to deal with multiple eSSSecurityLabels.
1874 3.1.2: Change two paragraphs to deal with multiple eSSSecurityLabels.
1876 3.2: Added words in the second paragraph about use of eSSSecurityLabel and
1877 S/MIME v2 clients.
1879 3.2: Changed the second option of the ESSPrivacyMark to be an implicit
1880 octet string. Added version number to ESSSecurityLabel. Made same changes
1881 in Appendix A.
1883 4.2: Replaced much of this section with more information about how to find
1884 the outer wrapper. Also renumbered sub-parts of this section.
1886 A: Removed UNIVERSAL 12 definition from top of module.
1888 F. Editor's Address
1890 Paul Hoffman
1891 Internet Mail Consortium
1892 127 Segre Place
1893 Santa Cruz, CA 95060
1894 (408) 426-9827
1895 phoffman@imc.org