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 <teos@taugh.com>.
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
<http://verify.example.org/start_verify.php?AAIxPIGFuZCBTeW1hbnRlYw>
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:
<BODY id=ridBody background=cid:436480918@10032004-1C16>
<div align="right">
<a href="http://verify.example.org/start_verify.php?AAIxxuWAN17">
<img alt="Certified Trusted Sender message From:
sender@example.com To: recip@example.org 18 Oct 2004
Click to Verify - verify.example.org"
height="38" width="351" border="0"
src="cid:iVXBah2uTJqbX124Lwgvgkw@example.com">
</a></div>
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]