Internet Draft J. Levine. Expires: April 18, 2005 Taughannock Networks Ray Everett-Church ePrivacy Group Vince Schiavone ePrivacy Group October 18, 2004 The Trusted Email Open Standard (TEOS) draft-levine-epg-teos-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2005. By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is intended to evolve, based on comments from readers. Comments and corrections are welcome, and may be sent to . Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Trusted Email Open Standard (TEOS) is a multi-level identity system for SMTP e-mail. It uses signatures to authenticate the identity of the sender of a message, and further permits the secure transmission of assertions about Internet Draft Trusted Email Open Standard [Page 1] Internet Draft October 18, 2004 each message including the type of message, third-party certifications, and graphical trust marks. Table of Contents 1. Introduction ............................................ 2 2. Basic Identity Signatures ............................... 3 3. Signature locations ..................................... 3 3.1. Header signatures ................................... 3 3.2. Body signatures ..................................... 4 3.2.1. Plain text message signatures ................... 4 3.2.2. HTML message signatures ......................... 4 4. Key Management .......................................... 4 5. Signature Trust Levels .................................. 5 5.1. Minimal signatures .................................. 5 5.2. Bulk Sender Trusted Email Signatures ................ 5 5.3. Consumer Oriented Trusted Email Certification Signatures 5 6. Security Considerations ................................. 6 7. Informative References .................................. 6 8. Authors' Addresses ...................................... 7 1. Introduction The Trusted Email Open Standard (TEOS) describes three levels of e-mail message authentication. The simplest level allows a domain to sign its own mail and to add optional assertions about the type of each message, such as advertisement, transactional mail, or personal mail. The second level, Bulk Sender Trusted Email Certification, adds third-party certification, with required assertions about message type, the relationship and permission of sender relative to the recipient, and a standardized opt-out, and more optional assertions about the mail depending on the details of the third party's certification program. The third level, Consumer Oriented Trusted Email Certification, adds more stringent verification of sender identity, a graphical seal that recipients can check to verify the source of the message, and a dispute resolution process when recipients challenge the sender's characterization of the mail. This document primarily focuses on the technical aspects of the identity and assertions. More information on the structure of certification programs can be found in [1]. Internet Draft Trusted Email Open Standard [Page 2] Internet Draft October 18, 2004 2. Basic Identity Signatures A basic identity is known as a Trusted Email Domain Identity (TEDI). The message signature can optionally also contain some Trusted Email Type Assertions, codes that the sender can use to describe the type of a message. The type codes depend on the schema used for a signature, but might include a set like these: 1. Unsolicited advertisements 2. Adult 3. Permission-based advertisements, offers 4. Invoices, statements, notices and customer service messages 5. Subscriptions 6. Official government email 7. Business to business or employee 8. Personal, friends and family 9. Non-profit, charitable Note that in basic identity signatures, there is no provision for validating the assertions; they are simply the sender's description of the mail. 3. Signature locations TEOS puts signatures in two places, in message headers for the benefit of automated checkers, and in the body of the message for the benefit of human recipients. 3.1. Header signatures TEOS adds two header lines to the message. One is an X-TEOS- Key header which includes the signing key used for the message. The other is an X-TEOS-1 header which includes information about the message in a securely signed form. The X-TEOS-Key header includes the exponent and modulus of the message's RSA signing key, along with a version of them signed by a verification service's signing key. (See "Key Management", below.) The three are represented as a colon- separated triple of base64 fields. All three are on a single line, which is broken here for display purposes. base64( public_exponent ): base64( modulus ): signed( base64( modulus ):base64( public_exponent ) ) The X-TEOS-1 header includes a set of features extracted from the message that are intended to uniquely identify it. The features include the To and From addresses, message Subject, date, and the assertions the sender makes about the message. The information in this header also appears in the body signatures. Internet Draft Trusted Email Open Standard [Page 3] Internet Draft October 18, 2004 3.2. Body signatures When TEOS signs a message, it adds signature information to the body of the message. The body signatures are intended both to deter replay attacks in which an attacker might attach valid signed headers to a different message body, and to allow message recipients to check the validity of incoming messages and report messages that are invalid or unwanted. 3.2.1 Plain text message signatures TEOS adds a footer to plain text messages that includes a signature link, such as this: Follow Link to Verify at verify.example.org The URL includes the same information as is in the X-TEOS-1 header. If the user clicks through the URL, the verifying system checks the signature, and if it verifies presents the decoded From, To, Date, and Subject headers to the user so he or she can compare them to the contents of the message. The web site provides options so that the user can report mismatching signatures, opt-out from the sender's list, or file a complaint about the message. 3.2.2 HTML message signatures TEOS adds a more elaborate signature to HTML messages. It creates a GIF image consisting of the From, To, Date, and Subject information overlaid on the verification service's logo, and adds that image to the message as a clickable link to the verification service, using HTML similar to this:
Certified Trusted Sender message
From:
   sender@example.com
To: recip@example.org
18 Oct 2004
   Click to Verify - verify.example.org
4. Key Management Each mailer's signature key is signed by a verification service. The verification service has a role similar to that of a certificate authority that signs SSL cerficiates for web Internet Draft Trusted Email Open Standard [Page 4] Internet Draft October 18, 2004 servers. The signatures in message bodies are sent to the verification service as part of a URL, so no key management outside of the verification service is needed. The signatures in message headers are intended to be verified by recipient MTAs, so the MTA needs the verification service's certificate the check the signatures. We anticipate that the number of verification services will be relatively small, so that MTA operators that wish to verify messages certified by a service they trust can retrieve the certificate and install it into the MTA manually. The TEOS signing algorithm does not depend on the source of the keys, so that if required, it would be straightforward to add an automated key distribution system such as the one used by Domain Keys[3]. 5. Signature Trust Levels TEOS provides for message verification by creating a signature of the message header fields and optional assertions, and placing that signature both in the message header and in the message body. TEOS provides three levels of signature trust, ranging from basic to comprehensive. 5.1. Minimal signatures The minimal signature includes the sender identity and optional message assertions of the message type. 5.2. Bulk Sender Trusted Email Signatures The second level of identity provides surer identity, suitable for mail to ISPs and enterprises. It provides for certification progarams that can set standards for the senders it certifies. Each certifying party can set its own standards, including mandatory type assertions for message type and the relationship and permission status of each message. One of those assertions should be a standardized opt-out in each message. Each certifying party signs the certification of each sender they certify. 5.3. Consumer Oriented Trusted Email Certification Signatures The third level adds more features intended for mail to consumers. It includes stringent verification of sender identity and more mandatory type assertions. It also includes a dispute resolution process and trust authority described in [1]. The mandatory type assertions include all those described in the previous section, a secure verifiable Internet Draft Trusted Email Open Standard [Page 5] Internet Draft October 18, 2004 graphical seal, and a link to a privacy policy. The seal is embedded in the message and is visible in an HTML mail client. If the user clicks on it, it links to the certifying party's web site and incldes sufficient information for that web site to verify the validity of the seal and to display the sender, receipient, and the assertions about the message. 6. Security Considerations TEOS creates signatures containing a message's From, To, Signature, Date, and other material. It is intended for messages sent from a single sender to a single recipient. (For messages sent to multiple receipients, each recipient gets a separately addressed and signed copy.) When a message is received, the recipient Mail Transfer Agent can verify the signature in the message header, assuming it has the CA's verification key available, and compare the fields in the signature to those in the message headers. If the fields do not match, the message has been tampered with or damaged. Human recipients can compare the signature information displayed in the image in HTML mail, or the click-through web page from text mail, with the messge headers. Again, if they don't match, the message has been tampered with or damaged. Although it is technically possible to attach an unrelated message body to the headers and header signature of a TEOS signed message, recipients can easily detect most kinds of tampering. A TEOS signed message should have the signature image in an HTML message, or the signature footer in a text message. If it doesn't, the recipient (or for that matter the MTA) can immediately recognize that it has been tampered with. 7. Informative References [1] V. Schiavone et al, "Trusted Email Open Standard: A Comprehensive Policy and Technology Proposal for Email Reform," ePrivacy Group, 2003, http://trustedemailopenstandard.org/whitepaper.pdf. [2] D. Atkins et al, "Threat Analysis of the Domain Name System", RFC 3833, August 2004. [3] Mark Delany "Domain-based Email Authentication Using Public-Keys", http://www.ietf.org/internet-drafts/draft- delany-domainkeys-base-01.txt. August 2004. Internet Draft Trusted Email Open Standard [Page 6] Internet Draft October 18, 2004 8. Authors' Addresses John R. Levine Taughannock Networks PO Box 727 Trumansburg NY 14886 USA E-mail: johnl@taugh.com Phone: +1 607 330 5711 Ray Everett-Church P. O. Box 640454 San Jose CA 95164-0454 E-mail: ray@everett.org Vince Schiavone ePrivacy Group 1304 Meadow Lane Berwyn PA 19312 E-mail: vs@prioratus.com Full Copyright Statement Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. 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 must 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 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Internet Draft Trusted Email Open Standard [Page 7] Internet Draft October 18, 2004 $Id: draft-epg-teos-00.n,v 1.2 2004/10/16 18:41:49 johnl Exp johnl $ Internet Draft Trusted Email Open Standard [Page 8]