idnits 2.17.1 draft-ietf-dkim-base-04.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 3038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3023. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1239 has weird spacing: '... email elec...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2006) is 6495 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: 'MIME' is mentioned on line 2747, but not defined ** 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 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 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: January 16, 2007 J. Callas 5 PGP Corporation 6 M. Delany 7 M. Libbey 8 Yahoo! Inc 9 J. Fenton 10 M. Thomas 11 Cisco Systems, Inc. 12 July 15, 2006 14 DomainKeys Identified Mail (DKIM) Signatures 15 draft-ietf-dkim-base-04 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 16, 2007. 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 54 protecting message signer identity and the integrity of the messages 55 they convey while retaining the functionality of Internet email as it 56 is known today. Protection of email identity may assist in the 57 global control of "spam" and "phishing". 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 69 1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.3 Simple Key Management . . . . . . . . . . . . . . . . . . 6 71 2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 72 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.4 Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7 76 2.5 Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 77 2.6 DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 78 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 9 79 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.2 Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 81 3.3 Signing and Verification Algorithms . . . . . . . . . . . 12 82 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 83 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 18 84 3.6 Key Management and Representation . . . . . . . . . . . . 26 85 3.7 Computing the Message Hashes . . . . . . . . . . . . . . . 30 86 3.8 Signing by Parent Domains . . . . . . . . . . . . . . . . 32 87 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 32 88 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 32 89 5.1 Determine if the Email Should be Signed and by Whom . . . 33 90 5.2 Select a private-key and corresponding selector 91 information . . . . . . . . . . . . . . . . . . . . . . . 33 92 5.3 Normalize the Message to Prevent Transport Conversions . . 34 93 5.4 Determine the header fields to Sign . . . . . . . . . . . 34 94 5.5 Compute the Message Hash and Signature . . . . . . . . . . 36 95 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 36 96 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 97 6.1 Extract Signatures from the Message . . . . . . . . . . . 37 98 6.2 Communicate Verification Results . . . . . . . . . . . . . 43 99 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 101 7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 44 102 7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 103 7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 45 104 7.4 _domainkey DNS TXT Record Tag Specifications . . . . . . . 46 105 7.5 DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 47 106 7.6 DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 47 107 8. Security Considerations . . . . . . . . . . . . . . . . . . 47 108 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 47 109 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 48 110 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 49 111 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 49 112 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 50 113 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 51 114 8.7 Intentionally malformed Key Records . . . . . . . . . . . 51 115 8.8 Intentionally Malformed DKIM-Signature header fields . . . 51 116 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 51 117 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 51 118 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 119 9.1 Normative References . . . . . . . . . . . . . . . . . . . 52 120 9.2 Informative References . . . . . . . . . . . . . . . . . . 52 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 122 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 54 123 A.1 The user composes an email . . . . . . . . . . . . . . . . 55 124 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 55 125 A.3 The email signature is verified . . . . . . . . . . . . . 56 126 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 57 127 B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 57 128 B.2 Outsourced Business Functions . . . . . . . . . . . . . . 57 129 B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 57 130 B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 58 131 B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 58 132 B.6 Third-party Message Transmission . . . . . . . . . . . . . 59 133 B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 59 134 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 59 135 D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 61 136 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 137 F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 62 138 F.1 Changes since -ietf-03 version . . . . . . . . . . . . . . 62 139 F.2 Changes since -ietf-02 version . . . . . . . . . . . . . . 63 140 F.3 Changes since -ietf-01 version . . . . . . . . . . . . . . 64 141 F.4 Changes since -ietf-00 version . . . . . . . . . . . . . . 65 142 F.5 Changes since -allman-01 version . . . . . . . . . . . . . 66 143 F.6 Changes since -allman-00 version . . . . . . . . . . . . . 66 144 Intellectual Property and Copyright Statements . . . . . . . 67 146 1. Introduction 148 [[Note: text in double square brackets (such as this text) will be 149 deleted before publication.]] 151 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 152 messages can be cryptographically signed, permitting a signing domain 153 to claim responsibility for the introduction of a message into the 154 mail stream. Message recipients can verify the signature by querying 155 the signer's domain directly to retrieve the appropriate public key, 156 and thereby confirm that the message was attested to by a party in 157 possession of the private key for the signing domain. 159 The approach taken by DKIM differs from previous approaches to 160 message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: 162 o the message signature is written as a message header field so that 163 neither human recipients nor existing MUA (Mail User Agent) 164 software are confused by signature-related content appearing in 165 the message body, 167 o there is no dependency on public and private key pairs being 168 issued by well-known, trusted certificate authorities, 170 o there is no dependency on the deployment of any new Internet 171 protocols or services for public key distribution or revocation, 173 o signature verification failure does not result in rejection of the 174 message, 176 o no attempt is made to include encryption as part of the mechanism, 178 o archival is not a design goal. 180 DKIM: 182 o is compatible with the existing email infrastructure and 183 transparent to the fullest extent possible 185 o requires minimal new infrastructure 187 o can be implemented independently of clients in order to reduce 188 deployment time 190 o does not require the use of an additional trusted third party 191 (such as a certificate authority or other entity) which might 192 impose significant costs or introduce delays to deployment 194 o can be deployed incrementally 196 o allows delegation of signing to third parties 198 1.1 Signing Identity 200 DKIM separates the question of the identity of the signer of the 201 message from the purported author of the message. In particular, a 202 signature includes the identity of the signer. Verifiers can use the 203 signing information to decide how they want to process the message. 204 The signing identity is included as part of the signature header 205 field. 207 INFORMATIVE RATIONALE: The signing identity specified by a DKIM 208 signature is not required to match an address in any particular 209 header field because of the broad methods of interpretation by 210 recipient mail systems, including MUAs. 212 1.2 Scalability 214 DKIM is designed to support the extreme scalability requirements 215 which characterize the email identification problem. There are 216 currently over 70 million domains and a much larger number of 217 individual addresses. DKIM seeks to preserve the positive aspects of 218 the current email infrastructure, such as the ability for anyone to 219 communicate with anyone else without introduction. 221 1.3 Simple Key Management 223 DKIM differs from traditional hierarchical public-key systems in that 224 no key signing infrastructure is required; the verifier requests the 225 public key from the claimed signer directly. 227 The DNS is proposed as the initial mechanism for publishing public 228 keys. DKIM is designed to be extensible to other key fetching 229 services as they become available. 231 2. Terminology and Definitions 233 This section defines terms used in the rest of the document. Syntax 234 descriptions use the form described in Augmented BNF for Syntax 235 Specifications [RFC4234]. 237 2.1 Signers 239 Elements in the mail system that sign messages are referred to as 240 signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission 241 Agents), MTAs (Mail Transfer Agents), or other agents such as mailing 242 list exploders. In general any signer will be involved in the 243 injection of a message into the message system in some way. The key 244 issue is that a message must be signed before it leaves the 245 administrative domain of the signer. 247 2.2 Verifiers 249 Elements in the mail system that verify signatures are referred to as 250 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 251 In most cases it is expected that verifiers will be close to an end 252 user (reader) of the message or some consuming agent such as a 253 mailing list exploder. 255 2.3 White Space 257 There are three forms of white space: 259 o WSP represents simple white space, i.e., a space or a tab 260 character, and is inherited from[RFC2822]. 262 o SWSP is streaming white space, defined as WSP plus the CR and LF 263 characters. 265 o FWS, also from [RFC2822], is folding white space. It allows 266 multiple lines separated by CRLF followed by at least one white 267 space, to be joined. 269 The formal ABNF for SWSP is: 271 SWSP = CR / LF / WSP ; streaming white space 273 2.4 Common ABNF Tokens 275 The following ABNF tokens are used elsewhere in this document. 277 hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] 278 base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) 280 2.5 Imported ABNF Tokens 282 The following tokens are imported from other RFCs as noted. Those 283 RFCs should be considered definitive. However, all tokens having 284 names beginning with "obs-" should be excluded from this import, as 285 they have been obsoleted and are expected to go away in future 286 editions of those RFCs. 288 The following tokens are imported from [RFC2821]: 290 o "Local-part" (implementation warning: this permits quoted 291 strings) 293 o "sub-domain" 295 The following definitions are imported from [RFC2822]: 297 o "WSP" (space or tab) 299 o "FWS" (folding white space) 301 o "field-name" (name of a header field) 303 o "dot-atom-text" (in the local-part of an email address) 305 The following tokens are imported from [RFC2045]: 307 o "qp-section" (a single line of quoted-printable-encoded text) 309 o "hex-octet" (a quoted-printable encoded octet) 311 INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not 312 obey the rules of RFC 4234 and must be interpreted accordingly, 313 particularly as regards case folding. 315 Other tokens not defined herein are imported from [RFC4234]. These 316 are intuitive primitives such as SP, ALPHA, CRLF, etc. 318 2.6 DKIM-Quoted-Printable 320 The DKIM-Quoted-Printable encoding syntax resembles that described in 321 Quoted-Printable [RFC2045] section 6.7: any character MAY be encoded 322 as an "=" followed by two hexadecimal digits from the alphabet 323 "0123456789ABCDEF" (no lower case characters permitted) representing 324 the hexadecimal-encoded integer value of that character. All control 325 characters (those with values < %x20), eight-bit characters (values > 326 %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon 327 (";", %x3B) MUST be encoded. Note that all white space, including 328 SPACE, CR and LF characters, MUST be encoded. After encoding, FWS 329 MAY be added at arbitrary locations in order to avoid excessively 330 long lines; such white space is NOT part of the value, and MUST be 331 removed before decoding. 333 ABNF: 334 dkim-quoted-printable = 335 *(FWS / hex-octet / dkim-safe-char) 336 ; hex-octet is from RFC 2045 337 dkim-safe-char = %x21-3A / %x3C / %x3E-7E 338 ; '!' - ':', '<', '>' - '~' 339 ; Characters not listed as "mail-safe" in 340 ; RFC 2049 are also not recommended. 342 INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- 343 Printable as defined in RFC 2045 in several important ways: 345 1. White space in the input text, including CR and LF, must be 346 encoded. RFC 2045 does not require such encoding, and does 347 not permit encoded of CR or LF characters that are part of a 348 CRLF line break. 350 2. White space in the encoded text is ignored. This is to allow 351 DKIM-Quoted-Printable to be wrapped as needed in headers. In 352 particular, RFC 2045 requires that line breaks in the input be 353 represented as physical line breaks; that is not the case 354 here. 356 3. The "soft line break" syntax ("=" as the last non-white-space 357 character on the line) does not apply. 359 4. DKIM-Quoted-Printable does not require that encoded lines be 360 no more than 76 characters long (although there may be other 361 requirements depending on the context in which the encoded 362 text is being used). 364 3. Protocol Elements 366 Protocol Elements are conceptual parts of the protocol that are not 367 specific to either signers or verifiers. The protocol descriptions 368 for signers and verifiers are described in later sections (Signer 369 Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This 370 section must be read in the context of those sections. 372 3.1 Selectors 374 To support multiple concurrent public keys per signing domain, the 375 key namespace is subdivided using "Selectors". For example, 376 Selectors might indicate the names of office locations (e.g., 377 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 378 (e.g., "january2005", "february2005", etc.), or even the individual 379 user. 381 Selectors are needed to support some important use cases. For 382 example: 384 o Domains which want to delegate signing capability for a specific 385 address for a given duration to a partner, such as an advertising 386 provider or other out-sourced function. 388 o Domains which want to allow frequent travelers to send messages 389 locally without the need to connect with a particular MSA. 391 o "Affinity" domains (e.g., college alumni associations) which 392 provide forwarding of incoming mail but which do not operate a 393 mail submission agent for outgoing mail. 395 Periods are allowed in Selectors and are component separators. When 396 keys are retrieved from the DNS, periods in Selectors define DNS 397 label boundaries in a manner similar to the conventional use in 398 domain names. Selector components might be used to combine dates 399 with locations; for example, "march2005.reykjavik". In a DNS 400 implementation, this can be used to allow delegation of a portion of 401 the Selector name-space. 403 ABNF: 404 selector = sub-domain *( "." sub-domain ) 406 The number of public keys and corresponding Selectors for each domain 407 are determined by the domain owner. Many domain owners will be 408 satisfied with just one Selector whereas administratively distributed 409 organizations may choose to manage disparate Selectors and key pairs 410 in different regions or on different email servers. 412 Beyond administrative convenience, Selectors make it possible to 413 seamlessly replace public keys on a routine basis. If a domain 414 wishes to change from using a public key associated with Selector 415 "january2005" to a public key associated with Selector 416 "february2005", it merely makes sure that both public keys are 417 advertised in the public-key repository concurrently for the 418 transition period during which email may be in transit prior to 419 verification. At the start of the transition period, the outbound 420 email servers are configured to sign with the "february2005" private- 421 key. At the end of the transition period, the "january2005" public 422 key is removed from the public-key repository. 424 INFORMATIVE NOTE: A key may also be revoked as described below. 425 The distinction between revoking and removing a key selector 426 record is subtle. When phasing out keys as described above, a 427 signing domain would probably simply remove the key record after 428 the transition period. However, a signing domain could elect to 429 revoke the key (but maintain the key record) for a further period. 430 There is no defined semantic difference between a revoked key and 431 a removed key. 433 While some domains may wish to make Selector values well known, 434 others will want to take care not to allocate Selector names in a way 435 that allows harvesting of data by outside parties. E.g., if per-user 436 keys are issued, the domain owner will need to make the decision as 437 to whether to associate this Selector directly with the user name, or 438 make it some unassociated random value, such as a fingerprint of the 439 public key. 441 INFORMATIVE IMPLEMENTERS' NOTE: reusing a Selector with a new key 442 (for example, changing the key associated with a user's name) 443 makes it impossible to tell the difference between a message that 444 didn't verify because the key is no longer valid versus a message 445 that is actually forged. Signers should not change the key 446 associated with a Selector. When creating a new key, signers 447 should associate it with a new Selector. 449 3.2 Tag=Value Lists 451 DKIM uses a simple "tag=value" syntax in several contexts, including 452 in messages and domain signature records. 454 Values are a series of strings containing either plain text, "base64" 455 text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, 456 section 6.7), or "dkim-quoted-printable" (as defined above). The 457 name of the tag will determine the encoding of each value; however, 458 no encoding may include the semicolon (";") character, since that 459 separates tag-specs. 461 INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" 462 defined below (as "tag-value") only includes 7-bit characters, an 463 implementation that wished to anticipate future standards would be 464 advised to not preclude the use of UTF8-encoded text in tag=value 465 lists. 467 Formally, the syntax rules are: 468 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 469 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 470 tag-name = ALPHA 0*ALNUMPUNC 471 tag-value = [ 1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR ) ] 472 ; WSP and FWS prohibited at beginning and end 473 VALCHAR = %x21-3A / %x3C-7E 474 ; EXCLAMATION to TILDE except SEMICOLON 475 ALNUMPUNC = ALPHA / DIGIT / "_" 477 Note that WSP is allowed anywhere around tags; in particular, any WSP 478 after the "=" and any WSP before the terminating ";" is not part of 479 the value; however, WSP inside the value is significant. 481 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 482 processed as case sensitive unless the specific tag description of 483 semantics specifies case insensitivity. 485 Tags with duplicate names MUST NOT be specified within a single tag- 486 list. 488 Whitespace within a value MUST be retained unless explicitly excluded 489 by the specific tag description. 491 Tag=value pairs that represent the default value MAY be included to 492 aid legibility. 494 Unrecognized tags MUST be ignored. 496 Tags that have an empty value are not the same as omitted tags. An 497 omitted tag is treated as having the default value; a tag with an 498 empty value explicitly designates the empty string as the value. For 499 example, "g=" does not mean "g=*", even though "g=*" is the default 500 for that tag. 502 3.3 Signing and Verification Algorithms 504 DKIM supports multiple digital signature algorithms. Two algorithms 505 are defined by this specification at this time: rsa-sha1, and rsa- 506 sha256. The rsa-sha256 algorithm is the default if no algorithm is 507 specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. 508 Signers MUST implement and SHOULD sign using rsa-sha256. 510 3.3.1 The rsa-sha1 Signing Algorithm 512 The rsa-sha1 Signing Algorithm computes a message hash as described 513 in Section 3.7 below using SHA-1 as the hash-alg. That hash is then 514 signed by the signer using the RSA algorithm (defined in PKCS#1 515 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 516 The hash MUST NOT be truncated or converted into any form other than 517 the native binary form before being signed. 519 3.3.2 The rsa-sha256 Signing Algorithm 521 The rsa-sha256 Signing Algorithm computes a message hash as described 522 in Section 3.7 below using SHA-256 as the hash-alg. That hash is 523 then signed by the signer using the RSA algorithm (actually PKCS#1 524 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 525 The hash MUST NOT be truncated or converted into any form other than 526 the native binary form before being signed. 528 3.3.3 Other algorithms 530 Other algorithms MAY be defined in the future. Verifiers MUST ignore 531 any signatures using algorithms that they do not implement. 533 3.3.4 Key sizes 535 Selecting appropriate key sizes is a trade-off between cost, 536 performance and risk. Since short RSA keys more easily succumb to 537 off-line attacks, signers MUST use RSA keys of at least 1024 bits for 538 long-lived keys. Verifiers MUST be able to validate signatures with 539 keys ranging from 512 bits to 2048 bits, and they MAY be able to 540 validate signatures with larger keys. Verifier policies may use the 541 length of the signing key as one metric for determining whether a 542 signature is acceptable. 544 Factors that should influence the key size choice include: 546 o The practical constraint that large keys may not fit within a 512 547 byte DNS UDP response packet 549 o The security constraint that keys smaller than 1024 bits are 550 subject to off-line attacks 552 o Larger keys impose higher CPU costs to verify and sign email 554 o Keys can be replaced on a regular basis, thus their lifetime can 555 be relatively short 557 o The security goals of this specification are modest compared to 558 typical goals of public-key systems 560 See [RFC3766] for further discussion of selecting key sizes. 562 3.4 Canonicalization 564 Empirical evidence demonstrates that some mail servers and relay 565 systems modify email in transit, potentially invalidating a 566 signature. There are two competing perspectives on such 567 modifications. For most signers, mild modification of email is 568 immaterial to the authentication status of the email. For such 569 signers a canonicalization algorithm that survives modest in-transit 570 modification is preferred. 572 Other signers demand that any modification of the email, however 573 minor, result in a signature verification failure. These signers 574 prefer a canonicalization algorithm that does not tolerate in-transit 575 modification of the signed email. 577 Some signers may be willing to accept modifications to header fields 578 that are within the bounds of email standards such as [RFC2822], but 579 are unwilling to accept any modification to the body of messages. 581 To satisfy all requirements, two canonicalization algorithms are 582 defined for each of the header and the body: a "simple" algorithm 583 that tolerates almost no modification and a "relaxed" algorithm that 584 tolerates common modifications such as white-space replacement and 585 header field line re-wrapping. A signer MAY specify either algorithm 586 for header or body when signing an email. If no canonicalization 587 algorithm is specified by the signer, the "simple" algorithm defaults 588 for both header and body. Verifiers MUST implement both 589 canonicalization algorithms. Note that the header and body may use 590 different canonicalization algorithms. Further canonicalization 591 algorithms MAY be defined in the future; verifiers MUST ignore any 592 signatures that use unrecognized canonicalization algorithms. 594 [[WORKING GROUP DISCUSSION POINT: If a message is transmitted 595 using CHUNKING (that is, BDAT instead of the DATA command) and 596 BODY=BINARYMIME [RFC3030] then the body should be treated as a 597 binary stream, and no canonicalization whatsoever should be done. 598 Do we want to leave this for the future, say that canonicalization 599 is ignored in this circumstance, or add a third "binary" body 600 canonicalization algorithm? Or something else, of course.]] 602 Canonicalization simply prepares the email for presentation to the 603 signing or verification algorithm. It MUST NOT change the 604 transmitted data in any way. Canonicalization of header fields and 605 body are described below. 607 NOTE: This section assumes that the message is already in "network 608 normal" format (e.g., text is ASCII encoded, lines are separated with 609 CRLF characters, etc.). See also Section 5.3 for information about 610 normalizing the message. 612 3.4.1 The "simple" Header Field Canonicalization Algorithm 614 The "simple" header canonicalization algorithm does not change header 615 fields in any way. Header fields MUST be presented to the signing or 616 verification algorithm exactly as they are in the message being 617 signed or verified. In particular, header field names MUST NOT be 618 case folded and white space MUST NOT be changed. 620 3.4.2 The "relaxed" Header Field Canonicalization Algorithm 622 The "relaxed" header canonicalization algorithm MUST apply the 623 following steps in order: 625 o Convert all header field names (not the header field values) to 626 lower case. For example, convert "SUBJect: AbC" to "subject: 627 AbC". 629 o Unfold all header field continuation lines as described in 630 [RFC2822]; in particular, lines with terminators embedded in 631 continued header field values (that is, CRLF sequences followed by 632 WSP) MUST be interpreted without the CRLF. Implementations MUST 633 NOT remove the CRLF at the end of the header field value. 635 o Convert all sequences of one or more WSP characters to a single SP 636 character. WSP characters here include those before and after a 637 line folding boundary. 639 o Delete all WSP characters at the end of each unfolded header field 640 value. 642 o Delete any WSP characters remaining before and after the colon 643 separating the header field name from the header field value. The 644 colon separator MUST be retained. 646 3.4.3 The "simple" Body Canonicalization Algorithm 648 The "simple" body canonicalization algorithm ignores all empty lines 649 at the end of the message body. An empty line is a line of zero 650 length after removal of the line terminator. If there is no trailing 651 CRLF on the message, a CRLF is added. It makes no other changes to 652 the message body. In more formal terms, the "simple" body 653 canonicalization algorithm converts "0*CRLF" at the end of the body 654 to a single "CRLF". 656 3.4.4 The "relaxed" Body Canonicalization Algorithm 658 [[This section may be deleted; see discussion below.]] The "relaxed" 659 body canonicalization algorithm: 661 o Ignores all white space at the end of lines. Implementations MUST 662 NOT remove the CRLF at the end of the line. 664 o Reduces all sequences of WSP within a line to a single SP 665 character. 667 o Ignores all empty lines at the end of the message body. "Empty 668 line" is defined in Section 3.4.3. 670 [[WORKING GROUP DISCUSSION POINT (ISSUE 1326): Mike Thomas has 671 found bare CRs in the wild that are getting converted to CRLF by 672 some MTAs and thus breaking signatures. Shall we (a) drop 673 "relaxed" until we can figure out how to do it right and then put 674 it in as an extension, (b) change "relaxed" to handle this case, 675 probably by having it convert bare CR and LF to CRLF, or (c) 676 something else?]] 678 3.4.5 Body Length Limits 680 A body length count MAY be specified to limit the signature 681 calculation to an initial prefix of the body text, measured in 682 octets. If the body length count is not specified then the entire 683 message body is signed. 685 INFORMATIVE RATIONALE: This capability is provided because it is 686 very common for mailing lists to add trailers to messages (e.g., 687 instructions how to get off the list). Until those messages are 688 also signed, the body length count is a useful tool for the 689 verifier since it may as a matter of policy accept messages having 690 valid signatures with extraneous data. 692 INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables 693 an attack in which an attacker modifies a message to include 694 content that solely benefits the attacker. It is possible for the 695 appended content to completely replace the original content in the 696 end recipient's eyes and to defeat duplicate message detection 697 algorithms. To avoid this attack, signers should be wary of using 698 this tag, and verifiers might wish to ignore the tag or remove 699 text that appears after the specified content length, perhaps 700 based on other criteria. 702 The body length count allows the signer of a message to permit data 703 to be appended to the end of the body of a signed message. The body 704 length count MUST be calculated following the canonicalization 705 algorithm; for example, any white space ignored by a canonicalization 706 algorithm is not included as part of the body length count. Signers 707 of MIME messages that include a body length count SHOULD be sure that 708 the length extends to the closing MIME boundary string. 710 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 711 the only acceptable modifications are to add to the MIME postlude 712 would use a body length count encompassing the entire final MIME 713 boundary string, including the final "--CRLF". A signer wishing 714 to allow additional MIME parts but not modification of existing 715 parts would use a body length count extending through the final 716 MIME boundary string, omitting the final "--CRLF". 718 A body length count of zero means that the body is completely 719 unsigned. 721 Signers wishing to ensure that no modification of any sort can occur 722 should specify the "simple" canonicalization algorithm for both 723 header and body and omit the body length count. 725 3.4.6 Canonicalization Examples (INFORMATIVE) 727 (In the following examples, actual white space is used only for 728 clarity. The actual input and output text is designated using 729 bracketed descriptors: "" for a space character, "" for a 730 tab character, and "" for a carriage-return/line-feed sequence. 731 For example, "X Y" and "XY" represent the same three 732 characters.) 734 Example 1: A message reading: 735 A: X 736 B : Y 737 Z 738 739 C 740 D E 741 742 744 when canonicalized using relaxed canonicalization for both header and 745 body results in a header reading: 746 a:X 747 b:Y Z 749 and a body reading: 750 C 751 D E 753 Example 2: The same message canonicalized using simple 754 canonicalization for both header and body results in a header 755 reading: 756 A: X 757 B : Y 758 Z 760 and a body reading: 761 C 762 D E 764 Example 3: When processed using relaxed header canonicalization and 765 simple body canonicalization, the canonicalized version has a header 766 of: 767 a:X 768 b:Y Z 770 and a body reading: 771 C 772 D E 774 3.5 The DKIM-Signature header field 776 The signature of the email is stored in the "DKIM-Signature:" header 777 field. This header field contains all of the signature and key- 778 fetching data. The DKIM-Signature value is a tag-list as described 779 in Section 3.2. 781 The "DKIM-Signature:" header field SHOULD be treated as though it 782 were a trace header field as defined in section 3.6 of [RFC2822], and 783 hence SHOULD NOT be reordered and SHOULD be prepended to the message. 785 The "DKIM-Signature:" header field being created or verified is 786 always included in the signature calculation, after the body of the 787 message; however, when calculating or verifying the signature, the 788 value of the b= tag (signature value) of that DKIM-Signature header 789 field MUST be treated as though it were an empty string. Unknown 790 tags in the "DKIM-Signature:" header field MUST be included in the 791 signature calculation but MUST be otherwise ignored by verifiers. 792 Other "DKIM-Signature:" header fields that are included in the 793 signature should be treated as normal header fields; in particular, 794 the b= tag is not treated specially. 796 The encodings for each field type are listed below. Tags described 797 as qp-section are as described in section 6.7 of MIME Part One 798 [RFC2045], with the additional conversion of semicolon characters to 799 "=3B"; intuitively, this is one line of quoted-printable encoded 800 text. Tags described as dkim-quoted-printable are as defined in 801 Section 2.6. 803 Tags on the DKIM-Signature header field along with their type and 804 requirement status are shown below. Unrecognized tags MUST be 805 ignored. 807 v= Version (MUST be included). This tag defines the version of this 808 specification that applies to the signature record. It MUST have 809 the value 0.4. 811 ABNF: 813 sig-v-tag = %x76 [FWS] "=" [FWS] "0.4" 815 INFORMATIVE NOTE: DKIM-Signature version numbers are 816 expected to increase arithmetically as new versions of this 817 specification are released. 819 [[INFORMATIVE NOTE: Upon publication, this version number 820 should be changed to "1", and this note should be deleted.]] 822 a= The algorithm used to generate the signature (plain-text; 823 REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; 824 signers SHOULD sign using "rsa-sha256". See Section 3.3 for a 825 description of algorithms. 827 ABNF: 829 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 830 sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h 831 sig-a-tag-k = "rsa" / x-sig-a-tag-k 832 sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h 833 x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension 834 x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension 836 b= The signature data (base64; REQUIRED). Whitespace is ignored in 837 this value and MUST be ignored when re-assembling the original 838 signature. In particular, the signing process can safely insert 839 FWS in this value in arbitrary places to conform to line-length 840 limits. See Signer Actions (Section 5) for how the signature is 841 computed. 843 ABNF: 845 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 846 sig-b-tag-data = base64string 848 bh= The hash of the canonicalized body part of the message as limited 849 by the "l=" tag (base64; REQUIRED). Whitespace is ignored in 850 this value and MUST be ignored when re-assembling the original 851 signature. In particular, the signing process can safely insert 852 FWS in this value in arbitrary places to conform to line-length 853 limits. See Section 3.7 for how the body hash is computed. 855 ABNF: 857 sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data 858 sig-bh-tag-data = base64string 860 c= Message canonicalization (plain-text; OPTIONAL, default is 861 "simple/simple"). This tag informs the verifier of the type of 862 canonicalization used to prepare the message for signing. It 863 consists of two names separated by a "slash" (%d47) character, 864 corresponding to the header and body canonicalization algorithms 865 respectively. These algorithms are described in Section 3.4. If 866 only one algorithm is named, that algorithm is used for the 867 header and "simple" is used for the body. For example, 868 "c=relaxed" is treated the same as "c=relaxed/simple". 870 ABNF: 872 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 873 ["/" sig-c-tag-alg] 874 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 875 x-sig-c-tag-alg = hyphenated-word ; for later extension 877 d= The domain of the signing entity (plain-text; REQUIRED). This is 878 the domain that will be queried for the public key. This domain 879 MUST be the same as or a parent domain of the "i=" tag (the 880 signing identity, as described below), or it MUST meet the 881 requirements for parent domain signing described in Section 3.8. 882 When presented with a signature that does not meet these 883 requirement, verifiers MUST consider the signature invalid. 885 Internationalized domain names MUST be punycode-encoded 886 [RFC3492]. 888 ABNF: 890 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 891 domain-name = sub-domain 1*("." sub-domain) 892 ; from RFC 2821 Domain, but excluding address-literal 894 h= Signed header fields (plain-text, but see description; REQUIRED). 895 A colon-separated list of header field names that identify the 896 header fields presented to the signing algorithm. The field MUST 897 contain the complete list of header fields in the order presented 898 to the signing algorithm. The field MAY contain names of header 899 fields that do not exist when signed; nonexistent header fields 900 do not contribute to the signature computation (that is, they are 901 treated as the null input, including the header field name, the 902 separating colon, the header field value, and any CRLF 903 terminator). The field MUST NOT include the DKIM-Signature 904 header field that is being created or verified, but may include 905 others. Folding white space (FWS) MAY be included on either side 906 of the colon separator. Header field names MUST be compared 907 against actual header field names in a case insensitive manner. 908 This list MUST NOT be empty. See Section 5.4 for a discussion of 909 choosing header fields to sign. 911 ABNF: 913 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 914 0*( *FWS ":" *FWS hdr-name ) 915 hdr-name = field-name 917 INFORMATIVE EXPLANATION: By "signing" header fields that do 918 not actually exist, a signer can prevent insertion of those 919 header fields before verification. However, since a signer 920 cannot possibly know what header fields might be created in 921 the future, and that some MUAs might present header fields 922 that are embedded inside a message (e.g., as a message/rfc822 923 content type), the security of this solution is not total. 925 INFORMATIVE EXPLANATION: The exclusion of the header field 926 name and colon as well as the header field value for non- 927 existent header fields prevents an attacker from inserting an 928 actual header field with a null value. 930 i= Identity of the user or agent (e.g., a mailing list manager) on 931 behalf of which this message is signed (dkim-quoted-printable; 932 OPTIONAL, default is an empty local-part followed by an "@" 933 followed by the domain from the "d=" tag). The syntax is a 934 standard email address where the local-part MAY be omitted. The 935 domain part of the address MUST be the same as or a subdomain of 936 the value of the "d=" tag. 938 Internationalized domain names MUST be punycode-encoded 939 [RFC3492]. 941 ABNF: 943 sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name 945 INFORMATIVE NOTE: The local-part of the "i=" tag is optional 946 because in some cases a signer may not be able to establish a 947 verified individual identity. In such cases, the signer may 948 wish to assert that although it is willing to go as far as 949 signing for the domain, it is unable or unwilling to commit 950 to an individual user name within their domain. It can do so 951 by including the domain part but not the local-part of the 952 identity. 954 INFORMATIVE DISCUSSION: This document does not require the 955 value of the "i=" tag to match the identity in any message 956 header field fields. This is considered to be a verifier 957 policy issue. Constraints between the value of the "i=" tag 958 and other identities in other header fields seek to apply 959 basic authentication into the semantics of trust associated 960 with a role such as content author. Trust is a broad and 961 complex topic and trust mechanisms are subject to highly 962 creative attacks. The real-world efficacy of any but the 963 most basic bindings between the "i=" value and other 964 identities is not well established, nor is its vulnerability 965 to subversion by an attacker. Hence reliance on the use of 966 these options should be strictly limited. In particular it 967 is not at all clear to what extent a typical end-user 968 recipient can rely on any assurances that might be made by 969 successful use of the "i=" options. 971 l= Body length count (plain-text unsigned decimal integer; OPTIONAL, 972 default is entire body). This tag informs the verifier of the 973 number of octets in the body of the email after canonicalization 974 included in the cryptographic hash, starting from 0 immediately 975 following the CRLF preceding the body. This value MUST NOT be 976 larger than the actual number of octets in the canonicalized 977 message body. 979 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 980 allow display of fraudulent content without appropriate 981 warning to end users. The l= tag is intended for increasing 982 signature robustness when sending to mailing lists that both 983 modify their content and do not sign their messages. 984 However, using the l= tag enables attacks in which an 985 intermediary with malicious intent modifies a message to 986 include content that solely benefits the attacker. It is 987 possible for the appended content to completely replace the 988 original content in the end recipient's eyes and to defeat 989 duplicate message detection algorithms. Examples are 990 described in Security Considerations (Section 8). To avoid 991 this attack, signers should be extremely wary of using this 992 tag, and verifiers might wish to ignore the tag or remove 993 text that appears after the specified content length. 995 INFORMATIVE NOTE: The value of the l= tag is constrained to 996 76 decimal digits, which will fit in a 256-bit binary integer 997 field. This constraint is not intended to predict the size 998 of future messages, but is intended to remind the implementer 999 to check the length of this and all other tags during 1000 verification. Implementers may need to limit the actual 1001 value expressed to a value smaller than 10^76, e.g., to allow 1002 a message to fit within the available storage space. 1004 ABNF: 1006 sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT 1008 q= A colon-separated list of query methods used to retrieve the 1009 public key (plain-text; OPTIONAL, default is "dns/txt"). Each 1010 query method is of the form "type[/options]", where the syntax 1011 and semantics of the options depends on the type and specified 1012 options. If there are multiple query mechanisms listed, the 1013 choice of query mechanism MUST NOT change the interpretation of 1014 the signature. Implementations MUST use the recognized query 1015 mechanisms in the order presented. 1017 Currently the only valid value is "dns/txt" which defines the DNS 1018 TXT record lookup algorithm described elsewhere in this document. 1019 The only option defined for the "dns" query type is "txt", which 1020 MUST be included. Verifiers and signers MUST support "dns/txt". 1022 ABNF: 1024 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 1025 *([FWS] ":" [FWS] sig-q-tag-method) 1026 sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] 1027 x-sig-q-tag-type = hyphenated-word ; for future extension 1028 x-sig-q-tag-args = qp-hdr-value 1030 s= The Selector subdividing the namespace for the "d=" (domain) tag 1031 (plain-text; REQUIRED). 1033 ABNF: 1035 sig-s-tag = %x73 [FWS] "=" [FWS] selector 1037 t= Signature Timestamp (plain-text unsigned decimal integer; 1038 RECOMMENDED, default is an unknown creation time). The time that 1039 this signature was created. The format is the number of seconds 1040 since 00:00:00 on January 1, 1970 in the UTC time zone. The 1041 value is expressed as an unsigned integer in decimal ASCII. This 1042 value is not constrained to fit into a 31- or 32-bit integer. 1043 Implementations SHOULD be prepared to handle values up to at 1044 least 10^12 (until approximately AD 200,000; this fits into 40 1045 bits). To avoid denial of service attacks, implementations MAY 1046 consider any value longer than 12 digits to be infinite. 1048 ABNF: 1050 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 1052 x= Signature Expiration (plain-text unsigned decimal integer; 1053 RECOMMENDED, default is no expiration). The format is the same 1054 as in the "t=" tag, represented as an absolute date, not as a 1055 time delta from the signing timestamp. The value is expressed as 1056 an unsigned integer in decimal ASCII, with the same contraints on 1057 the value in the "t=" tag. Signatures MAY be considered invalid 1058 if the verification time at the verifier is past the expiration 1059 date. The verification time should be the time that the message 1060 was first received at the administrative domain of the verifier 1061 if that time is reliably available; otherwise the current time 1062 should be used. The value of the "x=" tag MUST be greater than 1063 the value of the "t=" tag if both are present. 1065 INFORMATIVE NOTE: The x= tag is not intended as an anti- 1066 replay defense. 1068 ABNF: 1070 sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT 1072 z= Copied header fields (dkim-quoted-printable, but see description; 1073 OPTIONAL, default is null). A vertical-bar-separated list of 1074 selected header fields present when the message was signed, 1075 including both the field name and value. It is not required to 1076 include all header fields present at the time of signing. This 1077 field need not contain the same header fields listed in the "h=" 1078 tag. The header field text itself must encode the vertical bar 1079 ("|", %x7C) character (i.e., vertical bars in the z= text are 1080 metacharacters, and any actual vertical bar characters in a 1081 copied header field must be encoded). Note that all white space 1082 must be encoded, including white space between the colon and the 1083 header field value. After encoding, SWSP MAY be added at 1084 arbitrary locations in order to avoid excessively long lines; 1085 such white space is NOT part of the value of the header field, 1086 and MUST be removed before decoding. 1088 Verifiers MUST NOT use the header field names or copied values 1089 for checking the signature in any way. Copied header field 1090 values are for diagnostic use only. 1092 Header fields with characters requiring conversion (perhaps from 1093 legacy MTAs which are not [RFC2822] compliant) SHOULD be 1094 converted as described in MIME Part Three [RFC2047]. 1096 ABNF: 1097 sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy 1098 *( [FWS] "|" sig-z-tag-copy ) 1099 sig-z-tag-copy = hdr-name ":" qp-hdr-value 1100 qp-hdr-value = dkim-quoted-printable ; with "|" encoded 1102 INFORMATIVE EXAMPLE of a signature header field spread across 1103 multiple continuation lines: 1105 DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; 1106 c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; 1107 h=from:to:subject:date; 1108 z=From:foo@eng.example.net|To:joe@example.com| 1109 Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; 1110 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; 1111 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 1112 VoG4ZHRNiYzR 1114 3.6 Key Management and Representation 1116 Signature applications require some level of assurance that the 1117 verification public key is associated with the claimed signer. Many 1118 applications achieve this by using public key certificates issued by 1119 a trusted third party. However, DKIM can achieve a sufficient level 1120 of security, with significantly enhanced scalability, by simply 1121 having the verifier query the purported signer's DNS entry (or some 1122 security-equivalent) in order to retrieve the public key. 1124 DKIM keys can potentially be stored in multiple types of key servers 1125 and in multiple formats. The storage and format of keys are 1126 irrelevant to the remainder of the DKIM algorithm. 1128 Parameters to the key lookup algorithm are the type of the lookup 1129 (the "q=" tag), the domain of the responsible signer (the "d=" tag of 1130 the DKIM-Signature header field), and the Selector (the "s=" tag). 1132 public_key = dkim_find_key(q_val, d_val, s_val) 1134 This document defines a single binding, using DNS TXT records to 1135 distribute the keys. Other bindings may be defined in the future. 1137 3.6.1 Textual Representation 1139 It is expected that many key servers will choose to present the keys 1140 in an otherwise unstructured text format (for example, an XML form 1141 would not be considered to be unstructured text for this purpose). 1142 The following definition MUST be used for any DKIM key represented in 1143 an otherwise unstructured textual form. 1145 The overall syntax is a tag-list as described in Section 3.2. The 1146 current valid tags are described below. Other tags MAY be present 1147 and MUST be ignored by any implementation that does not understand 1148 them. 1150 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 1151 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 1152 (without the quotes). This tag MUST be the first tag in the 1153 record. Records beginning with a "v=" tag with any other value 1154 MUST be discarded. 1156 ABNF: 1158 key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" 1160 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 1161 This value MUST match the Local-part of the "i=" tag of the DKIM- 1162 Signature header field (or its default value of the empty string 1163 if "i=" is not specified), with a "*" character matching a 1164 sequence of zero or more arbitrary characters ("wildcarding"). 1165 The intent of this tag is to constrain which signing address can 1166 legitimately use this Selector. An email with a signing address 1167 that does not match the value of this tag constitutes a failed 1168 verification. Wildcarding allows matching for addresses such as 1169 "user+*". An empty "g=" value never matches any addresses. 1171 ABNF: 1173 key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart 1174 key-g-tag-lpart = [dot-atom-text] ["*"] [dot-atom-text] 1176 [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a "dot- 1177 atom-text". This should probably use a different character 1178 for wildcarding. Unfortunately, the options are non-mnemonic 1179 (e.g., "@", "(", ":"). Alternatively we could insist on 1180 escaping a "*" intended as a literal "*" in the address.]] 1182 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 1183 allowing all algorithms). A colon-separated list of hash 1184 algorithms that might be used. Signers and Verifiers MUST 1185 support the "sha256" hash algorithm. Verifiers MUST also support 1186 the "sha1" hash algorithm. 1188 ABNF: 1190 key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 1191 0*( [FWS] ":" [FWS] key-h-tag-alg ) 1192 key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg 1193 x-key-h-tag-alg = hyphenated-word ; for future extension 1195 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 1196 verifiers MUST support the "rsa" key type. The "rsa" key type 1197 indicates that an ASN.1 DER-encoded [X.660] RSAPublicKey 1198 [RFC3447] (see sections 3.1 and A.1.1) is being used in the p= 1199 tag. (Note: the p= tag further encodes the value using the 1200 base64 algorithm.) 1202 ABNF: 1204 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 1205 key-k-tag-type = "rsa" / x-key-k-tag-type 1206 x-key-k-tag-type = hyphenated-word ; for future extension 1208 [[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be 1209 hard to separate h= and k=; for example DSA implies that 1210 SHA-1 will be used. This might be an actual change to the 1211 spec depending on how we decide to fix this.]] 1213 n= Notes that might be of interest to a human (qp-section; OPTIONAL, 1214 default is empty). No interpretation is made by any program. 1215 This tag should be used sparingly in any key server mechanism 1216 that has space limitations (notably DNS). 1218 ABNF: 1220 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 1222 p= Public-key data (base64; REQUIRED). An empty value means that 1223 this public key has been revoked. The syntax and semantics of 1224 this tag value before being encoded in base64 is defined by the 1225 k= tag. 1227 ABNF: 1229 key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] 1231 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 1232 separated list of service types to which this record applies. 1233 Verifiers for a given service type MUST ignore this record if the 1234 appropriate type is not listed. Currently defined service types 1235 are: 1237 * matches all service types 1239 email electronic mail (not necessarily limited to SMTP) 1241 This tag is intended to permit signers to constrain the use of 1242 delegated keys, e.g., where a company is willing to delegate the 1243 right to send mail in their name to an outsourcer, but not to 1244 send IM or make VoIP calls. (This of course presumes that these 1245 keys are used in other services in the future.) 1246 ABNF: 1248 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type 1249 0*( [FWS] ":" [FWS] key-s-tag-type 1250 key-s-tag-type = "email" / "*" / x-key-s-tag-type 1251 x-key-s-tag-type = hyphenated-word ; for future extension 1253 t= Flags, represented as a colon-separated list of names (plain- 1254 text; OPTIONAL, default is no flags set). The defined flags are: 1256 y This domain is testing DKIM. Verifiers MUST NOT treat 1257 messages from signers in testing mode differently from 1258 unsigned email, even should the signature fail to verify. 1259 Verifiers MAY wish to track testing mode results to assist 1260 the signer. 1262 s Any DKIM-Signature header fields using the "i=" tag MUST have 1263 the same domain value on the right hand side of the "@" in 1264 the "i=" tag and the value of the "d=" tag. That is, the 1265 "i=" domain MUST NOT be a subdomain of "d=". Use of this 1266 flag is RECOMMENDED unless subdomaining is required. 1268 ABNF: 1270 key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 1271 0*( [FWS] ":" [FWS] key-t-tag-flag ) 1272 key-t-tag-flag = "y" / "s" / x-key-t-tag-flag 1273 x-key-t-tag-flag = hyphenated-word ; for future extension 1275 Unrecognized flags MUST be ignored. 1277 3.6.2 DNS binding 1279 A binding using DNS TXT records as a key service is hereby defined. 1280 All implementations MUST support this binding. 1282 3.6.2.1 Name Space 1284 All DKIM keys are stored in a subdomain named "_domainkey". Given a 1285 DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag 1286 of "foo.bar", the DNS query will be for 1287 "foo.bar._domainkey.example.com". 1289 Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be 1290 used. Note also that wildcards within domains (e.g., 1291 s._domainkey.*.example.com) are not supported by the DNS. 1293 3.6.2.2 Resource Record Types for Key Storage 1295 The DNS Resource Record type used is specified by an option to the 1296 query-type ("q=") tag. The only option defined in this base 1297 specification is "txt", indicating the use of a TXT RR record. A 1298 later extension of this standard may define another Resource Record 1299 type. 1301 TXT records are encoded as described in Section 3.6.1. 1303 3.7 Computing the Message Hashes 1305 Both signing and verifying message signatures starts with a step of 1306 computing two cryptographic hashes over the message. Signers will 1307 choose the parameters of the signature as described in Signer Actions 1308 (Section 5); verifiers will use the parameters specified in the 1309 "DKIM-Signature" header field being verified. In the following 1310 discussion, the names of the tags in the "DKIM-Signature" header 1311 field which either exists (when verifying) or will be created (when 1312 signing) are used. Note that canonicalization (Section 3.4) is only 1313 used to prepare the email for signing or verifying; it does not 1314 affect the transmitted email in any way. 1316 The signer or verifier must compute two hashes, one over the body of 1317 the message and one over the selected header fields of the message. 1318 Signers MUST compute them in the order shown. Verifiers MAY compute 1319 them in any order convenient to the verifier, provided that the 1320 result is semantically identical to the semantics that would be the 1321 case had they been computed in this order. 1323 In hash step 1, the signer or verifier MUST hash the message body, 1324 canonicalized using the body canonicalization algorithm specified in 1325 the "c=" tag and truncated to the length specified in the "l=" tag. 1326 That hash value is then converted to base64 form and inserted into 1327 the "bh=" tag of the DKIM-Signature: header field. 1329 In hash step 2, the signer or verifier MUST pass the following to the 1330 hash algorithm in the indicated order. 1332 1. The header fields specified by the "h=" tag, in the order 1333 specified in that tag, and canonicalized using the header 1334 canonicalization algorithm specified in the "c=" tag. Each 1335 header field must be terminated with a single CRLF. 1337 2. The "DKIM-Signature" header field that exists (verifying) or will 1338 be inserted (signing) in the message, with the value of the "b=" 1339 tag deleted (i.e., treated as the empty string), canonicalized 1340 using the header canonicalization algorithm specified in the "c=" 1341 tag, and without a trailing CRLF. 1343 All tags and their values in the DKIM-Signature header field are 1344 included in the cryptographic hash with the sole exception of the 1345 value portion of the "b=" (signature) tag, which MUST be treated as 1346 the null string. All tags MUST be included even if they might not be 1347 understood by the verifier. The header field MUST be presented to 1348 the hash algorithm after the body of the message rather than with the 1349 rest of the header fields and MUST be canonicalized as specified in 1350 the "c=" (canonicalization) tag. The DKIM-Signature header field 1351 MUST NOT be included in its own h= tag. 1353 When calculating the hash on messages that will be transmitted using 1354 base64 or quoted-printable encoding, signers MUST compute the hash 1355 after the encoding. Likewise, the verifier MUST incorporate the 1356 values into the hash before decoding the base64 or quoted-printable 1357 text. However, the hash MUST be computed before transport level 1358 encodings such as SMTP "dot-stuffing." 1360 With the exception of the canonicalization procedure described in 1361 Section 3.4, the DKIM signing process treats the body of messages as 1362 simply a string of octets. DKIM messages MAY be either in plain-text 1363 or in MIME format; no special treatment is afforded to MIME content. 1364 Message attachments in MIME format MUST be included in the content 1365 which is signed. 1367 More formally, the algorithm for the signature is: 1368 body-hash = hash-alg(canon_body) 1369 header-hash = hash-alg(canon_header || DKIM-SIG) 1370 signature = sig-alg(header-hash, key) 1372 where "sig-alg" is the signature algorithm specified by the "a=" tag, 1373 "hash-alg" is the hash algorithm specified by the "a=" tag, 1374 "canon_header" and "canon_body" are the canonicalized message header 1375 and body (respectively) as defined in Section 3.4 (excluding the 1376 DKIM-Signature header field), and "DKIM-SIG" is the canonicalized 1377 DKIM-Signature header field sans the signature value itself, but with 1378 "body-hash" included as the "bh=" tag. 1380 INFORMATIVE NOTE: Many digital signature APIs provide both 1381 hashing and application of the RSA private key using a single 1382 "sign()" primitive. When using such an API the last two steps in 1383 the algorithm would probably be combined into a single call that 1384 would perform both the "hash-alg" and the "sig-alg". 1386 3.8 Signing by Parent Domains 1388 In some circumstances, it is desirable for a domain to apply a 1389 signature on behalf of any of its subdomains without the need to 1390 maintain separate selectors (key records) in each subdomain. By 1391 default, private keys corresponding to key records can be used to 1392 sign messages for any subdomain of the domain in which they reside, 1393 e.g., a key record for the domain example.com can be used to verify 1394 messages where the signing identity (i= tag of the signature) is 1395 sub.example.com, or even sub1.sub2.example.com. In order to limit 1396 the capability of such keys when this is not intended, the "s" flag 1397 may be set in the t= tag of the key record to constrain the validity 1398 of the record to exactly the domain of the signing identity. If the 1399 referenced key record contains the "s" flag as part of the t= tag, 1400 the domain of the signing identity (i= flag) MUST be the same as that 1401 of the d= domain. If this flag is absent, the domain of the signing 1402 identity MUST be the same as, or a subdomain of, the d= domain. Key 1403 records which are not intended for use with subdomains SHOULD specify 1404 the "s" flag in the t= tag. 1406 4. Semantics of Multiple Signatures 1408 A signer that is adding a signature to a message merely creates a new 1409 DKIM-Signature header, using the usual semantics of the h= option. A 1410 signer MAY sign previously existing DKIM-Signature headers using the 1411 method described in section Section 5.4 to sign trace headers. 1412 Signers should be cognizant that signing DKIM-Signature headers may 1413 result in signature failures with intermediaries that do not 1414 recognize that DKIM-Signatures are trace headers and unwittingly 1415 reorder them. 1417 When evaluating a message with multiple signatures, a verifier should 1418 evaluate signatures independently and on their own merits. For 1419 example, a verifier that by policy chooses not to accept signatures 1420 with deprecated cryptographic algorithms should consider such 1421 signatures invalid. As with messages with a single signature, 1422 verifiers are at liberty to use the presence of valid signatures as 1423 an input to local policy; likewise, the interpretation of multiple 1424 valid signatures in combination is a local policy decision of the 1425 verifier. 1427 Signers SHOULD NOT remove any DKIM-Signature header fields from 1428 messages they are signing, even if they know that the signatures 1429 cannot be verified. 1431 5. Signer Actions 1433 The following steps are performed in order by signers. 1435 5.1 Determine if the Email Should be Signed and by Whom 1437 A signer can obviously only sign email for domains for which it has a 1438 private-key and the necessary knowledge of the corresponding public 1439 key and Selector information. However there are a number of other 1440 reasons beyond the lack of a private key why a signer could choose 1441 not to sign an email. 1443 INFORMATIVE NOTE: Signing modules may be incorporated into any 1444 portion of the mail system as deemed appropriate, including an 1445 MUA, a SUBMISSION server, or an MTA. Wherever implemented, 1446 signers should beware of signing (and thereby asserting 1447 responsibility for) messages that may be problematic. In 1448 particular, within a trusted enclave the signing address might be 1449 derived from the header according to local policy; SUBMISSION 1450 servers might only sign messages from users that are properly 1451 authenticated and authorized. 1453 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1454 sign Received header fields if the outgoing gateway MTA obfuscates 1455 Received header fields, for example to hide the details of 1456 internal topology. 1458 If an email cannot be signed for some reason, it is a local policy 1459 decision as to what to do with that email. 1461 5.2 Select a private-key and corresponding selector information 1463 This specification does not define the basis by which a signer should 1464 choose which private-key and Selector information to use. Currently, 1465 all Selectors are equal as far as this specification is concerned, so 1466 the decision should largely be a matter of administrative 1467 convenience. Distribution and management of private-keys is also 1468 outside the scope of this document. 1470 INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a 1471 private key when the Selector containing the corresponding public 1472 key is expected to be revoked or removed before the verifier has 1473 an opportunity to validate the signature. The signer should 1474 anticipate that verifiers may choose to defer validation, perhaps 1475 until the message is actually read by the final recipient. In 1476 particular, when rotating to a new key-pair, signing should 1477 immediately commence with the new private key and the old public 1478 key should be retained for a reasonable validation interval before 1479 being removed from the key server. 1481 5.3 Normalize the Message to Prevent Transport Conversions 1483 Some messages, particularly those using 8-bit characters, are subject 1484 to modification during transit, notably conversion to 7-bit form. 1485 Such conversions will break DKIM signatures. In order to minimize 1486 the chances of such breakage, signers SHOULD convert the message to a 1487 suitable MIME content transfer encoding such as quoted-printable or 1488 base64 as described in MIME Part One [RFC2045] before signing. Such 1489 conversion is outside the scope of DKIM; the actual message SHOULD be 1490 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 1491 DKIM algorithm. 1493 Should the message be submitted to the signer with any local encoding 1494 that will be modified before transmission, such conversion to 1495 canonical form MUST be done before signing. In particular, some 1496 systems use local line separator conventions (such as the Unix 1497 newline character) internally rather than the SMTP-standard CRLF 1498 sequence. All such local conventions MUST be converted to canonical 1499 format before signing. 1501 More generally, the signer MUST sign the message as it is expected to 1502 be received by the verifier rather than in some local or internal 1503 form. 1505 5.4 Determine the header fields to Sign 1507 The From header field MUST be signed (that is, included in the h= tag 1508 of the resulting DKIM-Signature header field). Signers SHOULD NOT 1509 sign an existing header field likely to be legitimately modified or 1510 removed in transit. In particular, [RFC2821] explicitly permits 1511 modification or removal of the "Return-Path" header field in transit. 1512 Signers MAY include any other header fields present at the time of 1513 signing at the discretion of the signer. 1515 INFORMATIVE OPERATIONS NOTE: The choice of which header fields to 1516 sign is non-obvious. One strategy is to sign all existing, non- 1517 repeatable header fields. An alternative strategy is to sign only 1518 header fields that are likely to be displayed to or otherwise be 1519 likely to affect the processing of the message at the receiver. A 1520 third strategy is to sign only "well known" headers. Note that 1521 verifiers may treat unsigned header fields with extreme 1522 skepticism, including refusing to display them to the end user or 1523 even ignore the signature if it does not cover certain header 1524 fields. For this reason signing fields present in the message 1525 such as Date, Subject, Reply-To, Sender, and all MIME headers is 1526 highly advised. 1528 The DKIM-Signature header field is always implicitly signed and MUST 1529 NOT be included in the h= tag except to indicate that other 1530 preexisting signatures are also signed. 1532 Signers MAY claim to have signed header fields that do not exist 1533 (that is, signers MAY include the header field name in the h= tag 1534 even if that header field does not exist in the message). When 1535 computing the signature, the non-existing header field MUST be 1536 treated as the null string (including the header field name, header 1537 field value, all punctuation, and the trailing CRLF). 1539 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1540 the absence of a header field; if that header field is added later 1541 the signature will fail. 1543 Signers choosing to sign an existing header field that occurs more 1544 than once in the message (such as Received) MUST sign the physically 1545 last instance of that header field in the header block. Signers 1546 wishing to sign multiple instances of such a header field MUST 1547 include the header field name multiple times in the h= tag of the 1548 DKIM-Signature header field, and MUST sign such header fields in 1549 order from the bottom of the header field block to the top. The 1550 signer MAY include more instances of a header field name in h= than 1551 there are actual corresponding header fields to indicate that 1552 additional header fields of that name SHOULD NOT be added. 1554 INFORMATIVE EXAMPLE: 1556 If the signer wishes to sign two existing Received header fields, 1557 and the existing header contains: 1559 Received: 1560 Received: 1561 Received: 1563 then the resulting DKIM-Signature header field should read: 1565 DKIM-Signature: ... h=Received : Received : ... 1567 and Received header fields and will be signed in that 1568 order. 1570 Signers should be careful of signing header fields that might have 1571 additional instances added later in the delivery process, since such 1572 header fields might be inserted after the signed instance or 1573 otherwise reordered. Trace header fields (such as Received and DKIM- 1574 Signature) and Resent-* blocks are the only fields prohibited by 1575 [RFC2822] from being reordered. 1577 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1578 header fields to be reordered (with the exception of Received 1579 header fields), reordering of signed header fields with multiple 1580 instances by intermediate MTAs will cause DKIM signatures to be 1581 broken; such anti-social behavior should be avoided. 1583 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1584 specification, all end-user visible header fields should be signed 1585 to avoid possible "indirect spamming." For example, if the 1586 "Subject" header field is not signed, a spammer can resend a 1587 previously signed mail, replacing the legitimate subject with a 1588 one-line spam. 1590 5.5 Compute the Message Hash and Signature 1592 The signer MUST compute the message hash as described in Section 3.7 1593 and then sign it using the selected public-key algorithm. This will 1594 result in a DKIM-Signature header field which will include the body 1595 hash and a signature of the header hash, where that header includes 1596 the DKIM-Signature header field itself. 1598 Entities such as mailing list managers that implement DKIM and which 1599 modify the message or a header field (for example, inserting 1600 unsubscribe information) before retransmitting the message SHOULD 1601 check any existing signature on input and MUST make such 1602 modifications before re-signing the message. 1604 The signer MAY elect to limit the number of bytes of the body that 1605 will be included in the hash and hence signed. The length actually 1606 hashed should be inserted in the "l=" tag of the "DKIM-Signature" 1607 header field. 1609 5.6 Insert the DKIM-Signature header field 1611 Finally, the signer MUST insert the "DKIM-Signature:" header field 1612 created in the previous step prior to transmitting the email. The 1613 "DKIM-Signature" header field MUST be the same as used to compute the 1614 hash as described above, except that the value of the "b=" tag MUST 1615 be the appropriately signed hash computed in the previous step, 1616 signed using the algorithm specified in the "a=" tag of the "DKIM- 1617 Signature" header field and using the private key corresponding to 1618 the Selector given in the "s=" tag of the "DKIM-Signature" header 1619 field, as chosen above in Section 5.2 1620 The "DKIM-Signature" MUST be inserted before any other DKIM-Signature 1621 fields in the header block. 1623 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1624 is to insert the "DKIM-Signature" header field at the beginning of 1625 the header block. In particular, it may be placed before any 1626 existing Received header fields. This is consistent with treating 1627 "DKIM-Signature" as a trace header. 1629 6. Verifier Actions 1631 Since a signer MAY remove or revoke a public key at any time, it is 1632 recommended that verification occur in a timely manner with the most 1633 timely place being during acceptance by the border MTA. 1635 A border or intermediate MTA MAY verify the message signature(s). An 1636 MTA who has performed verification MAY communicate the result of that 1637 verification by adding a verification header field to incoming 1638 messages. This considerably simplifies things for the user, who can 1639 now use an existing mail user agent. Most MUAs have the ability to 1640 filter messages based on message header fields or content; these 1641 filters would be used to implement whatever policy the user wishes 1642 with respect to unsigned mail. 1644 A verifying MTA MAY implement a policy with respect to unverifiable 1645 mail, regardless of whether or not it applies the verification header 1646 field to signed messages. 1648 Verifiers MUST produce a result that is semantically equivalent to 1649 applying the following steps in the order listed. In practice, 1650 several of these steps can be performed in parallel in order to 1651 improve performance. 1653 6.1 Extract Signatures from the Message 1655 The order in which verifiers try DKIM-Signature header fields is not 1656 defined; verifiers MAY try signatures in any order they would like. 1657 For example, one implementation might prefer to try the signatures in 1658 textual order, whereas another might want to prefer signatures by 1659 identities that match the contents of the "From" header field over 1660 other identities. Verifiers MUST NOT attribute ultimate meaning to 1661 the order of multiple DKIM-Signature header fields. In particular, 1662 there is reason to believe that some relays will reorder the header 1663 fields in potentially arbitrary ways. 1665 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1666 a clue to signing order in the absence of any other information. 1668 However, other clues as to the semantics of multiple signatures 1669 (such as correlating the signing host with Received headers) may 1670 also be considered. 1672 A verifier SHOULD NOT treat a message that has one or more bad 1673 signatures and no good signatures differently from a message with no 1674 signature at all; such treatment is a matter of local policy and is 1675 beyond the scope of this document. 1677 When a signature successfully verifies, a verifier will either stop 1678 processing or attempt to verify any other signatures, at the 1679 discretion of the implementation. A verifier MAY limit the number of 1680 signatures it tries to avoid denial-of-service attacks. 1682 INFORMATIVE NOTE: An attacker could send messages with large 1683 numbers of faulty signatures, each of which would require a DNS 1684 lookup. This could be an attack on the domain that receives the 1685 message, by slowing down the verifier by requiring it to do large 1686 number of DNS lookups and signature verifications. It could also 1687 be an attack against the domains listed in the signatures, 1688 essentially by enlisting innocent verifiers in launching an attack 1689 against the DNS servers of the actual victim. 1691 In the following description, text reading "return status 1692 (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") 1693 means that the verifier MUST immediately cease processing that 1694 signature. The verifier SHOULD proceed to the next signature, if any 1695 is present, and completely ignore the bad signature. If the status 1696 is "PERMFAIL", the signature failed and should not be reconsidered. 1697 If the status is "TEMPFAIL", the signature could not be verified at 1698 this time but may be tried again later. A verifier MAY either defer 1699 the message for later processing, perhaps by queueing it locally or 1700 issuing a 451/4.7.5 SMTP reply, or try another signature; if no good 1701 signature is found and any of the signatures resulted in a TEMPFAIL 1702 status, the verifier MAY save the message for later processing. The 1703 "(explanation)" is not normative text; it is provided solely for 1704 clarification. 1706 Verifiers SHOULD ignore any DKIM-Signature header fields where the 1707 signature does not validate. Verifiers that are prepared to validate 1708 multiple signature header fields SHOULD proceed to the next signature 1709 header field, should it exist. However, verifiers MAY make note of 1710 the fact that an invalid signature was present for consideration at a 1711 later step. 1713 INFORMATIVE NOTE: The rationale of this requirement is to permit 1714 messages that have invalid signatures but also a valid signature 1715 to work. For example, a mailing list exploder might opt to leave 1716 the original submitter signature in place even though the exploder 1717 knows that it is modifying the message in some way that will break 1718 that signature, and the exploder inserts its own signature. In 1719 this case the message should succeed even in the presence of the 1720 known-broken signature. 1722 For each signature to be validated, the following steps should be 1723 performed in such a manner as to produce a result that is 1724 semantically equivalent to performing them in the indicated order. 1726 6.1.1 Validate the Signature Header Field 1728 Implementers MUST meticulously validate the format and values in the 1729 DKIM-Signature header field; any inconsistency or unexpected values 1730 MUST cause the header field to be completely ignored and the verifier 1731 to return PERMFAIL (signature syntax error). Being "liberal in what 1732 you accept" is definitely a bad strategy in this security context. 1733 Note however that this does not include the existence of unknown tags 1734 in a DKIM-Signature header field, which are explicitly permitted. 1736 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag 1737 that is inconsistent with this specification and return PERMFAIL 1738 (incompatible version). 1740 INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of 1741 course, choose to also verify signatures generated by older 1742 versions of this specification. 1744 If the DKIM-Signature header field does not contain any of the tags 1745 listed as required in Section 3.5 the verifier MUST ignore the DKIM- 1746 Signature header field and return PERMFAIL (signature missing 1747 required tag). 1749 If the "DKIM-Signature" header field does not contain the "i=" tag, 1750 the verifier MUST behave as though the value of that tag were "@d", 1751 where "d" is the value from the "d=" tag. 1753 Verifiers MUST confirm that the domain specified in the "d=" tag is 1754 the same as or a parent domain of the domain part of the "i=" tag. 1755 If not, the DKIM-Signature header field MUST be ignored and the 1756 verifier should return PERMFAIL (domain mismatch). 1758 If the "h=" tag does not include the "From" header field the verifier 1759 MUST ignore the DKIM-Signature header field and return PERMFAIL (From 1760 field not signed). 1762 Verifiers MAY ignore the DKIM-Signature header field and return 1763 PERMFAIL (signature expired) if it contains an "x=" tag and the 1764 signature has expired. 1766 Verifiers MAY ignore the DKIM-Signature header field and return 1767 PERMFAIL (unacceptable signature header) for any other reason, for 1768 example, if the signature does not sign header fields that the 1769 verifier views to be essential. As a case in point, if MIME header 1770 fields are not signed, certain attacks may be possible that the 1771 verifier would prefer to avoid. 1773 6.1.2 Get the Public Key 1775 The public key for a signature is needed to complete the verification 1776 process. The process of retrieving the public key depends on the 1777 query type as defined by the "q=" tag in the "DKIM-Signature:" header 1778 field. Obviously, a public key need only be retrieved if the process 1779 of extracting the signature information is completely successful. 1780 Details of key management and representation are described in 1781 Section 3.6. The verifier MUST validate the key record and MUST 1782 ignore any public key records that are malformed. 1784 When validating a message, a verifier MUST perform the following 1785 steps in a manner that is semantically the same as performing them in 1786 the order indicated (in some cases the implementation may parallelize 1787 or reorder these steps, as long as the semantics remain unchanged): 1789 1. Retrieve the public key as described in (Section 3.6) using the 1790 domain from the "d=" tag and the Selector from the "s=" tag. 1792 2. If the query for the public key fails to respond, the verifier 1793 MAY defer acceptance of this email and return TEMPFAIL (key 1794 unavailable). If verification is occurring during the incoming 1795 SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply 1796 code. Alternatively, the verifier MAY store the message in the 1797 local queue for later trial or ignore the signature. Note that 1798 storing a message in the local queue is subject to denial-of- 1799 service attacks. 1801 3. If the query for the public key fails because the corresponding 1802 key record does not exist, the verifier MUST immediately return 1803 PERMFAIL (no key for signature). 1805 4. If the query for the public key returns multiple key records, the 1806 verifier may choose one of the key records or may cycle through 1807 the key records performing the remainder of these steps on each 1808 record at the discretion of the implementer. The order of the 1809 key records is unspecified. If the verifier chooses to cycle 1810 through the key records, then the "return with ..." wording in 1811 the remainder of this section means "try the next key record, if 1812 any; if none, return to try another signature in the usual way." 1814 5. If the result returned from the query does not adhere to the 1815 format defined in this specification, the verifier MUST ignore 1816 the key record and return PERMFAIL (key syntax error). Verifiers 1817 are urged to validate the syntax of key records carefully to 1818 avoid attempted attacks. 1820 6. If the "g=" tag in the public key does not match the Local-part 1821 of the "i=" tag in the message signature header field, the 1822 verifier MUST ignore the key record and return PERMFAIL 1823 (inapplicable key). If the Local-part of the "i=" tag on the 1824 message signature is not present, the g= tag must be * (valid for 1825 all addresses in the domain) or the entire g= tag must be omitted 1826 (which defaults to "g=*"), otherwise the verifier MUST ignore the 1827 key record and return PERMFAIL (inapplicable key). Other than 1828 this test, verifiers SHOULD NOT treat a message signed with a key 1829 record having a g= tag any differently than one without; in 1830 particular, verifiers SHOULD NOT prefer messages that seem to 1831 have an individual signature by virtue of a g= tag versus a 1832 domain signature. 1834 7. If the "h=" tag exists in the public key record and the hash 1835 algorithm implied by the a= tag in the DKIM-Signature header is 1836 not included in the contents of the "h=" tag, the verifier MUST 1837 ignore the key record and return PERMFAIL (inappropriate hash 1838 algorithm). 1840 8. If the public key data (the "p=" tag) is empty then this key has 1841 been revoked and the verifier MUST treat this as a failed 1842 signature check and return PERMFAIL (key revoked). There is no 1843 defined semantic difference between a key that has been revoked 1844 and a key record that has been removed. 1846 9. If the public key data is not suitable for use with the algorithm 1847 and key types defined by the "a=" and "k=" tags in the "DKIM- 1848 Signature" header field, the verifier MUST immediately return 1849 PERMFAIL (inappropriate key algorithm). 1851 6.1.3 Compute the Verification 1853 Given a signer and a public key, verifying a signature consists of 1854 actions semantically equivalent to the following steps. 1856 1. Based on the algorithm defined in the "c=" tag, the body length 1857 specified in the "l=" tag, and the header field names in the "h=" 1858 tag, prepare a canonicalized version of the message as is 1859 described in Section 3.7 (note that this version does not 1860 actually need to be instantiated). When matching header field 1861 names in the "h=" tag against the actual message header field, 1862 comparisons MUST be case-insensitive. 1864 2. Based on the algorithm indicated in the "a=" tag, compute the 1865 message hashes from the canonical copy as described in 1866 Section 3.7. 1868 3. Verify that the hash of the canonicalized message body computed 1869 in the previous step matches the hash value conveyed in the "bh=" 1870 tag. 1872 4. Using the signature conveyed in the "b=" tag, verify the 1873 signature against the header hash using the mechanism appropriate 1874 for the public key algorithm described in the "a=" tag. If the 1875 signature does not validate, the verifier SHOULD ignore the 1876 signature and return PERMFAIL (signature did not verify). 1878 5. Otherwise, the signature has correctly verified. 1880 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1881 initiate the public-key query in parallel with calculating the 1882 hash as the public key is not needed until the final decryption is 1883 calculated. Implementations may also verify the signature on the 1884 message header before validating that the message hash listed in 1885 the "bh=" tag in the DKIM-Signature header field matches that of 1886 the actual message body; however, if the body hash does not match, 1887 the entire signature must be considered to have failed. 1889 A body length specified in the "l=" tag of the signature limits the 1890 number of bytes of the body passed to the verification algorithm. 1891 All data beyond that limit is not validated by DKIM. Hence, 1892 verifiers might treat a message that contains bytes beyond the 1893 indicated body length with suspicion, such as by truncating the 1894 message at the indicated body length, declaring the signature invalid 1895 (e.g., by returning PERMFAIL (unsigned content)), or conveying the 1896 partial verification to the policy module. 1898 INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body 1899 at the indicated body length might pass on a malformed MIME 1900 message if the signer used the "N-4" trick described in the 1901 informative note in Section 5.5. Such verifiers may wish to check 1902 for this case and include a trailing "--CRLF" to avoid breaking 1903 the MIME structure. A simple way to achieve this might be to 1904 append "--CRLF" to any "multipart" message with a body length; if 1905 the MIME structure is already correctly formed, this will appear 1906 in the postlude and will not be displayed to the end user. 1908 6.2 Communicate Verification Results 1910 Verifiers wishing to communicate the results of verification to other 1911 parts of the mail system may do so in whatever manner they see fit. 1912 For example, implementations might choose to add an email header 1913 field to the message before passing it on. Any such header field 1914 SHOULD be inserted before any existing DKIM-Signature or preexisting 1915 authentication status header fields in the header field block. 1917 INFORMATIVE ADVICE to MUA filter writers: Patterns intended to 1918 search for results header fields to visibly mark authenticated 1919 mail for end users should verify that such header field was added 1920 by the appropriate verifying domain and that the verified identity 1921 matches the author identity that will be displayed by the MUA. In 1922 particular, MUA filters should not be influenced by bogus results 1923 header fields added by attackers. Verifiers may wish to delete 1924 existing results header fields after verification and before 1925 adding a new header field to circumvent this attack. 1927 6.3 Interpret Results/Apply Local Policy 1929 It is beyond the scope of this specification to describe what actions 1930 a verifier system should make, but an authenticated email presents an 1931 opportunity to a receiving system that unauthenticated email cannot. 1932 Specifically, an authenticated email creates a predictable identifier 1933 by which other decisions can reliably be managed, such as trust and 1934 reputation. Conversely, unauthenticated email lacks a reliable 1935 identifier that can be used to assign trust and reputation. It is 1936 reasonable to treat unauthenticated email as lacking any trust and 1937 having no positive reputation. 1939 In general verifiers SHOULD NOT reject messages solely on the basis 1940 of a lack of signature or an unverifiable signature. However, if the 1941 verifier does opt to reject such messages, and the verifier runs 1942 synchronously with the SMTP session and a signature is missing or 1943 does not verify, the MTA SHOULD reject the message with an error such 1944 as: 1946 550 5.7.1 Unsigned messages not accepted 1948 550 5.7.5 Message signature incorrect 1950 If it is not possible to fetch the public key, perhaps because the 1951 key server is not available, a temporary failure message MAY be 1952 generated, such as: 1954 451 4.7.5 Unable to verify signature - key server unavailable 1956 A temporary failure of the key server or other external service is 1957 the only condition that should use a 4xx SMTP reply code. In 1958 particular, signature verification failures MUST NOT return 4xx SMTP 1959 replies. 1961 Once the signature has been verified, that information MUST be 1962 conveyed to higher level systems (such as explicit allow/white lists 1963 and reputation systems) and/or to the end user. If the message is 1964 signed on behalf of any address other than that in the From: header 1965 field, the mail system SHOULD take pains to ensure that the actual 1966 signing identity is clear to the reader. 1968 The verifier MAY treat unsigned header fields with extreme 1969 skepticism, including marking them as untrusted or even deleting them 1970 before display to the end user. 1972 While the symptoms of a failed verification are obvious -- the 1973 signature doesn't verify -- establishing the exact cause can be more 1974 difficult. If a Selector cannot be found, is that because the 1975 Selector has been removed or was the value changed somehow in 1976 transit? If the signature line is missing is that because it was 1977 never there, or was it removed by an over-zealous filter? For 1978 diagnostic purposes, the exact reason why the verification fails 1979 SHOULD be made available to the policy module and possibly recorded 1980 in the system logs. However in terms of presentation to the end 1981 user, the result SHOULD be presented as a simple binary result: 1982 either the email is verified or it is not. If the email cannot be 1983 verified, then it SHOULD be rendered the same as all unverified email 1984 regardless of whether it looks like it was signed or not. 1986 7. IANA Considerations 1988 DKIM introduces some new namespaces that require IANA registry. 1990 [[Missing registries for signature t= (flags) tags, as well as key 1991 record s= (service type) and t= (flags).]] 1993 7.1 DKIM-Signature Tag Specifications 1995 A DKIM-Signature provides for a list of tag specifications. IANA is 1996 requested to establish the DKIM Signature Tag Specification Registry, 1997 for tag specifications that can be used in DKIM-Signature fields and 1998 that have been specified in any published RFC. 2000 The initial entries in the registry comprise: 2002 +------+-----------------+ 2003 | TYPE | RFC | 2004 +------+-----------------+ 2005 | v | (this document) | 2006 | a | (this document) | 2007 | b | (this document) | 2008 | bh | (this document) | 2009 | c | (this document) | 2010 | d | (this document) | 2011 | h | (this document) | 2012 | i | (this document) | 2013 | l | (this document) | 2014 | q | (this document) | 2015 | s | (this document) | 2016 | t | (this document) | 2017 | x | (this document) | 2018 | z | (this document) | 2019 +------+-----------------+ 2021 7.2 DKIM-Signature Query Method Registry 2023 The "q=" tag-spec, as specified in Section 3.5 provides for a list of 2024 query methods. 2026 IANA is requested to establish the DKIM Query Method Registry, for 2027 mechanisms that can be used to retrieve the key that will permit 2028 validation processing of a message signed using DKIM and have been 2029 specified in any published RFC. 2031 The initial entry in the registry comprises: 2033 +------+--------+-----------------+ 2034 | TYPE | OPTION | RFC | 2035 +------+--------+-----------------+ 2036 | dns | txt | (this document) | 2037 +------+--------+-----------------+ 2039 7.3 DKIM-Signature Canonicalization Registry 2041 The "c=" tag-spec, as specified in Section 3.5 provides for a 2042 specifier for canonicalization algorithms for the header and body of 2043 the message. 2045 IANA is requested to establish the DKIM Canonicalization Algorithm 2046 Registry, for algorithms for converting a message into a canonical 2047 form before signing or verifying using DKIM and have been specified 2048 in any published RFC. 2050 The initial entries in the header registry comprise: 2052 +---------+-----------------+ 2053 | TYPE | RFC | 2054 +---------+-----------------+ 2055 | simple | (this document) | 2056 | relaxed | (this document) | 2057 +---------+-----------------+ 2059 The initial entries in the body registry comprise: 2061 +---------+-----------------+ 2062 | TYPE | RFC | 2063 +---------+-----------------+ 2064 | simple | (this document) | 2065 | relaxed | (this document) | 2066 +---------+-----------------+ 2068 7.4 _domainkey DNS TXT Record Tag Specifications 2070 A _domainkey DNS TXT record provides for a list of tag 2071 specifications. IANA is requested to establish the DKIM _domainkey 2072 DNS TXT Tag Specification Registry, for tag specifications that can 2073 be used in DNS TXT Records and that have been specified in any 2074 published RFC. 2076 The initial entries in the registry comprise: 2078 +------+-----------------+ 2079 | TYPE | RFC | 2080 +------+-----------------+ 2081 | v | (this document) | 2082 | g | (this document) | 2083 | h | (this document) | 2084 | k | (this document) | 2085 | n | (this document) | 2086 | p | (this document) | 2087 | s | (this document) | 2088 | t | (this document) | 2089 +------+-----------------+ 2091 7.5 DKIM Key Type Registry 2093 The "k=" (as specified in Section 3.6.1) and the "a=" 2094 (Section 3.5) tags provide for a list of mechanisms 2095 that can be used to decode a DKIM signature. 2097 IANA is requested to establish the DKIM Key Type Registry, for such 2098 mechanisms that have been specified in any published RFC. 2100 The initial entry in the registry comprises: 2102 +------+---------+ 2103 | TYPE | RFC | 2104 +------+---------+ 2105 | rsa | RFC3447 | 2106 +------+---------+ 2108 7.6 DKIM Hash Algorithms Registry 2110 The "h=" list (specified in Section 3.6.1) and the "a=" 2111 (Section 3.5) provide for a list of mechanisms that can 2112 be used to produce a digest of message data. 2114 IANA is requested to establish the DKIM Hash Algorithms Registry, for 2115 such mechanisms that have been specified in any published RFC. 2117 The initial entries in the registry comprise: 2119 +--------+-----+ 2120 | TYPE | RFC | 2121 +--------+-----+ 2122 | sha1 | ? | 2123 | sha256 | ? | 2124 +--------+-----+ 2126 8. Security Considerations 2128 It has been observed that any mechanism that is introduced which 2129 attempts to stem the flow of spam is subject to intensive attack. 2130 DKIM needs to be carefully scrutinized to identify potential attack 2131 vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. 2133 8.1 Misuse of Body Length Limits ("l=" Tag) 2135 Body length limits (in the form of the "l=" tag) are subject to 2136 several potential attacks. 2138 8.1.1 Addition of new MIME parts to multipart/* 2140 If the body length limit does not cover a closing MIME multipart 2141 section (including the trailing ""--CRLF"" portion), then it is 2142 possible for an attacker to intercept a properly signed multipart 2143 message and add a new body part. Depending on the details of the 2144 MIME type and the implementation of the verifying MTA and the 2145 receiving MUA, this could allow an attacker to change the information 2146 displayed to an end user from an apparently trusted source. 2148 For example, if an attacker can append information to a "text/html" 2149 body part, they may be able to exploit a bug in some MUAs that 2150 continue to read after a "" marker, and thus display HTML text 2151 on top of already displayed text. If a message has a "multipart/ 2152 alternative" body part, they might be able to add a new body part 2153 that is preferred by the displaying MTA. 2155 8.1.2 Addition of new HTML content to existing content 2157 Several receiving MUA implementations do not cease display after a 2158 """" tag. In particular, this allows attacks involving 2159 overlaying images on top of existing text. 2161 INFORMATIVE EXAMPLE: Appending the following text to an existing, 2162 properly closed message will in many MUAs result in inappropriate 2163 data being rendered on top of existing, correct data: 2164
2165 2167
2169 8.2 Misappropriated Private Key 2171 If the private key for a user is resident on their computer and is 2172 not protected by an appropriately secure mechanism, it is possible 2173 for malware to send mail as that user and any other user sharing the 2174 same private key. The malware would, however, not be able to 2175 generate signed spoofs of other signers' addresses, which would aid 2176 in identification of the infected user and would limit the 2177 possibilities for certain types of attacks involving socially- 2178 engineered messages. This threat applies mainly to MUA-based 2179 implementations; protection of private keys on servers can be easily 2180 achieved through the use of specialized cryptographic hardware. 2182 A larger problem occurs if malware on many users' computers obtains 2183 the private keys for those users and transmits them via a covert 2184 channel to a site where they can be shared. The compromised users 2185 would likely not know of the misappropriation until they receive 2186 "bounce" messages from messages they are purported to have sent. 2187 Many users might not understand the significance of these bounce 2188 messages and would not take action. 2190 One countermeasure is to use a user-entered passphrase to encrypt the 2191 private key, although users tend to choose weak passphrases and often 2192 reuse them for different purposes, possibly allowing an attack 2193 against DKIM to be extended into other domains. Nevertheless, the 2194 decoded private key might be briefly available to compromise by 2195 malware when it is entered, or might be discovered via keystroke 2196 logging. The added complexity of entering a passphrase each time one 2197 sends a message would also tend to discourage the use of a secure 2198 passphrase. 2200 A somewhat more effective countermeasure is to send messages through 2201 an outgoing MTA that can authenticate the submitter using existing 2202 techniques (e.g., SMTP Authentication), possibly validate the message 2203 itself (e.g., verify that the header is legitimate and that the 2204 content passes a spam content check), and sign the message using a 2205 key appropriate for the submitter address. Such an MTA can also 2206 apply controls on the volume of outgoing mail each user is permitted 2207 to originate in order to further limit the ability of malware to 2208 generate bulk email. 2210 8.3 Key Server Denial-of-Service Attacks 2212 Since the key servers are distributed (potentially separate for each 2213 domain), the number of servers that would need to be attacked to 2214 defeat this mechanism on an Internet-wide basis is very large. 2215 Nevertheless, key servers for individual domains could be attacked, 2216 impeding the verification of messages from that domain. This is not 2217 significantly different from the ability of an attacker to deny 2218 service to the mail exchangers for a given domain, although it 2219 affects outgoing, not incoming, mail. 2221 A variation on this attack is that if a very large amount of mail 2222 were to be sent using spoofed addresses from a given domain, the key 2223 servers for that domain could be overwhelmed with requests. However, 2224 given the low overhead of verification compared with handling of the 2225 email message itself, such an attack would be difficult to mount. 2227 8.4 Attacks Against DNS 2229 Since DNS is a required binding for key services, specific attacks 2230 against DNS must be considered. 2232 While the DNS is currently insecure [RFC3833], it is expected that 2233 the security problems should and will be solved by DNSSEC [RFC4033], 2234 and all users of the DNS will reap the benefit of that work. 2236 Secondly, the types of DNS attacks relevant to DKIM are very costly 2237 and are far less rewarding than DNS attacks on other Internet 2238 applications. 2240 To systematically thwart the intent of DKIM, an attacker must conduct 2241 a very costly and very extensive attack on many parts of the DNS over 2242 an extended period. No one knows for sure how attackers will 2243 respond, however the cost/benefit of conducting prolonged DNS attacks 2244 of this nature is expected to be uneconomical. 2246 Finally, DKIM is only intended as a "sufficient" method of proving 2247 authenticity. It is not intended to provide strong cryptographic 2248 proof about authorship or contents. Other technologies such as 2249 OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. 2251 A second security issue related to the DNS revolves around the 2252 increased DNS traffic as a consequence of fetching Selector-based 2253 data as well as fetching signing domain policy. Widespread 2254 deployment of DKIM will result in a significant increase in DNS 2255 queries to the claimed signing domain. In the case of forgeries on a 2256 large scale, DNS servers could see a substantial increase in queries. 2258 8.5 Replay Attacks 2260 In this attack, a spammer sends a message to be spammed to an 2261 accomplice, which results in the message being signed by the 2262 originating MTA. The accomplice resends the message, including the 2263 original signature, to a large number of recipients, possibly by 2264 sending the message to many compromised machines that act as MTAs. 2265 The messages, not having been modified by the accomplice, have valid 2266 signatures. 2268 Partial solutions to this problem involve the use of reputation 2269 services to convey the fact that the specific email address is being 2270 used for spam, and that messages from that signer are likely to be 2271 spam. This requires a real-time detection mechanism in order to 2272 react quickly enough. However, such measures might be prone to 2273 abuse, if for example an attacker resent a large number of messages 2274 received from a victim in order to make them appear to be a spammer. 2276 Large verifiers might be able to detect unusually large volumes of 2277 mails with the same signature in a short time period. Smaller 2278 verifiers can get substantially the same volume information via 2279 existing collaborative systems. 2281 8.6 Limits on Revoking Keys 2283 When a large domain detects undesirable behavior on the part of one 2284 of its users, it might wish to revoke the key used to sign that 2285 user's messages in order to disavow responsibility for messages which 2286 have not yet been verified or which are the subject of a replay 2287 attack. However, the ability of the domain to do so can be limited 2288 if the same key, for scalability reasons, is used to sign messages 2289 for many other users. Mechanisms for explicitly revoking keys on a 2290 per-address basis have been proposed but require further study as to 2291 their utility and the DNS load they represent. 2293 8.7 Intentionally malformed Key Records 2295 It is possible for an attacker to publish key records in DNS which 2296 are intentionally malformed, with the intent of causing a denial-of- 2297 service attack on a non-robust verifier implementation. The attacker 2298 could then cause a verifier to read the malformed key record by 2299 sending a message to one of its users referencing the malformed 2300 record in a (not necessarily valid) signature. Verifiers MUST 2301 thoroughly verify all key records retrieved from DNS and be robust 2302 against intentionally as well as unintentionally malformed key 2303 records. 2305 8.8 Intentionally Malformed DKIM-Signature header fields 2307 Verifiers MUST be prepared to receive messages with malformed DKIM- 2308 Signature header fields, and thoroughly verify the header field 2309 before depending on any of its contents. 2311 8.9 Information Leakage 2313 An attacker could determine when a particular signature was verified 2314 by using a per-message Selector and then monitoring their DNS traffic 2315 for the key lookup. This would act as the equivalent of a "web bug" 2316 for verification time rather than when the message was read. 2318 8.10 Remote Timing Attacks 2320 In some cases it may be possible to extract private keys using a 2321 remote timing attack [BONEH03]. Implementations should consider 2322 obfuscating the timing to prevent such attacks. 2324 9. References 2325 9.1 Normative References 2327 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2328 Extensions (MIME) Part One: Format of Internet Message 2329 Bodies", RFC 2045, November 1996. 2331 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2332 Part Three: Message header field Extensions for Non-ASCII 2333 Text", RFC 2047, November 1996. 2335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2336 Requirement Levels", BCP 14, RFC 2119, March 1997. 2338 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2339 April 2001. 2341 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2342 April 2001. 2344 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2345 Standards (PKCS) #1: RSA Cryptography Specifications 2346 Version 2.1", RFC 3447, February 2003. 2348 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 2349 for Internationalized Domain Names in Application(IDNA)", 2350 March 2003. 2352 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2353 Specifications: ABNF", RFC 4234, October 2005. 2355 [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 2356 encoding rules: Specification of Basic Encoding Rules 2357 (BER), Canonical Encoding Rules (CER) and Distinguished 2358 Encoding Rules (DER)", 1997. 2360 9.2 Informative References 2362 [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing 2363 Attacks are Practical", 2003, . 2366 [ID-DKIM-THREATS] 2367 Fenton, J., "Analysis of Threats Motivating DomainKeys 2368 Identified Mail (DKIM)", draft-fenton-dkim-threats-02 2369 (work in progress), April 2006. 2371 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 2372 "Security Multiparts for MIME: Multipart/Signed and 2373 Multipart/Encrypted", RFC 1847, October 1995. 2375 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 2376 "OpenPGP Message Format", RFC 2440, November 1998. 2378 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for 2379 Public Keys Used For Exchanging Symmetric Keys", RFC 3766, 2380 April 2004. 2382 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2383 Name System (DNS)", RFC 3833, August 2004. 2385 [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", 2386 RFC 3851, June 1999. 2388 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2389 Rose, "DNS Security Introduction and Requirements", 2390 RFC 4033, March 2005. 2392 Authors' Addresses 2394 Eric Allman 2395 Sendmail, Inc. 2396 6425 Christie Ave, Suite 400 2397 Emeryville, CA 94608 2398 USA 2400 Phone: +1 510 594 5501 2401 Email: eric+dkim@sendmail.org 2402 URI: 2404 Jon Callas 2405 PGP Corporation 2406 3460 West Bayshore 2407 Palo Alto, CA 94303 2408 USA 2410 Phone: +1 650 319 9016 2411 Email: jon@pgp.com 2412 Mark Delany 2413 Yahoo! Inc 2414 701 First Avenue 2415 Sunnyvale, CA 95087 2416 USA 2418 Phone: +1 408 349 6831 2419 Email: markd+dkim@yahoo-inc.com 2420 URI: 2422 Miles Libbey 2423 Yahoo! Inc 2424 701 First Avenue 2425 Sunnyvale, CA 95087 2426 USA 2428 Email: mlibbeymail-mailsig@yahoo.com 2429 URI: 2431 Jim Fenton 2432 Cisco Systems, Inc. 2433 MS SJ-24/2 2434 170 W. Tasman Drive 2435 San Jose, CA 95134-1706 2436 USA 2438 Phone: +1 408 526 5914 2439 Email: fenton@cisco.com 2440 URI: 2442 Michael Thomas 2443 Cisco Systems, Inc. 2444 MS SJ-9/2 2445 170 W. Tasman Drive 2446 San Jose, CA 95134-1706 2448 Phone: +1 408 525 5386 2449 Email: mat@cisco.com 2451 Appendix A. Example of Use (INFORMATIVE) 2453 This section shows the complete flow of an email from submission to 2454 final delivery, demonstrating how the various components fit 2455 together. 2457 A.1 The user composes an email 2459 From: Joe SixPack 2460 To: Suzie Q 2461 Subject: Is dinner ready? 2462 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2463 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2465 Hi. 2467 We lost the game. Are you hungry yet? 2469 Joe. 2471 A.2 The email is signed 2473 This email is signed by the example.com outbound email server and now 2474 looks like this: 2476 DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; 2477 c=simple; q=dns/txt; i=joe@football.example.com; 2478 h=Received : From : To : Subject : Date : Message-ID; 2479 bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; 2480 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2481 VoG4ZHRNiYzR; 2482 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2483 by submitserver.example.com with SUBMISSION; 2484 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2485 From: Joe SixPack 2486 To: Suzie Q 2487 Subject: Is dinner ready? 2488 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2489 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2491 Hi. 2493 We lost the game. Are you hungry yet? 2495 Joe. 2497 The signing email server requires access to the private-key 2498 associated with the "brisbane" Selector to generate this signature. 2500 A.3 The email signature is verified 2502 The signature is normally verified by an inbound SMTP server or 2503 possibly the final delivery agent. However, intervening MTAs can 2504 also perform this verification if they choose to do so. The 2505 verification process uses the domain "example.com" extracted from the 2506 "d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM- 2507 Signature" header field to form the DNS DKIM query for: 2509 brisbane._domainkey.example.com 2511 Signature verification starts with the physically last "Received" 2512 header field, the "From" header field, and so forth, in the order 2513 listed in the "h=" tag. Verification follows with a single CRLF 2514 followed by the body (starting with "Hi."). The email is canonically 2515 prepared for verifying with the "simple" method. The result of the 2516 query and subsequent verification of the signature is stored in the 2517 "Authentication-Results" header field line. After successful 2518 verification, the email looks like this: 2520 X-Authentication-Results: shopping.example.net 2521 header.from=joe@football.example.com; dkim=pass 2522 Received: from mout23.football.example.com (192.168.1.1) 2523 by shopping.example.net with SMTP; 2524 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2525 DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; 2526 c=simple; q=dns/txt; i=joe@football.example.com; 2527 h=Received : From : To : Subject : Date : Message-ID; 2528 bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; 2529 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2530 VoG4ZHRNiYzR 2531 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2532 by submitserver.example.com with SUBMISSION; 2533 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2534 From: Joe SixPack 2535 To: Suzie Q 2536 Subject: Is dinner ready? 2537 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2538 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2540 Hi. 2542 We lost the game. Are you hungry yet? 2544 Joe. 2546 Appendix B. Usage Examples (INFORMATIVE) 2548 Studies in this appendix are for informational purposes only. In no 2549 case should these examples be used as guidance when creating an 2550 implementation. 2552 B.1 Simple Message Forwarding 2554 In some cases the recipient may request forwarding of email messages 2555 from the original address to another, through the use of a Unix 2556 .forward file or equivalent. In this case messages are typically 2557 forwarded without modification, except for the addition of a Received 2558 header field to the message and a change in the Envelope-to address. 2559 In this case, the eventual recipient should be able to verify the 2560 original signature since the signed content has not changed, and 2561 attribute the message correctly. 2563 B.2 Outsourced Business Functions 2565 Outsourced business functions represent a use case that motivates the 2566 need for Selectors (the "s=" signature tag) and granularity (the "g=" 2567 key tag). Examples of outsourced business functions are legitimate 2568 email marketing providers and corporate benefits providers. In 2569 either case, the outsourced function would like to be able to send 2570 messages using the email domain of the client company. At the same 2571 time, the client may be reluctant to register a key for the provider 2572 that grants the ability to send messages for any address in the 2573 domain. 2575 The outsourcing company can generate a keypair and the client company 2576 can register the public key using a unique Selector for a specific 2577 address such as winter-promotions@example.com by specifying a 2578 granularity of "g=winter-promotions" or "g=*-promotions" (to allow a 2579 range of addresses). This would enable the provider to send messages 2580 using that specific address and have them verify properly. The 2581 client company retains control over the email address because it 2582 retains the ability to revoke the key at any time. 2584 B.3 PDAs and Similar Devices 2586 PDAs are one example of the use of multiple keys per user. Suppose 2587 that John Doe wanted to be able to send messages using his corporate 2588 email address, jdoe@example.com, and the device did not have the 2589 ability to make a VPN connection to the corporate network. If the 2590 device was equipped with a private key registered for 2591 jdoe@example.com by the administrator of that domain, and appropriate 2592 software to sign messages, John could send signed messages through 2593 the outgoing network of the PDA service provider. 2595 B.4 Mailing Lists 2597 There is a wide range of behavior in forwarders and mailing lists 2598 (collectively called "forwarders" below), ranging from those which 2599 make no modification to the message itself (other than to add a 2600 Received header field and change the envelope information) to those 2601 which may add header fields, change the Subject header field, add 2602 content to the body (typically at the end), or reformat the body in 2603 some manner. 2605 Forwarders which do not modify the body or signed header fields of a 2606 message with a valid signature may re-sign the message as described 2607 below. 2609 Forwarders which make any modification to a message that could result 2610 in its signature becoming invalid should sign or re-sign using an 2611 appropriate identification (e.g., mailing-list-name@example.net). 2612 Since in so doing the (re-)signer is taking responsibility for the 2613 content of the message, modifying forwarders may elect to forward or 2614 re-sign only for messages which were received with valid signatures 2615 or other indications that the messages being signed are not spoofed. 2617 Forwarders which wish to re-sign a message must apply a Sender header 2618 field to the message to identify the address being used to sign the 2619 message and must remove any preexisting Sender header field as 2620 required by [RFC2822]. The forwarder applies a new DKIM-Signature 2621 header field with the signature, public key, and related information 2622 of the forwarder. 2624 B.5 Affinity Addresses 2626 "Affinity addresses" are email addresses that users employ to have an 2627 email address that is independent of any changes in email service 2628 provider they may choose to make. They are typically associated with 2629 college alumni associations, professional organizations, and 2630 recreational organizations with which they expect to have a long-term 2631 relationship. These domains usually provide forwarding of incoming 2632 email, but (currently) usually depend on the user to send outgoing 2633 messages through their own service provider's MTA. They usually have 2634 an associated Web application which authenticates the user and allows 2635 the forwarding address to be changed. 2637 With DKIM, affinity domains could use the Web application to allow 2638 users to register their own public keys to be used to sign messages 2639 on behalf of their affinity address. This is another application 2640 that takes advantage of user-level keying, and domains used for 2641 affinity addresses would typically have a very large number of user- 2642 level keys. Alternatively, the affinity domain could handle outgoing 2643 mail, operating a mail submission agent that authenticates users 2644 before accepting and signing messages for them. This is of course 2645 dependent on the user's service provider not blocking the relevant 2646 TCP ports used for mail submission. 2648 B.6 Third-party Message Transmission 2650 Third-party message transmission refers to the authorized sending of 2651 mail by an Internet application on behalf of a user. For example, a 2652 website providing news may allow the reader to forward a copy of the 2653 message to a friend; this is typically done using the reader's email 2654 address. This is sometimes referred to as the "Evite problem", named 2655 after the website of the same name that allows a user to send 2656 invitations to friends. 2658 One way this can be handled is to continue to put the reader's email 2659 address in the From header field of the message, but put an address 2660 owned by the site into the Sender header field, and sign the message 2661 on behalf of that address. A verifying MTA could accept this and 2662 rewrite the From header field to indicate the address that was 2663 verified, i.e., From: John Doe via news@news-site.com 2664 . (However, such rewriting must be done after the 2665 verification pass is complete, and will break any later attempts to 2666 re-verify.) 2668 B.7 SMTP Servers for Roaming Users 2670 Roaming users may find themselves in circumstances where it is 2671 convenient or necessary to use an SMTP server other than their home 2672 server; examples are IETF conferences and many hotels. In such 2673 circumstances the signature, if any, will be added by a party other 2674 than the user's home system. 2676 Ideally roaming users would connect back to their home server using 2677 either a VPN or a SUBMISSION server running with SMTP AUTHentication 2678 on port 587. If the signing can be performed on the roaming user's 2679 laptop then they can sign before submission, although the risk of 2680 further modification may be high. If neither of these are possible, 2681 these roaming users will not be able to send mail signed using their 2682 own domain key. 2684 Appendix C. Creating a public key (INFORMATIVE) 2686 The default signature is an RSA signed SHA256 digest of the complete 2687 email. For ease of explanation, the openssl command is used to 2688 describe the mechanism by which keys and signatures are managed. One 2689 way to generate a 1024 bit, unencrypted private-key suitable for 2690 DKIM, is to use openssl like this: 2692 $ openssl genrsa -out rsa.private 1024 2694 For increased security, the "-passin" parameter can also be added to 2695 encrypt the private key. Use of this parameter will require entering 2696 a password for several of the following steps. Servers may prefer to 2697 use hardware cryptographic support. 2699 The "genrsa" step results in the file rsa.private containing the key 2700 information similar to this: 2702 -----BEGIN RSA PRIVATE KEY----- 2703 MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC 2704 jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb 2705 to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB 2706 AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX 2707 /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ 2708 gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO 2709 n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 2710 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ 2711 eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 2712 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 2713 qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf 2714 eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX 2715 GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= 2716 -----END RSA PRIVATE KEY----- 2718 To extract the public-key component from the private-key, use openssl 2719 like this: 2721 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 2723 This results in the file rsa.public containing the key information 2724 similar to this: 2726 -----BEGIN PUBLIC KEY----- 2727 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM 2728 oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R 2729 tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI 2730 MmPSPDdQPNUYckcQ2QIDAQAB 2731 -----END PUBLIC KEY----- 2733 This public-key data (without the BEGIN and END tags) is placed in 2734 the DNS. With the signature, canonical email contents, and public 2735 key, a verifying system can test the validity of the signature. The 2736 openssl invocation to verify a signature looks like this: 2738 openssl dgst -verify rsa.public -sha256 -signature signature.file \ 2739 . 2805 Appendix F. Edit History 2807 [[This section to be removed before publication.]] 2809 F.1 Changes since -ietf-03 version 2811 The following changes were made between draft-ietf-dkim-base-03 and 2812 draft-ietf-dkim-base-04: 2814 o Re-worded Abstract to avoid use of "prove" and "non-repudiation". 2816 o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. 2818 o Capitalize Selector throughout. 2820 o Add discussion of plain text, mentioning informatively that 2821 implementors should plan for eventual 8-bit requirements. 2823 o Drop RSA requirement of exponent of 65537 (not required, since it 2824 is already in the key) and clarify the key format. 2826 o Drop SHOULD that DKIM-Signature should precede header fields that 2827 it signs. 2829 o Mention that wildcard DNS records MUST NOT be used for selector 2830 records. 2832 o Add section 3.8 to clarify the t=s flag. 2834 o Change the list of header fields that MUST be signed to include 2835 only From. 2837 o Require that verifier check that From is in the list of signed 2838 header fields. 2840 o Drop all reference to draft-kucherawy-sender-auth-header draft. 2842 o Substantially expand Section 7 (IANA Considerations) to include 2843 initial registries. 2845 o Add section B.7 (use case: SMTP Servers for Roaming Users). 2847 o Add several examples; update some others. 2849 o Considerable minor editorial updating to clarify language, delete 2850 redundant text, fix spelling errors, etc. 2852 Still to be resolved: 2854 o How does "simple" body canonicalization interact with BINARYMIME 2855 data? 2857 o Deal with "relaxed" body canonicalizations, especially in regard 2858 to bare CRs and NLs. 2860 o How to handle "*" in g= dot-atom-text (which allows "*" as a 2861 literal character). 2863 o The IANA Considerations need to be completed and cleaned up. 2865 F.2 Changes since -ietf-02 version 2867 The following changes were made between draft-ietf-dkim-base-02 and 2868 draft-ietf-dkim-base-03: 2870 o Section 5.2: changed key expiration text to be informational; 2871 drop "seven day" wording in favor of something vaguer. 2873 o Don't indicate that the "i=" tag value should be passed to the key 2874 lookup service; this can be added as an extension if required. 2876 o Move Section 6.6 (MUA Considerations) to be Appendix D and modify 2877 it to avoid any hint of normative language. 2879 o Soften the DKIM_STAT_ language in section 6 so that it doesn't 2880 appear normative. This involved using only PERMFAIL and TEMPFAIL 2881 as status, with parenthetical explanations. 2883 o Restructured section 6 to make it clearer which steps apply on a 2884 per-signature basis versus a per-message basis. 2886 o Clarification of "signing identity" in several places. 2888 o Clarification that DKIM-Signature header fields being signed by 2889 another DKIM-Signature header field should be treated as a normal 2890 header field (i.e., their "b=" field is unchanged). 2892 o Change ABNF on a= tag to separate the public key algorithm from 2893 the hash algorithm. 2895 o Add t=s flag in key record to disallow subdomains in the i= tag 2896 relative to the d= tag of the DKIM-Signature header field. 2898 o Add a new definition for "dkim-quoted-printable", which is a 2899 simple case of quoted-printable from RFC2045. dkim-quoted- 2900 printable requires that all white space in the original text be 2901 escaped, and all unescaped white space in the encoded field should 2902 be ignored to allow arbitrary wrapping of the header fields which 2903 may contain the content. 2905 o Use dkim-quoted-printable as the encoding used in z= rather than 2906 referring to RFC2045, since they are different. 2908 o Rewrite description of g= tag in the key record. 2910 o Deleted use of Domain in ABNF, which permits address-literals; 2911 define domain-name to act in stead. 2913 F.3 Changes since -ietf-01 version 2915 The following changes were made between draft-ietf-dkim-base-01 and 2916 draft-ietf-dkim-base-02: 2918 o Change wording on "x=" tag in DKIM-Signature header field 2919 regarding verifier handling of expired signatures from MUST to MAY 2920 (per 20 April Jabber session). Also, make it clear that received 2921 time is to be preferred over current time if reliably available. 2923 o Several changes to limit wording that would intrude into verifier 2924 policy. This is largely changing statements such as "... MUST 2925 reject the message" to "... MUST consider the signature invalid." 2927 o Drop normative references to ID-DKIM-RR, OpenSSL, PEM, and 2928 Stringprep. 2930 o Change "v=" tag in DKIM-Signature from "MUST NOT" to "MUST"; the 2931 version number is 0.2 for this draft, with the expectation that 2932 the first official version will be "v=1". (Per 18 May Jabber 2933 session.) 2935 o Change "q=dns" query access method to "q=dnstxt" to emphasize the 2936 use of the TXT record. The expectation is that a later extension 2937 will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 2938 May Jabber session.) 2940 o Several typos fixed, including removing a paragraph that implied 2941 that the DKIM-Signature header field should be hashed with the 2942 body (it should not). 2944 F.4 Changes since -ietf-00 version 2946 The following changes were made between draft-ietf-dkim-base-00 and 2947 draft-ietf-dkim-base-01: 2949 o Added section 8.9 (Information Leakage). 2951 o Replace section 4 (Multiple Signatures) with much less vague text. 2953 o Fixed ABNF for base64string. 2955 o Added rsa-sha256 signing algorithm. 2957 o Expanded several examples. 2959 o Changed signing algorithm to use separate hash of the body of the 2960 message; this is represented as the "bh=" tag in the DKIM- 2961 Signature header field. 2963 o Changed "z=" tag so that it need not have the same header field 2964 names as the "h=" tag. 2966 o Significant wordsmithing. 2968 F.5 Changes since -allman-01 version 2970 The following changes were made between draft-allman-dkim-base-01 and 2971 draft-ietf-dkim-base-00: 2973 o Remove references to Sender Signing Policy document. Such 2974 consideration is implicitly included in Section 6.3. 2976 o Added ABNF for all tags. 2978 o Updated references (still includes some references to expired 2979 drafts, notably ID-AUTH-RES. 2981 o Significant wordsmithing. 2983 F.6 Changes since -allman-00 version 2985 The following changes were made between draft-allman-dkim-base-00 and 2986 draft-allman-dkim-base-01: 2988 o Changed "c=" tag to separate out header from body 2989 canonicalization. 2991 o Eliminated "nowsp" canonicalization in favor of "relaxed", which 2992 is somewhat less relaxed (but more secure) than "nowsp". 2994 o Moved the (empty) Compliance section to the Sender Signing Policy 2995 document. 2997 o Added several IANA Considerations. 2999 o Fixed a number of grammar and formatting errors. 3001 Intellectual Property Statement 3003 The IETF takes no position regarding the validity or scope of any 3004 Intellectual Property Rights or other rights that might be claimed to 3005 pertain to the implementation or use of the technology described in 3006 this document or the extent to which any license under such rights 3007 might or might not be available; nor does it represent that it has 3008 made any independent effort to identify any such rights. Information 3009 on the procedures with respect to rights in RFC documents can be 3010 found in BCP 78 and BCP 79. 3012 Copies of IPR disclosures made to the IETF Secretariat and any 3013 assurances of licenses to be made available, or the result of an 3014 attempt made to obtain a general license or permission for the use of 3015 such proprietary rights by implementers or users of this 3016 specification can be obtained from the IETF on-line IPR repository at 3017 http://www.ietf.org/ipr. 3019 The IETF invites any interested party to bring to its attention any 3020 copyrights, patents or patent applications, or other proprietary 3021 rights that may cover technology that may be required to implement 3022 this standard. Please address the information to the IETF at 3023 ietf-ipr@ietf.org. 3025 The IETF has been notified of intellectual property rights claimed in 3026 regard to some or all of the specification contained in this 3027 document. For more information consult the online list of claimed 3028 rights. 3030 Disclaimer of Validity 3032 This document and the information contained herein are provided on an 3033 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3034 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3035 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3036 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3037 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3038 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3040 Copyright Statement 3042 Copyright (C) The Internet Society (2006). This document is subject 3043 to the rights, licenses and restrictions contained in BCP 78, and 3044 except as set forth therein, the authors retain all their rights. 3046 Acknowledgment 3048 Funding for the RFC Editor function is currently provided by the 3049 Internet Society.