idnits 2.17.1 draft-ietf-dkim-base-05.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 3113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3098. ** 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 2 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 1245 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 (August 23, 2006) is 6455 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 2800, 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 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 9 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: February 24, 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 August 23, 2006 14 DomainKeys Identified Mail (DKIM) Signatures 15 draft-ietf-dkim-base-05 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 February 24, 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 . . . . . . . . . . 37 96 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 37 97 6.1 Extract Signatures from the Message . . . . . . . . . . . 38 98 6.2 Communicate Verification Results . . . . . . . . . . . . . 43 99 6.3 Interpret Results/Apply Local Policy . . . . . . . . . . . 43 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 101 7.1 DKIM-Signature Tag Specifications . . . . . . . . . . . . 45 102 7.2 DKIM-Signature Query Method Registry . . . . . . . . . . . 45 103 7.3 DKIM-Signature Canonicalization Registry . . . . . . . . . 46 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 7.7 DKIM Service Types Registry . . . . . . . . . . . . . . . 48 108 7.8 DKIM Selector Flags Registry . . . . . . . . . . . . . . . 48 109 8. Security Considerations . . . . . . . . . . . . . . . . . . 49 110 8.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 49 111 8.2 Misappropriated Private Key . . . . . . . . . . . . . . . 49 112 8.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 50 113 8.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 51 114 8.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 51 115 8.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 52 116 8.7 Intentionally malformed Key Records . . . . . . . . . . . 52 117 8.8 Intentionally Malformed DKIM-Signature header fields . . . 52 118 8.9 Information Leakage . . . . . . . . . . . . . . . . . . . 52 119 8.10 Remote Timing Attacks . . . . . . . . . . . . . . . . . 53 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 121 9.1 Normative References . . . . . . . . . . . . . . . . . . . 53 122 9.2 Informative References . . . . . . . . . . . . . . . . . . 53 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 124 A. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 56 125 A.1 The user composes an email . . . . . . . . . . . . . . . . 56 126 A.2 The email is signed . . . . . . . . . . . . . . . . . . . 56 127 A.3 The email signature is verified . . . . . . . . . . . . . 57 128 B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 58 129 B.1 Simple Message Forwarding . . . . . . . . . . . . . . . . 58 130 B.2 Outsourced Business Functions . . . . . . . . . . . . . . 58 131 B.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 59 132 B.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 59 133 B.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 60 134 B.6 Third-party Message Transmission . . . . . . . . . . . . . 60 135 B.7 SMTP Servers for Roaming Users . . . . . . . . . . . . . . 61 136 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 61 137 D. MUA Considerations . . . . . . . . . . . . . . . . . . . . . 63 138 E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 139 F. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 64 140 F.1 Changes since -ietf-04 version . . . . . . . . . . . . . . 64 141 F.2 Changes since -ietf-03 version . . . . . . . . . . . . . . 64 142 F.3 Changes since -ietf-02 version . . . . . . . . . . . . . . 66 143 F.4 Changes since -ietf-01 version . . . . . . . . . . . . . . 67 144 F.5 Changes since -ietf-00 version . . . . . . . . . . . . . . 67 145 F.6 Changes since -allman-01 version . . . . . . . . . . . . . 68 146 F.7 Changes since -allman-00 version . . . . . . . . . . . . . 68 147 Intellectual Property and Copyright Statements . . . . . . . 69 149 1. Introduction 151 [[Note: text in double square brackets (such as this text) will be 152 deleted before publication.]] 154 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 155 messages can be cryptographically signed, permitting a signing domain 156 to claim responsibility for the introduction of a message into the 157 mail stream. Message recipients can verify the signature by querying 158 the signer's domain directly to retrieve the appropriate public key, 159 and thereby confirm that the message was attested to by a party in 160 possession of the private key for the signing domain. 162 The approach taken by DKIM differs from previous approaches to 163 message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: 165 o the message signature is written as a message header field so that 166 neither human recipients nor existing MUA (Mail User Agent) 167 software are confused by signature-related content appearing in 168 the message body, 170 o there is no dependency on public and private key pairs being 171 issued by well-known, trusted certificate authorities, 173 o there is no dependency on the deployment of any new Internet 174 protocols or services for public key distribution or revocation, 176 o signature verification failure does not result in rejection of the 177 message, 179 o no attempt is made to include encryption as part of the mechanism, 181 o archival is not a design goal. 183 DKIM: 185 o is compatible with the existing email infrastructure and 186 transparent to the fullest extent possible 188 o requires minimal new infrastructure 190 o can be implemented independently of clients in order to reduce 191 deployment time 193 o does not require the use of an additional trusted third party 194 (such as a certificate authority or other entity) which might 195 impose significant costs or introduce delays to deployment 197 o can be deployed incrementally 199 o allows delegation of signing to third parties 201 1.1 Signing Identity 203 DKIM separates the question of the identity of the signer of the 204 message from the purported author of the message. In particular, a 205 signature includes the identity of the signer. Verifiers can use the 206 signing information to decide how they want to process the message. 207 The signing identity is included as part of the signature header 208 field. 210 INFORMATIVE RATIONALE: The signing identity specified by a DKIM 211 signature is not required to match an address in any particular 212 header field because of the broad methods of interpretation by 213 recipient mail systems, including MUAs. 215 1.2 Scalability 217 DKIM is designed to support the extreme scalability requirements 218 which characterize the email identification problem. There are 219 currently over 70 million domains and a much larger number of 220 individual addresses. DKIM seeks to preserve the positive aspects of 221 the current email infrastructure, such as the ability for anyone to 222 communicate with anyone else without introduction. 224 1.3 Simple Key Management 226 DKIM differs from traditional hierarchical public-key systems in that 227 no key signing infrastructure is required; the verifier requests the 228 public key from the claimed signer directly. 230 The DNS is proposed as the initial mechanism for publishing public 231 keys. DKIM is designed to be extensible to other key fetching 232 services as they become available. 234 2. Terminology and Definitions 236 This section defines terms used in the rest of the document. Syntax 237 descriptions use the form described in Augmented BNF for Syntax 238 Specifications [RFC4234]. 240 2.1 Signers 242 Elements in the mail system that sign messages are referred to as 243 signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission 244 Agents), MTAs (Mail Transfer Agents), or other agents such as mailing 245 list exploders. In general any signer will be involved in the 246 injection of a message into the message system in some way. The key 247 issue is that a message must be signed before it leaves the 248 administrative domain of the signer. 250 2.2 Verifiers 252 Elements in the mail system that verify signatures are referred to as 253 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 254 In most cases it is expected that verifiers will be close to an end 255 user (reader) of the message or some consuming agent such as a 256 mailing list exploder. 258 2.3 White Space 260 There are three forms of white space: 262 o WSP represents simple white space, i.e., a space or a tab 263 character. 265 o SWSP is streaming white space, defined as WSP plus CRLF. 267 o FWS is folding white space. It allows multiple lines separated by 268 CRLF followed by at least one white space, to be joined. 270 The formal ABNF SWSP and FWS is: 272 SWSP = WSP / CRLF ; streaming white space 273 FWSP = ([*WSP CRLF] 1*WSP) 275 The definition of FWS is identical to that in [RFC2822] except for 276 the exclusion of obs-FWS. WSP is inherited from [RFC4234]. 278 2.4 Common ABNF Tokens 280 The following ABNF tokens are used elsewhere in this document. 282 hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] 283 base64string = 1*(ALPHA / DIGIT / "+" / "/" / "=" / SWSP) 285 2.5 Imported ABNF Tokens 287 The following tokens are imported from other RFCs as noted. Those 288 RFCs should be considered definitive. However, all tokens having 289 names beginning with "obs-" should be excluded from this import, as 290 they have been obsoleted and are expected to go away in future 291 editions of those RFCs. 293 The following tokens are imported from [RFC2821]: 295 o "Local-part" (implementation warning: this permits quoted 296 strings) 298 o "sub-domain" 300 The following definitions are imported from [RFC2822]: 302 o "WSP" (space or tab) 304 o "FWS" (folding white space) 306 o "field-name" (name of a header field) 308 o "dot-atom-text" (in the local-part of an email address) 310 The following tokens are imported from [RFC2045]: 312 o "qp-section" (a single line of quoted-printable-encoded text) 314 o "hex-octet" (a quoted-printable encoded octet) 316 INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not 317 obey the rules of RFC 4234 and must be interpreted accordingly, 318 particularly as regards case folding. 320 Other tokens not defined herein are imported from [RFC4234]. These 321 are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, 322 etc. 324 2.6 DKIM-Quoted-Printable 326 The DKIM-Quoted-Printable encoding syntax resembles that described in 327 Quoted-Printable [RFC2045] section 6.7: any character MAY be encoded 328 as an "=" followed by two hexadecimal digits from the alphabet 329 "0123456789ABCDEF" (no lower case characters permitted) representing 330 the hexadecimal-encoded integer value of that character. All control 331 characters (those with values < %x20), eight-bit characters (values > 332 %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon 333 (";", %x3B) MUST be encoded. Note that all white space, including 334 SPACE, CR and LF characters, MUST be encoded. After encoding, FWS 335 MAY be added at arbitrary locations in order to avoid excessively 336 long lines; such white space is NOT part of the value, and MUST be 337 removed before decoding. 339 ABNF: 340 dkim-quoted-printable = 341 *(FWS / hex-octet / dkim-safe-char) 342 ; hex-octet is from RFC 2045 343 dkim-safe-char = %x21-3A / %x3C / %x3E-7E 344 ; '!' - ':', '<', '>' - '~' 345 ; Characters not listed as "mail-safe" in 346 ; RFC 2049 are also not recommended. 348 INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- 349 Printable as defined in RFC 2045 in several important ways: 351 1. White space in the input text, including CR and LF, must be 352 encoded. RFC 2045 does not require such encoding, and does 353 not permit encoded of CR or LF characters that are part of a 354 CRLF line break. 356 2. White space in the encoded text is ignored. This is to allow 357 DKIM-Quoted-Printable to be wrapped as needed in headers. In 358 particular, RFC 2045 requires that line breaks in the input be 359 represented as physical line breaks; that is not the case 360 here. 362 3. The "soft line break" syntax ("=" as the last non-white-space 363 character on the line) does not apply. 365 4. DKIM-Quoted-Printable does not require that encoded lines be 366 no more than 76 characters long (although there may be other 367 requirements depending on the context in which the encoded 368 text is being used). 370 3. Protocol Elements 372 Protocol Elements are conceptual parts of the protocol that are not 373 specific to either signers or verifiers. The protocol descriptions 374 for signers and verifiers are described in later sections (Signer 375 Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This 376 section must be read in the context of those sections. 378 3.1 Selectors 380 To support multiple concurrent public keys per signing domain, the 381 key namespace is subdivided using "Selectors". For example, 382 Selectors might indicate the names of office locations (e.g., 383 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 384 (e.g., "january2005", "february2005", etc.), or even the individual 385 user. 387 Selectors are needed to support some important use cases. For 388 example: 390 o Domains which want to delegate signing capability for a specific 391 address for a given duration to a partner, such as an advertising 392 provider or other out-sourced function. 394 o Domains which want to allow frequent travelers to send messages 395 locally without the need to connect with a particular MSA. 397 o "Affinity" domains (e.g., college alumni associations) which 398 provide forwarding of incoming mail but which do not operate a 399 mail submission agent for outgoing mail. 401 Periods are allowed in Selectors and are component separators. When 402 keys are retrieved from the DNS, periods in Selectors define DNS 403 label boundaries in a manner similar to the conventional use in 404 domain names. Selector components might be used to combine dates 405 with locations; for example, "march2005.reykjavik". In a DNS 406 implementation, this can be used to allow delegation of a portion of 407 the Selector name-space. 409 ABNF: 410 selector = sub-domain *( "." sub-domain ) 412 The number of public keys and corresponding Selectors for each domain 413 are determined by the domain owner. Many domain owners will be 414 satisfied with just one Selector whereas administratively distributed 415 organizations may choose to manage disparate Selectors and key pairs 416 in different regions or on different email servers. 418 Beyond administrative convenience, Selectors make it possible to 419 seamlessly replace public keys on a routine basis. If a domain 420 wishes to change from using a public key associated with Selector 421 "january2005" to a public key associated with Selector 422 "february2005", it merely makes sure that both public keys are 423 advertised in the public-key repository concurrently for the 424 transition period during which email may be in transit prior to 425 verification. At the start of the transition period, the outbound 426 email servers are configured to sign with the "february2005" private- 427 key. At the end of the transition period, the "january2005" public 428 key is removed from the public-key repository. 430 INFORMATIVE NOTE: A key may also be revoked as described below. 431 The distinction between revoking and removing a key selector 432 record is subtle. When phasing out keys as described above, a 433 signing domain would probably simply remove the key record after 434 the transition period. However, a signing domain could elect to 435 revoke the key (but maintain the key record) for a further period. 436 There is no defined semantic difference between a revoked key and 437 a removed key. 439 While some domains may wish to make Selector values well known, 440 others will want to take care not to allocate Selector names in a way 441 that allows harvesting of data by outside parties. E.g., if per-user 442 keys are issued, the domain owner will need to make the decision as 443 to whether to associate this Selector directly with the user name, or 444 make it some unassociated random value, such as a fingerprint of the 445 public key. 447 INFORMATIVE IMPLEMENTERS' NOTE: reusing a Selector with a new key 448 (for example, changing the key associated with a user's name) 449 makes it impossible to tell the difference between a message that 450 didn't verify because the key is no longer valid versus a message 451 that is actually forged. Signers should not change the key 452 associated with a Selector. When creating a new key, signers 453 should associate it with a new Selector. 455 3.2 Tag=Value Lists 457 DKIM uses a simple "tag=value" syntax in several contexts, including 458 in messages and domain signature records. 460 Values are a series of strings containing either plain text, "base64" 461 text (as defined in [RFC2045], section 6.8), "qp-section" (ibid, 462 section 6.7), or "dkim-quoted-printable" (as defined above). The 463 name of the tag will determine the encoding of each value; however, 464 no encoding may include the semicolon (";") character, since that 465 separates tag-specs. 467 INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" 468 defined below (as "tag-value") only includes 7-bit characters, an 469 implementation that wished to anticipate future standards would be 470 advised to not preclude the use of UTF8-encoded text in tag=value 471 lists. 473 Formally, the syntax rules are: 474 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 475 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 476 tag-name = ALPHA 0*ALNUMPUNC 477 tag-value = [ 1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR ) ] 478 ; WSP and FWS prohibited at beginning and end 479 VALCHAR = %x21-3A / %x3C-7E 480 ; EXCLAMATION to TILDE except SEMICOLON 481 ALNUMPUNC = ALPHA / DIGIT / "_" 483 Note that WSP is allowed anywhere around tags; in particular, any WSP 484 after the "=" and any WSP before the terminating ";" is not part of 485 the value; however, WSP inside the value is significant. 487 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 488 processed as case sensitive unless the specific tag description of 489 semantics specifies case insensitivity. 491 Tags with duplicate names MUST NOT be specified within a single tag- 492 list. 494 Whitespace within a value MUST be retained unless explicitly excluded 495 by the specific tag description. 497 Tag=value pairs that represent the default value MAY be included to 498 aid legibility. 500 Unrecognized tags MUST be ignored. 502 Tags that have an empty value are not the same as omitted tags. An 503 omitted tag is treated as having the default value; a tag with an 504 empty value explicitly designates the empty string as the value. For 505 example, "g=" does not mean "g=*", even though "g=*" is the default 506 for that tag. 508 3.3 Signing and Verification Algorithms 510 DKIM supports multiple digital signature algorithms. Two algorithms 511 are defined by this specification at this time: rsa-sha1, and rsa- 512 sha256. The rsa-sha256 algorithm is the default if no algorithm is 513 specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. 514 Signers MUST implement and SHOULD sign using rsa-sha256. 516 3.3.1 The rsa-sha1 Signing Algorithm 518 The rsa-sha1 Signing Algorithm computes a message hash as described 519 in Section 3.7 below using SHA-1 as the hash-alg. That hash is then 520 signed by the signer using the RSA algorithm (defined in PKCS#1 521 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 522 The hash MUST NOT be truncated or converted into any form other than 523 the native binary form before being signed. 525 3.3.2 The rsa-sha256 Signing Algorithm 527 The rsa-sha256 Signing Algorithm computes a message hash as described 528 in Section 3.7 below using SHA-256 as the hash-alg. That hash is 529 then signed by the signer using the RSA algorithm (actually PKCS#1 530 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. 531 The hash MUST NOT be truncated or converted into any form other than 532 the native binary form before being signed. 534 3.3.3 Other algorithms 536 Other algorithms MAY be defined in the future. Verifiers MUST ignore 537 any signatures using algorithms that they do not implement. 539 3.3.4 Key sizes 541 Selecting appropriate key sizes is a trade-off between cost, 542 performance and risk. Since short RSA keys more easily succumb to 543 off-line attacks, signers MUST use RSA keys of at least 1024 bits for 544 long-lived keys. Verifiers MUST be able to validate signatures with 545 keys ranging from 512 bits to 2048 bits, and they MAY be able to 546 validate signatures with larger keys. Verifier policies may use the 547 length of the signing key as one metric for determining whether a 548 signature is acceptable. 550 Factors that should influence the key size choice include: 552 o The practical constraint that large keys may not fit within a 512 553 byte DNS UDP response packet 555 o The security constraint that keys smaller than 1024 bits are 556 subject to off-line attacks 558 o Larger keys impose higher CPU costs to verify and sign email 560 o Keys can be replaced on a regular basis, thus their lifetime can 561 be relatively short 563 o The security goals of this specification are modest compared to 564 typical goals of public-key systems 566 See [RFC3766] for further discussion of selecting key sizes. 568 3.4 Canonicalization 570 Empirical evidence demonstrates that some mail servers and relay 571 systems modify email in transit, potentially invalidating a 572 signature. There are two competing perspectives on such 573 modifications. For most signers, mild modification of email is 574 immaterial to the authentication status of the email. For such 575 signers a canonicalization algorithm that survives modest in-transit 576 modification is preferred. 578 Other signers demand that any modification of the email, however 579 minor, result in a signature verification failure. These signers 580 prefer a canonicalization algorithm that does not tolerate in-transit 581 modification of the signed email. 583 Some signers may be willing to accept modifications to header fields 584 that are within the bounds of email standards such as [RFC2822], but 585 are unwilling to accept any modification to the body of messages. 587 To satisfy all requirements, two canonicalization algorithms are 588 defined for each of the header and the body: a "simple" algorithm 589 that tolerates almost no modification and a "relaxed" algorithm that 590 tolerates common modifications such as white-space replacement and 591 header field line re-wrapping. A signer MAY specify either algorithm 592 for header or body when signing an email. If no canonicalization 593 algorithm is specified by the signer, the "simple" algorithm defaults 594 for both header and body. Verifiers MUST implement both 595 canonicalization algorithms. Note that the header and body may use 596 different canonicalization algorithms. Further canonicalization 597 algorithms MAY be defined in the future; verifiers MUST ignore any 598 signatures that use unrecognized canonicalization algorithms. 600 [[NON-NORMATIVE DISCUSSION POINT: If a message is transmitted 601 using CHUNKING (that is, BDAT instead of the DATA command) and 602 BODY=BINARYMIME [RFC3030] then the body should be treated as a 603 binary stream, and no canonicalization whatsoever should be done. 604 Do we want to leave this for the future, say that canonicalization 605 is ignored in this circumstance, or add a third "binary" body 606 canonicalization algorithm? Or something else, of course.]] 608 Canonicalization simply prepares the email for presentation to the 609 signing or verification algorithm. It MUST NOT change the 610 transmitted data in any way. Canonicalization of header fields and 611 body are described below. 613 NOTE: This section assumes that the message is already in "network 614 normal" format (e.g., text is ASCII encoded, lines are separated with 615 CRLF characters, etc.). See also Section 5.3 for information about 616 normalizing the message. 618 3.4.1 The "simple" Header Field Canonicalization Algorithm 620 The "simple" header canonicalization algorithm does not change header 621 fields in any way. Header fields MUST be presented to the signing or 622 verification algorithm exactly as they are in the message being 623 signed or verified. In particular, header field names MUST NOT be 624 case folded and white space MUST NOT be changed. 626 3.4.2 The "relaxed" Header Field Canonicalization Algorithm 628 The "relaxed" header canonicalization algorithm MUST apply the 629 following steps in order: 631 o Convert all header field names (not the header field values) to 632 lower case. For example, convert "SUBJect: AbC" to "subject: 633 AbC". 635 o Unfold all header field continuation lines as described in 636 [RFC2822]; in particular, lines with terminators embedded in 637 continued header field values (that is, CRLF sequences followed by 638 WSP) MUST be interpreted without the CRLF. Implementations MUST 639 NOT remove the CRLF at the end of the header field value. 641 o Convert all sequences of one or more WSP characters to a single SP 642 character. WSP characters here include those before and after a 643 line folding boundary. 645 o Delete all WSP characters at the end of each unfolded header field 646 value. 648 o Delete any WSP characters remaining before and after the colon 649 separating the header field name from the header field value. The 650 colon separator MUST be retained. 652 3.4.3 The "simple" Body Canonicalization Algorithm 654 The "simple" body canonicalization algorithm ignores all empty lines 655 at the end of the message body. An empty line is a line of zero 656 length after removal of the line terminator. If there is no trailing 657 CRLF on the message, a CRLF is added. It makes no other changes to 658 the message body. In more formal terms, the "simple" body 659 canonicalization algorithm converts "0*CRLF" at the end of the body 660 to a single "CRLF". 662 3.4.4 The "relaxed" Body Canonicalization Algorithm 664 [[This section may be deleted; see discussion below.]] The "relaxed" 665 body canonicalization algorithm: 667 o Ignores all white space at the end of lines. Implementations MUST 668 NOT remove the CRLF at the end of the line. 670 o Reduces all sequences of WSP within a line to a single SP 671 character. 673 o Ignores all empty lines at the end of the message body. "Empty 674 line" is defined in Section 3.4.3. 676 [[NON-NORMATIVE DISCUSSION POINT (ISSUE 1326): Mike Thomas has 677 found bare CRs in the wild that are getting converted to CRLF by 678 some MTAs and thus breaking signatures. Shall we (a) drop 679 "relaxed" until we can figure out how to do it right and then put 680 it in as an extension, (b) change "relaxed" to handle this case, 681 probably by having it convert bare CR and LF to CRLF, or (c) 682 something else?]] 684 3.4.5 Body Length Limits 686 A body length count MAY be specified to limit the signature 687 calculation to an initial prefix of the body text, measured in 688 octets. If the body length count is not specified then the entire 689 message body is signed. 691 INFORMATIVE RATIONALE: This capability is provided because it is 692 very common for mailing lists to add trailers to messages (e.g., 693 instructions how to get off the list). Until those messages are 694 also signed, the body length count is a useful tool for the 695 verifier since it may as a matter of policy accept messages having 696 valid signatures with extraneous data. 698 INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables 699 an attack in which an attacker modifies a message to include 700 content that solely benefits the attacker. It is possible for the 701 appended content to completely replace the original content in the 702 end recipient's eyes and to defeat duplicate message detection 703 algorithms. To avoid this attack, signers should be wary of using 704 this tag, and verifiers might wish to ignore the tag or remove 705 text that appears after the specified content length, perhaps 706 based on other criteria. 708 The body length count allows the signer of a message to permit data 709 to be appended to the end of the body of a signed message. The body 710 length count MUST be calculated following the canonicalization 711 algorithm; for example, any white space ignored by a canonicalization 712 algorithm is not included as part of the body length count. Signers 713 of MIME messages that include a body length count SHOULD be sure that 714 the length extends to the closing MIME boundary string. 716 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 717 the only acceptable modifications are to add to the MIME postlude 718 would use a body length count encompassing the entire final MIME 719 boundary string, including the final "--CRLF". A signer wishing 720 to allow additional MIME parts but not modification of existing 721 parts would use a body length count extending through the final 722 MIME boundary string, omitting the final "--CRLF". 724 A body length count of zero means that the body is completely 725 unsigned. 727 Signers wishing to ensure that no modification of any sort can occur 728 should specify the "simple" canonicalization algorithm for both 729 header and body and omit the body length count. 731 3.4.6 Canonicalization Examples (INFORMATIVE) 733 (In the following examples, actual white space is used only for 734 clarity. The actual input and output text is designated using 735 bracketed descriptors: "" for a space character, "" for a 736 tab character, and "" for a carriage-return/line-feed sequence. 737 For example, "X Y" and "XY" represent the same three 738 characters.) 740 Example 1: A message reading: 741 A: X 742 B : Y 743 Z 744 745 C 746 D E 747 748 750 when canonicalized using relaxed canonicalization for both header and 751 body results in a header reading: 752 a:X 753 b:Y Z 755 and a body reading: 756 C 757 D E 759 Example 2: The same message canonicalized using simple 760 canonicalization for both header and body results in a header 761 reading: 762 A: X 763 B : Y 764 Z 766 and a body reading: 767 C 768 D E 770 Example 3: When processed using relaxed header canonicalization and 771 simple body canonicalization, the canonicalized version has a header 772 of: 773 a:X 774 b:Y Z 776 and a body reading: 777 C 778 D E 780 3.5 The DKIM-Signature header field 782 The signature of the email is stored in the "DKIM-Signature:" header 783 field. This header field contains all of the signature and key- 784 fetching data. The DKIM-Signature value is a tag-list as described 785 in Section 3.2. 787 The "DKIM-Signature:" header field SHOULD be treated as though it 788 were a trace header field as defined in section 3.6 of [RFC2822], and 789 hence SHOULD NOT be reordered and SHOULD be prepended to the message. 791 The "DKIM-Signature:" header field being created or verified is 792 always included in the signature calculation, after the body of the 793 message; however, when calculating or verifying the signature, the 794 value of the b= tag (signature value) of that DKIM-Signature header 795 field MUST be treated as though it were an empty string. Unknown 796 tags in the "DKIM-Signature:" header field MUST be included in the 797 signature calculation but MUST be otherwise ignored by verifiers. 798 Other "DKIM-Signature:" header fields that are included in the 799 signature should be treated as normal header fields; in particular, 800 the b= tag is not treated specially. 802 The encodings for each field type are listed below. Tags described 803 as qp-section are as described in section 6.7 of MIME Part One 804 [RFC2045], with the additional conversion of semicolon characters to 805 "=3B"; intuitively, this is one line of quoted-printable encoded 806 text. Tags described as dkim-quoted-printable are as defined in 807 Section 2.6. 809 Tags on the DKIM-Signature header field along with their type and 810 requirement status are shown below. Unrecognized tags MUST be 811 ignored. 813 v= Version (MUST be included). This tag defines the version of this 814 specification that applies to the signature record. It MUST have 815 the value 0.5. 817 ABNF: 819 sig-v-tag = %x76 [FWS] "=" [FWS] "0.5" 821 INFORMATIVE NOTE: DKIM-Signature version numbers are 822 expected to increase arithmetically as new versions of this 823 specification are released. 825 [[INFORMATIVE NOTE: Upon publication, this version number 826 should be changed to "1", and this note should be deleted.]] 828 a= The algorithm used to generate the signature (plain-text; 829 REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; 830 signers SHOULD sign using "rsa-sha256". See Section 3.3 for a 831 description of algorithms. 833 ABNF: 835 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 836 sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h 837 sig-a-tag-k = "rsa" / x-sig-a-tag-k 838 sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h 839 x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension 840 x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension 842 b= The signature data (base64; REQUIRED). Whitespace is ignored in 843 this value and MUST be ignored when re-assembling the original 844 signature. In particular, the signing process can safely insert 845 FWS in this value in arbitrary places to conform to line-length 846 limits. See Signer Actions (Section 5) for how the signature is 847 computed. 849 ABNF: 851 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 852 sig-b-tag-data = base64string 854 bh= The hash of the canonicalized body part of the message as limited 855 by the "l=" tag (base64; REQUIRED). Whitespace is ignored in 856 this value and MUST be ignored when re-assembling the original 857 signature. In particular, the signing process can safely insert 858 FWS in this value in arbitrary places to conform to line-length 859 limits. See Section 3.7 for how the body hash is computed. 861 ABNF: 863 sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data 864 sig-bh-tag-data = base64string 866 c= Message canonicalization (plain-text; OPTIONAL, default is 867 "simple/simple"). This tag informs the verifier of the type of 868 canonicalization used to prepare the message for signing. It 869 consists of two names separated by a "slash" (%d47) character, 870 corresponding to the header and body canonicalization algorithms 871 respectively. These algorithms are described in Section 3.4. If 872 only one algorithm is named, that algorithm is used for the 873 header and "simple" is used for the body. For example, 874 "c=relaxed" is treated the same as "c=relaxed/simple". 876 ABNF: 878 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 879 ["/" sig-c-tag-alg] 880 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 881 x-sig-c-tag-alg = hyphenated-word ; for later extension 883 d= The domain of the signing entity (plain-text; REQUIRED). This is 884 the domain that will be queried for the public key. This domain 885 MUST be the same as or a parent domain of the "i=" tag (the 886 signing identity, as described below), or it MUST meet the 887 requirements for parent domain signing described in Section 3.8. 888 When presented with a signature that does not meet these 889 requirement, verifiers MUST consider the signature invalid. 891 Internationalized domain names MUST be encoded as described in 892 [RFC3490]. 894 ABNF: 896 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 897 domain-name = sub-domain 1*("." sub-domain) 898 ; from RFC 2821 Domain, but excluding address-literal 900 h= Signed header fields (plain-text, but see description; REQUIRED). 901 A colon-separated list of header field names that identify the 902 header fields presented to the signing algorithm. The field MUST 903 contain the complete list of header fields in the order presented 904 to the signing algorithm. The field MAY contain names of header 905 fields that do not exist when signed; nonexistent header fields 906 do not contribute to the signature computation (that is, they are 907 treated as the null input, including the header field name, the 908 separating colon, the header field value, and any CRLF 909 terminator). The field MUST NOT include the DKIM-Signature 910 header field that is being created or verified, but may include 911 others. Folding white space (FWS) MAY be included on either side 912 of the colon separator. Header field names MUST be compared 913 against actual header field names in a case insensitive manner. 914 This list MUST NOT be empty. See Section 5.4 for a discussion of 915 choosing header fields to sign. 917 ABNF: 919 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 920 0*( *FWS ":" *FWS hdr-name ) 921 hdr-name = field-name 923 INFORMATIVE EXPLANATION: By "signing" header fields that do 924 not actually exist, a signer can prevent insertion of those 925 header fields before verification. However, since a signer 926 cannot possibly know what header fields might be created in 927 the future, and that some MUAs might present header fields 928 that are embedded inside a message (e.g., as a message/rfc822 929 content type), the security of this solution is not total. 931 INFORMATIVE EXPLANATION: The exclusion of the header field 932 name and colon as well as the header field value for non- 933 existent header fields prevents an attacker from inserting an 934 actual header field with a null value. 936 i= Identity of the user or agent (e.g., a mailing list manager) on 937 behalf of which this message is signed (dkim-quoted-printable; 938 OPTIONAL, default is an empty local-part followed by an "@" 939 followed by the domain from the "d=" tag). The syntax is a 940 standard email address where the local-part MAY be omitted. The 941 domain part of the address MUST be the same as or a subdomain of 942 the value of the "d=" tag. 944 Internationalized domain names MUST be converted using the steps 945 listed in section 4 of [RFC3490] using the "ToASCII" function. 947 ABNF: 949 sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name 951 INFORMATIVE NOTE: The local-part of the "i=" tag is optional 952 because in some cases a signer may not be able to establish a 953 verified individual identity. In such cases, the signer may 954 wish to assert that although it is willing to go as far as 955 signing for the domain, it is unable or unwilling to commit 956 to an individual user name within their domain. It can do so 957 by including the domain part but not the local-part of the 958 identity. 960 INFORMATIVE DISCUSSION: This document does not require the 961 value of the "i=" tag to match the identity in any message 962 header field fields. This is considered to be a verifier 963 policy issue. Constraints between the value of the "i=" tag 964 and other identities in other header fields seek to apply 965 basic authentication into the semantics of trust associated 966 with a role such as content author. Trust is a broad and 967 complex topic and trust mechanisms are subject to highly 968 creative attacks. The real-world efficacy of any but the 969 most basic bindings between the "i=" value and other 970 identities is not well established, nor is its vulnerability 971 to subversion by an attacker. Hence reliance on the use of 972 these options should be strictly limited. In particular it 973 is not at all clear to what extent a typical end-user 974 recipient can rely on any assurances that might be made by 975 successful use of the "i=" options. 977 l= Body length count (plain-text unsigned decimal integer; OPTIONAL, 978 default is entire body). This tag informs the verifier of the 979 number of octets in the body of the email after canonicalization 980 included in the cryptographic hash, starting from 0 immediately 981 following the CRLF preceding the body. This value MUST NOT be 982 larger than the actual number of octets in the canonicalized 983 message body. 985 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 986 allow display of fraudulent content without appropriate 987 warning to end users. The l= tag is intended for increasing 988 signature robustness when sending to mailing lists that both 989 modify their content and do not sign their messages. 990 However, using the l= tag enables attacks in which an 991 intermediary with malicious intent modifies a message to 992 include content that solely benefits the attacker. It is 993 possible for the appended content to completely replace the 994 original content in the end recipient's eyes and to defeat 995 duplicate message detection algorithms. Examples are 996 described in Security Considerations (Section 8). To avoid 997 this attack, signers should be extremely wary of using this 998 tag, and verifiers might wish to ignore the tag or remove 999 text that appears after the specified content length. 1001 INFORMATIVE NOTE: The value of the l= tag is constrained to 1002 76 decimal digits, which will fit in a 256-bit binary integer 1003 field. This constraint is not intended to predict the size 1004 of future messages, but is intended to remind the implementer 1005 to check the length of this and all other tags during 1006 verification. Implementers may need to limit the actual 1007 value expressed to a value smaller than 10^76, e.g., to allow 1008 a message to fit within the available storage space. 1010 ABNF: 1012 sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT 1014 q= A colon-separated list of query methods used to retrieve the 1015 public key (plain-text; OPTIONAL, default is "dns/txt"). Each 1016 query method is of the form "type[/options]", where the syntax 1017 and semantics of the options depends on the type and specified 1018 options. If there are multiple query mechanisms listed, the 1019 choice of query mechanism MUST NOT change the interpretation of 1020 the signature. Implementations MUST use the recognized query 1021 mechanisms in the order presented. 1023 Currently the only valid value is "dns/txt" which defines the DNS 1024 TXT record lookup algorithm described elsewhere in this document. 1025 The only option defined for the "dns" query type is "txt", which 1026 MUST be included. Verifiers and signers MUST support "dns/txt". 1028 ABNF: 1030 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 1031 *([FWS] ":" [FWS] sig-q-tag-method) 1032 sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] 1033 x-sig-q-tag-type = hyphenated-word ; for future extension 1034 x-sig-q-tag-args = qp-hdr-value 1036 s= The Selector subdividing the namespace for the "d=" (domain) tag 1037 (plain-text; REQUIRED). 1039 ABNF: 1041 sig-s-tag = %x73 [FWS] "=" [FWS] selector 1043 t= Signature Timestamp (plain-text unsigned decimal integer; 1044 RECOMMENDED, default is an unknown creation time). The time that 1045 this signature was created. The format is the number of seconds 1046 since 00:00:00 on January 1, 1970 in the UTC time zone. The 1047 value is expressed as an unsigned integer in decimal ASCII. This 1048 value is not constrained to fit into a 31- or 32-bit integer. 1049 Implementations SHOULD be prepared to handle values up to at 1050 least 10^12 (until approximately AD 200,000; this fits into 40 1051 bits). To avoid denial of service attacks, implementations MAY 1052 consider any value longer than 12 digits to be infinite. 1054 ABNF: 1056 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 1058 x= Signature Expiration (plain-text unsigned decimal integer; 1059 RECOMMENDED, default is no expiration). The format is the same 1060 as in the "t=" tag, represented as an absolute date, not as a 1061 time delta from the signing timestamp. The value is expressed as 1062 an unsigned integer in decimal ASCII, with the same contraints on 1063 the value in the "t=" tag. Signatures MAY be considered invalid 1064 if the verification time at the verifier is past the expiration 1065 date. The verification time should be the time that the message 1066 was first received at the administrative domain of the verifier 1067 if that time is reliably available; otherwise the current time 1068 should be used. The value of the "x=" tag MUST be greater than 1069 the value of the "t=" tag if both are present. 1071 INFORMATIVE NOTE: The x= tag is not intended as an anti- 1072 replay defense. 1074 ABNF: 1076 sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT 1078 z= Copied header fields (dkim-quoted-printable, but see description; 1079 OPTIONAL, default is null). A vertical-bar-separated list of 1080 selected header fields present when the message was signed, 1081 including both the field name and value. It is not required to 1082 include all header fields present at the time of signing. This 1083 field need not contain the same header fields listed in the "h=" 1084 tag. The header field text itself must encode the vertical bar 1085 ("|", %x7C) character (i.e., vertical bars in the z= text are 1086 metacharacters, and any actual vertical bar characters in a 1087 copied header field must be encoded). Note that all white space 1088 must be encoded, including white space between the colon and the 1089 header field value. After encoding, SWSP MAY be added at 1090 arbitrary locations in order to avoid excessively long lines; 1091 such white space is NOT part of the value of the header field, 1092 and MUST be removed before decoding. 1094 Verifiers MUST NOT use the header field names or copied values 1095 for checking the signature in any way. Copied header field 1096 values are for diagnostic use only. 1098 Header fields with characters requiring conversion (perhaps from 1099 legacy MTAs which are not [RFC2822] compliant) SHOULD be 1100 converted as described in MIME Part Three [RFC2047]. 1102 ABNF: 1103 sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy 1104 *( [FWS] "|" sig-z-tag-copy ) 1105 sig-z-tag-copy = hdr-name ":" qp-hdr-value 1106 qp-hdr-value = dkim-quoted-printable ; with "|" encoded 1108 INFORMATIVE EXAMPLE of a signature header field spread across 1109 multiple continuation lines: 1111 DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; 1112 c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; 1113 h=from:to:subject:date; 1114 z=From:foo@eng.example.net|To:joe@example.com| 1115 Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; 1116 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; 1117 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 1118 VoG4ZHRNiYzR 1120 3.6 Key Management and Representation 1122 Signature applications require some level of assurance that the 1123 verification public key is associated with the claimed signer. Many 1124 applications achieve this by using public key certificates issued by 1125 a trusted third party. However, DKIM can achieve a sufficient level 1126 of security, with significantly enhanced scalability, by simply 1127 having the verifier query the purported signer's DNS entry (or some 1128 security-equivalent) in order to retrieve the public key. 1130 DKIM keys can potentially be stored in multiple types of key servers 1131 and in multiple formats. The storage and format of keys are 1132 irrelevant to the remainder of the DKIM algorithm. 1134 Parameters to the key lookup algorithm are the type of the lookup 1135 (the "q=" tag), the domain of the responsible signer (the "d=" tag of 1136 the DKIM-Signature header field), and the Selector (the "s=" tag). 1138 public_key = dkim_find_key(q_val, d_val, s_val) 1140 This document defines a single binding, using DNS TXT records to 1141 distribute the keys. Other bindings may be defined in the future. 1143 3.6.1 Textual Representation 1145 It is expected that many key servers will choose to present the keys 1146 in an otherwise unstructured text format (for example, an XML form 1147 would not be considered to be unstructured text for this purpose). 1148 The following definition MUST be used for any DKIM key represented in 1149 an otherwise unstructured textual form. 1151 The overall syntax is a tag-list as described in Section 3.2. The 1152 current valid tags are described below. Other tags MAY be present 1153 and MUST be ignored by any implementation that does not understand 1154 them. 1156 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 1157 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 1158 (without the quotes). This tag MUST be the first tag in the 1159 record. Records beginning with a "v=" tag with any other value 1160 MUST be discarded. 1162 ABNF: 1164 key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" 1166 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 1167 This value MUST match the Local-part of the "i=" tag of the DKIM- 1168 Signature header field (or its default value of the empty string 1169 if "i=" is not specified), with a "*" character matching a 1170 sequence of zero or more arbitrary characters ("wildcarding"). 1171 The intent of this tag is to constrain which signing address can 1172 legitimately use this Selector. An email with a signing address 1173 that does not match the value of this tag constitutes a failed 1174 verification. Wildcarding allows matching for addresses such as 1175 "user+*". An empty "g=" value never matches any addresses. 1177 ABNF: 1179 key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart 1180 key-g-tag-lpart = [dot-atom-text] ["*"] [dot-atom-text] 1182 [[NON-NORMATIVE DISCUSSION POINT: "*" is legal in a "dot- 1183 atom-text". This should probably use a different character 1184 for wildcarding. Unfortunately, the options are non-mnemonic 1185 (e.g., "@", "(", ":"). Alternatively we could insist on 1186 escaping a "*" intended as a literal "*" in the address.]] 1188 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 1189 allowing all algorithms). A colon-separated list of hash 1190 algorithms that might be used. Signers and Verifiers MUST 1191 support the "sha256" hash algorithm. Verifiers MUST also support 1192 the "sha1" hash algorithm. 1194 ABNF: 1196 key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 1197 0*( [FWS] ":" [FWS] key-h-tag-alg ) 1198 key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg 1199 x-key-h-tag-alg = hyphenated-word ; for future extension 1201 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 1202 verifiers MUST support the "rsa" key type. The "rsa" key type 1203 indicates that an ASN.1 DER-encoded [X.660] RSAPublicKey 1204 [RFC3447] (see sections 3.1 and A.1.1) is being used in the p= 1205 tag. (Note: the p= tag further encodes the value using the 1206 base64 algorithm.) 1208 ABNF: 1210 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 1211 key-k-tag-type = "rsa" / x-key-k-tag-type 1212 x-key-k-tag-type = hyphenated-word ; for future extension 1214 [[NON-NORMATIVE DISCUSSION NOTE: In some cases it can be 1215 hard to separate h= and k=; for example DSA implies that 1216 SHA-1 will be used. This might be an actual change to the 1217 spec depending on how we decide to fix this.]] 1219 n= Notes that might be of interest to a human (qp-section; OPTIONAL, 1220 default is empty). No interpretation is made by any program. 1221 This tag should be used sparingly in any key server mechanism 1222 that has space limitations (notably DNS). 1224 ABNF: 1226 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 1228 p= Public-key data (base64; REQUIRED). An empty value means that 1229 this public key has been revoked. The syntax and semantics of 1230 this tag value before being encoded in base64 is defined by the 1231 k= tag. 1233 ABNF: 1235 key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] 1237 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 1238 separated list of service types to which this record applies. 1239 Verifiers for a given service type MUST ignore this record if the 1240 appropriate type is not listed. Currently defined service types 1241 are: 1243 * matches all service types 1245 email electronic mail (not necessarily limited to SMTP) 1247 This tag is intended to permit signers to constrain the use of 1248 delegated keys, e.g., where a company is willing to delegate the 1249 right to send mail in their name to an outsourcer, but not to 1250 send IM or make VoIP calls. (This of course presumes that these 1251 keys are used in other services in the future.) 1252 ABNF: 1254 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type 1255 0*( [FWS] ":" [FWS] key-s-tag-type 1256 key-s-tag-type = "email" / "*" / x-key-s-tag-type 1257 x-key-s-tag-type = hyphenated-word ; for future extension 1259 t= Flags, represented as a colon-separated list of names (plain- 1260 text; OPTIONAL, default is no flags set). The defined flags are: 1262 y This domain is testing DKIM. Verifiers MUST NOT treat 1263 messages from signers in testing mode differently from 1264 unsigned email, even should the signature fail to verify. 1265 Verifiers MAY wish to track testing mode results to assist 1266 the signer. 1268 s Any DKIM-Signature header fields using the "i=" tag MUST have 1269 the same domain value on the right hand side of the "@" in 1270 the "i=" tag and the value of the "d=" tag. That is, the 1271 "i=" domain MUST NOT be a subdomain of "d=". Use of this 1272 flag is RECOMMENDED unless subdomaining is required. 1274 ABNF: 1276 key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 1277 0*( [FWS] ":" [FWS] key-t-tag-flag ) 1278 key-t-tag-flag = "y" / "s" / x-key-t-tag-flag 1279 x-key-t-tag-flag = hyphenated-word ; for future extension 1281 Unrecognized flags MUST be ignored. 1283 3.6.2 DNS binding 1285 A binding using DNS TXT records as a key service is hereby defined. 1286 All implementations MUST support this binding. 1288 3.6.2.1 Name Space 1290 All DKIM keys are stored in a subdomain named "_domainkey". Given a 1291 DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag 1292 of "foo.bar", the DNS query will be for 1293 "foo.bar._domainkey.example.com". 1295 Wildcard DNS records (e.g., *.bar._domainkey.example.com) MUST NOT be 1296 used. Note also that wildcards within domains (e.g., 1297 s._domainkey.*.example.com) are not supported by the DNS. 1299 3.6.2.2 Resource Record Types for Key Storage 1301 The DNS Resource Record type used is specified by an option to the 1302 query-type ("q=") tag. The only option defined in this base 1303 specification is "txt", indicating the use of a TXT RR record. A 1304 later extension of this standard may define another Resource Record 1305 type. 1307 TXT records are encoded as described in Section 3.6.1. 1309 3.7 Computing the Message Hashes 1311 Both signing and verifying message signatures starts with a step of 1312 computing two cryptographic hashes over the message. Signers will 1313 choose the parameters of the signature as described in Signer Actions 1314 (Section 5); verifiers will use the parameters specified in the 1315 "DKIM-Signature" header field being verified. In the following 1316 discussion, the names of the tags in the "DKIM-Signature" header 1317 field which either exists (when verifying) or will be created (when 1318 signing) are used. Note that canonicalization (Section 3.4) is only 1319 used to prepare the email for signing or verifying; it does not 1320 affect the transmitted email in any way. 1322 The signer or verifier must compute two hashes, one over the body of 1323 the message and one over the selected header fields of the message. 1324 Signers MUST compute them in the order shown. Verifiers MAY compute 1325 them in any order convenient to the verifier, provided that the 1326 result is semantically identical to the semantics that would be the 1327 case had they been computed in this order. 1329 In hash step 1, the signer or verifier MUST hash the message body, 1330 canonicalized using the body canonicalization algorithm specified in 1331 the "c=" tag and truncated to the length specified in the "l=" tag. 1332 That hash value is then converted to base64 form and inserted into 1333 the "bh=" tag of the DKIM-Signature: header field. 1335 In hash step 2, the signer or verifier MUST pass the following to the 1336 hash algorithm in the indicated order. 1338 1. The header fields specified by the "h=" tag, in the order 1339 specified in that tag, and canonicalized using the header 1340 canonicalization algorithm specified in the "c=" tag. Each 1341 header field must be terminated with a single CRLF. 1343 2. The "DKIM-Signature" header field that exists (verifying) or will 1344 be inserted (signing) in the message, with the value of the "b=" 1345 tag deleted (i.e., treated as the empty string), canonicalized 1346 using the header canonicalization algorithm specified in the "c=" 1347 tag, and without a trailing CRLF. 1349 All tags and their values in the DKIM-Signature header field are 1350 included in the cryptographic hash with the sole exception of the 1351 value portion of the "b=" (signature) tag, which MUST be treated as 1352 the null string. All tags MUST be included even if they might not be 1353 understood by the verifier. The header field MUST be presented to 1354 the hash algorithm after the body of the message rather than with the 1355 rest of the header fields and MUST be canonicalized as specified in 1356 the "c=" (canonicalization) tag. The DKIM-Signature header field 1357 MUST NOT be included in its own h= tag. 1359 When calculating the hash on messages that will be transmitted using 1360 base64 or quoted-printable encoding, signers MUST compute the hash 1361 after the encoding. Likewise, the verifier MUST incorporate the 1362 values into the hash before decoding the base64 or quoted-printable 1363 text. However, the hash MUST be computed before transport level 1364 encodings such as SMTP "dot-stuffing." 1366 With the exception of the canonicalization procedure described in 1367 Section 3.4, the DKIM signing process treats the body of messages as 1368 simply a string of octets. DKIM messages MAY be either in plain-text 1369 or in MIME format; no special treatment is afforded to MIME content. 1370 Message attachments in MIME format MUST be included in the content 1371 which is signed. 1373 More formally, the algorithm for the signature is: 1374 body-hash = hash-alg(canon_body) 1375 header-hash = hash-alg(canon_header || DKIM-SIG) 1376 signature = sig-alg(header-hash, key) 1378 where "sig-alg" is the signature algorithm specified by the "a=" tag, 1379 "hash-alg" is the hash algorithm specified by the "a=" tag, 1380 "canon_header" and "canon_body" are the canonicalized message header 1381 and body (respectively) as defined in Section 3.4 (excluding the 1382 DKIM-Signature header field), and "DKIM-SIG" is the canonicalized 1383 DKIM-Signature header field sans the signature value itself, but with 1384 "body-hash" included as the "bh=" tag. 1386 INFORMATIVE NOTE: Many digital signature APIs provide both 1387 hashing and application of the RSA private key using a single 1388 "sign()" primitive. When using such an API the last two steps in 1389 the algorithm would probably be combined into a single call that 1390 would perform both the "hash-alg" and the "sig-alg". 1392 3.8 Signing by Parent Domains 1394 In some circumstances, it is desirable for a domain to apply a 1395 signature on behalf of any of its subdomains without the need to 1396 maintain separate selectors (key records) in each subdomain. By 1397 default, private keys corresponding to key records can be used to 1398 sign messages for any subdomain of the domain in which they reside, 1399 e.g., a key record for the domain example.com can be used to verify 1400 messages where the signing identity (i= tag of the signature) is 1401 sub.example.com, or even sub1.sub2.example.com. In order to limit 1402 the capability of such keys when this is not intended, the "s" flag 1403 may be set in the t= tag of the key record to constrain the validity 1404 of the record to exactly the domain of the signing identity. If the 1405 referenced key record contains the "s" flag as part of the t= tag, 1406 the domain of the signing identity (i= flag) MUST be the same as that 1407 of the d= domain. If this flag is absent, the domain of the signing 1408 identity MUST be the same as, or a subdomain of, the d= domain. Key 1409 records which are not intended for use with subdomains SHOULD specify 1410 the "s" flag in the t= tag. 1412 4. Semantics of Multiple Signatures 1414 A signer that is adding a signature to a message merely creates a new 1415 DKIM-Signature header, using the usual semantics of the h= option. A 1416 signer MAY sign previously existing DKIM-Signature headers using the 1417 method described in section Section 5.4 to sign trace headers. 1418 Signers should be cognizant that signing DKIM-Signature headers may 1419 result in signature failures with intermediaries that do not 1420 recognize that DKIM-Signatures are trace headers and unwittingly 1421 reorder them. 1423 When evaluating a message with multiple signatures, a verifier should 1424 evaluate signatures independently and on their own merits. For 1425 example, a verifier that by policy chooses not to accept signatures 1426 with deprecated cryptographic algorithms should consider such 1427 signatures invalid. As with messages with a single signature, 1428 verifiers are at liberty to use the presence of valid signatures as 1429 an input to local policy; likewise, the interpretation of multiple 1430 valid signatures in combination is a local policy decision of the 1431 verifier. 1433 Signers SHOULD NOT remove any DKIM-Signature header fields from 1434 messages they are signing, even if they know that the signatures 1435 cannot be verified. 1437 5. Signer Actions 1439 The following steps are performed in order by signers. 1441 5.1 Determine if the Email Should be Signed and by Whom 1443 A signer can obviously only sign email for domains for which it has a 1444 private-key and the necessary knowledge of the corresponding public 1445 key and Selector information. However there are a number of other 1446 reasons beyond the lack of a private key why a signer could choose 1447 not to sign an email. 1449 INFORMATIVE NOTE: Signing modules may be incorporated into any 1450 portion of the mail system as deemed appropriate, including an 1451 MUA, a SUBMISSION server, or an MTA. Wherever implemented, 1452 signers should beware of signing (and thereby asserting 1453 responsibility for) messages that may be problematic. In 1454 particular, within a trusted enclave the signing address might be 1455 derived from the header according to local policy; SUBMISSION 1456 servers might only sign messages from users that are properly 1457 authenticated and authorized. 1459 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1460 sign Received header fields if the outgoing gateway MTA obfuscates 1461 Received header fields, for example to hide the details of 1462 internal topology. 1464 If an email cannot be signed for some reason, it is a local policy 1465 decision as to what to do with that email. 1467 5.2 Select a private-key and corresponding selector information 1469 This specification does not define the basis by which a signer should 1470 choose which private-key and Selector information to use. Currently, 1471 all Selectors are equal as far as this specification is concerned, so 1472 the decision should largely be a matter of administrative 1473 convenience. Distribution and management of private-keys is also 1474 outside the scope of this document. 1476 INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a 1477 private key when the Selector containing the corresponding public 1478 key is expected to be revoked or removed before the verifier has 1479 an opportunity to validate the signature. The signer should 1480 anticipate that verifiers may choose to defer validation, perhaps 1481 until the message is actually read by the final recipient. In 1482 particular, when rotating to a new key-pair, signing should 1483 immediately commence with the new private key and the old public 1484 key should be retained for a reasonable validation interval before 1485 being removed from the key server. 1487 5.3 Normalize the Message to Prevent Transport Conversions 1489 Some messages, particularly those using 8-bit characters, are subject 1490 to modification during transit, notably conversion to 7-bit form. 1491 Such conversions will break DKIM signatures. In order to minimize 1492 the chances of such breakage, signers SHOULD convert the message to a 1493 suitable MIME content transfer encoding such as quoted-printable or 1494 base64 as described in MIME Part One [RFC2045] before signing. Such 1495 conversion is outside the scope of DKIM; the actual message SHOULD be 1496 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 1497 DKIM algorithm. 1499 If the message is submitted to the signer with any local encoding 1500 that will be modified before transmission, that modification to 1501 canonical [RFC2822] form MUST be done before signing. In particular, 1502 bare CR or LF characters (used by some systems as a local line 1503 separator convention) MUST be converted to the SMTP-standard CRLF 1504 sequence before the message is signed. Any conversion of this sort 1505 SHOULD be applied to the message actually sent to the recipient(s), 1506 not just to the version presented to the signing algorithm. 1508 More generally, the signer MUST sign the message as it is expected to 1509 be received by the verifier rather than in some local or internal 1510 form. 1512 5.4 Determine the header fields to Sign 1514 The From header field MUST be signed (that is, included in the h= tag 1515 of the resulting DKIM-Signature header field). Signers SHOULD NOT 1516 sign an existing header field likely to be legitimately modified or 1517 removed in transit. In particular, [RFC2821] explicitly permits 1518 modification or removal of the "Return-Path" header field in transit. 1519 Signers MAY include any other header fields present at the time of 1520 signing at the discretion of the signer. 1522 INFORMATIVE OPERATIONS NOTE: The choice of which header fields to 1523 sign is non-obvious. One strategy is to sign all existing, non- 1524 repeatable header fields. An alternative strategy is to sign only 1525 header fields that are likely to be displayed to or otherwise be 1526 likely to affect the processing of the message at the receiver. A 1527 third strategy is to sign only "well known" headers. Note that 1528 verifiers may treat unsigned header fields with extreme 1529 skepticism, including refusing to display them to the end user or 1530 even ignore the signature if it does not cover certain header 1531 fields. For this reason signing fields present in the message 1532 such as Date, Subject, Reply-To, Sender, and all MIME headers is 1533 highly advised. 1535 The DKIM-Signature header field is always implicitly signed and MUST 1536 NOT be included in the h= tag except to indicate that other 1537 preexisting signatures are also signed. 1539 Signers MAY claim to have signed header fields that do not exist 1540 (that is, signers MAY include the header field name in the h= tag 1541 even if that header field does not exist in the message). When 1542 computing the signature, the non-existing header field MUST be 1543 treated as the null string (including the header field name, header 1544 field value, all punctuation, and the trailing CRLF). 1546 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1547 the absence of a header field; if that header field is added later 1548 the signature will fail. 1550 INFORMATIVE NOTE: A header field name need only be listed once 1551 more than the actual number of that header field in a message at 1552 the time of signing in order to prevent any further additions. 1553 For example, if there is a single "Comments" header field at the 1554 time of signing, listing "Comments" twice in the h= tag is 1555 sufficient to prevent any number of Comments header fields from 1556 being appended; it is not necessary (but is legal) to list 1557 "Comments" three or more times in the h= tag. 1559 Signers choosing to sign an existing header field that occurs more 1560 than once in the message (such as Received) MUST sign the physically 1561 last instance of that header field in the header block. Signers 1562 wishing to sign multiple instances of such a header field MUST 1563 include the header field name multiple times in the h= tag of the 1564 DKIM-Signature header field, and MUST sign such header fields in 1565 order from the bottom of the header field block to the top. The 1566 signer MAY include more instances of a header field name in h= than 1567 there are actual corresponding header fields to indicate that 1568 additional header fields of that name SHOULD NOT be added. 1570 INFORMATIVE EXAMPLE: 1572 If the signer wishes to sign two existing Received header fields, 1573 and the existing header contains: 1575 Received: 1576 Received: 1577 Received: 1579 then the resulting DKIM-Signature header field should read: 1581 DKIM-Signature: ... h=Received : Received : ... 1583 and Received header fields and will be signed in that 1584 order. 1586 Signers should be careful of signing header fields that might have 1587 additional instances added later in the delivery process, since such 1588 header fields might be inserted after the signed instance or 1589 otherwise reordered. Trace header fields (such as Received and DKIM- 1590 Signature) and Resent-* blocks are the only fields prohibited by 1591 [RFC2822] from being reordered. 1593 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1594 header fields to be reordered (with the exception of Received 1595 header fields), reordering of signed header fields with multiple 1596 instances by intermediate MTAs will cause DKIM signatures to be 1597 broken; such anti-social behavior should be avoided. 1599 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1600 specification, all end-user visible header fields should be signed 1601 to avoid possible "indirect spamming." For example, if the 1602 "Subject" header field is not signed, a spammer can resend a 1603 previously signed mail, replacing the legitimate subject with a 1604 one-line spam. 1606 5.5 Compute the Message Hash and Signature 1608 The signer MUST compute the message hash as described in Section 3.7 1609 and then sign it using the selected public-key algorithm. This will 1610 result in a DKIM-Signature header field which will include the body 1611 hash and a signature of the header hash, where that header includes 1612 the DKIM-Signature header field itself. 1614 Entities such as mailing list managers that implement DKIM and which 1615 modify the message or a header field (for example, inserting 1616 unsubscribe information) before retransmitting the message SHOULD 1617 check any existing signature on input and MUST make such 1618 modifications before re-signing the message. 1620 The signer MAY elect to limit the number of bytes of the body that 1621 will be included in the hash and hence signed. The length actually 1622 hashed should be inserted in the "l=" tag of the "DKIM-Signature" 1623 header field. 1625 5.6 Insert the DKIM-Signature header field 1627 Finally, the signer MUST insert the "DKIM-Signature:" header field 1628 created in the previous step prior to transmitting the email. The 1629 "DKIM-Signature" header field MUST be the same as used to compute the 1630 hash as described above, except that the value of the "b=" tag MUST 1631 be the appropriately signed hash computed in the previous step, 1632 signed using the algorithm specified in the "a=" tag of the "DKIM- 1633 Signature" header field and using the private key corresponding to 1634 the Selector given in the "s=" tag of the "DKIM-Signature" header 1635 field, as chosen above in Section 5.2 1637 The "DKIM-Signature" MUST be inserted before any other DKIM-Signature 1638 fields in the header block. 1640 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1641 is to insert the "DKIM-Signature" header field at the beginning of 1642 the header block. In particular, it may be placed before any 1643 existing Received header fields. This is consistent with treating 1644 "DKIM-Signature" as a trace header. 1646 6. Verifier Actions 1648 Since a signer MAY remove or revoke a public key at any time, it is 1649 recommended that verification occur in a timely manner with the most 1650 timely place being during acceptance by the border MTA. 1652 A border or intermediate MTA MAY verify the message signature(s). An 1653 MTA who has performed verification MAY communicate the result of that 1654 verification by adding a verification header field to incoming 1655 messages. This considerably simplifies things for the user, who can 1656 now use an existing mail user agent. Most MUAs have the ability to 1657 filter messages based on message header fields or content; these 1658 filters would be used to implement whatever policy the user wishes 1659 with respect to unsigned mail. 1661 A verifying MTA MAY implement a policy with respect to unverifiable 1662 mail, regardless of whether or not it applies the verification header 1663 field to signed messages. 1665 Verifiers MUST produce a result that is semantically equivalent to 1666 applying the following steps in the order listed. In practice, 1667 several of these steps can be performed in parallel in order to 1668 improve performance. 1670 6.1 Extract Signatures from the Message 1672 The order in which verifiers try DKIM-Signature header fields is not 1673 defined; verifiers MAY try signatures in any order they would like. 1674 For example, one implementation might prefer to try the signatures in 1675 textual order, whereas another might want to prefer signatures by 1676 identities that match the contents of the "From" header field over 1677 other identities. Verifiers MUST NOT attribute ultimate meaning to 1678 the order of multiple DKIM-Signature header fields. In particular, 1679 there is reason to believe that some relays will reorder the header 1680 fields in potentially arbitrary ways. 1682 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1683 a clue to signing order in the absence of any other information. 1684 However, other clues as to the semantics of multiple signatures 1685 (such as correlating the signing host with Received headers) may 1686 also be considered. 1688 A verifier SHOULD NOT treat a message that has one or more bad 1689 signatures and no good signatures differently from a message with no 1690 signature at all; such treatment is a matter of local policy and is 1691 beyond the scope of this document. 1693 When a signature successfully verifies, a verifier will either stop 1694 processing or attempt to verify any other signatures, at the 1695 discretion of the implementation. A verifier MAY limit the number of 1696 signatures it tries to avoid denial-of-service attacks. 1698 INFORMATIVE NOTE: An attacker could send messages with large 1699 numbers of faulty signatures, each of which would require a DNS 1700 lookup. This could be an attack on the domain that receives the 1701 message, by slowing down the verifier by requiring it to do large 1702 number of DNS lookups and signature verifications. It could also 1703 be an attack against the domains listed in the signatures, 1704 essentially by enlisting innocent verifiers in launching an attack 1705 against the DNS servers of the actual victim. 1707 In the following description, text reading "return status 1708 (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") 1709 means that the verifier MUST immediately cease processing that 1710 signature. The verifier SHOULD proceed to the next signature, if any 1711 is present, and completely ignore the bad signature. If the status 1712 is "PERMFAIL", the signature failed and should not be reconsidered. 1713 If the status is "TEMPFAIL", the signature could not be verified at 1714 this time but may be tried again later. A verifier MAY either defer 1715 the message for later processing, perhaps by queueing it locally or 1716 issuing a 451/4.7.5 SMTP reply, or try another signature; if no good 1717 signature is found and any of the signatures resulted in a TEMPFAIL 1718 status, the verifier MAY save the message for later processing. The 1719 "(explanation)" is not normative text; it is provided solely for 1720 clarification. 1722 Verifiers SHOULD ignore any DKIM-Signature header fields where the 1723 signature does not validate. Verifiers that are prepared to validate 1724 multiple signature header fields SHOULD proceed to the next signature 1725 header field, should it exist. However, verifiers MAY make note of 1726 the fact that an invalid signature was present for consideration at a 1727 later step. 1729 INFORMATIVE NOTE: The rationale of this requirement is to permit 1730 messages that have invalid signatures but also a valid signature 1731 to work. For example, a mailing list exploder might opt to leave 1732 the original submitter signature in place even though the exploder 1733 knows that it is modifying the message in some way that will break 1734 that signature, and the exploder inserts its own signature. In 1735 this case the message should succeed even in the presence of the 1736 known-broken signature. 1738 For each signature to be validated, the following steps should be 1739 performed in such a manner as to produce a result that is 1740 semantically equivalent to performing them in the indicated order. 1742 6.1.1 Validate the Signature Header Field 1744 Implementers MUST meticulously validate the format and values in the 1745 DKIM-Signature header field; any inconsistency or unexpected values 1746 MUST cause the header field to be completely ignored and the verifier 1747 to return PERMFAIL (signature syntax error). Being "liberal in what 1748 you accept" is definitely a bad strategy in this security context. 1749 Note however that this does not include the existence of unknown tags 1750 in a DKIM-Signature header field, which are explicitly permitted. 1752 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag 1753 that is inconsistent with this specification and return PERMFAIL 1754 (incompatible version). 1756 INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of 1757 course, choose to also verify signatures generated by older 1758 versions of this specification. 1760 If any tag listed as "required" in Section 3.5 is omitted from the 1761 DKIM-Signature header field, the verifier MUST ignore the DKIM- 1762 Signature header field and return PERMFAIL (signature missing 1763 required tag). 1765 INFORMATIONAL NOTE: The tags listed as required in Section 3.5 1766 are "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there 1767 be a conflict between this note and Section 3.5, Section 3.5 is 1768 normative. 1770 If the "DKIM-Signature" header field does not contain the "i=" tag, 1771 the verifier MUST behave as though the value of that tag were "@d", 1772 where "d" is the value from the "d=" tag. 1774 Verifiers MUST confirm that the domain specified in the "d=" tag is 1775 the same as or a parent domain of the domain part of the "i=" tag. 1776 If not, the DKIM-Signature header field MUST be ignored and the 1777 verifier should return PERMFAIL (domain mismatch). 1779 If the "h=" tag does not include the "From" header field the verifier 1780 MUST ignore the DKIM-Signature header field and return PERMFAIL (From 1781 field not signed). 1783 Verifiers MAY ignore the DKIM-Signature header field and return 1784 PERMFAIL (signature expired) if it contains an "x=" tag and the 1785 signature has expired. 1787 Verifiers MAY ignore the DKIM-Signature header field and return 1788 PERMFAIL (unacceptable signature header) for any other reason, for 1789 example, if the signature does not sign header fields that the 1790 verifier views to be essential. As a case in point, if MIME header 1791 fields are not signed, certain attacks may be possible that the 1792 verifier would prefer to avoid. 1794 6.1.2 Get the Public Key 1796 The public key for a signature is needed to complete the verification 1797 process. The process of retrieving the public key depends on the 1798 query type as defined by the "q=" tag in the "DKIM-Signature:" header 1799 field. Obviously, a public key need only be retrieved if the process 1800 of extracting the signature information is completely successful. 1801 Details of key management and representation are described in 1802 Section 3.6. The verifier MUST validate the key record and MUST 1803 ignore any public key records that are malformed. 1805 When validating a message, a verifier MUST perform the following 1806 steps in a manner that is semantically the same as performing them in 1807 the order indicated (in some cases the implementation may parallelize 1808 or reorder these steps, as long as the semantics remain unchanged): 1810 1. Retrieve the public key as described in (Section 3.6) using the 1811 domain from the "d=" tag and the Selector from the "s=" tag. 1813 2. If the query for the public key fails to respond, the verifier 1814 MAY defer acceptance of this email and return TEMPFAIL (key 1815 unavailable). If verification is occurring during the incoming 1816 SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply 1817 code. Alternatively, the verifier MAY store the message in the 1818 local queue for later trial or ignore the signature. Note that 1819 storing a message in the local queue is subject to denial-of- 1820 service attacks. 1822 3. If the query for the public key fails because the corresponding 1823 key record does not exist, the verifier MUST immediately return 1824 PERMFAIL (no key for signature). 1826 4. If the query for the public key returns multiple key records, the 1827 verifier may choose one of the key records or may cycle through 1828 the key records performing the remainder of these steps on each 1829 record at the discretion of the implementer. The order of the 1830 key records is unspecified. If the verifier chooses to cycle 1831 through the key records, then the "return with ..." wording in 1832 the remainder of this section means "try the next key record, if 1833 any; if none, return to try another signature in the usual way." 1835 5. If the result returned from the query does not adhere to the 1836 format defined in this specification, the verifier MUST ignore 1837 the key record and return PERMFAIL (key syntax error). Verifiers 1838 are urged to validate the syntax of key records carefully to 1839 avoid attempted attacks. 1841 6. If the "g=" tag in the public key does not match the Local-part 1842 of the "i=" tag in the message signature header field, the 1843 verifier MUST ignore the key record and return PERMFAIL 1844 (inapplicable key). If the Local-part of the "i=" tag on the 1845 message signature is not present, the g= tag must be * (valid for 1846 all addresses in the domain) or the entire g= tag must be omitted 1847 (which defaults to "g=*"), otherwise the verifier MUST ignore the 1848 key record and return PERMFAIL (inapplicable key). Other than 1849 this test, verifiers SHOULD NOT treat a message signed with a key 1850 record having a g= tag any differently than one without; in 1851 particular, verifiers SHOULD NOT prefer messages that seem to 1852 have an individual signature by virtue of a g= tag versus a 1853 domain signature. 1855 7. If the "h=" tag exists in the public key record and the hash 1856 algorithm implied by the a= tag in the DKIM-Signature header is 1857 not included in the contents of the "h=" tag, the verifier MUST 1858 ignore the key record and return PERMFAIL (inappropriate hash 1859 algorithm). 1861 8. If the public key data (the "p=" tag) is empty then this key has 1862 been revoked and the verifier MUST treat this as a failed 1863 signature check and return PERMFAIL (key revoked). There is no 1864 defined semantic difference between a key that has been revoked 1865 and a key record that has been removed. 1867 9. If the public key data is not suitable for use with the algorithm 1868 and key types defined by the "a=" and "k=" tags in the "DKIM- 1869 Signature" header field, the verifier MUST immediately return 1870 PERMFAIL (inappropriate key algorithm). 1872 6.1.3 Compute the Verification 1874 Given a signer and a public key, verifying a signature consists of 1875 actions semantically equivalent to the following steps. 1877 1. Based on the algorithm defined in the "c=" tag, the body length 1878 specified in the "l=" tag, and the header field names in the "h=" 1879 tag, prepare a canonicalized version of the message as is 1880 described in Section 3.7 (note that this version does not 1881 actually need to be instantiated). When matching header field 1882 names in the "h=" tag against the actual message header field, 1883 comparisons MUST be case-insensitive. 1885 2. Based on the algorithm indicated in the "a=" tag, compute the 1886 message hashes from the canonical copy as described in 1887 Section 3.7. 1889 3. Verify that the hash of the canonicalized message body computed 1890 in the previous step matches the hash value conveyed in the "bh=" 1891 tag. 1893 4. Using the signature conveyed in the "b=" tag, verify the 1894 signature against the header hash using the mechanism appropriate 1895 for the public key algorithm described in the "a=" tag. If the 1896 signature does not validate, the verifier SHOULD ignore the 1897 signature and return PERMFAIL (signature did not verify). 1899 5. Otherwise, the signature has correctly verified. 1901 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1902 initiate the public-key query in parallel with calculating the 1903 hash as the public key is not needed until the final decryption is 1904 calculated. Implementations may also verify the signature on the 1905 message header before validating that the message hash listed in 1906 the "bh=" tag in the DKIM-Signature header field matches that of 1907 the actual message body; however, if the body hash does not match, 1908 the entire signature must be considered to have failed. 1910 A body length specified in the "l=" tag of the signature limits the 1911 number of bytes of the body passed to the verification algorithm. 1912 All data beyond that limit is not validated by DKIM. Hence, 1913 verifiers might treat a message that contains bytes beyond the 1914 indicated body length with suspicion, such as by truncating the 1915 message at the indicated body length, declaring the signature invalid 1916 (e.g., by returning PERMFAIL (unsigned content)), or conveying the 1917 partial verification to the policy module. 1919 INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body 1920 at the indicated body length might pass on a malformed MIME 1921 message if the signer used the "N-4" trick described in the 1922 informative note in Section 5.5. Such verifiers may wish to check 1923 for this case and include a trailing "--CRLF" to avoid breaking 1924 the MIME structure. A simple way to achieve this might be to 1925 append "--CRLF" to any "multipart" message with a body length; if 1926 the MIME structure is already correctly formed, this will appear 1927 in the postlude and will not be displayed to the end user. 1929 6.2 Communicate Verification Results 1931 Verifiers wishing to communicate the results of verification to other 1932 parts of the mail system may do so in whatever manner they see fit. 1933 For example, implementations might choose to add an email header 1934 field to the message before passing it on. Any such header field 1935 SHOULD be inserted before any existing DKIM-Signature or preexisting 1936 authentication status header fields in the header field block. 1938 INFORMATIVE ADVICE to MUA filter writers: Patterns intended to 1939 search for results header fields to visibly mark authenticated 1940 mail for end users should verify that such header field was added 1941 by the appropriate verifying domain and that the verified identity 1942 matches the author identity that will be displayed by the MUA. In 1943 particular, MUA filters should not be influenced by bogus results 1944 header fields added by attackers. Verifiers may wish to delete 1945 existing results header fields after verification and before 1946 adding a new header field to circumvent this attack. 1948 6.3 Interpret Results/Apply Local Policy 1950 It is beyond the scope of this specification to describe what actions 1951 a verifier system should make, but an authenticated email presents an 1952 opportunity to a receiving system that unauthenticated email cannot. 1953 Specifically, an authenticated email creates a predictable identifier 1954 by which other decisions can reliably be managed, such as trust and 1955 reputation. Conversely, unauthenticated email lacks a reliable 1956 identifier that can be used to assign trust and reputation. It is 1957 reasonable to treat unauthenticated email as lacking any trust and 1958 having no positive reputation. 1960 In general verifiers SHOULD NOT reject messages solely on the basis 1961 of a lack of signature or an unverifiable signature. However, if the 1962 verifier does opt to reject such messages, and the verifier runs 1963 synchronously with the SMTP session and a signature is missing or 1964 does not verify, the MTA SHOULD reject the message with an error such 1965 as: 1967 550 5.7.1 Unsigned messages not accepted 1969 550 5.7.5 Message signature incorrect 1971 If it is not possible to fetch the public key, perhaps because the 1972 key server is not available, a temporary failure message MAY be 1973 generated, such as: 1975 451 4.7.5 Unable to verify signature - key server unavailable 1977 A temporary failure of the key server or other external service is 1978 the only condition that should use a 4xx SMTP reply code. In 1979 particular, signature verification failures MUST NOT return 4xx SMTP 1980 replies. 1982 Once the signature has been verified, that information MUST be 1983 conveyed to higher level systems (such as explicit allow/white lists 1984 and reputation systems) and/or to the end user. If the message is 1985 signed on behalf of any address other than that in the From: header 1986 field, the mail system SHOULD take pains to ensure that the actual 1987 signing identity is clear to the reader. 1989 The verifier MAY treat unsigned header fields with extreme 1990 skepticism, including marking them as untrusted or even deleting them 1991 before display to the end user. 1993 While the symptoms of a failed verification are obvious -- the 1994 signature doesn't verify -- establishing the exact cause can be more 1995 difficult. If a Selector cannot be found, is that because the 1996 Selector has been removed or was the value changed somehow in 1997 transit? If the signature line is missing is that because it was 1998 never there, or was it removed by an over-zealous filter? For 1999 diagnostic purposes, the exact reason why the verification fails 2000 SHOULD be made available to the policy module and possibly recorded 2001 in the system logs. However in terms of presentation to the end 2002 user, the result SHOULD be presented as a simple binary result: 2003 either the email is verified or it is not. If the email cannot be 2004 verified, then it SHOULD be rendered the same as all unverified email 2005 regardless of whether it looks like it was signed or not. 2007 7. IANA Considerations 2009 DKIM introduces some new namespaces that require IANA registry. 2011 7.1 DKIM-Signature Tag Specifications 2013 A DKIM-Signature provides for a list of tag specifications. IANA is 2014 requested to establish the DKIM Signature Tag Specification Registry, 2015 for tag specifications that can be used in DKIM-Signature fields and 2016 that have been specified in any published RFC. 2018 The initial entries in the registry comprise: 2020 +------+-----------------+ 2021 | TYPE | RFC | 2022 +------+-----------------+ 2023 | v | (this document) | 2024 | a | (this document) | 2025 | b | (this document) | 2026 | bh | (this document) | 2027 | c | (this document) | 2028 | d | (this document) | 2029 | h | (this document) | 2030 | i | (this document) | 2031 | l | (this document) | 2032 | q | (this document) | 2033 | s | (this document) | 2034 | t | (this document) | 2035 | x | (this document) | 2036 | z | (this document) | 2037 +------+-----------------+ 2039 7.2 DKIM-Signature Query Method Registry 2041 The "q=" tag-spec, as specified in Section 3.5 provides for a list of 2042 query methods. 2044 IANA is requested to establish the DKIM Query Method Registry, for 2045 mechanisms that can be used to retrieve the key that will permit 2046 validation processing of a message signed using DKIM and have been 2047 specified in any published RFC. 2049 The initial entry in the registry comprises: 2051 +------+--------+-----------------+ 2052 | TYPE | OPTION | RFC | 2053 +------+--------+-----------------+ 2054 | dns | txt | (this document) | 2055 +------+--------+-----------------+ 2057 7.3 DKIM-Signature Canonicalization Registry 2059 The "c=" tag-spec, as specified in Section 3.5 provides for a 2060 specifier for canonicalization algorithms for the header and body of 2061 the message. 2063 IANA is requested to establish the DKIM Canonicalization Algorithm 2064 Registry, for algorithms for converting a message into a canonical 2065 form before signing or verifying using DKIM and have been specified 2066 in any published RFC. 2068 The initial entries in the header registry comprise: 2070 +---------+-----------------+ 2071 | TYPE | RFC | 2072 +---------+-----------------+ 2073 | simple | (this document) | 2074 | relaxed | (this document) | 2075 +---------+-----------------+ 2077 The initial entries in the body registry comprise: 2079 +---------+-----------------+ 2080 | TYPE | RFC | 2081 +---------+-----------------+ 2082 | simple | (this document) | 2083 | relaxed | (this document) | 2084 +---------+-----------------+ 2086 7.4 _domainkey DNS TXT Record Tag Specifications 2088 A _domainkey DNS TXT record provides for a list of tag 2089 specifications. IANA is requested to establish the DKIM _domainkey 2090 DNS TXT Tag Specification Registry, for tag specifications that can 2091 be used in DNS TXT Records and that have been specified in any 2092 published RFC. 2094 The initial entries in the registry comprise: 2096 +------+-----------------+ 2097 | TYPE | RFC | 2098 +------+-----------------+ 2099 | v | (this document) | 2100 | g | (this document) | 2101 | h | (this document) | 2102 | k | (this document) | 2103 | n | (this document) | 2104 | p | (this document) | 2105 | s | (this document) | 2106 | t | (this document) | 2107 +------+-----------------+ 2109 7.5 DKIM Key Type Registry 2111 The "k=" (as specified in Section 3.6.1) and the "a=" 2112 (Section 3.5) tags provide for a list of mechanisms 2113 that can be used to decode a DKIM signature. 2115 IANA is requested to establish the DKIM Key Type Registry, for such 2116 mechanisms that have been specified in any published RFC. 2118 The initial entry in the registry comprises: 2120 +------+---------+ 2121 | TYPE | RFC | 2122 +------+---------+ 2123 | rsa | RFC3447 | 2124 +------+---------+ 2126 7.6 DKIM Hash Algorithms Registry 2128 The "h=" list (specified in Section 3.6.1) and the "a=" 2129 (Section 3.5) provide for a list of mechanisms that can 2130 be used to produce a digest of message data. 2132 IANA is requested to establish the DKIM Hash Algorithms Registry, for 2133 such mechanisms that have been specified in any published RFC. 2135 The initial entries in the registry comprise: 2137 +--------+-----+ 2138 | TYPE | RFC | 2139 +--------+-----+ 2140 | sha1 | ? | 2141 | sha256 | ? | 2142 +--------+-----+ 2144 7.7 DKIM Service Types Registry 2146 The "s=" list (specified in Section 3.6.1) provides for a 2147 list of service types to which this selector may apply. 2149 IANA is requested to establish the DKIM Service Types Registry, for 2150 service types that have been specified in any published RFC. 2152 The initial entries in the registry comprise: 2154 +-------+-----------------+ 2155 | TYPE | RFC | 2156 +-------+-----------------+ 2157 | email | (this document) | 2158 | * | (this document) | 2159 +-------+-----------------+ 2161 7.8 DKIM Selector Flags Registry 2163 The "t=" list (specified in Section 3.6.1) provides for a 2164 list of flags to modify interpretation of the selector. 2166 IANA is requested to establish the DKIM Selector Flags Registry, for 2167 additional flags that have been specified in any published RFC. 2169 The initial entries in the registry comprise: 2171 +------+-----------------+ 2172 | TYPE | RFC | 2173 +------+-----------------+ 2174 | y | (this document) | 2175 | s | (this document) | 2176 +------+-----------------+ 2178 8. Security Considerations 2180 It has been observed that any mechanism that is introduced which 2181 attempts to stem the flow of spam is subject to intensive attack. 2182 DKIM needs to be carefully scrutinized to identify potential attack 2183 vectors and the vulnerability to each. See also [ID-DKIM-THREATS]. 2185 8.1 Misuse of Body Length Limits ("l=" Tag) 2187 Body length limits (in the form of the "l=" tag) are subject to 2188 several potential attacks. 2190 8.1.1 Addition of new MIME parts to multipart/* 2192 If the body length limit does not cover a closing MIME multipart 2193 section (including the trailing ""--CRLF"" portion), then it is 2194 possible for an attacker to intercept a properly signed multipart 2195 message and add a new body part. Depending on the details of the 2196 MIME type and the implementation of the verifying MTA and the 2197 receiving MUA, this could allow an attacker to change the information 2198 displayed to an end user from an apparently trusted source. 2200 For example, if an attacker can append information to a "text/html" 2201 body part, they may be able to exploit a bug in some MUAs that 2202 continue to read after a "" marker, and thus display HTML text 2203 on top of already displayed text. If a message has a "multipart/ 2204 alternative" body part, they might be able to add a new body part 2205 that is preferred by the displaying MTA. 2207 8.1.2 Addition of new HTML content to existing content 2209 Several receiving MUA implementations do not cease display after a 2210 """" tag. In particular, this allows attacks involving 2211 overlaying images on top of existing text. 2213 INFORMATIVE EXAMPLE: Appending the following text to an existing, 2214 properly closed message will in many MUAs result in inappropriate 2215 data being rendered on top of existing, correct data: 2216
2217 2219
2221 8.2 Misappropriated Private Key 2223 If the private key for a user is resident on their computer and is 2224 not protected by an appropriately secure mechanism, it is possible 2225 for malware to send mail as that user and any other user sharing the 2226 same private key. The malware would, however, not be able to 2227 generate signed spoofs of other signers' addresses, which would aid 2228 in identification of the infected user and would limit the 2229 possibilities for certain types of attacks involving socially- 2230 engineered messages. This threat applies mainly to MUA-based 2231 implementations; protection of private keys on servers can be easily 2232 achieved through the use of specialized cryptographic hardware. 2234 A larger problem occurs if malware on many users' computers obtains 2235 the private keys for those users and transmits them via a covert 2236 channel to a site where they can be shared. The compromised users 2237 would likely not know of the misappropriation until they receive 2238 "bounce" messages from messages they are purported to have sent. 2239 Many users might not understand the significance of these bounce 2240 messages and would not take action. 2242 One countermeasure is to use a user-entered passphrase to encrypt the 2243 private key, although users tend to choose weak passphrases and often 2244 reuse them for different purposes, possibly allowing an attack 2245 against DKIM to be extended into other domains. Nevertheless, the 2246 decoded private key might be briefly available to compromise by 2247 malware when it is entered, or might be discovered via keystroke 2248 logging. The added complexity of entering a passphrase each time one 2249 sends a message would also tend to discourage the use of a secure 2250 passphrase. 2252 A somewhat more effective countermeasure is to send messages through 2253 an outgoing MTA that can authenticate the submitter using existing 2254 techniques (e.g., SMTP Authentication), possibly validate the message 2255 itself (e.g., verify that the header is legitimate and that the 2256 content passes a spam content check), and sign the message using a 2257 key appropriate for the submitter address. Such an MTA can also 2258 apply controls on the volume of outgoing mail each user is permitted 2259 to originate in order to further limit the ability of malware to 2260 generate bulk email. 2262 8.3 Key Server Denial-of-Service Attacks 2264 Since the key servers are distributed (potentially separate for each 2265 domain), the number of servers that would need to be attacked to 2266 defeat this mechanism on an Internet-wide basis is very large. 2267 Nevertheless, key servers for individual domains could be attacked, 2268 impeding the verification of messages from that domain. This is not 2269 significantly different from the ability of an attacker to deny 2270 service to the mail exchangers for a given domain, although it 2271 affects outgoing, not incoming, mail. 2273 A variation on this attack is that if a very large amount of mail 2274 were to be sent using spoofed addresses from a given domain, the key 2275 servers for that domain could be overwhelmed with requests. However, 2276 given the low overhead of verification compared with handling of the 2277 email message itself, such an attack would be difficult to mount. 2279 8.4 Attacks Against DNS 2281 Since DNS is a required binding for key services, specific attacks 2282 against DNS must be considered. 2284 While the DNS is currently insecure [RFC3833], it is expected that 2285 the security problems should and will be solved by DNSSEC [RFC4033], 2286 and all users of the DNS will reap the benefit of that work. 2288 Secondly, the types of DNS attacks relevant to DKIM are very costly 2289 and are far less rewarding than DNS attacks on other Internet 2290 applications. 2292 To systematically thwart the intent of DKIM, an attacker must conduct 2293 a very costly and very extensive attack on many parts of the DNS over 2294 an extended period. No one knows for sure how attackers will 2295 respond, however the cost/benefit of conducting prolonged DNS attacks 2296 of this nature is expected to be uneconomical. 2298 Finally, DKIM is only intended as a "sufficient" method of proving 2299 authenticity. It is not intended to provide strong cryptographic 2300 proof about authorship or contents. Other technologies such as 2301 OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. 2303 A second security issue related to the DNS revolves around the 2304 increased DNS traffic as a consequence of fetching Selector-based 2305 data as well as fetching signing domain policy. Widespread 2306 deployment of DKIM will result in a significant increase in DNS 2307 queries to the claimed signing domain. In the case of forgeries on a 2308 large scale, DNS servers could see a substantial increase in queries. 2310 8.5 Replay Attacks 2312 In this attack, a spammer sends a message to be spammed to an 2313 accomplice, which results in the message being signed by the 2314 originating MTA. The accomplice resends the message, including the 2315 original signature, to a large number of recipients, possibly by 2316 sending the message to many compromised machines that act as MTAs. 2317 The messages, not having been modified by the accomplice, have valid 2318 signatures. 2320 Partial solutions to this problem involve the use of reputation 2321 services to convey the fact that the specific email address is being 2322 used for spam, and that messages from that signer are likely to be 2323 spam. This requires a real-time detection mechanism in order to 2324 react quickly enough. However, such measures might be prone to 2325 abuse, if for example an attacker resent a large number of messages 2326 received from a victim in order to make them appear to be a spammer. 2328 Large verifiers might be able to detect unusually large volumes of 2329 mails with the same signature in a short time period. Smaller 2330 verifiers can get substantially the same volume information via 2331 existing collaborative systems. 2333 8.6 Limits on Revoking Keys 2335 When a large domain detects undesirable behavior on the part of one 2336 of its users, it might wish to revoke the key used to sign that 2337 user's messages in order to disavow responsibility for messages which 2338 have not yet been verified or which are the subject of a replay 2339 attack. However, the ability of the domain to do so can be limited 2340 if the same key, for scalability reasons, is used to sign messages 2341 for many other users. Mechanisms for explicitly revoking keys on a 2342 per-address basis have been proposed but require further study as to 2343 their utility and the DNS load they represent. 2345 8.7 Intentionally malformed Key Records 2347 It is possible for an attacker to publish key records in DNS which 2348 are intentionally malformed, with the intent of causing a denial-of- 2349 service attack on a non-robust verifier implementation. The attacker 2350 could then cause a verifier to read the malformed key record by 2351 sending a message to one of its users referencing the malformed 2352 record in a (not necessarily valid) signature. Verifiers MUST 2353 thoroughly verify all key records retrieved from DNS and be robust 2354 against intentionally as well as unintentionally malformed key 2355 records. 2357 8.8 Intentionally Malformed DKIM-Signature header fields 2359 Verifiers MUST be prepared to receive messages with malformed DKIM- 2360 Signature header fields, and thoroughly verify the header field 2361 before depending on any of its contents. 2363 8.9 Information Leakage 2365 An attacker could determine when a particular signature was verified 2366 by using a per-message Selector and then monitoring their DNS traffic 2367 for the key lookup. This would act as the equivalent of a "web bug" 2368 for verification time rather than when the message was read. 2370 8.10 Remote Timing Attacks 2372 In some cases it may be possible to extract private keys using a 2373 remote timing attack [BONEH03]. Implementations should consider 2374 obfuscating the timing to prevent such attacks. 2376 9. References 2378 9.1 Normative References 2380 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2381 Extensions (MIME) Part One: Format of Internet Message 2382 Bodies", RFC 2045, November 1996. 2384 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2385 Part Three: Message header field Extensions for Non-ASCII 2386 Text", RFC 2047, November 1996. 2388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2389 Requirement Levels", BCP 14, RFC 2119, March 1997. 2391 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2392 April 2001. 2394 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2395 April 2001. 2397 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2398 Standards (PKCS) #1: RSA Cryptography Specifications 2399 Version 2.1", RFC 3447, February 2003. 2401 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2402 "Internationalizing Domain Names in Applications (IDNA)", 2403 March 2003. 2405 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2406 Specifications: ABNF", RFC 4234, October 2005. 2408 [X.660] "ITU-T Recommendation X.660 Information Technology - ASN.1 2409 encoding rules: Specification of Basic Encoding Rules 2410 (BER), Canonical Encoding Rules (CER) and Distinguished 2411 Encoding Rules (DER)", 1997. 2413 9.2 Informative References 2415 [BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing 2416 Attacks are Practical", 2003, . 2419 [ID-DKIM-THREATS] 2420 Fenton, J., "Analysis of Threats Motivating DomainKeys 2421 Identified Mail (DKIM)", draft-fenton-dkim-threats-02 2422 (work in progress), April 2006. 2424 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 2425 "Security Multiparts for MIME: Multipart/Signed and 2426 Multipart/Encrypted", RFC 1847, October 1995. 2428 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 2429 "OpenPGP Message Format", RFC 2440, November 1998. 2431 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for 2432 Public Keys Used For Exchanging Symmetric Keys", RFC 3766, 2433 April 2004. 2435 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2436 Name System (DNS)", RFC 3833, August 2004. 2438 [RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", 2439 RFC 3851, June 1999. 2441 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2442 Rose, "DNS Security Introduction and Requirements", 2443 RFC 4033, March 2005. 2445 Authors' Addresses 2447 Eric Allman 2448 Sendmail, Inc. 2449 6425 Christie Ave, Suite 400 2450 Emeryville, CA 94608 2451 USA 2453 Phone: +1 510 594 5501 2454 Email: eric+dkim@sendmail.org 2455 URI: 2457 Jon Callas 2458 PGP Corporation 2459 3460 West Bayshore 2460 Palo Alto, CA 94303 2461 USA 2463 Phone: +1 650 319 9016 2464 Email: jon@pgp.com 2466 Mark Delany 2467 Yahoo! Inc 2468 701 First Avenue 2469 Sunnyvale, CA 95087 2470 USA 2472 Phone: +1 408 349 6831 2473 Email: markd+dkim@yahoo-inc.com 2474 URI: 2476 Miles Libbey 2477 Yahoo! Inc 2478 701 First Avenue 2479 Sunnyvale, CA 95087 2480 USA 2482 Email: mlibbeymail-mailsig@yahoo.com 2483 URI: 2485 Jim Fenton 2486 Cisco Systems, Inc. 2487 MS SJ-24/2 2488 170 W. Tasman Drive 2489 San Jose, CA 95134-1706 2490 USA 2492 Phone: +1 408 526 5914 2493 Email: fenton@cisco.com 2494 URI: 2496 Michael Thomas 2497 Cisco Systems, Inc. 2498 MS SJ-9/2 2499 170 W. Tasman Drive 2500 San Jose, CA 95134-1706 2502 Phone: +1 408 525 5386 2503 Email: mat@cisco.com 2505 Appendix A. Example of Use (INFORMATIVE) 2507 This section shows the complete flow of an email from submission to 2508 final delivery, demonstrating how the various components fit 2509 together. 2511 A.1 The user composes an email 2513 From: Joe SixPack 2514 To: Suzie Q 2515 Subject: Is dinner ready? 2516 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2517 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2519 Hi. 2521 We lost the game. Are you hungry yet? 2523 Joe. 2525 A.2 The email is signed 2527 This email is signed by the example.com outbound email server and now 2528 looks like this: 2530 DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; 2531 c=simple; q=dns/txt; i=joe@football.example.com; 2532 h=Received : From : To : Subject : Date : Message-ID; 2533 bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; 2534 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2535 VoG4ZHRNiYzR; 2536 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2537 by submitserver.example.com with SUBMISSION; 2538 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2539 From: Joe SixPack 2540 To: Suzie Q 2541 Subject: Is dinner ready? 2542 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2543 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2545 Hi. 2547 We lost the game. Are you hungry yet? 2549 Joe. 2551 The signing email server requires access to the private-key 2552 associated with the "brisbane" Selector to generate this signature. 2554 A.3 The email signature is verified 2556 The signature is normally verified by an inbound SMTP server or 2557 possibly the final delivery agent. However, intervening MTAs can 2558 also perform this verification if they choose to do so. The 2559 verification process uses the domain "example.com" extracted from the 2560 "d=" tag and the Selector "brisbane" from the "s=" tag in the "DKIM- 2561 Signature" header field to form the DNS DKIM query for: 2563 brisbane._domainkey.example.com 2565 Signature verification starts with the physically last "Received" 2566 header field, the "From" header field, and so forth, in the order 2567 listed in the "h=" tag. Verification follows with a single CRLF 2568 followed by the body (starting with "Hi."). The email is canonically 2569 prepared for verifying with the "simple" method. The result of the 2570 query and subsequent verification of the signature is stored in the 2571 "Authentication-Results" header field line. After successful 2572 verification, the email looks like this: 2574 X-Authentication-Results: shopping.example.net 2575 header.from=joe@football.example.com; dkim=pass 2576 Received: from mout23.football.example.com (192.168.1.1) 2577 by shopping.example.net with SMTP; 2578 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2579 DKIM-Signature: a=rsa-sha256; s=brisbane; d=example.com; 2580 c=simple; q=dns/txt; i=joe@football.example.com; 2581 h=Received : From : To : Subject : Date : Message-ID; 2582 bh=ZSVEYuq4ri3LR9S+qjlzCP+LxvJrIfrOI2g5hxp5+MI=; 2583 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2584 VoG4ZHRNiYzR 2585 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2586 by submitserver.example.com with SUBMISSION; 2587 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2588 From: Joe SixPack 2589 To: Suzie Q 2590 Subject: Is dinner ready? 2591 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2592 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2594 Hi. 2596 We lost the game. Are you hungry yet? 2598 Joe. 2600 Appendix B. Usage Examples (INFORMATIVE) 2602 Studies in this appendix are for informational purposes only. In no 2603 case should these examples be used as guidance when creating an 2604 implementation. 2606 B.1 Simple Message Forwarding 2608 In some cases the recipient may request forwarding of email messages 2609 from the original address to another, through the use of a Unix 2610 .forward file or equivalent. In this case messages are typically 2611 forwarded without modification, except for the addition of a Received 2612 header field to the message and a change in the Envelope-to address. 2613 In this case, the eventual recipient should be able to verify the 2614 original signature since the signed content has not changed, and 2615 attribute the message correctly. 2617 B.2 Outsourced Business Functions 2619 Outsourced business functions represent a use case that motivates the 2620 need for Selectors (the "s=" signature tag) and granularity (the "g=" 2621 key tag). Examples of outsourced business functions are legitimate 2622 email marketing providers and corporate benefits providers. In 2623 either case, the outsourced function would like to be able to send 2624 messages using the email domain of the client company. At the same 2625 time, the client may be reluctant to register a key for the provider 2626 that grants the ability to send messages for any address in the 2627 domain. 2629 The outsourcing company can generate a keypair and the client company 2630 can register the public key using a unique Selector for a specific 2631 address such as winter-promotions@example.com by specifying a 2632 granularity of "g=winter-promotions" or "g=*-promotions" (to allow a 2633 range of addresses). This would enable the provider to send messages 2634 using that specific address and have them verify properly. The 2635 client company retains control over the email address because it 2636 retains the ability to revoke the key at any time. 2638 B.3 PDAs and Similar Devices 2640 PDAs are one example of the use of multiple keys per user. Suppose 2641 that John Doe wanted to be able to send messages using his corporate 2642 email address, jdoe@example.com, and the device did not have the 2643 ability to make a VPN connection to the corporate network. If the 2644 device was equipped with a private key registered for 2645 jdoe@example.com by the administrator of that domain, and appropriate 2646 software to sign messages, John could send signed messages through 2647 the outgoing network of the PDA service provider. 2649 B.4 Mailing Lists 2651 There is a wide range of behavior in forwarders and mailing lists 2652 (collectively called "forwarders" below), ranging from those which 2653 make no modification to the message itself (other than to add a 2654 Received header field and change the envelope information) to those 2655 which may add header fields, change the Subject header field, add 2656 content to the body (typically at the end), or reformat the body in 2657 some manner. 2659 Forwarders which do not modify the body or signed header fields of a 2660 message with a valid signature may re-sign the message as described 2661 below. 2663 Forwarders which make any modification to a message that could result 2664 in its signature becoming invalid should sign or re-sign using an 2665 appropriate identification (e.g., mailing-list-name@example.net). 2666 Since in so doing the (re-)signer is taking responsibility for the 2667 content of the message, modifying forwarders may elect to forward or 2668 re-sign only for messages which were received with valid signatures 2669 or other indications that the messages being signed are not spoofed. 2671 Forwarders which wish to re-sign a message must apply a Sender header 2672 field to the message to identify the address being used to sign the 2673 message and must remove any preexisting Sender header field as 2674 required by [RFC2822]. The forwarder applies a new DKIM-Signature 2675 header field with the signature, public key, and related information 2676 of the forwarder. 2678 B.5 Affinity Addresses 2680 "Affinity addresses" are email addresses that users employ to have an 2681 email address that is independent of any changes in email service 2682 provider they may choose to make. They are typically associated with 2683 college alumni associations, professional organizations, and 2684 recreational organizations with which they expect to have a long-term 2685 relationship. These domains usually provide forwarding of incoming 2686 email, but (currently) usually depend on the user to send outgoing 2687 messages through their own service provider's MTA. They usually have 2688 an associated Web application which authenticates the user and allows 2689 the forwarding address to be changed. 2691 With DKIM, affinity domains could use the Web application to allow 2692 users to register their own public keys to be used to sign messages 2693 on behalf of their affinity address. This is another application 2694 that takes advantage of user-level keying, and domains used for 2695 affinity addresses would typically have a very large number of user- 2696 level keys. Alternatively, the affinity domain could handle outgoing 2697 mail, operating a mail submission agent that authenticates users 2698 before accepting and signing messages for them. This is of course 2699 dependent on the user's service provider not blocking the relevant 2700 TCP ports used for mail submission. 2702 B.6 Third-party Message Transmission 2704 Third-party message transmission refers to the authorized sending of 2705 mail by an Internet application on behalf of a user. For example, a 2706 website providing news may allow the reader to forward a copy of the 2707 message to a friend; this is typically done using the reader's email 2708 address. This is sometimes referred to as the "Evite problem", named 2709 after the website of the same name that allows a user to send 2710 invitations to friends. 2712 One way this can be handled is to continue to put the reader's email 2713 address in the From header field of the message, but put an address 2714 owned by the site into the Sender header field, and sign the message 2715 on behalf of that address. A verifying MTA could accept this and 2716 rewrite the From header field to indicate the address that was 2717 verified, i.e., From: John Doe via news@news-site.com 2718 . (However, such rewriting must be done after the 2719 verification pass is complete, and will break any later attempts to 2720 re-verify.) 2722 B.7 SMTP Servers for Roaming Users 2724 Roaming users may find themselves in circumstances where it is 2725 convenient or necessary to use an SMTP server other than their home 2726 server; examples are IETF conferences and many hotels. In such 2727 circumstances the signature, if any, will be added by a party other 2728 than the user's home system. 2730 Ideally roaming users would connect back to their home server using 2731 either a VPN or a SUBMISSION server running with SMTP AUTHentication 2732 on port 587. If the signing can be performed on the roaming user's 2733 laptop then they can sign before submission, although the risk of 2734 further modification may be high. If neither of these are possible, 2735 these roaming users will not be able to send mail signed using their 2736 own domain key. 2738 Appendix C. Creating a public key (INFORMATIVE) 2740 The default signature is an RSA signed SHA256 digest of the complete 2741 email. For ease of explanation, the openssl command is used to 2742 describe the mechanism by which keys and signatures are managed. One 2743 way to generate a 1024 bit, unencrypted private-key suitable for 2744 DKIM, is to use openssl like this: 2746 $ openssl genrsa -out rsa.private 1024 2748 For increased security, the "-passin" parameter can also be added to 2749 encrypt the private key. Use of this parameter will require entering 2750 a password for several of the following steps. Servers may prefer to 2751 use hardware cryptographic support. 2753 The "genrsa" step results in the file rsa.private containing the key 2754 information similar to this: 2756 -----BEGIN RSA PRIVATE KEY----- 2757 MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC 2758 jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb 2759 to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB 2760 AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX 2761 /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ 2762 gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO 2763 n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 2764 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ 2765 eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 2766 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 2767 qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf 2768 eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX 2769 GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= 2770 -----END RSA PRIVATE KEY----- 2772 To extract the public-key component from the private-key, use openssl 2773 like this: 2775 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 2777 This results in the file rsa.public containing the key information 2778 similar to this: 2780 -----BEGIN PUBLIC KEY----- 2781 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM 2782 oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R 2783 tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI 2784 MmPSPDdQPNUYckcQ2QIDAQAB 2785 -----END PUBLIC KEY----- 2787 This public-key data (without the BEGIN and END tags) is placed in 2788 the DNS. With the signature, canonical email contents, and public 2789 key, a verifying system can test the validity of the signature. The 2790 openssl invocation to verify a signature looks like this: 2792 openssl dgst -verify rsa.public -sha256 -signature signature.file \ 2793 . 2858 Appendix F. Edit History 2860 [[This section to be removed before publication.]] 2862 F.1 Changes since -ietf-04 version 2864 The following changes were made between draft-ietf-dkim-base-04 and 2865 draft-ietf-dkim-base-05: 2867 o Clarified definition of "plain text" in section 3.2 (issue 1316). 2869 o Added some clarification about multiple listings of non-existent 2870 header field names in h= in section 5.4 (issue 1316). 2872 o Finished filling out IANA registries in section 7 (issue 1320). 2874 o Clarified handling of bare CR and LF in section 5.3 (issue 1326). 2876 o Listed the required tags in section 6.1.1 as an informational note 2877 (issue 1330). 2879 o Changed IDNA reference from 3492 to 3490 (issue 1331). 2881 o Changed the reference for WSP to 4234; changed the definition of 2882 SWSP to exclude bare CR and LF (issue 1332). 2884 F.2 Changes since -ietf-03 version 2886 The following changes were made between draft-ietf-dkim-base-03 and 2887 draft-ietf-dkim-base-04: 2889 o Re-worded Abstract to avoid use of "prove" and "non-repudiation". 2891 o Use dot-atom-text instead of dot-atom to avoid inclusion of CFWS. 2893 o Capitalize Selector throughout. 2895 o Add discussion of plain text, mentioning informatively that 2896 implementors should plan for eventual 8-bit requirements. 2898 o Drop RSA requirement of exponent of 65537 (not required, since it 2899 is already in the key) and clarify the key format. 2901 o Drop SHOULD that DKIM-Signature should precede header fields that 2902 it signs. 2904 o Mention that wildcard DNS records MUST NOT be used for selector 2905 records. 2907 o Add section 3.8 to clarify the t=s flag. 2909 o Change the list of header fields that MUST be signed to include 2910 only From. 2912 o Require that verifier check that From is in the list of signed 2913 header fields. 2915 o Drop all reference to draft-kucherawy-sender-auth-header draft. 2917 o Substantially expand Section 7 (IANA Considerations) to include 2918 initial registries. 2920 o Add section B.7 (use case: SMTP Servers for Roaming Users). 2922 o Add several examples; update some others. 2924 o Considerable minor editorial updating to clarify language, delete 2925 redundant text, fix spelling errors, etc. 2927 Still to be resolved: 2929 o How does "simple" body canonicalization interact with BINARYMIME 2930 data? 2932 o Deal with "relaxed" body canonicalizations, especially in regard 2933 to bare CRs and NLs. 2935 o How to handle "*" in g= dot-atom-text (which allows "*" as a 2936 literal character). 2938 o The IANA Considerations need to be completed and cleaned up. 2940 F.3 Changes since -ietf-02 version 2942 The following changes were made between draft-ietf-dkim-base-02 and 2943 draft-ietf-dkim-base-03: 2945 o Section 5.2: changed key expiration text to be informational; 2946 drop "seven day" wording in favor of something vaguer. 2948 o Don't indicate that the "i=" tag value should be passed to the key 2949 lookup service; this can be added as an extension if required. 2951 o Move Section 6.6 (MUA Considerations) to be Appendix D and modify 2952 it to avoid any hint of normative language. 2954 o Soften the DKIM_STAT_ language in section 6 so that it doesn't 2955 appear normative. This involved using only PERMFAIL and TEMPFAIL 2956 as status, with parenthetical explanations. 2958 o Restructured section 6 to make it clearer which steps apply on a 2959 per-signature basis versus a per-message basis. 2961 o Clarification of "signing identity" in several places. 2963 o Clarification that DKIM-Signature header fields being signed by 2964 another DKIM-Signature header field should be treated as a normal 2965 header field (i.e., their "b=" field is unchanged). 2967 o Change ABNF on a= tag to separate the public key algorithm from 2968 the hash algorithm. 2970 o Add t=s flag in key record to disallow subdomains in the i= tag 2971 relative to the d= tag of the DKIM-Signature header field. 2973 o Add a new definition for "dkim-quoted-printable", which is a 2974 simple case of quoted-printable from RFC2045. dkim-quoted- 2975 printable requires that all white space in the original text be 2976 escaped, and all unescaped white space in the encoded field should 2977 be ignored to allow arbitrary wrapping of the header fields which 2978 may contain the content. 2980 o Use dkim-quoted-printable as the encoding used in z= rather than 2981 referring to RFC2045, since they are different. 2983 o Rewrite description of g= tag in the key record. 2985 o Deleted use of Domain in ABNF, which permits address-literals; 2986 define domain-name to act in stead. 2988 F.4 Changes since -ietf-01 version 2990 The following changes were made between draft-ietf-dkim-base-01 and 2991 draft-ietf-dkim-base-02: 2993 o Change wording on "x=" tag in DKIM-Signature header field 2994 regarding verifier handling of expired signatures from MUST to MAY 2995 (per 20 April Jabber session). Also, make it clear that received 2996 time is to be preferred over current time if reliably available. 2998 o Several changes to limit wording that would intrude into verifier 2999 policy. This is largely changing statements such as "... MUST 3000 reject the message" to "... MUST consider the signature invalid." 3002 o Drop normative references to ID-DKIM-RR, OpenSSL, PEM, and 3003 Stringprep. 3005 o Change "v=" tag in DKIM-Signature from "MUST NOT" to "MUST"; the 3006 version number is 0.2 for this draft, with the expectation that 3007 the first official version will be "v=1". (Per 18 May Jabber 3008 session.) 3010 o Change "q=dns" query access method to "q=dnstxt" to emphasize the 3011 use of the TXT record. The expectation is that a later extension 3012 will define "q=dnsdkk" to indicate use of a DKK record. (Per 18 3013 May Jabber session.) 3015 o Several typos fixed, including removing a paragraph that implied 3016 that the DKIM-Signature header field should be hashed with the 3017 body (it should not). 3019 F.5 Changes since -ietf-00 version 3021 The following changes were made between draft-ietf-dkim-base-00 and 3022 draft-ietf-dkim-base-01: 3024 o Added section 8.9 (Information Leakage). 3026 o Replace section 4 (Multiple Signatures) with much less vague text. 3028 o Fixed ABNF for base64string. 3030 o Added rsa-sha256 signing algorithm. 3032 o Expanded several examples. 3034 o Changed signing algorithm to use separate hash of the body of the 3035 message; this is represented as the "bh=" tag in the DKIM- 3036 Signature header field. 3038 o Changed "z=" tag so that it need not have the same header field 3039 names as the "h=" tag. 3041 o Significant wordsmithing. 3043 F.6 Changes since -allman-01 version 3045 The following changes were made between draft-allman-dkim-base-01 and 3046 draft-ietf-dkim-base-00: 3048 o Remove references to Sender Signing Policy document. Such 3049 consideration is implicitly included in Section 6.3. 3051 o Added ABNF for all tags. 3053 o Updated references (still includes some references to expired 3054 drafts, notably ID-AUTH-RES. 3056 o Significant wordsmithing. 3058 F.7 Changes since -allman-00 version 3060 The following changes were made between draft-allman-dkim-base-00 and 3061 draft-allman-dkim-base-01: 3063 o Changed "c=" tag to separate out header from body 3064 canonicalization. 3066 o Eliminated "nowsp" canonicalization in favor of "relaxed", which 3067 is somewhat less relaxed (but more secure) than "nowsp". 3069 o Moved the (empty) Compliance section to the Sender Signing Policy 3070 document. 3072 o Added several IANA Considerations. 3074 o Fixed a number of grammar and formatting errors. 3076 Intellectual Property Statement 3078 The IETF takes no position regarding the validity or scope of any 3079 Intellectual Property Rights or other rights that might be claimed to 3080 pertain to the implementation or use of the technology described in 3081 this document or the extent to which any license under such rights 3082 might or might not be available; nor does it represent that it has 3083 made any independent effort to identify any such rights. Information 3084 on the procedures with respect to rights in RFC documents can be 3085 found in BCP 78 and BCP 79. 3087 Copies of IPR disclosures made to the IETF Secretariat and any 3088 assurances of licenses to be made available, or the result of an 3089 attempt made to obtain a general license or permission for the use of 3090 such proprietary rights by implementers or users of this 3091 specification can be obtained from the IETF on-line IPR repository at 3092 http://www.ietf.org/ipr. 3094 The IETF invites any interested party to bring to its attention any 3095 copyrights, patents or patent applications, or other proprietary 3096 rights that may cover technology that may be required to implement 3097 this standard. Please address the information to the IETF at 3098 ietf-ipr@ietf.org. 3100 The IETF has been notified of intellectual property rights claimed in 3101 regard to some or all of the specification contained in this 3102 document. For more information consult the online list of claimed 3103 rights. 3105 Disclaimer of Validity 3107 This document and the information contained herein are provided on an 3108 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3109 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3110 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3111 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3112 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3113 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3115 Copyright Statement 3117 Copyright (C) The Internet Society (2006). This document is subject 3118 to the rights, licenses and restrictions contained in BCP 78, and 3119 except as set forth therein, the authors retain all their rights. 3121 Acknowledgment 3123 Funding for the RFC Editor function is currently provided by the 3124 Internet Society.