idnits 2.17.1
draft-ietf-smime-ess-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-24) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 2313 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 447 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
** There are 82 instances of lines with control characters in the document.
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 100: '...entInfo eContent MUST be absent. If th...'
RFC 2119 keyword, line 102: '...entInfo eContent MUST contain the resu...'
RFC 2119 keyword, line 125: '...contentType MUST be id-data. The Envel...'
RFC 2119 keyword, line 154: '...receiving agents MUST be able to inter...'
RFC 2119 keyword, line 235: '...request MUST be in the inside signatur...'
(137 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 1731 has weird spacing: '... | none inst...'
== Line 1733 has weird spacing: '... | none none...'
== Line 1734 has weird spacing: '... | none inst...'
== Line 1735 has weird spacing: '... | none inst...'
== Line 1736 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 (September 30, 1998) is 9338 days in the past. Is
this intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'MSP4' on line 2234 looks like a reference
-- Missing reference section? 'SMIME3' on line 2248 looks like a reference
-- Missing reference section? 'SMIME2' on line 2245 looks like a reference
-- Missing reference section? 'ASN1-1988' on line 2225 looks like a
reference
-- Missing reference section? 'ESS' on line 302 looks like a reference
-- Missing reference section? 'CMS' on line 2231 looks like a reference
-- Missing reference section? 'MSG' on line 307 looks like a reference
-- Missing reference section? '0' on line 2217 looks like a reference
-- Missing reference section? '1' on line 2218 looks like a reference
-- Missing reference section? 'MTSABS' on line 2237 looks like a reference
-- Missing reference section? '2' on line 2219 looks like a reference
-- Missing reference section? 'UNIVERSAL 12' on line 2069 looks like a
reference
-- Missing reference section? 'UTF8' on line 2252 looks like a reference
-- Missing reference section? 'ASN1-1994' on line 2228 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-08.txt Internet Mail Consortium
3 September 30, 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), ftp.ietf.org (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 [MSP4], 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 signed attributes
66 bound to the encrypted body. Outer attributes may be added or removed by
67 the message originator or intermediate agents, and may be signed by
68 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 signed attributes can be used for access
75 control to the inner body. Requests for signed receipts by the originator
76 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
115 is 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
119 with parameters, optional MIME headers (such as
120 Content-transfer-encoding and Content-disposition), and the result of
121 step 3 above.
123 5. Encrypt the result of step 4 as a single block, turning it into an
124 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
125 contentType MUST be id-data. The EnvelopedData structure is encapsulated by
126 a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
127 called the "encrypted body".
129 6. Add the appropriate MIME headers: a Content-type of
130 application/pkcs7-mime with parameters, and optional MIME headers such as
131 Content-transfer-encoding and Content-disposition.
133 7. Using the same logic as in step 3 above, sign the result of step 6 (the
134 MIME headers and the encrypted body) as a single block
136 8. Using the same logic as in step 4 above, add an appropriate MIME
137 construct to the signed message from step 7. The resulting message is
138 called the "outside signature", and is also the triple wrapped message.
140 1.2 Format of a Triple Wrapped Message
142 A triple wrapped message has many layers of encapsulation. The structure
143 differs based on the choice of format for the signed portions of the
144 message. Because of the way that MIME encapsulates data, the layers do not
145 appear in order, and the notion of "layers" becomes vague.
147 There is no need to use the multipart/signed format in an inner signature
148 because it is known that the recipient is able to process S/MIME messages
149 (because they decrypted the middle wrapper). A sending agent might choose
150 to use the multipart/signed format in the outer layer so that a non-S/MIME
151 agent could see that the next inner layer is encrypted; however, this is
152 not of great value, since all it shows the recipient is that the rest of
153 the message is unreadable. Because many sending agents always use
154 multipart/signed structures, all receiving agents MUST be able to interpret
155 either multipart/signed or application/pkcs7-mime signature structures.
157 The format of a triple wrapped message that uses multipart/signed for both
158 signatures is:
160 [step 8] Content-type: multipart/signed;
161 [step 8] protocol="application/pkcs7-signature";
162 [step 8] boundary=outerboundary
163 [step 8]
164 [step 8] --outerboundary
165 [step 6] Content-type: application/pkcs7-mime; )
166 [step 6] smime-type=enveloped-data )
167 [step 6] )
168 [step 4] Content-type: multipart/signed; | )
169 [step 4] protocol="application/pkcs7-signature"; | )
170 [step 4] boundary=innerboundary | )
171 [step 4] | )
172 [step 4] --innerboundary | )
173 [step 2] Content-type: text/plain % | )
174 [step 2] % | )
175 [step 1] Original content % | )
176 [step 4] | )
177 [step 4] --innerboundary | )
178 [step 4] Content-type: application/pkcs7-signature | )
179 [step 4] | )
180 [step 3] inner SignedData block (eContent is missing) | )
181 [step 4] | )
182 [step 4] --innerboundary-- | )
183 [step 8]
184 [step 8] --outerboundary
185 [step 8] Content-type: application/pkcs7-signature
186 [step 8]
187 [step 7] outer SignedData block (eContent is missing)
188 [step 8]
189 [step 8] --outerboundary--
191 % = These lines are what the inner signature is computed over.
192 | = These lines are what is encrypted in step 5. This encrypted result
193 is opaque and is a part of an EnvelopedData block.
194 ) = These lines are what the outer signature is computed over.
196 The format of a triple wrapped message that uses application/pkcs7-mime for
197 the both signatures is:
199 [step 8] Content-type: application/pkcs7-mime;
200 [step 8] smime-type=signed-data
201 [step 8]
202 [step 7] outer SignedData block (eContent is present) O
203 [step 6] Content-type: application/pkcs7-mime; ) O
204 [step 6] smime-type=enveloped-data; ) O
205 [step 6] ) O
206 [step 4] Content-type: application/pkcs7-mime; | ) O
207 [step 4] smime-type=signed-data | ) O
208 [step 4] | ) O
209 [step 3] inner SignedData block (eContent is present) I | ) O
210 [step 2] Content-type: text/plain I | ) O
211 [step 2] I | ) O
212 [step 1] Original content I | ) O
214 I = These lines are the inner SignedData block, which is opaque and
215 contains the ASN.1 encoded result of step 2 as well as control
216 information.
217 | = These lines are what is encrypted in step 5. This encrypted result
218 is opaque and is a part of an EnvelopedData block.
219 ) = These lines are what the outer signature is computed over.
220 O = These lines are the outer SignedData block, which is opaque and
221 contains the ASN.1 encoded result of step 6 as well as control
222 information.
224 1.3 Security Services and Triple Wrapping
226 The three security services described in this document are used with triple
227 wrapped messages in different ways. This section briefly describes the
228 relationship of each service with triple wrapping; the other sections of
229 the document go into greater detail.
231 1.3.1 Signed Receipts and Triple Wrapping
233 A signed receipt may be requested in any SignedData object. However, if a
234 signed receipt is requested for a triple wrapped message, the receipt
235 request MUST be in the inside signature, not in the outside signature. A
236 secure mailing list agent may change the receipt policy in the outside
237 signature of a triple wrapped message when that message is processed by the
238 mailing list.
240 Note: the signed receipts and receipt requests described in this draft
241 differ from those described in the work done by the IETF Receipt
242 Notification Working Group. The output of that Working Group, when
243 finished, is not expected to work well with triple wrapped messages as
244 described in this document.
246 1.3.2 Security Labels and Triple Wrapping
248 A security label may be included in the signed attributes of any SignedData
249 object. A security label attribute may be included in either the inner
250 signature, outer signature, or both.
252 The inner security label is used for access control decisions related to
253 the plaintext original content. The inner signature provides authentication
254 and cryptographically protects the original signer's security label that is
255 on the inside body. This strategy facilitates the forwarding of messages
256 because the original signer's security label is included in the SignedData
257 block which can be forwarded to a third party that can verify the inner
258 signature which will cover the inner security label. The confidentiality
259 security service can be applied to the inner security label by encrypting
260 the entire inner SignedData block within an EnvelopedData block.
262 A security label may also be included in the signed attributes of the outer
263 SignedData block which will include the sensitivities of the encrypted
264 message. The outer security label is used for access control and routing
265 decisions related to the encrypted message. Note that a security label
266 attribute can only be used in an signedAttributes block. An
267 eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned
268 attributes.
270 1.3.3 Secure Mailing Lists and Triple Wrapping
272 Secure mail list message processing depends on the structure of S/MIME
273 layers present in the message sent to the mail list agent. The agent never
274 changes the data that was hashed to form the inner signature, if such a
275 signature is present. If an outer signature is present, then the agent will
276 modify the data that was hashed to form that outer signature. In all cases,
277 the agent adds or updates an mlExpansionHistory attribute to document the
278 agent's processing, and ultimately adds or replaces the outer signature on
279 the message to be distributed.
281 1.3.4 Placement of Attributes
283 Certain attributes should be placed in the inner or outer SignedData
284 message; some attributes can be in either. Further, some attributes must be
285 signed, while signing is optional for others, and some attributes must not
286 be signed. The following table summarizes the recommendation of this
287 profile.
289 | |Inner or |
290 Attribute |OID |outer |Signed
291 ------------------|----------------------------- |----------|--------
292 contentHints |id-aa-contentHint [ESS] |either |MAY
293 contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
294 contentReference |id-aa-contentReference [ESS] |either |MUST
295 contentType |id-contentType [CMS] |either |MUST
296 counterSignature |id-countersignature [CMS] |either |MUST NOT
297 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
298 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
299 messageDigest |id-messageDigest [CMS] |either |MUST
300 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
301 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
302 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
303 signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
304 signingTime |id-signingTime [CMS] |either |MUST
305 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
306 sMIMEEncryption-
307 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
309 CMS defines signedAttrs as a SET OF Attributes and defines
310 unsignedAttributes as a SET OF Attributes. ESS defines the contentHints,
311 contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
312 receiptRequest, contentReference and equivalentLabels attribute types. A
313 signerInfo MUST NOT include multiple instances of any of the attribute
314 types defined in ESS. Later sections of ESS specify further restrictions
315 that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel
316 attribute types.
318 CMS defines the syntax for the signed and unsigned attributes as
319 "attrValues SET OF AttributeValue". For all of the attribute types defined
320 in ESS, if the attribute type is present in a signerInfo, then it MUST only
321 include a single instance of AttributeValue. In other words, there MUST NOT
322 be zero or multiple instances of AttributeValue present in the attrValues
323 SET OF AttributeValue.
325 If a counterSignature attribute is present, then it MUST be included in the
326 unsigned attributes. It MUST NOT be included in the signed attributes. The
327 only attributes that are allowed in a counterSignature attribute are
328 counterSignature, messageDigest, signingTime, and signingCertificate.
330 Note that the inner and outer signatures are usually for different senders.
331 The same attribute in the two signatures could lead to very different
332 consequences.
334 The macValue attribute is only used in authenticatedData, never in
335 signedData.
337 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
338 identifier assigned to the message.
340 1.4 Required and Optional Attributes
342 Some security gateways sign messages that pass through them. If the message
343 is any type other than a signedData type, the gateway has only one way to
344 sign the message: by wrapping it with a signedData block and MIME headers.
345 If the message to be signed by the gateway is a signedData message already,
346 the gateway can sign the message by inserting a signerInfo into the
347 signedData block.
349 The main advantage of a gateway adding a signerInfo instead of wrapping the
350 message in a new signature is that the message doesn't grow as much as if
351 the gateway wrapped the message. The main disadvantage is that the gateway
352 must check for the presence of certain attributes in the other signerInfos
353 and duplicate those attributes.
355 If a gateway or other processor adds a signerInfo to an existing signedData
356 block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes
357 from other signerInfos. This helps ensure that the recipient will process
358 those attributes in a signerInfo that it can verify.
360 Note that someone may in the future define an attribute that must be
361 present in each signerInfo of a signedData block in order for the signature
362 to be processed. If that happens, a gateway that inserts signerInfos and
363 doesn't copy that attribute will cause every message with that attribute to
364 fail when processed by the recipient. For this reason, it is safer to wrap
365 messages with new signatures than to insert signerInfos.
367 1.5 Object Identifiers
369 The object identifiers for many of the objects described in this draft are
370 found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be
371 found in the registry kept at .
372 When this draft moves to standards track within the IETF, it is intended
373 that the IANA will maintain this registry.
375 2. Signed Receipts
377 Returning a signed receipt provides to the originator proof of delivery of
378 a message, and allows the originator to demonstrate to a third party that
379 the recipient was able to verify the signature of the original message.
380 This receipt is bound to the original message through the signature;
381 consequently, this service may be requested only if a message is signed.
382 The receipt sender may optionally also encrypt a receipt to provide
383 confidentiality between the receipt sender and the receipt recipient.
385 2.1 Signed Receipt Concepts
387 The originator of a message may request a signed receipt from the message's
388 recipients. The request is indicated by adding a receiptRequest attribute
389 to the signedAttributes field of the SignerInfo object for which the
390 receipt is requested. The receiving user agent software SHOULD
391 automatically create a signed receipt when requested to do so, and return
392 the receipt in accordance with mailing list expansion options, local
393 security policies, and configuration options.
395 Because receipts involve the interaction of two parties, the terminology
396 can sometimes be confusing. In this section, the "sender" is the agent that
397 sent the original message that included a request for a receipt. The
398 "receiver" is the party that received that message and generated the
399 receipt.
401 The steps in a typical transaction are:
403 1. Sender creates a signed message including a receipt request attribute
404 (Section 2.2).
406 2. Sender transmits the resulting message to the recipient or recipients.
408 3. Recipient receives message and determines if there is a valid signature
409 and receipt request in the message (Section 2.3).
411 4. Recipient creates a signed receipt (Section 2.4).
413 5. Recipient transmits the resulting signed receipt message to the sender
414 (Section 2.5).
416 6. Sender receives the message and validates that it contains a signed
417 receipt for the original message (Section 2.6). This validation relies on
418 the sender having retained either a copy of the original message or
419 information extracted from the original message.
421 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
422 syntax for the receipt is given in Section 2.8.
424 Note that an agent SHOULD remember when it has sent a receipt so that it
425 can avoid re-sending a receipt each time it processes the message.
427 2.2 Receipt Request Creation
429 Multi-layer S/MIME messages may contain multiple SignedData layers.
430 However, receipts may be requested only for the innermost SignedData layer
431 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
432 receiptRequest attribute can be included in the signedAttributes of a
433 SignerInfo.
435 A ReceiptRequest attribute MUST NOT be included in the attributes of a
436 SignerInfo in a SignedData object that encapsulates a Receipt content. In
437 other words, the user agent MUST NOT request a signed receipt for a signed
438 receipt.
440 A sender requests receipts by placing a receiptRequest attribute in the
441 signed attributes of a signerInfo as follows:
443 1. A receiptRequest data structure is created.
445 2. A signed content identifier for the message is created and assigned to
446 the signedContentIdentifier field. The signedContentIdentifier is used to
447 associate the signed receipt with the message requesting the signed
448 receipt.
450 3. The entities requested to return a signed receipt are noted in the
451 receiptsFrom field.
453 4. The message originator MUST populate the receiptsTo field with a
454 GeneralNames for each entity to whom the recipient should send the signed
455 receipt. If the message originator wants the recipient to send the signed
456 receipt to the originator, then the originator MUST include a GeneralNames
457 for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
458 GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
459 GeneralNames represents an entity. There may be multiple GeneralName
460 instances in each GeneralNames. At a minimum, the message originator MUST
461 populate each entity's GeneralNames with the address to which the signed
462 receipt should be sent. Optionally, the message originator MAY also
463 populate each entity's GeneralNames with other GeneralName instances (such
464 as directoryName).
466 5. The completed receiptRequest attribute is placed in the signedAttributes
467 field of the SignerInfo object.
469 2.2.1 Multiple Receipt Requests
471 There can be multiple SignerInfos within a SignedData object, and each
472 SignerInfo may include signedAttributes. Therefore, a single SignedData
473 object may include multiple SignerInfos, each SignerInfo having a
474 receiptRequest attribute. For example, an originator can send a signed
475 message with two SignerInfos, one containing a DSS signature, the other
476 containing an RSA signature.
478 Each recipient SHOULD return only one signed receipt.
480 Not all of the SignerInfos need to include receipt requests, but in all of
481 the SignerInfos that do contain receipt requests, the receipt requests MUST
482 be identical.
484 2.2.2 Information Needed to Validate Signed Receipts
486 The sending agent MUST retain one or both of the following items to support
487 the validation of signed receipts returned by the recipients.
489 - the original signedData object requesting the signed receipt
491 - the message signature digest value used to generate the original
492 signedData signerInfo signature value and the digest value of the
493 Receipt content containing values included in the original signedData
494 object. If signed receipts are requested from multiple recipients, then
495 retaining these digest values is a performance enhancement because the
496 sending agent can reuse the saved values when verifying each returned
497 signed receipt.
499 2.3 Receipt Request Processing
501 A receiptRequest is associated only with the SignerInfo object in which the
502 receipt request attribute is directly attached. Processing software SHOULD
503 examine the signedAttributes field of each of the SignerInfos for which it
504 verifies a signature in the innermost signedData object to determine if a
505 receipt is requested. This may result in the receiving agent processing
506 multiple receiptRequest attributes included in a single SignedData object.
508 Before processing a receiptRequest signedAttribute, the receiving agent
509 MUST verify the signature of the SignerInfo which covers the receiptRequest
510 attribute. A recipient MUST NOT process a receiptRequest attribute that has
511 not been verified. Because all receiptRequest attributes in a SignedData
512 object must be identical, the receiving application fully processes (as
513 described in the following paragraphs) the first receiptRequest attribute
514 that it encounters in a SignerInfo that it verifies, and it then ensures
515 that all other receiptRequest attributes in signerInfos that it verifies
516 are identical to the first one encountered. If there are verified
517 ReceiptRequest attributes which conflict, then the processing software MUST
518 NOT return any signed receipt. A signed receipt SHOULD be returned if any
519 signerInfo containing a receiptRequest attribute can be validated, even if
520 other signerInfos containing the same receiptRequest attribute cannot be
521 validated because they are signed using an algorithm not supported by the
522 receiving agent.
524 If a receiptRequest attribute is absent from the signed attributes, then a
525 signed receipt has not been requested from any of the message recipients
526 and MUST NOT be created. If a receiptRequest attribute is present in the
527 signed attributes, then a signed receipt has been requested from some or
528 all of the message recipients. Note that in some cases, a receiving agent
529 might receive two almost-identical messages, one with a receipt request and
530 the other without one. In this case, the receiving agent SHOULD send a
531 signed receipt for the message that requests a signed receipt.
533 If a receiptRequest attribute is present in the signed attributes, the
534 following process SHOULD be used to determine if a message recipient has
535 been requested to return a signed receipt.
537 1. If an mlExpansionHistory attribute is present in the outermost
538 signedData block, do one of the following two steps, based on the absence
539 or presence of mlReceiptPolicy:
541 1.1. If an mlReceiptPolicy value is absent from the last MLData
542 element, a Mail List receipt policy has not been specified and the
543 processing software SHOULD examine the receiptRequest attribute value
544 to determine if a receipt should be created and returned.
546 1.2. If an mlReceiptPolicy value is present in the last MLData element,
547 do one of the following two steps, based on the value of
548 mlReceiptPolicy:
550 1.2.1. If the mlReceiptPolicy value is none, then the receipt
551 policy of the Mail List supersedes the originator's request for a
552 signed receipt and a signed receipt MUST NOT be created.
554 1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo,
555 the processing software SHOULD examine the receiptsFrom value from
556 the receiptRequest attribute to determine if a receipt should be
557 created and returned. If a receipt is created, the insteadOf and
558 inAdditionTo fields identify entities that SHOULD be sent the
559 receipt instead of or in addition to the originator.
561 2. If the receiptsFrom value of the receiptRequest attribute is
562 allOrFirstTier, do one of the following two steps based on the value of
563 allOrFirstTier.
565 2.1. If the value of allOrFirstTier is allReceipts, then a signed
566 receipt SHOULD be created.
568 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
569 the following two steps based on the presence of an mlExpansionHistory
570 attribute in an outer signedData block:
572 2.2.1. If an mlExpansionHistory attribute is present, then this
573 recipient is not a first tier recipient and a signed receipt MUST
574 NOT be created.
576 2.2.2. If an mlExpansionHistory attribute is not present, then a
577 signed receipt SHOULD be created.
579 3. If the receiptsFrom value of the receiptRequest attribute is a
580 receiptList:
582 3.1. If receiptList contains one of the GeneralNames of the recipient,
583 then a signed receipt should be created.
585 3.2. If receiptList does not contain one of the GeneralNames of the
586 recipient, then a signed receipt MUST NOT be created.
588 A flow chart for the above steps to be executed for each signerInfo for
589 which the receiving agent verifies the signature would be:
591 0. Receipt Request attribute present?
592 YES -> 1.
593 NO -> STOP
594 1. Has mlExpansionHistory in outer signedData?
595 YES -> 1.1.
596 NO -> 2.
597 1.1. mlReceiptPolicy absent?
598 YES -> 2.
599 NO -> 1.2.
600 1.2. Pick based on value of mlReceiptPolicy.
601 none -> 1.2.1.
602 insteadOf or inAdditionTo -> 1.2.2.
603 1.2.1. STOP.
604 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
605 create it if required, send it to recipients designated by
606 mlReceiptPolicy, then -> STOP.
607 2. Is value of receiptsFrom allOrFirstTier?
608 YES -> Pick based on value of allOrFirstTier.
609 allReceipts -> 2.1.
610 firstTierRecipients -> 2.2.
611 NO -> 3.
612 2.1. Create a receipt, then -> STOP.
613 2.2. Has mlExpansionHistory in the outer signedData block?
614 YES -> 2.2.1.
615 NO -> 2.2.2.
616 2.2.1. STOP.
617 2.2.2. Create a receipt, then -> STOP.
618 3. Is receiptsFrom value of receiptRequest a receiptList?
619 YES -> 3.1.
620 NO -> STOP.
621 3.1. Does receiptList contain the recipient?
622 YES -> Create a receipt, then -> STOP.
623 NO -> 3.2.
624 3.2. STOP.
626 2.4 Signed Receipt Creation
628 A signed receipt is a signedData object encapsulating a Receipt content
629 (also called a "signedData/Receipt"). Signed receipts are created as
630 follows:
632 1. The signature of the original signedData signerInfo that includes the
633 receiptRequest signed attribute MUST be successfully verified before
634 creating the signedData/Receipt.
636 1.1. The content of the original signedData object is digested as
637 described in [CMS]. The resulting digest value is then compared with
638 the value of the messageDigest attribute included in the
639 signedAttributes of the original signedData signerInfo. If these digest
640 values are different, then the signature verification process fails and
641 the signedData/Receipt MUST NOT be created.
643 1.2. The ASN.1 DER encoded signedAttributes (including messageDigest,
644 receiptRequest and, possibly, other signed attributes) in the original
645 signedData signerInfo are digested as described in [CMS]. The resulting
646 digest value, called msgSigDigest, is then used to verify the signature
647 of the original signedData signerInfo. If the signature verification
648 fails, then the signedData/Receipt MUST NOT be created.
650 2. A Receipt structure is created.
652 2.1. The value of the Receipt version field is set to 1.
654 2.2. The object identifier from the contentType attribute included in
655 the original signedData signerInfo that includes the receiptRequest
656 attribute is copied into the Receipt contentType.
658 2.3. The original signedData signerInfo receiptRequest
659 signedContentIdentifier is copied into the Receipt
660 signedContentIdentifier.
662 2.4. The signature value from the original signedData signerInfo that
663 includes the receiptRequest attribute is copied into the Receipt
664 originatorSignatureValue.
666 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
668 4. D1 is digested. The resulting digest value is included as the
669 messageDigest attribute in the signedAttributes of the signerInfo which
670 will eventually contain the signedData/Receipt signature value.
672 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
673 signature of the original signedData signerInfo is included as the
674 msgSigDigest attribute in the signedAttributes of the signerInfo which will
675 eventually contain the signedData/Receipt signature value.
677 6. A contentType attribute including the id-ct-receipt object identifier
678 MUST be created and added to the signed attributes of the signerInfo which
679 will eventually contain the signedData/Receipt signature value.
681 7. A signingTime attribute indicating the time that the signedData/Receipt
682 is signed SHOULD be created and added to the signed attributes of the
683 signerInfo which will eventually contain the signedData/Receipt signature
684 value. Other attributes (except receiptRequest) may be added to the
685 signedAttributes of the signerInfo.
687 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
688 possibly, others) of the signerInfo are ASN.1 DER encoded and digested as
689 described in CMS, Section 5.3. The resulting digest value is used to
690 calculate the signature value which is then included in the
691 signedData/Receipt signerInfo.
693 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
694 the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
695 id-ct-receipt object identifier MUST be included in the signedData
696 encapContentInfo eContentType. This results in a single ASN.1 encoded
697 object composed of a signedData including the Receipt content. The Data
698 content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
699 in a MIME header or any other header prior to being encoded as part of the
700 signedData object.
702 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
703 wrapper with the smime-type parameter set to "signed-receipt". This will
704 allow for identification of signed receipts without having to crack the
705 ASN.1 body. The smime-type parameter would still be set as normal in any
706 layer wrapped around this message.
708 11. If the signedData/Receipt is to be encrypted within an envelopedData
709 object, then an outer signedData object MUST be created that encapsulates
710 the envelopedData object, and a contentHints attribute with contentType set
711 to the id-ct-receipt object identifier MUST be included in the outer
712 signedData SignerInfo signedAttributes. When a receiving agent processes
713 the outer signedData object, the presence of the id-ct-receipt OID in the
714 contentHints contentType indicates that a signedData/Receipt is encrypted
715 within the envelopedData object encapsulated by the outer signedData.
717 All agents that support the generation of ESS signed receipts MUST provide
718 the ability to send encrypted signed receipts (that is, a
719 signedData/Receipt encapsulated within an envelopedData). The agent MAY
720 send an encrypted signed receipt in response to an
721 envelopedData-encapsulated signedData requesting a signed receipt. It is a
722 matter of local policy regarding whether or not the signed receipt should
723 be encrypted. The ESS signed receipt includes the message digest value
724 calculated for the original signedData object that requested the signed
725 receipt. If the original signedData object was sent encrypted within an
726 envelopedData object and the ESS signed receipt is sent unencrypted, then
727 the message digest value calculated for the original encrypted signedData
728 object is sent unencrypted. The responder should consider this when
729 deciding whether or not to encrypt the ESS signed receipt.
731 2.4.1 MLExpansionHistory Attributes and Receipts
733 An MLExpansionHistory attribute MUST NOT be included in the attributes of a
734 SignerInfo in a SignedData object that encapsulates a Receipt content. This
735 is true because when a SignedData/Receipt is sent to an MLA for
736 distribution, then the MLA must always encapsulate the received
737 SignedData/Receipt in an outer SignedData in which the MLA will include the
738 MLExpansionHistory attribute. The MLA cannot change the signedAttributes of
739 the received SignedData/Receipt object, so it can't add the
740 MLExpansionHistory to the SignedData/Receipt.
742 2.5 Determining the Recipients of the Signed Receipt
744 If a signed receipt was created by the process described in the sections
745 above, then the software MUST use the following process to determine to
746 whom the signed receipt should be sent.
748 1. The receiptsTo field must be present in the receiptRequest attribute.
749 The software initiates the sequence of recipients with the value(s) of
750 receiptsTo.
752 2. If the MlExpansionHistory attribute is present in the outer SignedData
753 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
754 then the software replaces the sequence of recipients with the value(s) of
755 insteadOf.
757 3. If the MlExpansionHistory attribute is present in the outer SignedData
758 block and the last MLData contains an MLReceiptPolicy value of
759 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
760 sequence of recipients.
762 2.6. Signed Receipt Validation
764 A signed receipt is communicated as a single ASN.1 encoded object composed
765 of a signedData object directly including a Receipt content. It is
766 identified by the presence of the id-ct-receipt object identifier in the
767 encapContentInfo eContentType value of the signedData object including the
768 Receipt content.
770 A signedData/Receipt is validated as follows:
772 1. ASN.1 decode the signedData object including the Receipt content.
774 2. Extract the contentType, signedContentIdentifier, and
775 originatorSignatureValue from the decoded Receipt structure to identify the
776 original signedData signerInfo that requested the signedData/Receipt.
778 3. Acquire the message signature digest value calculated by the sender to
779 generate the signature value included in the original signedData signerInfo
780 that requested the signedData/Receipt.
782 3.1. If the sender-calculated message signature digest value has been
783 saved locally by the sender, it must be located and retrieved.
785 3.2. If it has not been saved, then it must be re-calculated based on
786 the original signedData content and signedAttributes as described in
787 [CMS].
789 4. The message signature digest value calculated by the sender is then
790 compared with the value of the msgSigDigest signedAttribute included in the
791 signedData/Receipt signerInfo. If these digest values are identical, then
792 that proves that the message signature digest value calculated by the
793 recipient based on the received original signedData object is the same as
794 that calculated by the sender. This proves that the recipient received
795 exactly the same original signedData content and signedAttributes as sent
796 by the sender because that is the only way that the recipient could have
797 calculated the same message signature digest value as calculated by the
798 sender. If the digest values are different, then the signedData/Receipt
799 signature verification process fails.
801 5. Acquire the digest value calculated by the sender for the Receipt
802 content constructed by the sender (including the contentType,
803 signedContentIdentifier, and signature value that were included in the
804 original signedData signerInfo that requested the signedData/Receipt).
806 5.1. If the sender-calculated Receipt content digest value has been
807 saved locally by the sender, it must be located and retrieved.
809 5.2. If it has not been saved, then it must be re-calculated. As
810 described in section 2.4 above, step 2, create a Receipt structure
811 including the contentType, signedContentIdentifier and signature value
812 that were included in the original signedData signerInfo that requested
813 the signed receipt. The Receipt structure is then ASN.1 DER encoded to
814 produce a data stream which is then digested to produce the Receipt
815 content digest value.
817 6. The Receipt content digest value calculated by the sender is then
818 compared with the value of the messageDigest signedAttribute included in
819 the signedData/Receipt signerInfo. If these digest values are identical,
820 then that proves that the values included in the Receipt content by the
821 recipient are identical to those that were included in the original
822 signedData signerInfo that requested the signedData/Receipt. This proves
823 that the recipient received the original signedData signed by the sender,
824 because that is the only way that the recipient could have obtained the
825 original signedData signerInfo signature value for inclusion in the Receipt
826 content. If the digest values are different, then the signedData/Receipt
827 signature verification process fails.
829 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
830 signerInfo are digested as described in [CMS].
832 8. The resulting digest value is then used to verify the signature value
833 included in the signedData/Receipt signerInfo. If the signature
834 verification is successful, then that proves the integrity of the
835 signedData/receipt signerInfo signedAttributes and authenticates the
836 identity of the signer of the signedData/Receipt signerInfo. Note that the
837 signedAttributes include the recipient-calculated Receipt content digest
838 value (messageDigest attribute) and recipient-calculated message signature
839 digest value (msgSigDigest attribute). Therefore, the aforementioned
840 comparison of the sender-generated and recipient-generated digest values
841 combined with the successful signedData/Receipt signature verification
842 proves that the recipient received the exact original signedData content
843 and signedAttributes (proven by msgSigDigest attribute) that were signed by
844 the sender of the original signedData object (proven by messageDigest
845 attribute). If the signature verification fails, then the
846 signedData/Receipt signature verification process fails.
848 The signature verification process for each signature algorithm that is
849 used in conjunction with the CMS protocol is specific to the algorithm.
850 These processes are described in documents specific to the algorithms.
852 2.7 Receipt Request Syntax
854 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
855 receiptRequest attribute only within the signed attributes associated with
856 a signed message.
858 ReceiptRequest ::= SEQUENCE {
859 signedContentIdentifier ContentIdentifier,
860 receiptsFrom ReceiptsFrom,
861 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
863 ub-receiptsTo INTEGER ::= 16
865 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
866 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
868 ContentIdentifier ::= OCTET STRING
870 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
871 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
873 A signedContentIdentifier MUST be created by the message originator when
874 creating a receipt request. To ensure global uniqueness, the minimal
875 signedContentIdentifier SHOULD contain a concatenation of user-specific
876 identification information (such as a user name or public keying material
877 identification information), a GeneralizedTime string, and a random number.
879 The receiptsFrom field is used by the originator to specify the recipients
880 requested to return a signed receipt. A CHOICE is provided to allow
881 specification of:
882 - receipts from all recipients are requested
883 - receipts from first tier (recipients that did not receive the
884 message as members of a mailing list) recipients are requested
885 - receipts from a specific list of recipients are requested
887 ReceiptsFrom ::= CHOICE {
888 allOrFirstTier [0] AllOrFirstTier,
889 -- formerly "allOrNone [0]AllOrNone"
890 receiptList [1] SEQUENCE OF GeneralNames }
892 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
893 allReceipts (0),
894 firstTierRecipients (1) }
896 The receiptsTo field is used by the originator to identify the user(s) to
897 whom the identified recipient should send signed receipts. The message
898 originator MUST populate the receiptsTo field with a GeneralNames for each
899 entity to whom the recipient should send the signed receipt. If the message
900 originator wants the recipient to send the signed receipt to the
901 originator, then the originator MUST include a GeneralNames for itself in
902 the receiptsTo field.
904 2.8 Receipt Syntax
906 Receipts are represented using a new content type, Receipt. The Receipt
907 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
908 within a SignedData message.
910 Receipt ::= SEQUENCE {
911 version Version, -- Version is imported from [CMS]
912 contentType ContentType,
913 signedContentIdentifier ContentIdentifier,
914 originatorSignatureValue OCTET STRING }
916 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
917 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
919 The version field defines the syntax version number, which is 1 for this
920 version of the standard.
922 2.9 Content Hints
924 Many applications find it useful to have information that describes the
925 innermost signed content of a multi-layer message available on the
926 outermost signature layer. The contentHints attribute provides such
927 information.
929 Content-hints attribute values have ASN.1 type contentHints.
931 ContentHints ::= SEQUENCE {
932 contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
933 contentType ContentType }
935 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
936 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
938 The contentDescription field may be used to provide information that the
939 recipient may use to select protected messages for processing, such as a
940 message subject. If this field is set, then the attribute is expected to
941 appear on the signedData object enclosing an envelopedData object and not
942 on the inner signedData object. The SIZE (1..MAX) construct constrains the
943 sequence to have at least one entry. MAX indicates the upper bound is
944 unspecified. Implementations are free to choose an upper bound that suits
945 their environment.
947 Messages which contain a signedData object wrapped around an envelopedData
948 object, thus masking the inner content type of the message, SHOULD include
949 a contentHints attribute, except for the case of the data content type.
950 Specific message content types may either force or preclude the inclusion
951 of the contentHints attribute. For example, when a signedData/Receipt is
952 encrypted within an envelopedData object, an outer signedData object MUST
953 be created that encapsulates the envelopedData object and a contentHints
954 attribute with contentType set to the id-ct-receipt object identifier MUST
955 be included in the outer signedData SignerInfo signedAttributes.
957 2.10 Message Signature Digest Attribute
959 The msgSigDigest attribute can only be used in the signed attributes of a
960 signed receipt. It contains the digest of the ASN.1 DER encoded
961 signedAttributes included in the original signedData that requested the
962 signed receipt. Only one msgSigDigest attribute can appear in an signed
963 attributes set. It is defined as follows:
965 msgSigDigest ::= OCTET STRING
967 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
968 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
970 2.11 Signed Content Reference Attribute
972 The contentReference attribute is a link from one SignedData to another. It
973 may be used to link a reply to the original message to which it refers, or
974 to incorporate by reference one SignedData into another. The first
975 SignedData MUST include a contentIdentifier signed attribute, which SHOULD
976 be constructed as specified in section 2.7. The second SignedData links to
977 the first by including a ContentReference signed attribute containing the
978 content type, content identifier, and signature value from the first
979 SignedData.
981 ContentReference ::= SEQUENCE {
982 contentType ContentType,
983 signedContentIdentifier ContentIdentifier,
984 originatorSignatureValue OCTET STRING }
986 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
987 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
989 3. Security Labels
991 This section describes the syntax to be used for security labels that can
992 optionally be associated with S/MIME encapsulated data. A security label is
993 a set of security information regarding the sensitivity of the content that
994 is protected by S/MIME encapsulation.
996 "Authorization" is the act of granting rights and/or privileges to users
997 permitting them access to an object. "Access control" is a means of
998 enforcing these authorizations. The sensitivity information in a security
999 label can be compared with a user's authorizations to determine if the user
1000 is allowed to access the content that is protected by S/MIME encapsulation.
1002 Security labels may be used for other purposes such as a source of routing
1003 information. The labels are often priority based ("secret", "confidential",
1004 "restricted", and so on) or role-based, describing which kind of people can
1005 see the information ("patient's health-care team", "medical billing
1006 agents", "unrestricted", and so on).
1008 3.1 Security Label Processing Rules
1010 A sending agent may include a security label attribute in the signed
1011 attributes of a signedData object. A receiving agent examines the security
1012 label on a received message and determines whether or not the recipient is
1013 allowed to see the contents of the message.
1015 3.1.1 Adding Security Labels
1017 A sending agent that is using security labels MUST put the security label
1018 attribute in the signedAttributes field of a SignerInfo block. The security
1019 label attribute MUST NOT be included in the unsigned attributes. Integrity
1020 and authentication security services MUST be applied to the security label,
1021 therefore it MUST be included as an signed attribute, if used. This causes
1022 the security label attribute to be part of the data that is hashed to form
1023 the SignerInfo signature value. A SignerInfo block MUST NOT have more than
1024 one security label signed attribute.
1026 When there are multiple SignedData blocks applied to a message, a security
1027 label attribute may be included in either the inner signature, outer
1028 signature, or both. A security label signed attribute may be included in a
1029 signedAttributes field within the inner SignedData block. The inner
1030 security label will include the sensitivities of the original content and
1031 will be used for access control decisions related to the plaintext
1032 encapsulated content. The inner signature provides authentication of the
1033 inner security label and cryptographically protects the original signer's
1034 inner security label of the original content.
1036 When the originator signs the plaintext content and signed attributes, the
1037 inner security label is bound to the plaintext content. An intermediate
1038 entity cannot change the inner security label without invalidating the
1039 inner signature. The confidentiality security service can be applied to the
1040 inner security label by encrypting the entire inner signedData object
1041 within an EnvelopedData block.
1043 A security label signed attribute may also be included in a
1044 signedAttributes field within the outer SignedData block. The outer
1045 security label will include the sensitivities of the encrypted message and
1046 will be used for access control decisions related to the encrypted message
1047 and for routing decisions. The outer signature provides authentication of
1048 the outer security label (as well as for the encapsulated content which may
1049 include nested S/MIME messages).
1051 There can be multiple SignerInfos within a SignedData object, and each
1052 SignerInfo may include signedAttributes. Therefore, a single SignedData
1053 object may include multiple eSSSecurityLabels, each SignerInfo having an
1054 eSSSecurityLabel attribute. For example, an originator can send a signed
1055 message with two SignerInfos, one containing a DSS signature, the other
1056 containing an RSA signature. If any of the SignerInfos included in a
1057 SignedData object include an eSSSecurityLabel attribute, then all of the
1058 SignerInfos in that SignedData object MUST include an eSSSecurityLabel
1059 attribute and the value of each MUST be identical.
1061 3.1.2 Processing Security Labels
1063 Before processing an eSSSecurityLabel signedAttribute, the receiving agent
1064 MUST verify the signature of the SignerInfo which covers the
1065 eSSSecurityLabel attribute. A recipient MUST NOT process an
1066 eSSSecurityLabel attribute that has not been verified.
1068 A receiving agent MUST process the eSSSecurityLabel attribute, if present,
1069 in each SignerInfo in the SignedData object for which it verifies the
1070 signature. This may result in the receiving agent processing multiple
1071 eSSSecurityLabels included in a single SignedData object. Because all
1072 eSSSecurityLabels in a SignedData object must be identical, the receiving
1073 agent processes (such as performing access control) on the first
1074 eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
1075 then ensures that all other eSSSecurityLabels in signerInfos that it
1076 verifies are identical to the first one encountered. If the
1077 eSSSecurityLabels in the signerInfos that it verifies are not all
1078 identical, then the receiving agent MUST warn the user of this condition.
1080 Receiving agents SHOULD have a local policy regarding whether or not to
1081 show the inner content of a signedData object that includes an
1082 eSSSecurityLabel security-policy-identifier that the processing software
1083 does not recognize. If the receiving agent does not recognize the
1084 eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
1085 processing the message and indicate an error.
1087 3.2 Syntax of eSSSecurityLabel
1089 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
1090 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
1091 ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
1092 [MSP4].
1094 ESSSecurityLabel ::= SET {
1095 security-policy-identifier SecurityPolicyIdentifier,
1096 security-classification SecurityClassification OPTIONAL,
1097 privacy-mark ESSPrivacyMark OPTIONAL,
1098 security-categories SecurityCategories OPTIONAL }
1100 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1101 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
1103 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1105 SecurityClassification ::= INTEGER {
1106 unmarked (0),
1107 unclassified (1),
1108 restricted (2),
1109 confidential (3),
1110 secret (4),
1111 top-secret (5) } (0..ub-integer-options)
1113 ub-integer-options INTEGER ::= 256
1115 ESSPrivacyMark ::= CHOICE {
1116 pString PrintableString SIZE (1..ub-privacy-mark-length),
1117 utf8String UTF8String SIZE (1..MAX)
1118 }
1120 ub-privacy-mark-length INTEGER ::= 128
1122 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1123 SecurityCategory
1125 ub-security-categories INTEGER ::= 64
1127 SecurityCategory ::= SEQUENCE {
1128 type [0] OBJECT IDENTIFIER,
1129 value [1] ANY DEFINED BY type -- defined by type
1130 }
1132 --Note: The aforementioned SecurityCategory syntax produces identical
1133 --hex encodings as the following SecurityCategory syntax that is
1134 --documented in the X.411 specification:
1135 --
1136 --SecurityCategory ::= SEQUENCE {
1137 -- type [0] SECURITY-CATEGORY,
1138 -- value [1] ANY DEFINED BY type }
1139 --
1140 --SECURITY-CATEGORY MACRO ::=
1141 --BEGIN
1142 --TYPE NOTATION ::= type | empty
1143 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1144 --END
1146 3.3 Security Label Components
1148 This section gives more detail on the the various components of the
1149 eSSSecurityLabel syntax.
1151 3.3.1 Security Policy Identifier
1153 A security policy is a set of criteria for the provision of security
1154 services. The eSSSecurityLabel security-policy-identifier is used to
1155 identify the security policy in force to which the security label relates.
1156 It indicates the semantics of the other security label components.
1158 3.3.2 Security Classification
1160 This specification defines the use of the Security Classification field
1161 exactly as is specified in the X.411 Recommendation, which states in part:
1163 If present, a security-classification may have one of a hierarchical
1164 list of values. The basic security-classification hierarchy is defined
1165 in this Recommendation, but the use of these values is defined by the
1166 security-policy in force. Additional values of security-classification,
1167 and their position in the hierarchy, may also be defined by a
1168 security-policy as a local matter or by bilateral agreement. The basic
1169 security-classification hierarchy is, in ascending order: unmarked,
1170 unclassified, restricted, confidential, secret, top-secret.
1172 This means that the security policy in force (identified by the
1173 eSSSecurityLabel security-policy-identifier) defines the
1174 SecurityClassification integer values and their meanings.
1176 An organization can develop its own security policy that defines the
1177 SecurityClassification INTEGER values and their meanings. However, the
1178 general interpretation of the X.411 specification is that the values of 0
1179 through 5 are reserved for the "basic hierarchy" values of unmarked,
1180 unclassified, restricted, confidential, secret, and top-secret. Note that
1181 X.411 does not provide the rules for how these values are used to label
1182 data and how access control is performed using these values.
1184 There is no universal definition of the rules for using these "basic
1185 hierarchy" values. Each organization (or group of organizations) will
1186 define a security policy which documents how the "basic hierarchy" values
1187 are used (if at all) and how access control is enforced (if at all) within
1188 their domain.
1190 Therefore, the security-classification value MUST be accompanied by a
1191 security-policy-identifier value to define the rules for its use. For
1192 example, a company's "secret" classification may convey a different meaning
1193 than the US Government "secret" classification. In summary, a security
1194 policy SHOULD NOT use integers 0 through 5 for other than their X.411
1195 meanings, and SHOULD instead use other values in a hierarchical fashion.
1197 Note that the set of valid security-classification values MUST be
1198 hierarchical, but these values do not necessarily need to be in ascending
1199 numerical order. Further, the values do not need to be contiguous.
1201 For example, in the Defense Message System 1.0 security policy, the
1202 security-classification value of 11 indicates Sensitive-But-Unclassified
1203 and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret
1204 as more sensitive than Sensitive-But-Unclassified even though the numerical
1205 value of top-secret is less than Sensitive-But-Unclassified.
1207 (Of course, if security-classification values are both hierarchical and in
1208 ascending order, a casual reader of the security policy is more likely to
1209 understand it.)
1211 An example of a security policy that does not use any of the X.411 values
1212 might be:
1213 10 -- anyone
1214 15 -- Morgan Corporation and its contractors
1215 20 -- Morgan Corporation employees
1216 25 -- Morgan Corporation board of directors
1218 An example of a security policy that uses part of the X.411 hierarchy might
1219 be:
1220 0 -- unmarked
1221 1 -- unclassified, can be read by everyone
1222 2 -- restricted to Timberwolf Productions staff
1223 6 -- can only be read to Timberwolf Productions executives
1225 3.3.3 Privacy Mark
1227 If present, the eSSSecurityLabel privacy-mark is not used for access
1228 control. The content of the eSSSecurityLabel privacy-mark may be defined by
1229 the security policy in force (identified by the eSSSecurityLabel
1230 security-policy-identifier) which may define a list of values to be used.
1231 Alternately, the value may be determined by the originator of the
1232 security-label.
1234 3.3.4 Security Categories
1236 If present, the eSSSecurityLabel security-categories provide further
1237 granularity for the sensitivity of the message. The security policy in
1238 force (identified by the eSSSecurityLabel security-policy-identifier) is
1239 used to indicate the syntaxes that are allowed to be present in the
1240 eSSSecurityLabel security-categories. Alternately, the security-categories
1241 and their values may be defined by bilateral agreement.
1243 3.4 Equivalent Security Labels
1245 Because organizations are allowed to define their own security policies,
1246 many different security policies will exist. Some organizations may wish to
1247 create equivalencies between their security policies with the security
1248 policies of other organizations. For example, the Acme Company and the
1249 Widget Corporation may reach a bilateral agreement that the "Acme private"
1250 security-classification value is equivalent to the "Widget sensitive"
1251 security-classification value.
1253 Receiving agents MUST NOT process an equivalentLabels attribute in a
1254 message if the agent does not trust the signer of that attribute to
1255 translate the original eSSSecurityLabel values to the security policy
1256 included in the equivalentLabels attribute. Receiving agents have the
1257 option to process equivalentLabels attributes but do not have to. It is
1258 acceptable for a receiving agent to only process eSSSecurityLabels. All
1259 receiving agents SHOULD recognize equivalentLabels attributes even if they
1260 do not process them.
1262 3.4.1 Creating Equivalent Labels
1264 The EquivalentLabels signed attribute is defined as:
1266 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
1268 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1269 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
1271 As stated earlier, the ESSSecurityLabel contains the sensitivity values
1272 selected by the original signer of the signedData. If an ESSSecurityLabel
1273 is present in a signerInfo, all signerInfos in the signedData MUST contain
1274 an ESSSecurityLabel and they MUST all be identical. In addition to an
1275 ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed
1276 attribute. If present, the equivalentLabels attribute MUST include one or
1277 more security labels that are believed by the signer to be semantically
1278 equivalent to the ESSSecurityLabel attribute included in the same
1279 signerInfo.
1281 All security-policy object identifiers MUST be unique in the set of
1282 ESSSecurityLabel and EquivalentLabels security labels. Before using an
1283 EquivalentLabels attribute, an agent MUST ensure that all security-policy
1284 OIDs are unique in the security label or labels included in the
1285 EquivalentLabels. Once the agent selects the security label (within the
1286 EquivalentLabels) to be used for processing, then the security-policy OID
1287 of the selected EquivalentLabels security label MUST be compared with the
1288 ESSSecurityLabel security-policy OID to ensure that they are unique.
1290 In the case that an ESSSecurityLabel attribute is not included in a
1291 signerInfo, then an EquivalentLabels attribute may still be included. For
1292 example, in the Acme security policy, the absence of an ESSSecurityLabel
1293 could be defined to equate to a security label composed of the Acme
1294 security-policy OID and the "unmarked" security-classification.
1296 Note that equivalentLabels MUST NOT be used to convey security labels that
1297 are semantically different from the ESSSecurityLabel included in the
1298 signerInfos in the signedData. If an entity needs to apply a security label
1299 that is semantically different from the ESSSecurityLabel, then it MUST
1300 include the sematically different security label in an outer signedData
1301 object that encapsulates the signedData object that includes the
1302 ESSSecurityLabel.
1304 If present, the equivalentLabels attribute MUST be an signed attribute; it
1305 MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF
1306 Attribute. A signerInfo MUST NOT include multiple instances of the
1307 equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
1308 attributes to include attrValues SET OF AttributeValue. A equivalentLabels
1309 attribute MUST only include a single instance of AttributeValue. There MUST
1310 NOT be zero or multiple instances of AttributeValue present in the
1311 attrValues SET OF AttributeValue.
1313 3.4.2 Processing Equivalent Labels
1315 A receiving agent SHOULD process the ESSSecurityLabel before processing any
1316 EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
1317 the receiving agent, it MUST process that label and MUST ignore all
1318 EquivalentLabels.
1320 When processing an EquivalentLabels attribute, the receiving agent MUST
1321 validate the signature on the EquivalentLabels attribute. A receiving agent
1322 MUST NOT act on an equivalentLabels attribute for which the signature could
1323 not be validated, and MUST NOT act on an equivalentLabels attribute unless
1324 that attribute is signed by an entity trusted to translate the original
1325 eSSSecurityLabel values to the security policy included in the
1326 equivalentLabels attribute. Determining who is allowed to specify
1327 equivalence mappings is a local policy. If a message has more than one
1328 EquivalentLabels attribute, the receiving agent SHOULD process the first
1329 one that it reads and validates that contains the security policy of
1330 interest to the receiving agent.
1332 4. Mail List Management
1334 Sending agents must create recipient-specific data structures for each
1335 recipient of an encrypted message. This process can impair performance for
1336 messages sent to a large number of recipients. Thus, Mail List Agents
1337 (MLAs) that can take a single message and perform the recipient-specific
1338 encryption for every recipient are often desired.
1340 An MLA appears to the message originator as a normal message recipient, but
1341 the MLA acts as a message expansion point for a Mail List (ML). The sender
1342 of a message directs the message to the MLA, which then redistributes the
1343 message to the members of the ML. This process offloads the per-recipient
1344 processing from individual user agents and allows for more efficient
1345 management of large MLs. MLs are true message recipients served by MLAs
1346 that provide cryptographic and expansion services for the mailing list.
1348 In addition to cryptographic handling of messages, secure mailing lists
1349 also have to prevent mail loops. A mail loop is where one mailing list is a
1350 member of a second mailing list, and the second mailing list is a member of
1351 the first. A message will go from one list to the other in a
1352 rapidly-cascading succession of mail that will be distributed to all other
1353 members of both lists.
1355 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
1356 outer signature of a triple wrapped message. The mlExpansionHistory
1357 attribute is essentially a list of every MLA that has processed the
1358 message. If an MLA sees its own unique entity identifier in the list, it
1359 knows that a loop has been formed, and does not send the message to the
1360 list again.
1362 4.1 Mail List Expansion
1364 Mail list expansion processing is noted in the value of the
1365 mlExpansionHistory attribute, located in the signed attributes of the MLA's
1366 SignerInfo block. The MLA creates or updates the signed mlExpansionHistory
1367 attribute value each time the MLA expands and signs a message for members
1368 of a mail list.
1370 The MLA MUST add an MLData record containing the MLA's identification
1371 information, date and time of expansion, and optional receipt policy to the
1372 end of the mail list expansion history sequence. If the mlExpansionHistory
1373 attribute is absent, then the MLA MUST add the attribute and the current
1374 expansion becomes the first element of the sequence. If the
1375 mlExpansionHistory attribute is present, then the MLA MUST add the current
1376 expansion information to the end of the existing MLExpansionHistory
1377 sequence. Only one mlExpansionHistory attribute can be included in the
1378 signedAttributes of a SignerInfo.
1380 Note that if the mlExpansionHistory attribute is absent, then the recipient
1381 is a first tier message recipient.
1383 There can be multiple SignerInfos within a SignedData object, and each
1384 SignerInfo may include signedAttributes. Therefore, a single SignedData
1385 object may include multiple SignerInfos, each SignerInfo having a
1386 mlExpansionHistory attribute. For example, an MLA can send a signed message
1387 with two SignerInfos, one containing a DSS signature, the other containing
1388 an RSA signature.
1390 If an MLA creates a SignerInfo that includes an mlExpansionHistory
1391 attribute, then all of the SignerInfos created by the MLA for that
1392 SignedData object MUST include an mlExpansionHistory attribute, and the
1393 value of each MUST be identical. Note that other agents might later add
1394 SignerInfo attributes to the SignedData block, and those additional
1395 SignerInfos might not include mlExpansionHistory attributes.
1397 A recipient MUST verify the signature of the SignerInfo which covers the
1398 mlExpansionHistory attribute before processing the mlExpansionHistory, and
1399 MUST NOT process the mlExpansionHistory attribute unless the signature over
1400 it has been verified. If a SignedData object has more than one SignerInfo
1401 that has an mlExpansionHistory attribute, the recipient MUST compare the
1402 mlExpansionHistory attributes in all the SignerInfos that it has verified,
1403 and MUST NOT process the mlExpansionHistory attribute unless every verified
1404 mlExpansionHistory attribute in the SignedData block is identical. If the
1405 mlExpansionHistory attributes in the verified signerInfos are not all
1406 identical, then the receiving agent MUST stop processing the message and
1407 SHOULD notify the user or MLA administrator of this error condition. In the
1408 mlExpansionHistory processing, SignerInfos that do not have an
1409 mlExpansionHistory attribute are ignored.
1411 4.1.1 Detecting Mail List Expansion Loops
1413 Prior to expanding a message, the MLA examines the value of any existing
1414 mail list expansion history attribute to detect an expansion loop. An
1415 expansion loop exists when a message expanded by a specific MLA for a
1416 specific mail list is redelivered to the same MLA for the same mail list.
1418 Expansion loops are detected by examining the mailListIdentifier field of
1419 each MLData entry found in the mail list expansion history. If an MLA finds
1420 its own identification information, then the MLA must discontinue expansion
1421 processing and should provide warning of an expansion loop to a human mail
1422 list administrator. The mail list administrator is responsible for
1423 correcting the loop condition.
1425 4.2 Mail List Agent Processing
1427 The first few paragraphs of this section provide a high-level description
1428 of MLA processing. The rest of the section provides a detailed description
1429 of MLA processing.
1431 MLA message processing depends on the structure of the S/MIME layers in the
1432 message sent to the MLA for expansion. In addition to sending triple
1433 wrapped messages to an MLA, an entity can send other types of messages to
1434 an MLA, such as:
1435 - a single wrapped signedData or envelopedData message
1436 - a double wrapped message (such as signed and enveloped, enveloped and
1437 signed, or signed and signed, and so on)
1438 - a quadruple-wrapped message (such as if a well-formed triple wrapped
1439 message was sent through a gateway that added an outer SignedData layer)
1441 In all cases, the MLA MUST parse all layers of the received message to
1442 determine if there are any signedData layers that include an
1443 eSSSecurityLabel signedAttribute. This may include decrypting an
1444 EnvelopedData layer to determine if an encapsulated SignedData layer
1445 includes an eSSSecurityLabel attribute. The MLA MUST fully process each
1446 eSSSecurityLabel attribute found in the various signedData layers,
1447 including performing access control checks, before distributing the message
1448 to the ML members. The details of the access control checks are beyond the
1449 scope of this document. The MLA MUST verify the signature of the signerInfo
1450 including the eSSSecurityLabel attribute before using it.
1452 In all cases, the MLA MUST sign the message to be sent to the ML members in
1453 a new "outer" signedData layer. The MLA MUST add or update an
1454 mlExpansionHistory attribute in the "outer" signedData that it creates to
1455 document MLA processing. If there was an "outer" signedData layer included
1456 in the original message received by the MLA, then the MLA-created "outer"
1457 signedData layer MUST include each signed attribute present in the
1458 original "outer" signedData layer, unless the MLA explicitly replaces an
1459 attribute (such as signingTime or mlExpansionHistory) with a new value.
1461 When an S/MIME message is received by the MLA, the MLA MUST first determine
1462 which received signedData layer, if any, is the "outer" signedData layer.
1463 To identify the received "outer" signedData layer, the MLA MUST verify the
1464 signature and fully process the signedAttributes in each of the
1465 outer signedData layers (working from the outside in) to determine if any
1466 of them either include an mlExpansionHistory attribute or encapsulate an
1467 envelopedData object.
1469 The MLA's search for the "outer" signedData layer is completed when it
1470 finds one of the following:
1471 - the "outer" signedData layer that includes an mlExpansionHistory
1472 attribute or encapsulates an envelopedData object
1473 - an envelopedData layer
1474 - the original content (that is, a layer that is neither envelopedData nor
1475 signedData).
1477 If the MLA finds an "outer" signedData layer, then the MLA MUST perform
1478 the following steps:
1480 1. Strip off all of the signedData layers that encapsulated the "outer"
1481 signedData layer
1483 2. Strip off the "outer" signedData layer itself (after remembering the
1484 included signedAttributes)
1486 3. Expand the envelopedData (if present)
1488 4. Sign the message to be sent to the ML members in a new "outer"
1489 signedData layer that includes the signedAttributes (unless explicitly
1490 replaced) from the original, received "outer" signedData layer.
1492 If the MLA finds an "outer" signedData layer that includes an
1493 mlExpansionHistory attribute AND the MLA subsequently finds an
1494 envelopedData layer buried deeper with the layers of the received message,
1495 then the MLA MUST strip off all of the signedData layers down to the
1496 envelopedData layer (including stripping off the original "outer"
1497 signedData layer) and MUST sign the expanded envelopedData in a new "outer"
1498 signedData layer that includes the signedAttributes (unless explicitly
1499 replaced) from the original, received "outer" signedData layer.
1501 If the MLA does not find an "outer" signedData layer AND does not find an
1502 envelopedData layer, then the MLA MUST sign the original, received message
1503 in a new "outer" signedData layer. If the MLA does not find an "outer"
1504 signedData AND does find an envelopedData layer then it MUST expand the
1505 envelopedData layer, if present, and sign it in a new "outer" signedData
1506 layer.
1508 4.2.1 Examples of Rule Processing
1510 The following examples help explain the rules above:
1512 1) A message (S1(Original Content)) (where S = SignedData) is sent to the
1513 MLA in which the signedData layer does not include an MLExpansionHistory
1514 attribute. The MLA verifies and fully processes the signedAttributes in S1.
1515 The MLA decides that there is not an original, received "outer" signedData
1516 layer since it finds the original content, but never finds an envelopedData
1517 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1518 signedData layer, S2, resulting in the following message sent to the ML
1519 recipients: (S2(S1(Original Content))). The MLA includes an
1520 mlExpansionHistory attribute in S2.
1522 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which
1523 none of the signedData layers includes an MLExpansionHistory attribute. The
1524 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The
1525 MLA decides that there is not an original, received "outer" signedData
1526 layer since it finds the original content, but never finds an envelopedData
1527 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1528 signedData layer, S4, resulting in the following message sent to the ML
1529 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an
1530 mlExpansionHistory attribute in S4.
1532 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent
1533 to the MLA in which S1 does not include an MLExpansionHistory attribute.
1534 The MLA decides that there is not an original, received "outer" signedData
1535 layer since it finds the E1 as the outer layer. The MLA expands the
1536 recipientInformation in E1. The MLA calculates a new signedData layer, S2,
1537 resulting in the following message sent to the ML recipients:
1538 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory
1539 attribute in S2.
1541 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
1542 includes an MLExpansionHistory attribute. The MLA verifies the signature
1543 and fully processes the signedAttributes in S2. The MLA finds the
1544 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
1545 signedData. The MLA remembers the signedAttributes included in S2 for later
1546 inclusion in the new outer signedData that it applies to the message. The
1547 MLA strips off S2. The MLA then expands the recipientInformation in E1
1548 (this invalidates the signature in S2 which is why it was stripped). The
1549 MLA calculates a new signedData layer, S3, resulting in the following
1550 message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA
1551 includes in S3 the attributes from S2 (unless it specifically replaces an
1552 attribute value) including an updated mlExpansionHistory attribute.
1554 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1555 none of the signedData layers include an MLExpansionHistory attribute. The
1556 MLA verifies the signature and fully processes the signedAttributes in S3
1557 and S2. When the MLA encounters E1, then it decides that S2 is the "outer"
1558 signedData since S2 encapsulates E1. The MLA remembers the signedAttributes
1559 included in S2 for later inclusion in the new outer signedData that it
1560 applies to the message. The MLA strips off S3 and S2. The MLA then expands
1561 the recipientInformation in E1 (this invalidates the signatures in S3 and
1562 S2 which is why they were stripped). The MLA calculates a new signedData
1563 layer, S4, resulting in the following message sent to the ML recipients:
1564 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1565 S2 (unless it specifically replaces an attribute value) and includes a new
1566 mlExpansionHistory attribute.
1568 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1569 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
1570 the signature and fully processes the signedAttributes in S3. The MLA finds
1571 the mlExpansionHistory in S3, so it decides that S3 is the "outer"
1572 signedData. The MLA remembers the signedAttributes included in S3 for later
1573 inclusion in the new outer signedData that it applies to the message. The
1574 MLA keeps on parsing encapsulated layers because it must determine if there
1575 are any eSSSecurityLabel attributes contained within. The MLA verifies the
1576 signature and fully processes the signedAttributes in S2. When the MLA
1577 encounters E1, then it strips off S3 and S2. The MLA then expands the
1578 recipientInformation in E1 (this invalidates the signatures in S3 and S2
1579 which is why they were stripped). The MLA calculates a new signedData
1580 layer, S4, resulting in the following message sent to the ML recipients:
1581 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1582 S3 (unless it specifically replaces an attribute value) including an
1583 updated mlExpansionHistory attribute.
1585 4.2.3 Processing Choices
1587 The processing used depends on the type of the outermost layer of the
1588 message. There are three cases for the type of the outermost data:
1589 - EnvelopedData
1590 - SignedData
1591 - data
1593 4.2.3.1 Processing for EnvelopedData
1595 1. The MLA locates its own RecipientInfo and uses the information it
1596 contains to obtain the message key.
1598 2. The MLA removes the existing recipientInfos field and replaces it with a
1599 new recipientInfos value built from RecipientInfo structures created for
1600 each member of the mailing list. The MLA also removes the existing
1601 originatorInfo field and replaces it with a new originatorInfo value built
1602 from information describing the MLA.
1604 3. The MLA encapsulates the expanded encrypted message in a SignedData
1605 block, adding an mlExpansionHistory attribute as described in the "Mail
1606 List Expansion" section to document the expansion.
1608 4. The MLA signs the new message and delivers the updated message to mail
1609 list members to complete MLA processing.
1611 4.2.3.2 Processing for SignedData
1613 MLA processing of multi-layer messages depends on the type of data in each
1614 of the layers. Step 3 below specifies that different processing will take
1615 place depending on the type of CMS message that has been signed. That is,
1616 it needs to know the type of data at the next inner layer, which may or may
1617 not be the innermost layer.
1619 1. The MLA verifies the signature value found in the outermost SignedData
1620 layer associated with the signed data. MLA processing of the message
1621 terminates if the message signature is invalid.
1623 2. If the outermost SignedData layer includes an signed mlExpansionHistory
1624 attribute the MLA checks for an expansion loop as described in the
1625 "Detecting Mail List Expansion Loops" section.
1627 3. Determine the type of the data that has been signed. That is, look at
1628 the type of data on the layer just below the SignedData, which may or may
1629 not be the "innermost" layer. Based on the type of data, perform either
1630 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1631 types).
1633 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1634 processing of the encrypted message as described previously. Note that
1635 this process invalidates the signature value in the outermost
1636 SignedData layer associated with the original encrypted message.
1637 Proceed to section 3.2 with the result of the expansion.
1639 3.2. If the signed data is SignedData, or is the result of expanding an
1640 EnvelopedData block in step 3.1:
1642 3.2.1. The MLA strips the existing outermost SignedData layer after
1643 remembering the value of the mlExpansionHistory and all other
1644 signed attributes in that layer, if present.
1646 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1647 encapsulates the expanded encrypted message in a new outermost
1648 SignedData layer. On the other hand, if the signed data is
1649 SignedData (from step 3.2), the MLA encapsulates the signed data in
1650 a new outermost SignedData layer.
1652 3.2.3. The outermost signedData layer created by the MLA replaces
1653 the original outermost signedData layer. The MLA MUST create an
1654 signed attribute list for the new outermost signedData layer which
1655 MUST include each signed attribute present in the original
1656 outermost signedData layer, unless the MLA explicitly replaces one
1657 or more particular attributes with new value. A special case is the
1658 mlExpansionHistory attribute. The MLA MUST add an
1659 mlExpansionHistory signed attribute to the outer signedData layer
1660 as follows:
1662 3.2.3.1. If the original outermost SignedData layer included an
1663 mlExpansionHistory attribute, the attribute's value is copied
1664 and updated with the current ML expansion information as
1665 described in the "Mail List Expansion" section.
1667 3.2.3.2. If the original outermost SignedData layer did not
1668 include an mlExpansionHistory attribute, a new attribute value
1669 is created with the current ML expansion information as
1670 described in the "Mail List Expansion" section.
1672 3.3. If the signed data is not EnvelopedData or SignedData:
1674 3.3.1. The MLA encapsulates the received signedData object in an
1675 outer SignedData object, and adds an mlExpansionHistory attribute
1676 to the outer SignedData object containing the current ML expansion
1677 information as described in the "Mail List Expansion" section.
1679 4. The MLA signs the new message and delivers the updated message to mail
1680 list members to complete MLA processing.
1682 A flow chart for the above steps would be:
1684 1. Has a valid signature?
1685 YES -> 2.
1686 NO -> STOP.
1687 2. Does outermost SignedData layer
1688 contain mlExpansionHistory?
1689 YES -> Check it, then -> 3.
1690 NO -> 3.
1691 3. Check type of data just below outermost
1692 SignedData.
1693 EnvelopedData -> 3.1.
1694 SignedData -> 3.2.
1695 all others -> 3.3.
1696 3.1. Expand the encrypted message, then -> 3.2.
1697 3.2. -> 3.2.1.
1698 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
1699 and other signed attributes, then -> 3.2.2.
1700 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1701 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
1702 YES -> copy the old mlExpansionHistory values, then -> 4.
1703 NO -> create new mlExpansionHistory value, then -> 4.
1704 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
1705 attribute, then -> 4.
1706 4. Sign message, deliver it, STOP.
1708 4.2.3.3 Processing for data
1710 1. The MLA encapsulates the message in a SignedData layer, and adds an
1711 mlExpansionHistory attribute containing the current ML expansion
1712 information as described in the "Mail List Expansion" section.
1714 2. The MLA signs the new message and delivers the updated message to mail
1715 list members to complete MLA processing.
1717 4.3 Mail List Agent Signed Receipt Policy Processing
1719 If a mailing list (B) is a member of another mailing list (A), list B often
1720 needs to propagate forward the mailing list receipt policy of A. As a
1721 general rule, a mailing list should be conservative in propagating forward
1722 the mailing list receipt policy because the ultimate recipient need only
1723 process the last item in the ML expansion history. The MLA builds the
1724 expansion history to meet this requirement.
1726 The following table describes the outcome of the union of mailing list A's
1727 policy (the rows in the table) and mailing list B's policy (the columns in
1728 the table).
1730 | B's policy
1731 A's policy | none insteadOf inAdditionTo missing
1732 -------------------------------------------------------------------------
1733 none | none none none none
1734 insteadOf | none insteadOf(B) *1 insteadOf(A)
1735 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
1736 missing | none insteadOf(B) inAdditionTo(B) missing
1738 *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
1739 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
1741 4.4 Mail List Expansion History Syntax
1743 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1744 there are more than ub-ml-expansion-history mailing lists in the sequence,
1745 the processing agent should provide notification of the error to a human
1746 mail list administrator. The mail list administrator is responsible for
1747 correcting the overflow condition.
1749 MLExpansionHistory ::= SEQUENCE
1750 SIZE (1..ub-ml-expansion-history) OF MLData
1752 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1753 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
1755 ub-ml-expansion-history INTEGER ::= 64
1757 MLData contains the expansion history describing each MLA that has
1758 processed a message. As an MLA distributes a message to members of an ML,
1759 the MLA records its unique identifier, date and time of expansion, and
1760 receipt policy in an MLData structure.
1762 MLData ::= SEQUENCE {
1763 mailListIdentifier EntityIdentifier,
1764 -- EntityIdentifier is imported from [CMS]
1765 expansionTime GeneralizedTime,
1766 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1768 EntityIdentifier ::= CHOICE {
1769 issuerAndSerialNumber IssuerAndSerialNumber,
1770 subjectKeyIdentifier SubjectKeyIdentifier }
1772 The receipt policy of the ML can withdraw the originator's request for the
1773 return of a signed receipt. However, if the originator of the message has
1774 not requested a signed receipt, the MLA cannot request a signed receipt. In
1775 the event that a ML's signed receipt policy supersedes the originator's
1776 request for signed receipts, such that the originator will not receive any
1777 signed receipts, then the MLA MAY inform the originator of that fact.
1779 When present, the mlReceiptPolicy specifies a receipt policy that
1780 supersedes the originator's request for signed receipts. The policy can be
1781 one of three possibilities: receipts MUST NOT be returned (none); receipts
1782 should be returned to an alternate list of recipients, instead of to the
1783 originator (insteadOf); or receipts should be returned to a list of
1784 recipients in addition to the originator (inAdditionTo).
1786 MLReceiptPolicy ::= CHOICE {
1787 none [0] NULL,
1788 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
1789 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
1791 5. Signing Certificate Attribute
1793 Concerns have been raised over the fact that the certificate which the
1794 signer of a [CMS] SignedData object desired to be bound into the
1795 verification process of the SignedData object is not cryptographically
1796 bound into the signature itself. This section addresses this issue by
1797 creating a new attribute to be placed in the signed attributes section of a
1798 SignerInfo object.
1800 This section also presents a description of a set of possible attacks
1801 dealing with the substitution of one certificate to verify the signature
1802 for the desired certificate. A set of ways for preventing or addressing
1803 these attacks is presented to deal with the simplest of the attacks.
1805 Attribute certificates can be used as part of a signature verification
1806 process. There is no way in CMS to include the list of attribute
1807 certificates to be used in the verification process. The set of attribute
1808 certificates used in the signature verification process needs to have the
1809 ability for the signer to restrict the set of certificates. This
1810 information needs to be encoded in a manner that is covered by the
1811 signature on the SignedData object. The methods in this section allows for
1812 the set of attribute certificates to be listed as part of the signing
1813 certificate attribute.
1815 Explicit policies can also be used as part of a signature verification
1816 process. If a signer desires to state an explicit policy that should be
1817 used validating the signature, that policy needs to be cryptographically
1818 bound into the signing process. The methods described in this section
1819 allows for a set of policy statements to be listed as part of the signing
1820 certificate attribute.
1822 5.1. Attack Descriptions
1824 At least three different attacks can be launched against a possible
1825 signature verification process by changing the certificate or certficates
1826 used in the signature verification process.
1828 5.1.1 Substitution Attack Description
1830 The first attack deals with simple substitution of one certificate for
1831 another certificate. In this attack, the issuer and serial number in the
1832 SignerInfo is modified to refer to a new certificate. This new certificate
1833 is used the signature verification process.
1835 The first version of this attack is a simple denial of service attack where
1836 an invalid certificate is substituted for the valid certificate. This
1837 renders the message unverifiable, as the public key in the certificate no
1838 longer matches the private key used to sign the message.
1840 The second version is a substitution of one valid certificate for the
1841 original valid certificate where the public keys in the certificates match.
1842 This allows the signature to be validated under potentially different
1843 certificate constraints than the originator of the message intended.
1845 5.1.2 Reissue of Certificate Description
1847 The second attack deals with a certificate authority (CA) re-issuing the
1848 signing certificate (or potentially one of its certificates). This attack
1849 may start becoming more frequent as Certificate Authorities reissue their
1850 own root certificates, or as certificate authorities change policies in the
1851 certificate while reissuing their root certificates. This problem also
1852 occurs when cross certificates (with potentially different restrictions)
1853 are used in the process of verifying a signature.
1855 5.1.3 Rogue Duplicate CA Description
1857 The third attack deals with a rogue entity setting up a certificate
1858 authority that attempts to duplicate the structure of an existing CA.
1859 Specifically, the rogue entity issues a new certificate with the same
1860 public keys as the signer used, but signed by the rogue entity's private
1861 key.
1863 5.2 Attack Responses
1865 This document does not attempt to solve all of the above attacks; however,
1866 a brief description of responses to each of the attacks is given in this
1867 section.
1869 5.2.1 Substitution Attack Response
1871 The denial of service attack cannot be prevented. After the certificate
1872 identifier has been modified in transit, no verification of the signature
1873 is possible. There is also no way to automatically identify the attack
1874 because it is indistinguishable from a message corruption.
1876 The substitution of a valid certificate can be responded to in two
1877 different manners. The first is to make a blanket statement that the use of
1878 the same public key in two different certificates is bad practice and has
1879 to be avoided. In practice, there is no practical way to prevent users from
1880 getting new certificates with the same public keys, and it should be
1881 assumed that they will do this. Section 5.4 provides a new attribute that
1882 can be included in the SignerInfo signed attributes. This binds the correct
1883 certificate identifier into the signature. This will convert the attack
1884 from a potentially successful one to simply a denial of service attack.
1886 5.2.2 Reissue of Certificate Response
1888 A CA should never reissue a certificate with different attributes.
1889 Certificate Authorities that do so are following poor practices and cannot
1890 be relied on. Using the hash of the certificate as the reference to the
1891 certificate prevents this attach for end-entity certificates.
1893 Preventing the attack based on reissuing of CA certificates would require a
1894 substantial change the attribute presented in section 5.4. It would require
1895 that a sequence of certificate identifiers be included in the attribute.
1896 This presents problems when the relying party is using a cross-certificate
1897 as part of its authentication process, and this certificate does not appear
1898 on the list of certificates. The problems outside of a closed PKI make the
1899 addition of this information prone to error, possibly causing the rejection
1900 of valid chains.
1902 5.2.3 Rogue Duplicate CA Response
1904 The best method of preventing this attack is to avoid trusting the rogue
1905 CA. The use of the hash to identify certificates prevents the use of
1906 end-entity certificates from the rogue authority. However the only true way
1907 to prevent this attack is to never trust the rogue CA.
1909 5.3 Related Signature Verification Context
1911 Some applications require that additional information be used as part of
1912 the signature validation process. In particular, attribute certificates and
1913 policy identifiers provide additional information about the abilities and
1914 intent of the signer. The signing certificate attribute described in
1915 Section 5.4 provides the ability to bind this context information as part
1916 of the signature.
1918 5.3.1 Attribute Certificates
1920 Some applications require that attribute certificates be validated. This
1921 validation requires that the application be able to find the correct
1922 attribute certificates to perform the verification process; however there
1923 is no list of attribute certificates in a SignerInfo object. The sender has
1924 the ability to include a set of attribute certificates in a SignedData
1925 object. The receiver has the ability to retrieve attribute certificates
1926 from a directory service. There are some circumstances where the signer may
1927 wish to limit the set of attribute certificates that may be used in
1928 verifying a signature. It is useful to be able to list the set of attribute
1929 certificates the signer wants the recipient to use in validating the
1930 signature.
1932 5.3.2 Policy Information
1934 A related aspect of the certificate binding is the issue of multiple
1935 certification paths. In some instances, the semantics of a certificate in
1936 its use with a message may depend on the Certificate Authorities and
1937 policies that apply. To address this issue, the signer may also wish to
1938 bind that context under the signature. While this could be done by either
1939 signing the complete certification path or a policy ID, only a binding for
1940 the policy ID is described here.
1942 5.4 Signing Certificate Attribute Definition
1944 The signing certificate attribute is designed to prevent the simple
1945 substitution and re-issue attacks, and to allow for a restricted set of
1946 attribute certificates to be used in verifying a signature.
1948 The following object identifier identifies the encrypted-data content type:
1950 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
1951 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1952 smime(16) id-aa(2) }
1954 The definition of SigningCertificate is
1956 SigningCertificate ::= SEQUENCE {
1957 certs SEQUENCE OF CertID,
1958 policies SEQUENCE OF PolicyInformation OPTIONAL
1959 }
1961 The first certificate identified in the sequence of certificate identifiers
1962 MUST be the certificate used to verify the signature. The encoding of the
1963 CertID for this certificate SHOULD NOT include the issuerAndSerialNumber
1964 because the issuerAndSerialNumber is already present in the SignerInfo. The
1965 certificate identified is used during the signature verification process.
1966 If the hash of the certificate does not match the certificate used to
1967 decode the signature, the signature MUST be considered invalid.
1969 If more than one certificate is present in the sequence of CertIDs, the
1970 certificates after the first one limit the set of attribute certificates
1971 that are used during signature validation. The issuerAndSerialNumber SHOULD
1972 be present in these certificates, unless the client who is validating the
1973 signature is expected to have easy access to all the certificates required
1974 for validation. If only the signing certificate is present in the sequence.
1975 there are no restrictions on the set of attribute certificates used in
1976 validating the signature.
1978 The sequence of policy information terms identifies those certificate
1979 policies that the signer asserts apply to the certificate, and under which
1980 the certificate should be relied upon. This value suggests a policy value
1981 to be used in the relying party's certification path validation.
1983 If present, the SigningCertificate attribute MUST be a signed attribute; it
1984 MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
1985 Attribute. A SignerInfo MUST NOT include multiple instances of the
1986 SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
1987 attributes to include attrValues SET OF AttributeValue. A
1988 SigningCertificate attribute MUST include only a single instance of
1989 AttributeValue. There MUST NOT be zero or multiple instances of
1990 AttributeValue present in the attrValues SET OF AttributeValue.
1992 5.4.1 Certificate Identification
1994 The best way to identify certificates is an often-discussed issue. [CMS]
1995 has imposed a restriction for SignedData objects that the issuer DN must be
1996 present in all signing certificates. The issuer/serial number pair is
1997 therefore sufficient to identify the correct signing certificate. This
1998 information is already present, as part of the SignerInfo object, and
1999 duplication of this information would be unfortunate. A hash of the entire
2000 certificate serves the same function (allowing the receiver to very the
2001 same certificate is being used), is smaller and permits a detection of the
2002 simple substitution attacks.
2004 Attribute certificates do not have an issuer/serial number pair represented
2005 anywhere in a SignerInfo object. When an attribute certificate is not
2006 included in the SignedData object, it becomes much more difficult to get
2007 the correct set of certificates based only on a hash of the certificate.
2008 For this reason, attribute certificates are identified by the IssuerSerial
2009 object.
2011 This document defines a certificate identifier as:
2013 CertID ::= SEQUENCE {
2014 certHash Hash,
2015 issuerSerial IssuerSerial OPTIONAL
2016 }
2018 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
2020 IssuerSerial ::= SEQUENCE {
2021 issuer GeneralNames,
2022 serialNumber CertificateSerialNumber
2023 }
2025 When creating a CertID, the certHash is computed over the entire DER
2026 encoded certificate including the signature. The issuerSerial would
2027 normally be present unless the value can be inferred from other
2028 information.
2030 When encoding IssuerSerial, serialNumber is the serial number that uniquely
2031 identifies the certificate. For non-attribute certificates, the issuer MUST
2032 contain only the issuer name from the certificate encoded in the
2033 directoryName choice of GeneralNames. For attribute certificates, the
2034 issuer MUST contain the issuer name field from the attribute certificate.
2036 6. Security Considerations
2038 This entire document discusses security.
2040 A. ASN.1 Module
2042 ExtendedSecurityServices
2043 { iso(1) member-body(2) us(840) rsadsi(113549)
2044 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
2046 DEFINITIONS IMPLICIT TAGS ::=
2047 BEGIN
2049 IMPORTS
2051 -- Cryptographic Message Syntax (CMS)
2052 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version
2053 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
2054 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
2056 -- X.509
2057 GeneralNames FROM CertificateExtensions
2058 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
2060 -- Extended Security Services
2062 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
2063 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
2064 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
2065 -- have at least one entry. MAX indicates the upper bound is unspecified.
2066 -- Implementations are free to choose an upper bound that suits their
2067 -- environment.
2069 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
2070 -- The contents are formatted as described in [UTF8]
2072 -- Section 2.7
2074 ReceiptRequest ::= SEQUENCE {
2075 signedContentIdentifier ContentIdentifier,
2076 receiptsFrom ReceiptsFrom,
2077 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
2079 ub-receiptsTo INTEGER ::= 16
2081 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2082 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
2084 ContentIdentifier ::= OCTET STRING
2086 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2087 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
2089 ReceiptsFrom ::= CHOICE {
2090 allOrFirstTier [0] AllOrFirstTier,
2091 -- formerly "allOrNone [0]AllOrNone"
2092 receiptList [1] SEQUENCE OF GeneralNames }
2094 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
2095 allReceipts (0),
2096 firstTierRecipients (1) }
2098 -- Section 2.8
2100 Receipt ::= SEQUENCE {
2101 version Version, -- Version is imported from [CMS]
2102 contentType ContentType,
2103 signedContentIdentifier ContentIdentifier,
2104 originatorSignatureValue OCTET STRING }
2106 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2107 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
2109 -- Section 2.9
2111 ContentHints ::= SEQUENCE {
2112 contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
2113 contentType ContentType }
2115 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2116 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
2118 -- Section 2.10
2120 MsgSigDigest ::= OCTET STRING
2122 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2123 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
2125 -- Section 2.11
2127 ContentReference ::= SEQUENCE {
2128 contentType ContentType,
2129 signedContentIdentifier ContentIdentifier,
2130 originatorSignatureValue OCTET STRING }
2132 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2133 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
2135 -- Section 3.2
2137 ESSSecurityLabel ::= SET {
2138 security-policy-identifier SecurityPolicyIdentifier,
2139 security-classification SecurityClassification OPTIONAL,
2140 privacy-mark ESSPrivacyMark OPTIONAL,
2141 security-categories SecurityCategories OPTIONAL }
2143 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2144 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
2146 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
2148 SecurityClassification ::= INTEGER {
2149 unmarked (0),
2150 unclassified (1),
2151 restricted (2),
2152 confidential (3),
2153 secret (4),
2154 top-secret (5) } (0..ub-integer-options)
2156 ub-integer-options INTEGER ::= 256
2158 ESSPrivacyMark ::= CHOICE {
2159 pString PrintableString SIZE (1..ub-privacy-mark-length),
2160 utf8String UTF8String SIZE (1..MAX)
2161 }
2163 ub-privacy-mark-length INTEGER ::= 128
2165 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
2166 SecurityCategory
2168 ub-security-categories INTEGER ::= 64
2170 SecurityCategory ::= SEQUENCE {
2171 type [0] OBJECT IDENTIFIER,
2172 value [1] ANY DEFINED BY type -- defined by type
2173 }
2175 --Note: The aforementioned SecurityCategory syntax produces identical
2176 --hex encodings as the following SecurityCategory syntax that is
2177 --documented in the X.411 specification:
2178 --
2179 --SecurityCategory ::= SEQUENCE {
2180 -- type [0] SECURITY-CATEGORY,
2181 -- value [1] ANY DEFINED BY type }
2182 --
2183 --SECURITY-CATEGORY MACRO ::=
2184 --BEGIN
2185 --TYPE NOTATION ::= type | empty
2186 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
2187 --END
2189 -- Section 3.4
2191 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
2193 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2194 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
2196 -- Section 4.4
2198 MLExpansionHistory ::= SEQUENCE
2199 SIZE (1..ub-ml-expansion-history) OF MLData
2201 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2202 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
2204 ub-ml-expansion-history INTEGER ::= 64
2206 MLData ::= SEQUENCE {
2207 mailListIdentifier EntityIdentifier,
2208 -- EntityIdentifier is imported from [CMS]
2209 expansionTime GeneralizedTime,
2210 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
2212 EntityIdentifier ::= CHOICE {
2213 issuerAndSerialNumber IssuerAndSerialNumber,
2214 subjectKeyIdentifier SubjectKeyIdentifier }
2216 MLReceiptPolicy ::= CHOICE {
2217 none [0] NULL,
2218 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
2219 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
2221 END -- of ExtendedSecurityServices
2223 B. References
2225 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
2226 Notation One (ASN.1)"
2228 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
2229 Notation One (ASN.1)"
2231 [CMS] "Cryptographic Message Syntax", Internet Draft
2232 draft-ietf-smime-cms-xx.
2234 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP)
2235 4.0", Specification SDN.701, Revision A, 1997-02-06.
2237 [MTSABS] "1988 International Telecommunication Union (ITU) Data
2238 Communication Networks Message Handling Systems: Message Transfer System:
2239 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
2240 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
2241 mts(3) modules(0) mts-abstract-service(1)}
2243 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315.
2245 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
2246 "S/MIME Version 2 Certificate Handling", RFC 2312.
2248 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
2249 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling",
2250 Internet Draft draft-ietf-smime-cert-xx.
2252 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
2254 C. Acknowledgments
2256 The first draft of this work was prepared by David Solo. John Pawling did a
2257 huge amount of very detailed revision work during the many phases of the
2258 document.
2260 Many other people have contributed hard work to this draft, including:
2261 Bancroft Scott
2262 Bengt Ackzell
2263 Blake Ramsdell
2264 Carlisle Adams
2265 David Kemp
2266 Jim Schaad
2267 Russ Housley
2268 Scott Hollenbeck
2269 Steve Dusse
2271 D. Open Issues
2273 None.
2275 E. Changes from draft-ietf-smime-ess-07 to draft-ietf-smime-ess-08
2277 3.4.2: Tiny typos.
2279 4.4: Added ASN.1 for EntityIdentifier. Also added this to Appendix A.
2281 5: Added this entire section.
2283 A: Removed EntityIdentifier from the imports from CMS, and added
2284 IssuerAndSerialNumber to the imports.
2286 F. Editor's Address
2288 Paul Hoffman
2289 Internet Mail Consortium
2290 127 Segre Place
2291 Santa Cruz, CA 95060
2292 (831) 426-9827
2293 phoffman@imc.org