WDIFF

draft-delany-domainkeys-base-00.txt --> draft-delany-domainkeys-base-01.txt

INTERNET DRAFT Mark Delany
Title: draft-delany-domainkeys-base-00.txt draft-delany-domainkeys-base-01.txt Yahoo! Inc
Expires: November 2004 May February 2005 August 2004

Domain-based Email Authentication Using Public-Keys
Advertised in the DNS (DomainKeys)

Status of this Memo

This document may not be modified, and derivative works of it may not
be created. This document may only be posted in an Internet-Draft.

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.

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

Abstract

"DomainKeys" creates a domain-level authentication framework for email
by using public-key technology and the DNS to prove the provenance and
contents of an email.

This document defines the base framework of digitally signing email on
a per-domain basis. Subsequent documents leverage this base framework
to prove and validate email delivery paths as well as extend signing
to facilitate per-user authentication.

The ultimate goal of this framework is to unequivocally prove and
protect identity while retaining the semantics of Internet email as it
is known today. Proof and protection of email identity may assist in
the global control of "spam" and "phishing".

While this document presents technical details, it is not yet intended
as a definitive or final specification, rather, the intent is to
define a framework and sufficient technical detail to promote
experimental deployment with a view to evolving into a comprehensive
authentication standard for email.

Delany Expires February, 2005 [Page 1]

Internet-Draft DomainKeys August 2004

Table of Contents

1. Introduction
1.1 Lack of authentication is damaging Internet email
1.2 Digitally signed email creates credible domain authentication
1.3 Public-keys in the DNS
1.4 Initial deployment is likely at the border MTA
1.5 Conveying verification results to UAs
1.6 Technical minutiae is are not completely covered
1.7 Motivation
1.8 Benefits of DomainKeys
1.9 Definitions
1.10 Requirements Notation

2. DomainKeys overview

3. DomainKeys detailed view
3.1 Determining the sending domain address of an email
3.2 Retrieving the public-key given the "sending domain" sending domain
3.2.1 Introducing "selectors"
3.2.2 Public-key signing and verification algorithm
3.2.3 Public-key representation in the DNS
3.2.4 Key sizes
3.3 Canonical preparation of email for signing
3.4 Storing the signature in the email header
3.4 Canonical preparation of email for signing
3.4.1 The "simple" canonicalization algorithm
3.4.2 The "nofws" canonicalization algorithm
3.5 The signing process
3.5.1 Identifying the sending domain
3.5.2 Determining if an email should be signed
3.5.3 Selecting a private-key and corresponding selector information
3.5.4 Calculating the signature value
3.5.5 Pre-pending Prepending the "DomainKey-Signature:" header
3.6 Policy statement of sending domain
3.6.1 Domain policy is nascent
3.6.2 Interim sending domain policy
3.7 The verification process
3.7.1 Verification should render a binary result
3.7.2 Extracting signature information from the headers
3.7.3 Retrieve the public-key based on the signature information
3.7.4 Verify the signature
3.7.5 Retrieving sending domain policy
3.7.6 Applying local policy
3.8 Conveying verification results to UAs

4. Example of use
4.1 The user composes an email
4.2 The email is signed
4.3 The email signature is verified

Delany Expires February, 2005 [Page 2]

Internet-Draft DomainKeys August 2004

5. Association with a Certificate Authority
5.1 The "DomainKey-X509:" header

6. Topics for discussion
6.1 The benefits of selectors
6.2 Canonicalization of email
6.3 Mailing lists
6.4 Roving users
6.5 Envelope audit

7. Security Considerations
7.1 DNS
7.1.1 The DNS is not currently secure
7.1.2 DomainKeys creates additional DNS load
7.2 Key Management
7.3 Implementation risks
7.4 Privacy assumptions with forwarding addresses

8. The trial
8.1 Goals
8.2 Constraints on participation

9. Notes to Implementors
9.1 TXT records

10. References
10.1 Normative References
10.2 Informative References

11. Acknowledgments

Appendix A - Syntax rules for the tag=value format

Appendix B - Sample "simple" canonicalization program: dk_simple_canonical

Appendix C - Sample signing shell script: dk_simple_sign

Appendix D - Sample email showing draft-01 changes

12. Change History

Author's Address

Delany Expires February, 2005 [Page 3]

Internet-Draft DomainKeys August 2004

1. Introduction

This document proposes an authentication framework for email that
stores public-keys in the DNS and digitally signs email on a domain
basis. Separate documents discuss how this framework can be extended
to validate the delivery path of email as well as facilitate per-user
authentication.

1.1 Lack of authentication is damaging Internet email

Authentication of email is not currently widespread. Not only is it
difficult to prove your own identity, it is impossible to prevent
others from abusing your identity.

While most email exchanges do not intrinsically need authentication
beyond context, it is the rampant abuse of identity by "spammers",
"phishers", and their criminal ilk that makes proof necessary. In
other words, authentication is as much about protection as proof.

Importantly, the inability to authenticate email effectively delegates
much of the control of the disposition of inbound email to the sender,
since senders can trivially assume any email address. Creating email
authentication is the first step to returning dispositional control of
email to the recipient.

For the purposes of this document, authentication is seen from a user
perspective, and is intended to answer the question "who sent this
email?" where "who" is the email address the recipient sees and "this
email" is the content that the recipient sees.

1.2 Digitally signing email creates credible domain authentication

DomainKeys combines public-key cryptography and the DNS to provide
credible domain-level authentication for email.

When an email claims to originate from a certain domain, DomainKeys
provides a mechanism by which the recipient system can credibly
determine that the email did in fact originate from a person or system
authorized to send email for that domain.

The authentication provided by DomainKeys works in a number of
scenarios in which other authentication systems fail or create complex
operational requirements. These include:

o forwarded email

o distributed sending systems

Delany Expires February, 2005 [Page 4]

Internet-Draft DomainKeys August 2004

o authorized third-party sending

This base definition of DomainKeys is intended to only enable
domain-level authenticity; whether a given message is really sent by
the purported user within the domain is outside the scope of the base
definition. Having said that, this specification includes the
possibility that some domains may wish to delegate fine-grained
authentication to individual users.

1.3 Public-keys in the DNS

DomainKeys differs from traditional hierarchical public-key systems in
that it initially leverages the DNS for public-key management, placing complete
and direct control of key generation and management with the owner of
the domain. That is, if you have control over the DNS for a given
domain, you have control over your DomainKeys for that domain.

The DNS is proposed as an interim the initial mechanism for publishing
public-keys. DomainKeys is specifically designed to be extensible to
other key fetching services as they become available.

1.4 Initial deployment is likely at the border MTA

For practical reasons, it is expected that initial implementations of
DomainKeys will be deployed on MTAs that accept or relay email across
administrative or organizational boundaries. There are numerous
advantages to deployment at the border MTA, including:

o a reduction in the number of MTAs that have to be changed to
support an implementation of DomainKeys

o a reduction in the number of MTAs involved in transmitting the
email between a signing system and a verifying system, thus
reducing the number of places that can make accidental changes
to the contents

o removing the need to implement DomainKeys within an internal
email network.

However there is no necessity to deploy DomainKeys at the border as
signing and verifying can effectively occur anywhere from the border
MTA right back to the UA. In particular the best place to sign an
email for many domains is likely to be at the point of SUBMISSION
where the sender is often authenticated through SMTP AUTH or other
identifying mechanisms.

1.5 Conveying verification results to UAs

Delany Expires February, 2005 [Page 5]

Internet-Draft DomainKeys August 2004

It follows that testing the authenticity of an email results in some
action based on the results of the test. Oftentimes the action is to
notify the UA in some way - typically via a header line.

As yet there is no standard for communicating authentication results
to UAs. To complicate matters, there are currently a number of draft
proposals that attempt to define UA notification mechanisms.

It makes a great deal of sense to consolidate the various notification
mechanisms, and this specification will adopt a unified standard as
soon as one becomes available.

However, until a unified standard exists, this specification proposes
an interim header to communicate the results of the authentication.

1.6 Technical minutiae is are not completely covered

The intent of this draft is to communicate the fundamental
characteristics of DomainKeys and come close to for an implementable
specification. However, exacting detail is avoided in preference to
conveying the main intent. Furthermore, where convenient, this
document implies specifications based on implementor. However some aspects
are derived from the implementation functionality of readily
available software, in particular the openssl command [OPENSSL].

In part this strategy is due to laziness, in part to avoid clutter,
and in part tacit acknowledgment [OPENSSL]
and, rather than duplicate that many of these details documentation, implementors are best
refined by further discussion and after trials
expected to understand the mechanics of early
implementations within the email community. openssl command,
sufficient to complete the implementation.

1.7 Motivation

The motivation for DomainKeys is to define a simple, cheap, and
"sufficiently effective" mechanism by which domain owners can control
who has authority to send email using their domain. To this end, the
designers of DomainKeys set out to build a framework which:

o is transparent and compatible with the existing email
infrastructure

o requires no new infrastructure

o can be implemented independently of clients in order to
potentially
reduce deployment time

o does not require the use of a central certificate authority
which might impose fees for certificates or introduce delays to
deployment

o does not require a "flag" day.

While we believe that DomainKeys meets these criteria, it is by no
means a perfect solution. The current Internet imposes considerable
compromises on any similar scheme, and readers should be careful not
to misinterpret the information provided in this document to imply

Delany Expires February, 2005 [Page 6]

Internet-Draft DomainKeys August 2004

that DomainKeys can make makes stronger credibility statements than it can. is able
to do.

1.8 Benefits of DomainKeys

As the reader will discover, DomainKeys is nothing more than solely an authentication
system. It is not a magic bullet for spam, nor is it an authorization
system, a reputation system, a certification system, or a trust
system.

However, a strong authentication system such as DomainKeys creates an
unimpeachable framework within which comprehensive authorization
systems, reputations systems and their ilk can be developed.

2. DomainKeys overview

Under DomainKeys, a domain owner generates one or more private/public
key-pairs that will be used

1.9 Definitions

With reference to secure messages originating from that
domain. The domain owner places the public-key in his domain
namespace (i.e., in following sample email:

Line Data
Number Bytes Content
---- --- --------------------------------------------
01 46 From: "Joe SixPack" <joe@football.example.com>
02 40 To: "Suzie Q" <suzie@shopping.example.net>
03 25 Subject: Is dinner ready?
04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
05 40 Comment: This comment has a continuation
06 51 because this line begins with folding white space
07 60 Message-ID: <20030712040037.46341@football.example.com>
08 00
09 03 Hi.
10 00
11 37 We lost the game. Are you hungry yet?
12 00
13 04 Joe.
14 00
15 00

Line 01 is the first line of the email and the first line of the
headers.

Line 05 and 06 constitute the "Content:" header.

Line 06 is a continuation header line.

Line 07 is the last line of the headers.

Line 08 is the empty line that separates the header from the body.

Line 09 is the first line of the body.

Delany Expires February, 2005 [Page 7]

Internet-Draft DomainKeys August 2004

Line 10, 12, 14 and 15 are empty lines.

Line 13 is the last non-empty line of the email.

Line 15 is the last line of the body and the last line of the email.

Line 01 to 15 constitute the complete email.

1.10 Requirements notation

This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119].

2. DomainKeys overview

Under DomainKeys, a domain owner generates one or more private/public
key-pairs that will be used to sign messages originating from that
domain. The domain owner places the public-key in his domain
namespace (i.e., in a DNS record associated with that domain), and
makes the private-key available to the outbound email system. When an
email is submitted by an authorized user of that domain, the email
system uses the private-key to digitally sign the email associated
with the sending domain. The signature is added as a header to the
email, and the message is transferred to its recipients in the usual
way.

When a message is received with a DomainKey signature header, the
receiving system can verify the signature as follows:

1. Extract the signature and claimed sending domain from the
email.

2. Fetch the public-key from the claimed sending domain namespace.

3. Use public-key to determine whether the signature of the email
has been generated with the corresponding private-key, and thus
whether the email was sent with the authority of the claimed
sending domain.

In the event that an email arrives without a signature or when the
signature verification fails, the receiving system retrieves the
policy of the claimed sending domain to ascertain the preferred
disposition of such email.

Armed with this information, the recipient system can apply local

Delany Expires February, 2005 [Page 8]

Internet-Draft DomainKeys August 2004

policy based on the results of the signature test.

3. DomainKeys detailed view

This section discusses the specifics of DomainKeys that are needed to
create interoperable implementations. This section answers the
following questions:

Given an email, how is the sending domain determined?

How is the public-key retrieved for a sending domain?

As email transits the email system, it can potentially go through a
number of changes. Which parts of the email are included in the
signature and how are they protected from such transformations?

How is the signature represented in the email?

If a signature is not present, or a verification fails, how does the
recipient determine the policy intent of the sending domain?

Finally, on verifying the authenticity of an email, how is that
result conveyed to participating UAs?

While there are many alternative design choices, most lead to
comparable functionality. The overriding selection criteria used to
choose amongst the alternatives are:

o use deployed technology whenever possible

o prefer ease of implementation

o avoid trading risk for excessive flexibility or interoperability

o include basic flexibility

Adherence to these criteria implies that some existing email
implementations will require changes to participate in DomainKeys.
Ultimately some hard choices need to be made regarding which
requirements are more important.

3.1 Determining the sending domain address of an email

The goal of DomainKeys is to give the recipient confidence that the
email originated from the claimed sender. As with much of Internet
email, agreement over what constitutes the "sender" is no easy
matter. Forwarding systems and mailing lists add serious complications
to an overtly simple question.

>From From the point of view of the
recipient, the authenticity claim should be directed at the domain

Delany Expires February, 2005 [Page 9]

Internet-Draft DomainKeys August 2004

most visible to the recipient. Clearly that

In the first instance, the most visible address is clearly the RFC2822 From:
"From:" address [RFC2822]. Therefore, a conforming
DomainKey email must have MUST contain
a single valid From: "From:" header containing from which an email address with a domain name in
can be extracted.

A conforming email MAY contain a single RFC2822 "Sender:" header from
which an email address with a domain name can be extracted.

If the email address. This "sending domain" is used to
formulate has a valid "From:" and a valid "Sender:" header, then
the query needed to retrieve signer MUST use the public-key. sending address in the "Sender:" header.

If the email has a valid "From:" and no "Sender:" header, then the
signer MUST use the first sending address in the "From:" header.

In all other cases, a signer MUST NOT sign the email. Implementors
should note the an email with a "Sender:" header and no "From:" header
MUST NOT be signed.

The domain name in the sending address constitutes the "sending
domain".

3.2 Retrieving the public-key given the "sending domain" sending domain

To avoid namespace conflicts, it is proposed that the DNS namespace
"_domainkey." be reserved within the sending domain for storing
public-keys, e.g., if the sending domain is example.net, then the
public-keys for that domain are stored in the _domainkey.example.net
namespace.

3.2.1 Introducing "selectors"

To support multiple concurrent public-keys per sending domain, the DNS
namespace is further subdivided with "selectors". Selectors are
arbitrary, single-level
arbitrary names below the "_domainkey." namespace. They
can be any string A selector value that is
and length MUST be legal in both the DNS namespace and in email headers (obviously ";" and perhaps "." should be excluded characters).
with the additional provision that they cannot contain a semicolon.

Examples of namespace using selectors are:

"sanfrancisco._domainkey.example.net"
"coolumbeach._domainkey.example.net"
"reykjavik._domainkey.example.net"
"default._domainkey.example.net"

and

"january2004._domainkey.example.net"

Delany Expires February, 2005 [Page 10]

Internet-Draft DomainKeys August 2004

"february2004._domainkey.example.net"
"march2004._domainkey.example.net"

Periods are allowed in selectors and are to be treated as component
separators. In the case of DNS queries that means the period defines
sub-domain boundaries.

The number of public-keys and corresponding selectors for each domain
are determined by the domain owner. Many domain owners will be
satisfied with just one selector whereas administratively distributed
organizations may choose to manage disparate selectors and key pairs
in different regions or on different email servers.

Beyond administrative convenience, selectors make it possible to
seamlessly replace public-keys on a routine basis. If a domain wishes
to change from using a public-key associated with selector "january"
to a public-key associated with selector "february", it merely makes
sure that both public-keys are advertised in the DNS concurrently for
the transition period during which email may be in transit prior to
verification. At the start of the transition period, the outbound
email servers are configured to sign with the "february"
private-key. At the end of the transition period, the "january"
public-key is removed from the DNS.

While some domains may wish to make selector values well known, others
will want to take care not to allocate selector names in a way that
allows harvesting of data by outside parties. E.g., if per-user keys
are issued, the domain owner will need to make the decision as to
whether to make this selector associated directly with the user name,
or make it some unassociated random value, such as the fingerprint of
the public-key.

3.2.2 Public-key signing and verification algorithm

The default signature is an RSA signed SHA1 digest of the email
headers and content. Other candidate algorithms could include GnuPG
[GPG] variants. (Suggestions for the mechanisms needed to include
GnuPG and other freely available algorithms should be directed to the
feedback address at the end of this document.) complete
email.

For ease of explanation, the openssl command is used throughout this
document to describe the mechanism by which keys and signatures are
managed.

One way to generate a 384 768 bit private-key suitable for DomainKeys, is
to use openssl like this:

$ openssl genrsa -out rsa.private 384 768

Which results in the file rsa.private containing the key information
similar to this:

Delany Expires February, 2005 [Page 11]

Internet-Draft DomainKeys August 2004

MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
-----END RSA PRIVATE KEY-----

Once a private-key has been generated, the openssl command can be used
to sign an appropriately prepared email, like this:

$ openssl dgst -sign rsa.private -sha1 <input.file

Which results in signature data similar to this when represented in
Base64 [MIME] format:

MrNZCpqRVgtLYdnvFYtP3jAQlsY3bRNGiwT/ZuaIdDzh68nxSqtW9p24kcB5074m

aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz
msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl

How this signature is added to the email is discussed later in this
document.

To extract the public-key component from the private-key, use openssl
like this:

$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Which results in the file rsa.public containing the key information
similar to this:

This public-key data is placed in the DNS.

With the signature, canonical email contents and public-key, a
verifying system can test the validity of the signature. The openssl
invocation to verify a signature looks like this:

openssl dgst -verify rsa.public -sha1 -signature signature.file <input.file

Delany Expires February, 2005 [Page 12]

Internet-Draft DomainKeys August 2004

3.2.3 Public-key representation in the DNS

There is currently no standard method defined for storing public-keys
in the DNS. As an interim measure, the public-key is stored as a TXT
record derived from a PEM format [PEM], that is, as a Base64
representation of a DER encoded key. Here is an example of a 384 768 bit
RSA key in PEM form:

To save scarce DNS packet space and aid extensibility, the PEM
wrapping generated by openssl is MUST be removed and the remaining public-key data along with
other attributes relevant to DomainKeys functionality are stored as
tag=value pairs separated by semi-colons, semicolons, e.g.:

brisbane._domainkey IN TXT "g=; k=rsa; p=MEwwDQYJKoZIhvcNAQEB p=MHww ... IDAQAB"

Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048
bits. Signers MUST support at least one of the verifier supported key
sizes.

The initial current valid tags are:

g = granularity of the key (the default of '' = all domain, which
means that any left-hand-side key. If present with a non-zero length
value, this value MUST exactly match the local part of the @
sending address. This tag is valid with optional.

The intent of this
DomainKey)

(Though not yet defined, one possible interpretation for
non-empty values tag is that they could represent a Base64 SHA1
fingerprint of the email address used to identify the constrain which sending
domain. This, though, does not handle the notion of tagged
addresses as well as one would like.) address
can legitimately use this selector. An email with a sending
address that does not match the value of this tag constitutes
a failed verification.

k = key type (rsa = is the default). Signers and verifiers MUST
support the default) 'rsa' key type.

n = Notes that may be of interest to a human. No interpretation is
made by any program. This tag is optional.

p = public-key data, encoded as a Base64 string. An empty value
means that this public-key has been revoked. This tag MUST be
present.

t = testing mode ('y' means that this domain is testing DomainKeys
and unverified email should not MUST NOT be treated differently from
verified email. Recipient systems may MAY wish to track testing

Delany Expires February, 2005 [Page 13]

Internet-Draft DomainKeys August 2004

mode results to assist the sender.) This tag is optional.

(Syntax rules for the tag=value format are discussed in Appendix A).

Keeping the size of the TXT record to a minimum is important as some
implementations of content and caching DNS servers are reported to
have problems supporting large TXT records. In this example, the
encoding creates 119 bytes of content for example above, the
encoding generates a 182 byte TXT record. That this encoding is less
than 128 512 bytes is of particular significance to some
DNS implementations that do not handle large as it fits within a
single UDP response packet. With careful selection of query values, a
TXT records correctly. record can accommodate a 2048 bit key.

For the same size restriction reason, the 'n' tag should SHOULD be used
sparingly. The most likely use of this tag is to convey a reason why a
public-key might have been revoked. In this case set the 'n' tag to
the explanation and remove the public-key value from the 'p' tag.

3.3 Canonical preparation of email for signing

DomainKeys

3.2.4 Key sizes

Selecting appropriate key sizes is initially expected to be deployed at, a trade-off between cost,
performance and risk. This specification does not define either
minimum or close to, maximum keys sizes - that decision is a matter for each
domain owner.

Factors that should influence this decision include:

o the
email borders of an organization rather than in UAs or SUBMISSION
servers. In other words, practical constraint that a 2048 bit key is the signing largest key
that fits within a 512 byte DNS UDP response packet

o Larger keys impose higher CPU costs to verify and verifying algorithms normally
apply after an sign email has been packaged, transmogrified and generally
prepared for transmission across the Internet via SMTP.

o Keys can be replaced on a regular basis, thus their lifetime can
be relatively short

o The security goals of this light, and in the interest specification are modest compared to
typical goals of vastly simplifying trial
implementations, public key systems

In general, it is proposed expected that most domain owners will use keys that
are no larger than 1024 bits.

3.3 Storing the default preparation of
signing material derived from the email include all headers and
contents and that a lightweight canonical process be used to prepare
these headers and content for submission to the signing and verifying
algorithms.

The initial canonicalization method is designated "simple" and
processes email as follows:

o Each line of the email is presented to the signing algorithm in
the order it occurs in the email. Line one first, line two,
second, etc.

o For each line in the email, any local line terminator is
removed.

o Regardless of the presence or absence of a local line
terminator, the signing algorithm is to calculate the signature
over the line of data as if the line is terminated with a CRLF.

o Trailing empty lines are ignored. An empty line is a line of
zero length after removal of the local line terminator.

This canonicalization simply prepares the email for the signing
algorithm. It does not change the transmitted data in any way.

Appendix B contains a sample program that demonstrates this "simple"
canonical processing.

3.4 Storing the signature in the email header

The signature signature in the email header

The signature of the email is stored as a header line in the
transmitted email. It is proposed that a single new header be
introduced, called "DomainKey-Signature:" that
header. This header contains all of the
signature-related signature and key-fetching
data.

When transmitting generating the signed email, the "DomainKey-Signature:" header
line immediately precedes
MUST precede the original email headers and content presented to the signature

Delany Expires February, 2005 [Page 14]

Internet-Draft DomainKeys August 2004

algorithm.

The "DomainKey-Signature:" header is not included in the signature
calculation.

For extensibility, the "DomainKey-Signature:" header contains
tag=value pairs separated by semi-colons, semicolons, e.g.:

DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net; q=dns; c=simple

The initial current valid tags are:

a = The algorithm used to generate the signature. The default is
"rsa-sha1", an RSA signed SHA1 digest. Signers and verifiers
MUST support "rsa-sha1".

b = The signature data, encoded as a Base64 string. This tag MUST
be present.

Whitespace is ignored in this value and must MUST be removed when
re-assembling the original signature. This is another way of
saying that the signing process can safely insert folding
whitespace in this value to conform to line-length limits.

c = Canonicalization algorithm. The method by which the headers
and content are prepared for presentation to the signing
algorithm. Currently the only valid value is This tag MUST be present. Verifiers MUST support
"simple" which
defines the algorithm described in this document. More
sophisticated algorithms may evolve as part and "nofws". Signers MUST support at least one of
the
trials. There is no default value for this tag. verifier supported algorithms.

d = The domain name of the signing domain. At this stage, This tag MUST be
present. In conjunction with the selector tag, this domain name must match
forms the basis of the public-key query. The value in this tag
MUST match the domain name found of the sending email address or MUST be
one of the parent domains of the sending email address.

h = A colon separated list of header field names that identify the
headers presented to the signing algorithm. If present, the
value MUST contain the complete list of headers in the From:
header. This order
presented to the signing algorithm. If this tag is largely here not
present, all headers subsequent to allow extensions the signature header are
included in the order found in the email.

A verifier MUST support this tag. A signer MAY support this
tag. If a signer generates this tag it MUST include all email
headers in the original email as a verifier MAY remove or
render suspicious, lines that
allow intermediate domain involvement. There are not included in the
signature.

Whitespace is no default
value for ignored in this tag. value.

Delany Expires February, 2005 [Page 15]

Internet-Draft DomainKeys August 2004

q = The query method used to retrieve the public-key. This tag
MUST be present. Currently the only valid value is "dns" which
defines the DNS lookup algorithm described in this
document. There is no default
value for this tag. Verifiers and signers MUST support "dns".

s = The selector used to form the query for the public-key. This
tag MUST be present. In the DNS query type, this value is pre-pended
prepended to the "_domainkey." namespace of the sending
domain. There is no default value
for this tag.

(Syntax rules for the tag=value format are discussed in Appendix A).

Here is an example of a signature header spread across multiple
continuation lines:

DomainKey-Signature: a=rsa-sha1 s=brisbane; d=example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;

Extreme care must be taken to ensure that any new tags added to this
header are defined and used solely for the purpose of fetching and
verifying the signature. Any semantics beyond verification cannot be
trusted as this header is not protected by the signature.

If additional semantics not pertaining directly to signature
verification are required, they must only be added as subsequent
headers protected by the signature. Semantic additions might include
audit information describing the initial submission.

3.5 The

3.4 Canonical preparation of email for signing process

The previous sections defined the various components and mechanisms
needed to sign an email. This section brings those together

DomainKeys is initially expected to define be deployed at, or close to, the complete process
email borders of signing an email.

>From organization rather than in UAs or SUBMISSION
servers. In other words, the perspective of a signing server, signing and verifying algorithms normally
apply after an email with
DomainKeys consists of has been packaged, transmogrified and generally
prepared for transmission across the following steps:

o identifying Internet via SMTP and thus the sending domain

o determining if an
likelihood of the email being subsequently modified is reduced.

Nonetheless, empirical evidence suggests that some mail servers and
relay systems modify email in transit, potentially invalidating a
signature.

There are two competing perspectives on such modifications. For most
senders, mild modification of email is immaterial to the
authentication status of the email. For such senders a
canonicalization algorithm that survives modest in-transit
modification is preferred.

Delany Expires February, 2005 [Page 16]

Internet-Draft DomainKeys August 2004

For other senders however, any modification of the email - however
minor - results in a desire for the authentication to fail. In other
words, such senders do not want a modified email to be seen as being
authorized by them. These senders prefer a canonicalization algorithm
that does not tolerate in-transit modification of the signed email.

To satisfy both requirements, two canonicalization algorithms are
defined. A "simple" algorithm that tolerates almost no modification
and a "nofws" algorithm that tolerates common modifications as
white-space replacement and header line re-wrapping.

A sender may choose either algorithm when signing an email. A verifier
MUST be able to process email using either algorithm.

Either algorithm can be used in conjunction with the "h" tag in the
"DomainKey-Signature:" header, though it is more likely to make sense
to use the "h" tag with the "nofws" algorithm.

Canonicalization simply prepares the email for the signing or
verification algorithm. It does not change the transmitted data in any
way.

3.4.1 The "simple" canonicalization algorithm

o Each line of the email is presented to the signing algorithm in
the order it occurs in the complete email, from the first line
of the headers to the last line of the body.

o If the "h" tag is used, only those header lines (and their
continuation lines if any) added to the "h" tag list are
included.

o The "h" tag only constrains header lines, it has no bearing on
body lines, which are are always included.

o Remove any local line terminator.

o Append CRLF to the resulting line.

o All trailing empty lines are ignored. An empty line is a line of
zero length after removal of the local line terminator. The
empty line that separates the header from the body is a to be
included in this process.

Appendix B contains a sample program that demonstrates this "simple"
canonical processing.

3.4.2 The "nofws" canonicalization algorithm

Delany Expires February, 2005 [Page 17]

Internet-Draft DomainKeys August 2004

The "nofws" algorithm is more complicated than the "simple" algorithm
for two reasons; folding white space is removed from all lines and
header continuation lines are unwrapped.

o Each line of the email is presented to the signing algorithm in
the order it occurs in the complete email, from the first line
of the headers to the last line of the body.

o Header continuation lines are unwrapped so that header lines are
processed as a single line.

o If the "h" tag is used, only those header lines (and their
continuation lines if any) added to the "h" tag list are
included.

o The "h" tag only constrains header lines, it has no bearing on
body lines, which are are always included.

o For each line in the email, remove all folding white space
characters. Folding white space is defined in RFC2822 as being
the decimal ASCII values 9 (HTAB), 10 (NL), 13 (CR) and 32 (SP).

o Append CRLF to the resulting line.

o Trailing empty lines are ignored. An empty line is a line of
zero length after removal of the local line terminator.

3.5 The signing process

The previous sections defined the various components and mechanisms
needed to sign an email. This section brings those together to define
the complete process of signing an email.

A signer MUST only sign email from submissions that are authorized to
use the sending address.

Once authorization of the submission has been determined, the signing
process consists of the following steps:

o identifying the sending domain

o determining if an email should be signed

o selecting a private-key and corresponding selector information

o calculating the signature value

o pre-pending prepending the "DomainKey-Signature:" header

If an email cannot be signed for some reason, it is a local policy

Delany Expires February, 2005 [Page 18]

Internet-Draft DomainKeys August 2004

decision as to what to do with that email. That policy decision could
vary depending on whether the email already appears to be signed,
whether it claims to be from a domain which the local system can sign
for, or a combination of those factors. In many cases, it is expected
that the local policy will be unchanged by the introduction of
DomainKeys.

Since the verification process is fail-negative - that is, a failed
verification implies negative disposition of that email - a
particularly simplistic signing server could sign all email regardless
of whether it should or not, and let the verifying servers determine
whether the signature validly applies to the From: domain. Appendix C
contains a sample shell script that demonstrates a simple signing
server.

3.5.1 Identifying the sending domain

The sending domain is determined by finding the first email address in the first From: header of the email. If
"Sender:" header, or, if that is not present, the first email address does
not contain a domain for which the signing system is responsible, then
of the "From:" header. An email cannot that lacks a valid "From:" or
"Sender:" header MUST NOT be signed. In this context, "first" means the header
closest to the first line of the email.

3.5.2 Determining if an email should be signed

The signing server

A signer can obviously only sign email for domains for which it has a
private-key and the necessary knowledge of the corresponding
public-key and selector information.

The signing server should information, however there are a number of
other reasons why a signer may choose not normally attempt to sign an email.

A signer MUST NOT sign an email that
already contains a "DomainKey-Signature:" header. The presumption is
that if the signature was generated by another signing server for that
domain. This decision email submission is ultimately a local policy matter. An
alternative local policy could be not
authorized to remove such headers and re-sign
if use the sending domain.

A signer MUST NOT sign an email is from that already contains a domain
"DomainKey-Signature:" header unless a "Sender:" header has been added
that was not included in the signing server can sign for. original signature. The most obvious case
where this occurs is with mailing lists.

A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.

3.5.3 Selecting a private-key and corresponding selector information

This specification does not define the basis by which a signing server signer should
choose which private-key and selector information to use. Currently,
all selectors are equal as far as this specification is concerned, so
the decision should largely be a matter of administrative convenience.

3.5.4 Calculating the signature value

The signing server must signer MUST use one of the defined canonicalization
processed algorithms to
present the email to the signing algorithm. At this stage
that means preparation using the "simple" canonicalization
process. This canonicalization process Canonicalization is only
used to prepare the email for signing, it does not affect the
transmitted email in any way.

To avoid possible ambiguity, a signing server may choose to signer MAY remove any pre-existing
"DomainKey-Status:" headers from the email prior to preparation for
signing and transmission. This action MUST only be taken if the signer
is certain of the authenticity of the email submission as a the
presence of a "DomainKey-Signature:" header normally indicates an
externally submitted email on which verification has been attempted.

Delany Expires February, 2005 [Page 19]

Internet-Draft DomainKeys August 2004

3.5.5 Pre-pending Prepending the "DomainKey-Signature:" header

The final step in the signing process is to pre-pend that the signer MUST prepend
the "DomainKey-Signature:" header and continue prior to continuing with the process
of transmitting the email.

3.6 Policy statement of sending domain

While the disposition of inbound email is ultimately a matter for the
receiving system, the introduction of authentication in email creates
a need for the sender domain to indicate their signing policy and
preferred disposition of unsigned email. In particular, whether a
domain is participating in DomainKeys, whether they are testing and
whether it signs all outbound email.

3.6.1 Domain policy is nascent

As yet there is no standard for a domain to indicate sending policy to
recipient MTAs. Indeed the whole notion of sender policy is relatively
new to email. To complicate matters, there are currently a number of
incompatible draft proposals that attempt to define comprehensive
sender policy mechanisms.

Fortunately, the IETF MARID Working Group [MARID] has recently decided
to develop a standard policy language and retrieval mechanism that is
likely to be flexible enough to cover all the policy needs of
DomainKeys.

However, until a unified standard exists, this specification proposes
a minimalist and interim sender policy mechanism. The sole purpose of
this policy is to define the level of participation in DomainKeys and
consequently how unverified email should be treated relative to
verified email from that domain.

To re-iterate this last point, we strongly take the view that sending
domain policy will ultimately encompass much more than just the
dispositional needs of DomainKeys. To that end, implementors are
encouraged to completely separate their DomainKeys verification
process from the determination and application of sender domain
policy.

3.6.2 Interim sending domain policy

The interim sending domain policy is very simple and is expressed in
the _domainkey TXT record in the DNS of the sending domain. E.g., in
the example.com domain that record is called _domainkey.example.com

Delany Expires February, 2005 [Page 20]

Internet-Draft DomainKeys August 2004

The contents of this TXT record are stored as tag=value pairs
separated by semi-colons, semicolons, e.g.:

_domainkey IN TXT "t=y; o=-; n=notes;" n=notes; r=emailAddress"

All tags are optional The initial current valid tags are:

n = Notes that may be of interest to a human. No interpretation is
made by any program.

o = Outbound Signing policy ('-' means that this domain signs all
email, '~' is the default and means that this domain may sign
some email with DomainKeys) DomainKeys).

r = A reporting email address. If present, this defines the email
address where invalid verification results are reported. This
tag is primarily intended for early implementors - the content
and frequency of the reports will be defined in a separate
document.

t = testing mode ('y' means that this domain is testing DomainKeys
so unsigned and unverifiable email should not be treated
differently from verified email. Recipient systems may wish to
track testing mode results to assist the sender.)

Note that testing mode cannot be turned off by this tag - thus
policy cannot revert the testing mode setting of a Selector.

(Syntax rules for the tag=value format are discussed in Appendix A).

Recipient systems should SHOULD only retrieve this policy TXT record to
determine policy when an email fails to verify. verify or does not include a
signature. Recipient systems
should SHOULD not retrieve this policy TXT
record for email that successfully verifies. Note that "testing mode" should
SHOULD also be in the Selector TXT record if the domain owner is
running a DomainKeys test.

If the policy TXT record does not exist, recipient systems must MUST
assume the default values.

There is an important implication when a domain states that it signs
all email with the "o=-" setting. Namely that the sending domain
prefers that the recipient system treat unsigned mail with a great
deal of suspicion. Such suspicion could reasonably extend to rejecting
such email. A verifying system MAY reject unverified email if a domain
policy indicates that it signs all email.

Of course nothing compels a recipient MTA to abide by the policy of
the sender. In fact, during the trial a sending domain would want to
be very certain about setting this policy, as processing by recipient

Delany Expires February, 2005 [Page 21]

Internet-Draft DomainKeys August 2004

MTAs may be unpredictable. Nonetheless, a domain that states that it
signs all email should MUST expect that unverified email may be rejected by
some receiving MTAs.

3.7 The verification process

There is no defined or recommended limit on the lifetime of a selector
and corresponding public-key, however it is recommended that
verification occur in a timely manner with the most timely place being
during acceptance or local delivery by the MTA.

Verifying a signature consists of the following three steps:

o Extract the signature information from the headers

o Retrieve the public-key based on the signature information

o Check that the signature verifies against the contents

In the event that any of these steps fails, the sending domain policy
is ascertained to assist in applying local policy.

3.7.1 Verification should render a binary result

While the symptoms of a failed verification are obvious - the
signature doesn't verify - establishing the exact cause can be more
difficult. If a selector cannot be found, is that because the selector
has been removed or was the value changed somehow in transit? If the
signature line is missing is that because it was never there, or was
it removed by an over-zealous filter?

For diagnostic purposes, the exact reason why the verification fails
should
SHOULD be recorded, however in terms of presentation to the end user,
the result should SHOULD be presented as a simple binary result: either the
email is verified or it is not. If the email cannot be verified, then
it should SHOULD be rendered the same as all unverified email regardless of
whether it looks like it was signed or not.

3.7.2 Extracting signature information from the headers

The signature information needed to verify the email consists of
extracting data from the "DomainKey-Signature:" line and identification the claimed
sending domain from the "From:" or "Sender:" header. This process
varies depending on the presence of the "h" tag in the signature line.

The process of extracting the signature information consists of:

1. Starting at the first line of the headers and searching in

Delany Expires February, 2005 [Page 22]

Internet-Draft DomainKeys August 2004

sequential order, find each occurrence of the claimed sending
domain from
"DomainKey-Signature:" header and determining whether the
sending domain is based on the "From:" or the From: "Sender:" header.

The process of extracting

If the signature information consists of:

1. Scanning line contains the email for "h" tag, then the last occurrence presence
of the
"DomainKey-Signature:" header. If found, verify that the
contents conform to this specification and extract "sender" or "from" header field name in the values
for subsequent use. In this context, "last" means value
determines the header line farthest from to use for the first sending domain.

If the signature line does not contain the "h" tag, then the
presence of the email. "Sender:" or "From:" header in subsequent
header lines determines which one is used for the sending
domain.

2. If more than one signature line is found, a From: verifier MUST use
the signature based on the "Sender:" header as the basis for
performing verification.

If more than one signature line is found prior to be based on the last
"DomainKey-Signature:"
"From:" header, treat the email us unverified.

Only lines subsequent to the "DomainKey-Signature:" are
included in then the first signature calculation, thus any pre-pended
lines are ignored as far as verification data is concerned. line found MUST be
used.

If multiple "DomainKey-Signature: " headers are found, all but
the last more than one should signature line is found to be ignored.

2. Scanning based on the remaining headers to find
"Sender:" header, then the first occurrence of
the From: signature line and extract found MUST be
used.

3. A verifier MUST NOT continue with the verification unless that
the claimed sending domain from matches the
first address domain in the From: line. In this context, "first" means
the line closest to the first line 'd' tag of the email.

If signature,
or that it is a claimed sending sub-domain of the domain cannot be extracted from in the From:
line, then treat 'd' tag.

4. Based on the email as unverified.

If algorithm defined in the claimed sending domain does not match 'c' tag, and the domain
identified with header
field names in the 'd' tag of 'h' tag, the "DomainKey-Signature:"
header, then treat verifier canonicalizes the
email as unverified. part of verifying the signature.

5. Based on the query type defined in the 'q' tag, make the query
to retrieve the public-key to verify the signature.

Implementors should program defensively when scanning for may wish to initiate the
signature information public key query in parallel
with calculating the SHA1 as the contents are completely under public key is not needed until the control
of
the sending system - some of which may have malicious intent. final RSA is calculated.

Implementors MUST meticulously validate the format and values in the
"DomainKey-Signature:" header; any inconsistency or unexpected values
MUST result in an unverified email. Being "liberal in what you accept"
is definitely a bad strategy in this security context.

3.7.3 Retrieve the public-key based on the signature information

The public-key is needed to complete the verification process. The
process of retrieving the public-key depends on the query type as
defined by the "q" tag in the "DomainKey-Signature:" header

Delany Expires February, 2005 [Page 23]

Internet-Draft DomainKeys August 2004

line. Obviously, a public-key should only be retrieved if the process
of extracting the signature information is completely successful.

Currently the only valid query type is "dns". The public-key retrieval
process for this type is:

1. Using the selector name defined by the 's' tag, the
"_domainkey" namespace and the domain name defined by the 'd'
tag, construct and issue the DNS TXT record query string.

E.g., if s=brisbane and d=example.net, the query string is
"brisbane._domainkey.example.net".

2. If the query for the public-key fails to respond, the verifier
SHOULD defer acceptance of this email (normally this will be
achieved with a 4XX SMTP response code).

3. If the query for the public-key fails because the corresponding
data does not exist, the verifier MUST treat the email as
unverified.

4. If the result returned from the query does not adhere to the
format defined in this specification, the verifier MUST treat
the email as unverified.

5. If the public-key data is not suitable for use with the
algorithm type defined by the 'a' tag in the
"DomainKey-Signature:" header, the verifier MUST treat the
email as unverified.

Implementors should MUST meticulously validate the format and values returned
by the public-key query, query and presented in the "DomainKey-Signature:"
header; any inconsistency or unexpected values should MUST result in an
unverified email. Being "liberal in what you accept" is definitely a
bad strategy in this security context.

3.7.4 Verify the signature

Armed with the signature information from the "DomainKey-Signature:"
header and the public-key information returned by the query, the
signature of the email can now be verified.

The canonicalization algorithm defined by the 'c' tag in the
"DomainKey-Signature:" header defines how the data is prepared for the
verification algorithm and the 'a' tag in the same header defines
which verification algorithm to use.

Even though there is currently only one canonicalization algorithm and
one verification algorithm, implementors should consider the
possibility that this list may grow.

3.7.5 Retrieving sending domain policy

Delany Expires February, 2005 [Page 24]

Internet-Draft DomainKeys August 2004

In the event that an email fails to verify, the policy of the sending
domain should MUST be consulted. For now that means consulting the _domainkey
TXT record in the DNS of the claimed sending domain.

While a receiver can always do whatever they want, it behooves a
receiver to domain in the 'd' tag of the signature
line. Eg, if the 'd' tag contains example.net, the TXT query is:

_domainkey.example.net

A verifier SHOULD consider the sending domain policy statement and act
accordingly. The range of possibilities is up to the receiver, but it
could
MAY include rejecting the email.

3.7.6 Applying local policy

After all verification processes are complete the recipient system has
authentication information that can help it decide what to do with the
email.

It is beyond the scope of this specification to describe what actions
a recipient system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email
cannot. Specifically, an authenticated email creates a predictable
identifier by which other decisions can reliably be managed, such as
trust and reputation.

Conversely, unauthenticated email lacks a reliable identifier that can
be used to assign trust and reputation. It is not unreasonable to
treat unauthenticated email as lacking any trust and having no
positive reputation.

3.8 Conveying verification results to UAs

Apart from the application of automated policy, the result of a
signature verification should be conveyed to the user reading the
email.

Most email clients can be configured to recognize specific headers and
apply simple rules - e.g., filing in into a particular folder. Since
DomainKey signatures are expected to be initially verified at the
border MTA, the results of the verification need to be conveyed to the
email client. This is done with the "DomainKey-Status:" header line
pre-pended
prepended to the email.

The "DomainKey-Status:" header contains a single value starts with values that indicates indicate the
result of the verification. Valid values are:

"good" - the signature was verified at the time of testing
"bad" - the signature failed the verification
"no key" - the public-key query failed as the key does not exist
"revoked" - the public-key query failed as the key has been revoked

Delany Expires February, 2005 [Page 25]

Internet-Draft DomainKeys August 2004

"no signature" - this email has no "DomainKey-Signature:" header
"bad format" - the signature or the public-key contains unexpected data
"non-participant" - this sending domain has indicated that it does
not participate in DomainKeys.

Verifiers may append additional data that expands on the reason for
the particular status value.

A client can normally SHOULD just look for "good" and can safely assume that all other values
imply that the verification failed in could not be performed for some way.
reason. Policy action as a consequence of this header is entirely a
local matter.

Here are some examples:

DomainKey-Status: good
DomainKey-Status: bad format

Although it is expected that MTAs will be DomainKey aware before MUAs,
it is nonetheless possible that a DomainKey aware MUA can be fooled by
a spoofed "DomainKey-Status:" header that passes through a
non-DomainKey aware MTA.

If this is perceived to be a serious problem, then it may make sense
to preclude the "good" value and only have values that effectively
demote the email as far as the UA is concerned. That way successful
spoofing attempts can only serve to demote themselves.

4. Example of use

This section shows the complete flow of an email from submission to
final delivery, demonstrating how the various components fit together.

4.1 The user composes an email

From: "Joe SixPack" <joe@football.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

4.2 The email is signed

Delany Expires February, 2005 [Page 26]

Internet-Draft DomainKeys August 2004

This email is signed by the football.example.com outbound email server
and now looks like this:

DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.football.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: "Joe SixPack" <joe@football.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

The signing email server requires access to the private-key associated
with the "brisbane" selector to generate this signature. Distribution
and management of private-keys is outside the scope of this document.

4.3 The email signature is verified

The signature is normally verified by an inbound SMTP server or
possibly the final delivery agent. However, intervening MTAs can also
perform this verification if they choose to do so.

The verification process extracts uses the domain "football.example.com"
extracted from the From: "From:" header and the selector "brisbane" from the
"DomainKey-Signature:" header to form the DNS TXT query for:

brisbane._domainkey.football.example.com

Signature DNS TXT query for:

brisbane._domainkey.football.example.com

Since there is no "h" tag in the "DomainKey-Signature:" header,
signature verification starts from with the line following the
"DomainKey-Signature:" line. The email is obviously canonically prepared for
verifying with the "simple" method as discussed
previously. method.

The result of the query and subsequent verification of the signature
is stored in the "DomainKey-Status:" header line. After successful
verification, the email looks like this:

DomainKey-Status: good
Received: from mout23.brisbane.football.example.com (192.168.1.1)

Delany Expires February, 2005 [Page 27]

Internet-Draft DomainKeys August 2004

by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net; d=football.example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: "Joe SixPack" <joe@football.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

5. Association with a Certificate Authority

A fundamental aspect of DomainKeys is that public-keys are generated
and advertised by each domain at no additional cost. This
accessibility markedly differs from traditional Public Key
Infrastructures where there is typically a Certificate Authority (CA)
who validates an applicant and issues a signed certificate -
containing their public-key - for a recurring fee.

While CAs do impose costs, they also have the potential to provide
additional value as part of their certification process. Consider
financial institutions, public utilities, law enforcement agencies and
the like. In many cases, such entities justifiably need to
discriminate themselves above and beyond the authentication that
DomainKeys offers.

Creating a link between DomainKeys and CA issued certificates has the
potential to access additional authentication mechanisms that are more
authoritative than domain owner issued authentication. It is well
beyond the scope of this specification to describe such authorities
apart from defining how the linkage could be achieved with the
"DomainKey-X509:" header.

5.1 The "DomainKey-X509:" header

The "DomainKey-X509:" header provides a link between the public-key
used to sign the email and the certificate issued by a CA.

Delany Expires February, 2005 [Page 28]

Internet-Draft DomainKeys August 2004

The exact content, syntax and semantics of this header are yet to be
resolved. One possibility is that this header contains an encoding of
the certificate issued by a CA. Another possibility is that this
header contains a URL that points to a certificate issued by a CA.

In either case, this header can only be consulted if the
"DomainKey-Signature:" verifies and must MUST be part of the content signed
by the corresponding "DomainKey-Signature:" header. Furthermore, it is
likely that MUAs rather than MTAs will confirm that the link to the CA
issued certificate is valid. In part this is because many MUAs already
have built-in capabilities as a consequence of S/MIME [SMIME] [RFC1847] and
SSL [SSL] support.

The proof of linkage is made by testing that the public-key in the
certificate matches the public-key used to sign the email.

An example of a email containing the "DomainKey-X509:" header is:

DomainKey-Signature: a=rsa-sha1; s=statements;
d=largebank.example.com; c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
DomainKey-X509: https://ca.example.net/largebank.example.com
From: "Large Bank" <statements@largebank.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Statement for Account: 1234-5678
...

The format of the retrieved value from the URL is not yet defined, nor
is the determination of valid CAs.

The whole matter of linkage to CA issued certificates is one aspect of
DomainKeys that needs to be resolved with relevant CA and certificate
issuing entities. The primary point is that a link is possible to a
higher authority.

6. Topics for discussion

6.1 The benefits of selectors

Selectors are at the heart of the flexibility of DomainKeys. A domain
administrator is free to use a single DomainKey for all outbound
mail. Alternatively, they may use many DomainKeys differentiated by
selector and assign each key to different servers.

For example, a large outbound email farm might have a unique DomainKey
for each server, and thus their DNS will advertise potentially
hundreds of keys via their unique selectors.

Delany Expires February, 2005 [Page 29]

Internet-Draft DomainKeys August 2004

Another example is a corporate email administrator who might generate a
separate DomainKey for each regional office email server.

In essence, selectors allow a domain owner to distribute authority to
send on behalf of that domain. Combined with the ability to revoke by
removal or TTL expiration, a domain owner has course-grained coarse-grained control
over the duration of the distributed authority.

Selectors are particularly useful for domain owners who want to
contract a third-party mailing system to send a particular set of
mail. The domain owner can generate a special key pair and selector
just for this mail-out. The domain owner has to provide the Private
Key and selector to the third party for the life of the
mail-out. However, as soon as the mail-out is completely delivered,
the domain owner can revoke the public-key by the simple expedient of
removing the entry from the DNS.

6.2 Canonicalization of email

It is an unfortunate fact that some email software routinely (and
often unnecessarily) transforms email as it transits through the
network. Such transformations conflict with a the fundamental purpose of
cryptographic signatures - to detect modifications.

The "best" method for canonicalizing an email for presentation to

While two canonicalization algorithms are defined in this
specification, the
signing algorithm will no doubt be a matter primary goal of much debate. Should all
headers be signed? Should whitespace be trimmed? Should header lines
be unwrapped? Should known format headers such as Date: be converted "nofws" is to provide a common form? Should the whole email be encapsulated as transition
path to "simple". With a MIME
object? Alternatively, is the lightweight canonicalization (called
"simple") proposed in this document in fact, too heavy?

At this stage, in the interest mixture of early interoperability tests, "simple" and "nofws" email, a very
simplistic, default canonicalization is used. In part this is based on
the assumption
receiver can determine which systems are modifying email in ways that early DomainKey implementations will likely be
deployed at
cause the border signature to fail and that most email transformations occur
within such borders.

Gaining rough consensus on the best canonicalization algorithm for thus provide feedback to the
long-term will no doubt be a challenging process. modifying
system.

6.3 Mailing lists

Mailing list managers (MLMs) must resolve a number of issues prior to
participating in DomainKeys.

First, MLMs need to decide whether they simply pass through a
submission and signature unchanged (and quite possibly unverified), or
whether they verify the inbound signature and apply their own
signature prior to redistribution to the list recipients.

One argument for the latter is that MLMs often make significant
changes to the submission. They may add tag lines, rewrite Subject:
lines and re-package contents in a digest form.

Secondly, MLMs usually re-distribute email with the original From:
header unchanged. However, if they want to apply their own signature
to the distributed email, they have to replace the From: line. Such a
change presents modify email in a surprise to mailing list participants way that don't
render the Sender: header.

One possibility is to adapt DomainKeys causes
signatures to specifically recognize MLM
traffic, e.g. recognizing that MLMs often insert fail, MUST pre-pend a Sender: line "Sender:" header and
searching arrange for that as
the sending domain.

Another possibility is for MLMs email to adopt strict and consistent
conventions regarding header generation at the point of
redistribution. E.g., From: should always be converted resigned as it is distributed to Resent-From:. the list recipients.

A final possibility is that MLMs may not participating SUBMISSION server can deduce the need to participate in
DomainKeys as recipients have other means of sufficiently recognizing
legitimate MLM traffic, resign such as List-ID: headers.
an email by the presence of a "Sender:" header from an authorized
submission.

6.4 Roving users

One scenario that presents a particular problem with any form of email
authentication, including DomainKeys, is the roving user. A user who
is obliged to use a third-party SUBMISSION service when unable to
connect to their own SUBMISSION service. The classic example cited is
a traveling salesperson being redirected to a hotel email server to

Delany Expires February, 2005 [Page 30]

Internet-Draft DomainKeys August 2004

send email.

As far as DomainKeys is concerned, email of this nature clearly
originates from an email server that does not have authority to send
on behalf of the domain of the salesperson and is therefore
indistinguishable from a forgery. While DomainKeys does not prescribe
any specific action for such email it is likely that over time, such
email will be treated as second class email.

The typical solution offered to roving users is to submit email via an
authorized server for their domain - perhaps via a VPN or a web
interface or even SMTP AUTH back to a SUBMISSION server.

While these are perfectly acceptable solutions for many, they are not
necessarily solutions that are available or possible for all such
users.

One possible way to address the needs of this contingent of
potentially disenfranchised users, is for the domain to issue per-user
DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag
value in the corresponding DNS record.

Possible semantics and mechanisms for per-user DomainKeys are
canvassed in a separate document. Suffice to say here that the base
definition specifically supports the possibility of per-user
DomainKeys.

6.5 Envelope audit

[ To be discussed: Identify the preconditions in the base document
that allow for envelope auditing to protect against replay and
joe-jobs ]

7. Security Considerations

7.1 DNS

DomainKeys is primarily a security mechanism. Its core purpose is to
make claims about email authentication in a credible way. However,
DomainKeys, like virtually all Internet applications, relies on the
DNS which has well-known security flaws [DNS-THREATS].

7.1.1 The DNS is not currently secure

While the DNS is currently insecure, it is expected that the security
problems should and will be solved by DNSSEC, DNSSEC [DNSSEC], and all users
of the DNS will reap the benefit of that work.

Secondly, the types of DNS attacks relevant to DomainKeys are very
costly and are far less rewarding than DNS attacks on other Internet
applications.

Delany Expires February, 2005 [Page 31]

Internet-Draft DomainKeys August 2004

To systematically thwart the intent of DomainKeys, an attacker must
conduct a very costly and very extensive attack on many parts of the
DNS over an extended period. No one knows for sure how attackers will
respond, however the cost/benefit of conducting prolonged DNS attacks
of this nature is expected to be uneconomical.

Finally, DomainKeys is only intended as a "sufficient" method of
proving authenticity. It is not intended to provide strong
cryptographic proof about authorship or contents. Other technologies
such as GnuPG and S/MIME address those requirements.

7.1.2 DomainKeys creates additional DNS load

A second security issue related to the DNS revolves around the
increased DNS traffic as a consequence of fetching Selector-based data
as well as fetching sending domain policy. Widespread deployment of
DomainKeys will result in a significant increase in DNS queries to the
claimed sending domain. In the case of forgeries on a large scale, DNS
servers could see a substantial increase in queries.

7.2 Key Management

All public-key systems require management of key pairs. Private-keys
in particular need to be securely distributed to each signing mail
server and protected on those servers. For those familiar with SSL,
the key management issues are similar to those of managing SSL
certificates. Poor key management may result in unauthorized access to
private-keys, which in essence gives unauthorized access to your
identity.

7.3 Implementation Risks

It is well recognized in cryptographic circles that many security
failures are caused by poor implementations rather than poor
algorithms. For example, early SSL implementations were vulnerable
because the implementors used predictable "random numbers".

While some MTA software already supports various cryptographic
techniques, such as TLS, many do not. This proposal introduces
cryptographic requirements into MTA software which implies a much
higher duty of care to manage the increased risk.

There are numerous articles, books, courses, and consultants that help
programming security applications. Potential implementors are strongly
encouraged to avail themselves of all possible resources to ensure
secure implementations.

Delany Expires February, 2005 [Page 32]

Internet-Draft DomainKeys August 2004

7.4 Privacy assumptions with forwarding addresses

Some people believe that they can achieve anonymity by using an email
forwarding service. While this has never been particularly true as
bounces, over-quota messages, vacation messages and web bugs all
conspire to expose IP addresses and domain names associated with the
delivery path, the DNS queries that are required to verify DomainKeys
signature can provide additional information to the sender.

In particular, as mail is forwarded through the mail network, the DNS
queries for the selector will typically identify the DNS cache used by
the forwarding and delivery MTAs.

8. The trial

The first step in validating DomainKeys as a viable email
authentication system is to conduct a trial of the technology. A
number of organizations have committed to developing and deploying
DomainKeys and Open Source implementations are expected to become
available. Interested parties are encouraged to participate in this
trial and help evolve this specification based on those experiences.

8.1 Goals

The primary goals of the trial are to:

o understand the operational implications of running a DNS-based
public-key system for email

o evolve measure the likely canonical needs effectiveness of future specifications

o determine the best method for MLM participation canonicalization algorithms

o experiment with possible per-user key deployment models

o fully define the semantics of the "DomainKey-X509:" header

8.2 Constraints on participation

Due to the "simple" canonicalization algorithm, participants in the
trial should ensure that they:

o do not re-arrange or modify headers or contents

o are 8BITMIME compliant

o they sign email after any transfer-encoding
transformations have been made prior to transmission transmission.

Acknowledging the possibility that early DomainKey implementations may
be less than perfect and that senders may be merely testing their
implementations, recipient systems should be reticent about applying
strict policy to unverified email. Particularly if the sending domain
policy or the selector information has the testing mode set.

Delany Expires February, 2005 [Page 33]

Internet-Draft DomainKeys August 2004

9. Notes to Implementors

9.1 TXT records

The DNS is very flexible in that it is possible to have multiple TXT
records for a single name and for those TXT records to contain
multiple strings.

In all cases, implementors of DomainKeys should expect a single TXT
record for any particular name. If multiple TXT records are returned,
the implementation is free to pick any single TXT record as the
authoritative data. In other words, if a name server returns different
TXT records for the same name, it can expect unpredictable results.

Within a single TXT record, implementors should concatenate multiple
strings in the order presented and ignore string boundaries. Note that
a number of popular DNS command-line tools render multiple strings as
separately quoted strings which can be misleading to a novice
implementor.

10. References

10.1 Normative References

[MIME] Borenstein, N., Freed, N., "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies ", RFC 2045, November, 1996.

[OPENSSL] http://www.openssl.org

[PEM] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures," RFC 1421 February 1993.

[SMIME] Galvin, J., Murphy, S., Crocker, S., Freed, N.,
"Security Multiparts for MIME", RFC 1847, October
1995.

10.2 Informative References

[DNS-THREATS] http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt

[DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html

[GPG] http://www.gnupg.org

[KEY-RR] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.

[MARID] http://www.ietf.org/html.charters/marid-charter.html

[NO-KEY-RR] Massey, D., Rose, S., "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.

[RFC1847] Galvin, J., Murphy, S., Crocker, S., Freed, N., "Security
Multiparts for MIME", RFC 1847, October, 1995.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

Delany Expires February, 2005 [Page 34]

Internet-Draft DomainKeys August 2004

[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC
2822, April 2001.

[SSL] http://wp.netscape.com/security/techbriefs/ssl.html

11. Acknowledgments

The author wishes to thank Russ Allbery, Eric Allman, Edwin Aoki,
Claus Asmann, Steve Atkins, Dave Crocker, Michael Cudahy, Jutta
Degener, Jim Fenton, Duncan Findlay, Phillip Hallam-Baker, Murray
S. Kucherawy, John Levine, Miles Libbey, David Margrave, Justin Mason,
David Mayne, Russell Nelson, Juan Altmayer Pizzorno, Blake Ramsdell,
Scott Renfro, the Spamhaus.org team, Malte S. Stretz, Robert Sanders,
and Rand Wacker for their valuable suggestions and constructive
criticism.

Appendix A - Syntax rules for the tag=value format

A simple tag=value syntax is used to encode data in the response
values for DNS queries as well as headers embedded in emails. In a
later draft, a formal grammar will be used to precisely define the
rules, for now, this section summarized the most salient syntactic
rules for this encoding:

o A tag=value pair consists of three tokens, a "tag", the "="
character and the "value"

o A tag is MUST be one character long and must MUST be a lower-case
alphabetic character

o Duplicate tags are not allowed

o A value can MUST only consist of characters that are valid in
RFC2822 headers, DNS TXT records and are within the ASCII range
of characters from SPACE (0x20) to TILDE (0x7E)
inclusive. Values
cannot MUST NOT contain a colon or semi-colon semicolon but
they may contain "=" characters.

o A tag=value pair is MUST be terminated by a semi-colon semicolon or the end
of the data

o Values are MUST be processed as case sensitive, (though some values may have sensitive unless the same
semantics regardless specific
tag description of case) semantics imply case insensitivity.

o Values are a minimum of MAY be zero bytes long

o Whitespace can MAY surround any of the tokens, however whitespace
within a value forms part of that value MUST be retained unless explicitly
excluded. excluded by
the specific tag description. Currently the only tag tags that

Delany Expires February, 2005 [Page 35]

Internet-Draft DomainKeys August 2004

specifically ignores embedded whitespace is are the 'b' and 'h' tag
in the signature "DomainKey-Signature:" header.

o Tag=value pairs that represent the default value need not MAY be
present included
to aid legibility.

o Unrecognized tags and values should MUST be ignored

Appendix B - Sample "simple" canonicalization program: dk_simple_canonical

This sample perl program called dk_simple_canonical, demonstrates the
"simple" canonical processing by converting stdin to canonical form on
stdout:

my $pendingTerminators = 0;
my $canonCRLF = "\r\n";
while(<>) {
chomp; # Remove local line terminator
if (length == 0) {
$pendingTerminators++; # Count potential trailing empties
next; # and avoid printing them
}

# A non-empty line means printing all the potentials prior to
# printing the data line.

print $canonCRLF while $pendingTerminators-- > 0;
print; # print the data line
$pendingTerminators = 1; # data is not yet terminated
}
print $canonCRLF if $pendingTerminators > 0;
exit(0);

Appendix C - Sample signing shell script: dk_simple_sign

This sample shell script demonstrates how to sign an email that
matches the DomainKeys specification. It assumes that the private-key
has been previously generated and that the dk_simple_canonical program
is in the PATH. This script also assumes that the From: "From:" domain
matches the domain of the selector. selector and that the submitter is
authorized to use that address.

#! /bin/sh

file=$1
domain=$2
selector=$3

Delany Expires February, 2005 [Page 36]

Internet-Draft DomainKeys August 2004

if [ ! -r "$file" -o ! "$domain" -o ! "$selector" ]; then
echo >&2 Usage: dk_simple_sign filename domain selector
exit 1
fi

echo "DomainKey-Signature: a=rsa-sha1; q=dns; c=simple;"
echo " s=$selector; d=$domain;"

dk_simple_canonical <$file |
openssl dgst -sign rsa.private -sha1 |
perl -MMIME::Base64 -0777 -ne 'print encode_base64($_)'
openssl base64 |
sed -e '1s/^/b=/' -e 's/^/ /'

cat <$file

exit 0

Appendix D - Sample email showing draft-01 changes

This email demonstrates a number of important changes made to this
version of the specification.

Sender: <weekenders@listserv.example.org>
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.org;
c=nofws; q=dns;
h=Sender:Received:DomainKey-Signature:
Received:From:To:Subject:Date:Message-ID;
b=grUU7EOwzCbuoejh39KE+epT3zGdmAP693IOGujxSBb+4qtIR9yg1EubJYMDVuuvt
1uySVzETz/0GrzxPC2L8w==
Received: from mout23.brisbane.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: "Joe SixPack" <joe@football.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Is dinner ready?
Message-ID: <20030712040037.46341.5F8J@football.example.com>
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
X-Orig-IP: [192.168.1.1]

Hi.

We lost the game. Are you hungry yet?

Delany Expires February, 2005 [Page 37]

Internet-Draft DomainKeys August 2004

Joe.

o The email has a signature for the "Sender:" and the "From:"

o The "Sender:" header is the last signing domain.

o The first signature line uses the "nofws" canonicalization
algorithm

o The domain in the Sender: is a sub-domain of the 'd' value.

o Based on the 'h' tag, the "Sender:", "Date:" and "Message-ID:"
headers have been re-ordered.

o Based on the 'h' tag, the "X-Orig-IP:" header was added after the
email was signed by the "Sender:".

12. Change History

This document is a revision of the previous version named
draft-delany-domainkeys-base-00.txt. For the convenience of those
familiar with the earlier version, the major changes are summarized
here:

1. Added "Sender:" header as an alternative to "From:" header.
2. The domain in the 'd' tag now only has to match the rightmost
part of the sending address.
3. Introduced the "nofws" canonicalization scheme.
4. Completed the meaning of 'g' tag.
5. Introduced the 'h' tag in the signature.
6. Introduced the 'r' tag in the policy.

Author's Address

Mark Delany
Yahoo! Inc
701 First Avenue
Sunnyvale, CA 95087

domainkeys-feedbackbase00@yahoo.com

domainkeys-feedbackbase01@yahoo.com

Please send comments to the author at the above address. The feedback
email address will remain valid until this draft expires or is
replaced with a subsequent revision.

Delany Expires February, 2005 [Page 38]

Internet-Draft DomainKeys August 2004

RCS: $Id: draft-delany-domainkeys-base-00.txt,v 1.4 2004/05/18 00:42:11 draft-delany-domainkeys-base-01.txt,v 1.7 2004/08/20 21:47:51 markd Exp $

Delany Expires February, 2005 [Page 39]

----