idnits 2.17.1 draft-allman-dkim-base-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2184. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 60 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 100 has weird spacing: '...Results heade...' == Line 892 has weird spacing: '...Results heade...' == Line 965 has weird spacing: '... email elec...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2005) is 6859 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XINDX' is mentioned on line 803, but not defined == Missing Reference: 'XREF-TBD' is mentioned on line 773, but not defined -- Looks like a reference, but probably isn't: '5' on line 1938 == Missing Reference: 'MIME' is mentioned on line 2116, but not defined == Unused Reference: 'OPENSSL' is defined on line 1753, but no explicit reference was found in the text == Unused Reference: 'RFC1421' is defined on line 1756, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1771, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 1777, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 1781, but no explicit reference was found in the text == Unused Reference: 'RFC1847' is defined on line 1787, but no explicit reference was found in the text -- No information found for draft-dkk-rr-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-DK-RR' -- No information found for draft-allman-dkim-policy - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-DKPOLICY' == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-02 ** Downref: Normative reference to an Informational draft: draft-crocker-email-arch (ref. 'ID-MAIL-ARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPENSSL' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pre-MASS E. Allman 3 Internet-Draft Sendmail, Inc. 4 Expires: January 10, 2006 J. Callas 5 PGP Corporation 6 M. Delany 7 M. Libbey 8 Yahoo! Inc 9 J. Fenton 10 M. Thomas 11 Cisco Systems, Inc. 12 July 9, 2005 14 DomainKeys Identified Mail (DKIM) 15 draft-allman-dkim-base-00 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 10, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 DomainKeys Identified Mail (DKIM) defines a domain-level 49 authentication framework for email using public-key cryptography and 50 key server technology to permit verification of the source and 51 contents of messages by either Mail Transport Agents (MTAs) or Mail 52 User Agents (MUAs). The ultimate goal of this framework is to prove 53 and protect message sender identity and the integrity of the messages 54 they convey while retaining the functionality of Internet email as it 55 is known today. Proof and protection of email identity, including 56 repudiation and non-repudiation, may assist in the global control of 57 "spam" and "phishing". 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 (Unresolved Issues/To Be Done) 67 Security Considerations needs further work. 69 Need to add new and check existing ABNF. 71 Need to resolve remaining cross references (XINDX) 73 CONVERSION DISCLAIMER 75 This initial version that is being submitted as an IETF Internet- 76 Draft has been converted over to RFC format by Dave Crocker. Besides 77 the many rough edges to the resulting format of the document, he 78 suspects there also might be some more serious errors, such as sub- 79 sections being at the wrong level. These errors will be repaired as 80 soon as they are reported. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 1.2 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 87 1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 88 1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 89 2. Terminology and Definitions . . . . . . . . . . . . . . . . 7 90 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 92 2.3 Imported ABNF tokens . . . . . . . . . . . . . . . . . . . 7 93 2.4 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 94 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 8 95 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 96 3.2 Tag=Value Format for DKIM header fields . . . . . . . . . 9 97 3.3 Signing and Verification Algorithms . . . . . . . . . . . 11 98 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 12 99 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 16 100 3.6 The Authentication-Results header field . . . . . . . . . 21 101 3.7 Key Management and Representation . . . . . . . . . . . . 21 102 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 23 103 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 24 104 5.1 Determine if the Email Should be Signed and by Whom . . . 24 105 5.2 Select a private-key and corresponding selector 106 information . . . . . . . . . . . . . . . . . . . . . . . 25 107 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 29 108 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 29 109 6.2 Extract the Signature from the Message . . . . . . . . . . 29 110 6.3 Get the Public Key . . . . . . . . . . . . . . . . . . . . 30 111 6.4 Compute the Verification . . . . . . . . . . . . . . . . . 31 112 6.5 Apply Sender Signing Policy . . . . . . . . . . . . . . . 33 113 6.6 Interpret Results/Apply Local Policy . . . . . . . . . . . 33 114 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 35 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 116 9. Security Considerations . . . . . . . . . . . . . . . . . . 35 117 9.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 35 118 9.2 Misappropriated Private Key . . . . . . . . . . . . . . . 36 119 9.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 37 120 9.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 37 121 9.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 38 122 9.6 Limits on Revoking Key Authorization . . . . . . . . . . . 38 123 9.7 Intentionally malformed Key Records . . . . . . . . . . . 38 124 9.8 Intentionally Malformed DKIM-Signature header fields . . . 39 125 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 126 10.1 References -- Normative . . . . . . . . . . . . . . . . 39 127 10.2 References -- Informative . . . . . . . . . . . . . . . 40 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 129 A. Appendix A -- Usage Examples (INFORMATIVE) . . . . . . . . . 42 130 A.1 Simple message transfer . . . . . . . . . . . . . . . . . 42 131 A.2 Outsourced business functions . . . . . . . . . . . . . . 42 132 A.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 43 133 A.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 43 134 A.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 43 135 A.6 Third-party Message Transmission . . . . . . . . . . . . . 44 136 B. Appendix B -- Example of Use (INFORMATIVE) . . . . . . . . . 44 137 B.1 The user composes an email . . . . . . . . . . . . . . . . 44 138 B.2 The email is signed . . . . . . . . . . . . . . . . . . . 45 139 B.3 The email signature is verified . . . . . . . . . . . . . 46 140 C. Appendix C -- Creating a public key (INFORMATIVE) . . . . . 47 141 D. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 48 142 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 143 Intellectual Property and Copyright Statements . . . . . . . 49 145 1. Introduction 147 1.1 Overview 149 DomainKeys Identified Mail (DKIM) defines a simple, low cost, and 150 effective mechanism by which cryptographic signatures can be applied 151 to email messages, to demonstrate that the sender of the message was 152 authorized to use a given email address. Message recipients can 153 verify the signature by querying the signer's domain directly to 154 determine whether the key that was used to sign the message was 155 authorized by that domain for that address. This confirms that the 156 message was sent by a party authorized to use the signer's email 157 address. 159 The approach taken by DKIM differs from previous approaches to 160 message signing (e.g. S/MIME, OpenPGP) in that: 162 o the message signature is written to the message header fields so 163 that neither human recipients nor existing MUA software are 164 confused by signature-related content appearing in the message 165 body 167 o there is no dependency on public and private key pairs being 168 issued by well-known, trusted certificate authorities 170 o there is no dependency on the deployment of any new Internet 171 protocols or services for public key distribution or revocation. 173 DKIM: 175 o is transparent and compatible with the existing email 176 infrastructure 178 o requires minimal new infrastructure 180 o can be implemented independently of clients in order to reduce 181 deployment time 183 o does not require the use of a trusted third party (such as a 184 certificate authority or other entity) which might impose 185 significant costs or introduce delays to deployment 187 o can be deployed incrementally. 189 Just as an email administrator, by creating an email account, gives a 190 user the ability to receive mail sent to a given address, DKIM allows 191 that administrator to constrain the use of that account when sending 192 email. The administrator can delegate the use of an address in 193 several ways. The administrator could operate a mail transfer agent 194 (MTA) or mail submission agent (MSA) for the domain that 195 authenticates the signer when accepting a message. This MTA or MSA 196 would typically have a private key that is authorized to send mail 197 for anyone in the domain. Alternatively, the administrator could 198 register a public key for the signer with which, assuming the sender 199 has an MTA or MUA with the appropriate software and the corresponding 200 private key, the sender could sign their own outgoing messages. In 201 the latter case, the private key would typically be authorized for 202 one or more specific email addresses that the sender is authorized to 203 use. 205 A "selector" mechanism allows multiple keys per domain, including 206 delegation of the right to authenticate a portion of the namespace to 207 a trusted third party. 209 1.2 Signing Identity 211 DKIM separates the question of the signer of the message from the 212 purported author of the message. In particular, a signature includes 213 the identity of the signer. Recipients can use the signing 214 information to decide how they want to process the message. 216 INFORMATIVE RATIONALE: The signing address associated with a DKIM 217 signature is not required to match a particular header field 218 because of the broad methods of interpretation by recipient mail 219 systems, including MUAs. 221 1.3 Scalability 223 The email identification problem is characterized by extreme 224 scalability requirements. There are currently on the order of 70 225 million domains and a much larger number of individual addresses. It 226 is important to preserve the positive aspects of the current email 227 infrastructure, such as the ability for anyone to communicate with 228 anyone else without introduction. 230 1.4 Simple Key Management 232 DKIM differs from traditional hierarchical public-key systems in that 233 no key signing infrastructure is required; the verifier requests the 234 public key from the claimed signer directly. 236 The DNS is proposed as the initial mechanism for publishing public 237 keys. DKIM is specifically designed to be extensible to other key 238 fetching services as they become available. 240 2. Terminology and Definitions 242 2.1 Signers 244 Elements in the mail system that sign messages are referred to as 245 signers. These may be MUAs, MSAs, MTAs, or other agents such as 246 mailing list exploders. In general any signer will be involved in 247 the injection of a message into the message system in some way. The 248 key issue is that a message must be signed before it leaves the 249 administrative domain of the signer. 251 2.2 Verifiers 253 Elements in the mail system that verify signatures are referred to as 254 verifiers. These may be MTAs, Messages Delivery Agents (MDA), or 255 MUAs. In most cases it is expected that verifiers will be close to 256 an end user (reader) of the message or some consuming agent such as a 257 mailing list exploder. 259 2.3 Imported ABNF tokens 261 The following tokens are imported from other RFCs as noted. Those 262 RFCs should be considered definitive. However, all tokens having 263 names beginning with "obs-" should be excluded from this import. 265 The following tokens are imported from RFC 2821: 267 o Local-part (implementation warning: this permits quoted strings) 269 o Domain (implementation warning: this permits address-literals) 271 o sub-domain 273 The following definitions are imported from RFC 2822: 275 o WSP (space or tab) 277 o FWS (folding white space) 279 o field-name (name of a header field) 281 Other tokens not defined herein are imported from RFC 2234. These 282 are mostly intuitive primitives such as SP, ALPHA, CRLF, etc. 284 2.4 White Space 286 There are three forms of white space: 288 o WSP represents simple white space, i.e., a space or a tab 289 character, and is inherited from RFC 2822. 291 o SWSP is streaming white space; it adds the CR and LF characters. 293 o FWS, also from RFC 2822, is folding white space. It allows 294 multiple lines to be joined separated by CRLF followed by at least 295 one white space. 297 Using the syntax of RFC 2234, the formal ABNF for SWSP is: 299 SWSP = CR / LF / WSP ; streaming white space 301 Other terminology is based on [ID-MAIL-ARCH]. 303 3. Protocol Elements 305 Protocol Elements are conceptual parts of the protocol that are not 306 specific to either signers or verifiers. The protocol descriptions 307 for signers and verifiers are described in later sections. 309 3.1 Selectors 311 To support multiple concurrent public keys per signing domain, the 312 key namespace is subdivided using "selectors". For example, 313 selectors might indicate the names of office locations (e.g., 314 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 315 (e.g., "january2005", "february2005", etc.), or even the individual 316 user. 318 INFORMATIVE IMPLEMENTERS' NOTE: reusing a selector with a new key 319 (for example, changing the key associated with a user's name) 320 makes it impossible to tell the difference between a message that 321 didn't verify because the key is no longer authorized versus a 322 message that is actually forged. Signers SHOULD NOT change the 323 key associated with a selector. When creating a new key, signers 324 SHOULD associate it with a new selector. 326 Selectors are needed to support some important use cases. For 327 example: 329 o Domains which want to authorize a partner, such as an advertising 330 provider or other outsourced function, to use a specific address 331 for a given duration. 333 o Domains which want to allow frequent travelers to send messages 334 locally without the need to connect with a particular MSA. 336 o "Affinity" domains (e.g., college alumni associations) which 337 provide forwarding of incoming mail but which do not operate a 338 mail submission agent for outgoing mail. 340 Periods are allowed in selectors and are component separators. If 341 keys are stored in DNS, the period defines sub-domain boundaries. 342 Sub-selectors might be used to combine dates with locations; for 343 example, "march2005.reykjavik". This can be used to allow delegation 344 of a portion of the selector name-space. 346 ABNF: 348 selector = sub-domain *( "." sub-domain ) 350 The number of public keys and corresponding selectors for each domain 351 are determined by the domain owner. Many domain owners will be 352 satisfied with just one selector whereas administratively distributed 353 organizations may choose to manage disparate selectors and key pairs 354 in different regions or on different email servers. 356 Beyond administrative convenience, selectors make it possible to 357 seamlessly replace public keys on a routine basis. If a domain 358 wishes to change from using a public key associated with selector 359 "january2005" to a public key associated with selector 360 "february2005", it merely makes sure that both public keys are 361 advertised in the public-key repository concurrently for the 362 transition period during which email may be in transit prior to 363 verification. At the start of the transition period, the outbound 364 email servers are configured to sign with the "february2005" private- 365 key. At the end of the transition period, the "january2005" public 366 key is removed from the public-key repository. 368 While some domains may wish to make selector values well known, 369 others will want to take care not to allocate selector names in a way 370 that allows harvesting of data by outside parties. E.g., if per-user 371 keys are issued, the domain owner will need to make the decision as 372 to whether to make this selector associated directly with the user 373 name, or make it some unassociated random value, such as the 374 fingerprint of the public key. 376 3.2 Tag=Value Format for DKIM header fields 378 DKIM uses a simple "tag=value" syntax in several contexts, including 379 in messages, domain signature records, and policy records. 381 Values are a series of strings containing either base64 text, plain 382 text, or quoted printable text, as defined in [RFC2045], section 6.7. 383 The name of the tag will determine the encoding of each value. In 384 general, the plain text type SHOULD be used if it is not permissible 385 to have 8 bit and/or syntactically problematic characters (such as 386 semicolon). Binary forms MUST be encoded as base64, and free form 387 text (e.g., user supplied) MUST be typed as quoted printable. 389 Formally, the syntax rules are: 391 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 392 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 393 tag-name = ALPHA 0*ALNUMPUNC 394 tag-value = *VALCHAR ; SWSP prohibited at beginning and end 395 VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 396 ; HTAB and SP to TILDE except SEMICOLON 397 ALNUMPUNC = ALPHA / DIGIT / "-" 398 ; alphanumeric plus hyphen. 400 Note that WSP is allowed anywhere around tags; in particular, WSP 401 between the tag-name and the "=", and any WSP before the terminating 402 ";" is not part of the value. 404 INFORMATIVE ADVICE: in some cases space might be limited for 405 storing tag-lists; notably, keys stored in DNS. For this reason, 406 tag-values that have length constraints SHOULD have single- 407 character tag names. 409 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 410 processed as case sensitive unless the specific tag description of 411 semantics specifies case insensitivity. 413 Duplicate tags MUST NOT be specified within a single tag-list. 415 Whitespace within a value MUST be retained unless explicitly excluded 416 by the specific tag description. 418 Tag=value pairs that represent the default value MAY be included to 419 aid legibility. 421 Unrecognized tags MUST be ignored. 423 Tags that have an empty value are not the same as omitted tags. An 424 omitted tag is treated as having the default value; a tag with an 425 empty value explicitly designates the empty string as the value. For 426 example, "g=" does not mean "g=*", even though "g=*" is the default 427 for that tag. 429 3.3 Signing and Verification Algorithms 431 DKIM supports multiple key signing/verification algorithms. The only 432 algorithm defined by this specification at this time is rsa-sha1, 433 which is the default if no algorithm is specified and which MUST be 434 supported by all implementations. 436 3.3.1 The rsa-sha1 Signing Algorithm 438 The rsa-sha1 Signing Algorithm computes a SHA-1 hash of the message 439 header field and body as described in section XINDX below. That hash 440 is then encrypted by the signer using the RSA algorithm and the 441 signer's private key. The hash MUST NOT be truncated or converted 442 into any form other than the native binary form before being signed. 444 More formally, the algorithm for the signature using rsa-sha1 is: 446 RSA(SHA1(canon_message, DKIM-SIG), key) 448 where canon_message is the canonicalized message header and body as 449 defined in Section 3.4 and DKIM-SIG is the canonicalized DKIM- 450 Signature header field sans the signature value itself. 452 3.3.2 Other algorithms 454 Other algorithms MAY be defined in the future. Verifiers MUST ignore 455 any signatures using algorithms that they do not understand. 457 3.3.3 Key sizes 459 Selecting appropriate key sizes is a trade-off between cost, 460 performance and risk. All implementations MUST support keys of sizes 461 512, 768, 1024, 1536 and 2048 bits and MAY support larger keys. 463 Factors that should influence the key size choice include: 465 o The practical constraint that a 2048 bit key is the largest key 466 that fits within a 512 byte DNS UDP response packet 468 o The security constraint that keys smaller than 1024 bits are 469 subject to brute force attacks. 471 o Larger keys impose higher CPU costs to verify and sign email 473 o Keys can be replaced on a regular basis, thus their lifetime can 474 be relatively short 476 o The security goals of this specification are modest compared to 477 typical goals of public-key systems 479 3.4 Canonicalization 481 Empirical evidence demonstrates that some mail servers and relay 482 systems modify email in transit, potentially invalidating a 483 signature. There are two competing perspectives on such 484 modifications. For most signers, mild modification of email is 485 immaterial to the authentication status of the email. For such 486 signers a canonicalization algorithm that survives modest in-transit 487 modification is preferred. 489 Other signers however, demand that any modification of the email -- 490 however minor -- results in an authentication failure. These signers 491 prefer a canonicalization algorithm that does not tolerate in-transit 492 modification of the signed email. 494 To satisfy both requirements, two canonicalization algorithms are 495 defined: a "simple" algorithm that tolerates almost no modification 496 and a "nowsp" algorithm that tolerates common modifications as white- 497 space replacement and header field line re-wrapping. A signer MAY 498 specify either algorithm when signing an email. If no 499 canonicalization algorithm is specified by the signer, the "simple" 500 algorithm is used. A verifier MUST be able to process email using 501 either canonicalization algorithm. Further canonicalization 502 algorithms MAY be defined in the future; verifiers MUST ignore any 503 signatures that use unrecognized canonicalization algorithms. 505 Canonicalization simply prepares the email for presentation to the 506 signing or verification algorithm. It MUST NOT change the 507 transmitted data in any way. 509 In all cases, the header field of the message is presented to the 510 signing algorithm first in the order indicated by the signature 511 header field. Only header fields listed as signed in the signature 512 header field are included. The CRLF separating the header field from 513 the body is then presented. Canonicalization of header fields and 514 body are described below. 516 3.4.1 The "simple" canonicalization algorithm 518 o Ignore all empty lines at the end of the message body. An empty 519 line is a line of zero length after removal of the line 520 terminator. 522 o Make no further changes to either the header field or the body. 523 In particular, no white space should be ignored other than as 524 described above. 526 3.4.2 The "nowsp" canonicalization algorithm 528 The "nowsp" algorithm ignores all white space from all lines and 529 unwraps header field continuation lines. These rules MUST be applied 530 in order. 532 o Unwrap header field continuation lines so that individual header 533 fields are processed as a single line. Only folding line 534 terminators (CRLF followed by white space) should be removed 535 during this step; in particular, implementations MUST NOT remove 536 the colon between the header field name and header field value and 537 MUST NOT remove the terminating CRLF on individual header fields. 539 o Map all header field names (not the header field contents) to 540 lower case. For example, convert "SUBJect: AbC" to "subject: 541 AbC". 543 o Ignore all SWSP in the body. SWSP is defined in [XINDX]. Line 544 terminators have no special significance here; in particular, CR 545 and LF MUST be ignored when computing the signature. 547 o Ignore all SWSP in header fields except for the trailing CRLF. 548 That is, the signing algorithm processes a single CRLF between 549 each header field and two CRLFs between the end of the last header 550 field signed and the body. 552 INFORMATIVE RATIONALE: header fields are often rewrapped during 553 transmission, especially at gateways. Some bodies will get 554 wrapped to obey line length limits; eliminating all SWSP allows 555 wrapping even at arbitrary points. 557 INFORMATIVE EXAMPLE: A message reading: 559 A: X 560 B: Y 561 Z 562 563 C 564 D E 566 is canonicalized to: 568 a:Xb:YZCDE 570 After the body is processed, a single CRLF followed by the "DKIM- 571 Signature" header field being created or verified is presented to the 572 algorithm. The contents of the "b=" tag, if any, MUST be deleted, 573 and the header field must be canonicalized according to the algorithm 574 that is specified in the "c=" tag. Any final CRLF on the "DKIM- 575 Signature" header field MUST NOT be included in the signature 576 computation. 578 INFORMATIVE DISCUSSION: Some parties have proposed extending the 579 "nowsp" algorithm to also remove the leading ">" on all lines 580 beginning ">From " (six characters, including a trailing space). 581 This is not included in this specification because of (a) the 582 additional complexity required in the algorithm and (b) a lack of 583 clear understanding of whether this transformation happens 584 primarily during message transmission or primarily during storage 585 in a UNIX V7-style local mailbox. Evidence indicates that such 586 munging during transmission is rare at this time. 588 3.4.3 Body Length Limits 590 A body length count MAY be specified to limit the signature 591 calculation to an initial prefix of the body text. If the body 592 length count is not specified then the entire message body is signed 593 and verified. 595 INFORMATIVE IMPLEMENTATION NOTE: The l= tag could be useful in 596 increasing signature robustness when sending to a mailing list 597 that both modifies content sent to it and does not sign its 598 messages. However, using the l= tag enables a replay attack in 599 which a sender with malicious intent modifies a message to include 600 content that solely benefits the attacker. It is possible for the 601 appended content to completely replace the original content in the 602 end recipient's eyes and to defeat duplicate message detection 603 algorithms. To avoid this attack, signers should be wary of using 604 this tag, and verifiers might wish to ignore the tag or remove 605 text that appears after the specified content length. 607 The body length count allows the signer of a message to permit data 608 to be appended to the end of the body of a signed message. The body 609 length count is made following the canonicalization algorithm; for 610 example whitespace characters MUST NOT be included in the count when 611 using the "nowsp" algorithm. 613 INFORMATIVE RATIONALE: This capability is provided because it is 614 very common for mailing lists to add trailers to messages (e.g., 615 instructions how to get off the list). Until those messages are 616 also signed, the body length count is a useful tool for the 617 verifier since it MAY as a matter of policy accept messages having 618 valid signatures with extraneous data. 620 Signers of MIME messages that include a body length count SHOULD be 621 sure that the length extends to the closing MIME boundary string. 623 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 624 the only acceptable modifications are to add to the MIME postlude 625 would use a body length count encompassing the entire final MIME 626 boundary string, including the final "--CRLF". A signer wishing 627 to allow additional MIME parts but not modification of existing 628 parts would use a body length count extending through the final 629 MIME boundary string, omitting the final "--CRLF". 631 A body length count of zero means that the body is completely 632 unsigned. 634 Note that verifiers MAY choose to reject or truncate messages that 635 have body content beyond that specified by the body length count. 637 INFORMATIVE IMPLEMENTATION ADVICE: Signers wishing to ensure that 638 no modification of any sort can occur SHOULD specify the "simple" 639 algorithm and no body length count. 641 Despite the measures described above, some messages, particularly 642 those containing 8-bit data, could be subject to modification in 643 transit invalidating the signature. Messages containing 8-bit data 644 SHOULD be converted to MIME format prior to signing, using a suitable 645 content transfer-encoding such as quoted-printable or base64. Such 646 conversion is outside the scope of DKIM; the actual message SHOULD be 647 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 648 DKIM algorithm. 650 3.5 The DKIM-Signature header field 652 The signature of the email is stored in the "DKIM-Signature:" header 653 field. This header field contains all of the signature and key- 654 fetching data. The DKIM-Signature value is a tag-list as described 655 in XINDX. 657 The "DKIM-Signature:" header field SHOULD be treated as though it 658 were a trace header field as defined in section 3.6 of [RFC2822], and 659 hence SHOULD NOT be reordered and SHOULD be kept in blocks prepended 660 to the message. In particular, the "DKIM-Signature" header field 661 SHOULD precede the original email header fields presented to the 662 canonicalization and signature algorithms. 664 The "DKIM-Signature:" header field is included in the signature 665 calculation, after the body of the message; however, when calculating 666 or verifying the signature, the b= (signature value) value MUST be 667 treated as though it were the null string. Unknown tags MUST be 668 signed but MUST be otherwise ignored by verifiers. 670 The encodings for each field type are listed below. Tags described 671 as quoted-printable are as described in section 6.7 of [RFC2045], 672 with the additional conversion of semicolon and vertical bar 673 characters to =3B and =7C, respectively. 675 Tags on the DKIM-Signature header field along with their type and 676 requirement status are shown below. Valid tags are: 678 v= Version (MUST NOT be included). This tag is reserved for future 679 use to indicate a possible new, incompatible version of the 680 specification. It MUST NOT be included in the DKIM-Signature 681 header field. 683 a= The algorithm used to generate the signature (plain-text; 684 REQUIRED). Signers and verifiers MUST support "rsa-sha1", an RSA- 685 signed SHA-1 digest. See section XINDX for a description of 686 algorithms. 688 INFORMATIVE RATIONALE: The authors understand that SHA-1 has 689 been theoretically compromised. However, viable attacks 690 require the attacker to choose both sets of input text; given a 691 preexisting input (a "preimaging" attack), it is still hard to 692 determine another input that produces an SHA-1 collision, and 693 the chance that such input would be of value to an attacker is 694 minimal. Also, there is broad library for SHA-1, whereas 695 alternatives such as SHA-256 are just emerging. Finally, DKIM 696 is not intended to have legal- or military-grade requirements. 697 There is nothing inherent in using SHA-1 here other than 698 implementer convenience. See 699 for 700 a discussion of the security issues. 702 b= The signature data (base64; REQUIRED). Whitespace is ignored in 703 this value and MUST be ignored when re-assembling the original 704 signature. This is another way of saying that the signing process 705 can safely insert FWS in this value in arbitrary places to conform 706 to line-length limits. See section [XINDX (Signer Actions)] for 707 how the signature is computed. 709 c= Body canonicalization (plain-text; OPTIONAL, default is 710 "simple"). This tag informs the verifier of the type of 711 canonicalization used to prepare the message for signing. The 712 semantics of this field is described in section XINDX above. 714 d= The domain of the signing entity (plain-text; REQUIRED). This 715 is the domain that will be queried for the public key. This 716 domain MUST be the same as or a parent domain of the "i=" tag. 717 When presented with a signature that does not meet this 718 requirement, verifiers MUST either ignore the signature or reject 719 the message.. 721 h= Signed header fields (plain-text, but see description; 722 REQUIRED). A colon-separated list of header field names that 723 identify the header fields presented to the signing algorithm. 724 The field MUST contain the complete list of header fields in the 725 order presented to the signing algorithm. The field MAY contain 726 names of header fields that do not exist when signed; nonexistent 727 header fields do not contribute to the signature computation (that 728 is, they are treated as the null input, including the header field 729 name, the separating colon, the header field value, and any CRLF 730 terminator), and when verified non-existent header fields MUST be 731 treated in the same way. The field MUST NOT include the DKIM- 732 Signature header field that is being created or verified. Folding 733 white space (FWS) MAY be included on either side of the colon 734 separator. Header field names MUST be compared against actual 735 header field names in a case insensitive manner. 737 ABNF: 739 sig-h-tag = "h=" *FWS hdr-name 0*( *FWS ":" *FWS hdr-name ) 740 hdr-name = field-name 741 INFORMATIVE EXPLANATION: By "signing" header fields that do 742 not actually exist, a signer can prevent insertion of those 743 header fields before verification. However, since a sender 744 cannot possibly know what header fields might be created in the 745 future, and that some MUAs might present header fields that are 746 embedded inside a message (e.g., as a message/rfc822 content 747 type), the security of this solution is not total. 749 INFORMATIVE EXPLANATION: The exclusion of the header field 750 name and colon as well as the header field value for non- 751 existent header fields prevents an attacker from inserting an 752 actual header field with a null value. 754 i= Identity of the user or agent (e.g., a mailing list manager) on 755 behalf of which this message is signed (quoted-printable; 756 OPTIONAL, default is an empty local-part followed by an "@" 757 followed by the domain from the "d=" tag). The syntax is a 758 standard email address where the local-part is optional. If the 759 signing domain is unable or unwilling to commit to an individual 760 user name within their domain, the local-part of the address MUST 761 be omitted. If the local-part of the address is omitted or the 762 "i=" tag is not present, the key used to sign MUST be valid for 763 any address in the domain. The domain part of the address MUST be 764 the same as or a subdomain of the value of the "d=" tag. 766 ABNF: 768 sig-i-tag = "i=" [ Local-part ] "@" Domain 770 INFORMATIVE DISCUSSION: This document does not require the 771 value of the "i=" tag to match the identity in any message 772 header field fields. This is considered to be a verifier 773 policy issue, described in another document [XREF-TBD]. 774 Constraints between the value of the "i=" tag and other 775 identities in other header fields seek to apply basic 776 authentication into the semantics of trust associated with a 777 role such as content author. Trust is a broad and complex 778 topic and trust mechanisms are subject to highly creative 779 attacks. The real-world efficacy of any but the most basic 780 bindings between the "i=" value and other identities is not 781 well established, nor is its vulnerability to subversion by an 782 attacker. Hence reliance on the use of these options SHOULD be 783 strictly limited. In particular it is not at all clear to what 784 extent a typical end-user recipient can rely on any assurances 785 that might be made by successful use of the "i=" options. 787 l= Body count (plain-text decimal integer; OPTIONAL, default is 788 entire body). This tag informs the verifier of the number of 789 bytes in the body of the email included in the cryptographic hash, 790 starting from 0 immediately following the CRLF preceding the body. 792 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 793 allow display of fraudulent content without appropriate warning 794 to end users. The l= tag is intended for increasing signature 795 robustness when sending to mailing lists that both modify their 796 content and do not sign their messages. However, using the l= 797 tag enables man-in-the-middle attacks in which an intermediary 798 with malicious intent modifies a message to include content 799 that solely benefits the attacker. It is possible for the 800 appended content to completely replace the original content in 801 the end recipient's eyes and to defeat duplicate message 802 detection algorithms. Examples are described in Security 803 Considerations [XINDX]. 805 To avoid this attack, signers should be extremely wary of using 806 this tag, and verifiers might wish to ignore the tag or remove 807 text that appears after the specified content length. 809 q= A colon-separated list of query methods used to retrieve the 810 public key (plain-text; OPTIONAL, default is "dns"). Each query 811 method is of the form "type[/options]", where the syntax and 812 semantics of the options depends on the type. If there are 813 multiple query mechanisms listed, the choice of query mechanism 814 MUST NOT change the interpretation of the signature. Currently 815 the only valid value is "dns" which defines the DNS lookup 816 algorithm described elsewhere in this document. No options are 817 defined for the "dns" query type, but the string "dns" MAY have a 818 trailing "/" character. Verifiers and signers MUST support "dns". 820 INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on 821 "dns" allows for the possibility of adding options later and 822 makes it clear that matching of the query type must terminate 823 on either "/" or end of string. 825 s= The selector subdividing the namespace for the "d=" (domain) tag 826 (plain-text; REQUIRED). 828 t= Signature Timestamp (plain-text; RECOMMENDED, default is an 829 unknown creation time). The time that this signature was created. 830 The format is the standard Unix seconds-since-1970. The value is 831 expressed as an unsigned integer in decimal ASCII. 833 INFORMATIVE IMPLEMENTATION NOTE: This value is not constrained 834 to fit into a 31- or 32-bit integer. Implementations SHOULD be 835 prepared to handle values up to at least 10^12 (until 836 approximately AD 200,000; this fits into 40 bits). To avoid 837 denial of service attacks, implementations MAY consider any 838 value longer than 12 digits to be infinite. 840 x= Signature Expiration (plain-text; RECOMMENDED, default is no 841 expiration). Signature expiration in seconds-since-1970 format as 842 an absolute date, not as a time delta from the signing timestamp. 843 Signatures MUST NOT be considered valid if the current time at the 844 verifier is past the expiration date. The value is expressed as 845 an unsigned integer in decimal ASCII. 847 INFORMATIVE IMPLEMENTATION NOTE: See above. 849 INFORMATIVE NOTE: The x= tag is not intended as an anti-replay 850 defense. 852 z= Copied header fields (plain-text, but see description; OPTIONAL, 853 default is null). A vertical-bar-separated list of header field 854 names and copies of header field values that identify the header 855 fields presented to the signing algorithm. The field MUST contain 856 the complete list of header fields in the order presented to the 857 signing algorithm. Copied header field values MUST immediately 858 follow the header field name with a colon separator (no white 859 space permitted). Header field values MUST be represented as 860 Quoted-Printable [XREF] with vertical bars, colons, semicolons, 861 and white space encoded in addition to the usual requirements. 863 Verifiers MUST NOT use the copied header field values for 864 verification should they be present in the h= field. Copied header 865 field values are for forensic use only. 867 header fields with characters requiring conversion (perhaps from 868 legacy MTAs which are not RFC 2822 compliant) SHOULD be converted as 869 described in [RFC2047]. 871 ABNF: 873 sig-z-tag = "z=" *FWS hdr-copy *( *FWS "|" hdr-copy ) 874 *FWS 878 ; needs to be updated with real definition 879 ; (could be messy) 881 INFORMATIVE EXAMPLE of a signature header field spread across 882 multiple continuation lines: 884 DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane 885 c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; 886 h=from:to:subject:date; 887 z=From:foo@eng.example.net|To:joe@example.com| 888 Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 889 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 890 VoG4ZHRNiYzR 892 3.6 The Authentication-Results header field 894 Verifiers wishing to communicate the results of verification via an 895 email header field SHOULD use the Authentication-Results header field 896 [ID-AUTH-RES]. 898 3.7 Key Management and Representation 900 DKIM keys do not require third party signatures by Certificate 901 Authorities in order to be trusted, since the public key is retrieved 902 directly from the signer. 904 DKIM keys can potentially be stored in multiple types of key servers 905 and in multiple formats. The storage and format of keys are 906 irrelevant to the remainder of the DKIM algorithm. 908 Parameters to the key lookup algorithm are the domain of the 909 responsible signer (the "d=" tag of the DKIM-Signature header field), 910 the selector (the "s=" tag), and the signing identity (the "i=" tag). 911 The "i=" tag value could be ignored by some key services. 913 This document defines a single binding, using DNS to distribute the 914 keys. 916 3.7.1 Textual Representation 918 It is expected that many key servers will choose to present the keys 919 in a text format. The following definition MUST be used for any DKIM 920 key represented in textual form. 922 The overall syntax is a key-value-list as described above. The 923 current valid tags are: 925 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 926 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 927 (without the quotes). This tag MUST be the first tag in the 928 response. Responses beginning with a "v=" tag with any other 929 value MUST be discarded. 931 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 932 This value MUST match the local part of the signing address, with 933 a "*" character acting as a wildcard. The intent of this tag is 934 to constrain which signing address can legitimately use this 935 selector. An email with a signing address that does not match the 936 value of this tag constitutes a failed verification. Wildcarding 937 allows matching for addresses such as "user+*". An empty "g=" 938 value never matches any addresses. 940 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 941 allowing all algorithms). A colon-separated list of hash 942 algorithms that might be used. Signers and Verifiers MUST support 943 the "sha1" hash algorithm. 945 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 946 verifiers MUST support the 'rsa' key type. 948 n= Notes that might be of interest to a human (quoted-printable; 949 OPTIONAL, default is empty). No interpretation is made by any 950 program. This tag should be used sparingly in any key server 951 mechanism that has space limitations (notably DNS). 953 p= Public-key data (base64; REQUIRED). An empty value means that 954 this public key has been revoked. The syntax and semantics of 955 this tag value is defined by the k= tag. 957 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 958 separated list of service types to which this record applies. 959 Verifiers for a given service type MUST ignore this record if the 960 appropriate type is not listed. Currently defined service types 961 are: 963 * matches all service types 965 email electronic mail (not necessarily limited to SMTP) 967 This tag is intended to permit senders to constrain the use of 968 delegated keys, e.g., where a company is willing to delegate 969 the right to send mail in their name to an outsourcer, but not 970 to send IM or make VoIP calls. (This of course presumes that 971 these keys are used in other services in the future.) 973 t= Flags, represented as a colon-separated list of names (plain- 974 text; OPTIONAL, default is no flags set). The defined flags are: 976 y This domain is testing DKIM; unverified email MUST NOT be 977 treated differently from verified email. Verifier systems MAY 978 wish to track testing mode results to assist the signer. 980 Unrecognized flags MUST be ignored. 982 3.7.2 DNS binding 984 A binding using DNS as a key service is hereby defined. All 985 implementations MUST support this binding. 987 3.7.2.1 Name Space. 989 All DKIM keys are stored in a "_domainkey" subdomain. Given a DKIM- 990 Signature field with a "d=" tag of "domain" and an "s=" tag of 991 "selector", the DNS query will be for "selector._domainkey.domain". 993 The value of the "i=" tag is not used by the DNS binding. 995 3.7.2.2 Resource Record Types for Key Storage 997 This section needs to be fleshed out. ACTUALLY: will be addressed 998 in another document. 1000 Two RR types are used: DKK and TXT. 1002 The DKK RR is expected to be a non-text, binary representation 1003 intended to allow the largest possible keys to be represented and 1004 transmitted in a UDP DNS packet. Details of this RR are described in 1005 [ID-DK-RR]. 1007 TXT records are encoded as described in section XINDX above. 1009 Verifiers SHOULD search for a DKIM RR first, if possible, followed by 1010 a TXT RR. If the verifier is unable to search for a DKK RR or a DKK 1011 RR is not found, the verifier MUST search for a TXT RR. 1013 4. Semantics of Multiple Signatures 1015 Considerable energy has been spent discussion the desirability and 1016 semantics of multiple DKIM signatures in a single message. On the 1017 one hand, discarding existing signature header fields loses 1018 information which could prove to be valuable in the future. On the 1019 other hand, since header fields are known to be re-ordered in transit 1020 by at least some MTAs, determining the most interesting signature 1021 header field is non-trivial. 1023 Further confusion could occur with multiple signatures added at the 1024 same logical "depth". For example, a signer could choose to sign 1025 using different signing or canonicalization algorithms. However, 1026 even this is problematic because some of those signatures will 1027 inevitably have to sign some of the others (and at very minimum must 1028 be presented to the verification algorithm in the same order as 1029 presented to the signature algorithm). 1031 Also, many agents are expected to break existing signatures (e.g., a 1032 mailing list that modifies Subject header fields or adds unsubscribe 1033 information to the end of the message). Retaining signature 1034 information that is known to be bad could create more problems than 1035 it solves. 1037 For these reasons, multiple signatures are not prohibited but are 1038 left undefined. 1040 INFORMATIVE IMPLEMENTATION GUIDANCE: Agents that forward mail 1041 without modification could decide whether to add another signature 1042 or simply retain an existing signatures. Agents that are known to 1043 break existing signatures MAY leave the existing signature or 1044 delete it. Agents that re-sign messages that are already signed 1045 SHOULD verify the previous signature and should probably refuse to 1046 sign any critical information that failed a signature 1047 verification. 1049 5. Signer Actions 1051 5.1 Determine if the Email Should be Signed and by Whom 1053 A signer can obviously only sign email for domains for which it has a 1054 private-key and the necessary knowledge of the corresponding public 1055 key and selector information. However there are a number of other 1056 reasons beyond the lack of a private key why a signer could choose 1057 not to sign an email. 1059 A SUBMISSION server MAY sign if the sender is authenticated by some 1060 secure means, e.g., SMTP AUTH. Within a trusted enclave the signing 1061 address MAY be derived from the header field according to local 1062 signer policy. Within a trusted enclave an MTA MAY do the signing. 1064 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1065 sign Received header fields if the outgoing gateway MTA obfuscates 1066 Received header fields, for example to hide the details of 1067 internal topology. 1069 A signer MUST NOT sign an email if the submitter is not authorized to 1070 use the signing address. 1072 A signer SHOULD NOT remove an existing "DKIM-Signature:" header field 1073 unless that signature was added by an entity under the same domain. 1074 That is, DKIM-Signature header fields SHOULD NOT be removed unless 1075 the d= tag of that existing DKIM-Signature header field is the same 1076 as or a subdomain of the d= tag of the new DKIM-Signature header 1077 field that is being added. 1079 If an email cannot be signed for some reason, it is a local policy 1080 decision as to what to do with that email. 1082 5.2 Select a private-key and corresponding selector information 1084 This specification does not define the basis by which a signer should 1085 choose which private-key and selector information to use. Currently, 1086 all selectors are equal as far as this specification is concerned, so 1087 the decision should largely be a matter of administrative 1088 convenience. 1090 A signer SHOULD NOT sign with a key that is expected to expire within 1091 seven days; that is, when rotating to a new key, signing should 1092 immediately commence with the new key and the old key SHOULD be 1093 retained for at least seven days before being removed from the key 1094 server. 1096 5.2.1 Normalize the Message to Prevent Transport Conversions 1098 Some messages, notably those using 8-bit characters, are subject to 1099 conversion to 7-bit during transmission. Such conversions will break 1100 DKIM signatures. In order to minimize the chances of such breakage, 1101 signers SHOULD convert the message to MIME-encoded 7-bit form as 1102 described in [RFC2045] before signing. 1104 Should the message be submitted to the signer with any local encoding 1105 that will be modified before transmission, such conversion to 1106 canonical form MUST be done before signing. In particular, some 1107 systems use local line separator conventions (such as the Unix 1108 newline character) internally rather than the SMTP-standard CRLF 1109 sequence. All such local conventions MUST be converted to canonical 1110 format before signing. 1112 More generally, the signer MUST sign the message as it will be 1113 emitted on the wire rather than in some local or internal form. 1115 5.2.2 Determine the header fields to Sign 1117 The From header field MUST be signed (that is, included in the h= tag 1118 of the resulting DKIM-Signature header field); any header field that 1119 describes the role of the signer (for example, the Sender or Resent- 1120 From header field if the signature is on behalf of the corresponding 1121 address and that address is different from the From address) MUST 1122 also be included. The signed header fields SHOULD also include the 1123 Subject and Date header fields as well as all MIME header fields. 1124 Signers SHOULD NOT sign an existing header field likely to be 1125 legitimately modified or removed in transit. In particular, RFC 2821 1126 explicitly permits modification or removal of the "Return-Path" 1127 header field in transit. Signers MAY include any other header fields 1128 present at the time of signing at the discretion of the signer. It 1129 is RECOMMENDED that all other existing, non-repeatable header fields 1130 be signed. 1132 The DKIM-Signature header field is always implicitly signed and MUST 1133 NOT be included in the h= tag except to indicate that other 1134 preexisting signatures are also signed. 1136 Signers MUST sign any header fields that the signers wish to have the 1137 verifiers treat as trusted. Put another way, verifiers MAY treat 1138 unsigned header fields with extreme skepticism, up to and including 1139 refusing to display them to the end user. 1141 Signers MAY claim to have signed header fields that do not exist 1142 (that is, signers MAY include the header field name in the h= tag 1143 even if that header field does not exist in the message). When 1144 computing the signature, the non-existing header field MUST be 1145 treated as the null string (including the header field name, header 1146 field value, all punctuation, and the trailing CRLF). 1148 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1149 the absence of a header field; if that header field should be 1150 added later the signature will fail. 1152 Signers choosing to sign an existing replicated header field (such as 1153 Received) MUST sign the physically last instance of that header field 1154 in the header field block. Signers wishing to sign multiple 1155 instances of an existing replicated header field MUST include the 1156 header field name multiple times in the h= tag of the DKIM-Signature 1157 header field, and MUST sign such header fields in order from the 1158 bottom of the header field block to the top. The signer MAY include 1159 more header field names than there are actual corresponding header 1160 fields to indicate that additional header fields of that name SHOULD 1161 NOT be added. (However, header fields that can be replicated should 1162 not be signed; see below.) 1163 INFORMATIVE EXAMPLE: 1165 If the signer wishes to sign two existing Received header fields, 1166 and the existing header contains: 1168 Received: 1169 Received: 1170 Received: 1172 then the resulting DKIM-Signature header field should read: 1174 DKIM-Signature: ... h=Received : Received : ... 1176 and Received header fields and will be signed in that 1177 order. 1179 Signers SHOULD NOT sign header fields that might be replicated 1180 (either at the time of signing or potentially in the future), with 1181 the exception of trace header fields such as Received. Comment and 1182 non standard header fields (including X-* header fields) are 1183 permitted by [RFC2822] to be replicated; however, many such header 1184 fields are, by convention, not replicated. Signers need to 1185 understand the implications of signing header field fields that might 1186 later be replicated, especially in the face of header field 1187 reordering. In particular, [RFC2822] only requires that trace header 1188 fields retain the original order. 1190 INFORMATIVE RATIONALE: Received: is allowed because these header 1191 fields, as well as Resent-* header fields, are already order- 1192 sensitive. 1194 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1195 header field blocks to be reordered (with the exception of 1196 Received header fields), reordering of signed replicated header 1197 fields by intermediate MTAs will cause DKIM signatures to be 1198 broken; such anti-social behavior should be avoided. 1200 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1201 specification, all end-user visible header fields should be signed 1202 to avoid possible "indirect spamming." For example, if the 1203 "Subject" header field is not signed, a spammer can resend a 1204 previously signed mail, replacing the legitimate subject with a 1205 one-line spam. 1207 INFORMATIVE NOTE: There has been some discussion that a Sender 1208 Signing Policy include the list of header fields that the signer 1209 always signs. N.B. In theory this is unnecessary, since as long 1210 as the signer really always signs the indicated header fields 1211 there is no possibility of an attacker replaying an existing 1212 message that has such an unsigned header field. 1214 5.2.3 Compute the Signature 1216 The signer MUST use one of the defined canonicalization algorithms as 1217 described in section XINDX to present the email to the signing 1218 algorithm. Canonicalization is only used to prepare the email for 1219 signing; it does not affect the transmitted email in any way. 1221 To avoid possible ambiguity, a signer SHOULD either sign or remove 1222 any preexisting "Authentication-Results:" header fields from the 1223 email prior to preparation for signing and transmission. 1224 "Authentication-Results" header fields MUST only be signed if the 1225 signer is certain of the authenticity of the preexisting header 1226 field, for example, if it is locally generated or signed by a 1227 previous DKIM-Signature line that the current signer has verified. 1228 Signers MUST NOT sign Authentication-Results header fields that could 1229 be forgeries. 1231 Entities such as mailing list managers that implement DKIM and which 1232 modify the message or the header field (for example, inserting 1233 unsubscribe information) before retransmitting the message SHOULD 1234 check any existing signature on input and MUST make such 1235 modifications before re-signing the message; such signing SHOULD 1236 include the Authentication-Results header field, if any, inserted 1237 upon message receipt. 1239 All tags and their values in the DKIM-Signature header field are 1240 included in the cryptographic hash with the sole exception of the 1241 value of the "b=" (signature) tag, which MUST be treated as the null 1242 string. All tags MUST be included even if they might not be 1243 understood by the verifier. The header field MUST be presented to 1244 the hash algorithm after the body of the message rather than with the 1245 rest of the header fields and MUST be canonicalized as specified in 1246 the "c=" (canonicalization) tag. The DKIM-Signature header field 1247 MUST NOT be included in its own h= tag. 1249 When calculating the hash on values that will be base64 or quoted- 1250 printable encoded, the hash MUST be computed after the encoding. 1251 Likewise, the verifier MUST incorporate the values into the hash 1252 before decoding the base64 or quoted-printable text. 1254 With the exception of the canonicalization procedure described in 1255 section XINDX, the DKIM signing process treats the body of messages 1256 as simply a string of characters. DKIM messages MAY be either in 1257 plain-text or in MIME format; no special treatment is afforded to 1258 MIME content. Message attachments in MIME format MUST be included in 1259 the content which is signed. 1261 5.2.4 Insert the DKIM-Signature header field 1263 The final step in the signing process is that the signer MUST insert 1264 the "DKIM-Signature:" header field as defined in section XINDX prior 1265 to transmitting the email. The "DKIM-Signature" SHOULD be inserted 1266 before any header fields that it signs in the header field block. 1268 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1269 is to insert the "DKIM-Signature" header field at the beginning of 1270 the header field block. 1272 6. Verifier Actions 1274 6.1 Introduction 1276 Since a signer MAY expire a public key at any time, it is recommended 1277 that verification occur in a timely manner with the most timely place 1278 being during acceptance by the border MTA. 1280 A border or intermediate MTA MAY verify the message signatures and 1281 add a verification header field to incoming messages. This 1282 considerably simplifies things for the user, who can now use an 1283 existing mail user agent. Most MUAs have the ability to filter 1284 messages based on message header fields or content; these filters 1285 would be used to implement whatever policy the user wishes with 1286 respect to unsigned mail. 1288 A verifying MTA MAY implement a policy with respect to unverifiable 1289 mail, regardless of whether or not it applies the verification header 1290 field to signed messages. Separate policies MAY be defined for 1291 unsigned messages, messages with incorrect signatures, and when the 1292 signature cannot be verified. Treatment of unsigned messages MUST be 1293 based on the results of the Sender Signing Policy check described in 1294 [ID-DKPOLICY]. 1296 6.2 Extract the Signature from the Message 1298 The signature and associated signing identity is included in the 1299 value of the DKIM-Signature header field. 1301 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. 1302 Existence of such a tag indicates a new, incompatible version of the 1303 DKIM-Signature header field. 1305 If the "DKIM-Signature" header field does not contain the "i=" tag, 1306 the verifier MUST behave as though the value of that tag were "@d", 1307 where "d" is the value from the "d=" tag (which MUST exist). 1309 Verifiers MUST confirm that the domain specified in the "d=" tag is 1310 the same as or a superdomain of the domain part of the "i=" tag. If 1311 not, the DKIM-Signature header field MUST be ignored. 1313 Implementers MUST meticulously validate the format and values in the 1314 "DKIM-Signature:" header field; any inconsistency or unexpected 1315 values MUST result in an unverified email. Being "liberal in what 1316 you accept" is definitely a bad strategy in this security context. 1317 Note however that this does not include the existence of unknown tags 1318 in a "DKIM-Signature" header field, which are explicitly permitted. 1320 Verifiers MUST NOT attribute ultimate meaning to the order of 1321 multiple DKIM-Signature header fields. In particular, there is 1322 reason to believe that some relays will reorder the header field in 1323 potentially arbitrary ways. 1325 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1326 a clue to signing order in the absence of any other information. 1327 However, other clues as to the semantics of multiple signatures 1328 must be considered before using ordering. 1330 Since there can be multiple signatures in a message, a verifier 1331 SHOULD ignore an invalid signature (regardless if caused by a 1332 syntactic or semantic problem) and try other signatures. A verifier 1333 MAY choose to treat a message with one or more invalid signatures 1334 with more suspicion than a message with no signature at all. 1336 6.3 Get the Public Key 1338 The public key is needed to complete the verification process. The 1339 process of retrieving the public key depends on the query type as 1340 defined by the "q=" tag in the "DKIM-Signature:" header field line. 1341 Obviously, a public key should only be retrieved if the process of 1342 extracting the signature information is completely successful. 1343 Details of key management are described in section XINDX. The 1344 verifier MUST validate the key record and MUST ignore any public key 1345 records that are malformed. 1347 When validating a message, a verifier MUST: 1349 1. Retrieve the public key as described under Key Management (XINDX) 1350 using the domain from the "d=" tag and the selector from the "s=" 1351 tag. 1353 2. If the query for the public key fails to respond, the verifier 1354 SHOULD defer acceptance of this email (normally this will be 1355 achieved with a 451/4.7.5 SMTP response code). 1357 3. If the query for the public key fails because the corresponding 1358 RR does not exist, the verifier MUST ignore the signature. 1360 4. If the result returned from the query does not adhere to the 1361 format defined in this specification, the verifier MUST ignore 1362 the signature. 1364 5. If the "g=" tag in the public key does not match the local part 1365 of the "i=" tag on the message signature, the verifier MUST treat 1366 the signature as invalid. If the local part of the "i=" tag on 1367 the message signature is not present, the g= tag must be * (valid 1368 for all addresses in the domain) or not present (which defaults 1369 to *), otherwise the verifier MUST ignore the signature. Other 1370 than this test, verifiers MUST NOT treat a message signed with a 1371 key record having a g= tag any differently than one without; in 1372 particular, verifiers MUST NOT prefer messages that seem to have 1373 an individual signature by virtue of a g= tag vs. a domain 1374 signature. 1376 6. If the "h=" tag exists in the public key record and the hash 1377 algorithm implied by the a= tag in the DKIM-Signature header is 1378 not included in the "h=" tag, the verifier MUST ignore the 1379 signature. 1381 7. If the public key data is not suitable for use with the algorithm 1382 type defined by the "a=" tag in the "DKIM-Signature" header 1383 field, the verifier MUST ignore the signature. 1385 If the public key data (the "p=" tag) is empty then this key has been 1386 revoked and the verifier MUST treat this as a failed signature check. 1388 6.4 Compute the Verification 1390 Given a signer and a public key, verifying a signature consists of 1391 the following steps. 1393 o Based on the algorithm defined in the "c=" tag, the body length 1394 specified in the "l=" tag, and the header field names in the "h=" 1395 tag, create a canonicalized copy of the email as is described in 1396 section XINDX. When matching header field names in the "h=" tag 1397 against the actual message header field, comparisons MUST be case- 1398 insensitive. 1400 o Based on the algorithm indicated in the "a=" tag, 1402 * Compute the message hash from the canonical copy as described 1403 in section XINDX. Note that this requires presenting the 1404 "nowsp" canonicalized DKIM-Signature header field to the hash 1405 algorithm after the body of the message, and with the "b=" 1406 value treated as the empty string. 1408 * Decrypt the signature using the signer's public key. 1410 o Compare the decrypted signature to the message hash. 1412 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1413 initiate the public-key query in parallel with calculating the 1414 hash as the public key is not needed until the final decryption is 1415 calculated. 1417 Verifiers MUST ignore any DKIM-Signature header fields where the 1418 signature does not validate. Verifiers that are prepared to validate 1419 multiple signature header fields SHOULD proceed to the next signature 1420 header field, should it exist. However, verifiers MAY make note of 1421 the fact that an invalid signature was present for consideration at a 1422 later step. 1424 INFORMATIVE NOTE: The rationale of this requirement is to permit 1425 messages that have invalid signatures but also a valid signature 1426 to work. For example, a mailing list exploder might opt to leave 1427 the original submitter signature in place even though the exploder 1428 knows that it is modifying the message in some way that will break 1429 that signature, and the exploder inserts its own signature. In 1430 this case the message should succeed even in the presence of the 1431 known-broken signature. 1433 If a body length is specified in the "l=" tag of the signature, 1434 verifiers MUST only verify the number of bytes indicated in the body 1435 length. Verifiers MAY decide that a message containing bytes beyond 1436 the indicated body length MAY still treat such a message as 1437 suspicious. Verifiers MAY truncate the message at the indicated body 1438 length or reject the message outright. MUAs MAY visually mark the 1439 unverified part of the body in a distinctive font or color to the end 1440 user. 1442 6.5 Apply Sender Signing Policy 1444 Verifiers MUST consult the Sender Signing Policy as described in [ID- 1445 DKPOLICY] and act accordingly. The range of possibilities is up to 1446 the verifier, but it MAY include rejecting the email. 1448 6.6 Interpret Results/Apply Local Policy 1450 It is beyond the scope of this specification to describe what actions 1451 a verifier system should make, but an authenticated email presents an 1452 opportunity to a receiving system that unauthenticated email cannot. 1453 Specifically, an authenticated email creates a predictable identifier 1454 by which other decisions can reliably be managed, such as trust and 1455 reputation. Conversely, unauthenticated email lacks a reliable 1456 identifier that can be used to assign trust and reputation. It is 1457 reasonable to treat unauthenticated email as lacking any trust and 1458 having no positive reputation. 1460 If the verifying MTA is capable of verifying the public key of the 1461 signer and check the signature on the message synchronously with the 1462 SMTP session and such signature is missing or does not verify, the 1463 MTA MAY reject the message with an error such as: 550 5.7.1 Unsigned 1464 messages not accepted 550 5.7.5 Message signature incorrect 1466 If it is not possible to verify the authorization of the public key 1467 in the message, perhaps because the key server is not available, a 1468 temporary failure message MAY be generated, such as: 451 4.7.5 1469 Unable to verify signature - key server unavailable 1471 Once the signature has been verified, that information MUST be 1472 conveyed to higher level systems (such as explicit allow/white lists 1473 and reputation systems) and/or to the end user. If the 1474 authentication status is to be stored in the message header field, 1475 the Authentication-Results header field [ID-AUTH-RES] SHOULD be used 1476 to convey this information. If the message is signed on behalf of 1477 any address other than that in the From: header field, the mail 1478 system SHOULD take pains to ensure that the actual signing identity 1479 is clear to the reader. 1481 The verifier MAY treat unsigned header fields with extreme 1482 skepticism, including marking them as untrusted or even deleting them 1483 before display to the end user. 1485 While the symptoms of a failed verification are obvious -- the 1486 signature doesn't verify -- establishing the exact cause can be more 1487 difficult. If a selector cannot be found, is that because the 1488 selector has been removed or was the value changed somehow in 1489 transit? If the signature line is missing is that because it was 1490 never there, or was it removed by an over-zealous filter? For 1491 diagnostic purposes, the exact reason why the verification fails 1492 SHOULD be recorded in the "Authentication-Results" header field and 1493 possibly the system logs. However in terms of presentation to the 1494 end user, the result SHOULD be presented as a simple binary result: 1495 either the email is verified or it is not. If the email cannot be 1496 verified, then it SHOULD be rendered the same as all unverified email 1497 regardless of whether it looks like it was signed or not. 1499 Insert the Authentication-Results header field. That header field is 1500 described in [ID-AUTH-RES]. The Authentication-Results header field 1501 SHOULD be inserted before any existing DKIM-Signature or 1502 Authentication-Results header fields in the header field block. 1504 INFORMATIVE ADVICE to MUA filter writers: 1506 Patterns intended to search for Authentication-Results header 1507 fields to visibly mark authenticated mail for end users should 1508 verify that the Authentication-Results header field was added by 1509 the appropriate verifying domain and that the verified identity 1510 matches the sender identity that will be displayed by the MUA. In 1511 particular, MUA patterns should not be influenced by bogus 1512 Authentication-Results header fields added by attackers. 1514 In order to retain the current semantics and visibility of the From 1515 header field, verifying mail agents SHOULD take steps to ensure that 1516 the signing address is prominently visible to the user if it is 1517 different from the From address. If MUA implementations that 1518 highlight the signed address are not available, this MAY be done by 1519 the validating MTA or MDA by rewriting the From address in a manner 1520 which remains compliant with [RFC2822]. If performed, the rewriting 1521 SHOULD include the name of the signer in the address. For example: 1523 From: John Q. User 1525 might be converted to 1527 From: "John Q. User via " 1529 This sort of address inconsistency is expected for mailing lists, but 1530 might be otherwise used to mislead the verifier, for example if a 1531 message supposedly from administration@your-bank.com had a Sender 1532 address of fraud@badguy.com. 1534 Under no circumstances should an unsigned header field be displayed 1535 in any context that might be construed by the end user as having been 1536 signed. Notably, unsigned header fields SHOULD be hidden from the 1537 end user to the extent possible. 1539 7. Compliance 1541 Placeholder for Phillip H-B's suggested compliance section: 1543 5) there should be a compliance section. I think that the spec 1544 should say what it takes for an email sender, recipient and MTA to 1545 comply with the spec in one place. In particular I think that 1546 somewhere there needs to be the statement that an SMTP forwarder is 1547 compliant with this spec IFF all messages that bear a signature are 1548 forwarded in a manner that preserves each of the canonicalization 1549 mechanisms specified. 1551 8. IANA Considerations 1553 Use of the _domainkey prefix in DNS records will require registration 1554 by IANA. 1556 The DKK and DKP RR types must be registered by IANA. 1558 9. Security Considerations 1560 It has been observed that any mechanism that is introduced which 1561 attempts to stem the flow of spam is subject to intensive attack. 1562 DKIM needs to be carefully scrutinized to identify potential attack 1563 vectors and the vulnerability to each. 1565 9.1 Misuse of Body Length Limits ("l=" Tag) 1567 Body length limits (in the form of the "l=" tag) are subject to 1568 several potential attacks. 1570 9.1.1 Addition of new MIME parts to multipart/* 1572 If the body length limit does not cover a closing MIME multipart 1573 header field (including the trailing "--CRLF" portion), then it is 1574 possible for an attacker to intercept a properly signed multipart 1575 message and add a new body part. Depending on the details of the 1576 MIME type and the implementation of the verifying MTA and the 1577 receiving MUA, this could allow an attacker to change the information 1578 displayed to an end user from an apparently trusted source. 1580 *** Example appropriate here *** 1582 9.1.2 Addition of new HTML content to existing content 1584 Several receiving MUA implementations do not cease display after a 1585 "" tag. In particular, this allows attacks involving 1586 overlaying images on top of existing text. 1588 INFORMATIVE EXAMPLE: Appending the following text to an existing, 1589 properly closed message will in many MUAs result in inappropriate 1590 data being rendered on top of existing, correct data: 1592
1593 1595
1597 9.2 Misappropriated Private Key 1599 If the private key for a user is resident on their computer and is 1600 not protected by an appropriately secure passphrase, it is possible 1601 for malware to send mail as that user. The malware would, however, 1602 not be able to generate signed spoofs of other signers' addresses, 1603 which would aid in identification of the infected user and would 1604 limit the possibilities for certain types of attacks involving 1605 socially-engineered messages. 1607 A larger problem occurs if malware on many users' computers obtains 1608 the private keys for those users and transmits them via a covert 1609 channel to a site where they can be shared. The compromised users 1610 would likely not know of the misappropriation until they receive 1611 "bounce" messages from messages they are supposed to have sent. Many 1612 users might not understand the significance of these bounce messages 1613 and would not take action. 1615 One countermeasure is to use a passphrase, although users tend to 1616 choose weak passphrases and often reuse them for different purposes, 1617 possibly allowing an attack against DKIM to be extended into other 1618 domains. Nevertheless, the decoded private key might be briefly 1619 available to compromise by malware when it is entered, or might be 1620 discovered via keystroke logging. The added complexity of entering a 1621 passphrase each time one sends a message would also tend to 1622 discourage the use of a secure passphrase. 1624 A somewhat more effective countermeasure is to send messages through 1625 an outgoing MTA that can authenticate the sender and will sign the 1626 message using its key which is normally authorized for all addresses 1627 in the domain. Such an MTA can also apply controls on the volume of 1628 outgoing mail each user is permitted to originate in order to further 1629 limit the ability of malware to generate bulk email. 1631 9.3 Key Server Denial-of-Service Attacks 1633 Since the key servers are distributed (potentially separate for each 1634 domain), the number of servers that would need to be attacked to 1635 defeat this mechanism on an Internet-wide basis is very large. 1636 Nevertheless, key servers for individual domains could be attacked, 1637 impeding the verification of messages from that domain. This is not 1638 significantly different from the ability of an attacker to deny 1639 service to the mail exchangers for a given domain, although it 1640 affects outgoing, not incoming, mail. 1642 A variation on this attack is that if a very large amount of mail 1643 were to be sent using spoofed addresses from a given domain, the key 1644 servers for that domain could be overwhelmed with requests. However, 1645 given the low overhead of verification compared with handling of the 1646 email message itself, such an attack would be difficult to mount. 1648 9.4 Attacks Against DNS 1650 Since DNS is a required binding for key services, specific attacks 1651 against DNS must be considered. 1653 While the DNS is currently insecure [RFC3833], it is expected that 1654 the security problems should and will be solved by DNSSEC [RFC4033], 1655 and all users of the DNS will reap the benefit of that work. 1657 Secondly, the types of DNS attacks relevant to DKIM are very costly 1658 and are far less rewarding than DNS attacks on other Internet 1659 applications. 1661 To systematically thwart the intent of DKIM, an attacker must conduct 1662 a very costly and very extensive attack on many parts of the DNS over 1663 an extended period. No one knows for sure how attackers will 1664 respond, however the cost/benefit of conducting prolonged DNS attacks 1665 of this nature is expected to be uneconomical. 1667 Finally, DKIM is only intended as a "sufficient" method of proving 1668 authenticity. It is not intended to provide strong cryptographic 1669 proof about authorship or contents. Other technologies such as 1670 OpenPGP [RFC2440] and S/MIME [RFC2633] address those requirements. 1672 A second security issue related to the DNS revolves around the 1673 increased DNS traffic as a consequence of fetching Selector-based 1674 data as well as fetching signing domain policy. Widespread 1675 deployment of DKIM will result in a significant increase in DNS 1676 queries to the claimed signing domain. In the case of forgeries on a 1677 large scale, DNS servers could see a substantial increase in queries. 1679 9.5 Replay Attacks 1681 In this attack, a spammer sends a message to be spammed to an 1682 accomplice, which results in the message being signed by the 1683 originating MTA. The accomplice resends the message, including the 1684 original signature, to a large number of recipients, possibly by 1685 sending the message to many compromised machines that act as MTAs. 1686 The messages, not having been modified by the accomplice, have valid 1687 signatures. 1689 Partial solutions to this problem involve the use of reputation 1690 services to convey the fact that the specific email address is being 1691 used for spam, and that messages from that signer are likely to be 1692 spam. This requires a real-time detection mechanism in order to 1693 react quickly enough. However, such measures might be prone to 1694 abuse, if for example an attacker resent a large number of messages 1695 received from a victim in order to make them appear to be a spammer. 1697 Large verifiers might be able to detect unusually large volumes of 1698 mails with the same signature in a short time period. Smaller 1699 verifiers can get substantially the same volume information via 1700 existing collaborative systems. 1702 9.6 Limits on Revoking Key Authorization 1704 When a large domain detects undesirable behavior on the part of one 1705 of its users, it might wish to revoke the key used to sign that 1706 user's messages in order to disavow responsibility for messages which 1707 have not yet been verified or which are the subject of a replay 1708 attack. However, the ability of the domain to do so can be limited 1709 if the same key, for scalability reasons, is used to sign messages 1710 for many other users. Mechanisms for explicitly revoking key 1711 authorization on a per-address basis have been proposed but require 1712 further study as to their utility and the DNS load they represent. 1714 9.7 Intentionally malformed Key Records 1716 It is possible for an attacker to publish key records in DNS which 1717 are intentionally malformed, with the intent of causing a denial-of- 1718 service attack on a non-robust verifier implementation. The attacker 1719 could then cause a verifier to read the malformed key record by 1720 sending a message to one of its users referencing the malformed 1721 record in a (not necessarily valid) signature. Verifiers MUST 1722 thoroughly verify all key records retrieved from DNS and be robust 1723 against intentionally as well as unintentionally malformed key 1724 records. 1726 9.8 Intentionally Malformed DKIM-Signature header fields 1728 Verifiers MUST be prepared to receive messages with malformed DKIM- 1729 Signature header fields, and thoroughly verify the header field 1730 before depending on any of its contents. 1732 10. References 1734 10.1 References -- Normative 1736 [ID-AUTH-RES] 1737 Kucherawy, M., "Message header field for Indicating Sender 1738 Authentication Status", draft-kucherawy-sender-auth-header 1739 field-02 (work in progress), 2005. 1741 [ID-DK-RR] 1742 "[*] dk rr", draft-dkk-rr-xx (work in progress), 2005. 1744 [ID-DKPOLICY] 1745 "[*] dk policy", draft-allman-dkim-policy (work in 1746 progress), 2005. 1748 [ID-MAIL-ARCH] 1749 Crocker, D., "Internet Mail Architecture", 1750 draft-crocker-email-arch-02 (work in progress), 1751 April 2005. 1753 [OPENSSL] Team, C&D., "", WEB http://www.openssl.org/docs/, 1754 June 2005. 1756 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1757 Mail: Part I: Message Encryption and Authentication 1758 Procedures", RFC 1421, February 1993. 1760 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1761 Extensions (MIME) Part One: Format of Internet Message 1762 Bodies", RFC 2045, November 1996. 1764 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1765 Part Three: Message header field Extensions for Non-ASCII 1766 Text", RFC 2047, November 1996. 1768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1769 Requirement Levels", BCP 14, RFC 2119, March 1997. 1771 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1772 Specifications: ABNF", RFC 2234, November 1997. 1774 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1775 April 2001. 1777 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1778 Standards (PKCS) #1: RSA Cryptography Specifications 1779 Version 2.1", RFC 3447, February 2003. 1781 [RFC3491] Hoffman, P. and M. Blanchet, "[*] Nameprep: A Stringprep 1782 Profile for Internationalized Domain Names (IDN)", 1783 RFC 3491, March 2003. 1785 10.2 References -- Informative 1787 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 1788 "Security Multiparts for MIME: Multipart/Signed and 1789 Multipart/Encrypted", RFC 1847, October 1995. 1791 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1792 "OpenPGP Message Format", RFC 2440, November 1998. 1794 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1795 RFC 2633, June 1999. 1797 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1798 Name System (DNS)", RFC 3833, August 2004. 1800 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1801 Rose, "DNS Security Introduction and Requirements", 1802 RFC 4033, March 2005. 1804 Authors' Addresses 1806 Eric Allman 1807 Sendmail, Inc. 1808 6425 Christie Ave, Suite 400 1809 Emeryville, CA 94608 1810 USA 1812 Phone: +1 510 594 5501 1813 Email: eric+dkim@sendmail.org 1814 URI: 1816 Jon Callas 1817 PGP Corporation 1818 3460 West Bayshore 1819 Palo Alto, CA 94303 1820 USA 1822 Phone: +1 650 319 9016 1823 Email: jon@pgp.com 1825 Mark Delany 1826 Yahoo! Inc 1827 701 First Avenue 1828 Sunnyvale, CA 95087 1829 USA 1831 Phone: +1 408 349 6831 1832 Email: markd+dkim@yahoo-inc.com 1833 URI: 1835 Miles Libbey 1836 Yahoo! Inc 1837 701 First Avenue 1838 Sunnyvale, CA 95087 1839 USA 1841 Email: mlibbeymail-mailsig@yahoo.com 1842 URI: 1844 Jim Fenton 1845 Cisco Systems, Inc. 1846 MS SJ-24/2 1847 170 W. Tasman Drive 1848 San Jose, CA 95134-1706 1849 USA 1851 Phone: +1 408 526 5914 1852 Email: fenton@cisco.com 1853 URI: 1855 Michael Thomas 1856 Cisco Systems, Inc. 1857 MS SJ-9/2 1858 170 W. Tasman Drive 1859 San Jose, CA 95134-1706 1861 Phone: +1 408 525 5386 1862 Email: mat@cisco.com 1864 Appendix A. Appendix A -- Usage Examples (INFORMATIVE) 1866 This section taken directly from IIM without serious editing; it 1867 should be updated or deleted before publication. In no case should 1868 these examples be used as guidance when creating an implementation. 1870 A.1 Simple message transfer 1872 The above sections largely describe the process of signing and 1873 verifying a message which goes directly from one user to another. 1874 One special case is where the recipient has requested forwarding of 1875 the email message from the original address to another, through the 1876 use of a Unix .forward file or equivalent. In this case the message 1877 is typically forwarded without modification, except for the addition 1878 of a Received header field to the message and a change in the 1879 Envelope-to address. In this case, the eventual recipient should be 1880 able to verify the original signature since the signed content has 1881 not changed, and attribute the message correctly. 1883 A.2 Outsourced business functions 1885 Outsourced business functions represent a use case that motivates the 1886 need for user-level keying. Examples of outsourced business 1887 functions are legitimate email marketing providers and corporate 1888 benefits providers. In either case, the outsourced function would 1889 like to be able to send messages using the email domain of the client 1890 company. At the same time, the client may be reluctant to register a 1891 key for the provider that grants the ability to send messages for any 1892 address in the domain. 1894 With user-level keying, the outsourcing company can generate a 1895 keypair and the client company can register the public key for a 1896 specific address such as promotions@example.com. This would enable 1897 the provider to send messages using that specific address and have 1898 them verify properly. The client company retains control over the 1899 email address because it retains the authority to revoke the key 1900 registration at any time. 1902 A.3 PDAs and Similar Devices 1904 PDAs are one example of the use of multiple keys per user. Suppose 1905 that John Doe wanted to be able to send messages using his corporate 1906 email address, jdoe@example.com, and the device did not have the 1907 ability to make a VPN connection to the corporate network. If the 1908 device was equipped with a private key registered for 1909 jdoe@example.com by the administrator of that domain, and appropriate 1910 software to sign messages, John could send IIM messages through the 1911 outgoing network of the PDA service provider. 1913 A.4 Mailing Lists 1915 There is a wide range of behavior in forwarders and mailing lists 1916 (collectively called "forwarders" below), ranging from those which 1917 make no modification to the message itself (other than to add a 1918 Received header field and change the envelope information) to those 1919 which may add header fields, change the Subject header field, add 1920 content to the body (typically at the end), or reformat the body in 1921 some manner. 1923 Forwarders which do not modify the body or signed header fields of a 1924 message with a valid signature MAY re-sign the message as described 1925 below. 1927 Forwarders which make any modification to a message that could result 1928 in its signature becoming invalid SHOULD sign or re-sign using an 1929 appropriate identification (e.g., mailing-list-name@example.net). 1930 Since in so doing the (re-)signer is taking responsibility for the 1931 content of the message, modifying forwarders MAY elect to forward or 1932 re-sign only for messages which were received with valid signatures 1933 or other indications that the messages being signed are not spoofed. 1935 Forwarders which wish to re-sign a message MUST apply a Sender header 1936 field to the message to identify the address being used to sign the 1937 message and MUST remove any preexisting Sender header field as 1938 required by RFC 2822 [5]. The forwarder applies a new IIM-Sig header 1939 field with the signature, public key, and related information of the 1940 forwarder. Previously existing IIM-Sig header fields SHOULD NOT be 1941 removed. 1943 A.5 Affinity Addresses 1945 "Affinity addresses" are email addresses that users employ to have an 1946 email address that is independent of any changes in email service 1947 provider they may choose to make. They are typically associated with 1948 college alumni associations, professional organizations, and 1949 recreational organizations with which they expect to have a long-term 1950 relationship. These domains usually provide forwarding of incoming 1951 email, but (currently) usually depend on the user to send outgoing 1952 messages through their own service provider's MTA. They usually have 1953 an associated Web application which authenticates the user and allows 1954 the forwarding address to be changed. 1956 With DKIM, affinity domains could use the Web application to allow 1957 users to register their own public keys to be used to sign messages 1958 on behalf of their affinity address. This is another application 1959 that takes advantage of user-level keying, and domains used for 1960 affinity addresses would typically have a very large number of user- 1961 level keys. Alternatively, the affinity domain could decide to start 1962 handling outgoing mail, and could operate a mail submission agent 1963 that authenticates users before accepting and signing messages for 1964 them. This is of course dependent on the user's service provider not 1965 blocking the relevant TCP ports used for mail submission. 1967 A.6 Third-party Message Transmission 1969 Third-party message transmission refers to the authorized sending of 1970 mail by an Internet application on behalf of a user. For example, a 1971 website providing news may allow the reader to forward a copy of the 1972 message to a friend; this is typically done using the reader's email 1973 address. This is sometimes referred to as the "Evite problem", named 1974 after the website of the same name that allows a user to send 1975 invitations to friends. 1977 One way this can be handled is to continue to put the reader's email 1978 address in the From field of the message, but put an address owned by 1979 the site into the Sender field, and sign the message on behalf of the 1980 Sender. A verifying MTA SHOULD accept this and rewrite the From 1981 field to indicate the address that was verified, i.e., From: John 1982 Doe via news@news-site.com . 1984 Appendix B. Appendix B -- Example of Use (INFORMATIVE) 1986 This section taken directly from DK without serious editing; it 1987 should be updated or deleted before publication. In no case should 1988 these examples be used as guidance when creating an implementation. 1990 This section shows the complete flow of an email from submission to 1991 final delivery, demonstrating how the various components fit 1992 together. 1994 B.1 The user composes an email 1995 From: "Joe SixPack" 1996 To: "Suzie Q" 1997 Subject: Is dinner ready? 1998 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 1999 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2001 Hi. 2003 We lost the game. Are you hungry yet? 2005 Joe. 2007 B.2 The email is signed 2009 This email is signed by the example.com outbound email server and now 2010 looks like this: 2012 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2013 c=simple; q=dns; i=joe@football.example.com; 2014 h=Received : From : To : Subject : Date : Message-ID; 2015 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2016 VoG4ZHRNiYzR; 2017 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2018 by submitserver.example.com with SUBMISSION; 2019 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2020 From: "Joe SixPack" 2021 To: "Suzie Q" 2022 Subject: Is dinner ready? 2023 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2024 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2026 Hi. 2028 We lost the game. Are you hungry yet? 2030 Joe. 2032 The signing email server requires access to the private-key 2033 associated with the "brisbane" selector to generate this signature. 2034 Distribution and management of private-keys is outside the scope of 2035 this document. 2037 B.3 The email signature is verified 2039 The signature is normally verified by an inbound SMTP server or 2040 possibly the final delivery agent. However, intervening MTAs can 2041 also perform this verification if they choose to do so. The 2042 verification process uses the domain "example.com" extracted from the 2043 "d=" header field and the selector "brisbane" from the "s=" tag in 2044 the "DKIM-Signature" header field to form the DNS DKIM query for: 2046 brisbane._dkim.example.com 2048 Signature verification starts with the physically last "Received" 2049 header field, the "From" header field, and so forth, in the order 2050 listed in the "h=" tag. Verification follows with a single CRLF 2051 followed by the body (starting with "Hi."). The email is canonically 2052 prepared for verifying with the "simple" method. The result of the 2053 query and subsequent verification of the signature is stored in the 2054 "Authentication-Results" header field line. After successful 2055 verification, the email looks like this: 2057 Authentication-Status: XXX 2058 Received: from mout23.football.example.com (192.168.1.1) 2059 by shopping.example.net with SMTP; 2060 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2061 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.net; 2062 c=simple; q=dns; i=joe@football.example.com; 2063 h=Received : From : To : Subject : Date : Message-ID; 2064 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2065 VoG4ZHRNiYzR 2066 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2067 by submitserver.example.com with SUBMISSION; 2068 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2069 From: "Joe SixPack" 2070 To: "Suzie Q" 2071 Subject: Is dinner ready? 2072 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2073 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2075 Hi. 2077 We lost the game. Are you hungry yet? 2079 Joe. 2081 Appendix C. Appendix C -- Creating a public key (INFORMATIVE) 2083 Drop this section? It seems like this could clarify things for some 2084 people. 2086 The default signature is an RSA signed SHA1 digest of the complete 2087 email. For ease of explanation, the openssl command is used to 2088 describe the mechanism by which keys and signatures are managed. One 2089 way to generate a 768 bit private-key suitable for DKIM, is to use 2090 openssl like this: 2092 $ openssl genrsa -out rsa.private 768 2094 This results in the file rsa.private containing the key information 2095 similar to this: 2097 -----BEGIN RSA PRIVATE KEY----- 2098 MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 2099 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo 2100 AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH 2101 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn 2102 Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 2103 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew 2104 ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs 2105 FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb 2106 weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 2107 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= 2108 -----END RSA PRIVATE KEY----- 2110 Once a private-key has been generated, the openssl command can be 2111 used to sign an appropriately prepared email, like this: 2113 $ openssl dgst -sign rsa.private -sha1 . 2162 Intellectual Property Statement 2164 The IETF takes no position regarding the validity or scope of any 2165 Intellectual Property Rights or other rights that might be claimed to 2166 pertain to the implementation or use of the technology described in 2167 this document or the extent to which any license under such rights 2168 might or might not be available; nor does it represent that it has 2169 made any independent effort to identify any such rights. Information 2170 on the procedures with respect to rights in RFC documents can be 2171 found in BCP 78 and BCP 79. 2173 Copies of IPR disclosures made to the IETF Secretariat and any 2174 assurances of licenses to be made available, or the result of an 2175 attempt made to obtain a general license or permission for the use of 2176 such proprietary rights by implementers or users of this 2177 specification can be obtained from the IETF on-line IPR repository at 2178 http://www.ietf.org/ipr. 2180 The IETF invites any interested party to bring to its attention any 2181 copyrights, patents or patent applications, or other proprietary 2182 rights that may cover technology that may be required to implement 2183 this standard. Please address the information to the IETF at 2184 ietf-ipr@ietf.org. 2186 The IETF has been notified of intellectual property rights claimed in 2187 regard to some or all of the specification contained in this 2188 document. For more information consult the online list of claimed 2189 rights. 2191 Disclaimer of Validity 2193 This document and the information contained herein are provided on an 2194 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2195 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2196 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2197 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2198 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2199 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2201 Copyright Statement 2203 Copyright (C) The Internet Society (2005). This document is subject 2204 to the rights, licenses and restrictions contained in BCP 78, and 2205 except as set forth therein, the authors retain all their rights. 2207 Acknowledgment 2209 Funding for the RFC Editor function is currently provided by the 2210 Internet Society.