idnits 2.17.1 draft-ietf-dkim-base-01.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 2567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2552. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character 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 1123 has weird spacing: '... email elec...' == Line 1288 has weird spacing: '...ination is a ...' == Line 1647 has weird spacing: '...ined by the "...' -- 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 (April 13, 2006) is 6588 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: 'XREF-TBD' is mentioned on line 855, but not defined == Missing Reference: 'MIME' is mentioned on line 2441, but not defined == Unused Reference: 'ID-SHA' is defined on line 2040, but no explicit reference was found in the text == Unused Reference: 'OPENSSL' is defined on line 2044, but no explicit reference was found in the text == Unused Reference: 'RFC1421' is defined on line 2049, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 2074, but no explicit reference was found in the text -- No information found for draft-dkim-dkk-rr-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-DKIM-RR' ** Downref: Normative reference to an Informational draft: draft-eastlake-sha2 (ref. 'ID-SHA') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPENSSL' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** 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 normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-02 -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM E. Allman 3 Internet-Draft Sendmail, Inc. 4 Expires: October 15, 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 April 13, 2006 14 DomainKeys Identified Mail Signatures (DKIM) 15 draft-ietf-dkim-base-01 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 October 15, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 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 Transfer Agents (MTAs) or Mail 52 User Agents (MUAs). The ultimate goal of this framework is to permit 53 a signing domain to assert responsibility for a message, thus proving 54 and protecting message sender identity and the integrity of the 55 messages they convey while retaining the functionality of Internet 56 email as it is known today. Proof and protection of email identity, 57 including repudiation and non-repudiation, may assist in the global 58 control of "spam" and "phishing". 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.2 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 71 1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 72 1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 73 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 74 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 77 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 78 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 79 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 80 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 82 3.3 Signing and Verification Algorithms . . . . . . . . . . . 11 83 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 12 84 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 16 85 3.6 Key Management and Representation . . . . . . . . . . . . 23 86 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 27 87 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 29 88 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 30 89 5.1 Determine if the Email Should be Signed and by Whom . . . 30 90 5.2 Select a private-key and corresponding selector 91 information . . . . . . . . . . . . . . . . . . . . . . . 30 92 5.3 Normalize the Message to Prevent Transport Conversions . . 31 93 5.4 Determine the header fields to Sign . . . . . . . . . . . 31 94 5.5 Compute the Message Hash and Signature . . . . . . . . . . 33 95 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 34 96 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 35 97 6.1 Extract the Signature from the Message . . . . . . . . . . 35 98 6.2 Get the Public Key . . . . . . . . . . . . . . . . . . . . 36 99 6.3 Compute the Verification . . . . . . . . . . . . . . . . . 37 100 6.4 Communicate Verification Results . . . . . . . . . . . . . 39 101 6.5 Interpret Results/Apply Local Policy . . . . . . . . . . . 39 102 6.6 MUA Considerations . . . . . . . . . . . . . . . . . . . . 40 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 105 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 42 106 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 42 107 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 43 108 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 43 109 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 44 110 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 44 111 8.7 Intentionally malformed Key Records . . . . . . . . . . . 45 112 8.8 Intentionally Malformed DKIM-Signature header fields . . . 45 113 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 45 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 116 9.1 Normative References . . . . . . . . . . . . . . . . . . . 45 117 9.2 Informative References . . . . . . . . . . . . . . . . . . 46 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47 119 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . . 48 120 A.1 The user composes an email . . . . . . . . . . . . . . . . 49 121 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 49 122 A.3 The email signature is verified . . . . . . . . . . . . . 50 123 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . . 51 124 B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 51 125 B.2 Outsourced Business Functions . . . . . . . . . . . . . . 51 126 B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 51 127 B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 52 128 B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 52 129 B.6 Third-party Message Transmission . . . . . . . . . . . . . 53 130 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . . 53 131 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 132 E. Edit History . . . . . . . . . . . . . . . . . . . . . . . . . 55 133 E.1 Changes since -ietf-00 version . . . . . . . . . . . . . . 55 134 E.2 Changes since -allman-01 version . . . . . . . . . . . . . 56 135 E.3 Changes since -allman-00 version . . . . . . . . . . . . . 56 136 Intellectual Property and Copyright Statements . . . . . . . . 57 138 1. Introduction 140 [[Note: text in double square brackets (such as this text) will be 141 deleted before publication.]] 143 1.1 Overview 145 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 146 messages can be cryptographically signed, permitting a signing domain 147 to claim responsibility for the introduction of a message into the 148 mail stream. Message recipients can verify the signature by querying 149 the signer's domain directly to retrieve the appropriate public key, 150 and thereby confirm that the message was attested to by a party in 151 possession of the private key for the signing domain. 153 The approach taken by DKIM differs from previous approaches to 154 message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: 156 o the message signature is written to the message header fields so 157 that neither human recipients nor existing MUA (Mail User Agent) 158 software are confused by signature-related content appearing in 159 the message body, 161 o there is no dependency on public and private key pairs being 162 issued by well-known, trusted certificate authorities, 164 o there is no dependency on the deployment of any new Internet 165 protocols or services for public key distribution or revocation, 167 o it makes no attempt to include encryption as part of the 168 mechanism. 170 DKIM: 172 o is compatible with the existing email infrastructure and 173 transparent to the fullest extent possible 175 o requires minimal new infrastructure 177 o can be implemented independently of clients in order to reduce 178 deployment time 180 o does not require the use of a trusted third party (such as a 181 certificate authority or other entity) which might impose 182 significant costs or introduce delays to deployment 184 o can be deployed incrementally 185 o allows delegation of signing to third parties. 187 A "selector" mechanism allows multiple keys per domain, including 188 delegation of the right to authenticate a portion of the namespace to 189 a trusted third party. 191 1.2 Signing Identity 193 DKIM separates the question of the identity of the signer of the 194 message from the purported author of the message. In particular, a 195 signature includes the identity of the signer. Verifiers can use the 196 signing information to decide how they want to process the message. 198 INFORMATIVE RATIONALE: The signing address associated with a DKIM 199 signature is not required to match a particular header field 200 because of the broad methods of interpretation by recipient mail 201 systems, including MUAs. 203 1.3 Scalability 205 The email identification problem is characterized by extreme 206 scalability requirements. There are currently over 70 million 207 domains and a much larger number of individual addresses. It is 208 important to preserve the positive aspects of the current email 209 infrastructure, such as the ability for anyone to communicate with 210 anyone else without introduction. 212 1.4 Simple Key Management 214 DKIM differs from traditional hierarchical public-key systems in that 215 no key signing infrastructure is required; the verifier requests the 216 public key from the claimed signer directly. 218 The DNS is proposed as the initial mechanism for publishing public 219 keys. DKIM is designed to be extensible to other key fetching 220 services as they become available. 222 2. Terminology and Definitions 224 This section defines terms used in the rest of the document. Syntax 225 descriptions use the form described in Augmented BNF for Syntax 226 Specifications [RFC4234]. 228 2.1 Signers 230 Elements in the mail system that sign messages are referred to as 231 signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission 232 Agents), MTAs (Mail Transfer Agents), or other agents such as mailing 233 list exploders. In general any signer will be involved in the 234 injection of a message into the message system in some way. The key 235 issue is that a message must be signed before it leaves the 236 administrative domain of the signer. 238 2.2 Verifiers 240 Elements in the mail system that verify signatures are referred to as 241 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 242 In most cases it is expected that verifiers will be close to an end 243 user (reader) of the message or some consuming agent such as a 244 mailing list exploder. 246 2.3 White Space 248 There are three forms of white space: 250 o WSP represents simple white space, i.e., a space or a tab 251 character, and is inherited from[RFC2822]. 253 o SWSP is streaming white space; it adds the CR and LF characters. 255 o FWS, also from [RFC2822], is folding white space. It allows 256 multiple lines separated by CRLF followed by at least one white 257 space, to be joined. 259 The formal ABNF for SWSP is: 261 SWSP = CR / LF / WSP ; streaming white space 263 2.4 Common ABNF Tokens 265 The following ABNF tokens are used elsewhere in this document. 267 hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] 268 base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) 270 2.5 Imported ABNF Tokens 272 The following tokens are imported from other RFCs as noted. Those 273 RFCs should be considered definitive. However, all tokens having 274 names beginning with "obs-" should be excluded from this import, as 275 they have been obsoleted and are expected to go away in future 276 editions of those RFCs. 278 The following tokens are imported from [RFC2821]: 280 o Local-part (implementation warning: this permits quoted strings) 282 o Domain (implementation warning: this permits address-literals) 284 o sub-domain 286 The following definitions are imported from [RFC2822]: 288 o WSP (space or tab) 290 o FWS (folding white space) 292 o field-name (name of a header field) 294 o dot-atom (in the local-part of an email address) 296 The following tokens are imported from [RFC2045]: 298 o qp-section (a single line of quoted-printable-encoded text) 300 Other tokens not defined herein are imported from [RFC4234]. These 301 are intuitive primitives such as SP, ALPHA, CRLF, etc. 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 (Signer 308 Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This 309 section must be read in the context of those sections. 311 3.1 Selectors 313 To support multiple concurrent public keys per signing domain, the 314 key namespace is subdivided using "selectors". For example, 315 selectors might indicate the names of office locations (e.g., 316 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 317 (e.g., "january2005", "february2005", etc.), or even the individual 318 user. 320 INFORMATIVE IMPLEMENTERS' NOTE: reusing a selector with a new key 321 (for example, changing the key associated with a user's name) 322 makes it impossible to tell the difference between a message that 323 didn't verify because the key is no longer valid versus a message 324 that is actually forged. Signers should not change the key 325 associated with a selector. When creating a new key, signers 326 should associate it with a new selector. 328 Selectors are needed to support some important use cases. For 329 example: 331 o Domains which want to delegate signing capability for a specific 332 address for a given duration to a partner, such as an advertising 333 provider or other outsourced function. 335 o Domains which want to allow frequent travelers to send messages 336 locally without the need to connect with a particular MSA. 338 o "Affinity" domains (e.g., college alumni associations) which 339 provide forwarding of incoming mail but which do not operate a 340 mail submission agent for outgoing mail. 342 Periods are allowed in selectors and are component separators. If 343 keys are stored in DNS, the period defines sub-domain boundaries. 344 Sub-selectors might be used to combine dates with locations; for 345 example, "march2005.reykjavik". This can be used to allow delegation 346 of a portion of the selector name-space. 348 ABNF: 349 selector = sub-domain *( "." sub-domain ) 351 The number of public keys and corresponding selectors for each domain 352 are determined by the domain owner. Many domain owners will be 353 satisfied with just one selector whereas administratively distributed 354 organizations may choose to manage disparate selectors and key pairs 355 in different regions or on different email servers. 357 Beyond administrative convenience, selectors make it possible to 358 seamlessly replace public keys on a routine basis. If a domain 359 wishes to change from using a public key associated with selector 360 "january2005" to a public key associated with selector 361 "february2005", it merely makes sure that both public keys are 362 advertised in the public-key repository concurrently for the 363 transition period during which email may be in transit prior to 364 verification. At the start of the transition period, the outbound 365 email servers are configured to sign with the "february2005" private- 366 key. At the end of the transition period, the "january2005" public 367 key is removed from the public-key repository. 369 While some domains may wish to make selector values well known, 370 others will want to take care not to allocate selector names in a way 371 that allows harvesting of data by outside parties. E.g., if per-user 372 keys are issued, the domain owner will need to make the decision as 373 to whether to make this selector associated directly with the user 374 name, or make it some unassociated random value, such as a 375 fingerprint of the public key. 377 3.2 Tag=Value Lists 379 DKIM uses a simple "tag=value" syntax in several contexts, including 380 in messages, domain signature records, and policy records. 382 Values are a series of strings containing either base64 text, plain 383 text, or quoted printable text, as defined in [RFC2045], section 6.7. 384 The name of the tag will determine the encoding of each value; 385 however, no encoding may include the semicolon (";") character, since 386 that separates tag-specs. 388 Formally, the syntax rules are: 389 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 390 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 391 tag-name = ALPHA 0*ALNUMPUNC 392 tag-value = 0*VALCHAR ; SWSP prohibited at beginning and end 393 VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 394 ; HTAB and SP to TILDE except SEMICOLON 395 ALNUMPUNC = ALPHA / DIGIT / "_" 397 Note that WSP is allowed anywhere around tags; in particular, WSP 398 between the tag-name and the "=", and any WSP before the terminating 399 ";" is not part of the value. 401 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 402 processed as case sensitive unless the specific tag description of 403 semantics specifies case insensitivity. 405 Tags with duplicate names MUST NOT be specified within a single tag- 406 list. 408 Whitespace within a value MUST be retained unless explicitly excluded 409 by the specific tag description. 411 Tag=value pairs that represent the default value MAY be included to 412 aid legibility. 414 Unrecognized tags MUST be ignored. 416 Tags that have an empty value are not the same as omitted tags. An 417 omitted tag is treated as having the default value; a tag with an 418 empty value explicitly designates the empty string as the value. For 419 example, "g=" does not mean "g=*", even though "g=*" is the default 420 for that tag. 422 3.3 Signing and Verification Algorithms 424 DKIM supports multiple key signing/verification algorithms. Two 425 algorithms are defined by this specification at this time: rsa-sha1, 426 and rsa-sha256. The rsa-sha256 algorithm is the default if no 427 algorithm is specified. Verifiers MUST implement both rsa-sha1 and 428 rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256. 430 3.3.1 The rsa-sha1 Signing Algorithm 432 The rsa-sha1 Signing Algorithm computes a message hash as described 433 in Section 3.7 below using SHA-1 as the hash-alg. That hash is then 434 encrypted by the signer using the RSA algorithm (defined in PKCS#1 435 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 436 The hash MUST NOT be truncated or converted into any form other than 437 the native binary form before being signed. 439 3.3.2 The rsa-sha256 Signing Algorithm 441 The rsa-sha256 Signing Algorithm computes a message hash as described 442 in Section 3.7 below using SHA-256 as the hash-alg. That hash is 443 then encrypted by the signer using the RSA algorithm (actually PKCS#1 444 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 445 The hash MUST NOT be truncated or converted into any form other than 446 the native binary form before being signed. 448 3.3.3 Other algorithms 450 Other algorithms MAY be defined in the future. Verifiers MUST ignore 451 any signatures using algorithms that they do not understand. 453 3.3.4 Key sizes 455 Selecting appropriate key sizes is a trade-off between cost, 456 performance and risk. Since short RSA keys more easily succumb to 457 off-line attacks, signers MUST use RSA keys of at least 1024 bits for 458 long-lived keys. Verifiers MUST be able to validate signatures with 459 keys ranging from 512 bits to 2048 bits, and they MAY be able to 460 validate signatures with larger keys. Security policies may use the 461 length of the signing key as one metric for determining whether a 462 signature is acceptable. 464 Factors that should influence the key size choice include: 466 o The practical constraint that large keys may not fit within a 512 467 byte DNS UDP response packet 469 o The security constraint that keys smaller than 1024 bits are 470 subject to off-line attacks 472 o Larger keys impose higher CPU costs to verify and sign email 474 o Keys can be replaced on a regular basis, thus their lifetime can 475 be relatively short 477 o The security goals of this specification are modest compared to 478 typical goals of public-key systems 480 See RFC3766 [RFC3766] for further discussion of selecting key sizes. 482 3.4 Canonicalization 484 Empirical evidence demonstrates that some mail servers and relay 485 systems modify email in transit, potentially invalidating a 486 signature. There are two competing perspectives on such 487 modifications. For most signers, mild modification of email is 488 immaterial to the authentication status of the email. For such 489 signers a canonicalization algorithm that survives modest in-transit 490 modification is preferred. 492 Other signers demand that any modification of the email, however 493 minor, result in an authentication failure. These signers prefer a 494 canonicalization algorithm that does not tolerate in-transit 495 modification of the signed email. 497 Some signers may be willing to accept modifications to header fields 498 that are within the bounds of email standards such as [RFC2822], but 499 are unwilling to accept any modification to the body of messages. 501 To satisfy all requirements, two canonicalization algorithms are 502 defined for each of the header and the body: a "simple" algorithm 503 that tolerates almost no modification and a "relaxed" algorithm that 504 tolerates common modifications such as white-space replacement and 505 header field line re-wrapping. A signer MAY specify either algorithm 506 for header or body when signing an email. If no canonicalization 507 algorithm is specified by the signer, the "simple" algorithm defaults 508 for both header and body. Verifiers MUST implement both 509 canonicalization algorithms. Further canonicalization algorithms MAY 510 be defined in the future; verifiers MUST ignore any signatures that 511 use unrecognized canonicalization algorithms. 513 In all cases, the header fields of the message are presented to the 514 signing algorithm first in the order indicated by the signature 515 header field and canonicalized using the indicated algorithm. Only 516 header fields listed as signed in the signature header field are 517 included. The CRLF separating the header field from the body is then 518 presented, followed by the canonicalized body. Note that the header 519 and body may use different canonicalization algorithms. 521 Canonicalization simply prepares the email for presentation to the 522 signing or verification algorithm. It MUST NOT change the 523 transmitted data in any way. Canonicalization of header fields and 524 body are described below. 526 NOTE: This section assumes that the message is already in "network 527 normal" format (e.g., text is ASCII encoded, lines are separated with 528 CRLF characters, etc.). See also Section 5.3 for information about 529 normalizing the message. 531 3.4.1 The "simple" Header Field Canonicalization Algorithm 533 The "simple" header canonicalization algorithm does not change header 534 fields in any way. Header fields MUST be presented to the signing or 535 verification algorithm exactly as they are in the message being 536 signed or verified. In particular, header field names MUST NOT be 537 case folded and white space MUST NOT be changed. 539 3.4.2 The "relaxed" Header Field Canonicalization Algorithm 541 The "relaxed" header canonicalization algorithm MUST apply the 542 following steps in order: 544 o Convert all header field names (not the header field values) to 545 lower case. For example, convert "SUBJect: AbC" to "subject: 546 AbC". 548 o Unfold all header field continuation lines as described in 549 [RFC2822]; in particular, lines with terminators embedded in 550 continued header field values (that is, CRLF sequences followed by 551 WSP) MUST be interpreted without the CRLF. Implementations MUST 552 NOT remove the CRLF at the end of the header field value. 554 o Convert all sequences of one or more WSP characters to a single SP 555 character. WSP characters here include those before and after a 556 line folding boundary. 558 o Delete all WSP characters at the end of each unfolded header field 559 value. 561 o Delete any WSP characters remaining before and after the colon 562 separating the header field name from the header field value. The 563 colon separator MUST be retained. 565 [NON-NORMATIVE DOCUMENTATION NOTE: The only difference between 566 "relaxed" header field canonicalization and "nowsp" listed in the 567 previous version of this draft is that nowsp reduces all strings 568 of streaming white space to zero characters while "relaxed" 569 reduces strings of white space to one space.] 571 3.4.3 The "simple" Body Canonicalization Algorithm 573 The "simple" body canonicalization algorithm ignores all empty lines 574 at the end of the message body. An empty line is a line of zero 575 length after removal of the line terminator. It makes no other 576 changes to the message body. In more formal terms, the "simple" body 577 canonicalization algorithm reduces "CRLF 0*CRLF" at the end of the 578 body to a single "CRLF". 580 3.4.4 The "relaxed" Body Canonicalization Algorithm 582 [[This section may be deleted; see discussion below.]] The "relaxed" 583 body canonicalization algorithm: 585 o Ignores all white space at the end of lines. Implementations MUST 586 NOT remove the CRLF at the end of the line. 588 o Reduces all sequences of WSP within a line to a single SP 589 character. 591 o Ignores all empty lines at the end of the message body. "Empty 592 line" is defined in Section 3.4.3. 594 [[NON-NORMATIVE DISCUSSION: The authors are undecided whether to 595 leave the "relaxed" body canonicalization algorithm in to the 596 specification or delete it entirely. We believe that for the vast 597 majority of cases, the "simple" body canonicalization algorithm 598 should be sufficient. We simply do not have enough data to know 599 whether to retain the "relaxed" body canonicalization algorithm or 600 not.]] 602 3.4.5 Body Length Limits 604 A body length count MAY be specified to limit the signature 605 calculation to an initial prefix of the body text. If the body 606 length count is not specified then the entire message body is signed 607 and verified. 609 INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be 610 useful in increasing signature robustness when sending to a 611 mailing list that both appends to content sent to it and does not 612 sign its messages. However, using such limits enables an attack 613 in which a sender with malicious intent modifies a message to 614 include content that solely benefits the attacker. It is possible 615 for the appended content to completely replace the original 616 content in the end recipient's eyes and to defeat duplicate 617 message detection algorithms. To avoid this attack, signers 618 should be wary of using this tag, and verifiers might wish to 619 ignore the tag or remove text that appears after the specified 620 content length, perhaps based on other criteria. 622 The body length count allows the signer of a message to permit data 623 to be appended to the end of the body of a signed message. The body 624 length count is made following the canonicalization algorithm; for 625 example, any white space ignored by a canonicalization algorithm is 626 not included as part of the body length count. 628 INFORMATIVE RATIONALE: This capability is provided because it is 629 very common for mailing lists to add trailers to messages (e.g., 630 instructions how to get off the list). Until those messages are 631 also signed, the body length count is a useful tool for the 632 verifier since it may as a matter of policy accept messages having 633 valid signatures with extraneous data. 635 Signers of MIME messages that include a body length count SHOULD be 636 sure that the length extends to the closing MIME boundary string. 638 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 639 the only acceptable modifications are to add to the MIME postlude 640 would use a body length count encompassing the entire final MIME 641 boundary string, including the final "--CRLF". A signer wishing 642 to allow additional MIME parts but not modification of existing 643 parts would use a body length count extending through the final 644 MIME boundary string, omitting the final "--CRLF". 646 A body length count of zero means that the body is completely 647 unsigned. 649 Note that verifiers MAY choose to reject or truncate messages that 650 have body content beyond that specified by the body length count. 652 Signers wishing to ensure that no modification of any sort can occur 653 should specify the "simple" algorithm and omit the body length count. 655 3.4.6 Example 657 (In the following examples, actual white space is used only for 658 clarity. The actual input and output text is designated using 659 bracketed descriptors: "" for a space character, "" for a 660 tab character, and "" for a carriage-return/line-feed sequence. 661 For example, "X Y" and "XY" represent the same three 662 characters.) 664 A message reading: 665 A: X 666 B : Y 667 Z 668 669 C 670 D E 671 672 674 when canonicalized using relaxed canonicalization for both header and 675 body results in: 676 a:X 677 b:Y Z 678 679 C 680 D E 682 The same message canonicalized using simple canonicalization for both 683 header and body results in: 684 A: X 685 B : Y 686 Z 687 688 C 689 D E 691 When processed using relaxed header canonicalization and simple body 692 canonicalization, the canonicalized version reads: 693 a:X 694 b:Y Z 695 696 C 697 D E 699 3.5 The DKIM-Signature header field 701 The signature of the email is stored in the "DKIM-Signature:" header 702 field. This header field contains all of the signaturee and key- 703 fetching data. The DKIM-Signature value is a tag-list as described 704 in Section 3.2. 706 The "DKIM-Signature:" header field SHOULD be treated as though it 707 were a trace header field as defined in section 3.6 of [RFC2822], and 708 hence SHOULD NOT be reordered and SHOULD be prepended to the message. 709 In particular, the "DKIM-Signature" header field SHOULD precede the 710 original email header fields presented to the canonicalization and 711 signature algorithms. 713 The "DKIM-Signature:" header field is always included in the 714 signature calculation, after the body of the message; however, when 715 calculating or verifying the signature, the value of the b= tag 716 (signature value) MUST be treated as though it were the null string. 717 Unknown tags MUST be signed and verified but MUST be otherwise 718 ignored by verifiers. 720 The encodings for each field type are listed below. Tags described 721 as quoted-printable are as described in section 6.7 of MIME Part One 722 [RFC2045], with the additional conversion of semicolon characters to 723 "=3B". 725 Tags on the DKIM-Signature header field along with their type and 726 requirement status are shown below. Defined tags are described 727 below. Unrecognized tags MUST be ignored. 729 v= Version (MUST NOT be included). This tag is reserved for future 730 use to indicate a possible new, incompatible version of the 731 specification. It MUST NOT be included in the DKIM-Signature 732 header field. 734 ABNF: 736 sig-v-tag = 738 a= The algorithm used to generate the signature (plain-text; 739 REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; 740 signers SHOULD sign using "rsa-sha256". See Section 3.3 for a 741 description of algorithms. 743 ABNF: 745 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 746 sig-a-tag-alg = "rsa-sha1" / "rsa-sha256" / x-sig-a-tag-alg 747 x-sig-a-tag-alg = hyphenated-word ; for later extension 748 b= The signature data (base64; REQUIRED). Whitespace is ignored in 749 this value and MUST be ignored when re-assembling the original 750 signature. In particular, the signing process can safely insert 751 FWS in this value in arbitrary places to conform to line-length 752 limits. See Signer Actions (Section 5) for how the signature is 753 computed. 755 ABNF: 757 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 758 sig-b-tagg-data = base64string 760 bh= The hash of the body part of the message (base64; REQUIRED). 761 Whitespace is ignored in this value and MUST be ignored when re- 762 assembling the original signature. In particular, the signing 763 process can safely insert FWS in this value in arbitrary places 764 to conform to line-length limits. See Section 3.7 for how the 765 body hash is computed. 767 c= Message canonicalization (plain-text; OPTIONAL, default is 768 "simple/simple"). This tag informs the verifier of the type of 769 canonicalization used to prepare the message for signing. It 770 consists of two names separated by a "slash" (%d47) character, 771 corresponding to the header and body canonicalization algorithms 772 respectively. These algorithms are described in Section 3.4. If 773 only one algorithm is named, that algorithm is used for the 774 header and "simple" is used for the body. For example, 775 "c=relaxed" is treated the same as "c=relaxed/simple". 777 ABNF: 779 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 780 ["/" sig-c-tag-alg] 781 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 782 x-sig-c-tag-alg = hyphenated-word ; for later extension 784 d= The domain of the signing entity (plain-text; REQUIRED). This 785 is the domain that will be queried for the public key. This 786 domain MUST be the same as or a parent domain of the "i=" tag 787 (the signing identity, as described below). When presented with 788 a signature that does not meet this requirement, verifiers MUST 789 either ignore the signature or reject the message. 791 ABNF: 793 sig-d-tag = %x64 [FWS] "=" [FWS] Domain 795 h= Signed header fields (plain-text, but see description; 796 REQUIRED). A colon-separated list of header field names that 797 identify the header fields presented to the signing algorithm. 798 The field MUST contain the complete list of header fields in the 799 order presented to the signing algorithm. The field MAY contain 800 names of header fields that do not exist when signed; nonexistent 801 header fields do not contribute to the signature computation 802 (that is, they are treated as the null input, including the 803 header field name, the separating colon, the header field value, 804 and any CRLF terminator). The field MUST NOT include the DKIM- 805 Signature header field that is being created or verified. 806 Folding white space (FWS) MAY be included on either side of the 807 colon separator. Header ffield names MUST be compared against 808 actual header field names in a case insensitive manner. This 809 list MUST NOT be empty. See Section 5.4 for a discussion of 810 choosing header fields to sign. 812 ABNF: 814 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 815 0*( *FWS ":" *FWS hdr-name ) 816 hdr-name = field-name 818 INFORMATIVE EXPLANATION: By "signing" header fields that do 819 not actually exist, a signer can prevent insertion of those 820 header fields before verification. However, since a sender 821 cannot possibly know what header fields might be created in 822 the future, and that some MUAs might present header fields 823 that are embedded inside a message (e.g., as a message/rfc822 824 content type), the security of this solution is not total. 826 INFORMATIVE EXPLANATION: The exclusion of the header field 827 name and colon as well as the header field value for non- 828 existent header fields prevents an attacker from inserting an 829 actual header field with a null value. 831 i= Identity of the user or agent (e.g., a mailing list manager) on 832 behalf of which this message is signed (quoted-printable; 833 OPTIONAL, default is an empty local-part followed by an "@" 834 followed by the domain from the "d=" tag). The syntax is a 835 standard email address where the local-part MAY be omitted. The 836 domain part of the address MUST be the same as or a subdomain of 837 the value of the "d=" tag. 839 ABNF: 841 sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" Domain 843 INFORMATIVE NOTE: The local-part of the "i=" tag is optional 844 because in some cases a signer may not be able to establish a 845 verified individual identity. In such cases, the signer may 846 wish to assert that although it is willing to go as far as 847 signing for the domain, it is unable or unwilling to commit 848 to an individual user name within their domain. It can do so 849 by including the domain part but not the local-part of the 850 identity. 852 INFORMATIVE DISCUSSION: This document does not require the 853 value of the "i=" tag to match the identity in any message 854 header field fields. This is considered to be a verifier 855 policy issue, described in another document [XREF-TBD]. 856 Constraints between the value of the "i=" tag and other 857 identities in other header fields seek to apply basic 858 aauthentication into the semantics of trust associated with a 859 role such as content author. Trust is a broad and complex 860 topic and trust mechanisms are subject to highly creative 861 attacks. The real-world efficacy of any but the most basic 862 bindings between the "i=" value and other identities is not 863 well established, nor is its vulnerability to subversion by 864 an attacker. Hence reliance on the use of these options 865 should be strictly limited. In particular it is not at all 866 clear to what extent a typical end-user recipient can rely on 867 any assurances that might be made by successful use of the 868 "i=" options. 870 l= Body count (plain-text decimal integer; OPTIONAL, default is 871 entire body). This tag informs the verifier of the number of 872 bytes in the body of the email after canonicalization included in 873 the cryptographic hash, starting from 0 immediately following the 874 CRLF preceding the body. 876 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 877 allow display of fraudulent content without appropriate 878 warning to end users. The l= tag is intended for increasing 879 signature robustness when sending to mailing lists that both 880 modify their content and do not sign their messages. 881 However, using the l= tag enables man-in-the-middle attacks 882 in which an intermediary with malicious intent modifies a 883 message to include content that solely benefits the attacker. 885 It is possible for the appended content to completely replace 886 the original content in the end recipient's eyes and to 887 defeat duplicate message detection algorithms. Examples are 888 described in Security Considerations (Section 8). 890 To avoid this attack, signers should be extremely wary of 891 using this tag, and verifiers might wish to ignore the tag or 892 remove text that appears after the specified content length. 894 ABNF: 896 sig-l-tag = %x6c [FWS] "=" [FWS] 1*DIGIT 898 q= A colon-separated list of query methods used to retrieve the 899 public key (plain-text; OPTIONAL, default is "dns"). Each query 900 method is of the form "type[/options]", where the syntax and 901 semantics of the options depends on the type. If there are 902 multiple query mechanisms listed, the choice of query mechanism 903 MUST NOT change the interpretation of the signature. Currently 904 the only valid value iis "dns" which defines the DNS lookup 905 algorithm described elsewhere in this document. No options are 906 defined for the "dns" query type, but the string "dns" MAY have a 907 trailing "/" character. Verifiers and signers MUST support 908 "dns". 910 INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on 911 "dns" allows for the possibility of adding options later and 912 makes it clear that matching of the query type must terminate 913 on either "/" or end of string. 915 ABNF: 917 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 918 *([FWS] ":" [FWS] sig-q-tag-method) 919 sig-q-tag-method = sig-q-tag-type ["/" sig-q-tag-args] 920 sig-q-tag-type = "dns" / x-sig-q-tag-type 921 x-sig-q-tag-type = hyphenated-word ; for future extension 922 x-sig-q-tag-args = qp-hdr-value 924 s= The selector subdividing the namespace for the "d=" (domain) tag 925 (plain-text; REQUIRED). 927 ABNF: 929 sig-s-tag = %x73 [FWS] "=" [FWS] Domain 930 t= Signature Timestamp (plain-text; RECOMMENDED, default is an 931 unknown creation time). The time that this signature was 932 created. The format is the number of seconds since 00:00:00 on 933 January 1, 1970 in the UTC time zone. The value is expressed as 934 an unsigned integer in decimal ASCII. This value is not 935 constrained to fit into a 31- or 32-bit integer. Implementations 936 SHOULD be prepared to handle values up to at least 10^12 (until 937 approximately AD 200,000; this fits into 40 bits). To avoid 938 denial of service attacks, implementations MAY consider any value 939 longer than 12 digits to be infinite. 941 ABNF: 943 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 945 x= Signature Expiration (plain-text; RECOMMENDED, default is no 946 expiration). The format is the same as in the "t=" tag, 947 represented as an absolute date, not as a time delta from the 948 signing timestamp. Signatures MUST NOT be considered valid if 949 the current time at the verifier is past the expiration date. 950 The value is expressed as an unsigned integer in decimal ASCII, 951 with the same contraints on the value in the "t=" tag. The value 952 of the "x=" tag MUST be greater than the value of the "t=" tag if 953 both are present. 955 INFORMATIVE NOTE: The x= tag is not intended as an anti- 956 replay defense. 958 ABNF: 960 sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT 962 z= Copied header fields (plain-text, but see description; OPTIONAL, 963 default is null). A vertical-bar-separated list of header field 964 names and copies of header field values that identify the header 965 fields present when the message was signed. This field need not 966 contain the same header fields listed in the "h=" tag. Copied 967 header field values MUST immediately follow the header field name 968 with a colon separator (no white space permitted). Header field 969 values MUST be represented as Quoted-Printable [RFC2045] with 970 vertical bars, colons, semicolons, and white space encoded in 971 addition to the usual requirements. 973 Verifiers MUST NOT use the header field names or copied values 974 for checking the signature in any way. Copied header field 975 values are for diagnostic use only. 977 Header fields with characters requiring conversion (perhaps from 978 legacy MTAs which are not [RFC2822] compliant) SHOULD be 979 converted as described in MIME Part Three [RFC2047]. 981 ABNF: 982 sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy 983 *( [FWS] "|" sig-z-tag-copy ) 984 sig-z-tag-copy = hdr-name ":" [FWS] qp-hdr-value 985 qp-hdr-value = 987 ; needs to be updated with real definition 988 ; (could be messy) 990 INFORMATIVE EXAMPLE of a signature header field spread across 991 multiple continuation lines: 993 DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane 994 c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; 995 h=from:to:subject:date; 996 z=From:foo@eng.example.net|To:joe@example.com| 997 Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 998 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 999 VoG4ZHRNiYzR 1001 3.6 Key Management and Representation 1003 Signature applications require some level of assurance that the 1004 verification public key is associated with the claimed signer. Many 1005 applications achieve this by using public key certificates issued by 1006 a trusted third party. However, DKIM can achieve a sufficient level 1007 of security, with significantly enhanced scalability, by simply 1008 having the verifier query the purported signer's DNS entry (or some 1009 security-equivalent) in order to retrieve the public key. 1011 DKIM keys can potentially be stored in multiple types of key servers 1012 and in multiple formats. The storage and format of keys are 1013 irrelevant to the remainder of the DKIM algorithm. 1015 Parameters to the key lookup algorithm are the type of the lookup 1016 (the "q=" tag), the domain of the responsible signer (the "d=" tag of 1017 the DKIM-Signature header field), the signing identity (the "i=" 1018 tag), and the selector (the "s=" tag). The "i=" tag value could be 1019 ignored by some key services. 1021 public_key = dkim_find_key(q_val, d_val, i_val, s_val) 1023 This document defines a single binding, using DNS to distribute the 1024 keys. 1026 3.6.1 Textual Representation 1028 It is expected that many key servers will choose to present the keys 1029 in an otherwise unstructured text format (for example, an XML form 1030 would not be considered to be unstructured text for this purpose). 1031 The following definition MUST be used for any DKIM key represented in 1032 an otherwise unstructured textual form. 1034 The overall syntax is a key-value-list as described in Section 3.2. 1035 The current valid tags are described below. Other tags MAY be 1036 present and MUST be ignored by any implementation that does not 1037 understand them. 1039 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 1040 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 1041 (without the quotes). This tag MUST be the first tag in the 1042 response. Responses beginning with a "v=" tag with any other 1043 value MUST be discarded. 1045 ABNF: 1047 key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" 1049 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 1050 This value MUST match the local part of the signing address, with 1051 a "*" character acting as a wildcard. The intent of this tag is 1052 to constrain which signing address can legitimately use this 1053 selector. An email with a signing address that does not match 1054 the value of this tag constitutes a failed verification. 1055 Wildcarding allows matching for addresses such as "user+*". An 1056 empty "g=" value never matches any addresses. 1058 ABNF: 1060 key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart 1061 key-g-tag-lpart = [dot-atom] ["*"] [dot-atom] 1063 [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a dot- 1064 atom. This should probably use a different character for 1065 wildcarding. Unfortunately, the options are non-mnemonic 1066 (e.g., "@", "(", ":"). Alternatively we could insist on 1067 escaping a "*" intended as a literal "*" in the address.]] 1069 h= Accceptable hash algorithms (plain-text; OPTIONAL, defaults to 1070 allowing all algorithms). A colon-separated list of hash 1071 algorithms that might be used. Signers and Verifiers MUST 1072 support the "sha1" hash algorithm. 1074 ABNF: 1076 key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 1077 0*( [FWS] ":" [FWS] key-h-tag-alg ) 1078 key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg 1079 x-key-h-tag-alg = hyphenated-word ; for future extension 1081 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 1082 verifiers MUST support the "rsa" key type. The "rsa" key type 1083 indicates that an RSA public key, as defined in [RFC3447], 1084 sections 3.1 and A.1.1, is being used in the p= tag. (Note: the 1085 p= tag further encodes the value using the base64 algorithm.) 1087 ABNF: 1089 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 1090 key-k-tag-type = "rsa" / x-key-k-tag-type 1091 x-key-k-tag-type = hyphenated-word ; for future extension 1093 [[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be 1094 hard to separate h= and k=; for example DSA implies that 1095 SHA-1 will be used. This might be an actual change to the 1096 spec depending on how we decide to fix this.]] 1098 n= Notes that might be of interest to a human (quoted-printable; 1099 OPTIONAL, default is empty). No interpretation is made by any 1100 program. This tag should be used sparingly in any key server 1101 mechanism that has space limitations (notably DNS). 1103 ABNF: 1105 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 1106 p= Public-key data (base64; REQUIRED). An empty value means that 1107 this public key has been revoked. The syntax and semantics of 1108 this tag value before being encoded in base64 is defined by the 1109 k= tag. 1111 ABNF: 1113 key-p-tag = %x70 [FWS] "=" [FWS] base64string 1115 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 1116 separated list of service types to which this record applies. 1117 Verifiers for a given service type MUST ignore this record if the 1118 appropriate type is not listed. Currently defined service types 1119 are: 1121 * matches all service types 1123 email electronic mail (not necessarily limited to SMTP) 1125 This tag is intended to permit senders to constrain the use of 1126 delegated keys, e.g., where a company is willing to delegate the 1127 right to send mail in their name to an outsourcer, but not to 1128 send IM or make VoIP calls. (This of courrse presumes that these 1129 keys are used in other services in the future.) 1131 ABNF: 1133 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type 1134 key-s-tag-type = "email" / "*" / x-key-s-tag-type 1135 x-key-s-tag-type = hyphenated-word ; for future extension 1137 t= Flags, represented as a colon-separated list of names (plain- 1138 text; OPTIONAL, default is no flags set). The defined flags are: 1140 y This domain is testing DKIM. Verifiers MUST NOT treat 1141 messages from signers in testing mode differently from 1142 unsigned email, even should the signature fail to verify. 1143 Verifiers MAY wish to track testing mode results to assist 1144 the signer. 1146 ABNF: 1148 key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 1149 0*( [FWS] ":" [FWS] key-t-tag-flag ) 1150 key-t-tag-flag = "y" / x-key-t-tag-flag 1151 x-key-t-tag-flag = hyphenated-word ; for future extension 1153 Unrecognized flags MUST be ignored. 1155 3.6.2 DNS binding 1157 A binding using DNS as a key service is hereby defined. All 1158 implementations MUST support this binding. 1160 3.6.2.1 Name Space 1162 All DKIM keys are stored in a subdomain named ""_domainkey"". Given 1163 a DKIM-Signature field with a "d=" tag of ""example.com"" and an "s=" 1164 tag of ""sample"", the DNS query will be for 1165 ""sample._domainkey.example.com"". 1167 The value of the "i=" tag is not used by the DNS binding. 1169 3.6.2.2 Resource Record Types for Key Storage 1171 [[This section needs to be fleshed out. ACTUALLY: will be addressed 1172 in another document.]] 1174 Two RR types are used: DKK and TXT. 1176 The DKK RR is expected to be a non-text, binary representation 1177 intended to allow the largest possible keys to be represented and 1178 transmitted in a UDP DNS packet. Details of this RR are described in 1179 [ID-DKIM-RR]. 1181 TXT records are encoded as described in Section 3.6.1. 1183 Verifiers SHOULD search for a DKK RR first, if possible, followed by 1184 a TXT RR. If the verifier is unable to search for a DKK RR or a DKK 1185 RR is not found, the verifier MUST search for a TXT RR. 1187 3.7 Computing the Message Hashes 1189 Both signing and verifying message signatures starts with a step of 1190 computing two cryptographic hash over the message. Signers will 1191 choose the parameters of the signature as described in Signer Actions 1192 (Section 5); verifiers will use the parameters specified in the 1193 "DKIM-Signature" header field being verified. In the following 1194 discussion, the names of the tags in the "DKIM-Signature" header 1195 field which either exists (when verifying) or will be created (when 1196 signing) are used. Note that canonicalization (Section 3.4) is only 1197 used to prepare the email for signing or verifying; it does not 1198 affect the transmitted email in any way. 1200 The signer or verifier must compute two hashes, one over the body of 1201 the message and one over the header of the message. Signers MUST 1202 compute them in the order shown. Verifiers MAY compute them in any 1203 order convenient to the verifier, provided that the result is 1204 semantically identical to the semantics that would be the case had 1205 they been computed in this order. 1207 In hash step 1, the signer or verifier MUST hash the message body, 1208 canonicalized using the header canonicalization algorithm specified 1209 in the "c=" tag and truncated to the length specified in the "l=" 1210 tag. That hash value is then converted to base64 form and inserted 1211 into the "XXX=" tag of the DKIM-Signature: header field. 1213 In hash step 2, the signer or verifier MUST pass the following to the 1214 hash algorithm in the indicated order. 1216 1. The header fields specified by the "h=" tag, in the order 1217 specified in that tag, and canonicalized using the header 1218 canonicalization algorithm specified in the "c=" tag. Each 1219 header field must be terminated with a single CRLF. 1221 2. The "DKIM-Signature" header field that exists (verifying) or will 1222 be inserted (signing) in the message, with the value of the "b=" 1223 tag deleted (i.e., treated as the empty string), canonicalized 1224 using the header canonicalization algorithm specified in the "c=" 1225 tag, and without a trailing CRLF. 1227 After the body is processed, a single CRLF followed by the "DKIM- 1228 Signature" header field being created or verified is presented to the 1229 algorithm. The value portion of the "b=" tag (that is, the portion 1230 after the "=" sign) must be treated as though it were empty, and the 1231 header field must be canonicalized according to the algorithm that is 1232 specified in the "c=" tag. Any final CRLF on the "DKIM-Signature" 1233 header field MUST NOT be included in the signature computation. 1235 All tags and their values in the DKIM-Signature header field are 1236 included in the cryptographic hash with the sole exception of the 1237 value portion of the "b=" (signature) tag, which MUST be treated as 1238 the null string. All tags MUST be included even if they might not be 1239 understood by the verifier. The header field MUST be presented to 1240 the hash algorithm after the body of the message rather than with the 1241 rest of the headder fields and MUST be canonicalized as specified in 1242 the "c=" (canonicalization) tag. The DKIM-Signature header field 1243 MUST NOT be included in its own h= tag. 1245 When calculating the hash on messages that will be transmitted using 1246 base64 or quoted-printable encoding, signers MUST compute the hash 1247 after the encoding. Likewise, the verifier MUST incorporate the 1248 values into the hash before decoding the base64 or quoted-printable 1249 text. However, the hash MUST be computed before transport level 1250 encodings such as SMTP "dot-stuffing." 1252 With the exception of the canonicalization procedure described in 1253 Section 3.4, the DKIM signing process treats the body of messages as 1254 simply a string of characters. DKIM messages MAY be either in plain- 1255 text or in MIME format; no special treatment is afforded to MIME 1256 content. Message attachments in MIME format MUST be included in the 1257 content which is signed. 1259 More formally, the algorithm for the signature is: 1260 body-hash = hash-alg(canon_body) 1261 header-hash = crypt-alg(hash-alg(canon_header || DKIM-SIG), key) 1263 where crypt-alg is the encryption algorithm specified by the "a=" 1264 tag, hash-alg is the hash algorithm specified by the "a=" tag, 1265 canon_header and canon_body are the canonicalized message header and 1266 body (respectively) as defined in Section 3.4 (excluding the DKIM- 1267 Signature header field), and DKIM-SIG is the canonicalized DKIM- 1268 Signature header field sans the signature value itself, but with 1269 body-hash included as the "bh=" tag. 1271 4. Semantics of Multiple Signatures 1273 A signer that is adding a signature to a message merely creates a new 1274 DKIM-Signature header, using the usual semantics of the h= option. A 1275 signer MAY sign previously existing DKIM-Signature headers using the 1276 method described in section NN to sign trace headers. Signers should 1277 be cognizant that signing DKIM-Signature headers may result in 1278 signature failures with intermediaries that do not recognize that 1279 DKIM-Signature's are trace headers and unwittingly reorder them. 1281 When evaluating a message with multiple signatures, a receiver should 1282 evaluate signatures independently and on their own merits. For 1283 example, a receiver that by policy chooses not to accept signatures 1284 with deprecated crypto algorithms should consider such signatures 1285 invalid. As with messages with a single signature, receievers are at 1286 liberty to use the presence of valid signatures as an input to local 1287 policy; likewise, the interpretation of multiple valid signatures in 1288 combination is a local policy decision of the receiver. 1290 Signers SHOULD NOT remove any DKIM-Signature headers from messages 1291 they are signing, even if they know that the headers cannot be 1292 verified. 1294 5. Signer Actions 1296 The following steps are performed in order by signers. 1298 5.1 Determine if the Email Should be Signed and by Whom 1300 A signer can obviously only sign email for domains for which it has a 1301 private-key and the necessary knowledge of the corresponding public 1302 key and selector information. However there are a number of other 1303 reasons beyond the lack of a private key why a signer could choose 1304 not to sign an email. 1306 A SUBMISSION server MAY sign if the sender is authenticated by some 1307 secure means, e.g., SMTP AUTH. Within a trusted enclave the signing 1308 address MAY be derived from the header field according to local 1309 signer policy. Within a trusted enclave an MTA MAY do the signing. 1311 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1312 sign Received header fields if the outgoing gateway MTA obfuscates 1313 Received header fields, for example to hide the details of 1314 internal topology. 1316 A signer MUST NOT sign an email if it is unwilling to be held 1317 responsible for the message; in particular, the signer SHOULD ensure 1318 that the submitter has a bona fide relationship with the signer and 1319 that the submitter has the right to use the address being claimed. 1321 If an email cannot be signed for some reason, it is a local policy 1322 decision as to what to do with that email. 1324 5.2 Select a private-key and corresponding selector information 1326 This specification does not define the basis by which a signer should 1327 choose which private-key and selector information to use. Currently, 1328 all selectors are equal as far as this specification is concerned, so 1329 the decision should largely be a matter of administrative 1330 convenience. Distribution and management of private-keys is also 1331 outside the scope of this document. 1333 A signer SHOULD NOT sign with a key that is expected to expire within 1334 seven days; that is, when rotating to a new key, signing should 1335 immediately commence with the new key and the old key SHOULD be 1336 retained for at least seven days before being removed from the key 1337 server. 1339 5.3 Normalize the Message to Prevent Transport Conversions 1341 Some messages, particularly those using 8-bit characters, are subject 1342 to modification during transitt, notably conversion to 7-bit form. 1343 Such conversions will break DKIM signatures. In order to minimize 1344 the chances of such breakage, signers SHOULD convert the message to a 1345 suitable MIME content transfer encoding such as quoted-printable or 1346 base64 as described in MIME Part One [RFC2045] before signing. Such 1347 conversion is outside the scope of DKIM; the actual message SHOULD be 1348 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 1349 DKIM algorithm. 1351 Should the message be submitted to the signer with any local encoding 1352 that will be modified before transmission, such conversion to 1353 canonical form MUST be done before signing. In particular, some 1354 systems use local line separator conventions (such as the Unix 1355 newline character) internally rather than the SMTP-standard CRLF 1356 sequence. All such local conventions MUST be converted to canonical 1357 format before signing. 1359 More generally, the signer MUST sign the message as it will be 1360 received by the verifier rather than in some local or internal form. 1362 5.4 Determine the header fields to Sign 1364 The From header field MUST be signed (that is, included in the h= tag 1365 of the resulting DKIM-Signature header field); any header field that 1366 describes the role of the signer (for example, the Sender or Resent- 1367 From header field if the signature is on behalf of the corresponding 1368 address and that address is different from the From address) MUST 1369 also be included. The signed header fields SHOULD also include the 1370 Subject and Date header fields as well as all MIME header fields. 1371 Signers SHOULD NOT sign an existing header field likely to be 1372 legitimately modified or removed in transit. In particular, 1373 [RFC2821] explicitly permits modification or removal of the "Return- 1374 Path" header field in transit. Signers MAY include any other header 1375 fields present at the time of signing at the discretion of the 1376 signer. It is RECOMMENDED that all other existing, non-repeatable 1377 header fields be signed. 1379 The DKIM-Signature header field is always implicitly signed and MUST 1380 NOT be included in the h= tag except to indicate that other 1381 preexisting signatures are also signed. 1383 Signers MUST sign any header fields that the signers wish to assert 1384 were present at the time of signing. Put another way, verifiers MAY 1385 treat unsigned header fields with extreme skepticism, up to and 1386 including refusing to display them to the end user. 1388 Signers MAY claim to have signed header fields that do not exist 1389 (that is, signers MAY include the header field name in the h=D tag 1390 even if that header field does not exist in the message). When 1391 computing the signature, the non-existing header field MUST be 1392 treated as the null string (including the header field name, header 1393 field value, all punctuation, and the trailing CRLF). 1395 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1396 the absence of a header field; if that header field is added later 1397 the signature will fail. 1399 Signers choosing to sign an existing replicated header field (such as 1400 Received) MUST sign the physically last instance of that header field 1401 in the header field block. Signers wishing to sign multiple 1402 instances of an existing replicated header field MUST include the 1403 header field name multiple times in the h= tag of the DKIM-Signature 1404 header field, and MUST sign such header fields in order from the 1405 bottom of the header field block to the top. The signer MAY include 1406 more header field names than there are actual corresponding header 1407 fields to indicate that additional header fields of that name SHOULD 1408 NOT be added. 1410 INFORMATIVE EXAMPLE: 1412 If the signer wishes to sign two existing Received header fields, 1413 and the existing header contains: 1415 Received: 1416 Received: 1417 Received: 1419 then the resulting DKIM-Signature header field should read: 1421 DKIM-Signature: ... h=Received : Received : ... 1423 and Received header fields and will be signed in that 1424 order. 1426 Signers SHOULD NOT sign header fields that might be replicated 1427 (either at the time of signing or potentially in the future), with 1428 the exception of trace header fields such as Received. Comment and 1429 non standard header fields (including X-* header fields) are 1430 permitted by [RFC2822] to be replicated; however, many such header 1431 fields are, by convention, not replicated. Signers need to 1432 understand the implications of signing header fields that might later 1433 be replicated, especially in the face of header field reordering. In 1434 particular, [RFC2822] only requires that trace header fields retain 1435 the original order. 1437 INFORMATIVE RATIONALE: Received: is allowed because these header 1438 fields, as well as Resent-* header fields, are already order- 1439 sensitive. 1441 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1442 header field blocks to be reordered (with the exception of 1443 Received header fields), reordering of signed replicated header 1444 fields by intermediate MTAs will cause DKIM signatures to be 1445 broken; such anti-social behavior shoulld be avoided. 1447 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1448 specification, all end-user visible header fields should be signed 1449 to avoid possible "indirect spamming." For example, if the 1450 "Subject" header field is not signed, a spammer can resend a 1451 previously signed mail, replacing the legitimate subject with a 1452 one-line spam. 1454 INFORMATIVE NOTE: There has been some discussion that a Sender 1455 Signing Policy include the list of header fields that the signer 1456 always signs. N.B. In theory this is unnecessary, since as long 1457 as the signer really always signs the indicated header fields 1458 there is no possibility of an attacker replaying an existing 1459 message that has such an unsigned header field. 1461 5.5 Compute the Message Hash and Signature 1463 The signer MUST compute the message hash as described in Section 3.7 1464 and then sign it using the selected public-key algorithm. This will 1465 result in a DKIM-Signature header field which will include the body 1466 hash and a signature of the header hash, where that header includes 1467 the DKIM-Signature header field itself. 1469 To avoid possible ambiguity, a signer SHOULD either sign or remove 1470 any preexisting header fields which convey the results of previous 1471 verifications of the message signature prior to preparation for 1472 signing and transmission. Such header fields MUST NOT be signed if 1473 the signer is uncertain of the authenticity of the preexisting header 1474 field, for example, if it is not locally generated or signed by a 1475 previous DKIM-Signature line that the current signer has verified. 1477 Entities such as mailing list managers that implement DKIM and which 1478 modify the message or a header field (for example, inserting 1479 unsubscribe information) before retransmitting the message SHOULD 1480 check any existing signature on input and MUST make such 1481 modifications before re-signing the message; such signing SHOULD 1482 include any prior verification status, if any, that was inserted upon 1483 message receipt. 1485 The signer MAY elect to limit the number of bytes of the body that 1486 will be included in the hash and hence signed. The length actually 1487 hashed should be inserted in the "l=" tag of the "DKIM-Signature" 1488 header field. 1490 INFORMATIVE NOTE: A possible value to include in the "l=" tag 1491 would include the entire length of the message being signed, 1492 thereby allowing intermediate agents to append further information 1493 to the message without breaking the signature (e.g., a mailing 1494 list manager might add unsubscribe innformation to the body). A 1495 signer wishing to permit such intermediate agents to add another 1496 MIME body part to a "multipart/mixed" message should use a length 1497 that covers the entire presented message except for the trailing 1498 "--CRLF" characters; this is known as the "N-4" approach. Note 1499 that more than four characters may need to be stripped, since 1500 there could be postlude information that needs to be ignored. 1502 5.6 Insert the DKIM-Signature header field 1504 Finally, the signer MUST insert the "DKIM-Signature:" header field 1505 created in the previous step prior to transmitting the email. The 1506 "DKIM-Signature" header field MUST be the same as used to compute the 1507 hash as described above, except that the value of the "b=" tag MUST 1508 be the appropriately signed hash computed in the previous step, 1509 signed using the algorithm specified in the "a=" tag of the "DKIM- 1510 Signature" header field and using the private key corresponding to 1511 the selector given in the "s=" tag of the "DKIM-Signature" header 1512 field, as chosen above in Section 5.2 1514 The "DKIM-Signature" SHOULD be inserted before any header fields that 1515 it signs in the header block. 1517 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1518 is to insert the "DKIM-Signature" header field at the beginning of 1519 the header block. In particular, it may be placed before any 1520 existing Received header fields. This is consistent with treating 1521 "DKIM-Signature" as a trace header. 1523 6. Verifier Actions 1525 Since a signer MAY expire a public key at any time, it is recommended 1526 that verification occur in a timely manner with the most timely place 1527 being during acceptance by the border MTA. 1529 A border or intermediate MTA MAY verify the message signatures and 1530 add a verification header field to incoming messages. This 1531 considerably simplifies things for the user, who can now use an 1532 existing mail user agent. Most MUAs have the ability to filter 1533 messages based on message header fields or content; these filters 1534 would be used to implement whatever policy the user wishes with 1535 respect to unsigned mail. 1537 A verifying MTA MAY implement a policy with respect to unverifiable 1538 mail, regardless of whether or not it applies the verification header 1539 field to signed messages. 1541 Verifiers MUST apply the following steps in the order listed. In 1542 many cases these steps say that a "DKIM-Signature" header field must 1543 be ignored, e.g., because it is malformed or because the signature 1544 verification failed. In such cases verifiers SSHOULD proceed to the 1545 next signature, and treat the message as verified if any signature 1546 succeeded, ignoring the bad signatures. The order in which 1547 signatures are tried is a matter of local policy for the verifier and 1548 is not defined here. A verifier MAY treat a message that has one or 1549 more bad signatures and no good signatures differently from a message 1550 with no signature at all; again, this is local policy and is beyond 1551 the scope of this document. 1553 6.1 Extract the Signature from the Message 1555 The signature and associated signing identity is included in the 1556 value of the DKIM-Signature header field. 1558 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. 1559 Existence of such a tag indicates a new, incompatible version of the 1560 DKIM-Signature header field. 1562 If the "DKIM-Signature" header field does not contain the "i=" tag, 1563 the verifier MUST behave as though the value of that tag were "@d", 1564 where "d" is the value from the "d=" tag (which MUST exist). 1566 Verifiers MUST confirm that the domain specified in the "d=" tag is 1567 the same as or a superdomain of the domain part of the "i=" tag. If 1568 not, the DKIM-Signature header field MUST be ignored. 1570 Implementers MUST meticulously validate the format and values in the 1571 "DKIM-Signature:" header field; any inconsistency or unexpected 1572 values MUST cause the header field to be completely ignored. Being 1573 "liberal in what you accept" is definitely a bad strategy in this 1574 security context. Note however that this does not include the 1575 existence of unknown tags in a "DKIM-Signature" header field, which 1576 are explicitly permitted. 1578 Verifiers MUST NOT attribute ultimate meaning to the order of 1579 multiple DKIM-Signature header fields. In particular, there is 1580 reason to believe that some relays will reorder the header field in 1581 potentially arbitrary ways. 1583 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1584 a clue to signing order in the absence of any other information. 1585 However, other clues as to the semantics of multiple signatures 1586 must be considered before using ordering. 1588 Since there can be multiple signatures in a message, a verifier 1589 SHOULD ignore an invalid signature (regardless if caused by a 1590 syntactic or semantic problem) and try other signatures. A verifier 1591 MAY choose to treat a message with one or more invalid signatures and 1592 no valid signatures with more suspicion than a message with no 1593 signature at all. 1595 6.2 Get the Public Key 1597 The public key is needed to complete the verificatiion process. The 1598 process of retrieving the public key depends on the query type as 1599 defined by the "q=" tag in the "DKIM-Signature:" header field line. 1600 Obviously, a public key should only be retrieved if the process of 1601 extracting the signature information is completely successful. 1602 Details of key management and representation are described in 1603 Section 3.6. The verifier MUST validate the key record and MUST 1604 ignore any public key records that are malformed. 1606 When validating a message, a verifier MUST perform the following 1607 steps in a manner that is semantically the same as performing them in 1608 the order indicated (in some cases the implementation may parallelize 1609 or reorder these steps, as long as the semantics remain unchanged): 1611 1. Retrieve the public key as described in (Section 3.6) using the 1612 domain from the "d=" tag and the selector from the "s=" tag. 1614 2. If the query for the public key fails to respond, the verifier 1615 SHOULD defer acceptance of this email (normally this will be 1616 achieved with a 451/4.7.5 SMTP reply code). 1618 3. If the query for the public key fails because the corresponding 1619 RR does not exist, the verifier MUST ignore the signature. 1621 4. If the result returned from the query does not adhere to the 1622 format defined in this specification, the verifier MUST ignore 1623 the signature. 1625 5. If the "g=" tag in the public key does not match the local part 1626 of the "i=" tag on the message signature, the verifier MUST 1627 ignore the signature. If the local part of the "i=" tag on the 1628 message signature is not present, the g= tag must be * (valid for 1629 all addresses in the domain) or not present (which defaults to 1630 *), otherwise the verifier MUST ignore the signature. Other than 1631 this test, verifiers MUST NOT treat a message signed with a key 1632 record having a g= tag any differently than one without; in 1633 particular, verifiers MUST NOT prefer messages that seem to have 1634 an individual signature by virtue of a g= tag vs. a domain 1635 signature. 1637 6. If the "h=" tag exists in the public key record and the hash 1638 algorithm implied by the a= tag in the DKIM-Signature header is 1639 not included in the "h=" tag, the verifier MUST ignore the 1640 signature. 1642 7. If the public key data (the "p=" tag) is empty then this key has 1643 been revoked and the verifier MUST treat this as a failed 1644 signature check. 1646 8. If the public key data is not suitable for use with the algorithm 1647 type defined by the "a=" tag in the "DKIM-Signature" header 1648 field, the verifier MUST ignore the signature. 1650 If the signature is to be ignored, verifiers SHOULD search for 1651 another signature in the message. 1653 6.3 Compute the Verification 1655 Given a signer and a public key, verifying a signature consists of 1656 the following steps. 1658 1. Based on the algorithm defined in the "c=" tag, the body length 1659 specified in the "l=" tag, and the header field names in the "h=" 1660 tag, create a canonicalized copy of the email as is described in 1661 Section 3.7. When matching header field names in the "h=" tag 1662 against the actual message header field, comparisons MUST be 1663 case-insensitive. 1665 2. Based on the algorithm indicated in the "a=" tag, 1667 * Compute the message hashes from the canonical copy as 1668 described in Section 3.7. 1670 * Decrypt the signature using the signer's public key. 1672 3. Compare the decrypted signature to the message hash. If they are 1673 identical, the hash computed by the signer must be the same as 1674 the hash computed by the verifier, and hence the signature 1675 verifies; otherwise, the signature fails. 1677 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1678 initiate the public-key query in parallel with calculating the 1679 hash as the public key is not needed until the final decryption is 1680 calculated. Implementations may also verify the signature on the 1681 message header before validating that the message hash listed in 1682 the "bh=" tag in the DKIM-Signature header field matches that of 1683 the actual message body; however, if the body hash does match, the 1684 entire signature must be considered to have failed. 1686 Verifiers SHOULD ignore any DKIM-Signature header fields where the 1687 signature does not validate. Verifiers that are prepared to validate 1688 multiple signature header fields SHOULD proceed to the next signature 1689 header field, should it exist. However, verifiers MAY make note of 1690 the fact that an invalid signature was present for consideration at a 1691 later step. 1693 INFORMATIVE NOTE: The rationale of this requirement is to permit 1694 messages that have invalid signatures but also a valid signature 1695 to work. For example, a mailing list exploder might opt to leave 1696 the original submitter signature in place even though the exploder 1697 knows that it is modifying the message in some way that will break 1698 that signature, and the exploder inserts its own signature. In 1699 this case the message should succeed eveen in the presence of the 1700 known-broken signature. 1702 If a body length is specified in the "l=" tag of the signature, 1703 verifiers MUST only verify the number of bytes indicated in the body 1704 length. Verifiers MAY decide to treat a message containing bytes 1705 beyond the indicated body length with suspicion. Verifiers MAY 1706 truncate the message at the indicated body length or reject the 1707 signature outright. 1709 INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body 1710 at the indicated body length might pass on a malformed MIME 1711 message if the signer used the "N-4" trick described in the 1712 informative note inSection 5.5. Such verifiers may wish to check 1713 for this case and include a trailing "--CRLF" to avoid breaking 1714 the MIME structure. A simple way to achieve this might be to 1715 append "--CRLF" to any "multipart" message with a body length; if 1716 the MIME structure is already correctly formed, this will appear 1717 in the postlude and will not be displayed to the end user. 1719 6.4 Communicate Verification Results 1721 Verifiers wishing to communicate the results of verification to other 1722 parts of the mail system may do so in whatever manner they see fit. 1723 For example, implementations might choose to add an email header 1724 field to the message before passing it on. An example proposal for a 1725 header field is the Authentication-Results header field [ID-AUTH- 1726 RES]. Any such header field SHOULD be inserted before any existing 1727 DKIM-Signature or Authentication-Results header fields in the header 1728 field block. 1730 INFORMATIVE ADVICE to MUA filter writers: Patterns intended to 1731 search for results header fields to visibly mark authenticated 1732 mail for end users should verify that such header field was added 1733 by the appropriate verifying domain and that the verified identity 1734 matches the sender identity that will be displayed by the MUA. In 1735 particular, MUA patterns should not be influenced by bogus results 1736 header fields added by attackers. 1738 6.5 Interpret Results/Apply Local Policy 1740 It is beyond the scope of this specification to describe what actions 1741 a verifier system should make, but an authenticated email presents an 1742 opportunity to a receiving system that unauthenticated email cannot. 1743 Specifically, an authenticated email creates a predictable identifier 1744 by which other decisions can reliably be managed, such as trust and 1745 reputation. Conversely, unauthenticated email lacks a reliable 1746 identifier that can be used to assign trust and reputation. It is 1748 reasonable to treat unauthenticated email as lacking any trust and 1749 having no positive reputation. 1751 If the verifying MTA is capable of verifying the public key of the 1752 signer and check the signature on the message synchronously with the 1753 SMTP session and such signature is missing or does not verify the MTA 1754 MAY reject the message with an error such as: 1756 550 5.7.1 Unsigned messages not accepted 1758 550 5.7.5 Message signature incorrect 1760 If it is not possible to fetch the public key, perhaps because the 1761 key server is not available, a temporary failure message MAY be 1762 generated, such as: 1764 451 4.7.5 Unable to verify signature - key server unavailable 1766 Once the signature has been verified, that information MUST be 1767 conveyed to higher level systems (such as explicit allow/white lists 1768 and reputation systems) and/or to the end user. If the message is 1769 signed on behalf of any address other than that in the From: header 1770 field, the mail system SHOULD take pains to ensure that the actual 1771 signing identity is clear to the reader. 1773 INFORMATIVE NOTE: If the authentication status is to be stored in 1774 the message header field, the Authentication-Results header field 1775 [ID-AUTH-RES] may be used to convey this information. 1777 The verifier MAY treat unsigned header fields with extreme 1778 skepticism, including marking them as untrusted or even deleting them 1779 before display to the end user. 1781 While the symptoms of a failed verification are obvious -- the 1782 signature doesn't verify -- establishing the exact cause can be more 1783 difficult. If a selector cannot be found, is that because the 1784 selector has been removed or was the value changed somehow in 1785 transit? If the signature line is missing is that because it was 1786 never there, or was it removed by an over-zealous filter? For 1787 diagnostic purposes, the exact reason why the verification fails 1788 SHOULD be recorded in the "Authentication-Results" header field and 1789 possibly the system logs. However in terms of presentation to the 1790 end user, the result SHOULD be presented as a simple binary result: 1791 either the email is verified or it is not. If the email cannot be 1792 verified, then it SHOULD be rendered the same as all unverified email 1793 regardless of whether it looks like it was signed or not. 1795 6.6 MUA Considerations 1797 In order to retain the current semantics and visibility of the From 1798 header field, verifying mail agents SHOULD take steps to ensure that 1799 the signing address is prominently visible to the user if it is 1800 different from the From address. MUAs MAY visually mark the 1801 unverified part of the body in a distinctive font or color to the end 1802 user. 1804 If MUA implementations that highlight the signed address are not 1805 available, this MAY be done by the validating MTA or MDA by rewriting 1806 the From address in a manner which remains compliant with [RFC2822]. 1807 Such modifications MUST be performed after the final verification 1808 step since they will break the signature. If performed, the 1809 rewriting SHOULD include the name of the signer in the address. For 1810 example: 1812 From: John Q. User 1814 might be converted to 1816 From: "John Q. User via " 1818 This sort of address inconsistency is expected for mailing lists, but 1819 might be otherwise used to mislead the verifier, for example if a 1820 message supposedly from administration@your-bank.com had a Sender 1821 address of fraud@badguy.com. 1823 Under no circumstances should an unsigned header field be displayed 1824 in any context that might be construed by the end user as having been 1825 signed. Notably, unsigned header fields SHOULD be hidden from the 1826 end user to the extent possible. 1828 The MUA MAY hide or mark portions of the message body that are not 1829 signed wh�en using the "l=" tag. 1831 7. IANA Considerations 1833 Use of the _domainkey prefix in DNS records will require registration 1834 by IANA. 1836 To avoid conflicts, tag names for the DKIM-Signature header and key 1837 records should be registered with IANA. 1839 Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature 1840 header field, and the "h=", "k=", "s=", and "t" tags in key records 1841 should be registered with IANA for the same reason. 1843 The DKK RR type must be registered by IANA. 1845 8. Security Considerations 1847 It has been observed that any mechanism that is introduced which 1848 attempts to stem the flow of spam is subject to intensive attack. 1849 DKIM needs to be carefully scrutinized to identify potential attack 1850 vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. 1852 8.1 Misuse of Body Length Limits ("l=" Tag) 1854 Body length limits (in the form of the "l=" tag) are subject to 1855 several potential attacks. 1857 8.1.1 Addition of new MIME parts to multipart/* 1859 If the body length limit does not cover a closing MIME multipart 1860 section (including the trailing ""--CRLF"" portion), then it is 1861 possible for an attacker to intercept a properly signed multipart 1862 message and add a new body part. Depending on the details of the 1863 MIME type and the implementation of the verifying MTA and the 1864 receiving MUA, this could allow an attacker to change the information 1865 displayed to an end user from an apparently trusted source. 1867 *** Example appropriate here *** 1869 8.1.2 Addition of new HTML content to existing content 1871 Several receiving MUA implementations do not cease display after a 1872 """" tag. In particular, this allows attacks involving 1873 overlaying images on top of existing text. 1875 INFORMATIVE EXAMPLE: Appending the following text to an existing, 1876 properly closed message will in many MUAs result in inappropriate 1877 data being rendered on top of existing, correct data: 1878
1879 1881
1883 8.2 Misappropriated Private Key 1885 If the private key for a user is resident on their computer and is 1886 not protected by an appropriately secure mechanism, it is possible 1887 for malware to send mail as that user and any other user sharing the 1888 same private key. The malware would, however, not be able to 1889 generate signed spoofs of other signers' addresses, which would aid 1890 in identification of the infected user and would limit the 1891 possibilities for certain types of attacks involving socially- 1892 engineered messages. 1894 A larger problem occurs if malware on many users' computers obtains 1895 the private keys for those users and transmits them via a covert 1896 channel to a site where they can be shared. The compromised users 1897 would likely not know of the misappropriation until they receive 1898 "bounce" messages from messages they are purported to have sent. 1900 Many users might not understand the significance of these bounce 1901 messages and would not take action. 1903 One countermeasure is to use a user-entered passphrase to encrypt the 1904 private key, although users tend to choose weak passphrases and often 1905 reuse them for different purposes, possibly allowing an attack 1906 against DKIM to be extended into other domains. Nevertheless, the 1907 decoded private key might be briefly available to compromise by 1908 malware when it is entered, or might be discovered via keystroke 1909 logging. The added complexity of entering a passphrase each time one 1910 sends a message would also tend to discourage the use of a secure 1911 passphrase. 1913 A somewhat more effective countermeasure is to send messages through 1914 an outgoing MTA that can authenticate the submitter using existing 1916 techniques (e.g., SMTP Authentication), possibly validate the message 1917 itself (e.g., verify that the header is legitimate and that the 1918 content passes a spam content check), and sign the message using a 1919 key appropriate for the submitter address. Such an MTA can also 1920 apply controls on the volume of outgoing mail each user is permitted 1921 to originate in order to further limit the ability of malware to 1922 generate bulk email. 1924 8.3 Key Server Denial-of-Service Attacks 1926 Since the key servers are distributed (potentially separate for each 1927 domain), the number of servers that would need to be attacked to 1928 defeat this mechanism on an Internet-wide basis is very large. 1929 Nevertheless, key servers for individual domains could be attacked, 1930 impeding the verification of messages from that domain. This is not 1931 significantly different from the ability of an attacker to deny 1932 service to the mail exchangers for a given domain, although it 1933 affects outgoing, not incoming, mail. 1935 A variation on this attack is that if a very large amount of mail 1936 were to be sent using spoofed addresses from a given domain, the key 1937 servers for that domain could be overwhelmed with requests. However, 1938 given the low overhead of verification compared with handling of the 1939 email message itself, such an attack would be difficult to mount. 1941 8.4 Attacks Against DNS 1943 Since DNS is a required binding for key services, specific attacks 1944 against DNS must be considered. 1946 While the DNS is currently insecure [RFC3833], it is expected that 1947 the security problems should and will be solved by DNSSEC [RFC4033], 1948 and all users of the DNS will reap the benefit of that work. 1950 Secondly, the types of DNS attacks relevant to DKIM are very costly 1951 and are far less rewarding than DNS attacks on other Internet 1952 applications. 1954 To systematically thwart the intent of DKIM, an attacker must conduct 1955 a very costly and very extensive attack on many parts of the DNS over 1956 an extended period. No one knows for sure how attackers will 1957 respond, however the cost/benefit of conducting prolonged DNS attacks 1958 of this nature is expected to be uneconomical. 1960 Finally, DKIM is only intended as a "sufficient" method of proving 1961 authenticity. It is not intended to provide strong cryptographic 1962 proof about authorship or contents. Other technologies such as 1963 OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. 1965 A second security issue related to the DNS revolves around the 1966 increased DNS traffic as a consequence of fetching Selector-based 1967 data as well as fetching siggning domain policy. Widespread 1968 deployment of DKIM will result in a significant increase in DNS 1969 queries to the claimed signing domain. In the case of forgeries on a 1970 large scale, DNS servers could see a substantial increase in queries. 1972 8.5 Replay Attacks 1974 In this attack, a spammer sends a message to be spammed to an 1975 accomplice, which results in the message being signed by the 1976 originating MTA. The accomplice resends the message, including the 1977 original signature, to a large number of recipients, possibly by 1978 sending the message to many compromised machines that act as MTAs. 1979 The messages, not having been modified by the accomplice, have valid 1980 signatures. 1982 Partial solutions to this problem involve the use of reputation 1983 services to convey the fact that the specific email address is being 1984 used for spam, and that messages from that signer are likely to be 1985 spam. This requires a real-time detection mechanism in order to 1986 react quickly enough. However, such measures might be prone to 1987 abuse, if for example an attacker resent a large number of messages 1988 received from a victim in order to make them appear to be a spammer. 1990 Large verifiers might be able to detect unusually large volumes of 1991 mails with the same signature in a short time period. Smaller 1992 verifiers can get substantially the same volume information via 1993 existing collaborative systems. 1995 8.6 Limits on Revoking Keys 1997 When a large domain detects undesirable behavior on the part of one 1998 of its users, it might wish to revoke the key used to sign that 1999 user's messages in order to disavow responsibility for messages which 2000 have not yet been verified or which are the subject of a replay 2001 attack. However, the ability of the domain to do so can be limited 2002 if the same key, for scalability reasons, is used to sign messages 2003 for many other users. Mechanisms for explicitly revoking keys on a 2004 per-address basis have been proposed but require further study as to 2005 their utility and the DNS load they represent. 2007 8.7 Intentionally malformed Key Records 2009 It is possible for an attacker to publish key records in DNS which 2010 are intentionally malformed, with the intent of causing a denial-of- 2011 service attack on a non-robust verifier implementation. The attacker 2012 could then cause a verifier to read the malformed key record by 2013 sending a message to one of its users referencing the malformed 2014 record in a (not necessarily valid) signature. Verifiers MUST 2015 thoroughly verify all key records retrieved from DNS and be robust 2016 against intentionally as well as unintentiionally malformed key 2017 records. 2019 8.8 Intentionally Malformed DKIM-Signature header fields 2021 Verifiers MUST be prepared to receive messages with malformed DKIM- 2022 Signature header fields, and thoroughly verify the header field 2023 before depending on any of its contents. 2025 8.9 Information Leakage 2027 An attacker could determine when a particular signature was verified 2028 by using a per-message selector and then monitoring their DNS traffic 2029 for the key lookup. This would act as the equivalent of a "web bug" 2030 for verification time rather than when the message was read. 2032 9. References 2034 9.1 Normative References 2036 [ID-DKIM-RR] 2037 "DKIM Key Resource Records (To be written)", 2038 draft-dkim-dkk-rr-xx (work in progress), 2005. 2040 [ID-SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 2041 (SHA and HMAC-SHA)", draft-eastlake-sha2-02 (work in 2042 progress), January 2006. 2044 [OPENSSL] Team, C&D., "OpenSSL Documents", 2045 http://www.openssl.org/docs/, 2047 . 2049 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 2050 Mail: Part I: Message Encryption and Authentication 2051 Procedures", RFC 1421, February 1993. 2053 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2054 Extensions (MIME) Part One: Format of Internet Message 2055 Bodies", RFC 2045, November 1996. 2057 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2058 Part Three: Message header field Extensions for Non-ASCII 2059 Text", RFC 2047, November 1996. 2061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2062 Requirement Levels", BCP 14, RFC 2119, March 1997. 2064 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2065 April 2001. 2067 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2068 April 2001. 2070 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2071 Standards (PKCS) #1: RSA Cryptography Specifications 2072 Version 2.1", RFC 3447, February 2003. 2074 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 2075 Profile for Internationalized Domain Names (IDN)", 2076 RFC 3491, March 2003. 2078 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2079 Specifications: ABNF", RFC 4234, October 2005. 2081 9.2 Informative References 2083 [ID-AUTH-RES] 2084 Kucherawy, M., "Message header field for Indicating Sender 2085 Authentication Status", 2086 draft-kucherawy-sender-auth-header-02 (work in progress), 2087 May 2005. 2089 [ID-DKIM-THREATS] 2090 Fenton, J., "Analysis of Threats Motivating DomainKeys 2091 Identified Mail (DKIM)", draft-fenton-dkim-threats-02 2092 (work in progress), December 2005. 2094 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 2095 "Security Multiparts for MIME: Multipart/Signed and 2096 Multipart/Encrypted", RFC 1847, October 1995. 2098 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 2099 "OpenPGP Message Format", RFC 2440, November 1998. 2101 [RFC3766] "", 2005. 2103 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2104 Name System (DNS)", RFC 3833, August 2004. 2106 [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", 2107 RFC 3851, June 1999. 2109 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2110 Rose, "DNS Security Introduction and Requirements", 2111 RFC 4033, March 2005. 2113 Authors' Addresses 2115 Eric Allman 2116 Sendmail, Inc. 2117 6425 Christie Ave, Suite 400 2118 Emeryville, CA 94608 2119 USA 2121 Phone: +1 510 594 5501 2122 Email: eric+dkim@sendmail.org 2123 URI: 2125 Jon Callas 2126 PGP Corporation 2127 3460 West Bayshore 2128 Palo Alto, CA 94303 2129 USA 2131 Phone: +1 650 319 9016 2132 Email: jon@pgp.com 2133 Mark Delany 2134 Yahoo! Inc 2135 701 First Avenue 2136 Sunnyvale, CA 95087 2137 USA 2139 Phone: +1 408 349 6831 2140 Email: markd+dkim@yahoo-inc.com 2141 URI: 2143 Miles Libbey 2144 Yahoo! Inc 2145 701 First Avenue 2146 Sunnyvale, CA 95087 2147 USA 2149 Email: mlibbeymail-mailsig@yahoo.com 2150 URI: 2152 Jim Fenton 2153 Cisco Systems, Inc. 2154 MS SJ-24/2 2155 170 W. Tasman Drive 2156 San Jose, CA 95134-1706 2157 USA 2159 Phone: +1 408 526 5914 2160 Email: fenton@cisco.com 2161 URI: 2163 Michael Thomas 2164 Cisco Systems, Inc. 2165 MS SJ-9/2 2166 170 W. Tasman Drive 2167 San Jose, CA 95134-1706 2169 Phone: +1 408 525 5386 2170 Email: mat@cisco.com 2172 Appendix A. Example of Use (INFORMATIVE) 2174 This section shows the complete flow of an email from submission to 2175 final delivery, demonstrating how the various components fit 2176 together. 2178 A.1 The user composes an email 2180 From: Joe SixPack 2181 To: Suzie Q 2182 Subject: Is dinner ready? 2183 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2184 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2186 Hi. 2188 We lost the game. Are you hungry yet? 2190 Joe. 2192 A.2 The email is signed 2194 This email is signed by the example.com outbound email server and now 2195 looks like this: 2197 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2198 c=simple; q=dns; i=joe@football.example.com; 2199 h=Received : From : To : Subject : Date : Message-ID; 2200 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2201 VoG4ZHRNiYzR; 2202 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2203 by submitserver.example.com with SUBMISSION; 2204 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2205 From: Joe SixPack 2206 To: Suzie Q 2207 Subject: Is dinner ready? 2208 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2209 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2211 Hi. 2213 We lost the game. Are you hungry yet? 2215 Joe. 2217 The signing email server requires access to the private-key 2218 associated with the "brisbane" selector to generate this signature. 2220 A.3 The email signature is verified 2222 The signature is normally verified by an inbound SMTP server or 2223 possibly the final delivery agent. However, intervening MTAs can 2224 also perform this verification if they choose to do so. The 2225 verification process uses the domain "example.com" extracted from the 2226 "d=" tag and the selector "brisbane" from the "s=" tag in the "DKIM- 2227 Signature" header field to form the DNS DKIM query for: 2229 brisbane._dkim.example.com 2231 Signature verification starts with the physically last "Received" 2232 header field, the "From" header field, and so forth, in the order 2233 listed in the "h=" tag. Verification follows with a single CRLF 2234 followed by the body (starting with "Hi."). The email is canonically 2235 prepared for verifying with the "simple" method. The result of the 2236 query and subsequent verification of the signature is stored in the 2237 "Authentication-Results" header field line. After successful 2238 verification, the email looks like this: 2240 Authentication-Results: shopping.example.net 2241 header.from=joe@football.example.com; dkim=pass 2242 Received: from mout23.football.example.com (192.168.1.1) 2243 by shopping.example.net with SMTP; 2244 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2245 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2246 c=simple; q=dns; i=joe@football.example.com; 2247 h=Received : From : To : Subject : Date : Message-ID; 2248 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2249 VoG4ZHRNiYzR 2250 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2251 by submitserver.example.com with SUBMISSION; 2252 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2253 From: Joe SixPack 2254 To: Suzie Q 2255 Subject: Is dinner ready? 2256 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2257 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2259 Hi. 2261 We lost the game. Are you hungry yet? 2263 Joe. 2265 Appendix B. Usage Examples (INFORMATIVE) 2267 Studies in this appendix are for informational purposes only. In no 2268 case should these examples be used as guidance when creating an 2269 implementation. 2271 B.1 Simple Message Forwarding 2273 In some cases the recipient may request forwarding of email messages 2274 from the original address to another, through the use of a Unix 2275 .forward file or equivalent. In this case messages are typically 2276 forwarded without modification, except for the addition of a Received 2277 header field to the message and a change in the Envelope-to address. 2278 In this case, the eventual recipient should be able to verify the 2279 original signature since the signed content has not changed, and 2280 attribute the message correctly. 2282 B.2 Outsourced Business Functions 2284 Outsourced business functions represent a use case that motivates the 2285 need for selectors (the "s=" signature tag) and granularity (the "g=" 2286 key tag). Examples of outsourced business functions are legitimate 2287 email marketing providers and corporate benefits providers. In 2288 either case, the outsourced function would like to be able to send 2289 messages using the email domain of the client company. At the same 2290 time, the client may be reluctant to register a key for the provider 2291 that grants the ability to send messages for any address in the 2292 domain. 2294 The outsourcing company can generate a keypair and the client company 2295 can register the public key using a unique selector for a specific 2296 address such as winter-promotions@example.com by specifying a 2297 granularity of "g=winter-promotions" or "g=*-promotions" (to allow a 2298 range of addresses). This would enable the provider to send messages 2299 using that specific address and have them verify properly. The 2300 client company retains control over the email address because it 2301 retains the ability to revoke the key at any time. 2303 B.3 PDAs and Similar Devices 2305 PDAs are one example of the use of multiple keys per user. Suppose 2306 that John Doe wanted to be able to send messages using his corporate 2307 email address, jdoe@example.com, and the device did not have the 2308 ability to make a VPN connection to the corporate network. If the 2309 device was equipped with a private key registered for 2310 jdoe@example.com by the administrator of that domain, and appropriate 2311 software to sign messages, John could send signed messages through 2312 the outgoing network of the PDA service provider. 2314 B.4 Mailing Lists 2316 There is a wide range of behavior in forwarders and mailing lists 2317 (collectively called "forwarders" below), ranging from those which 2318 make no modification to the message itself (other than to add a 2319 Received header field and change the envelope information) to those 2320 which may add header fields, change the Subject header field, add 2321 content to the body (typically at the end), or reformat the body in 2322 some manner. 2324 Forwarders which do not modify the body or signed header fields of a 2325 message with a valid signature may re-sign the message as described 2326 below. 2328 Forwarders which make any modification to a message that could result 2329 in its signature becoming invalid should sign or re-sign using an 2330 appropriate identification (e.g., mailing-list-name@example.net). 2331 Since in so doing the (re-)signer is taking responsibility for the 2332 content of the message, modifying forwarders may elect to forward or 2333 re-sign only for messages which were received with valid signatures 2334 or other indications that the messages being signed are not spoofed. 2336 Forwarders which wish to re-sign a message must apply a Sender header 2337 field to the message to identify the address being used to sign the 2338 message and must remove any preexisting Sender header field as 2339 required by [RFC2822]. The forwarder applies a new DKIM-Signature 2340 header field with the signature, public key, and related information 2341 of the forwarder. 2343 B.5 Affinity Addresses 2345 "Affinity addresses" are email addresses that users employ to have an 2346 email address that is independent of any changes in email service 2347 provider they may choose to make. They are typically associated with 2348 college alumni associations, professional organizations, and 2349 recreational organizations with which they expect to have a long-term 2350 relationship. These domains usually provide forwarding of incoming 2351 email, but (currently) usually depend on the user to send outgoing 2352 messages through their own service provider's MTA. They usually have 2353 an aassociated Web application which authenticates the user and allows 2354 the forwarding address to be changed. 2356 With DKIM, affinity domains could use the Web application to allow 2357 users to register their own public keys to be used to sign messages 2358 on behalf of their affinity address. This is another application 2359 that takes advantage of user-level keying, and domains used for 2360 affinity addresses would typically have a very large number of user- 2361 level keys. Alternatively, the affinity domain could handle outgoing 2362 mail, operating a mail submission agent that authenticates users 2363 before accepting and signing messages for them. This is of course 2364 dependent on the user's service provider not blocking the relevant 2365 TCP ports used for mail submission. 2367 B.6 Third-party Message Transmission 2369 Third-party message transmission refers to the authorized sending of 2370 mail by an Internet application on behalf of a user. For example, a 2371 website providing news may allow the reader to forward a copy of the 2372 message to a friend; this is typically done using the reader's email 2373 address. This is sometimes referred to as the "Evite problem", named 2374 after the website of the same name that allows a user to send 2375 invitations to friends. 2377 One way this can be handled is to continue to put the reader's email 2378 address in the From field of the message, but put an address owned by 2379 the site into the Sender field, and sign the message on behalf of the 2380 Sender. A verifying MTA should accept this and rewrite the From 2381 field to indicate the address that was verified, i.e., From: John 2382 Doe via news@news-site.com . 2384 Appendix C. Creating a public key (INFORMATIVE) 2386 XXX Update to 1024 bit key and SHA-256 and adjust examples 2387 accordingly. XXX 2389 The default signature is an RSA signed SHA1 digest of the complete 2390 email. For ease of explanation, the openssl command is used to 2391 describe the mechanism by which keys and signatures are managed. One 2392 way to generate a 768 bit private-key suitable for DKIM, is to use 2393 openssl like this: 2395 $ openssl genrsa -out rsa.private 768 2397 This results in the file rsa.private containing the key information 2398 similar to this: 2400 -----BEGIN RSA PRIVATE KEY----- 2401 MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 2402 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo 2403 AUsFUq+J6+OpprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH 2404 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn 2405 Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 2406 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew 2407 ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs 2408 FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb 2409 weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 2410 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= 2411 -----END RSA PRIVATE KEY----- 2413 To extract the public-key component from the private-key, use openssl 2414 like this: 2416 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 2418 This results in the file rsa.public containing the key information 2419 similar to this: 2421 -----BEGIN PUBLIC KEY----- 2422 MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l 2423 MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E 2424 XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB 2425 -----END PUBLIC KEY----- 2427 This public-key data (without the BEGIN and END tags) is placed in 2428 the DNS. With the signature, canonical email contents and public 2429 key, a verifying system can test the validity of the signature. The 2430 openssl invocation to verify a signature looks like this: 2432 openssl dgst -verify rsa.public -sha1 -signature signature.file \ 2433 . 2469 Appendix E. Edit History 2471 [[This section to be removed before publication.]] 2473 E.1 Changes since -ietf-00 version 2475 The following changes were made between draft-ietf-dkim-base-00 and 2476 draft-ietf-dkim-base-01: 2478 o Added section 8.9 (Information Leakage). 2480 o Replace section 4 (Multiple Signatures) with much less vague text. 2482 o Fixed ABNF for base64string. 2484 o Added rsa-sha256 signing algorithm. 2486 o Expanded several examples. 2488 o Changed signing algorithm to use separate hash of the body of the 2489 message; this is represented as the "bh=" tag in the DKIM- 2490 Signature header field. 2492 o Changed "z=" tag so that it need not have the same header field 2493 names as the "h=" tag. 2495 o Significant wordsmithing. 2497 E.2 Changes since -allman-01 version 2499 The following changes were made between draft-allman-dkim-base-01 and 2500 draft-ietf-dkim-base-00: 2502 o Remove references to Sender Signing Policy document. Such 2503 consideration is implicitly included in Section 6.5. 2505 o Added ABNF for all tags. 2507 o Updated references (still includes some references to expired 2508 drafts, notably [ID-AUTH-RES]. 2510 o Significant wordsmithing. 2512 E.3 Changes since -allman-00 version 2514 The following changes were made between draft-allman-dkim-base-00 and 2515 draft-allman-dkim-base-01: 2517 o Changed "c=" tag to separate out header from body 2518 canonicalization. 2520 o Eliminated "nowsp" canonicalization in favor of "relaxed", which 2521 is somewhat less relaxed (but more secure) than "nowsp". 2523 o Moved the (empty) Compliance section to the Sender Signing Policy 2524 document. 2526 o Added several IANA Considerations. 2528 o Fixed a number of grammar and formatting errors. 2530 Intellectual Property Statement 2532 The IETF takes no position regarding the validity or scope of any 2533 Intellectual Property Rights or other rights that might be claimed to 2534 pertain to the implementation or use of the technology described in 2535 this document or the extent to which any license under such rights 2536 might oor might not be available; nor does it represent that it has 2537 made any independent effort to identify any such rights. Information 2538 on the procedures with respect to rights in RFC documents can be 2539 found in BCP 78 and BCP 79. 2541 Copies of IPR disclosures made to the IETF Secretariat and any 2542 assurances of licenses to be made available, or the result of an 2543 attempt made to obtain a general license or permission for the use of 2544 such proprietary rights by implementers or users of this 2545 specification can be obtained from the IETF on-line IPR repository at 2546 http://www.ietf.org/ipr. 2548 The IETF invites any interested party to bring to its attention any 2549 copyrights, patents or patent applications, or other proprietary 2550 rights that may cover technology that may be required to implement 2551 this standard. Please address the information to the IETF at 2552 ietf-ipr@ietf.org. 2554 The IETF has been notified of intellectual property rights claimed in 2555 regard to some or all of the specification contained in this 2556 document. For more information consult the online list of claimed 2557 rights. 2559 Disclaimer of Validity 2561 This document and the information contained herein are provided on an 2562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2569 Copyright Statement 2571 Copyright (C) The Internet Society (2006). This document is subject 2572 to the rights, licenses and restrictions contained in BCP 78, and 2573 except as set forth therein, the authors retain all their rights. 2575 Acknowledgment 2577 Funding for the RFC Editor function is currently provided by the 2578 Internet Society.