idnits 2.17.1
draft-ietf-smime-ess-10.txt:
-(466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(912): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(975): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1761): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(2179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-26) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== There are 22 instances of lines with non-ascii characters in the
document.
== 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 2372 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 442 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 109: '...entInfo eContent MUST be absent. If th...'
RFC 2119 keyword, line 111: '...entInfo eContent MUST contain the resu...'
RFC 2119 keyword, line 133: '...contentType MUST be id-data. The Envel...'
RFC 2119 keyword, line 162: '...receiving agents MUST be able to inter...'
RFC 2119 keyword, line 243: '...request MUST be in the inside signatur...'
(138 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 1746 has weird spacing: '... | none inst...'
== Line 1748 has weird spacing: '... | none none...'
== Line 1749 has weird spacing: '... | none inst...'
== Line 1750 has weird spacing: '... | none inst...'
== Line 1751 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 (November 12, 1998) is 9297 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 2286 looks like a reference
-- Missing reference section? 'MSG' on line 2326 looks like a reference
-- Missing reference section? 'CERT' on line 2326 looks like a reference
-- Missing reference section? 'SMIME2' on line 2297 looks like a reference
-- Missing reference section? 'ASN1-1988' on line 2268 looks like a
reference
-- Missing reference section? 'MUSTSHOULD' on line 2329 looks like a
reference
-- Missing reference section? 'ESS' on line 2331 looks like a reference
-- Missing reference section? 'CMS' on line 2277 looks like a reference
-- Missing reference section? '0' on line 2237 looks like a reference
-- Missing reference section? '1' on line 2238 looks like a reference
-- Missing reference section? 'MTSABS' on line 2289 looks like a reference
-- Missing reference section? '2' on line 2239 looks like a reference
-- Missing reference section? 'UNIVERSAL 12' on line 2089 looks like a
reference
-- Missing reference section? 'UTF8' on line 2300 looks like a reference
-- Missing reference section? 'ASN1-1994' on line 2271 looks like a
reference
-- Missing reference section? 'SMIME3' on line 2326 looks like a reference
Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Editor: Paul Hoffman
2 draft-ietf-smime-ess-10.txt Internet Mail Consortium
3 November 12, 1998
4 Expires in six months
6 Enhanced Security Services for S/MIME
8 Status of this memo
10 This document is an Internet-Draft. Internet-Drafts are working documents
11 of the Internet Engineering Task Force (IETF), its areas, and its working
12 groups. Note that other groups may also distribute working documents as
13 Internet-Drafts.
15 Internet-Drafts are draft documents valid for a maximum of six months and
16 may be updated, replaced, or obsoleted by other documents at any time. It
17 is inappropriate to use Internet-Drafts as reference material or to cite
18 them other than as "work in progress."
20 To learn the current status of any Internet-Draft, please check the
21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
23 (Pacific Rim), 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 ([MSG] and
37 [CERT]), and some of them can also be added to S/MIME version 2 [SMIME2].
38 The extensions described here will not cause an S/MIME version 3 recipient
39 to be unable to read messages from an S/MIME version 2 sender. However,
40 some of the extensions will cause messages created by an S/MIME version 3
41 sender to be unreadable by an S/MIME version 2 recipient.
43 This document describes both the procedures and the attributes needed for
44 the three services. Note that some of the attributes described in this
45 document are quite useful in other contexts and should be considered when
46 extending S/MIME or other CMS applications.
48 The format of the messages are described in ASN.1:1988 [ASN1-1988].
50 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
51 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
52 document are to be interpreted as described in [MUSTSHOULD].
54 This draft is being discussed on the 'ietf-smime' mailing list. To
55 subscribe, send a message to:
56 ietf-smime-request@imc.org
57 with the single word
58 subscribe
59 in the body of the message. There is a Web site for the mailing list at
60 .
62 1.1 Triple Wrapping
64 Some of the features of each service use the concept of a "triple wrapped"
65 message. A triple wrapped message is one that has been signed, then
66 encrypted, then signed again. The signers of the inner and outer signatures
67 may be different entities or the same entity. Note that the S/MIME
68 specification does not limit the number of nested encapsulations, so there
69 may be more than three wrappings.
71 1.1.1 Purpose of Triple Wrapping
73 Not all messages need to be triple wrapped. Triple wrapping is used when a
74 message must be signed, then encrypted, and then have signed attributes
75 bound to the encrypted body. Outer attributes may be added or removed by
76 the message originator or intermediate agents, and may be signed by
77 intermediate agents or the final recipient.
79 The inside signature is used for content integrity, non-repudiation with
80 proof of origin, and binding attributes (such as a security label) to the
81 original content. These attributes go from the originator to the recipient,
82 regardless of the number of intermediate entities such as mail list agents
83 that process the message. The signed attributes can be used for access
84 control to the inner body. Requests for signed receipts by the originator
85 are carried in the inside signature as well.
87 The encrypted body provides confidentiality, including confidentiality of
88 the attributes that are carried in the inside signature.
90 The outside signature provides authentication and integrity for information
91 that is processed hop-by-hop, where each hop is an intermediate entity such
92 as a mail list agent. The outer signature binds attributes (such as a
93 security label) to the encrypted body. These attributes can be used for
94 access control and routing decisions.
96 1.1.2 Steps for Triple Wrapping
98 The steps to create a triple wrapped message are:
100 1. Start with a message body, called the "original content".
102 2. Encapsulate the original content with the appropriate MIME Content-type
103 headers, such as "Content-type: text/plain". An exception to this MIME
104 encapsulation rule is that a signed receipt is not put in MIME headers.
106 3. Sign the result of step 2 (the inner MIME headers and the original
107 content). The SignedData encapContentInfo eContentType object identifier
108 MUST be id-data. If the structure you create in step 4 is multipart/signed,
109 then the SignedData encapContentInfo eContent MUST be absent. If the
110 structure you create in step 4 is application/pkcs7-mime, then the
111 SignedData encapContentInfo eContent MUST contain the result of step 2
112 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE
113 with a contentType of id-signedData.
115 4. Add an appropriate MIME construct to the signed message from step 3 as
116 defined in [MSG]. The resulting message is called the "inside signature".
118 - If you are signing using multipart/signed, the MIME construct added
119 consists of a Content-type of multipart/signed with parameters, the
120 boundary, the result of step 2 above, the boundary, a Content-type of
121 application/pkcs7-signature, optional MIME headers (such as
122 Content-transfer-encoding and Content-disposition), and a body part that
123 is the result of step 3 above.
125 - If you are instead signing using application/pkcs7-mime, the MIME
126 construct added consists of a Content-type of application/pkcs7-mime
127 with parameters, optional MIME headers (such as
128 Content-transfer-encoding and Content-disposition), and the result of
129 step 3 above.
131 5. Encrypt the result of step 4 as a single block, turning it into an
132 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
133 contentType MUST be id-data. The EnvelopedData structure is encapsulated by
134 a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
135 called the "encrypted body".
137 6. Add the appropriate MIME headers: a Content-type of
138 application/pkcs7-mime with parameters, and optional MIME headers such as
139 Content-transfer-encoding and Content-disposition.
141 7. Using the same logic as in step 3 above, sign the result of step 6 (the
142 MIME headers and the encrypted body) as a single block
144 8. Using the same logic as in step 4 above, add an appropriate MIME
145 construct to the signed message from step 7. The resulting message is
146 called the "outside signature", and is also the triple wrapped message.
148 1.2 Format of a Triple Wrapped Message
150 A triple wrapped message has many layers of encapsulation. The structure
151 differs based on the choice of format for the signed portions of the
152 message. Because of the way that MIME encapsulates data, the layers do not
153 appear in order, and the notion of "layers" becomes vague.
155 There is no need to use the multipart/signed format in an inner signature
156 because it is known that the recipient is able to process S/MIME messages
157 (because they decrypted the middle wrapper). A sending agent might choose
158 to use the multipart/signed format in the outer layer so that a non-S/MIME
159 agent could see that the next inner layer is encrypted; however, this is
160 not of great value, since all it shows the recipient is that the rest of
161 the message is unreadable. Because many sending agents always use
162 multipart/signed structures, all receiving agents MUST be able to interpret
163 either multipart/signed or application/pkcs7-mime signature structures.
165 The format of a triple wrapped message that uses multipart/signed for both
166 signatures is:
168 [step 8] Content-type: multipart/signed;
169 [step 8] protocol="application/pkcs7-signature";
170 [step 8] boundary=outerboundary
171 [step 8]
172 [step 8] --outerboundary
173 [step 6] Content-type: application/pkcs7-mime; )
174 [step 6] smime-type=enveloped-data )
175 [step 6] )
176 [step 4] Content-type: multipart/signed; | )
177 [step 4] protocol="application/pkcs7-signature"; | )
178 [step 4] boundary=innerboundary | )
179 [step 4] | )
180 [step 4] --innerboundary | )
181 [step 2] Content-type: text/plain % | )
182 [step 2] % | )
183 [step 1] Original content % | )
184 [step 4] | )
185 [step 4] --innerboundary | )
186 [step 4] Content-type: application/pkcs7-signature | )
187 [step 4] | )
188 [step 3] inner SignedData block (eContent is missing) | )
189 [step 4] | )
190 [step 4] --innerboundary-- | )
191 [step 8]
192 [step 8] --outerboundary
193 [step 8] Content-type: application/pkcs7-signature
194 [step 8]
195 [step 7] outer SignedData block (eContent is missing)
196 [step 8]
197 [step 8] --outerboundary--
199 % = These lines are what the inner signature is computed over.
200 | = These lines are what is encrypted in step 5. This encrypted result
201 is opaque and is a part of an EnvelopedData block.
202 ) = These lines are what the outer signature is computed over.
204 The format of a triple wrapped message that uses application/pkcs7-mime for
205 the both signatures is:
207 [step 8] Content-type: application/pkcs7-mime;
208 [step 8] smime-type=signed-data
209 [step 8]
210 [step 7] outer SignedData block (eContent is present) O
211 [step 6] Content-type: application/pkcs7-mime; ) O
212 [step 6] smime-type=enveloped-data; ) O
213 [step 6] ) O
214 [step 4] Content-type: application/pkcs7-mime; | ) O
215 [step 4] smime-type=signed-data | ) O
216 [step 4] | ) O
217 [step 3] inner SignedData block (eContent is present) I | ) O
218 [step 2] Content-type: text/plain I | ) O
219 [step 2] I | ) O
220 [step 1] Original content I | ) O
222 I = These lines are the inner SignedData block, which is opaque and
223 contains the ASN.1 encoded result of step 2 as well as control
224 information.
225 | = These lines are what is encrypted in step 5. This encrypted result
226 is opaque and is a part of an EnvelopedData block.
227 ) = These lines are what the outer signature is computed over.
228 O = These lines are the outer SignedData block, which is opaque and
229 contains the ASN.1 encoded result of step 6 as well as control
230 information.
232 1.3 Security Services and Triple Wrapping
234 The three security services described in this document are used with triple
235 wrapped messages in different ways. This section briefly describes the
236 relationship of each service with triple wrapping; the other sections of
237 the document go into greater detail.
239 1.3.1 Signed Receipts and Triple Wrapping
241 A signed receipt may be requested in any SignedData object. However, if a
242 signed receipt is requested for a triple wrapped message, the receipt
243 request MUST be in the inside signature, not in the outside signature. A
244 secure mailing list agent may change the receipt policy in the outside
245 signature of a triple wrapped message when that message is processed by the
246 mailing list.
248 Note: the signed receipts and receipt requests described in this draft
249 differ from those described in the work done by the IETF Receipt
250 Notification Working Group. The output of that Working Group, when
251 finished, is not expected to work well with triple wrapped messages as
252 described in this document.
254 1.3.2 Security Labels and Triple Wrapping
256 A security label may be included in the signed attributes of any SignedData
257 object. A security label attribute may be included in either the inner
258 signature, outer signature, or both.
260 The inner security label is used for access control decisions related to
261 the plaintext original content. The inner signature provides authentication
262 and cryptographically protects the integrity of the original signer's
263 security label that is in the inside body. This strategy facilitates the
264 forwarding of messages because the original signer's security label is
265 included in the SignedData block which can be forwarded to a third party
266 that can verify the inner signature which will cover the inner security
267 label. The confidentiality security service can be applied to the inner
268 security label by encrypting the entire inner SignedData block within an
269 EnvelopedData block.
271 A security label may also be included in the signed attributes of the outer
272 SignedData block which will include the sensitivities of the encrypted
273 message. The outer security label is used for access control and routing
274 decisions related to the encrypted message. Note that a security label
275 attribute can only be used in an signedAttributes block. An
276 eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned
277 attributes.
279 1.3.3 Secure Mailing Lists and Triple Wrapping
281 Secure mail list message processing depends on the structure of S/MIME
282 layers present in the message sent to the mail list agent. The mail list
283 agent never changes the data that was hashed to form the inner signature,
284 if such a signature is present. If an outer signature is present, then the
285 agent will modify the data that was hashed to form that outer signature. In
286 all cases, the agent adds or updates an mlExpansionHistory attribute to
287 document the agent's processing, and ultimately adds or replaces the outer
288 signature on the message to be distributed.
290 1.3.4 Placement of Attributes
292 Certain attributes should be placed in the inner or outer SignedData
293 message; some attributes can be in either. Further, some attributes must be
294 signed, while signing is optional for others, and some attributes must not
295 be signed. The following table summarizes the recommendation of this
296 profile. In the OID column, [ESS] indicates that the attribute is defined
297 in this document.
299 | |Inner or |
300 Attribute |OID |outer |Signed
301 ------------------|----------------------------- |----------|--------
302 contentHints |id-aa-contentHint [ESS] |either |MAY
303 contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY
304 contentReference |id-aa-contentReference [ESS] |either |MUST
305 contentType |id-contentType [CMS] |either |MUST
306 counterSignature |id-countersignature [CMS] |either |MUST NOT
307 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST
308 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST
309 messageDigest |id-messageDigest [CMS] |either |MUST
310 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST
311 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST
312 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST
313 signingCertificate|id-aa-signingCertificate [ESS]|either |MUST
314 signingTime |id-signingTime [CMS] |either |MUST
315 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST
316 sMIMEEncryption-
317 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST
319 CMS defines signedAttrs as a SET OF Attributes and defines
320 unsignedAttributes as a SET OF Attributes. ESS defines the contentHints,
321 contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory,
322 receiptRequest, contentReference and equivalentLabels attribute types. A
323 signerInfo MUST NOT include multiple instances of any of the attribute
324 types defined in ESS. Later sections of ESS specify further restrictions
325 that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel
326 attribute types.
328 CMS defines the syntax for the signed and unsigned attributes as
329 "attrValues SET OF AttributeValue". For all of the attribute types defined
330 in ESS, if the attribute type is present in a signerInfo, then it MUST only
331 include a single instance of AttributeValue. In other words, there MUST NOT
332 be zero or multiple instances of AttributeValue present in the attrValues
333 SET OF AttributeValue.
335 If a counterSignature attribute is present, then it MUST be included in the
336 unsigned attributes. It MUST NOT be included in the signed attributes. The
337 only attributes that are allowed in a counterSignature attribute are
338 counterSignature, messageDigest, signingTime, and signingCertificate.
340 Note that the inner and outer signatures are usually those of different
341 senders. Because of this, the same attribute in the two signatures could
342 lead to very different consequences.
344 The macValue attribute defined in [CMS] is only used in authenticatedData,
345 never in signedData.
347 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
348 identifier assigned to the message.
350 1.4 Required and Optional Attributes
352 Some security gateways sign messages that pass through them. If the message
353 is any type other than a signedData type, the gateway has only one way to
354 sign the message: by wrapping it with a signedData block and MIME headers.
355 If the message to be signed by the gateway is a signedData message already,
356 the gateway can sign the message by inserting a signerInfo into the
357 signedData block.
359 The main advantage of a gateway adding a signerInfo instead of wrapping the
360 message in a new signature is that the message doesn't grow as much as if
361 the gateway wrapped the message. The main disadvantage is that the gateway
362 must check for the presence of certain attributes in the other signerInfos
363 and duplicate those attributes.
365 If a gateway or other processor adds a signerInfo to an existing signedData
366 block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes
367 from other signerInfos. This helps ensure that the recipient will process
368 those attributes in a signerInfo that it can verify.
370 Note that someone may in the future define an attribute that must be
371 present in each signerInfo of a signedData block in order for the signature
372 to be processed. If that happens, a gateway that inserts signerInfos and
373 doesn't copy that attribute will cause every message with that attribute to
374 fail when processed by the recipient. For this reason, it is safer to wrap
375 messages with new signatures than to insert signerInfos.
377 1.5 Object Identifiers
379 The object identifiers for many of the objects described in this draft are
380 found in [CMS], [MSG], and [CERT]. Other object identifiers used in S/MIME
381 can be found in the registry kept at
382 . When this draft moves to
383 standards track within the IETF, it is intended that the IANA will maintain
384 this registry.
386 2. Signed Receipts
388 Returning a signed receipt provides to the originator proof of delivery of
389 a message, and allows the originator to demonstrate to a third party that
390 the recipient was able to verify the signature of the original message.
391 This receipt is bound to the original message through the signature;
392 consequently, this service may be requested only if a message is signed.
393 The receipt sender may optionally also encrypt a receipt to provide
394 confidentiality between the receipt sender and the receipt recipient.
396 2.1 Signed Receipt Concepts
398 The originator of a message may request a signed receipt from the message's
399 recipients. The request is indicated by adding a receiptRequest attribute
400 to the signedAttributes field of the SignerInfo object for which the
401 receipt is requested. The receiving user agent software SHOULD
402 automatically create a signed receipt when requested to do so, and return
403 the receipt in accordance with mailing list expansion options, local
404 security policies, and configuration options.
406 Because receipts involve the interaction of two parties, the terminology
407 can sometimes be confusing. In this section, the "sender" is the agent that
408 sent the original message that included a request for a receipt. The
409 "receiver" is the party that received that message and generated the
410 receipt.
412 The steps in a typical transaction are:
414 1. Sender creates a signed message including a receipt request attribute
415 (Section 2.2).
417 2. Sender transmits the resulting message to the recipient or recipients.
419 3. Recipient receives message and determines if there is a valid signature
420 and receipt request in the message (Section 2.3).
422 4. Recipient creates a signed receipt (Section 2.4).
424 5. Recipient transmits the resulting signed receipt message to the sender
425 (Section 2.5).
427 6. Sender receives the message and validates that it contains a signed
428 receipt for the original message (Section 2.6). This validation relies on
429 the sender having retained either a copy of the original message or
430 information extracted from the original message.
432 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1
433 syntax for the receipt is given in Section 2.8.
435 Note that a sending agent SHOULD remember when it has sent a receipt so
436 that it can avoid re-sending a receipt each time it processes the message.
438 2.2 Receipt Request Creation
440 Multi-layer S/MIME messages may contain multiple SignedData layers.
441 However, receipts may be requested only for the innermost SignedData layer
442 in a multi-layer S/MIME message, such as a triple wrapped message. Only one
443 receiptRequest attribute can be included in the signedAttributes of a
444 SignerInfo.
446 A ReceiptRequest attribute MUST NOT be included in the attributes of a
447 SignerInfo in a SignedData object that encapsulates a Receipt content. In
448 other words, the receiving agent MUST NOT request a signed receipt for a
449 signed receipt.
451 A sender requests receipts by placing a receiptRequest attribute in the
452 signed attributes of a signerInfo as follows:
454 1. A receiptRequest data structure is created.
456 2. A signed content identifier for the message is created and assigned to
457 the signedContentIdentifier field. The signedContentIdentifier is used to
458 associate the signed receipt with the message requesting the signed
459 receipt.
461 3. The entities requested to return a signed receipt are noted in the
462 receiptsFrom field.
464 4. The message originator MUST populate the receiptsTo field with a
465 GeneralNames for each entity to whom the recipient should send the signed
466 receipt.�If the message originator wants the recipient to send the signed
467 receipt to the originator, then the originator MUST include a GeneralNames
468 for itself in the receiptsTo field.�GeneralNames is a SEQUENCE OF
469 GeneralName.�receiptsTo is a SEQUENCE OF GeneralNames in which each
470 GeneralNames represents an entity.�There may be multiple GeneralName
471 instances in each GeneralNames.�At a minimum, the message originator MUST
472 populate each entity's GeneralNames with the address to which the signed
473 receipt should be sent.�Optionally, the message originator MAY also
474 populate each entity's GeneralNames with other GeneralName instances (such
475 as directoryName).
477 5. The completed receiptRequest attribute is placed in the signedAttributes
478 field of the SignerInfo object.
480 2.2.1 Multiple Receipt Requests
482 There can be multiple SignerInfos within a SignedData object, and each
483 SignerInfo may include signedAttributes. Therefore, a single SignedData
484 object may include multiple SignerInfos, each SignerInfo having a
485 receiptRequest attribute. For example, an originator can send a signed
486 message with two SignerInfos, one containing a DSS signature, the other
487 containing an RSA signature.
489 Each recipient SHOULD return only one signed receipt.
491 Not all of the SignerInfos need to include receipt requests, but in all of
492 the SignerInfos that do contain receipt requests, the receipt requests MUST
493 be identical.
495 2.2.2 Information Needed to Validate Signed Receipts
497 The sending agent MUST retain one or both of the following items to support
498 the validation of signed receipts returned by the recipients.
500 - the original signedData object requesting the signed receipt
502 - the message signature digest value used to generate the original
503 signedData signerInfo signature value and the digest value of the
504 Receipt content containing values included in the original signedData
505 object. If signed receipts are requested from multiple recipients, then
506 retaining these digest values is a performance enhancement because the
507 sending agent can reuse the saved values when verifying each returned
508 signed receipt.
510 2.3 Receipt Request Processing
512 A receiptRequest is associated only with the SignerInfo object to which the
513 receipt request attribute is directly attached. Receiving software SHOULD
514 examine the signedAttributes field of each of the SignerInfos for which it
515 verifies a signature in the innermost signedData object to determine if a
516 receipt is requested. This may result in the receiving agent processing
517 multiple receiptRequest attributes included in a single SignedData object,
518 such as requests made from different people who signed the object in
519 parallel.
521 Before processing a receiptRequest signedAttribute, the receiving agent
522 MUST verify the signature of the SignerInfo which covers the receiptRequest
523 attribute. A recipient MUST NOT process a receiptRequest attribute that has
524 not been verified. Because all receiptRequest attributes in a SignedData
525 object must be identical, the receiving application fully processes (as
526 described in the following paragraphs) the first receiptRequest attribute
527 that it encounters in a SignerInfo that it verifies, and it then ensures
528 that all other receiptRequest attributes in signerInfos that it verifies
529 are identical to the first one encountered. If there are verified
530 ReceiptRequest attributes which are not the same, then the processing
531 software MUST NOT return any signed receipt. A signed receipt SHOULD be
532 returned if any signerInfo containing a receiptRequest attribute can be
533 validated, even if other signerInfos containing the same receiptRequest
534 attribute cannot be validated because they are signed using an algorithm
535 not supported by the receiving agent.
537 If a receiptRequest attribute is absent from the signed attributes, then a
538 signed receipt has not been requested from any of the message recipients
539 and MUST NOT be created. If a receiptRequest attribute is present in the
540 signed attributes, then a signed receipt has been requested from some or
541 all of the message recipients. Note that in some cases, a receiving agent
542 might receive two almost-identical messages, one with a receipt request and
543 the other without one. In this case, the receiving agent SHOULD send a
544 signed receipt for the message that requests a signed receipt.
546 If a receiptRequest attribute is present in the signed attributes, the
547 following process SHOULD be used to determine if a message recipient has
548 been requested to return a signed receipt.
550 1. If an mlExpansionHistory attribute is present in the outermost
551 signedData block, do one of the following two steps, based on the absence
552 or presence of mlReceiptPolicy:
554 1.1. If an mlReceiptPolicy value is absent from the last MLData
555 element, a Mail List receipt policy has not been specified and the
556 processing software SHOULD examine the receiptRequest attribute value
557 to determine if a receipt should be created and returned.
559 1.2. If an mlReceiptPolicy value is present in the last MLData element,
560 do one of the following two steps, based on the value of
561 mlReceiptPolicy:
563 1.2.1. If the mlReceiptPolicy value is none, then the receipt
564 policy of the Mail List supersedes the originator's request for a
565 signed receipt and a signed receipt MUST NOT be created.
567 1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo,
568 the processing software SHOULD examine the receiptsFrom value from
569 the receiptRequest attribute to determine if a receipt should be
570 created and returned. If a receipt is created, the insteadOf and
571 inAdditionTo fields identify entities that SHOULD be sent the
572 receipt instead of or in addition to the originator.
574 2. If the receiptsFrom value of the receiptRequest attribute is
575 allOrFirstTier, do one of the following two steps based on the value of
576 allOrFirstTier.
578 2.1. If the value of allOrFirstTier is allReceipts, then a signed
579 receipt SHOULD be created.
581 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of
582 the following two steps based on the presence of an mlExpansionHistory
583 attribute in an outer signedData block:
585 2.2.1. If an mlExpansionHistory attribute is present, then this
586 recipient is not a first tier recipient and a signed receipt MUST
587 NOT be created.
589 2.2.2. If an mlExpansionHistory attribute is not present, then a
590 signed receipt SHOULD be created.
592 3. If the receiptsFrom value of the receiptRequest attribute is a
593 receiptList:
595 3.1. If receiptList contains one of the GeneralNames of the recipient,
596 then a signed receipt SHOULD be created.
598 3.2. If receiptList does not contain one of the GeneralNames of the
599 recipient, then a signed receipt MUST NOT be created.
601 A flow chart for the above steps to be executed for each signerInfo for
602 which the receiving agent verifies the signature would be:
604 0. Receipt Request attribute present?
605 YES -> 1.
606 NO -> STOP
607 1. Has mlExpansionHistory in outer signedData?
608 YES -> 1.1.
609 NO -> 2.
610 1.1. mlReceiptPolicy absent?
611 YES -> 2.
612 NO -> 1.2.
613 1.2. Pick based on value of mlReceiptPolicy.
614 none -> 1.2.1.
615 insteadOf or inAdditionTo -> 1.2.2.
616 1.2.1. STOP.
617 1.2.2. Examine receiptsFrom to determine if a receipt should be created,
618 create it if required, send it to recipients designated by
619 mlReceiptPolicy, then -> STOP.
620 2. Is value of receiptsFrom allOrFirstTier?
621 YES -> Pick based on value of allOrFirstTier.
622 allReceipts -> 2.1.
623 firstTierRecipients -> 2.2.
624 NO -> 3.
625 2.1. Create a receipt, then -> STOP.
626 2.2. Has mlExpansionHistory in the outer signedData block?
627 YES -> 2.2.1.
628 NO -> 2.2.2.
629 2.2.1. STOP.
630 2.2.2. Create a receipt, then -> STOP.
631 3. Is receiptsFrom value of receiptRequest a receiptList?
632 YES -> 3.1.
633 NO -> STOP.
634 3.1. Does receiptList contain the recipient?
635 YES -> Create a receipt, then -> STOP.
636 NO -> 3.2.
637 3.2. STOP.
639 2.4 Signed Receipt Creation
641 A signed receipt is a signedData object encapsulating a Receipt content
642 (also called a "signedData/Receipt"). Signed receipts are created as
643 follows:
645 1. The signature of the original signedData signerInfo that includes the
646 receiptRequest signed attribute MUST be successfully verified before
647 creating the signedData/Receipt.
649 1.1. The content of the original signedData object is digested as
650 described in [CMS]. The resulting digest value is then compared with
651 the value of the messageDigest attribute included in the
652 signedAttributes of the original signedData signerInfo. If these digest
653 values are different, then the signature verification process fails and
654 the signedData/Receipt MUST NOT be created.
656 1.2. The ASN.1 DER encoded signedAttributes (including messageDigest,
657 receiptRequest and, possibly, other signed attributes) in the original
658 signedData signerInfo are digested as described in [CMS]. The resulting
659 digest value, called msgSigDigest, is then used to verify the signature
660 of the original signedData signerInfo. If the signature verification
661 fails, then the signedData/Receipt MUST NOT be created.
663 2. A Receipt structure is created.
665 2.1. The value of the Receipt version field is set to 1.
667 2.2. The object identifier from the contentType attribute included in
668 the original signedData signerInfo that includes the receiptRequest
669 attribute is copied into the Receipt contentType.
671 2.3. The original signedData signerInfo receiptRequest
672 signedContentIdentifier is copied into the Receipt
673 signedContentIdentifier.
675 2.4. The signature value from the original signedData signerInfo that
676 includes the receiptRequest attribute is copied into the Receipt
677 originatorSignatureValue.
679 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.
681 4. D1 is digested. The resulting digest value is included as the
682 messageDigest attribute in the signedAttributes of the signerInfo which
683 will eventually contain the signedData/Receipt signature value.
685 5. The digest value (msgSigDigest) calculated in Step 1 to verify the
686 signature of the original signedData signerInfo is included as the
687 msgSigDigest attribute in the signedAttributes of the signerInfo which will
688 eventually contain the signedData/Receipt signature value.
690 6. A contentType attribute including the id-ct-receipt object identifier
691 MUST be created and added to the signed attributes of the signerInfo which
692 will eventually contain the signedData/Receipt signature value.
694 7. A signingTime attribute indicating the time that the signedData/Receipt
695 is signed SHOULD be created and added to the signed attributes of the
696 signerInfo which will eventually contain the signedData/Receipt signature
697 value. Other attributes (except receiptRequest) may be added to the
698 signedAttributes of the signerInfo.
700 8. The signedAttributes (messageDigest, msgSigDigest, contentType and,
701 possibly, others) of the signerInfo are ASN.1 DER encoded and digested as
702 described in [CMS]. The resulting digest value is used to calculate the
703 signature value which is then included in the signedData/Receipt
704 signerInfo.
706 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within
707 the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The
708 id-ct-receipt object identifier MUST be included in the signedData
709 encapContentInfo eContentType. This results in a single ASN.1 encoded
710 object composed of a signedData including the Receipt content. The Data
711 content type MUST NOT be used. The Receipt content MUST NOT be encapsulated
712 in a MIME header or any other header prior to being encoded as part of the
713 signedData object.
715 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME
716 wrapper with the smime-type parameter set to "signed-receipt". This will
717 allow for identification of signed receipts without having to crack the
718 ASN.1 body. The smime-type parameter would still be set as normal in any
719 layer wrapped around this message.
721 11. If the signedData/Receipt is to be encrypted within an envelopedData
722 object, then an outer signedData object MUST be created that encapsulates
723 the envelopedData object, and a contentHints attribute with contentType set
724 to the id-ct-receipt object identifier MUST be included in the outer
725 signedData SignerInfo signedAttributes. When a receiving agent processes
726 the outer signedData object, the presence of the id-ct-receipt OID in the
727 contentHints contentType indicates that a signedData/Receipt is encrypted
728 within the envelopedData object encapsulated by the outer signedData.
730 All sending agents that support the generation of ESS signed receipts MUST
731 provide the ability to send encrypted signed receipts (that is, a
732 signedData/Receipt encapsulated within an envelopedData). The sending agent
733 MAY send an encrypted signed receipt in response to an
734 envelopedData-encapsulated signedData requesting a signed receipt. It is a
735 matter of local policy regarding whether or not the signed receipt should
736 be encrypted. The ESS signed receipt includes the message digest value
737 calculated for the original signedData object that requested the signed
738 receipt. If the original signedData object was sent encrypted within an
739 envelopedData object and the ESS signed receipt is sent unencrypted, then
740 the message digest value calculated for the original encrypted signedData
741 object is sent unencrypted. The responder should consider this when
742 deciding whether or not to encrypt the ESS signed receipt.
744 2.4.1 MLExpansionHistory Attributes and Receipts
746 An MLExpansionHistory attribute MUST NOT be included in the attributes of a
747 SignerInfo in a SignedData object that encapsulates a Receipt content. This
748 is true because when a SignedData/Receipt is sent to an MLA for
749 distribution, then the MLA must always encapsulate the received
750 SignedData/Receipt in an outer SignedData in which the MLA will include the
751 MLExpansionHistory attribute. The MLA cannot change the signedAttributes of
752 the received SignedData/Receipt object, so it can't add the
753 MLExpansionHistory to the SignedData/Receipt.
755 2.5 Determining the Recipients of the Signed Receipt
757 If a signed receipt was created by the process described in the sections
758 above, then the software MUST use the following process to determine to
759 whom the signed receipt should be sent.
761 1. The receiptsTo field must be present in the receiptRequest attribute.
762 The software initiates the sequence of recipients with the value(s) of
763 receiptsTo.
765 2. If the MlExpansionHistory attribute is present in the outer SignedData
766 block, and the last MLData contains an MLReceiptPolicy value of insteadOf,
767 then the software replaces the sequence of recipients with the value(s) of
768 insteadOf.
770 3. If the MlExpansionHistory attribute is present in the outer SignedData
771 block and the last MLData contains an MLReceiptPolicy value of
772 inAdditionTo, then the software adds the value(s) of inAdditionTo to the
773 sequence of recipients.
775 2.6. Signed Receipt Validation
777 A signed receipt is communicated as a single ASN.1 encoded object composed
778 of a signedData object directly including a Receipt content. It is
779 identified by the presence of the id-ct-receipt object identifier in the
780 encapContentInfo eContentType value of the signedData object including the
781 Receipt content.
783 A signedData/Receipt is validated as follows:
785 1. ASN.1 decode the signedData object including the Receipt content.
787 2. Extract the contentType, signedContentIdentifier, and
788 originatorSignatureValue from the decoded Receipt structure to identify the
789 original signedData signerInfo that requested the signedData/Receipt.
791 3. Acquire the message signature digest value calculated by the sender to
792 generate the signature value included in the original signedData signerInfo
793 that requested the signedData/Receipt.
795 3.1. If the sender-calculated message signature digest value has been
796 saved locally by the sender, it must be located and retrieved.
798 3.2. If it has not been saved, then it must be re-calculated based on
799 the original signedData content and signedAttributes as described in
800 [CMS].
802 4. The message signature digest value calculated by the sender is then
803 compared with the value of the msgSigDigest signedAttribute included in the
804 signedData/Receipt signerInfo. If these digest values are identical, then
805 that proves that the message signature digest value calculated by the
806 recipient based on the received original signedData object is the same as
807 that calculated by the sender. This proves that the recipient received
808 exactly the same original signedData content and signedAttributes as sent
809 by the sender because that is the only way that the recipient could have
810 calculated the same message signature digest value as calculated by the
811 sender. If the digest values are different, then the signedData/Receipt
812 signature verification process fails.
814 5. Acquire the digest value calculated by the sender for the Receipt
815 content constructed by the sender (including the contentType,
816 signedContentIdentifier, and signature value that were included in the
817 original signedData signerInfo that requested the signedData/Receipt).
819 5.1. If the sender-calculated Receipt content digest value has been
820 saved locally by the sender, it must be located and retrieved.
822 5.2. If it has not been saved, then it must be re-calculated. As
823 described in section 2.4 above, step 2, create a Receipt structure
824 including the contentType, signedContentIdentifier and signature value
825 that were included in the original signedData signerInfo that requested
826 the signed receipt. The Receipt structure is then ASN.1 DER encoded to
827 produce a data stream which is then digested to produce the Receipt
828 content digest value.
830 6. The Receipt content digest value calculated by the sender is then
831 compared with the value of the messageDigest signedAttribute included in
832 the signedData/Receipt signerInfo. If these digest values are identical,
833 then that proves that the values included in the Receipt content by the
834 recipient are identical to those that were included in the original
835 signedData signerInfo that requested the signedData/Receipt. This proves
836 that the recipient received the original signedData signed by the sender,
837 because that is the only way that the recipient could have obtained the
838 original signedData signerInfo signature value for inclusion in the Receipt
839 content. If the digest values are different, then the signedData/Receipt
840 signature verification process fails.
842 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt
843 signerInfo are digested as described in [CMS].
845 8. The resulting digest value is then used to verify the signature value
846 included in the signedData/Receipt signerInfo. If the signature
847 verification is successful, then that proves the integrity of the
848 signedData/receipt signerInfo signedAttributes and authenticates the
849 identity of the signer of the signedData/Receipt signerInfo. Note that the
850 signedAttributes include the recipient-calculated Receipt content digest
851 value (messageDigest attribute) and recipient-calculated message signature
852 digest value (msgSigDigest attribute). Therefore, the aforementioned
853 comparison of the sender-generated and recipient-generated digest values
854 combined with the successful signedData/Receipt signature verification
855 proves that the recipient received the exact original signedData content
856 and signedAttributes (proven by msgSigDigest attribute) that were signed by
857 the sender of the original signedData object (proven by messageDigest
858 attribute). If the signature verification fails, then the
859 signedData/Receipt signature verification process fails.
861 The signature verification process for each signature algorithm that is
862 used in conjunction with the CMS protocol is specific to the algorithm.
863 These processes are described in documents specific to the algorithms.
865 2.7 Receipt Request Syntax
867 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the
868 receiptRequest attribute only within the signed attributes associated with
869 a signed message.
871 ReceiptRequest ::= SEQUENCE {
872 signedContentIdentifier ContentIdentifier,
873 receiptsFrom ReceiptsFrom,
874 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames }
876 ub-receiptsTo INTEGER ::= 16
878 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
879 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
881 ContentIdentifier ::= OCTET STRING
883 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
884 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
886 A signedContentIdentifier MUST be created by the message originator when
887 creating a receipt request. To ensure global uniqueness, the minimal
888 signedContentIdentifier SHOULD contain a concatenation of user-specific
889 identification information (such as a user name or public keying material
890 identification information), a GeneralizedTime string, and a random number.
892 The receiptsFrom field is used by the originator to specify the recipients
893 requested to return a signed receipt. A CHOICE is provided to allow
894 specification of:
895 - receipts from all recipients are requested
896 - receipts from first tier (recipients that did not receive the
897 message as members of a mailing list) recipients are requested
898 - receipts from a specific list of recipients are requested
900 ReceiptsFrom ::= CHOICE {
901 allOrFirstTier [0] AllOrFirstTier,
902 -- formerly "allOrNone [0]AllOrNone"
903 receiptList [1] SEQUENCE OF GeneralNames }
905 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
906 allReceipts (0),
907 firstTierRecipients (1) }
909 The receiptsTo field is used by the originator to identify the user(s) to
910 whom the identified recipient should send signed receipts. The message
911 originator MUST populate the receiptsTo field with a GeneralNames for each
912 entity to whom the recipient should send the signed receipt.�If the message
913 originator wants the recipient to send the signed receipt to the
914 originator, then the originator MUST include a GeneralNames for itself in
915 the receiptsTo field.
917 2.8 Receipt Syntax
919 Receipts are represented using a new content type, Receipt. The Receipt
920 content type shall have ASN.1 type Receipt. Receipts must be encapsulated
921 within a SignedData message.
923 Receipt ::= SEQUENCE {
924 version Version, -- Version is imported from [CMS]
925 contentType ContentType,
926 signedContentIdentifier ContentIdentifier,
927 originatorSignatureValue OCTET STRING }
929 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
930 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
932 The version field defines the syntax version number, which is 1 for this
933 version of the standard.
935 2.9 Content Hints
937 Many applications find it useful to have information that describes the
938 innermost signed content of a multi-layer message available on the
939 outermost signature layer. The contentHints attribute provides such
940 information.
942 Content-hints attribute values have ASN.1 type contentHints.
944 ContentHints ::= SEQUENCE {
945 � contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
946 � contentType ContentType }
948 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
949 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
951 The contentDescription field may be used to provide information that the
952 recipient may use to select protected messages for processing, such as a
953 message subject. If this field is set, then the attribute is expected to
954 appear on the signedData object enclosing an envelopedData object and not
955 on the inner signedData object. The (SIZE (1..MAX)) construct constrains
956 the sequence to have at least one entry. MAX indicates the upper bound is
957 unspecified. Implementations are free to choose an upper bound that suits
958 their environment.
960 Messages which contain a signedData object wrapped around an envelopedData
961 object, thus masking the inner content type of the message, SHOULD include
962 a contentHints attribute, except for the case of the data content type.
963 Specific message content types may either force or preclude the inclusion
964 of the contentHints attribute. For example, when a signedData/Receipt is
965 encrypted within an envelopedData object, an outer signedData object MUST
966 be created that encapsulates the envelopedData object and a contentHints
967 attribute with contentType set to the id-ct-receipt object identifier MUST
968 be included in the outer signedData SignerInfo signedAttributes.
970 2.10� Message Signature Digest Attribute
972 The msgSigDigest attribute can only be used in the signed attributes of a
973 signed receipt.�It contains the digest of the ASN.1 DER encoded
974 signedAttributes included in the original signedData that requested the
975 signed receipt.�Only one msgSigDigest attribute can appear in an signed
976 attributes set. It is defined as follows:
978 msgSigDigest ::= OCTET STRING
980 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
981 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
983 2.11 Signed Content Reference Attribute
985 The contentReference attribute is a link from one SignedData to another. It
986 may be used to link a reply to the original message to which it refers, or
987 to incorporate by reference one SignedData into another. The first
988 SignedData MUST include a contentIdentifier signed attribute, which SHOULD
989 be constructed as specified in section 2.7. The second SignedData links to
990 the first by including a ContentReference signed attribute containing the
991 content type, content identifier, and signature value from the first
992 SignedData.
994 ContentReference ::= SEQUENCE {
995 contentType ContentType,
996 signedContentIdentifier ContentIdentifier,
997 originatorSignatureValue OCTET STRING }
999 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1000 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
1002 3. Security Labels
1004 This section describes the syntax to be used for security labels that can
1005 optionally be associated with S/MIME encapsulated data. A security label is
1006 a set of security information regarding the sensitivity of the content that
1007 is protected by S/MIME encapsulation.
1009 "Authorization" is the act of granting rights and/or privileges to users
1010 permitting them access to an object. "Access control" is a means of
1011 enforcing these authorizations. The sensitivity information in a security
1012 label can be compared with a user's authorizations to determine if the user
1013 is allowed to access the content that is protected by S/MIME encapsulation.
1015 Security labels may be used for other purposes such as a source of routing
1016 information. The labels are often priority based ("secret", "confidential",
1017 "restricted", and so on) or role-based, describing which kind of people can
1018 see the information ("patient's health-care team", "medical billing
1019 agents", "unrestricted", and so on).
1021 3.1 Security Label Processing Rules
1023 A sending agent may include a security label attribute in the signed
1024 attributes of a signedData object. A receiving agent examines the security
1025 label on a received message and determines whether or not the recipient is
1026 allowed to see the contents of the message.
1028 3.1.1 Adding Security Labels
1030 A sending agent that is using security labels MUST put the security label
1031 attribute in the signedAttributes field of a SignerInfo block. The security
1032 label attribute MUST NOT be included in the unsigned attributes. Integrity
1033 and authentication security services MUST be applied to the security label,
1034 therefore it MUST be included as an signed attribute, if used. This causes
1035 the security label attribute to be part of the data that is hashed to form
1036 the SignerInfo signature value. A SignerInfo block MUST NOT have more than
1037 one security label signed attribute.
1039 When there are multiple SignedData blocks applied to a message, a security
1040 label attribute may be included in either the inner signature, outer
1041 signature, or both. A security label signed attribute may be included in a
1042 signedAttributes field within the inner SignedData block. The inner
1043 security label will include the sensitivities of the original content and
1044 will be used for access control decisions related to the plaintext
1045 encapsulated content. The inner signature provides authentication of the
1046 inner security label and cryptographically protects the original signer's
1047 inner security label of the original content.
1049 When the originator signs the plaintext content and signed attributes, the
1050 inner security label is bound to the plaintext content. An intermediate
1051 entity cannot change the inner security label without invalidating the
1052 inner signature. The confidentiality security service can be applied to the
1053 inner security label by encrypting the entire inner signedData object
1054 within an EnvelopedData block.
1056 A security label signed attribute may also be included in a
1057 signedAttributes field within the outer SignedData block. The outer
1058 security label will include the sensitivities of the encrypted message and
1059 will be used for access control decisions related to the encrypted message
1060 and for routing decisions. The outer signature provides authentication of
1061 the outer security label (as well as for the encapsulated content which may
1062 include nested S/MIME messages).
1064 There can be multiple SignerInfos within a SignedData object, and each
1065 SignerInfo may include signedAttributes. Therefore, a single SignedData
1066 object may include multiple eSSSecurityLabels, each SignerInfo having an
1067 eSSSecurityLabel attribute. For example, an originator can send a signed
1068 message with two SignerInfos, one containing a DSS signature, the other
1069 containing an RSA signature. If any of the SignerInfos included in a
1070 SignedData object include an eSSSecurityLabel attribute, then all of the
1071 SignerInfos in that SignedData object MUST include an eSSSecurityLabel
1072 attribute and the value of each MUST be identical.
1074 3.1.2 Processing Security Labels
1076 Before processing an eSSSecurityLabel signedAttribute, the receiving agent
1077 MUST verify the signature of the SignerInfo which covers the
1078 eSSSecurityLabel attribute. A recipient MUST NOT process an
1079 eSSSecurityLabel attribute that has not been verified.
1081 A receiving agent MUST process the eSSSecurityLabel attribute, if present,
1082 in each SignerInfo in the SignedData object for which it verifies the
1083 signature. This may result in the receiving agent processing multiple
1084 eSSSecurityLabels included in a single SignedData object. Because all
1085 eSSSecurityLabels in a SignedData object must be identical, the receiving
1086 agent processes (such as performing access control) on the first
1087 eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
1088 then ensures that all other eSSSecurityLabels in signerInfos that it
1089 verifies are identical to the first one encountered. If the
1090 eSSSecurityLabels in the signerInfos that it verifies are not all
1091 identical, then the receiving agent MUST warn the user of this condition.
1093 Receiving agents SHOULD have a local policy regarding whether or not to
1094 show the inner content of a signedData object that includes an
1095 eSSSecurityLabel security-policy-identifier that the processing software
1096 does not recognize. If the receiving agent does not recognize the
1097 eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
1098 processing the message and indicate an error.
1100 3.2 Syntax of eSSSecurityLabel
1102 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module.
1103 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS
1104 ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in
1105 [MSP4].
1107 ESSSecurityLabel ::= SET {
1108 security-policy-identifier SecurityPolicyIdentifier,
1109 security-classification SecurityClassification OPTIONAL,
1110 privacy-mark ESSPrivacyMark OPTIONAL,
1111 security-categories SecurityCategories OPTIONAL }
1113 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1114 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
1116 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
1118 SecurityClassification ::= INTEGER {
1119 unmarked (0),
1120 unclassified (1),
1121 restricted (2),
1122 confidential (3),
1123 secret (4),
1124 top-secret (5) } (0..ub-integer-options)
1126 ub-integer-options INTEGER ::= 256
1128 ESSPrivacyMark ::= CHOICE {
1129 ��� pString����� PrintableString (SIZE (1..ub-privacy-mark-length)),
1130 ��� utf8String�� UTF8String (SIZE (1..MAX))
1131 }
1133 ub-privacy-mark-length INTEGER ::= 128
1135 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
1136 SecurityCategory
1138 ub-security-categories INTEGER ::= 64
1140 SecurityCategory ::= SEQUENCE {
1141 type [0] OBJECT IDENTIFIER,
1142 value [1] ANY DEFINED BY type -- defined by type
1143 }
1145 --Note: The aforementioned SecurityCategory syntax produces identical
1146 --hex encodings as the following SecurityCategory syntax that is
1147 --documented in the X.411 specification:
1148 --
1149 --SecurityCategory ::= SEQUENCE {
1150 -- type [0] SECURITY-CATEGORY,
1151 -- value [1] ANY DEFINED BY type }
1152 --
1153 --SECURITY-CATEGORY MACRO ::=
1154 --BEGIN
1155 --TYPE NOTATION ::= type | empty
1156 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
1157 --END
1159 3.3 Security Label Components
1161 This section gives more detail on the the various components of the
1162 eSSSecurityLabel syntax.
1164 3.3.1 Security Policy Identifier
1166 A security policy is a set of criteria for the provision of security
1167 services. The eSSSecurityLabel security-policy-identifier is used to
1168 identify the security policy in force to which the security label relates.
1169 It indicates the semantics of the other security label components.
1171 3.3.2 Security Classification
1173 This specification defines the use of the Security Classification field
1174 exactly as is specified in the X.411 Recommendation, which states in part:
1176 If present, a security-classification may have one of a hierarchical
1177 list of values. The basic security-classification hierarchy is defined
1178 in this Recommendation, but the use of these values is defined by the
1179 security-policy in force. Additional values of security-classification,
1180 and their position in the hierarchy, may also be defined by a
1181 security-policy as a local matter or by bilateral agreement. The basic
1182 security-classification hierarchy is, in ascending order: unmarked,
1183 unclassified, restricted, confidential, secret, top-secret.
1185 This means that the security policy in force (identified by the
1186 eSSSecurityLabel security-policy-identifier) defines the
1187 SecurityClassification integer values and their meanings.
1189 An organization can develop its own security policy that defines the
1190 SecurityClassification INTEGER values and their meanings. However, the
1191 general interpretation of the X.411 specification is that the values of 0
1192 through 5 are reserved for the "basic hierarchy" values of unmarked,
1193 unclassified, restricted, confidential, secret, and top-secret. Note that
1194 X.411 does not provide the rules for how these values are used to label
1195 data and how access control is performed using these values.
1197 There is no universal definition of the rules for using these "basic
1198 hierarchy" values. Each organization (or group of organizations) will
1199 define a security policy which documents how the "basic hierarchy" values
1200 are used (if at all) and how access control is enforced (if at all) within
1201 their domain.
1203 Therefore, the security-classification value MUST be accompanied by a
1204 security-policy-identifier value to define the rules for its use. For
1205 example, a company's "secret" classification may convey a different meaning
1206 than the US Government "secret" classification. In summary, a security
1207 policy SHOULD NOT use integers 0 through 5 for other than their X.411
1208 meanings, and SHOULD instead use other values in a hierarchical fashion.
1210 Note that the set of valid security-classification values MUST be
1211 hierarchical, but these values do not necessarily need to be in ascending
1212 numerical order. Further, the values do not need to be contiguous.
1214 For example, in the Defense Message System 1.0 security policy, the
1215 security-classification value of 11 indicates Sensitive-But-Unclassified
1216 and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret
1217 as more sensitive than Sensitive-But-Unclassified even though the numerical
1218 value of top-secret is less than Sensitive-But-Unclassified.
1220 (Of course, if security-classification values are both hierarchical and in
1221 ascending order, a casual reader of the security policy is more likely to
1222 understand it.)
1224 An example of a security policy that does not use any of the X.411 values
1225 might be:
1226 10 -- anyone
1227 15 -- Morgan Corporation and its contractors
1228 20 -- Morgan Corporation employees
1229 25 -- Morgan Corporation board of directors
1231 An example of a security policy that uses part of the X.411 hierarchy might
1232 be:
1233 0 -- unmarked
1234 1 -- unclassified, can be read by everyone
1235 2 -- restricted to Timberwolf Productions staff
1236 6 -- can only be read to Timberwolf Productions executives
1238 3.3.3 Privacy Mark
1240 If present, the eSSSecurityLabel privacy-mark is not used for access
1241 control. The content of the eSSSecurityLabel privacy-mark may be defined by
1242 the security policy in force (identified by the eSSSecurityLabel
1243 security-policy-identifier) which may define a list of values to be used.
1244 Alternately, the value may be determined by the originator of the
1245 security-label.
1247 3.3.4 Security Categories
1249 If present, the eSSSecurityLabel security-categories provide further
1250 granularity for the sensitivity of the message. The security policy in
1251 force (identified by the eSSSecurityLabel security-policy-identifier) is
1252 used to indicate the syntaxes that are allowed to be present in the
1253 eSSSecurityLabel security-categories. Alternately, the security-categories
1254 and their values may be defined by bilateral agreement.
1256 3.4 Equivalent Security Labels
1258 Because organizations are allowed to define their own security policies,
1259 many different security policies will exist. Some organizations may wish to
1260 create equivalencies between their security policies with the security
1261 policies of other organizations. For example, the Acme Company and the
1262 Widget Corporation may reach a bilateral agreement that the "Acme private"
1263 security-classification value is equivalent to the "Widget sensitive"
1264 security-classification value.
1266 Receiving agents MUST NOT process an equivalentLabels attribute in a
1267 message if the agent does not trust the signer of that attribute to
1268 translate the original eSSSecurityLabel values to the security policy
1269 included in the equivalentLabels attribute. Receiving agents have the
1270 option to process equivalentLabels attributes but do not have to. It is
1271 acceptable for a receiving agent to only process eSSSecurityLabels. All
1272 receiving agents SHOULD recognize equivalentLabels attributes even if they
1273 do not process them.
1275 3.4.1 Creating Equivalent Labels
1277 The EquivalentLabels signed attribute is defined as:
1279 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
1281 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1282 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
1284 As stated earlier, the ESSSecurityLabel contains the sensitivity values
1285 selected by the original signer of the signedData. If an ESSSecurityLabel
1286 is present in a signerInfo, all signerInfos in the signedData MUST contain
1287 an ESSSecurityLabel and they MUST all be identical. In addition to an
1288 ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed
1289 attribute. If present, the equivalentLabels attribute MUST include one or
1290 more security labels that are believed by the signer to be semantically
1291 equivalent to the ESSSecurityLabel attribute included in the same
1292 signerInfo.
1294 All security-policy object identifiers MUST be unique in the set of
1295 ESSSecurityLabel and EquivalentLabels security labels. Before using an
1296 EquivalentLabels attribute, a receiving agent MUST ensure that all
1297 security-policy OIDs are unique in the security label or labels included in
1298 the EquivalentLabels. Once the receiving agent selects the security label
1299 (within the EquivalentLabels) to be used for processing, then the
1300 security-policy OID of the selected EquivalentLabels security label MUST be
1301 compared with the ESSSecurityLabel security-policy OID to ensure that they
1302 are unique.
1304 In the case that an ESSSecurityLabel attribute is not included in a
1305 signerInfo, then an EquivalentLabels attribute may still be included. For
1306 example, in the Acme security policy, the absence of an ESSSecurityLabel
1307 could be defined to equate to a security label composed of the Acme
1308 security-policy OID and the "unmarked" security-classification.
1310 Note that equivalentLabels MUST NOT be used to convey security labels that
1311 are semantically different from the ESSSecurityLabel included in the
1312 signerInfos in the signedData. If an entity needs to apply a security label
1313 that is semantically different from the ESSSecurityLabel, then it MUST
1314 include the sematically different security label in an outer signedData
1315 object that encapsulates the signedData object that includes the
1316 ESSSecurityLabel.
1318 If present, the equivalentLabels attribute MUST be an signed attribute; it
1319 MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as a SET
1320 OF Attribute. A signerInfo MUST NOT include multiple instances of the
1321 equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed
1322 attributes to include attrValues SET OF AttributeValue. A equivalentLabels
1323 attribute MUST only include a single instance of AttributeValue. There MUST
1324 NOT be zero or multiple instances of AttributeValue present in the
1325 attrValues SET OF AttributeValue.
1327 3.4.2 Processing Equivalent Labels
1329 A receiving agent SHOULD process the ESSSecurityLabel before processing any
1330 EquivalentLabels. If the policy in the ESSSecurityLabel is understood by
1331 the receiving agent, it MUST process that label and MUST ignore all
1332 EquivalentLabels.
1334 When processing an EquivalentLabels attribute, the receiving agent MUST
1335 validate the signature on the EquivalentLabels attribute. A receiving agent
1336 MUST NOT act on an equivalentLabels attribute for which the signature could
1337 not be validated, and MUST NOT act on an equivalentLabels attribute unless
1338 that attribute is signed by an entity trusted to translate the original
1339 eSSSecurityLabel values to the security policy included in the
1340 equivalentLabels attribute. Determining who is allowed to specify
1341 equivalence mappings is a local policy. If a message has more than one
1342 EquivalentLabels attribute, the receiving agent SHOULD process the first
1343 one that it reads and validates that contains the security policy of
1344 interest to the receiving agent.
1346 4. Mail List Management
1348 Sending agents must create recipient-specific data structures for each
1349 recipient of an encrypted message. This process can impair performance for
1350 messages sent to a large number of recipients. Thus, Mail List Agents
1351 (MLAs) that can take a single message and perform the recipient-specific
1352 encryption for every recipient are often desired.
1354 An MLA appears to the message originator as a normal message recipient, but
1355 the MLA acts as a message expansion point for a Mail List (ML). The sender
1356 of a message directs the message to the MLA, which then redistributes the
1357 message to the members of the ML. This process offloads the per-recipient
1358 processing from individual user agents and allows for more efficient
1359 management of large MLs. MLs are true message recipients served by MLAs
1360 that provide cryptographic and expansion services for the mailing list.
1362 In addition to cryptographic handling of messages, secure mailing lists
1363 also have to prevent mail loops. A mail loop is where one mailing list is a
1364 member of a second mailing list, and the second mailing list is a member of
1365 the first. A message will go from one list to the other in a
1366 rapidly-cascading succession of mail that will be distributed to all other
1367 members of both lists.
1369 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the
1370 outer signature of a triple wrapped message. The mlExpansionHistory
1371 attribute is essentially a list of every MLA that has processed the
1372 message. If an MLA sees its own unique entity identifier in the list, it
1373 knows that a loop has been formed, and does not send the message to the
1374 list again.
1376 4.1 Mail List Expansion
1378 Mail list expansion processing is noted in the value of the
1379 mlExpansionHistory attribute, located in the signed attributes of the MLA's
1380 SignerInfo block. The MLA creates or updates the signed mlExpansionHistory
1381 attribute value each time the MLA expands and signs a message for members
1382 of a mail list.
1384 The MLA MUST add an MLData record containing the MLA's identification
1385 information, date and time of expansion, and optional receipt policy to the
1386 end of the mail list expansion history sequence. If the mlExpansionHistory
1387 attribute is absent, then the MLA MUST add the attribute and the current
1388 expansion becomes the first element of the sequence. If the
1389 mlExpansionHistory attribute is present, then the MLA MUST add the current
1390 expansion information to the end of the existing MLExpansionHistory
1391 sequence. Only one mlExpansionHistory attribute can be included in the
1392 signedAttributes of a SignerInfo.
1394 Note that if the mlExpansionHistory attribute is absent, then the recipient
1395 is a first tier message recipient.
1397 There can be multiple SignerInfos within a SignedData object, and each
1398 SignerInfo may include signedAttributes. Therefore, a single SignedData
1399 object may include multiple SignerInfos, each SignerInfo having a
1400 mlExpansionHistory attribute. For example, an MLA can send a signed message
1401 with two SignerInfos, one containing a DSS signature, the other containing
1402 an RSA signature.
1404 If an MLA creates a SignerInfo that includes an mlExpansionHistory
1405 attribute, then all of the SignerInfos created by the MLA for that
1406 SignedData object MUST include an mlExpansionHistory attribute, and the
1407 value of each MUST be identical. Note that other agents might later add
1408 SignerInfo attributes to the SignedData block, and those additional
1409 SignerInfos might not include mlExpansionHistory attributes.
1411 A recipient MUST verify the signature of the SignerInfo which covers the
1412 mlExpansionHistory attribute before processing the mlExpansionHistory, and
1413 MUST NOT process the mlExpansionHistory attribute unless the signature over
1414 it has been verified. If a SignedData object has more than one SignerInfo
1415 that has an mlExpansionHistory attribute, the recipient MUST compare the
1416 mlExpansionHistory attributes in all the SignerInfos that it has verified,
1417 and MUST NOT process the mlExpansionHistory attribute unless every verified
1418 mlExpansionHistory attribute in the SignedData block is identical. If the
1419 mlExpansionHistory attributes in the verified signerInfos are not all
1420 identical, then the receiving agent MUST stop processing the message and
1421 SHOULD notify the user or MLA administrator of this error condition. In the
1422 mlExpansionHistory processing, SignerInfos that do not have an
1423 mlExpansionHistory attribute are ignored.
1425 4.1.1 Detecting Mail List Expansion Loops
1427 Prior to expanding a message, the MLA examines the value of any existing
1428 mail list expansion history attribute to detect an expansion loop. An
1429 expansion loop exists when a message expanded by a specific MLA for a
1430 specific mail list is redelivered to the same MLA for the same mail list.
1432 Expansion loops are detected by examining the mailListIdentifier field of
1433 each MLData entry found in the mail list expansion history. If an MLA finds
1434 its own identification information, then the MLA must discontinue expansion
1435 processing and should provide warning of an expansion loop to a human mail
1436 list administrator. The mail list administrator is responsible for
1437 correcting the loop condition.
1439 4.2 Mail List Agent Processing
1441 The first few paragraphs of this section provide a high-level description
1442 of MLA processing. The rest of the section provides a detailed description
1443 of MLA processing.
1445 MLA message processing depends on the structure of the S/MIME layers in the
1446 message sent to the MLA for expansion. In addition to sending triple
1447 wrapped messages to an MLA, an entity can send other types of messages to
1448 an MLA, such as:
1449 - a single wrapped signedData or envelopedData message
1450 - a double wrapped message (such as signed and enveloped, enveloped and
1451 signed, or signed and signed, and so on)
1452 - a quadruple-wrapped message (such as if a well-formed triple wrapped
1453 message was sent through a gateway that added an outer SignedData layer)
1455 In all cases, the MLA MUST parse all layers of the received message to
1456 determine if there are any signedData layers that include an
1457 eSSSecurityLabel signedAttribute. This may include decrypting an
1458 EnvelopedData layer to determine if an encapsulated SignedData layer
1459 includes an eSSSecurityLabel attribute. The MLA MUST fully process each
1460 eSSSecurityLabel attribute found in the various signedData layers,
1461 including performing access control checks, before distributing the message
1462 to the ML members. The details of the access control checks are beyond the
1463 scope of this document. The MLA MUST verify the signature of the signerInfo
1464 including the eSSSecurityLabel attribute before using it.
1466 In all cases, the MLA MUST sign the message to be sent to the ML members in
1467 a new "outer" signedData layer. The MLA MUST add or update an
1468 mlExpansionHistory attribute in the "outer" signedData that it creates to
1469 document MLA processing. If there was an "outer" signedData layer included
1470 in the original message received by the MLA, then the MLA-created "outer"
1471 signedData layer MUST include each signed attribute present in the
1472 original "outer" signedData layer, unless the MLA explicitly replaces an
1473 attribute (such as signingTime or mlExpansionHistory) with a new value.
1475 When an S/MIME message is received by the MLA, the MLA MUST first determine
1476 which received signedData layer, if any, is the "outer" signedData layer.
1477 To identify the received "outer" signedData layer, the MLA MUST verify the
1478 signature and fully process the signedAttributes in each of the
1479 outer signedData layers (working from the outside in) to determine if any
1480 of them either include an mlExpansionHistory attribute or encapsulate an
1481 envelopedData object.
1483 The MLA's search for the "outer" signedData layer is completed when it
1484 finds one of the following:
1485 - the "outer" signedData layer that includes an mlExpansionHistory
1486 attribute or encapsulates an envelopedData object
1487 - an envelopedData layer
1488 - the original content (that is, a layer that is neither envelopedData nor
1489 signedData).
1491 If the MLA finds an "outer" signedData layer, then the MLA MUST perform
1492 the following steps:
1494 1. Strip off all of the signedData layers that encapsulated the "outer"
1495 signedData layer
1497 2. Strip off the "outer" signedData layer itself (after remembering the
1498 included signedAttributes)
1500 3. Expand the envelopedData (if present)
1502 4. Sign the message to be sent to the ML members in a new "outer"
1503 signedData layer that includes the signedAttributes (unless explicitly
1504 replaced) from the original, received "outer" signedData layer.
1506 If the MLA finds an "outer" signedData layer that includes an
1507 mlExpansionHistory attribute AND the MLA subsequently finds an
1508 envelopedData layer buried deeper with the layers of the received message,
1509 then the MLA MUST strip off all of the signedData layers down to the
1510 envelopedData layer (including stripping off the original "outer"
1511 signedData layer) and MUST sign the expanded envelopedData in a new "outer"
1512 signedData layer that includes the signedAttributes (unless explicitly
1513 replaced) from the original, received "outer" signedData layer.
1515 If the MLA does not find an "outer" signedData layer AND does not find an
1516 envelopedData layer, then the MLA MUST sign the original, received message
1517 in a new "outer" signedData layer. If the MLA does not find an "outer"
1518 signedData AND does find an envelopedData layer then it MUST expand the
1519 envelopedData layer, if present, and sign it in a new "outer" signedData
1520 layer.
1522 4.2.1 Examples of Rule Processing
1524 The following examples help explain the rules above:
1526 1) A message (S1(Original Content)) (where S = SignedData) is sent to the
1527 MLA in which the signedData layer does not include an MLExpansionHistory
1528 attribute. The MLA verifies and fully processes the signedAttributes in S1.
1529 The MLA decides that there is not an original, received "outer" signedData
1530 layer since it finds the original content, but never finds an envelopedData
1531 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1532 signedData layer, S2, resulting in the following message sent to the ML
1533 recipients: (S2(S1(Original Content))). The MLA includes an
1534 mlExpansionHistory attribute in S2.
1536 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which
1537 none of the signedData layers includes an MLExpansionHistory attribute. The
1538 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The
1539 MLA decides that there is not an original, received "outer" signedData
1540 layer since it finds the original content, but never finds an envelopedData
1541 and never finds an mlExpansionHistory attribute. The MLA calculates a new
1542 signedData layer, S4, resulting in the following message sent to the ML
1543 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an
1544 mlExpansionHistory attribute in S4.
1546 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent
1547 to the MLA in which S1 does not include an MLExpansionHistory attribute.
1548 The MLA decides that there is not an original, received "outer" signedData
1549 layer since it finds the E1 as the outer layer. The MLA expands the
1550 recipientInformation in E1. The MLA calculates a new signedData layer, S2,
1551 resulting in the following message sent to the ML recipients:
1552 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory
1553 attribute in S2.
1555 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
1556 includes an MLExpansionHistory attribute. The MLA verifies the signature
1557 and fully processes the signedAttributes in S2. The MLA finds the
1558 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
1559 signedData. The MLA remembers the signedAttributes included in S2 for later
1560 inclusion in the new outer signedData that it applies to the message. The
1561 MLA strips off S2. The MLA then expands the recipientInformation in E1
1562 (this invalidates the signature in S2 which is why it was stripped). The
1563 MLA calculates a new signedData layer, S3, resulting in the following
1564 message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA
1565 includes in S3 the attributes from S2 (unless it specifically replaces an
1566 attribute value) including an updated mlExpansionHistory attribute.
1568 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1569 none of the signedData layers include an MLExpansionHistory attribute. The
1570 MLA verifies the signature and fully processes the signedAttributes in S3
1571 and S2. When the MLA encounters E1, then it decides that S2 is the "outer"
1572 signedData since S2 encapsulates E1. The MLA remembers the signedAttributes
1573 included in S2 for later inclusion in the new outer signedData that it
1574 applies to the message. The MLA strips off S3 and S2. The MLA then expands
1575 the recipientInformation in E1 (this invalidates the signatures in S3 and
1576 S2 which is why they were stripped). The MLA calculates a new signedData
1577 layer, S4, resulting in the following message sent to the ML recipients:
1578 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1579 S2 (unless it specifically replaces an attribute value) and includes a new
1580 mlExpansionHistory attribute.
1582 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
1583 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies
1584 the signature and fully processes the signedAttributes in S3. The MLA finds
1585 the mlExpansionHistory in S3, so it decides that S3 is the "outer"
1586 signedData. The MLA remembers the signedAttributes included in S3 for later
1587 inclusion in the new outer signedData that it applies to the message. The
1588 MLA keeps on parsing encapsulated layers because it must determine if there
1589 are any eSSSecurityLabel attributes contained within. The MLA verifies the
1590 signature and fully processes the signedAttributes in S2. When the MLA
1591 encounters E1, then it strips off S3 and S2. The MLA then expands the
1592 recipientInformation in E1 (this invalidates the signatures in S3 and S2
1593 which is why they were stripped). The MLA calculates a new signedData
1594 layer, S4, resulting in the following message sent to the ML recipients:
1595 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from
1596 S3 (unless it specifically replaces an attribute value) including an
1597 updated mlExpansionHistory attribute.
1599 4.2.3 Processing Choices
1601 The processing used depends on the type of the outermost layer of the
1602 message. There are three cases for the type of the outermost data:
1603 - EnvelopedData
1604 - SignedData
1605 - data
1607 4.2.3.1 Processing for EnvelopedData
1609 1. The MLA locates its own RecipientInfo and uses the information it
1610 contains to obtain the message key.
1612 2. The MLA removes the existing recipientInfos field and replaces it with a
1613 new recipientInfos value built from RecipientInfo structures created for
1614 each member of the mailing list. The MLA also removes the existing
1615 originatorInfo field and replaces it with a new originatorInfo value built
1616 from information describing the MLA.
1618 3. The MLA encapsulates the expanded encrypted message in a SignedData
1619 block, adding an mlExpansionHistory attribute as described in the "Mail
1620 List Expansion" section to document the expansion.
1622 4. The MLA signs the new message and delivers the updated message to mail
1623 list members to complete MLA processing.
1625 4.2.3.2 Processing for SignedData
1627 MLA processing of multi-layer messages depends on the type of data in each
1628 of the layers. Step 3 below specifies that different processing will take
1629 place depending on the type of CMS message that has been signed. That is,
1630 it needs to know the type of data at the next inner layer, which may or may
1631 not be the innermost layer.
1633 1. The MLA verifies the signature value found in the outermost SignedData
1634 layer associated with the signed data. MLA processing of the message
1635 terminates if the message signature is invalid.
1637 2. If the outermost SignedData layer includes an signed mlExpansionHistory
1638 attribute, the MLA checks for an expansion loop as described in the
1639 "Detecting Mail List Expansion Loops" section, then go to step 3. If the
1640 outermost SignedData layer does not include an signed mlExpansionHistory
1641 attribute, go directly to step 4.
1643 3. Determine the type of the data that has been signed. That is, look at
1644 the type of data on the layer just below the SignedData, which may or may
1645 not be the "innermost" layer. Based on the type of data, perform either
1646 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other
1647 types).
1649 3.1. If the signed data is EnvelopedData, the MLA performs expansion
1650 processing of the encrypted message as described previously. Note that
1651 this process invalidates the signature value in the outermost
1652 SignedData layer associated with the original encrypted message.
1653 Proceed to section 3.2 with the result of the expansion.
1655 3.2. If the signed data is SignedData, or is the result of expanding an
1656 EnvelopedData block in step 3.1:
1658 3.2.1. The MLA strips the existing outermost SignedData layer after
1659 remembering the value of the mlExpansionHistory and all other
1660 signed attributes in that layer, if present.
1662 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
1663 encapsulates the expanded encrypted message in a new outermost
1664 SignedData layer. On the other hand, if the signed data is
1665 SignedData (from step 3.2), the MLA encapsulates the signed data in
1666 a new outermost SignedData layer.
1668 3.2.3. The outermost signedData layer created by the MLA replaces
1669 the original outermost signedData layer.�The MLA MUST create an
1670 signed attribute list for the new outermost signedData layer which
1671 MUST include each signed attribute present in the original
1672 outermost signedData layer, unless the MLA explicitly replaces one
1673 or more particular attributes with new value.�A special case is the
1674 mlExpansionHistory attribute.�The MLA MUST add an
1675 mlExpansionHistory signed attribute to the outer signedData layer
1676 as follows:
1678 3.2.3.1. If the original outermost SignedData layer included an
1679 mlExpansionHistory attribute, the attribute's value is copied
1680 and updated with the current ML expansion information as
1681 described in the "Mail List Expansion" section.
1683 3.2.3.2. If the original outermost SignedData layer did not
1684 include an mlExpansionHistory attribute, a new attribute value
1685 is created with the current ML expansion information as
1686 described in the "Mail List Expansion" section.
1688 3.3. If the signed data is not EnvelopedData or SignedData:
1690 3.3.1. The MLA encapsulates the received signedData object in an
1691 outer SignedData object, and adds an mlExpansionHistory attribute
1692 to the outer SignedData object containing the current ML expansion
1693 information as described in the "Mail List Expansion" section.
1695 4. The MLA signs the new message and delivers the updated message to mail
1696 list members to complete MLA processing.
1698 A flow chart for the above steps would be:
1700 1. Has a valid signature?
1701 YES -> 2.
1702 NO -> STOP.
1703 2. Does outermost SignedData layer contain mlExpansionHistory?
1704 YES -> Check it, then -> 3.
1705 NO -> 4.
1706 3. Check type of data just below outermost
1707 SignedData.
1708 EnvelopedData -> 3.1.
1709 SignedData -> 3.2.
1710 all others -> 3.3.
1711 3.1. Expand the encrypted message, then -> 3.2.
1712 3.2. -> 3.2.1.
1713 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory
1714 and other signed attributes, then -> 3.2.2.
1715 3.2.2. Encapsulate in new signature, then -> 3.2.3.
1716 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory?
1717 YES -> copy the old mlExpansionHistory values, then -> 4.
1718 NO -> create new mlExpansionHistory value, then -> 4.
1719 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory
1720 attribute, then -> 4.
1721 4. Sign message, deliver it, STOP.
1723 4.2.3.3 Processing for data
1725 1. The MLA encapsulates the message in a SignedData layer, and adds an
1726 mlExpansionHistory attribute containing the current ML expansion
1727 information as described in the "Mail List Expansion" section.
1729 2. The MLA signs the new message and delivers the updated message to mail
1730 list members to complete MLA processing.
1732 4.3 Mail List Agent Signed Receipt Policy Processing
1734 If a mailing list (B) is a member of another mailing list (A), list B often
1735 needs to propagate forward the mailing list receipt policy of A. As a
1736 general rule, a mailing list should be conservative in propagating forward
1737 the mailing list receipt policy because the ultimate recipient need only
1738 process the last item in the ML expansion history. The MLA builds the
1739 expansion history to meet this requirement.
1741 The following table describes the outcome of the union of mailing list A's
1742 policy (the rows in the table) and mailing list B's policy (the columns in
1743 the table).
1745 | B's policy
1746 A's policy | none insteadOf inAdditionTo missing
1747 -------------------------------------------------------------------------
1748 none | none none none none
1749 insteadOf | none insteadOf(B) *1 insteadOf(A)
1750 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A)
1751 missing | none insteadOf(B) inAdditionTo(B) missing
1753 *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
1754 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
1756 4.4 Mail List Expansion History Syntax
1758 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
1759 there are more than ub-ml-expansion-history mailing lists in the sequence,
1760 the receiving agent should provide notification of the error to a human
1761 mail list administrator.�The mail list administrator is responsible for
1762 correcting the overflow condition.
1764 MLExpansionHistory ::= SEQUENCE
1765 SIZE (1..ub-ml-expansion-history) OF MLData
1767 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1768 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
1770 ub-ml-expansion-history INTEGER ::= 64
1772 MLData contains the expansion history describing each MLA that has
1773 processed a message. As an MLA distributes a message to members of an ML,
1774 the MLA records its unique identifier, date and time of expansion, and
1775 receipt policy in an MLData structure.
1777 MLData ::= SEQUENCE {
1778 mailListIdentifier EntityIdentifier,
1779 -- EntityIdentifier is imported from [CMS]
1780 expansionTime GeneralizedTime,
1781 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
1783 EntityIdentifier ::= CHOICE {
1784 issuerAndSerialNumber IssuerAndSerialNumber,
1785 subjectKeyIdentifier SubjectKeyIdentifier }
1787 The receipt policy of the ML can withdraw the originator's request for the
1788 return of a signed receipt. However, if the originator of the message has
1789 not requested a signed receipt, the MLA cannot request a signed receipt. In
1790 the event that a ML's signed receipt policy supersedes the originator's
1791 request for signed receipts, such that the originator will not receive any
1792 signed receipts, then the MLA MAY inform the originator of that fact.
1794 When present, the mlReceiptPolicy specifies a receipt policy that
1795 supersedes the originator's request for signed receipts. The policy can be
1796 one of three possibilities: receipts MUST NOT be returned (none); receipts
1797 should be returned to an alternate list of recipients, instead of to the
1798 originator (insteadOf); or receipts should be returned to a list of
1799 recipients in addition to the originator (inAdditionTo).
1801 MLReceiptPolicy ::= CHOICE {
1802 none [0] NULL,
1803 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
1804 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
1806 5. Signing Certificate Attribute
1808 Concerns have been raised over the fact that the certificate which the
1809 signer of a CMS SignedData object desired to be bound into the verification
1810 process of the SignedData object is not cryptographically bound into the
1811 signature itself. This section addresses this issue by creating a new
1812 attribute to be placed in the signed attributes section of a SignerInfo
1813 object.
1815 This section also presents a description of a set of possible attacks
1816 dealing with the substitution of one certificate to verify the signature
1817 for the desired certificate. A set of ways for preventing or addressing
1818 these attacks is presented to deal with the simplest of the attacks.
1820 Attribute certificates can be used as part of a signature verification
1821 process. There is no way in CMS to include the list of attribute
1822 certificates to be used in the verification process. The set of attribute
1823 certificates used in the signature verification process needs to have the
1824 ability for the signer to restrict the set of certificates. This
1825 information needs to be encoded in a manner that is covered by the
1826 signature on the SignedData object. The methods in this section allows for
1827 the set of attribute certificates to be listed as part of the signing
1828 certificate attribute.
1830 Explicit certificate policies can also be used as part of a signature
1831 verification process. If a signer desires to state an explicit certificate
1832 policy that should be used when validating the signature, that policy needs
1833 to be cryptographically bound into the signing process. The methods
1834 described in this section allows for a set of certificate policy statements
1835 to be listed as part of the signing certificate attribute.
1837 5.1. Attack Descriptions
1839 At least three different attacks can be launched against a possible
1840 signature verification process by changing the certificate or certficates
1841 used in the signature verification process.
1843 5.1.1 Substitution Attack Description
1845 The first attack deals with simple substitution of one certificate for
1846 another certificate. In this attack, the issuer and serial number in the
1847 SignerInfo is modified to refer to a new certificate. This new certificate
1848 is used during the signature verification process.
1850 The first version of this attack is a simple denial of service attack where
1851 an invalid certificate is substituted for the valid certificate. This
1852 renders the message unverifiable, as the public key in the certificate no
1853 longer matches the private key used to sign the message.
1855 The second version is a substitution of one valid certificate for the
1856 original valid certificate where the public keys in the certificates match.
1857 This allows the signature to be validated under potentially different
1858 certificate constraints than the originator of the message intended.
1860 5.1.2 Reissue of Certificate Description
1862 The second attack deals with a certificate authority (CA) re-issuing the
1863 signing certificate (or potentially one of its certificates). This attack
1864 may start becoming more frequent as Certificate Authorities reissue their
1865 own root certificates, or as certificate authorities change policies in the
1866 certificate while reissuing their root certificates. This problem also
1867 occurs when cross certificates (with potentially different restrictions)
1868 are used in the process of verifying a signature.
1870 5.1.3 Rogue Duplicate CA Description
1872 The third attack deals with a rogue entity setting up a certificate
1873 authority that attempts to duplicate the structure of an existing CA.
1874 Specifically, the rogue entity issues a new certificate with the same
1875 public keys as the signer used, but signed by the rogue entity's private
1876 key.
1878 5.2 Attack Responses
1880 This document does not attempt to solve all of the above attacks; however,
1881 a brief description of responses to each of the attacks is given in this
1882 section.
1884 5.2.1 Substitution Attack Response
1886 The denial of service attack cannot be prevented. After the certificate
1887 identifier has been modified in transit, no verification of the signature
1888 is possible. There is also no way to automatically identify the attack
1889 because it is indistinguishable from a message corruption.
1891 The substitution of a valid certificate can be responded to in two
1892 different manners. The first is to make a blanket statement that the use of
1893 the same public key in two different certificates is bad practice and has
1894 to be avoided. In practice, there is no practical way to prevent users from
1895 getting new certificates with the same public keys, and it should be
1896 assumed that they will do this. Section 5.4 provides a new attribute that
1897 can be included in the SignerInfo signed attributes. This binds the correct
1898 certificate identifier into the signature. This will convert the attack
1899 from a potentially successful one to simply a denial of service attack.
1901 5.2.2 Reissue of Certificate Response
1903 A CA should never reissue a certificate with different attributes.
1904 Certificate Authorities that do so are following poor practices and cannot
1905 be relied on. Using the hash of the certificate as the reference to the
1906 certificate prevents this attach for end-entity certificates.
1908 Preventing the attack based on reissuing of CA certificates would require a
1909 substantial change to the usage of the signingCertificate attribute
1910 presented in section 5.4. It would require that ESSCertIDs would need to be
1911 included in the attribute to represent the issuer certificates in the
1912 signer's certification path. This presents problems when the relying party
1913 is using a cross-certificate as part of its authentication process, and
1914 this certificate does not appear on the list of certificates. The problems
1915 outside of a closed PKI make the addition of this information prone to
1916 error, possibly causing the rejection of valid chains.
1918 5.2.3 Rogue Duplicate CA Response
1920 The best method of preventing this attack is to avoid trusting the rogue
1921 CA. The use of the hash to identify certificates prevents the use of
1922 end-entity certificates from the rogue authority. However the only true way
1923 to prevent this attack is to never trust the rogue CA.
1925 5.3 Related Signature Verification Context
1927 Some applications require that additional information be used as part of
1928 the signature validation process. In particular, attribute certificates and
1929 policy identifiers provide additional information about the abilities and
1930 intent of the signer. The signing certificate attribute described in
1931 Section 5.4 provides the ability to bind this context information as part
1932 of the signature.
1934 5.3.1 Attribute Certificates
1936 Some applications require that attribute certificates be validated. This
1937 validation requires that the application be able to find the correct
1938 attribute certificates to perform the verification process; however there
1939 is no list of attribute certificates in a SignerInfo object. The sender has
1940 the ability to include a set of attribute certificates in a SignedData
1941 object. The receiver has the ability to retrieve attribute certificates
1942 from a directory service. There are some circumstances where the signer may
1943 wish to limit the set of attribute certificates that may be used in
1944 verifying a signature. It is useful to be able to list the set of attribute
1945 certificates the signer wants the recipient to use in validating the
1946 signature.
1948 5.3.2 Policy Information
1950 A related aspect of the certificate binding is the issue of multiple
1951 certification paths. In some instances, the semantics of a certificate in
1952 its use with a message may depend on the Certificate Authorities and
1953 policies that apply. To address this issue, the signer may also wish to
1954 bind that context under the signature. While this could be done by either
1955 signing the complete certification path or a policy ID, only a binding for
1956 the policy ID is described here.
1958 5.4 Signing Certificate Attribute Definition
1960 The signing certificate attribute is designed to prevent the simple
1961 substitution and re-issue attacks, and to allow for a restricted set of
1962 attribute certificates to be used in verifying a signature.
1964 The definition of SigningCertificate is
1966 SigningCertificate ::= SEQUENCE {
1967 certs SEQUENCE OF ESSCertID,
1968 policies SEQUENCE OF PolicyInformation OPTIONAL
1969 }
1971 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
1972 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
1973 smime(16) id-aa(2) 12 }
1975 The first certificate identified in the sequence of certificate identifiers
1976 MUST be the certificate used to verify the signature. The encoding of the
1977 ESSCertID for this certificate SHOULD NOT include the issuerSerial because
1978 the issuerAndSerialNumber is already present in the SignerInfo. The
1979 certificate identified is used during the signature verification process.
1980 If the hash of the certificate does not match the certificate used to
1981 verify the signature, the signature MUST be considered invalid.
1983 If more than one certificate is present in the sequence of ESSCertIDs, the
1984 certificates after the first one limit the set of attribute certificates
1985 that are used during signature validation. The issuerSerial SHOULD be
1986 present in these certificates, unless the client who is validating the
1987 signature is expected to have easy access to all the certificates required
1988 for validation. If only the signing certificate is present in the sequence.
1989 there are no restrictions on the set of attribute certificates used in
1990 validating the signature.
1992 The sequence of policy information terms identifies those certificate
1993 policies that the signer asserts apply to the certificate, and under which
1994 the certificate should be relied upon. This value suggests a policy value
1995 to be used in the relying party's certification path validation.
1997 If present, the SigningCertificate attribute MUST be a signed attribute; it
1998 MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF
1999 Attribute. A SignerInfo MUST NOT include multiple instances of the
2000 SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed
2001 attributes to include attrValues SET OF AttributeValue. A
2002 SigningCertificate attribute MUST include only a single instance of
2003 AttributeValue. There MUST NOT be zero or multiple instances of
2004 AttributeValue present in the attrValues SET OF AttributeValue.
2006 5.4.1 Certificate Identification
2008 The best way to identify certificates is an often-discussed issue. CMS has
2009 imposed a restriction for SignedData objects that the issuer DN must be
2010 present in all signing certificates. The issuer/serial number pair is
2011 therefore sufficient to identify the correct signing certificate. This
2012 information is already present, as part of the SignerInfo object, and
2013 duplication of this information would be unfortunate. A hash of the entire
2014 certificate serves the same function (allowing the receiver to verify that
2015 the same certificate is being used as when the message was signed), is
2016 smaller, and permits a detection of the simple substitution attacks.
2018 Attribute certificates do not have an issuer/serial number pair represented
2019 anywhere in a SignerInfo object. When an attribute certificate is not
2020 included in the SignedData object, it becomes much more difficult to get
2021 the correct set of certificates based only on a hash of the certificate.
2022 For this reason, attribute certificates are identified by the IssuerSerial
2023 object.
2025 This document defines a certificate identifier as:
2027 ESSCertID ::= SEQUENCE {
2028 certHash Hash,
2029 issuerSerial IssuerSerial OPTIONAL
2030 }
2032 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
2034 IssuerSerial ::= SEQUENCE {
2035 issuer GeneralNames,
2036 serialNumber CertificateSerialNumber
2037 }
2039 When creating an ESSCertID, the certHash is computed over the entire DER
2040 encoded certificate including the signature. The issuerSerial would
2041 normally be present unless the value can be inferred from other
2042 information.
2044 When encoding IssuerSerial, serialNumber is the serial number that uniquely
2045 identifies the certificate. For non-attribute certificates, the issuer MUST
2046 contain only the issuer name from the certificate encoded in the
2047 directoryName choice of GeneralNames. For attribute certificates, the
2048 issuer MUST contain the issuer name field from the attribute certificate.
2050 6. Security Considerations
2052 This entire document discusses security.
2054 A. ASN.1 Module
2056 ExtendedSecurityServices
2057 { iso(1) member-body(2) us(840) rsadsi(113549)
2058 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
2060 DEFINITIONS IMPLICIT TAGS ::=
2061 BEGIN
2063 IMPORTS
2065 -- Cryptographic Message Syntax (CMS)
2066 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version
2067 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
2068 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
2070 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
2071 -- 1988 Syntax
2072 PolicyInformation FROM PKIX1Implicit88 {iso(1)
2073 identified-organization(3) dod(6) internet(1) security(5)
2074 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
2076 -- X.509
2077 GeneralNames, CertificateSerialNumber FROM CertificateExtensions
2078 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
2080 -- Extended Security Services
2082 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
2083 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
2084 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
2085 -- have at least one entry. MAX indicates the upper bound is unspecified.
2086 -- Implementations are free to choose an upper bound that suits their
2087 -- environment.
2089 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
2090 -- The contents are formatted as described in [UTF8]
2092 -- Section 2.7
2094 ReceiptRequest ::= SEQUENCE {
2095 signedContentIdentifier ContentIdentifier,
2096 receiptsFrom ReceiptsFrom,
2097 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
2099 ub-receiptsTo INTEGER ::= 16
2101 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2102 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
2104 ContentIdentifier ::= OCTET STRING
2106 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2107 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
2109 ReceiptsFrom ::= CHOICE {
2110 allOrFirstTier [0] AllOrFirstTier,
2111 -- formerly "allOrNone [0]AllOrNone"
2112 receiptList [1] SEQUENCE OF GeneralNames }
2114 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
2115 allReceipts (0),
2116 firstTierRecipients (1) }
2118 -- Section 2.8
2120 Receipt ::= SEQUENCE {
2121 version Version, -- Version is imported from [CMS]
2122 contentType ContentType,
2123 signedContentIdentifier ContentIdentifier,
2124 originatorSignatureValue OCTET STRING }
2126 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2127 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
2129 -- Section 2.9
2131 ContentHints ::= SEQUENCE {
2132 � contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
2133 � contentType ContentType }
2135 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
2136 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
2138 -- Section 2.10
2140 MsgSigDigest ::= OCTET STRING
2142 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2143 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
2145 -- Section 2.11
2147 ContentReference ::= SEQUENCE {
2148 contentType ContentType,
2149 signedContentIdentifier ContentIdentifier,
2150 originatorSignatureValue OCTET STRING }
2152 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2153 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
2155 -- Section 3.2
2157 ESSSecurityLabel ::= SET {
2158 security-policy-identifier SecurityPolicyIdentifier,
2159 security-classification SecurityClassification OPTIONAL,
2160 privacy-mark ESSPrivacyMark OPTIONAL,
2161 security-categories SecurityCategories OPTIONAL }
2163 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2164 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
2166 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
2168 SecurityClassification ::= INTEGER {
2169 unmarked (0),
2170 unclassified (1),
2171 restricted (2),
2172 confidential (3),
2173 secret (4),
2174 top-secret (5) } (0..ub-integer-options)
2176 ub-integer-options INTEGER ::= 256
2178 ESSPrivacyMark ::= CHOICE {
2179 ��� pString����� PrintableString (SIZE (1..ub-privacy-mark-length)),
2180 ��� utf8String�� UTF8String (SIZE (1..MAX))
2181 }
2183 ub-privacy-mark-length INTEGER ::= 128
2185 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
2186 SecurityCategory
2188 ub-security-categories INTEGER ::= 64
2190 SecurityCategory ::= SEQUENCE {
2191 type [0] OBJECT IDENTIFIER,
2192 value [1] ANY DEFINED BY type -- defined by type
2193 }
2195 --Note: The aforementioned SecurityCategory syntax produces identical
2196 --hex encodings as the following SecurityCategory syntax that is
2197 --documented in the X.411 specification:
2198 --
2199 --SecurityCategory ::= SEQUENCE {
2200 -- type [0] SECURITY-CATEGORY,
2201 -- value [1] ANY DEFINED BY type }
2202 --
2203 --SECURITY-CATEGORY MACRO ::=
2204 --BEGIN
2205 --TYPE NOTATION ::= type | empty
2206 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
2207 --END
2209 -- Section 3.4
2211 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
2213 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2214 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
2216 -- Section 4.4
2218 MLExpansionHistory ::= SEQUENCE
2219 SIZE (1..ub-ml-expansion-history) OF MLData
2221 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
2222 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
2224 ub-ml-expansion-history INTEGER ::= 64
2226 MLData ::= SEQUENCE {
2227 mailListIdentifier EntityIdentifier,
2228 -- EntityIdentifier is imported from [CMS]
2229 expansionTime GeneralizedTime,
2230 mlReceiptPolicy MLReceiptPolicy OPTIONAL }
2232 EntityIdentifier ::= CHOICE {
2233 issuerAndSerialNumber IssuerAndSerialNumber,
2234 subjectKeyIdentifier SubjectKeyIdentifier }
2236 MLReceiptPolicy ::= CHOICE {
2237 none [0] NULL,
2238 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
2239 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
2241 -- Section 5.4
2243 SigningCertificate ::= SEQUENCE {
2244 certs SEQUENCE OF ESSCertID,
2245 policies SEQUENCE OF PolicyInformation OPTIONAL
2246 }
2248 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
2249 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
2250 smime(16) id-aa(2) 12 }
2252 ESSCertID ::= SEQUENCE {
2253 certHash Hash,
2254 issuerSerial IssuerSerial OPTIONAL
2255 }
2257 Hash ::= OCTET STRING -- SHA1 hash of entire certificate
2259 IssuerSerial ::= SEQUENCE {
2260 issuer GeneralNames,
2261 serialNumber CertificateSerialNumber
2262 }
2264 END -- of ExtendedSecurityServices
2266 B. References
2268 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
2269 Notation One (ASN.1)"
2271 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
2272 Notation One (ASN.1)"
2274 [CERT] "S/MIME Version 3 Certificate Handling", Internet Draft
2275 draft-ietf-smime-cert-xx.
2277 [CMS] "Cryptographic Message Syntax", Internet Draft
2278 draft-ietf-smime-cms-xx.
2280 [MSG] "S/MIME Version 3 Message Specification", Internet Draft
2281 draft-ietf-smime-msg-xx.
2283 [MUSTSHOULD] "Key Words for Use in RFCs to Indicate Requirement Levels",
2284 RFC 2119.
2286 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP)
2287 4.0", Specification SDN.701, Revision A, 1997-02-06.
2289 [MTSABS] "1988 International Telecommunication Union (ITU) Data
2290 Communication Networks Message Handling Systems: Message Transfer System:
2291 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7,
2292 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
2293 mts(3) modules(0) mts-abstract-service(1)}
2295 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315.
2297 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
2298 "S/MIME Version 2 Certificate Handling", RFC 2312.
2300 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
2302 C. Acknowledgments
2304 The first draft of this work was prepared by David Solo. John Pawling did a
2305 huge amount of very detailed revision work during the many phases of the
2306 document.
2308 Many other people have contributed hard work to this draft, including:
2309 Andrew Farrell
2310 Bancroft Scott
2311 Bengt Ackzell
2312 Bill Flanigan
2313 Blake Ramsdell
2314 Carlisle Adams
2315 David Kemp
2316 Denis Pinkas
2317 Jim Schaad
2318 Russ Housley
2319 Scott Hollenbeck
2320 Steve Dusse
2322 D. Changes from draft-ietf-smime-ess-09 to draft-ietf-smime-ess-10
2324 Numerous small clarifications throughout.
2326 Changed the [SMIME3] reference to [CERT] and [MSG].
2328 1: Added paragraph about usefulness of attributes for other
2329 purposes. Also added reference to [MUSTSHOULD].
2331 1.3.4: Added note about [ESS].
2333 2.3: Added explanation at the end of the first paragraph about why
2334 you might get more than one receipt request. Also changed "conflict"
2335 to "are not the same" in the second paragraph.
2337 2.9, 3.2: Added parentheses around SIZE declarations. Also in Appendix
2338 A.
2340 4.2.3.2: Changed step 2 to say that if mlExpansionHistory isn't found,
2341 skip to step 4. Also updated the flow chart.
2343 5.4: Filled in the TBD of the id-aa-signingCertificate OID. Also in
2344 Appendix A.
2346 A: Fixed some bugs in the headers caused by typos.
2348 E. Editor's Address
2350 Paul Hoffman
2351 Internet Mail Consortium
2352 127 Segre Place
2353 Santa Cruz, CA 95060
2354 (831) 426-9827
2355 phoffman@imc.org