idnits 2.17.1 draft-ietf-dkim-base-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2403. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1072 has weird spacing: '... email elec...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2006) is 6656 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 814, but not defined == Missing Reference: 'MIME' is mentioned on line 2319, but not defined == Unused Reference: 'ID-SHA' is defined on line 1927, but no explicit reference was found in the text == Unused Reference: 'OPENSSL' is defined on line 1931, but no explicit reference was found in the text == Unused Reference: 'RFC1421' is defined on line 1935, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 1960, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-02 -- 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) -- 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: 10 errors (**), 0 flaws (~~), 10 warnings (==), 13 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: August 6, 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 February 2, 2006 14 DomainKeys Identified Mail Signatures (DKIM) 15 draft-ietf-dkim-base-00 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 6, 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 Format for DKIM header fields . . . . . . . . . 10 82 3.3 Signing and Verification Algorithms . . . . . . . . . . . 10 83 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 12 84 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 16 85 3.6 Key Management and Representation . . . . . . . . . . . . 22 86 3.7 Computing the Message Hash . . . . . . . . . . . . . . . . 26 87 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 28 88 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 28 89 5.1 Determine if the Email Should be Signed and by Whom . . . 29 90 5.2 Select a private-key and corresponding selector 91 information . . . . . . . . . . . . . . . . . . . . . . . 29 92 5.3 Normalize the Message to Prevent Transport Conversions . . 29 93 5.4 Determine the header fields to Sign . . . . . . . . . . . 30 94 5.5 Compute the Message Hash . . . . . . . . . . . . . . . . . 32 95 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 32 96 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 33 97 6.1 Extract the Signature from the Message . . . . . . . . . . 33 98 6.2 Get the Public Key . . . . . . . . . . . . . . . . . . . . 34 99 6.3 Compute the Verification . . . . . . . . . . . . . . . . . 35 100 6.4 Insert the Authentication-Results Header Field . . . . . . 36 101 6.5 Interpret Results/Apply Local Policy . . . . . . . . . . . 37 102 6.6 MUA Considerations . . . . . . . . . . . . . . . . . . . . 38 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 105 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 39 106 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 40 107 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 41 108 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 41 109 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 42 110 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 42 111 8.7 Intentionally malformed Key Records . . . . . . . . . . . 42 112 8.8 Intentionally Malformed DKIM-Signature header fields . . . 43 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 9.1 Normative References . . . . . . . . . . . . . . . . . . . 43 115 9.2 Informative References . . . . . . . . . . . . . . . . . . 44 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 117 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . . 46 118 A.1 The user composes an email . . . . . . . . . . . . . . . . 46 119 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 46 120 A.3 The email signature is verified . . . . . . . . . . . . . 47 121 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . . 48 122 B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 48 123 B.2 Outsourced Business Functions . . . . . . . . . . . . . . 48 124 B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 49 125 B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 49 126 B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 50 127 B.6 Third-party Message Transmission . . . . . . . . . . . . . 50 128 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . . 51 129 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 130 E. Edit History . . . . . . . . . . . . . . . . . . . . . . . . . 52 131 E.1 Changes since -allman-01 version . . . . . . . . . . . . . 52 132 E.2 Changes since -allman-00 version . . . . . . . . . . . . . 53 133 Intellectual Property and Copyright Statements . . . . . . . . 54 135 1. Introduction 137 1.1 Overview 139 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 140 messages can be cryptographically signed, permitting a signing domain 141 to claim responsibility for the introduction of a message into the 142 mail stream. Message recipients can verify the signature by querying 143 the signer's domain directly to retrieve the appropriate public key, 144 and thereby confirm that the message was attested to by a party in 145 possession of the private key for the signing domain. 147 The approach taken by DKIM differs from previous approaches to 148 message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: 150 o the message signature is written to the message header fields so 151 that neither human recipients nor existing MUA (Mail User Agent) 152 software are confused by signature-related content appearing in 153 the message body, 155 o there is no dependency on public and private key pairs being 156 issued by well-known, trusted certificate authorities, 158 o there is no dependency on the deployment of any new Internet 159 protocols or services for public key distribution or revocation, 161 o it makes no attempt to include encryption as part of the 162 mechanism. 164 DKIM: 166 o is transparent to and compatible with the existing email 167 infrastructure 169 o requires minimal new infrastructure 171 o can be implemented independently of clients in order to reduce 172 deployment time 174 o does not require the use of a trusted third party (such as a 175 certificate authority or other entity) which might impose 176 significant costs or introduce delays to deployment 178 o can be deployed incrementally 180 o allows delegation of signing to third parties. 182 A "selector" mechanism allows multiple keys per domain, including 183 delegation of the right to authenticate a portion of the namespace to 184 a trusted third party. 186 1.2 Signing Identity 188 DKIM separates the question of the signer of the message from the 189 purported author of the message. In particular, a signature includes 190 the identity of the signer. Recipients can use the signing 191 information to decide how they want to process the message. 193 INFORMATIVE RATIONALE: The signing address associated with a DKIM 194 signature is not required to match a particular header field 195 because of the broad methods of interpretation by recipient mail 196 systems, including MUAs. 198 1.3 Scalability 200 The email identification problem is characterized by extreme 201 scalability requirements. There are currently over 70 million 202 domains and a much larger number of individual addresses. It is 203 important to preserve the positive aspects of the current email 204 infrastructure, such as the ability for anyone to communicate with 205 anyone else without introduction. 207 1.4 Simple Key Management 209 DKIM differs from traditional hierarchical public-key systems in that 210 no key signing infrastructure is required; the verifier requests the 211 public key from the claimed signer directly. 213 The DNS is proposed as the initial mechanism for publishing public 214 keys. DKIM is designed to be extensible to other key fetching 215 services as they become available. 217 2. Terminology and Definitions 219 This section defines terms used in the rest of the document. Syntax 220 descriptions use the form described in Augmented BNF for Syntax 221 Specifications [RFC4234]. 223 2.1 Signers 225 Elements in the mail system that sign messages are referred to as 226 signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission 227 Agents), MTAs (Mail Transfer Agents), or other agents such as mailing 228 list exploders. In general any signer will be involved in the 229 injection of a message into the message system in some way. The key 230 issue is that a message must be signed before it leaves the 231 administrative domain of the signer. 233 2.2 Verifiers 235 Elements in the mail system that verify signatures are referred to as 236 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 237 In most cases it is expected that verifiers will be close to an end 238 user (reader) of the message or some consuming agent such as a 239 mailing list exploder. 241 2.3 White Space 243 There are three forms of white space: 245 o WSP represents simple white space, i.e., a space or a tab 246 character, and is inherited from[RFC2822]. 248 o SWSP is streaming white space; it adds the CR and LF characters. 250 o FWS, also from [RFC2822], is folding white space. It allows 251 multiple lines separated by CRLF followed by at least one white 252 space, to be joined. 254 The formal ABNF for SWSP is: 256 SWSP = CR / LF / WSP ; streaming white space 258 2.4 Common ABNF Tokens 260 The following ABNF tokens are used elsewhere in this document. 262 hyphenated-word = ALPHA *(ALPHA / DIGIT / "-") 263 base64string = 1*(ALPHA / DIGIT / "+" / "/" / SWSP) 265 2.5 Imported ABNF Tokens 267 The following tokens are imported from other RFCs as noted. Those 268 RFCs should be considered definitive. However, all tokens having 269 names beginning with "obs-" should be excluded from this import. 271 The following tokens are imported from [RFC2821]: 273 o Local-part (implementation warning: this permits quoted strings) 275 o Domain (implementation warning: this permits address-literals) 277 o sub-domain 279 The following definitions are imported from [RFC2822]: 281 o WSP (space or tab) 283 o FWS (folding white space) 285 o field-name (name of a header field) 287 o dot-atom (in the local-part of an email address) 289 The following tokens are imported from [RFC2045]: 291 o qp-section (a single line of quoted-printable-encoded text) 293 Other tokens not defined herein are imported from [RFC4234]. These 294 are intuitive primitives such as SP, ALPHA, CRLF, etc. 296 3. Protocol Elements 298 Protocol Elements are conceptual parts of the protocol that are not 299 specific to either signers or verifiers. The protocol descriptions 300 for signers and verifiers are described in later sections (Signer 301 Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This 302 section must be read in the context of those sections. 304 3.1 Selectors 306 To support multiple concurrent public keys per signing domain, the 307 key namespace is subdivided using "selectors". For example, 308 selectors might indicate the names of office locations (e.g., 309 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 310 (e.g., "january2005", "february2005", etc.), or even the individual 311 user. 313 INFORMATIVE IMPLEMENTERS' NOTE: reusing a selector with a new key 314 (for example, changing the key associated with a user's name) 315 makes it impossible to tell the difference between a message that 316 didn't verify because the key is no longer valid versus a message 317 that is actually forged. Signers should not change the key 318 associated with a selector. When creating a new key, signers 319 should associate it with a new selector. 321 Selectors are needed to support some important use cases. For 322 example: 324 o Domains which want to delegate signing capability for a specific 325 address for a given duration to a partner, such as an advertising 326 provider or other outsourced function. 328 o Domains which want to allow frequent travelers to send messages 329 locally without the need to connect with a particular MSA. 331 o "Affinity" domains (e.g., college alumni associations) which 332 provide forwarding of incoming mail but which do not operate a 333 mail submission agent for outgoing mail. 335 Periods are allowed in selectors and are component separators. If 336 keys are stored in DNS, the period defines sub-domain boundaries. 337 Sub-selectors might be used to combine dates with locations; for 338 example, "march2005.reykjavik". This can be used to allow delegation 339 of a portion of the selector name-space. 341 ABNF: 342 selector = sub-domain *( "." sub-domain ) 344 The number of public keys and corresponding selectors for each domain 345 are determined by the domain owner. Many domain owners will be 346 satisfied with just one selector whereas administratively distributed 347 organizations may choose to manage disparate selectors and key pairs 348 in different regions or on different email servers. 350 Beyond administrative convenience, selectors make it possible to 351 seamlessly replace public keys on a routine basis. If a domain 352 wishes to change from using a public key associated with selector 353 "january2005" to a public key associated with selector 354 "february2005", it merely makes sure that both public keys are 355 advertised in the public-key repository concurrently for the 356 transition period during which email may be in transit prior to 357 verification. At the start of the transition period, the outbound 358 email servers are configured to sign with the "february2005" private- 359 key. At the end of the transition period, the "january2005" public 360 key is removed from the public-key repository. 362 While some domains may wish to make selector values well known, 363 others will want to take care not to allocate selector names in a way 364 that allows harvesting of data by outside parties. E.g., if per-user 365 keys are issued, the domain owner will need to make the decision as 366 to whether to make this selector associated directly with the user 367 name, or make it some unassociated random value, such as the 368 fingerprint of the public key. 370 3.2 Tag=Value Format for DKIM header fields 372 DKIM uses a simple "tag=value" syntax in several contexts, including 373 in messages, domain signature records, and policy records. 375 Values are a series of strings containing either base64 text, plain 376 text, or quoted printable text, as defined in [RFC2045], section 6.7. 377 The name of the tag will determine the encoding of each value; 378 however, no encoding may include the semicolon (";") character, since 379 that separates tag-specs. 381 Formally, the syntax rules are: 382 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 383 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 384 tag-name = ALPHA 0*ALNUMPUNC 385 tag-value = *VALCHAR ; SWSP prohibited at beginning and end 386 VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 387 ; HTAB and SP to TILDE except SEMICOLON 388 ALNUMPUNC = ALPHA / DIGIT / "_" 390 Note that WSP is allowed anywhere around tags; in particular, WSP 391 between the tag-name and the "=", and any WSP before the terminating 392 ";" is not part of the value. 394 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 395 processed as case sensitive unless the specific tag description of 396 semantics specifies case insensitivity. 398 Tags with duplicate names MUST NOT be specified within a single tag- 399 list. 401 Whitespace within a value MUST be retained unless explicitly excluded 402 by the specific tag description. 404 Tag=value pairs that represent the default value MAY be included to 405 aid legibility. 407 Unrecognized tags MUST be ignored. 409 Tags that have an empty value are not the same as omitted tags. An 410 omitted tag is treated as having the default value; a tag with an 411 empty value explicitly designates the empty string as the value. For 412 example, "g=" does not mean "g=*", even though "g=*" is the default 413 for that tag. 415 3.3 Signing and Verification Algorithms 417 DKIM supports multiple key signing/verification algorithms. The only 418 algorithm defined by this specification at this time is rsa-sha1, 419 which is the default if no algorithm is specified and which MUST be 420 supported by all implementations. 422 3.3.1 The rsa-sha1 Signing Algorithm 424 The rsa-sha1 Signing Algorithm computes a SHA-1 hash of the message 425 header field and body as described in Section 3.7 below. That hash 426 is then encrypted by the signer using the RSA algorithm (actually 427 PKCS#1 version 1.5 [RFC3447]) and the signer's private key. The hash 428 MUST NOT be truncated or converted into any form other than the 429 native binary form before being signed. 431 More formally, the algorithm for the signature using rsa-sha1 is: 432 RSA(SHA1(canon_message || DKIM-SIG), key) 434 where canon_message is the canonicalized message header and body as 435 defined in Section 3.4 and DKIM-SIG is the canonicalized DKIM- 436 Signature header field sans the signature value itself. 438 3.3.2 Other algorithms 440 Other algorithms MAY be defined in the future. Verifiers MUST ignore 441 any signatures using algorithms that they do not understand. 443 3.3.3 Key sizes 445 Selecting appropriate key sizes is a trade-off between cost, 446 performance and risk. All implementations MUST support keys of sizes 447 512, 768, 1024, 1536 and 2048 bits and MAY support larger keys. 449 Factors that should influence the key size choice include: 451 o The practical constraint that a 2048 bit key is the largest key 452 that fits within a 512 byte DNS UDP response packet 454 o The security constraint that keys smaller than 1024 bits are 455 subject to brute force attacks. 457 o Larger keys impose higher CPU costs to verify and sign email 459 o Keys can be replaced on a regular basis, thus their lifetime can 460 be relatively short 462 o The security goals of this specification are modest compared to 463 typical goals of public-key systems 465 3.4 Canonicalization 467 Empirical evidence demonstrates that some mail servers and relay 468 systems modify email in transit, potentially invalidating a 469 signature. There are two competing perspectives on such 470 modifications. For most signers, mild modification of email is 471 immaterial to the authentication status of the email. For such 472 signers a canonicalization algorithm that survives modest in-transit 473 modification is preferred. 475 Other signers demand that any modification of the email, however 476 minor, result in an authentication failure. These signers prefer a 477 canonicalization algorithm that does not tolerate in-transit 478 modification of the signed email. 480 Some signers may be willing to accept modifications to header fields 481 that are within the bounds of email standards such as [RFC2822], but 482 are unwilling to accept any modification to the body of messages. 484 To satisfy all requirements, two canonicalization algorithms are 485 defined for each of the header and the body: a "simple" algorithm 486 that tolerates almost no modification and a "relaxed" algorithm that 487 tolerates common modifications such as white-space replacement and 488 header field line re-wrapping. A signer MAY specify either algorithm 489 for header or body when signing an email. If no canonicalization 490 algorithm is specified by the signer, the "simple" algorithm defaults 491 for both header and body. A verifier MUST be able to process email 492 using either canonicalization algorithm. Further canonicalization 493 algorithms MAY be defined in the future; verifiers MUST ignore any 494 signatures that use unrecognized canonicalization algorithms. 496 In all cases, the header fields of the message are presented to the 497 signing algorithm first in the order indicated by the signature 498 header field and canonicalized using the indicated algorithm. Only 499 header fields listed as signed in the signature header field are 500 included. The CRLF separating the header field from the body is then 501 presented, followed by the canonicalized body. Note that the header 502 and body may use different canonicalization algorithms. 504 Canonicalization simply prepares the email for presentation to the 505 signing or verification algorithm. It MUST NOT change the 506 transmitted data in any way. Canonicalization of header fields and 507 body are described below. 509 NOTE: This section assumes that the message is already in "network 510 normal" format (e.g., text is ASCII encoded, lines are separated with 511 CRLF characters, etc.). See also Section 5.3 for information about 512 normalizing the message. 514 3.4.1 The "simple" Header Field Canonicalization Algorithm 516 The "simple" header canonicalization algorithm does not change header 517 fields in any way. Header fields MUST be presented to the signing or 518 verification algorithm exactly as they are in the message being 519 signed or verified. In particular, header field names MUST NOT be 520 case folded. 522 3.4.2 The "relaxed" Header Field Canonicalization Algorithm 524 The "relaxed" header canonicalization algorithm MUST apply the 525 following steps in order: 527 o Convert all header field names (not the header field values) to 528 lower case. For example, convert "SUBJect: AbC" to "subject: 529 AbC". 531 o Unfold all header field continuation lines as described in 532 [RFC2822]; in particular, lines with terminators embedded in 533 continued header field values (that is, CRLF sequences followed by 534 WSP) MUST be interpreted without the CRLF. Implementations MUST 535 NOT remove the CRLF at the end of the header field value. 537 o Convert all sequences of one or more WSP characters to a single SP 538 character. WSP characters here include those before and after a 539 line folding boundary. 541 o Delete all WSP characters at the end of each unfolded header field 542 value. 544 o Delete any WSP characters remaining before and after the colon 545 separating the header field name from the header field value. The 546 colon separator MUST be retained. 548 [NON-NORMATIVE DOCUMENTATION NOTE: The only difference between 549 "relaxed" header field canonicalization and "nowsp" listed in the 550 previous version of this draft is that nowsp reduces all strings 551 of streaming white space to zero characters while "relaxed" 552 reduces strings of white space to one space.] 554 3.4.3 The "simple" Body Canonicalization Algorithm 556 The "simple" body canonicalization algorithm ignores all empty lines 557 at the end of the message body. An empty line is a line of zero 558 length after removal of the line terminator. It makes no other 559 changes to the message body. In more formal terms, the "simple" body 560 canonicalization algorithm reduces "CRLF 0*CRLF" to a single "CRLF" 561 at the end of the body. 563 3.4.4 The "relaxed" Body Canonicalization Algorithm 565 [[This section may be deleted; see discussion below.]] The "relaxed" 566 body canonicalization algorithm: 568 o Ignores all white space at the end of lines. Implementations MUST 569 NOT remove the CRLF at the end of the line. 571 o Reduces all sequences of WSP within a line to a single SP 572 character. 574 o Ignores all empty lines at the end of the message body. "Empty 575 line" is defined in Section 3.4.3. 577 [[NON-NORMATIVE DISCUSSION: The authors are undecided whether to 578 leave the "relaxed" body canonicalization algorithm in to the 579 specification or delete it entirely. We believe that for the vast 580 majority of cases, the "simple" body canonicalization algorithm 581 should be sufficient. We simply do not have enough data to know 582 whether retain the "relaxed" body canonicalization algorithm or 583 not.]] 585 3.4.5 Body Length Limits 587 A body length count MAY be specified to limit the signature 588 calculation to an initial prefix of the body text. If the body 589 length count is not specified then the entire message body is signed 590 and verified. 592 INFORMATIVE IMPLEMENTATION NOTE: Body length limits could be 593 useful in increasing signature robustness when sending to a 594 mailing list that both appends to content sent to it and does not 595 sign its messages. However, using such limits enables an attack 596 in which a sender with malicious intent modifies a message to 597 include content that solely benefits the attacker. It is possible 598 for the appended content to completely replace the original 599 content in the end recipient's eyes and to defeat duplicate 600 message detection algorithms. To avoid this attack, signers 601 should be wary of using this tag, and verifiers might wish to 602 ignore the tag or remove text that appears after the specified 603 content length. 605 The body length count allows the signer of a message to permit data 606 to be appended to the end of the body of a signed message. The body 607 length count is made following the canonicalization algorithm; for 608 example, any white space ignored by a canonicalization algorithm is 609 not included as part of the body length count. 611 INFORMATIVE RATIONALE: This capability is provided because it is 612 very common for mailing lists to add trailers to messages (e.g., 613 instructions how to get off the list). Until those messages are 614 also signed, the body length count is a useful tool for the 615 verifier since it may as a matter of policy accept messages having 616 valid signatures with extraneous data. 618 Signers of MIME messages that include a body length count SHOULD be 619 sure that the length extends to the closing MIME boundary string. 621 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 622 the only acceptable modifications are to add to the MIME postlude 623 would use a body length count encompassing the entire final MIME 624 boundary string, including the final "--CRLF". A signer wishing 625 to allow additional MIME parts but not modification of existing 626 parts would use a body length count extending through the final 627 MIME boundary string, omitting the final "--CRLF". 629 A body length count of zero means that the body is completely 630 unsigned. 632 Note that verifiers MAY choose to reject or truncate messages that 633 have body content beyond that specified by the body length count. 635 Signers wishing to ensure that no modification of any sort can occur 636 should specify the "simple" algorithm and omit the body length count. 638 3.4.6 Example 640 Assuming a "c=relaxes/relaxed" canonicalization algorithm, a message 641 reading: 642 A: X 643 B : Y 644 Z 645 646 C 647 D E 648 649 650 when canonicalized using "relaxed" for both header and body results 651 in: 653 a:X 654 b:YZ 655 656 C 657 DE 659 3.5 The DKIM-Signature header field 661 The signature of the email is stored in the "DKIM-Signature:" header 662 field. This header field contains all of the signature and key- 663 fetching data. The DKIM-Signature value is a tag-list as described 664 in Section 3.2. 666 The "DKIM-Signature:" header field SHOULD be treated as though it 667 were a trace header field as defined in section 3.6 of [RFC2822], and 668 hence SHOULD NOT be reordered and SHOULD be kept in blocks prepended 669 to the message. In particular, the "DKIM-Signature" header field 670 SHOULD precede the original email header fields presented to the 671 canonicalization and signature algorithms. 673 The "DKIM-Signature:" header field is always included in the 674 signature calculation, after the body of the message; however, when 675 calculating or verifying the signature, the b= (signature value) 676 value MUST be treated as though it were the null string. Unknown 677 tags MUST be signed but MUST be otherwise ignored by verifiers. 679 The encodings for each field type are listed below. Tags described 680 as quoted-printable are as described in section 6.7 of MIME Part One 681 [RFC2045], with the additional conversion of semicolon characters to 682 "=3B". 684 Tags on the DKIM-Signature header field along with their type and 685 requirement status are shown below. Valid tags are: 687 v= Version (MUST NOT be included). This tag is reserved for future 688 use to indicate a possible new, incompatible version of the 689 specification. It MUST NOT be included in the DKIM-Signature 690 header field. 692 ABNF: 694 sig-v-tag = 695 a= The algorithm used to generate the signature (plain-text; 696 REQUIRED). Signers and verifiers MUST support "rsa-sha1", an 697 RSA-signed SHA-1 digest. See Section 3.3 for a description of 698 algorithms. 700 INFORMATIVE RATIONALE: The authors understand that SHA-1 has 701 been theoretically compromised. However, viable attacks 702 require the attacker to choose both sets of input text; given 703 a preexisting input (a "preimaging" attack), it is still hard 704 to determine another input that produces an SHA-1 collision, 705 and the chance that such input would be of value to an 706 attacker is minimal. Also, there is broad library support 707 for SHA-1, whereas alternatives such as SHA-256 are just 708 emerging. Finally, DKIM is not intended to have legal- or 709 military-grade requirements. There is nothing inherent in 710 using SHA-1 here other than implementer convenience. See 711 712 for a discussion of the security issues. 714 ABNF: 716 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 717 sig-a-tag-alg = "rsa-sha1" / x-sig-a-tag-alg 718 x-sig-a-tag-alg = hyphenated-word ; for later extension 720 b= The signature data (base64; REQUIRED). Whitespace is ignored in 721 this value and MUST be ignored when re-assembling the original 722 signature. In particular, the signing process can safely insert 723 FWS in this value in arbitrary places to conform to line-length 724 limits. See Signer Actions (Section 5) for how the signature is 725 computed. 727 ABNF: 729 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 730 sig-b-tag-data = base64string 732 c= Body canonicalization (plain-text; OPTIONAL, default is "simple/ 733 simple"). This tag informs the verifier of the type of 734 canonicalization used to prepare the message for signing. It 735 consists of two names separated by a "slash" (%d47) character, 736 corresponding to the header and body canonicalization algorithms 737 respectively. These algorithms are described in Section 3.4. If 738 only one algorithm is named, that algorithm is used for the 739 header and "simple" is used for the body. For example, "relaxed" 740 is treated the same as "relaxed/simple". 742 ABNF: 744 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 745 ["/" sig-c-tag-alg] 746 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 747 x-sig-c-tag-alg = hyphenated-word ; for later extension 749 d= The domain of the signing entity (plain-text; REQUIRED). This 750 is the domain that will be queried for the public key. This 751 domain MUST be the same as or a parent domain of the "i=" tag. 752 When presented with a signature that does not meet this 753 requirement, verifiers MUST either ignore the signature or reject 754 the message. 756 ABNF: 758 sig-d-tag = %x64 [FWS] "=" [FWS] Domain 760 h= Signed header fields (plain-text, but see description; 761 REQUIRED). A colon-separated list of header field names that 762 identify the header fields presented to the signing algorithm. 763 The field MUST contain the complete list of header fields in the 764 order presented to the signing algorithm. The field MAY contain 765 names of header fields that do not exist when signed; nonexistent 766 header fields do not contribute to the signature computation 767 (that is, they are treated as the null input, including the 768 header field name, the separating colon, the header field value, 769 and any CRLF terminator), and when verified non-existent header 770 fields MUST be treated in the same way. The field MUST NOT 771 include the DKIM-Signature header field that is being created or 772 verified. Folding white space (FWS) MAY be included on either 773 side of the colon separator. Header field names MUST be compared 774 against actual header field names in a case insensitive manner. 776 ABNF: 778 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 779 0*( *FWS ":" *FWS hdr-name ) 780 hdr-name = field-name 782 INFORMATIVE EXPLANATION: By "signing" header fields that do 783 not actually exist, a signer can prevent insertion of those 784 header fields before verification. However, since a sender 785 cannot possibly know what header fields might be created in 786 the future, and that some MUAs might present header fields 787 that are embedded inside a message (e.g., as a message/rfc822 788 content type), the security of this solution is not total. 790 INFORMATIVE EXPLANATION: The exclusion of the header field 791 name and colon as well as the header field value for non- 792 existent header fields prevents an attacker from inserting an 793 actual header field with a null value. 795 i= Identity of the user or agent (e.g., a mailing list manager) on 796 behalf of which this message is signed (quoted-printable; 797 OPTIONAL, default is an empty local-part followed by an "@" 798 followed by the domain from the "d=" tag). The syntax is a 799 standard email address where the local-part is optional. If the 800 signing domain is unable or unwilling to commit to an individual 801 user name within their domain, the local-part of the address MUST 802 be omitted. If the local-part of the address is omitted or the 803 "i=" tag is not present, the key used to sign MUST be valid for 804 any address in the domain. The domain part of the address MUST 805 be the same as or a subdomain of the value of the "d=" tag. 807 ABNF: 809 sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" Domain 811 INFORMATIVE DISCUSSION: This document does not require the 812 value of the "i=" tag to match the identity in any message 813 header field fields. This is considered to be a verifier 814 policy issue, described in another document [XREF-TBD]. 815 Constraints between the value of the "i=" tag and other 816 identities in other header fields seek to apply basic 817 authentication into the semantics of trust associated with a 818 role such as content author. Trust is a broad and complex 819 topic and trust mechanisms are subject to highly creative 820 attacks. The real-world efficacy of any but the most basic 821 bindings between the "i=" value and other identities is not 822 well established, nor is its vulnerability to subversion by 823 an attacker. Hence reliance on the use of these options 824 should be strictly limited. In particular it is not at all 825 clear to what extent a typical end-user recipient can rely on 826 any assurances that might be made by successful use of the 827 "i=" options. 829 l= Body count (plain-text decimal integer; OPTIONAL, default is 830 entire body). This tag informs the verifier of the number of 831 bytes in the body of the email after canonicalization included in 832 the cryptographic hash, starting from 0 immediately following the 833 CRLF preceding the body. 835 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 836 allow display of fraudulent content without appropriate 837 warning to end users. The l= tag is intended for increasing 838 signature robustness when sending to mailing lists that both 839 modify their content and do not sign their messages. 840 However, using the l= tag enables man-in-the-middle attacks 841 in which an intermediary with malicious intent modifies a 842 message to include content that solely benefits the attacker. 843 It is possible for the appended content to completely replace 844 the original content in the end recipient's eyes and to 845 defeat duplicate message detection algorithms. Examples are 846 described in Security Considerations (Section 8). 848 To avoid this attack, signers should be extremely wary of 849 using this tag, and verifiers might wish to ignore the tag or 850 remove text that appears after the specified content length. 852 ABNF: 854 sig-l-tag = %x6c [FWS] "=" [FWS] 1*DIGIT 856 q= A colon-separated list of query methods used to retrieve the 857 public key (plain-text; OPTIONAL, default is "dns"). Each query 858 method is of the form "type[/options]", where the syntax and 859 semantics of the options depends on the type. If there are 860 multiple query mechanisms listed, the choice of query mechanism 861 MUST NOT change the interpretation of the signature. Currently 862 the only valid value is "dns" which defines the DNS lookup 863 algorithm described elsewhere in this document. No options are 864 defined for the "dns" query type, but the string "dns" MAY have a 865 trailing "/" character. Verifiers and signers MUST support 866 "dns". 868 INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on 869 "dns" allows for the possibility of adding options later and 870 makes it clear that matching of the query type must terminate 871 on either "/" or end of string. 873 ABNF: 875 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 876 *([FWS] ":" [FWS] sig-q-tag-method) 877 sig-q-tag-method = sig-q-tag-type ["/" sig-q-tag-args] 878 sig-q-tag-type = "dns" / x-sig-q-tag-type 879 x-sig-q-tag-type = hyphenated-word ; for future extension 880 x-sig-q-tag-args = qp-hdr-value 881 s= The selector subdividing the namespace for the "d=" (domain) tag 882 (plain-text; REQUIRED). 884 ABNF: 886 sig-s-tag = %x73 [FWS] "=" [FWS] Domain 888 t= Signature Timestamp (plain-text; RECOMMENDED, default is an 889 unknown creation time). The time that this signature was 890 created. The format is the standard Unix seconds-since-1970. 891 The value is expressed as an unsigned integer in decimal ASCII. 892 This value is not constrained to fit into a 31- or 32-bit 893 integer. Implementations SHOULD be prepared to handle values up 894 to at least 10^12 (until approximately AD 200,000; this fits into 895 40 bits). To avoid denial of service attacks, implementations 896 MAY consider any value longer than 12 digits to be infinite. 898 ABNF: 900 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 902 x= Signature Expiration (plain-text; RECOMMENDED, default is no 903 expiration). Signature expiration in seconds-since-1970 format 904 as an absolute date, not as a time delta from the signing 905 timestamp. Signatures MUST NOT be considered valid if the 906 current time at the verifier is past the expiration date. The 907 value is expressed as an unsigned integer in decimal ASCII, with 908 the same contraints on the value in the "t=" tag. 910 INFORMATIVE NOTE: The x= tag is not intended as an anti- 911 replay defense. 913 ABNF: 915 sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT 917 z= Copied header fields (plain-text, but see description; OPTIONAL, 918 default is null). A vertical-bar-separated list of header field 919 names and copies of header field values that identify the header 920 fields presented to the signing algorithm. The field MUST 921 contain the complete list of header fields in the order presented 922 to the signing algorithm. Copied header field values MUST 923 immediately follow the header field name with a colon separator 924 (no white space permitted). Header field values MUST be 925 represented as Quoted-Printable [RFC2045] with vertical bars, 926 colons, semicolons, and white space encoded in addition to the 927 usual requirements. 929 Verifiers MUST NOT use the copied header field values for 930 verification should they be present in the h= field. Copied 931 header field values are for forensic use only. 933 Header fields with characters requiring conversion (perhaps from 934 legacy MTAs which are not [RFC2822] compliant) SHOULD be 935 converted as described in MIME Part Three [RFC2047]. 937 ABNF: 938 sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy 939 *( [FWS] "|" sig-z-tag-copy ) 940 sig-z-tag-copy = hdr-name ":" [FWS] qp-hdr-value 941 qp-hdr-value = 943 ; needs to be updated with real definition 944 ; (could be messy) 946 INFORMATIVE EXAMPLE of a signature header field spread across 947 multiple continuation lines: 949 DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane 950 c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; 951 h=from:to:subject:date; 952 z=From:foo@eng.example.net|To:joe@example.com| 953 Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 954 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 955 VoG4ZHRNiYzR 957 3.6 Key Management and Representation 959 DKIM keys do not require third party signatures by Certificate 960 Authorities in order to be trusted, since the public key is retrieved 961 directly from the signer. 963 DKIM keys can potentially be stored in multiple types of key servers 964 and in multiple formats. The storage and format of keys are 965 irrelevant to the remainder of the DKIM algorithm. 967 Parameters to the key lookup algorithm are the type of the lookup 968 (the "q=" tag), the domain of the responsible signer (the "d=" tag of 969 the DKIM-Signature header field), the signing identity (the "i=" 970 tag), and the selector (the "s=" tag). The "i=" tag value could be 971 ignored by some key services. 973 public_key = dkim_find_key(q_val, d_val, i_val, s_val) 975 This document defines a single binding, using DNS to distribute the 976 keys. 978 3.6.1 Textual Representation 980 It is expected that many key servers will choose to present the keys 981 in a text format. The following definition MUST be used for any DKIM 982 key represented in textual form. 984 The overall syntax is a key-value-list as described above. The 985 current valid tags are: 987 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 988 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 989 (without the quotes). This tag MUST be the first tag in the 990 response. Responses beginning with a "v=" tag with any other 991 value MUST be discarded. 993 ABNF: 995 key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" 997 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 998 This value MUST match the local part of the signing address, with 999 a "*" character acting as a wildcard. The intent of this tag is 1000 to constrain which signing address can legitimately use this 1001 selector. An email with a signing address that does not match 1002 the value of this tag constitutes a failed verification. 1003 Wildcarding allows matching for addresses such as "user+*". An 1004 empty "g=" value never matches any addresses. 1006 ABNF: 1008 key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart 1009 key-g-tag-lpart = [dot-atom] ["*"] [dot-atom] 1011 [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a dot- 1012 atom. This should probably use a different character for 1013 wildcarding. Unfortunately, the options are non-mnemonic 1014 (e.g., "@", "(", ":"). Alternatively we could insist on 1015 escaping a "*" intended as a literal "*" in the address.]] 1017 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 1018 allowing all algorithms). A colon-separated list of hash 1019 algorithms that might be used. Signers and Verifiers MUST 1020 support the "sha1" hash algorithm. 1022 ABNF: 1024 key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 1025 0*( [FWS] ":" [FWS] key-h-tag-alg ) 1026 key-h-tag-alg = "sha1" / x-key-h-tag-alg 1027 x-key-h-tag-alg = hyphenated-word ; for future extension 1029 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 1030 verifiers MUST support the "rsa" key type. The "rsa" key type 1031 indicates that an RSA public key, as defined in [RFC3447], 1032 sections 3.1 and A.1.1, is being used in the p= tag. (Note: the 1033 p= tag further encodes the value using the base64 algorithm.) 1035 ABNF: 1037 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 1038 key-k-tag-type = "rsa" / x-key-k-tag-type 1039 x-key-k-tag-type = hyphenated-word ; for future extension 1041 [[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be 1042 hard to separate h= and k=; for example DSA implies that 1043 SHA-1 will be used. This might be an actual change to the 1044 spec depending on how we decide to fix this.]] 1046 n= Notes that might be of interest to a human (quoted-printable; 1047 OPTIONAL, default is empty). No interpretation is made by any 1048 program. This tag should be used sparingly in any key server 1049 mechanism that has space limitations (notably DNS). 1051 ABNF: 1053 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 1055 p= Public-key data (base64; REQUIRED). An empty value means that 1056 this public key has been revoked. The syntax and semantics of 1057 this tag value before being encoded in base64 is defined by the 1058 k= tag. 1060 ABNF: 1062 key-p-tag = %x70 [FWS] "=" [FWS] base64string 1064 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 1065 separated list of service types to which this record applies. 1066 Verifiers for a given service type MUST ignore this record if the 1067 appropriate type is not listed. Currently defined service types 1068 are: 1070 * matches all service types 1072 email electronic mail (not necessarily limited to SMTP) 1074 This tag is intended to permit senders to constrain the use of 1075 delegated keys, e.g., where a company is willing to delegate the 1076 right to send mail in their name to an outsourcer, but not to 1077 send IM or make VoIP calls. (This of course presumes that these 1078 keys are used in other services in the future.) 1080 ABNF: 1082 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type 1083 key-s-tag-type = "email" / "*" / x-key-s-tag-type 1084 x-key-s-tag-type = hyphenated-word ; for future extension 1086 t= Flags, represented as a colon-separated list of names (plain- 1087 text; OPTIONAL, default is no flags set). The defined flags are: 1089 y This domain is testing DKIM. Verifiers MUST NOT treat 1090 messages from signers in testing mode differently from 1091 unsigned email, even should the signature fail to verify. 1092 Verifiers MAY wish to track testing mode results to assist 1093 the signer. 1095 ABNF: 1097 key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 1098 0*( [FWS] ":" [FWS] key-t-tag-flag ) 1099 key-t-tag-flag = "y" / x-key-t-tag-flag 1100 x-key-t-tag-flag = hyphenated-word ; for future extension 1101 Unrecognized flags MUST be ignored. 1103 3.6.2 DNS binding 1105 A binding using DNS as a key service is hereby defined. All 1106 implementations MUST support this binding. 1108 3.6.2.1 Name Space 1110 All DKIM keys are stored in a "_domainkey" subdomain. Given a DKIM- 1111 Signature field with a "d=" tag of "domain" and an "s=" tag of 1112 "selector", the DNS query will be for "selector."_domainkey".domain". 1114 The value of the "i=" tag is not used by the DNS binding. 1116 3.6.2.2 Resource Record Types for Key Storage 1118 [[This section needs to be fleshed out. ACTUALLY: will be addressed 1119 in another document.]] 1121 Two RR types are used: DKK and TXT. 1123 The DKK RR is expected to be a non-text, binary representation 1124 intended to allow the largest possible keys to be represented and 1125 transmitted in a UDP DNS packet. Details of this RR are described in 1126 [ID-DKIM-RR]. 1128 TXT records are encoded as described in Section 3.6.1. 1130 Verifiers SHOULD search for a DKK RR first, if possible, followed by 1131 a TXT RR. If the verifier is unable to search for a DKK RR or a DKK 1132 RR is not found, the verifier MUST search for a TXT RR. 1134 3.7 Computing the Message Hash 1136 Both signing and verifying message signatures starts with a step of 1137 computing a cryptographic hash of the message. Signers will choose 1138 the parameters of the signature as described in Signer Actions 1139 (Section 5); verifiers will use the parameters specified in the 1140 "DKIM-Signature" header field being verified. In the following 1141 discussion, the names of the tags in the "DKIM-Signature" header 1142 field which either exists (when verifying) or will be created (when 1143 signing) are used. 1145 The signer or verifier MUST pass the following to the hash algorithm 1146 in the indicated order. Note that canonicalization (Section 3.4) is 1147 only used to prepare the email for signing or verifying; it does not 1148 affect the transmitted email in any way. 1150 1. The header fields specified by the "h=" tag, in the order 1151 specified in that tag, and canonicalized using the header 1152 canonicalization algorithm specified in the "c=" tag. 1154 2. A single CRLF. 1156 3. The message body, canonicalized using the body canonicalization 1157 algorithm specified in the "c=" tag, and truncated to the length 1158 specified in the "l=" tag. 1160 4. A single CRLF. 1162 5. The "DKIM-Signature" header field that exists (verifying) or will 1163 be inserted (signing) in the message, with the content of the 1164 "b=" tag deleted (i.e., treated as the empty string), 1165 canonicalized using the header canonicalization algorithm 1166 specified in the "c=" tag, and without a trailing CRLF. 1168 After the body is processed, a single CRLF followed by the "DKIM- 1169 Signature" header field being created or verified is presented to the 1170 algorithm. The value portion of the "b=" tag (that is, the portion 1171 after the "=" sign) must be treated as though it were empty, and the 1172 header field must be canonicalized according to the algorithm that is 1173 specified in the "c=" tag. Any final CRLF on the "DKIM-Signature" 1174 header field MUST NOT be included in the signature computation. 1176 All tags and their values in the DKIM-Signature header field are 1177 included in the cryptographic hash with the sole exception of the 1178 value portion of the "b=" (signature) tag, which MUST be treated as 1179 the null string. All tags MUST be included even if they might not be 1180 understood by the verifier. The header field MUST be presented to 1181 the hash algorithm after the body of the message rather than with the 1182 rest of the header fields and MUST be canonicalized as specified in 1183 the "c=" (canonicalization) tag. The DKIM-Signature header field 1184 MUST NOT be included in its own h= tag. 1186 When calculating the hash on messages that will be transmitted using 1187 base64 or quoted-printable encoding, signers MUST compute the hash 1188 after the encoding. Likewise, the verifier MUST incorporate the 1189 values into the hash before decoding the base64 or quoted-printable 1190 text. However, the hash MUST be computed before transport level 1191 encodings such as SMTP "dot-stuffing." 1193 With the exception of the canonicalization procedure described in 1194 Section 3.4, the DKIM signing process treats the body of messages as 1195 simply a string of characters. DKIM messages MAY be either in plain- 1196 text or in MIME format; no special treatment is afforded to MIME 1197 content. Message attachments in MIME format MUST be included in the 1198 content which is signed. 1200 4. Semantics of Multiple Signatures 1202 Considerable energy has been spent discussing the desirability and 1203 semantics of multiple DKIM signatures in a single message, 1204 particularly in a "re-sending" scenario such as a mailing list. On 1205 the one hand, discarding existing signature header fields loses 1206 information which could prove to be valuable in the future. On the 1207 other hand, since header fields are known to be re-ordered in transit 1208 by at least some MTAs, determining the most interesting signature 1209 header field is non-trivial. 1211 Further confusion could occur with multiple signatures added at the 1212 same logical "depth". For example, a signer could choose to sign 1213 using multiple signing or canonicalization algorithms. There is no a 1214 priori way to determine that two signatures are alternatives versus 1215 nested in a re-sending scenario. 1217 [[DOCUMENTATION NOTE: ISSUE: downgrade attacks by removal of sig 1218 headers that use stronger algorithms.]] 1220 Also, many agents are expected to break existing signatures (e.g., a 1221 mailing list that modifies Subject header fields or adds unsubscribe 1222 information to the end of the message). Retaining signature 1223 information that is known to be bad could create more problems than 1224 it solves. 1226 For these reasons, multiple signatures are not prohibited but are 1227 left undefined. 1229 INFORMATIVE IMPLEMENTATION GUIDANCE: Agents that forward mail 1230 without modification could decide whether to add another signature 1231 or simply retain an existing signatures. Agents that are known to 1232 break existing signatures may leave the existing signature or 1233 delete it. Agents that re-sign messages that are already signed 1234 should verify the previous signature and should probably refuse to 1235 sign any critical information that failed a signature 1236 verification. 1238 5. Signer Actions 1240 The following steps are performed in order by signers. 1242 5.1 Determine if the Email Should be Signed and by Whom 1244 A signer can obviously only sign email for domains for which it has a 1245 private-key and the necessary knowledge of the corresponding public 1246 key and selector information. However there are a number of other 1247 reasons beyond the lack of a private key why a signer could choose 1248 not to sign an email. 1250 A SUBMISSION server MAY sign if the sender is authenticated by some 1251 secure means, e.g., SMTP AUTH. Within a trusted enclave the signing 1252 address MAY be derived from the header field according to local 1253 signer policy. Within a trusted enclave an MTA MAY do the signing. 1255 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1256 sign Received header fields if the outgoing gateway MTA obfuscates 1257 Received header fields, for example to hide the details of 1258 internal topology. 1260 A signer MUST NOT sign an email if it is unwilling to be held 1261 responsible for the message; in particular, the signer SHOULD ensure 1262 that the submitter has a bona fide relationship with the signer and 1263 that the submitter has the right to use the address being claimed. 1265 If an email cannot be signed for some reason, it is a local policy 1266 decision as to what to do with that email. 1268 5.2 Select a private-key and corresponding selector information 1270 This specification does not define the basis by which a signer should 1271 choose which private-key and selector information to use. Currently, 1272 all selectors are equal as far as this specification is concerned, so 1273 the decision should largely be a matter of administrative 1274 convenience. 1276 A signer SHOULD NOT sign with a key that is expected to expire within 1277 seven days; that is, when rotating to a new key, signing should 1278 immediately commence with the new key and the old key SHOULD be 1279 retained for at least seven days before being removed from the key 1280 server. 1282 5.3 Normalize the Message to Prevent Transport Conversions 1284 Some messages, particularly those using 8-bit characters, are subject 1285 to modification during transit, notably conversion to 7-bit form. 1286 Such conversions will break DKIM signatures. In order to minimize 1287 the chances of such breakage, signers SHOULD convert the message to a 1288 suitable MIME content transfer encoding such as quoted-printable or 1289 base64 as described in MIME Part One [RFC2045] before signing. Such 1290 conversion is outside the scope of DKIM; the actual message SHOULD be 1291 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 1292 DKIM algorithm. 1294 Should the message be submitted to the signer with any local encoding 1295 that will be modified before transmission, such conversion to 1296 canonical form MUST be done before signing. In particular, some 1297 systems use local line separator conventions (such as the Unix 1298 newline character) internally rather than the SMTP-standard CRLF 1299 sequence. All such local conventions MUST be converted to canonical 1300 format before signing. 1302 More generally, the signer MUST sign the message as it will be 1303 received by the verifier rather than in some local or internal form. 1305 5.4 Determine the header fields to Sign 1307 The From header field MUST be signed (that is, included in the h= tag 1308 of the resulting DKIM-Signature header field); any header field that 1309 describes the role of the signer (for example, the Sender or Resent- 1310 From header field if the signature is on behalf of the corresponding 1311 address and that address is different from the From address) MUST 1312 also be included. The signed header fields SHOULD also include the 1313 Subject and Date header fields as well as all MIME header fields. 1314 Signers SHOULD NOT sign an existing header field likely to be 1315 legitimately modified or removed in transit. In particular, 1316 [RFC2821] explicitly permits modification or removal of the "Return- 1317 Path" header field in transit. Signers MAY include any other header 1318 fields present at the time of signing at the discretion of the 1319 signer. It is RECOMMENDED that all other existing, non-repeatable 1320 header fields be signed. 1322 The DKIM-Signature header field is always implicitly signed and MUST 1323 NOT be included in the h= tag except to indicate that other 1324 preexisting signatures are also signed. 1326 Signers MUST sign any header fields that the signers wish to have the 1327 verifiers treat as trusted. Put another way, verifiers MAY treat 1328 unsigned header fields with extreme skepticism, up to and including 1329 refusing to display them to the end user. 1331 Signers MAY claim to have signed header fields that do not exist 1332 (that is, signers MAY include the header field name in the h= tag 1333 even if that header field does not exist in the message). When 1334 computing the signature, the non-existing header field MUST be 1335 treated as the null string (including the header field name, header 1336 field value, all punctuation, and the trailing CRLF). 1338 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1339 the absence of a header field; if that header field is added later 1340 the signature will fail. 1342 Signers choosing to sign an existing replicated header field (such as 1343 Received) MUST sign the physically last instance of that header field 1344 in the header field block. Signers wishing to sign multiple 1345 instances of an existing replicated header field MUST include the 1346 header field name multiple times in the h= tag of the DKIM-Signature 1347 header field, and MUST sign such header fields in order from the 1348 bottom of the header field block to the top. The signer MAY include 1349 more header field names than there are actual corresponding header 1350 fields to indicate that additional header fields of that name SHOULD 1351 NOT be added. 1353 INFORMATIVE EXAMPLE: 1355 If the signer wishes to sign two existing Received header fields, 1356 and the existing header contains: 1358 Received: 1359 Received: 1360 Received: 1362 then the resulting DKIM-Signature header field should read: 1364 DKIM-Signature: ... h=Received : Received : ... 1366 and Received header fields and will be signed in that 1367 order. 1369 Signers SHOULD NOT sign header fields that might be replicated 1370 (either at the time of signing or potentially in the future), with 1371 the exception of trace header fields such as Received. Comment and 1372 non standard header fields (including X-* header fields) are 1373 permitted by [RFC2822] to be replicated; however, many such header 1374 fields are, by convention, not replicated. Signers need to 1375 understand the implications of signing header fields that might later 1376 be replicated, especially in the face of header field reordering. In 1377 particular, [RFC2822] only requires that trace header fields retain 1378 the original order. 1380 INFORMATIVE RATIONALE: Received: is allowed because these header 1381 fields, as well as Resent-* header fields, are already order- 1382 sensitive. 1384 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1385 header field blocks to be reordered (with the exception of 1386 Received header fields), reordering of signed replicated header 1387 fields by intermediate MTAs will cause DKIM signatures to be 1388 broken; such anti-social behavior should be avoided. 1390 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1391 specification, all end-user visible header fields should be signed 1392 to avoid possible "indirect spamming." For example, if the 1393 "Subject" header field is not signed, a spammer can resend a 1394 previously signed mail, replacing the legitimate subject with a 1395 one-line spam. 1397 INFORMATIVE NOTE: There has been some discussion that a Sender 1398 Signing Policy include the list of header fields that the signer 1399 always signs. N.B. In theory this is unnecessary, since as long 1400 as the signer really always signs the indicated header fields 1401 there is no possibility of an attacker replaying an existing 1402 message that has such an unsigned header field. 1404 5.5 Compute the Message Hash 1406 The signer MUST compute the message hash as described in Section 3.7 1407 and then sign it using the selected public-key algorithm. 1409 To avoid possible ambiguity, a signer SHOULD either sign or remove 1410 any preexisting header fields which convey the results of previous 1411 verifications of the message signature prior to preparation for 1412 signing and transmission. Such header fields MUST NOT be signed if 1413 the signer is uncertain of the authenticity of the preexisting header 1414 field, for example, if it is not locally generated or signed by a 1415 previous DKIM-Signature line that the current signer has verified. 1417 Entities such as mailing list managers that implement DKIM and which 1418 modify the message or the header field (for example, inserting 1419 unsubscribe information) before retransmitting the message SHOULD 1420 check any existing signature on input and MUST make such 1421 modifications before re-signing the message; such signing SHOULD 1422 include any prior verification status, if any, that was inserted upon 1423 message receipt. 1425 5.6 Insert the DKIM-Signature header field 1427 Finally, the signer MUST insert the "DKIM-Signature:" header field 1428 prior to transmitting the email. The "DKIM-Signature" header field 1429 MUST be the same as used to compute the hash as described above, 1430 except that the value of the "b=" tag MUST be the appropriately 1431 signed hash computed in the previous step, signed using the algorithm 1432 specified in the "a=" tag of the "DKIM-Signature" header field and 1433 using the private key corresponding to the selector given in the "s=" 1434 tag of the "DKIM-Signature" header field, as chosen above in 1435 Section 5.2 1437 The "DKIM-Signature" SHOULD be inserted before any header fields that 1438 it signs in the header block. 1440 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1441 is to insert the "DKIM-Signature" header field at the beginning of 1442 the header block. This is consistent with treating "DKIM- 1443 Signature" as a trace header. 1445 6. Verifier Actions 1447 Since a signer MAY expire a public key at any time, it is recommended 1448 that verification occur in a timely manner with the most timely place 1449 being during acceptance by the border MTA. 1451 A border or intermediate MTA MAY verify the message signatures and 1452 add a verification header field to incoming messages. This 1453 considerably simplifies things for the user, who can now use an 1454 existing mail user agent. Most MUAs have the ability to filter 1455 messages based on message header fields or content; these filters 1456 would be used to implement whatever policy the user wishes with 1457 respect to unsigned mail. 1459 A verifying MTA MAY implement a policy with respect to unverifiable 1460 mail, regardless of whether or not it applies the verification header 1461 field to signed messages. 1463 Verifiers apply the following steps in the order listed. 1465 6.1 Extract the Signature from the Message 1467 The signature and associated signing identity is included in the 1468 value of the DKIM-Signature header field. 1470 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. 1471 Existence of such a tag indicates a new, incompatible version of the 1472 DKIM-Signature header field. 1474 If the "DKIM-Signature" header field does not contain the "i=" tag, 1475 the verifier MUST behave as though the value of that tag were "@d", 1476 where "d" is the value from the "d=" tag (which MUST exist). 1478 Verifiers MUST confirm that the domain specified in the "d=" tag is 1479 the same as or a superdomain of the domain part of the "i=" tag. If 1480 not, the DKIM-Signature header field MUST be ignored. 1482 Implementers MUST meticulously validate the format and values in the 1483 "DKIM-Signature:" header field; any inconsistency or unexpected 1484 values MUST result in an unverified email. Being "liberal in what 1485 you accept" is definitely a bad strategy in this security context. 1486 Note however that this does not include the existence of unknown tags 1487 in a "DKIM-Signature" header field, which are explicitly permitted. 1489 Verifiers MUST NOT attribute ultimate meaning to the order of 1490 multiple DKIM-Signature header fields. In particular, there is 1491 reason to believe that some relays will reorder the header field in 1492 potentially arbitrary ways. 1494 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1495 a clue to signing order in the absence of any other information. 1496 However, other clues as to the semantics of multiple signatures 1497 must be considered before using ordering. 1499 Since there can be multiple signatures in a message, a verifier 1500 SHOULD ignore an invalid signature (regardless if caused by a 1501 syntactic or semantic problem) and try other signatures. A verifier 1502 MAY choose to treat a message with one or more invalid signatures and 1503 no valid signatures with more suspicion than a message with no 1504 signature at all. 1506 6.2 Get the Public Key 1508 The public key is needed to complete the verification process. The 1509 process of retrieving the public key depends on the query type as 1510 defined by the "q=" tag in the "DKIM-Signature:" header field line. 1511 Obviously, a public key should only be retrieved if the process of 1512 extracting the signature information is completely successful. 1513 Details of key management and representation are described in 1514 Section 3.6. The verifier MUST validate the key record and MUST 1515 ignore any public key records that are malformed. 1517 When validating a message, a verifier MUST: 1519 1. Retrieve the public key as described in (Section 3.6) using the 1520 domain from the "d=" tag and the selector from the "s=" tag. 1522 2. If the query for the public key fails to respond, the verifier 1523 SHOULD defer acceptance of this email (normally this will be 1524 achieved with a 451/4.7.5 SMTP reply code). 1526 3. If the query for the public key fails because the corresponding 1527 RR does not exist, the verifier MUST ignore the signature. 1529 4. If the result returned from the query does not adhere to the 1530 format defined in this specification, the verifier MUST ignore 1531 the signature. 1533 5. If the "g=" tag in the public key does not match the local part 1534 of the "i=" tag on the message signature, the verifier MUST 1535 ignore the signature. If the local part of the "i=" tag on the 1536 message signature is not present, the g= tag must be * (valid for 1537 all addresses in the domain) or not present (which defaults to 1538 *), otherwise the verifier MUST ignore the signature. Other than 1539 this test, verifiers MUST NOT treat a message signed with a key 1540 record having a g= tag any differently than one without; in 1541 particular, verifiers MUST NOT prefer messages that seem to have 1542 an individual signature by virtue of a g= tag vs. a domain 1543 signature. 1545 6. If the "h=" tag exists in the public key record and the hash 1546 algorithm implied by the a= tag in the DKIM-Signature header is 1547 not included in the "h=" tag, the verifier MUST ignore the 1548 signature. 1550 7. If the public key data (the "p=" tag) is empty then this key has 1551 been revoked and the verifier MUST treat this as a failed 1552 signature check. 1554 8. If the public key data is not suitable for use with the algorithm 1555 type defined by the "a=" tag in the "DKIM-Signature" header 1556 field, the verifier MUST ignore the signature. 1558 If the signature is to be ignored, verifiers SHOULD search for 1559 another signature in the message. 1561 6.3 Compute the Verification 1563 Given a signer and a public key, verifying a signature consists of 1564 the following steps. 1566 o Based on the algorithm defined in the "c=" tag, the body length 1567 specified in the "l=" tag, and the header field names in the "h=" 1568 tag, create a canonicalized copy of the email as is described in 1569 Section 3.7. When matching header field names in the "h=" tag 1570 against the actual message header field, comparisons MUST be case- 1571 insensitive. 1573 o Based on the algorithm indicated in the "a=" tag, 1575 * Compute the message hash from the canonical copy as described 1576 in Section 3.7. 1578 * Decrypt the signature using the signer's public key. 1580 o Compare the decrypted signature to the message hash. If they are 1581 identical, the hash computed by the signer must be the same as the 1582 hash computed by the verifier, and hence the signature verifies; 1583 otherwise, the signature fails. 1585 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1586 initiate the public-key query in parallel with calculating the 1587 hash as the public key is not needed until the final decryption is 1588 calculated. 1590 Verifiers MUST ignore any DKIM-Signature header fields where the 1591 signature does not validate. Verifiers that are prepared to validate 1592 multiple signature header fields SHOULD proceed to the next signature 1593 header field, should it exist. However, verifiers MAY make note of 1594 the fact that an invalid signature was present for consideration at a 1595 later step. 1597 INFORMATIVE NOTE: The rationale of this requirement is to permit 1598 messages that have invalid signatures but also a valid signature 1599 to work. For example, a mailing list exploder might opt to leave 1600 the original submitter signature in place even though the exploder 1601 knows that it is modifying the message in some way that will break 1602 that signature, and the exploder inserts its own signature. In 1603 this case the message should succeed even in the presence of the 1604 known-broken signature. 1606 If a body length is specified in the "l=" tag of the signature, 1607 verifiers MUST only verify the number of bytes indicated in the body 1608 length. Verifiers MAY decide to treat a message containing bytes 1609 beyond the indicated body length with suspicion. Verifiers MAY 1610 truncate the message at the indicated body length or reject the 1611 signature outright. 1613 6.4 Insert the Authentication-Results Header Field 1615 Verifiers wishing to communicate the results of verification via an 1616 email header field SHOULD use the Authentication-Results header field 1617 [ID-AUTH-RES]. The Authentication-Results header field SHOULD be 1618 inserted before any existing DKIM-Signature or Authentication-Results 1619 header fields in the header field block. 1621 INFORMATIVE ADVICE to MUA filter writers: Patterns intended to 1622 search for Authentication-Results header fields to visibly mark 1623 authenticated mail for end users should verify that the 1624 Authentication-Results header field was added by the appropriate 1625 verifying domain and that the verified identity matches the sender 1626 identity that will be displayed by the MUA. In particular, MUA 1627 patterns should not be influenced by bogus Authentication-Results 1628 header fields added by attackers. 1630 6.5 Interpret Results/Apply Local Policy 1632 It is beyond the scope of this specification to describe what actions 1633 a verifier system should make, but an authenticated email presents an 1634 opportunity to a receiving system that unauthenticated email cannot. 1635 Specifically, an authenticated email creates a predictable identifier 1636 by which other decisions can reliably be managed, such as trust and 1637 reputation. Conversely, unauthenticated email lacks a reliable 1638 identifier that can be used to assign trust and reputation. It is 1639 reasonable to treat unauthenticated email as lacking any trust and 1640 having no positive reputation. 1642 If the verifying MTA is capable of verifying the public key of the 1643 signer and check the signature on the message synchronously with the 1644 SMTP session and such signature is missing or does not verify the MTA 1645 MAY reject the message with an error such as: 1647 550 5.7.1 Unsigned messages not accepted 1649 550 5.7.5 Message signature incorrect 1651 If it is not possible to fetch the public key, perhaps because the 1652 key server is not available, a temporary failure message MAY be 1653 generated, such as: 1655 451 4.7.5 Unable to verify signature - key server unavailable 1657 Once the signature has been verified, that information MUST be 1658 conveyed to higher level systems (such as explicit allow/white lists 1659 and reputation systems) and/or to the end user. If the 1660 authentication status is to be stored in the message header field, 1661 the Authentication-Results header field [ID-AUTH-RES] SHOULD be used 1662 to convey this information. If the message is signed on behalf of 1663 any address other than that in the From: header field, the mail 1664 system SHOULD take pains to ensure that the actual signing identity 1665 is clear to the reader. 1667 The verifier MAY treat unsigned header fields with extreme 1668 skepticism, including marking them as untrusted or even deleting them 1669 before display to the end user. 1671 While the symptoms of a failed verification are obvious -- the 1672 signature doesn't verify -- establishing the exact cause can be more 1673 difficult. If a selector cannot be found, is that because the 1674 selector has been removed or was the value changed somehow in 1675 transit? If the signature line is missing is that because it was 1676 never there, or was it removed by an over-zealous filter? For 1677 diagnostic purposes, the exact reason why the verification fails 1678 SHOULD be recorded in the "Authentication-Results" header field and 1679 possibly the system logs. However in terms of presentation to the 1680 end user, the result SHOULD be presented as a simple binary result: 1681 either the email is verified or it is not. If the email cannot be 1682 verified, then it SHOULD be rendered the same as all unverified email 1683 regardless of whether it looks like it was signed or not. 1685 6.6 MUA Considerations 1687 In order to retain the current semantics and visibility of the From 1688 header field, verifying mail agents SHOULD take steps to ensure that 1689 the signing address is prominently visible to the user if it is 1690 different from the From address. MUAs MAY visually mark the 1691 unverified part of the body in a distinctive font or color to the end 1692 user. 1694 If MUA implementations that highlight the signed address are not 1695 available, this MAY be done by the validating MTA or MDA by rewriting 1696 the From address in a manner which remains compliant with [RFC2822]. 1697 Such modifications MUST be performed after the final verification 1698 step since they will break the signature. If performed, the 1699 rewriting SHOULD include the name of the signer in the address. For 1700 example: 1702 From: John Q. User 1704 might be converted to 1706 From: "John Q. User via " 1708 This sort of address inconsistency is expected for mailing lists, but 1709 might be otherwise used to mislead the verifier, for example if a 1710 message supposedly from administration@your-bank.com had a Sender 1711 address of fraud@badguy.com. 1713 Under no circumstances should an unsigned header field be displayed 1714 in any context that might be construed by the end user as having been 1715 signed. Notably, unsigned header fields SHOULD be hidden from the 1716 end user to the extent possible. 1718 The MUA MAY hide or mark portions of the message body that are not 1719 signed when using the "l=" tag. 1721 7. IANA Considerations 1723 Use of the _domainkey prefix in DNS records will require registration 1724 by IANA. 1726 To avoid conflicts, tag names for the DKIM-Signature header and key 1727 records should be registered with IANA. 1729 Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature 1730 header field, and the "h=", "k=", "s=", and "t" tags in key records 1731 should be registered with IANA for the same reason. 1733 The DKK RR type must be registered by IANA. 1735 8. Security Considerations 1737 It has been observed that any mechanism that is introduced which 1738 attempts to stem the flow of spam is subject to intensive attack. 1739 DKIM needs to be carefully scrutinized to identify potential attack 1740 vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. 1742 8.1 Misuse of Body Length Limits ("l=" Tag) 1744 Body length limits (in the form of the "l=" tag) are subject to 1745 several potential attacks. 1747 8.1.1 Addition of new MIME parts to multipart/* 1749 If the body length limit does not cover a closing MIME multipart 1750 section (including the trailing ""--CRLF"" portion), then it is 1751 possible for an attacker to intercept a properly signed multipart 1752 message and add a new body part. Depending on the details of the 1753 MIME type and the implementation of the verifying MTA and the 1754 receiving MUA, this could allow an attacker to change the information 1755 displayed to an end user from an apparently trusted source. 1757 *** Example appropriate here *** 1759 8.1.2 Addition of new HTML content to existing content 1761 Several receiving MUA implementations do not cease display after a 1762 """" tag. In particular, this allows attacks involving 1763 overlaying images on top of existing text. 1765 INFORMATIVE EXAMPLE: Appending the following text to an existing, 1766 properly closed message will in many MUAs result in inappropriate 1767 data being rendered on top of existing, correct data: 1768
1769 1771
1773 8.2 Misappropriated Private Key 1775 If the private key for a user is resident on their computer and is 1776 not protected by an appropriately secure passphrase, it is possible 1777 for malware to send mail as that user and any other user sharing the 1778 same private key. The malware would, however, not be able to 1779 generate signed spoofs of other signers' addresses, which would aid 1780 in identification of the infected user and would limit the 1781 possibilities for certain types of attacks involving socially- 1782 engineered messages. 1784 A larger problem occurs if malware on many users' computers obtains 1785 the private keys for those users and transmits them via a covert 1786 channel to a site where they can be shared. The compromised users 1787 would likely not know of the misappropriation until they receive 1788 "bounce" messages from messages they are purported to have sent. 1789 Many users might not understand the significance of these bounce 1790 messages and would not take action. 1792 One countermeasure is to use a user-entered passphrase to encrypt the 1793 private key, although users tend to choose weak passphrases and often 1794 reuse them for different purposes, possibly allowing an attack 1795 against DKIM to be extended into other domains. Nevertheless, the 1796 decoded private key might be briefly available to compromise by 1797 malware when it is entered, or might be discovered via keystroke 1798 logging. The added complexity of entering a passphrase each time one 1799 sends a message would also tend to discourage the use of a secure 1800 passphrase. 1802 A somewhat more effective countermeasure is to send messages through 1803 an outgoing MTA that can authenticate the submitter using existing 1804 techniques (e.g., SMTP Authentication), possibly validate the message 1805 itself (e.g., verify that the header is legitimate and that the 1806 content passes a spam content check), and sign the message using a 1807 key appropriate for the submitter address. Such an MTA can also 1808 apply controls on the volume of outgoing mail each user is permitted 1809 to originate in order to further limit the ability of malware to 1810 generate bulk email. 1812 8.3 Key Server Denial-of-Service Attacks 1814 Since the key servers are distributed (potentially separate for each 1815 domain), the number of servers that would need to be attacked to 1816 defeat this mechanism on an Internet-wide basis is very large. 1817 Nevertheless, key servers for individual domains could be attacked, 1818 impeding the verification of messages from that domain. This is not 1819 significantly different from the ability of an attacker to deny 1820 service to the mail exchangers for a given domain, although it 1821 affects outgoing, not incoming, mail. 1823 A variation on this attack is that if a very large amount of mail 1824 were to be sent using spoofed addresses from a given domain, the key 1825 servers for that domain could be overwhelmed with requests. However, 1826 given the low overhead of verification compared with handling of the 1827 email message itself, such an attack would be difficult to mount. 1829 8.4 Attacks Against DNS 1831 Since DNS is a required binding for key services, specific attacks 1832 against DNS must be considered. 1834 While the DNS is currently insecure [RFC3833], it is expected that 1835 the security problems should and will be solved by DNSSEC [RFC4033], 1836 and all users of the DNS will reap the benefit of that work. 1838 Secondly, the types of DNS attacks relevant to DKIM are very costly 1839 and are far less rewarding than DNS attacks on other Internet 1840 applications. 1842 To systematically thwart the intent of DKIM, an attacker must conduct 1843 a very costly and very extensive attack on many parts of the DNS over 1844 an extended period. No one knows for sure how attackers will 1845 respond, however the cost/benefit of conducting prolonged DNS attacks 1846 of this nature is expected to be uneconomical. 1848 Finally, DKIM is only intended as a "sufficient" method of proving 1849 authenticity. It is not intended to provide strong cryptographic 1850 proof about authorship or contents. Other technologies such as 1851 OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. 1853 A second security issue related to the DNS revolves around the 1854 increased DNS traffic as a consequence of fetching Selector-based 1855 data as well as fetching signing domain policy. Widespread 1856 deployment of DKIM will result in a significant increase in DNS 1857 queries to the claimed signing domain. In the case of forgeries on a 1858 large scale, DNS servers could see a substantial increase in queries. 1860 8.5 Replay Attacks 1862 In this attack, a spammer sends a message to be spammed to an 1863 accomplice, which results in the message being signed by the 1864 originating MTA. The accomplice resends the message, including the 1865 original signature, to a large number of recipients, possibly by 1866 sending the message to many compromised machines that act as MTAs. 1867 The messages, not having been modified by the accomplice, have valid 1868 signatures. 1870 Partial solutions to this problem involve the use of reputation 1871 services to convey the fact that the specific email address is being 1872 used for spam, and that messages from that signer are likely to be 1873 spam. This requires a real-time detection mechanism in order to 1874 react quickly enough. However, such measures might be prone to 1875 abuse, if for example an attacker resent a large number of messages 1876 received from a victim in order to make them appear to be a spammer. 1878 Large verifiers might be able to detect unusually large volumes of 1879 mails with the same signature in a short time period. Smaller 1880 verifiers can get substantially the same volume information via 1881 existing collaborative systems. 1883 8.6 Limits on Revoking Keys 1885 When a large domain detects undesirable behavior on the part of one 1886 of its users, it might wish to revoke the key used to sign that 1887 user's messages in order to disavow responsibility for messages which 1888 have not yet been verified or which are the subject of a replay 1889 attack. However, the ability of the domain to do so can be limited 1890 if the same key, for scalability reasons, is used to sign messages 1891 for many other users. Mechanisms for explicitly revoking keys on a 1892 per-address basis have been proposed but require further study as to 1893 their utility and the DNS load they represent. 1895 8.7 Intentionally malformed Key Records 1897 It is possible for an attacker to publish key records in DNS which 1898 are intentionally malformed, with the intent of causing a denial-of- 1899 service attack on a non-robust verifier implementation. The attacker 1900 could then cause a verifier to read the malformed key record by 1901 sending a message to one of its users referencing the malformed 1902 record in a (not necessarily valid) signature. Verifiers MUST 1903 thoroughly verify all key records retrieved from DNS and be robust 1904 against intentionally as well as unintentionally malformed key 1905 records. 1907 8.8 Intentionally Malformed DKIM-Signature header fields 1909 Verifiers MUST be prepared to receive messages with malformed DKIM- 1910 Signature header fields, and thoroughly verify the header field 1911 before depending on any of its contents. 1913 9. References 1915 9.1 Normative References 1917 [ID-AUTH-RES] 1918 Kucherawy, M., "Message header field for Indicating Sender 1919 Authentication Status", 1920 draft-kucherawy-sender-auth-header-02 (work in progress), 1921 May 2005. 1923 [ID-DKIM-RR] 1924 "DKIM Key Resource Records (To be written)", 1925 draft-dkim-dkk-rr-xx (work in progress), 2005. 1927 [ID-SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1928 (SHA and HMAC-SHA)", draft-eastlake-sha2-02 (work in 1929 progress), January 2006. 1931 [OPENSSL] Team, C&D., "OpenSSL Documents", 1932 http://www.openssl.org/docs/, 1933 . 1935 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1936 Mail: Part I: Message Encryption and Authentication 1937 Procedures", RFC 1421, February 1993. 1939 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1940 Extensions (MIME) Part One: Format of Internet Message 1941 Bodies", RFC 2045, November 1996. 1943 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1944 Part Three: Message header field Extensions for Non-ASCII 1945 Text", RFC 2047, November 1996. 1947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1948 Requirement Levels", BCP 14, RFC 2119, March 1997. 1950 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1951 April 2001. 1953 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1954 April 2001. 1956 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1957 Standards (PKCS) #1: RSA Cryptography Specifications 1958 Version 2.1", RFC 3447, February 2003. 1960 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1961 Profile for Internationalized Domain Names (IDN)", 1962 RFC 3491, March 2003. 1964 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1965 Specifications: ABNF", RFC 4234, October 2005. 1967 9.2 Informative References 1969 [ID-DKIM-THREATS] 1970 Fenton, J., "Analysis of Threats Motivating DomainKeys 1971 Identified Mail (DKIM)", draft-fenton-dkim-threats-02 1972 (work in progress), December 2005. 1974 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 1975 "Security Multiparts for MIME: Multipart/Signed and 1976 Multipart/Encrypted", RFC 1847, October 1995. 1978 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1979 "OpenPGP Message Format", RFC 2440, November 1998. 1981 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1982 Name System (DNS)", RFC 3833, August 2004. 1984 [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", 1985 RFC 3851, June 1999. 1987 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1988 Rose, "DNS Security Introduction and Requirements", 1989 RFC 4033, March 2005. 1991 Authors' Addresses 1993 Eric Allman 1994 Sendmail, Inc. 1995 6425 Christie Ave, Suite 400 1996 Emeryville, CA 94608 1997 USA 1999 Phone: +1 510 594 5501 2000 Email: eric+dkim@sendmail.org 2001 URI: 2003 Jon Callas 2004 PGP Corporation 2005 3460 West Bayshore 2006 Palo Alto, CA 94303 2007 USA 2009 Phone: +1 650 319 9016 2010 Email: jon@pgp.com 2012 Mark Delany 2013 Yahoo! Inc 2014 701 First Avenue 2015 Sunnyvale, CA 95087 2016 USA 2018 Phone: +1 408 349 6831 2019 Email: markd+dkim@yahoo-inc.com 2020 URI: 2022 Miles Libbey 2023 Yahoo! Inc 2024 701 First Avenue 2025 Sunnyvale, CA 95087 2026 USA 2028 Email: mlibbeymail-mailsig@yahoo.com 2029 URI: 2031 Jim Fenton 2032 Cisco Systems, Inc. 2033 MS SJ-24/2 2034 170 W. Tasman Drive 2035 San Jose, CA 95134-1706 2036 USA 2038 Phone: +1 408 526 5914 2039 Email: fenton@cisco.com 2040 URI: 2042 Michael Thomas 2043 Cisco Systems, Inc. 2044 MS SJ-9/2 2045 170 W. Tasman Drive 2046 San Jose, CA 95134-1706 2048 Phone: +1 408 525 5386 2049 Email: mat@cisco.com 2051 Appendix A. Example of Use (INFORMATIVE) 2053 This section shows the complete flow of an email from submission to 2054 final delivery, demonstrating how the various components fit 2055 together. 2057 A.1 The user composes an email 2059 From: Joe SixPack 2060 To: Suzie Q 2061 Subject: Is dinner ready? 2062 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2063 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2065 Hi. 2067 We lost the game. Are you hungry yet? 2069 Joe. 2071 A.2 The email is signed 2073 This email is signed by the example.com outbound email server and now 2074 looks like this: 2076 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2077 c=simple; q=dns; i=joe@football.example.com; 2078 h=Received : From : To : Subject : Date : Message-ID; 2079 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2080 VoG4ZHRNiYzR; 2081 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2082 by submitserver.example.com with SUBMISSION; 2083 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2084 From: Joe SixPack 2085 To: Suzie Q 2086 Subject: Is dinner ready? 2087 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2088 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2090 Hi. 2092 We lost the game. Are you hungry yet? 2094 Joe. 2096 The signing email server requires access to the private-key 2097 associated with the "brisbane" selector to generate this signature. 2098 Distribution and management of private-keys is outside the scope of 2099 this document. 2101 A.3 The email signature is verified 2103 The signature is normally verified by an inbound SMTP server or 2104 possibly the final delivery agent. However, intervening MTAs can 2105 also perform this verification if they choose to do so. The 2106 verification process uses the domain "example.com" extracted from the 2107 "d=" tag and the selector "brisbane" from the "s=" tag in the "DKIM- 2108 Signature" header field to form the DNS DKIM query for: 2110 brisbane._dkim.example.com 2112 Signature verification starts with the physically last "Received" 2113 header field, the "From" header field, and so forth, in the order 2114 listed in the "h=" tag. Verification follows with a single CRLF 2115 followed by the body (starting with "Hi."). The email is canonically 2116 prepared for verifying with the "simple" method. The result of the 2117 query and subsequent verification of the signature is stored in the 2118 "Authentication-Results" header field line. After successful 2119 verification, the email looks like this: 2121 Authentication-Results: shopping.example.net 2122 header.from=joe@football.example.com; dkim=pass 2123 Received: from mout23.football.example.com (192.168.1.1) 2124 by shopping.example.net with SMTP; 2125 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2126 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2127 c=simple; q=dns; i=joe@football.example.com; 2128 h=Received : From : To : Subject : Date : Message-ID; 2129 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2130 VoG4ZHRNiYzR 2131 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2132 by submitserver.example.com with SUBMISSION; 2133 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2134 From: Joe SixPack 2135 To: Suzie Q 2136 Subject: Is dinner ready? 2137 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2138 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2140 Hi. 2142 We lost the game. Are you hungry yet? 2144 Joe. 2146 Appendix B. Usage Examples (INFORMATIVE) 2148 Studies in this appendix are for informational purposes only. In no 2149 case should these examples be used as guidance when creating an 2150 implementation. 2152 B.1 Simple Message Forwarding 2154 In some cases the recipient may request forwarding of email messages 2155 from the original address to another, through the use of a Unix 2156 .forward file or equivalent. In this case messages are typically 2157 forwarded without modification, except for the addition of a Received 2158 header field to the message and a change in the Envelope-to address. 2159 In this case, the eventual recipient should be able to verify the 2160 original signature since the signed content has not changed, and 2161 attribute the message correctly. 2163 B.2 Outsourced Business Functions 2165 Outsourced business functions represent a use case that motivates the 2166 need for selectors (the "s=" signature tag) and granularity (the "g=" 2167 key tag). Examples of outsourced business functions are legitimate 2168 email marketing providers and corporate benefits providers. In 2169 either case, the outsourced function would like to be able to send 2170 messages using the email domain of the client company. At the same 2171 time, the client may be reluctant to register a key for the provider 2172 that grants the ability to send messages for any address in the 2173 domain. 2175 The outsourcing company can generate a keypair and the client company 2176 can register the public key using a unique selector for a specific 2177 address such as winter-promotions@example.com by specifying a 2178 granularity of "g=winter-promotions" or "g=*-promotions" (to allow a 2179 range of addresses). This would enable the provider to send messages 2180 using that specific address and have them verify properly. The 2181 client company retains control over the email address because it 2182 retains the ability to revoke the key at any time. 2184 B.3 PDAs and Similar Devices 2186 PDAs are one example of the use of multiple keys per user. Suppose 2187 that John Doe wanted to be able to send messages using his corporate 2188 email address, jdoe@example.com, and the device did not have the 2189 ability to make a VPN connection to the corporate network. If the 2190 device was equipped with a private key registered for 2191 jdoe@example.com by the administrator of that domain, and appropriate 2192 software to sign messages, John could send signed messages through 2193 the outgoing network of the PDA service provider. 2195 B.4 Mailing Lists 2197 There is a wide range of behavior in forwarders and mailing lists 2198 (collectively called "forwarders" below), ranging from those which 2199 make no modification to the message itself (other than to add a 2200 Received header field and change the envelope information) to those 2201 which may add header fields, change the Subject header field, add 2202 content to the body (typically at the end), or reformat the body in 2203 some manner. 2205 Forwarders which do not modify the body or signed header fields of a 2206 message with a valid signature may re-sign the message as described 2207 below. 2209 Forwarders which make any modification to a message that could result 2210 in its signature becoming invalid should sign or re-sign using an 2211 appropriate identification (e.g., mailing-list-name@example.net). 2212 Since in so doing the (re-)signer is taking responsibility for the 2213 content of the message, modifying forwarders may elect to forward or 2214 re-sign only for messages which were received with valid signatures 2215 or other indications that the messages being signed are not spoofed. 2217 Forwarders which wish to re-sign a message must apply a Sender header 2218 field to the message to identify the address being used to sign the 2219 message and must remove any preexisting Sender header field as 2220 required by [RFC2822]. The forwarder applies a new DKIM-Signature 2221 header field with the signature, public key, and related information 2222 of the forwarder. 2224 B.5 Affinity Addresses 2226 "Affinity addresses" are email addresses that users employ to have an 2227 email address that is independent of any changes in email service 2228 provider they may choose to make. They are typically associated with 2229 college alumni associations, professional organizations, and 2230 recreational organizations with which they expect to have a long-term 2231 relationship. These domains usually provide forwarding of incoming 2232 email, but (currently) usually depend on the user to send outgoing 2233 messages through their own service provider's MTA. They usually have 2234 an associated Web application which authenticates the user and allows 2235 the forwarding address to be changed. 2237 With DKIM, affinity domains could use the Web application to allow 2238 users to register their own public keys to be used to sign messages 2239 on behalf of their affinity address. This is another application 2240 that takes advantage of user-level keying, and domains used for 2241 affinity addresses would typically have a very large number of user- 2242 level keys. Alternatively, the affinity domain could handle outgoing 2243 mail, operating a mail submission agent that authenticates users 2244 before accepting and signing messages for them. This is of course 2245 dependent on the user's service provider not blocking the relevant 2246 TCP ports used for mail submission. 2248 B.6 Third-party Message Transmission 2250 Third-party message transmission refers to the authorized sending of 2251 mail by an Internet application on behalf of a user. For example, a 2252 website providing news may allow the reader to forward a copy of the 2253 message to a friend; this is typically done using the reader's email 2254 address. This is sometimes referred to as the "Evite problem", named 2255 after the website of the same name that allows a user to send 2256 invitations to friends. 2258 One way this can be handled is to continue to put the reader's email 2259 address in the From field of the message, but put an address owned by 2260 the site into the Sender field, and sign the message on behalf of the 2261 Sender. A verifying MTA should accept this and rewrite the From 2262 field to indicate the address that was verified, i.e., From: John 2263 Doe via news@news-site.com . 2265 Appendix C. Creating a public key (INFORMATIVE) 2267 The default signature is an RSA signed SHA1 digest of the complete 2268 email. For ease of explanation, the openssl command is used to 2269 describe the mechanism by which keys and signatures are managed. One 2270 way to generate a 768 bit private-key suitable for DKIM, is to use 2271 openssl like this: 2273 $ openssl genrsa -out rsa.private 768 2275 This results in the file rsa.private containing the key information 2276 similar to this: 2278 -----BEGIN RSA PRIVATE KEY----- 2279 MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 2280 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo 2281 AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH 2282 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn 2283 Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 2284 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew 2285 ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs 2286 FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb 2287 weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 2288 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= 2289 -----END RSA PRIVATE KEY----- 2291 To extract the public-key component from the private-key, use openssl 2292 like this: 2294 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 2296 This results in the file rsa.public containing the key information 2297 similar to this: 2299 -----BEGIN PUBLIC KEY----- 2300 MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l 2301 MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E 2302 XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB 2303 -----END PUBLIC KEY----- 2305 This public-key data (without the BEGIN and END tags) is placed in 2306 the DNS. With the signature, canonical email contents and public 2307 key, a verifying system can test the validity of the signature. The 2308 openssl invocation to verify a signature looks like this: 2310 openssl dgst -verify rsa.public -sha1 -signature signature.file \ 2311 . 2346 Appendix E. Edit History 2348 E.1 Changes since -allman-01 version 2350 The following changes were made between draft-allman-dkim-base-01 and 2351 draft-ietf-dkim-base-00: 2353 o Remove references to Sender Signing Policy document. Such 2354 consideration is implicitly included in Section 6.5. 2356 o Added ABNF for all tags. 2358 o Updated references (still includes some references to expired 2359 drafts, notably [ID-AUTH-RES]. 2361 o Significant wordsmithing. 2363 E.2 Changes since -allman-00 version 2365 The following changes were made between draft-allman-dkim-base-00 and 2366 draft-allman-dkim-base-01: 2368 o Changed "c=" tag to separate out header from body 2369 canonicalization. 2371 o Eliminated "nowsp" canonicalization in favor of "relaxed", which 2372 is somewhat less relaxed (but more secure) than "nowsp". 2374 o Moved the (empty) Compliance section to the Sender Signing Policy 2375 document. 2377 o Added several IANA Considerations. 2379 o Fixed a number of grammar and formatting errors. 2381 Intellectual Property Statement 2383 The IETF takes no position regarding the validity or scope of any 2384 Intellectual Property Rights or other rights that might be claimed to 2385 pertain to the implementation or use of the technology described in 2386 this document or the extent to which any license under such rights 2387 might or might not be available; nor does it represent that it has 2388 made any independent effort to identify any such rights. Information 2389 on the procedures with respect to rights in RFC documents can be 2390 found in BCP 78 and BCP 79. 2392 Copies of IPR disclosures made to the IETF Secretariat and any 2393 assurances of licenses to be made available, or the result of an 2394 attempt made to obtain a general license or permission for the use of 2395 such proprietary rights by implementers or users of this 2396 specification can be obtained from the IETF on-line IPR repository at 2397 http://www.ietf.org/ipr. 2399 The IETF invites any interested party to bring to its attention any 2400 copyrights, patents or patent applications, or other proprietary 2401 rights that may cover technology that may be required to implement 2402 this standard. Please address the information to the IETF at 2403 ietf-ipr@ietf.org. 2405 The IETF has been notified of intellectual property rights claimed in 2406 regard to some or all of the specification contained in this 2407 document. For more information consult the online list of claimed 2408 rights. 2410 Disclaimer of Validity 2412 This document and the information contained herein are provided on an 2413 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2414 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2415 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2416 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2417 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2418 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2420 Copyright Statement 2422 Copyright (C) The Internet Society (2006). This document is subject 2423 to the rights, licenses and restrictions contained in BCP 78, and 2424 except as set forth therein, the authors retain all their rights. 2426 Acknowledgment 2428 Funding for the RFC Editor function is currently provided by the 2429 Internet Society.