idnits 2.17.1 draft-ietf-smime-ira-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 101: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 102: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 114: '...pients attribute MUST be a signed attr...' RFC 2119 keyword, line 115: '...ed attribute; it MUST NOT be an unsign...' RFC 2119 keyword, line 119: '...pients attribute MUST only appear in t...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 2001) is 7837 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? 'CMS' on line 38 looks like a reference -- Missing reference section? 'MALFWD' on line 235 looks like a reference -- Missing reference section? 'STDWORDS' on line 104 looks like a reference -- Missing reference section? 'ESS' on line 118 looks like a reference -- Missing reference section? 'PROFILE' on line 130 looks like a reference -- Missing reference section? '0' on line 151 looks like a reference -- Missing reference section? '1' on line 152 looks like a reference -- Missing reference section? '2' on line 138 looks like a reference -- Missing reference section? '3' on line 139 looks like a reference -- Missing reference section? '4' on line 140 looks like a reference -- Missing reference section? '5' on line 141 looks like a reference -- Missing reference section? '6' on line 142 looks like a reference -- Missing reference section? '7' on line 143 looks like a reference -- Missing reference section? '8' on line 144 looks like a reference -- Missing reference section? 'MSG' on line 168 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft RSA Laboratories 4 expires in six months August 2001 6 Intended Recipients Attribute for the Cryptographic Message Syntax (CMS) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 This document describes the intended recipients attribute for use 38 with the Cryptographic Message Syntax (CMS) [CMS]. The intended 39 recipients attribute can be used as a signed attribute or as an 40 authenticated attribute. 42 This draft is being discussed on the "ietf-smime" mailing list. To 43 join the list, send a message to with 44 the single word "subscribe" in the body of the message. Also, there 45 is a Web site for the mailing list at . 48 1 Introduction 50 Don Davis has demonstrated that recipients of signed and encrypted 51 messages can decrypt the message, preserving the original signature, 52 then resend the message to a new recipient [MALFWD]. The new 53 recipient may act inappropriately based on the fact that they 54 received a message signed by the originator. 56 Consider this illustrative example: 58 Bob wants to have dinner with Alice. He writes a note, "Meet me 59 at the Iron Gate at 7:00 tonight", signs it, encrypts it for 60 Alice, and sends it to Alice. 62 Alice the decrypts the message, validates the signature, and reads 63 the message. She does not want to have dinner with Bob tonight, 64 so for fun Alice encrypts the signed message for Carol, and sends 65 it to Carol. 67 Carol the decrypts the message, validates the signature, and reads 68 the message. 70 Carol and Bob meet for dinner. 72 The problem is that Bob did not state the intended recipient in his 73 message. Simply saying, "Alice, please meet me at the Iron Gate at 74 7:00 tonight," would have fixed the problem. 76 In many situations, the signed message will provide adequate 77 indication of the intended recipients to avoid malicious forwarding 78 of signed content. For example, a Purchase Order includes 79 information about the supplier and the purchaser. 81 The intended recipients attribute is being defined to protect against 82 malicious forwarding when the message content does not inherently 83 provide a clear indication of the intended recipients. Further, the 84 intended recipients attribute can protect an originator of an 85 interpersonal message in face of name collisions and typographical 86 error. Suppose that Alice begins her message with "Dear Bill." Such 87 a message is susceptible to forwarding to other recipients named 88 Bill. Further, if Alice made an simple typographic error and 89 intended to begin here message with "Dear Will," then Will (the 90 intended recipient) is unsure if Alice meant to send him the message, 91 and the message is easily forwarded to a person named Bill. 93 The problem of intent that as expressed in [MALFWD] is beyond the 94 control of S/MIME protocol or its implementers. The use of the 95 digital signatures and encryption is correctly in the hands of the 96 user. However, the intended recipients attribute offers a mechanism 97 to reduce the likelihood of undetected malicious forwarding. 99 2 Terminology 101 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 102 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 103 described by Scott Bradner in [STDWORDS]. 105 3 Intended Recipients Attribute Syntax 107 The intended-recipients attribute type specifies the list of 108 recipients that the message originator intended to receive the 109 message. It includes the members of the TO list and the CC list. 110 However, members of the BCC list are not included. Including members 111 of the BCC list would disclose the membership to the other 112 recipients. 114 The intended-recipients attribute MUST be a signed attribute or an 115 authenticated attribute; it MUST NOT be an unsigned attribute or 116 unauthenticated attribute. 118 In the triple wrapper model described in RFC 2634 [ESS], the 119 intended-recipients attribute MUST only appear in the inner 120 signature. 122 The following object identifier identifies the intended-recipients 123 attribute: 125 id-aa-intendedRecipients OBJECT IDENTIFIER ::= 126 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 127 pkcs-9(9) smime(16) aa(2) 33 } 129 The intended-recipients attribute values have ASN.1 type 130 GeneralNames. GeneralNames is specified in [PROFILE], but the 131 definition is repeated here for reader convenience: 133 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 135 GeneralName ::= CHOICE { 136 otherName [0] OtherName, 137 rfc822Name [1] IA5String, 138 dNSName [2] IA5String, 139 x400Address [3] ORAddress, 140 directoryName [4] Name, 141 ediPartyName [5] EDIPartyName, 142 uniformResourceIdentifier [6] IA5String, 143 iPAddress [7] OCTET STRING, 144 registeredID [8] OBJECT IDENTIFIER} 146 OtherName ::= SEQUENCE { 147 type-id OBJECT IDENTIFIER, 148 value [0] EXPLICIT ANY DEFINED BY type-id } 150 EDIPartyName ::= SEQUENCE { 151 nameAssigner [0] DirectoryString OPTIONAL, 152 partyName [1] DirectoryString } 154 An intended-recipients attribute MUST have a single attribute value, 155 even though the syntax is defined as a SET OF AttributeValue. 157 The SignedAttributes and AuthAttributes syntaxes are each defined as 158 a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT 159 include multiple instances of the intended-recipients attribute. 160 Similarly, the AuthAttributes in an AuthenticatedData MUST NOT 161 include multiple instances of the intended-recipients attribute. 163 One GeneralName MUST appear in the SEQUENCE for each intended 164 recipient. The order of the names is not important. (A SEQUENCE is 165 used instead of a SET to avoid the sorting associated with the 166 distinguished encoding rules (DER) processing of SETs.) 168 When used with S/MIME [MSG], the rfc822Name form of the recipient 169 name SHOULD be used. The other forms of the recipient name are 170 permitted since the CMS is used in other protocols as well as S/MIME. 172 3.1 Originator Generation 174 Inclusion of the intended-recipients attribute is OPTIONAL. When a 175 message content is signed but not encrypted, inclusion of the 176 intended-recipients attribute may be counter to the originator's 177 goal. For example, when a press release is posted wide distribution 178 is intended. In such cases, inclusion of the intended-recipients 179 attribute is undesirable. 181 Originator generation of the intended-recipients attribute is simple 182 and straightforward. Each TO list and CC list recipient is 183 represented by on GeneralName in the SEQUENCE. Most of the time, the 184 rfc822Name form of the recipient name is used. 186 3.2 Recipient Validation 188 Recipient validation of the intended-recipients attribute is less 189 straightforward than generation of the intended-recipients attribute. 190 When a recipient receives the message as a member of a mail list or 191 as a BCC list recipient, they will not be listed in the intended- 192 recipients attribute, yet the originator does intend that this 193 recipient receive the message content. 195 In the normal case, the recipient will locate their own name in the 196 intended-recipients attribute. That is, no malicious forwarding is 197 detected. 199 If the received message includes a mlExpansionHistory attribute, then 200 the recipient can presume that the message was received as a normal 201 part of mail list distribution. A particularly paranoid 202 implementation MAY confirm membership in at least one of the mail 203 lists named in the intended-recipients attribute. 205 Unfortunately, the BCC case is indistinguishable from malicious 206 forwarding. Therefore, any display presented to a human user as a 207 result of the recipient name not being on listed on the intended- 208 recipient attribute SHOULD point out this possibility. 210 4 References 212 CMS Housley, R. Cryptographic Message Syntax. RFC . . 213 {draft-ietf-smime-rfc2630bis-*.txt} 215 ESS Hoffman, P., Editor. Enhanced Security Services for S/MIME. 216 RFC 2634. June 1999. 218 MALFWD Davis, D. Sender Authentication and the Surreptitious 219 Forwarding Attack in CMS and S/MIME. RFC . . 220 {draft-ietf-smime--*.txt} 222 MSG Ramsdell, B., Editor. S/MIME Version 3 Message 223 Specification. RFC 2633. June 1999. 225 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 226 X.509 Public Key Infrastructure: Certificate and CRL 227 Profile. RFC 2459. January 1999. 229 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 230 Requirement Levels. RFC 2119. March 1997. 232 5 Security Considerations 234 This whole document is about a mechanism to detect the malicious 235 forwarding of signed content [MALFWD]. The protections offered by 236 the intended-recipients attribute are necessary when the signed 237 content does not inherently provide an indication of the recipients 238 that the signer intended to receive the content. 240 6 Acknowledgments 242 I extend a special thanks to Don Davis and Burt Kaliski for their 243 efforts and support. 245 7 Author Address 247 Russell Housley 248 RSA Laboratories 249 918 Spring Knoll Drive 250 Herndon, VA 20170 251 USA 253 rhousley@rsasecurity.com 255 Full Copyright Statement 257 Copyright (C) The Internet Society (2001). All Rights Reserved. 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain it 261 or assist in its implementation may be prepared, copied, published 262 and distributed, in whole or in part, without restriction of any 263 kind, provided that the above copyright notice and this paragraph are 264 included on all such copies and derivative works. In addition, the 265 ASN.1 module presented in Appendix A may be used in whole or in part 266 without inclusion of the copyright notice. However, this document 267 itself may not be modified in any way, such as by removing the 268 copyright notice or references to the Internet Society or other 269 Internet organizations, except as needed for the purpose of 270 developing Internet standards in which case the procedures for 271 copyrights defined in the Internet Standards process shall be 272 followed, or as required to translate it into languages other than 273 English. 275 The limited permissions granted above are perpetual and will not be 276 revoked by the Internet Society or its successors or assigns. This 277 document and the information contained herein is provided on an "AS 278 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 279 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 280 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 281 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 282 OR FITNESS FOR A PARTICULAR PURPOSE.