S/MIME Working Group R. Housley Internet Draft RSA Laboratories expires in six months August 2001 Intended Recipients Attribute for the Cryptographic Message Syntax (CMS) <draft-ietf-smime-ira-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the intended recipients attribute for use with the Cryptographic Message Syntax (CMS) [CMS]. The intended recipients attribute can be used as a signed attribute or as an authenticated attribute. This draft is being discussed on the "ietf-smime" mailing list. To join the list, send a message to <ietf-smime-request@imc.org> with the single word "subscribe" in the body of the message. Also, there is a Web site for the mailing list at <http://www.imc.org/ietf- smime/>. 1 Introduction Don Davis has demonstrated that recipients of signed and encrypted messages can decrypt the message, preserving the original signature, then resend the message to a new recipient [MALFWD]. The new Housley [Page 1]
INTERNET DRAFT August 2001 recipient may act inappropriately based on the fact that they received a message signed by the originator. Consider this illustrative example: Bob wants to have dinner with Alice. He writes a note, "Meet me at the Iron Gate at 7:00 tonight", signs it, encrypts it for Alice, and sends it to Alice. Alice the decrypts the message, validates the signature, and reads the message. She does not want to have dinner with Bob tonight, so for fun Alice encrypts the signed message for Carol, and sends it to Carol. Carol the decrypts the message, validates the signature, and reads the message. Carol and Bob meet for dinner. The problem is that Bob did not state the intended recipient in his message. Simply saying, "Alice, please meet me at the Iron Gate at 7:00 tonight," would have fixed the problem. In many situations, the signed message will provide adequate indication of the intended recipients to avoid malicious forwarding of signed content. For example, a Purchase Order includes information about the supplier and the purchaser. The intended recipients attribute is being defined to protect against malicious forwarding when the message content does not inherently provide a clear indication of the intended recipients. Further, the intended recipients attribute can protect an originator of an interpersonal message in face of name collisions and typographical error. Suppose that Alice begins her message with "Dear Bill." Such a message is susceptible to forwarding to other recipients named Bill. Further, if Alice made an simple typographic error and intended to begin here message with "Dear Will," then Will (the intended recipient) is unsure if Alice meant to send him the message, and the message is easily forwarded to a person named Bill. The problem of intent that as expressed in [MALFWD] is beyond the control of S/MIME protocol or its implementers. The use of the digital signatures and encryption is correctly in the hands of the user. However, the intended recipients attribute offers a mechanism to reduce the likelihood of undetected malicious forwarding. Housley [Page 2]
INTERNET DRAFT August 2001 2 Terminology In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described by Scott Bradner in [STDWORDS]. 3 Intended Recipients Attribute Syntax The intended-recipients attribute type specifies the list of recipients that the message originator intended to receive the message. It includes the members of the TO list and the CC list. However, members of the BCC list are not included. Including members of the BCC list would disclose the membership to the other recipients. The intended-recipients attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute or unauthenticated attribute. In the triple wrapper model described in RFC 2634 [ESS], the intended-recipients attribute MUST only appear in the inner signature. The following object identifier identifies the intended-recipients attribute: id-aa-intendedRecipients OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 33 } The intended-recipients attribute values have ASN.1 type GeneralNames. GeneralNames is specified in [PROFILE], but the definition is repeated here for reader convenience: GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER} OtherName ::= SEQUENCE { Housley [Page 3]
INTERNET DRAFT August 2001 type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } EDIPartyName ::= SEQUENCE { nameAssigner [0] DirectoryString OPTIONAL, partyName [1] DirectoryString } An intended-recipients attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. The SignedAttributes and AuthAttributes syntaxes are each defined as a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the intended-recipients attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST NOT include multiple instances of the intended-recipients attribute. One GeneralName MUST appear in the SEQUENCE for each intended recipient. The order of the names is not important. (A SEQUENCE is used instead of a SET to avoid the sorting associated with the distinguished encoding rules (DER) processing of SETs.) When used with S/MIME [MSG], the rfc822Name form of the recipient name SHOULD be used. The other forms of the recipient name are permitted since the CMS is used in other protocols as well as S/MIME. 3.1 Originator Generation Inclusion of the intended-recipients attribute is OPTIONAL. When a message content is signed but not encrypted, inclusion of the intended-recipients attribute may be counter to the originator's goal. For example, when a press release is posted wide distribution is intended. In such cases, inclusion of the intended-recipients attribute is undesirable. Originator generation of the intended-recipients attribute is simple and straightforward. Each TO list and CC list recipient is represented by on GeneralName in the SEQUENCE. Most of the time, the rfc822Name form of the recipient name is used. 3.2 Recipient Validation Recipient validation of the intended-recipients attribute is less straightforward than generation of the intended-recipients attribute. When a recipient receives the message as a member of a mail list or as a BCC list recipient, they will not be listed in the intended- recipients attribute, yet the originator does intend that this recipient receive the message content. Housley [Page 4]
INTERNET DRAFT August 2001 In the normal case, the recipient will locate their own name in the intended-recipients attribute. That is, no malicious forwarding is detected. If the received message includes a mlExpansionHistory attribute, then the recipient can presume that the message was received as a normal part of mail list distribution. A particularly paranoid implementation MAY confirm membership in at least one of the mail lists named in the intended-recipients attribute. Unfortunately, the BCC case is indistinguishable from malicious forwarding. Therefore, any display presented to a human user as a result of the recipient name not being on listed on the intended- recipient attribute SHOULD point out this possibility. 4 References CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. <Date>. {draft-ietf-smime-rfc2630bis-*.txt} ESS Hoffman, P., Editor. Enhanced Security Services for S/MIME. RFC 2634. June 1999. MALFWD Davis, D. Sender Authentication and the Surreptitious Forwarding Attack in CMS and S/MIME. RFC <TBD>. <Date>. {draft-ietf-smime-<tbd>-*.txt} MSG Ramsdell, B., Editor. S/MIME Version 3 Message Specification. RFC 2633. June 1999. PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet X.509 Public Key Infrastructure: Certificate and CRL Profile. RFC 2459. January 1999. STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate Requirement Levels. RFC 2119. March 1997. 5 Security Considerations This whole document is about a mechanism to detect the malicious forwarding of signed content [MALFWD]. The protections offered by the intended-recipients attribute are necessary when the signed content does not inherently provide an indication of the recipients that the signer intended to receive the content. Housley [Page 5]
INTERNET DRAFT August 2001 6 Acknowledgments I extend a special thanks to Don Davis and Burt Kaliski for their efforts and support. 7 Author Address Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA rhousley@rsasecurity.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Appendix A may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Housley [Page 6]