idnits 2.17.1 draft-ietf-dkim-rfc4871bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5672, but the abstract doesn't seem to directly say this. It does mention RFC5672 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1318 has weird spacing: '... email elec...' -- The document date (April 27, 2011) is 4747 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) == Unused Reference: 'ITU-X660-1997' is defined on line 2858, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2-2002' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-X660-1997' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 5598 -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Obsoletes: 4871, 5672 T. Hansen, Ed. 5 (if approved) AT&T Laboratories 6 Intended status: Standards Track M. Kucherawy, Ed. 7 Expires: October 29, 2011 Cloudmark 8 April 27, 2011 10 DomainKeys Identified Mail (DKIM) Signatures 11 draft-ietf-dkim-rfc4871bis-08 13 Abstract 15 DomainKeys Identified Mail (DKIM) permits a person, role, or 16 organization that owns the signing domain to claim some 17 responsibility for a message by associating the domain with the 18 message. This can be an author's organization, an operational relay 19 or one of their agents. DKIM separates the question of the identity 20 of the signer of the message from the purported author of the 21 message. Assertion of responsibility is validated through a 22 cryptographic signature and querying the signer's domain directly to 23 retrieve the appropriate public key. Message transit from author to 24 recipient is through relays that typically make no substantive change 25 to the message content and thus preserve the DKIM signature. 27 This memo obsoletes RFC4871 and RFC5672 {DKIM 14}. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 29, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Notes to Editor and Reviewers . . . . . . . . . . . . . . . . 5 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 68 2.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 70 3.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 8 75 3.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 76 3.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 77 3.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 79 3.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 80 3.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 81 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 82 4.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 84 4.3. Signing and Verification Algorithms . . . . . . . . . . . 14 85 4.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 86 4.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 20 87 4.6. Key Management and Representation . . . . . . . . . . . . 29 88 4.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 89 4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 90 4.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 91 4.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 92 5. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 93 5.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 94 5.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 95 6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 96 6.1. Determine Whether the Email Should Be Signed and by 97 Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 98 6.2. Select a Private Key and Corresponding Selector 99 Information . . . . . . . . . . . . . . . . . . . . . . . 40 100 6.3. Normalize the Message to Prevent Transport Conversions . . 40 101 6.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 102 6.5. Recommended Signature Content . . . . . . . . . . . . . . 43 103 6.6. Compute the Message Hash and Signature . . . . . . . . . . 45 104 6.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 105 7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 106 7.1. Extract Signatures from the Message . . . . . . . . . . . 46 107 7.2. Communicate Verification Results . . . . . . . . . . . . . 51 108 7.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 110 8.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 111 8.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 112 8.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 113 8.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 114 8.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 115 8.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 116 8.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 117 8.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 118 8.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 119 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 120 9.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 121 9.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 122 9.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 123 9.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 124 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 125 9.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 61 126 9.7. Intentionally Malformed Key Records . . . . . . . . . . . 61 127 9.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 128 9.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 129 9.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 130 9.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 131 9.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 62 132 9.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 133 9.14. Attacks Involving Addition of Header Fields . . . . . . . 62 134 9.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 136 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 137 10.2. Informative References . . . . . . . . . . . . . . . . . . 65 138 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 139 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 140 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 67 141 A.3. The Email Signature is Verified . . . . . . . . . . . . . 68 142 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 69 143 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 144 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 145 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 146 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 147 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 148 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 151 1. Notes to Editor and Reviewers 153 This version of the memo contains notations such as "{DKIM 2}". 154 These correspond to DKIM working group issue tracker items. They 155 should be deleted prior to publication. 157 2. Introduction 159 DomainKeys Identified Mail (DKIM) permits a person, role, or 160 organization to claim some responsibility for a message by 161 associating a domain name [RFC1034] with the message [RFC5322], which 162 they are authorized to use. This can be an author's organization, an 163 operational relay or one of their agents. Assertion of 164 responsibility is validated through a cryptographic signature and 165 querying the signer's domain directly to retrieve the appropriate 166 public key. Message transit from author to recipient is through 167 relays that typically make no substantive change to the message 168 content and thus preserve the DKIM signature. A message can contain 169 multiple signatures, from the same or different organizations 170 involved with the message. 172 The approach taken by DKIM differs from previous approaches to 173 message signing (e.g., Secure/Multipurpose Internet Mail Extensions 174 (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: 176 o the message signature is written as a message header field so that 177 neither human recipients nor existing MUA (Mail User Agent) 178 software is confused by signature-related content appearing in the 179 message body; 181 o there is no dependency on public and private key pairs being 182 issued by well-known, trusted certificate authorities; 184 o there is no dependency on the deployment of any new Internet 185 protocols or services for public key distribution or revocation; 187 o signature verification failure does not force rejection of the 188 message; 190 o no attempt is made to include encryption as part of the mechanism; 192 o message archiving is not a design goal. 194 DKIM: 196 o is compatible with the existing email infrastructure and 197 transparent to the fullest extent possible; 199 o requires minimal new infrastructure; 201 o can be implemented independently of clients in order to reduce 202 deployment time; 204 o can be deployed incrementally; 206 o allows delegation of signing to third parties. 208 2.1. Signing Identity 210 DKIM separates the question of the identity of the signer of the 211 message from the purported author of the message. In particular, a 212 signature includes the identity of the signer. Verifiers can use the 213 signing information to decide how they want to process the message. 214 The signing identity is included as part of the signature header 215 field. 217 INFORMATIVE RATIONALE: The signing identity specified by a DKIM 218 signature is not required to match an address in any particular 219 header field because of the broad methods of interpretation by 220 recipient mail systems, including MUAs. 222 2.2. Scalability 224 DKIM is designed to support the extreme scalability requirements that 225 characterize the email identification problem. There are currently 226 over 70 million domains and a much larger number of individual 227 addresses. DKIM seeks to preserve the positive aspects of the 228 current email infrastructure, such as the ability for anyone to 229 communicate with anyone else without introduction. 231 2.3. Simple Key Management 233 DKIM differs from traditional hierarchical public-key systems in that 234 no Certificate Authority infrastructure is required; the verifier 235 requests the public key from a repository in the domain of the 236 claimed signer directly rather than from a third party. 238 The DNS is proposed as the initial mechanism for the public keys. 239 Thus, DKIM currently depends on DNS administration and the security 240 of the DNS system. DKIM is designed to be extensible to other key 241 fetching services as they become available. 243 2.4. Data Integrity 245 A DKIM signature associates the d= name with the computed hash of 246 some or all of the message (see Section 3.7) in order to prevent the 247 re-use of the signature with different messages. Verifying the 248 signature asserts that the hashed content has not changed since it 249 was signed, and asserts nothing else about "protecting" the end-to- 250 end integrity of the message. 252 3. Terminology and Definitions 254 This section defines terms used in the rest of the document. 256 DKIM is designed to operate within the Internet Mail service, as 257 defined in [RFC5598]. Basic email terminology is taken from that 258 specification. 260 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 264 document are to be interpreted as described in [RFC2119]. 266 3.1. Signers 268 Elements in the mail system that sign messages on behalf of a domain 269 are referred to as signers. These may be MUAs (Mail User Agents), 270 MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other 271 agents such as mailing list exploders. In general, any signer will 272 be involved in the injection of a message into the message system in 273 some way. The key issue is that a message must be signed before it 274 leaves the administrative domain of the signer. 276 3.2. Verifiers 278 Elements in the mail system that verify signatures are referred to as 279 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 280 In most cases it is expected that verifiers will be close to an end 281 user (reader) of the message or some consuming agent such as a 282 mailing list exploder. 284 3.3. Identity 286 A person, role, or organization. In the context of DKIM, examples 287 include the author, the author's organization, an ISP along the 288 handling path, an independent trust assessment service, and a mailing 289 list operator. 291 3.4. Identifier 293 A label that refers to an identity. 295 3.5. Signing Domain Identifier (SDID) 297 A single domain name that is the mandatory payload output of DKIM and 298 that refers to the identity claiming some responsibility for the 299 message by signing it. It is specified in Section 4.5. 301 3.6. Agent or User Identifier (AUID) 303 A single identifier that refers to the agent or user on behalf of 304 whom the Signing Domain Identifier (SDID) has taken responsibility. 305 The AUID comprises a domain name and an optional . The 306 domain name is the same as that used for the SDID or is a sub-domain 307 of it. For DKIM processing, the domain name portion of the AUID has 308 only basic domain name semantics; any possible owner-specific 309 semantics are outside the scope of DKIM. It is specified in 310 Section 4.5 . 312 3.7. Identity Assessor 314 A module that consumes DKIM's mandatory payload, which is the 315 responsible Signing Domain Identifier (SDID). The module is 316 dedicated to the assessment of the delivered identifier. Other DKIM 317 (and non-DKIM) values can also be delivered to this module as well as 318 to a more general message evaluation filtering engine. However, this 319 additional activity is outside the scope of the DKIM signature 320 specification. 322 3.8. Whitespace 324 There are three forms of whitespace: 326 o WSP represents simple whitespace, i.e., a space or a tab character 327 (formal definition in [RFC5234]). 329 o LWSP is linear whitespace, defined as WSP plus CRLF (formal 330 definition in [RFC5234]). 332 o FWS is folding whitespace. It allows multiple lines separated by 333 CRLF followed by at least one whitespace, to be joined. 335 The formal ABNF for these are (WSP and LWSP are given for information 336 only): 337 WSP = SP / HTAB 338 LWSP = *(WSP / CRLF WSP) 339 FWS = [*WSP CRLF] 1*WSP 341 The definition of FWS is identical to that in [RFC5322] except for 342 the exclusion of obs-FWS. 344 3.9. Imported ABNF Tokens 346 The following tokens are imported from other RFCs as noted. Those 347 RFCs should be considered definitive. 349 The following tokens are imported from [RFC5321]: 351 o "Local-part" (implementation warning: this permits quoted strings) 353 o "sub-domain" 355 The following tokens are imported from [RFC5322]: 357 o "field-name" (name of a header field) 359 o "dot-atom-text" (in the Local-part of an email address) 361 The following tokens are imported from [RFC2045]: 363 o "qp-section" (a single line of quoted-printable-encoded text) 365 o "hex-octet" (a quoted-printable encoded octet) 367 INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not 368 obey the rules of [RFC5234] and must be interpreted accordingly, 369 particularly as regards case folding. 371 Other tokens not defined herein are imported from [RFC5234]. These 372 are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, 373 etc. 375 3.10. Common ABNF Tokens 376 The following ABNF tokens are used elsewhere in this document: 377 hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] 378 ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") 379 base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) 380 [ [FWS] "=" [ [FWS] "=" ] ] 381 hdr-name = field-name 382 qp-hdr-value = dkim-quoted-printable ; with "|" encoded 384 3.11. DKIM-Quoted-Printable 386 The DKIM-Quoted-Printable encoding syntax resembles that described in 387 Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded 388 as an "=" followed by two hexadecimal digits from the alphabet 389 "0123456789ABCDEF" (no lowercase characters permitted) representing 390 the hexadecimal-encoded integer value of that character. All control 391 characters (those with values < %x20), 8-bit characters (values > 392 %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon 393 (";", %x3B) MUST be encoded. Note that all whitespace, including 394 SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS 395 MAY be added at arbitrary locations in order to avoid excessively 396 long lines; such whitespace is NOT part of the value, and MUST be 397 removed before decoding. 399 ABNF: 401 dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) 402 ; hex-octet is from RFC2045 403 dkim-safe-char = %x21-3A / %x3C / %x3E-7E 404 ; '!' - ':', '<', '>' - '~' 405 ; Characters not listed as "mail-safe" in 406 ; [RFC2049] are also not recommended. 408 INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- 409 Printable as defined in [RFC2045] in several important ways: 411 1. Whitespace in the input text, including CR and LF, must be 412 encoded. [RFC2045] does not require such encoding, and does 413 not permit encoding of CR or LF characters that are part of a 414 CRLF line break. 416 2. Whitespace in the encoded text is ignored. This is to allow 417 tags encoded using DKIM-Quoted-Printable to be wrapped as 418 needed. In particular, [RFC2045] requires that line breaks in 419 the input be represented as physical line breaks; that is not 420 the case here. 422 3. The "soft line break" syntax ("=" as the last non-whitespace 423 character on the line) does not apply. 425 4. DKIM-Quoted-Printable does not require that encoded lines be 426 no more than 76 characters long (although there may be other 427 requirements depending on the context in which the encoded 428 text is being used). 430 4. Protocol Elements 432 Protocol Elements are conceptual parts of the protocol that are not 433 specific to either signers or verifiers. The protocol descriptions 434 for signers and verifiers are described in later sections (Signer 435 Actions (Section 6) and Verifier Actions (Section 7)). NOTE: This 436 section must be read in the context of those sections. 438 4.1. Selectors 440 To support multiple concurrent public keys per signing domain, the 441 key namespace is subdivided using "selectors". For example, 442 selectors might indicate the names of office locations (e.g., 443 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 444 (e.g., "january2005", "february2005", etc.), or even an individual 445 user. 447 Selectors are needed to support some important use cases. For 448 example: 450 o Domains that want to delegate signing capability for a specific 451 address for a given duration to a partner, such as an advertising 452 provider or other outsourced function. 454 o Domains that want to allow frequent travelers to send messages 455 locally without the need to connect with a particular MSA. 457 o "Affinity" domains (e.g., college alumni associations) that 458 provide forwarding of incoming mail, but that do not operate a 459 mail submission agent for outgoing mail. 461 Periods are allowed in selectors and are component separators. When 462 keys are retrieved from the DNS, periods in selectors define DNS 463 label boundaries in a manner similar to the conventional use in 464 domain names. Selector components might be used to combine dates 465 with locations, for example, "march2005.reykjavik". In a DNS 466 implementation, this can be used to allow delegation of a portion of 467 the selector namespace. 469 ABNF: 470 selector = sub-domain *( "." sub-domain ) 472 The number of public keys and corresponding selectors for each domain 473 is determined by the domain owner. Many domain owners will be 474 satisfied with just one selector, whereas administratively 475 distributed organizations may choose to manage disparate selectors 476 and key pairs in different regions or on different email servers. 478 Beyond administrative convenience, selectors make it possible to 479 seamlessly replace public keys on a routine basis. If a domain 480 wishes to change from using a public key associated with selector 481 "january2005" to a public key associated with selector 482 "february2005", it merely makes sure that both public keys are 483 advertised in the public-key repository concurrently for the 484 transition period during which email may be in transit prior to 485 verification. At the start of the transition period, the outbound 486 email servers are configured to sign with the "february2005" private 487 key. At the end of the transition period, the "january2005" public 488 key is removed from the public-key repository. 490 INFORMATIVE NOTE: A key may also be revoked as described below. 491 The distinction between revoking and removing a key selector 492 record is subtle. When phasing out keys as described above, a 493 signing domain would probably simply remove the key record after 494 the transition period. However, a signing domain could elect to 495 revoke the key (but maintain the key record) for a further period. 496 There is no defined semantic difference between a revoked key and 497 a removed key. 499 While some domains may wish to make selector values well known, 500 others will want to take care not to allocate selector names in a way 501 that allows harvesting of data by outside parties. For example, if 502 per-user keys are issued, the domain owner will need to make the 503 decision as to whether to associate this selector directly with the 504 name of a registered end-user, or make it some unassociated random 505 value, such as a fingerprint of the public key. 507 INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key 508 (for example, changing the key associated with a user's name) 509 makes it impossible to tell the difference between a message that 510 didn't verify because the key is no longer valid versus a message 511 that is actually forged. For this reason, signers are ill-advised 512 to reuse selectors for new keys. A better strategy is to assign 513 new keys to new selectors. 515 4.2. Tag=Value Lists 517 DKIM uses a simple "tag=value" syntax in several contexts, including 518 in messages and domain signature records. 520 Values are a series of strings containing either plain text, "base64" 521 text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, 522 Section 6.7), or "dkim-quoted-printable" (as defined in 523 Section 3.11). The name of the tag will determine the encoding of 524 each value. Unencoded semicolon (";") characters MUST NOT occur in 525 the tag value, since that separates tag-specs. 527 INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined 528 below (as "tag-value") only includes 7-bit characters, an 529 implementation that wished to anticipate future standards would be 530 advised not to preclude the use of UTF8-encoded text in tag=value 531 lists. 533 Formally, the ABNF syntax rules are as follows: 534 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 535 tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] 536 tag-name = ALPHA 0*ALNUMPUNC 537 tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] 538 ; WSP and FWS prohibited at beginning and end 539 tval = 1*VALCHAR 540 VALCHAR = %x21-3A / %x3C-7E 541 ; EXCLAMATION to TILDE except SEMICOLON 542 ALNUMPUNC = ALPHA / DIGIT / "_" 544 Note that WSP is allowed anywhere around tags. In particular, any 545 WSP after the "=" and any WSP before the terminating ";" is not part 546 of the value; however, WSP inside the value is significant. 548 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 549 processed as case sensitive unless the specific tag description of 550 semantics specifies case insensitivity. 552 Tags with duplicate names MUST NOT occur within a single tag-list; if 553 a tag name does occur more than once, the entire tag-list is invalid. 555 Whitespace within a value MUST be retained unless explicitly excluded 556 by the specific tag description. 558 Tag=value pairs that represent the default value MAY be included to 559 aid legibility. 561 Unrecognized tags MUST be ignored. 563 Tags that have an empty value are not the same as omitted tags. An 564 omitted tag is treated as having the default value; a tag with an 565 empty value explicitly designates the empty string as the value. 567 4.3. Signing and Verification Algorithms 569 DKIM supports multiple digital signature algorithms. Two algorithms 570 are defined by this specification at this time: rsa-sha1 and rsa- 571 sha256. Signers MUST implement and SHOULD sign using rsa-sha256. 572 Verifiers MUST implement rsa-sha256. 574 INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some 575 senders might prefer to use rsa-sha1 when balancing security 576 strength against performance, complexity, or other needs. 577 However, compliant verifiers might not implement rsa-sha1; they 578 will treat such messages as unsigned. {DKIM 13} 580 4.3.1. The rsa-sha1 Signing Algorithm 582 The rsa-sha1 Signing Algorithm computes a message hash as described 583 in Section 4.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. 584 That hash is then signed by the signer using the RSA algorithm 585 (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the 586 signer's private key. The hash MUST NOT be truncated or converted 587 into any form other than the native binary form before being signed. 588 The signing algorithm SHOULD use a public exponent of 65537. 590 4.3.2. The rsa-sha256 Signing Algorithm 592 The rsa-sha256 Signing Algorithm computes a message hash as described 593 in Section 4.7 below using SHA-256 [FIPS-180-2-2002] as the hash-alg. 594 That hash is then signed by the signer using the RSA algorithm 595 (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the 596 signer's private key. The hash MUST NOT be truncated or converted 597 into any form other than the native binary form before being signed. 599 4.3.3. Key Sizes 601 Selecting appropriate key sizes is a trade-off between cost, 602 performance, and risk. Since short RSA keys more easily succumb to 603 off-line attacks, signers MUST use RSA keys of at least 1024 bits for 604 long-lived keys. Verifiers MUST be able to validate signatures with 605 keys ranging from 512 bits to 2048 bits, and they MAY be able to 606 validate signatures with larger keys. Verifier policies may use the 607 length of the signing key as one metric for determining whether a 608 signature is acceptable. 610 Factors that should influence the key size choice include the 611 following: 613 o The practical constraint that large (e.g., 4096 bit) keys may not 614 fit within a 512-byte DNS UDP response packet 616 o The security constraint that keys smaller than 1024 bits are 617 subject to off-line attacks 619 o Larger keys impose higher CPU costs to verify and sign email 621 o Keys can be replaced on a regular basis, thus their lifetime can 622 be relatively short 624 o The security goals of this specification are modest compared to 625 typical goals of other systems that employ digital signatures 627 See [RFC3766] for further discussion on selecting key sizes. 629 4.3.4. Other Algorithms 631 Other algorithms MAY be defined in the future. Verifiers MUST ignore 632 any signatures using algorithms that they do not implement. 634 4.4. Canonicalization 636 Some mail systems modify email in transit, potentially invalidating a 637 signature. For most signers, mild modification of email is 638 immaterial to validation of the DKIM domain name's use. For such 639 signers, a canonicalization algorithm that survives modest in-transit 640 modification is preferred. 642 Other signers demand that any modification of the email, however 643 minor, result in a signature verification failure. These signers 644 prefer a canonicalization algorithm that does not tolerate in-transit 645 modification of the signed email. 647 Some signers may be willing to accept modifications to header fields 648 that are within the bounds of email standards such as [RFC5322], but 649 are unwilling to accept any modification to the body of messages. 651 To satisfy all requirements, two canonicalization algorithms are 652 defined for each of the header and the body: a "simple" algorithm 653 that tolerates almost no modification and a "relaxed" algorithm that 654 tolerates common modifications such as whitespace replacement and 655 header field line rewrapping. A signer MAY specify either algorithm 656 for header or body when signing an email. If no canonicalization 657 algorithm is specified by the signer, the "simple" algorithm defaults 658 for both header and body. Verifiers MUST implement both 659 canonicalization algorithms. Note that the header and body may use 660 different canonicalization algorithms. Further canonicalization 661 algorithms MAY be defined in the future; verifiers MUST ignore any 662 signatures that use unrecognized canonicalization algorithms. 664 Canonicalization simply prepares the email for presentation to the 665 signing or verification algorithm. It MUST NOT change the 666 transmitted data in any way. Canonicalization of header fields and 667 body are described below. 669 NOTE: This section assumes that the message is already in "network 670 normal" format (text is ASCII encoded, lines are separated with CRLF 671 characters, etc.). See also Section 6.3 for information about 672 normalizing the message. 674 4.4.1. The "simple" Header Canonicalization Algorithm 676 The "simple" header canonicalization algorithm does not change header 677 fields in any way. Header fields MUST be presented to the signing or 678 verification algorithm exactly as they are in the message being 679 signed or verified. In particular, header field names MUST NOT be 680 case folded and whitespace MUST NOT be changed. 682 4.4.2. The "relaxed" Header Canonicalization Algorithm 684 The "relaxed" header canonicalization algorithm MUST apply the 685 following steps in order: 687 o Convert all header field names (not the header field values) to 688 lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". 690 o Unfold all header field continuation lines as described in 691 [RFC5322]; in particular, lines with terminators embedded in 692 continued header field values (that is, CRLF sequences followed by 693 WSP) MUST be interpreted without the CRLF. Implementations MUST 694 NOT remove the CRLF at the end of the header field value. 696 o Convert all sequences of one or more WSP characters to a single SP 697 character. WSP characters here include those before and after a 698 line folding boundary. 700 o Delete all WSP characters at the end of each unfolded header field 701 value. 703 o Delete any WSP characters remaining before and after the colon 704 separating the header field name from the header field value. The 705 colon separator MUST be retained. 707 4.4.3. The "simple" Body Canonicalization Algorithm 709 The "simple" body canonicalization algorithm ignores all empty lines 710 at the end of the message body. An empty line is a line of zero 711 length after removal of the line terminator. If there is no body or 712 no trailing CRLF on the message body, a CRLF is added. It makes no 713 other changes to the message body. In more formal terms, the 714 "simple" body canonicalization algorithm converts "0*CRLF" at the end 715 of the body to a single "CRLF". 717 Note that a completely empty or missing body is canonicalized as a 718 single "CRLF"; that is, the canonicalized length will be 2 octets. 720 The sha1 value (in base64) for an empty body (canonicalized to a 721 "CRLF") is: 722 uoq1oCgLlTqpdDX/iUbLy7J1Wic= 723 The sha256 value is: 724 frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= 726 4.4.4. The "relaxed" Body Canonicalization Algorithm 728 The "relaxed" body canonicalization algorithm MUST apply the 729 following steps (a) and (b) in order: 731 a. Reduce whitespace: 733 * Ignore all whitespace at the end of lines. Implementations 734 MUST NOT remove the CRLF at the end of the line. 736 * Reduce all sequences of WSP within a line to a single SP 737 character. 739 b. Ignore all empty lines at the end of the message body. "Empty 740 line" is defined in Section 3.4.3. If the body is non-empty, but 741 does not end with a CRLF, a CRLF is added. (For email, this is 742 only possible when using extensions to SMTP or non-SMTP transport 743 mechanisms.) 745 The sha1 value (in base64) for an empty body (canonicalized to a null 746 input) is: 747 2jmj7l5rSw0yVb/vlWAYkK/YBwk= 748 The sha256 value is: 749 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= 751 INFORMATIVE NOTE: It should be noted that the relaxed body 752 canonicalization algorithm may enable certain types of extremely 753 crude "ASCII Art" attacks where a message may be conveyed by 754 adjusting the spacing between words. If this is a concern, the 755 "simple" body canonicalization algorithm should be used instead. 757 4.4.5. Body Length Limits 759 A body length count MAY be specified to limit the signature 760 calculation to an initial prefix of the body text, measured in 761 octets. If the body length count is not specified, the entire 762 message body is signed. 764 INFORMATIVE RATIONALE: This capability is provided because it is 765 very common for mailing lists to add trailers to messages (e.g., 766 instructions how to get off the list). Until those messages are 767 also signed, the body length count is a useful tool for the 768 verifier since it may as a matter of policy accept messages having 769 valid signatures with extraneous data. 771 INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables 772 an attack in which an attacker modifies a message to include 773 content that solely benefits the attacker. It is possible for the 774 appended content to completely replace the original content in the 775 end recipient's eyes and to defeat duplicate message detection 776 algorithms. To avoid this attack, signers should be wary of using 777 this tag, and verifiers might wish to ignore the tag, {DKIM 2} 778 perhaps based on other criteria. 780 The body length count allows the signer of a message to permit data 781 to be appended to the end of the body of a signed message. The body 782 length count MUST be calculated following the canonicalization 783 algorithm; for example, any whitespace ignored by a canonicalization 784 algorithm is not included as part of the body length count. Signers 785 of MIME messages that include a body length count SHOULD be sure that 786 the length extends to the closing MIME boundary string. 788 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 789 the only acceptable modifications are to add to the MIME postlude 790 would use a body length count encompassing the entire final MIME 791 boundary string, including the final "--CRLF". A signer wishing 792 to allow additional MIME parts but not modification of existing 793 parts would use a body length count extending through the final 794 MIME boundary string, omitting the final "--CRLF". Note that this 795 only works for some MIME types, e.g., multipart/mixed but not 796 multipart/signed. 798 A body length count of zero means that the body is completely 799 unsigned. 801 Signers wishing to ensure that no modification of any sort can occur 802 should specify the "simple" canonicalization algorithm for both 803 header and body and omit the body length count. 805 4.4.6. Canonicalization Examples (INFORMATIVE) 807 In the following examples, actual whitespace is used only for 808 clarity. The actual input and output text is designated using 809 bracketed descriptors: "" for a space character, "" for a 810 tab character, and "" for a carriage-return/line-feed sequence. 811 For example, "X Y" and "XY" represent the same three 812 characters. 814 Example 1: A message reading: 815 A: X 816 B : Y 817 Z 818 819 C 820 D E 821 822 824 when canonicalized using relaxed canonicalization for both header and 825 body results in a header reading: 826 a:X 827 b:Y Z 829 and a body reading: 830 C 831 D E 833 Example 2: The same message canonicalized using simple 834 canonicalization for both header and body results in a header 835 reading: 836 A: X 837 B : Y 838 Z 840 and a body reading: 841 C 842 D E 844 Example 3: When processed using relaxed header canonicalization and 845 simple body canonicalization, the canonicalized version has a header 846 of: 847 a:X 848 b:Y Z 849 and a body reading: 850 C 851 D E 853 4.5. The DKIM-Signature Header Field 855 The signature of the email is stored in the DKIM-Signature header 856 field. This header field contains all of the signature and key- 857 fetching data. The DKIM-Signature value is a tag-list as described 858 in Section 4.2. 860 The DKIM-Signature header field SHOULD be treated as though it were a 861 trace header field as defined in Section 3.6 of [RFC5322], and hence 862 SHOULD NOT be reordered and SHOULD be prepended to the message. 864 The DKIM-Signature header field being created or verified is always 865 included in the signature calculation, after the rest of the header 866 fields being signed; however, when calculating or verifying the 867 signature, the value of the "b=" tag (signature value) of that DKIM- 868 Signature header field MUST be treated as though it were an empty 869 string. Unknown tags in the DKIM-Signature header field MUST be 870 included in the signature calculation but MUST be otherwise ignored 871 by verifiers. Other DKIM-Signature header fields that are included 872 in the signature should be treated as normal header fields; in 873 particular, the "b=" tag is not treated specially. 875 The encodings for each field type are listed below. Tags described 876 as qp-section are encoded as described in Section 6.7 of MIME Part 877 One [RFC2045], with the additional conversion of semicolon characters 878 to "=3B"; intuitively, this is one line of quoted-printable encoded 879 text. The dkim-quoted-printable syntax is defined in Section 3.11. 881 Tags on the DKIM-Signature header field along with their type and 882 requirement status are shown below. Unrecognized tags MUST be 883 ignored. 885 v= Version (MUST be included). This tag defines the version of this 886 specification that applies to the signature record. It MUST have 887 the value "1". Note that verifiers must do a string comparison on 888 this value; for example, "1" is not the same as "1.0". 890 ABNF: 891 sig-v-tag = %x76 [FWS] "=" [FWS] "1" 892 INFORMATIVE NOTE: DKIM-Signature version numbers are expected 893 to increase arithmetically as new versions of this 894 specification are released. 896 a= The algorithm used to generate the signature (plain-text; 897 REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; 898 signers SHOULD sign using "rsa-sha256". 900 ABNF: 902 sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg 903 sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h 904 sig-a-tag-k = "rsa" / x-sig-a-tag-k 905 sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h 906 x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) 907 ; for later extension 908 x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) 909 ; for later extension 911 b= The signature data (base64; REQUIRED). Whitespace is ignored in 912 this value and MUST be ignored when reassembling the original 913 signature. In particular, the signing process can safely insert 914 FWS in this value in arbitrary places to conform to line-length 915 limits. See Signer Actions (Section 6) for how the signature is 916 computed. 918 ABNF: 919 sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data 920 sig-b-tag-data = base64string 922 bh= The hash of the canonicalized body part of the message as 923 limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored 924 in this value and MUST be ignored when reassembling the original 925 signature. In particular, the signing process can safely insert 926 FWS in this value in arbitrary places to conform to line-length 927 limits. See Section 4.7 for how the body hash is computed. 929 ABNF: 930 sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data 931 sig-bh-tag-data = base64string 933 c= Message canonicalization (plain-text; OPTIONAL, default is 934 "simple/simple"). This tag informs the verifier of the type of 935 canonicalization used to prepare the message for signing. It 936 consists of two names separated by a "slash" (%d47) character, 937 corresponding to the header and body canonicalization algorithms 938 respectively. These algorithms are described in Section 4.4. If 939 only one algorithm is named, that algorithm is used for the header 940 and "simple" is used for the body. For example, "c=relaxed" is 941 treated the same as "c=relaxed/simple". 943 ABNF: 944 sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 945 ["/" sig-c-tag-alg] 946 sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg 947 x-sig-c-tag-alg = hyphenated-word ; for later extension 949 d= The SDID claiming responsibility for an introduction of a message 950 into the mail stream (plain-text; REQUIRED). Hence, the SDID 951 value is used to form the query for the public key. The SDID MUST 952 correspond to a valid DNS name under which the DKIM key record is 953 published. The conventions and semantics used by a signer to 954 create and use a specific SDID are outside the scope of the DKIM 955 Signing specification, as is any use of those conventions and 956 semantics. When presented with a signature that does not meet 957 these requirements, verifiers MUST consider the signature invalid. 959 Internationalized domain names MUST be encoded as A-Labels, as 960 described in Section 2.3 of [RFC5890]. {DKIM 4}. 962 ABNF: 964 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 965 domain-name = sub-domain 1*("." sub-domain) 966 ; from RFC5321 Domain, excluding address-literal 968 h= Signed header fields (plain-text, but see description; REQUIRED). 969 A colon-separated list of header field names that identify the 970 header fields presented to the signing algorithm. The field MUST 971 contain the complete list of header fields in the order presented 972 to the signing algorithm. The field MAY contain names of header 973 fields that do not exist when signed; nonexistent header fields do 974 not contribute to the signature computation (that is, they are 975 treated as the null input, including the header field name, the 976 separating colon, the header field value, and any CRLF 977 terminator). The field MUST NOT include the DKIM-Signature header 978 field that is being created or verified, but may include others. 979 Folding whitespace (FWS) MAY be included on either side of the 980 colon separator. Header field names MUST be compared against 981 actual header field names in a case-insensitive manner. This list 982 MUST NOT be empty. See Section 6.4 for a discussion of choosing 983 header fields to sign. 985 ABNF: 986 sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name 987 0*( [FWS] ":" [FWS] hdr-name ) 989 INFORMATIVE EXPLANATION: By "signing" header fields that do not 990 actually exist, a signer can prevent insertion of those header 991 fields before verification. However, since a signer cannot 992 possibly know what header fields might be created in the 993 future, and that some MUAs might present header fields that are 994 embedded inside a message (e.g., as a message/rfc822 content 995 type), the security of this solution is not total. 997 INFORMATIVE EXPLANATION: The exclusion of the header field name 998 and colon as well as the header field value for non-existent 999 header fields prevents an attacker from inserting an actual 1000 header field with a null value. 1002 i= The Agent or User Identifier (AUID) on behalf of which the SDID is 1003 taking responsibility (dkim-quoted-printable; OPTIONAL, default is 1004 an empty Local-part followed by an "@" followed by the domain from 1005 the "d=" tag). 1007 The syntax is a standard email address where the Local-part MAY be 1008 omitted. The domain part of the address MUST be the same as, or a 1009 subdomain of, the value of the "d=" tag. 1011 Internationalized domain names MUST be encoded as A-Labels, as 1012 described in Section 2.3 of [RFC5890]. {DKIM 4}. 1014 ABNF: 1016 sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] 1017 "@" domain-name 1019 The AUID is specified as having the same syntax as an email 1020 address, but is not required to have the same semantics. Notably, 1021 the domain name is not required to be registered in the DNS -- so 1022 it might not resolve in a query -- and the Local-part MAY be drawn 1023 from a namespace unrelated to any mailbox. The details of the 1024 structure and semantics for the namespace are determined by the 1025 Signer. Any knowledge or use of those details by verifiers or 1026 assessors is outside the scope of the DKIM Signing specification. 1027 The Signer MAY choose to use the same namespace for its AUIDs as 1028 its users' email addresses or MAY choose other means of 1029 representing its users. However, the signer SHOULD use the same 1030 AUID for each message intended to be evaluated as being within the 1031 same sphere of responsibility, if it wishes to offer receivers the 1032 option of using the AUID as a stable identifier that is finer 1033 grained than the SDID. 1035 INFORMATIVE NOTE: The Local-part of the "i=" tag is optional 1036 because in some cases a signer may not be able to establish a 1037 verified individual identity. In such cases, the signer might 1038 wish to assert that although it is willing to go as far as 1039 signing for the domain, it is unable or unwilling to commit to 1040 an individual user name within their domain. It can do so by 1041 including the domain part but not the Local-part of the 1042 identity. 1044 INFORMATIVE DISCUSSION: This specification does not require the 1045 value of the "i=" tag to match the identity in any message 1046 header fields. This is considered to be a verifier policy 1047 issue. Constraints between the value of the "i=" tag and other 1048 identities in other header fields seek to apply basic 1049 authentication into the semantics of trust associated with a 1050 role such as content author. Trust is a broad and complex 1051 topic and trust mechanisms are subject to highly creative 1052 attacks. The real-world efficacy of any but the most basic 1053 bindings between the "i=" value and other identities is not 1054 well established, nor is its vulnerability to subversion by an 1055 attacker. Hence reliance on the use of these options should be 1056 strictly limited. In particular, it is not at all clear to 1057 what extent a typical end-user recipient can rely on any 1058 assurances that might be made by successful use of the "i=" 1059 options. 1061 l= Body length count (plain-text unsigned decimal integer; OPTIONAL, 1062 default is entire body). This tag informs the verifier of the 1063 number of octets in the body of the email after canonicalization 1064 included in the cryptographic hash, starting from 0 immediately 1065 following the CRLF preceding the body. This value MUST NOT be 1066 larger than the actual number of octets in the canonicalized 1067 message body. 1069 INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might 1070 allow display of fraudulent content without appropriate warning 1071 to end users. The "l=" tag is intended for increasing 1072 signature robustness when sending to mailing lists that both 1073 modify their content and do not sign their messages. However, 1074 using the "l=" tag enables attacks in which an intermediary 1075 with malicious intent modifies a message to include content 1076 that solely benefits the attacker. It is possible for the 1077 appended content to completely replace the original content in 1078 the end recipient's eyes and to defeat duplicate message 1079 detection algorithms. Examples are described in Security 1080 Considerations Section 9. To avoid this attack, signers should 1081 be extremely wary of using this tag, and verifiers might wish 1082 to ignore the tag. {DKIM 2} 1084 INFORMATIVE NOTE: The value of the "l=" tag is constrained to 1085 76 decimal digits. This constraint is not intended to predict 1086 the size of future messages or to require implementations to 1087 use an integer representation large enough to represent the 1088 maximum possible value, but is intended to remind the 1089 implementer to check the length of this and all other tags 1090 during verification and to test for integer overflow when 1091 decoding the value. Implementers may need to limit the actual 1092 value expressed to a value smaller than 10^76, e.g., to allow a 1093 message to fit within the available storage space. 1095 ABNF: 1096 sig-l-tag = %x6c [FWS] "=" [FWS] 1097 1*76DIGIT 1099 q= A colon-separated list of query methods used to retrieve the 1100 public key (plain-text; OPTIONAL, default is "dns/txt"). Each 1101 query method is of the form "type[/options]", where the syntax and 1102 semantics of the options depend on the type and specified options. 1103 If there are multiple query mechanisms listed, the choice of query 1104 mechanism MUST NOT change the interpretation of the signature. 1105 Implementations MUST use the recognized query mechanisms in the 1106 order presented. Unrecognized query mechanisms MUST be ignored. 1108 Currently, the only valid value is "dns/txt", which defines the 1109 DNS TXT record lookup algorithm described elsewhere in this 1110 document. The only option defined for the "dns" query type is 1111 "txt", which MUST be included. Verifiers and signers MUST support 1112 "dns/txt". 1114 ABNF: 1115 sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method 1116 *([FWS] ":" [FWS] sig-q-tag-method) 1117 sig-q-tag-method = "dns/txt" / x-sig-q-tag-type 1118 ["/" x-sig-q-tag-args] 1119 x-sig-q-tag-type = hyphenated-word ; for future extension 1120 x-sig-q-tag-args = qp-hdr-value 1122 s= The selector subdividing the namespace for the "d=" (domain) tag 1123 (plain-text; REQUIRED). 1125 Internationalized selector names MUST be encoded as A-Labels, as 1126 described in Section 2.3 of [RFC5890]. {DKIM 4}. 1128 ABNF: 1129 sig-s-tag = %x73 [FWS] "=" [FWS] selector 1131 t= Signature Timestamp (plain-text unsigned decimal integer; 1132 RECOMMENDED, default is an unknown creation time). The time that 1133 this signature was created. The format is the number of seconds 1134 since 00:00:00 on January 1, 1970 in the UTC time zone. The value 1135 is expressed as an unsigned integer in decimal ASCII. This value 1136 is not constrained to fit into a 31- or 32-bit integer. 1137 Implementations SHOULD be prepared to handle values up to at least 1138 10^12 (until approximately AD 200,000; this fits into 40 bits). 1139 To avoid denial-of-service attacks, implementations MAY consider 1140 any value longer than 12 digits to be infinite. Leap seconds are 1141 not counted. Implementations MAY ignore signatures that have a 1142 timestamp in the future. 1144 ABNF: 1145 sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT 1147 x= Signature Expiration (plain-text unsigned decimal integer; 1148 RECOMMENDED, default is no expiration). The format is the same as 1149 in the "t=" tag, represented as an absolute date, not as a time 1150 delta from the signing timestamp. The value is expressed as an 1151 unsigned integer in decimal ASCII, with the same constraints on 1152 the value in the "t=" tag. Signatures MAY be considered invalid 1153 if the verification time at the verifier is past the expiration 1154 date. The verification time should be the time that the message 1155 was first received at the administrative domain of the verifier if 1156 that time is reliably available; otherwise the current time should 1157 be used. The value of the "x=" tag MUST be greater than the value 1158 of the "t=" tag if both are present. 1160 INFORMATIVE NOTE: The "x=" tag is not intended as an anti- 1161 replay defense. 1163 INFORMATIVE NOTE: Due to clock drift, the receiver's notion of 1164 when to consider the signature expired may not match exactly 1165 when the sender is expecting. Receivers MAY add a 'fudge 1166 factor' to allow for such possible drift. 1168 ABNF: 1169 sig-x-tag = %x78 [FWS] "=" [FWS] 1170 1*12DIGIT 1172 z= Copied header fields (dkim-quoted-printable, but see description; 1173 OPTIONAL, default is null). A vertical-bar-separated list of 1174 selected header fields present when the message was signed, 1175 including both the field name and value. It is not required to 1176 include all header fields present at the time of signing. This 1177 field need not contain the same header fields listed in the "h=" 1178 tag. The header field text itself must encode the vertical bar 1179 ("|", %x7C) character (i.e., vertical bars in the "z=" text are 1180 meta-characters, and any actual vertical bar characters in a 1181 copied header field must be encoded). Note that all whitespace 1182 must be encoded, including whitespace between the colon and the 1183 header field value. After encoding, FWS MAY be added at arbitrary 1184 locations in order to avoid excessively long lines; such 1185 whitespace is NOT part of the value of the header field, and MUST 1186 be removed before decoding. 1188 The header fields referenced by the "h=" tag refer to the fields 1189 in the [RFC5322] header of the message, not to any copied fields 1190 in the "z=" tag. Copied header field values are for diagnostic 1191 use. 1193 ABNF: 1194 sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy 1195 *( "|" [FWS] sig-z-tag-copy ) 1196 sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value 1198 INFORMATIVE EXAMPLE of a signature header field spread across 1199 multiple continuation lines: 1200 DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; 1201 c=simple; q=dns/txt; i=@eng.example.net; 1202 t=1117574938; x=1118006938; 1203 h=from:to:subject:date; 1204 z=From:foo@eng.example.net|To:joe@example.com| 1205 Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; 1206 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; 1207 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR 1209 4.6. Key Management and Representation 1211 Signature applications require some level of assurance that the 1212 verification public key is associated with the claimed signer. Many 1213 applications achieve this by using public key certificates issued by 1214 a trusted third party. However, DKIM can achieve a sufficient level 1215 of security, with significantly enhanced scalability, by simply 1216 having the verifier query the purported signer's DNS entry (or some 1217 security-equivalent) in order to retrieve the public key. 1219 DKIM keys can potentially be stored in multiple types of key servers 1220 and in multiple formats. The storage and format of keys are 1221 irrelevant to the remainder of the DKIM algorithm. 1223 Parameters to the key lookup algorithm are the type of the lookup 1224 (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- 1225 Signature header field), and the selector (the "s=" tag). 1226 public_key = dkim_find_key(q_val, d_val, s_val) 1228 This document defines a single binding, using DNS TXT records to 1229 distribute the keys. Other bindings may be defined in the future. 1231 4.6.1. Textual Representation 1233 It is expected that many key servers will choose to present the keys 1234 in an otherwise unstructured text format (for example, an XML form 1235 would not be considered to be unstructured text for this purpose). 1236 The following definition MUST be used for any DKIM key represented in 1237 an otherwise unstructured textual form. 1239 The overall syntax is a tag-list as described in Section 4.2. The 1240 current valid tags are described below. Other tags MAY be present 1241 and MUST be ignored by any implementation that does not understand 1242 them. 1244 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 1245 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 1246 (without the quotes). This tag MUST be the first tag in the 1247 record. Records beginning with a "v=" tag with any other value 1248 MUST be discarded. Note that verifiers must do a string 1249 comparison on this value; for example, "DKIM1" is not the same as 1250 "DKIM1.0". 1252 ABNF: 1253 key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31 1254 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 1255 allowing all algorithms). A colon-separated list of hash 1256 algorithms that might be used. Unrecognized algorithms MUST be 1257 ignored. Refer to Section 4.3 for a discussion of the hash 1258 algorithms implemented by Signers and Verifiers. The set of 1259 algorithms listed in this tag in each record is an operational 1260 choice made by the Signer. 1262 ABNF: 1263 key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 1264 0*( [FWS] ":" [FWS] key-h-tag-alg ) 1265 key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg 1266 x-key-h-tag-alg = hyphenated-word ; for future extension 1268 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 1269 verifiers MUST support the "rsa" key type. The "rsa" key type 1270 indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey 1271 [RFC3447] (see Sections Section 4.1 and A.1.1) is being used in 1272 the "p=" tag. (Note: the "p=" tag further encodes the value using 1273 the base64 algorithm.) Unrecognized key types MUST be ignored. 1275 ABNF: 1276 key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type 1277 key-k-tag-type = "rsa" / x-key-k-tag-type 1278 x-key-k-tag-type = hyphenated-word ; for future extension 1280 n= Notes that might be of interest to a human (qp-section; OPTIONAL, 1281 default is empty). No interpretation is made by any program. 1282 This tag should be used sparingly in any key server mechanism that 1283 has space limitations (notably DNS). This is intended for use by 1284 administrators, not end users. 1286 ABNF: 1287 key-n-tag = %x6e [FWS] "=" [FWS] qp-section 1288 p= Public-key data (base64; REQUIRED). An empty value means that 1289 this public key has been revoked. The syntax and semantics of 1290 this tag value before being encoded in base64 are defined by the 1291 "k=" tag. 1293 INFORMATIVE RATIONALE: If a private key has been compromised or 1294 otherwise disabled (e.g., an outsourcing contract has been 1295 terminated), a signer might want to explicitly state that it 1296 knows about the selector, but all messages using that selector 1297 should fail verification. Verifiers should ignore any DKIM- 1298 Signature header fields with a selector referencing a revoked 1299 key. 1301 ABNF: 1302 key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] 1304 INFORMATIVE NOTE: A base64string is permitted to include white 1305 space (FWS) at arbitrary places; however, any CRLFs must be 1306 followed by at least one WSP character. Implementors and 1307 administrators are cautioned to ensure that selector TXT 1308 records conform to this specification. 1310 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 1311 separated list of service types to which this record applies. 1312 Verifiers for a given service type MUST ignore this record if the 1313 appropriate type is not listed. Unrecognized service types MUST 1314 be ignored. Currently defined service types are as follows: 1316 * matches all service types 1318 email electronic mail (not necessarily limited to SMTP) 1320 This tag is intended to constrain the use of keys for other 1321 purposes, should use of DKIM be defined by other services in the 1322 future. 1324 ABNF: 1325 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type 1326 0*( [FWS] ":" [FWS] key-s-tag-type ) 1327 key-s-tag-type = "email" / "*" / x-key-s-tag-type 1328 x-key-s-tag-type = hyphenated-word ; for future extension 1330 t= Flags, represented as a colon-separated list of names (plain- 1331 text; OPTIONAL, default is no flags set). Unrecognized flags MUST 1332 be ignored. The defined flags are as follows: 1334 y This domain is testing DKIM. Verifiers MUST NOT treat messages 1335 from signers in testing mode differently from unsigned email, even 1336 should the signature fail to verify. Verifiers MAY wish to track 1337 testing mode results to assist the signer. 1339 s Any DKIM-Signature header fields using the "i=" tag MUST have the 1340 same domain value on the right-hand side of the "@" in the "i=" 1341 tag and the value of the "d=" tag. That is, the "i=" domain MUST 1342 NOT be a subdomain of "d=". Use of this flag is RECOMMENDED 1343 unless subdomaining is required. 1345 ABNF: 1346 key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 1347 0*( [FWS] ":" [FWS] key-t-tag-flag ) 1348 key-t-tag-flag = "y" / "s" / x-key-t-tag-flag 1349 x-key-t-tag-flag = hyphenated-word ; for future extension 1351 Unrecognized flags MUST be ignored. 1353 4.6.2. DNS Binding 1355 A binding using DNS TXT records as a key service is hereby defined. 1356 All implementations MUST support this binding. 1358 4.6.2.1. Namespace 1360 All DKIM keys are stored in a subdomain named "_domainkey". Given a 1361 DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag 1362 of "foo.bar", the DNS query will be for 1363 "foo.bar._domainkey.example.com". 1365 4.6.2.2. Resource Record Types for Key Storage 1367 The DNS Resource Record type used is specified by an option to the 1368 query-type ("q=") tag. The only option defined in this base 1369 specification is "txt", indicating the use of a TXT Resource Record 1370 (RR). A later extension of this standard may define another RR type. 1372 Strings in a TXT RR MUST be concatenated together before use with no 1373 intervening whitespace. TXT RRs MUST be unique for a particular 1374 selector name; that is, if there are multiple records in an RRset, 1375 the results are undefined. 1377 TXT RRs are encoded as described in Section 4.6.1 1379 4.7. Computing the Message Hashes 1381 Both signing and verifying message signatures start with a step of 1382 computing two cryptographic hashes over the message. Signers will 1383 choose the parameters of the signature as described in Signer Actions 1384 Section 6; verifiers will use the parameters specified in the DKIM- 1385 Signature header field being verified. In the following discussion, 1386 the names of the tags in the DKIM-Signature header field that either 1387 exists (when verifying) or will be created (when signing) are used. 1388 Note that canonicalization (Section 4.4) is only used to prepare the 1389 email for signing or verifying; it does not affect the transmitted 1390 email in any way. 1392 The signer/verifier MUST compute two hashes, one over the body of the 1393 message and one over the selected header fields of the message. 1395 Signers MUST compute them in the order shown. Verifiers MAY compute 1396 them in any order convenient to the verifier, provided that the 1397 result is semantically identical to the semantics that would be the 1398 case had they been computed in this order. 1400 In hash step 1, the signer/verifier MUST hash the message body, 1401 canonicalized using the body canonicalization algorithm specified in 1402 the "c=" tag and then truncated to the length specified in the "l=" 1403 tag. That hash value is then converted to base64 form and inserted 1404 into (signers) or compared to (verifiers) the "bh=" tag of the DKIM- 1405 Signature header field. 1407 In hash step 2, the signer/verifier MUST pass the following to the 1408 hash algorithm in the indicated order. 1410 1. The header fields specified by the "h=" tag, in the order 1411 specified in that tag, and canonicalized using the header 1412 canonicalization algorithm specified in the "c=" tag. Each 1413 header field MUST be terminated with a single CRLF. 1415 2. The DKIM-Signature header field that exists (verifying) or will 1416 be inserted (signing) in the message, with the value of the "b=" 1417 tag (including all surrounding whitespace) deleted (i.e., treated 1418 as the empty string), canonicalized using the header 1419 canonicalization algorithm specified in the "c=" tag, and without 1420 a trailing CRLF. 1422 All tags and their values in the DKIM-Signature header field are 1423 included in the cryptographic hash with the sole exception of the 1424 value portion of the "b=" (signature) tag, which MUST be treated as 1425 the null string. All tags MUST be included even if they might not be 1426 understood by the verifier. The header field MUST be presented to 1427 the hash algorithm after the body of the message rather than with the 1428 rest of the header fields and MUST be canonicalized as specified in 1429 the "c=" (canonicalization) tag. The DKIM-Signature header field 1430 MUST NOT be included in its own h= tag, although other DKIM-Signature 1431 header fields MAY be signed (see Section 5). 1433 When calculating the hash on messages that will be transmitted using 1434 base64 or quoted-printable encoding, signers MUST compute the hash 1435 after the encoding. Likewise, the verifier MUST incorporate the 1436 values into the hash before decoding the base64 or quoted-printable 1437 text. However, the hash MUST be computed before transport level 1438 encodings such as SMTP "dot-stuffing" (the modification of lines 1439 beginning with a "." to avoid confusion with the SMTP end-of-message 1440 marker, as specified in [RFC5321]). 1442 With the exception of the canonicalization procedure described in 1443 Section 4.4, the DKIM signing process treats the body of messages as 1444 simply a string of octets. DKIM messages MAY be either in plain-text 1445 or in MIME format; no special treatment is afforded to MIME content. 1446 Message attachments in MIME format MUST be included in the content 1447 that is signed. 1449 More formally, pseudo-code for the signature algorithm is: 1450 body-hash = hash-alg (canon-body, l-param) 1451 data-hash = hash-alg (h-headers, D-SIG, content-hash) 1452 signature = sig-alg (d-domain, selector, data-hash) 1454 where: 1456 body-hash: is the output from hashing the body, using hash-alg. 1458 hash-alg: is the hashing algorithm specified in the "a" 1459 parameter. 1461 canon-body: is a canonicalized representation of the body, 1462 produced by using the body algorithm specified in the "c" 1463 parameter, as defined in Section 4.4 and excluding the 1464 DKIM-Signature field. 1466 l-param: is the length-of-body value of the "l" parameter. 1468 data-hash: is the output from using the hash-alg algorithm, to 1469 hash the header including the DKIM-Signature header, and the 1470 body hash. 1472 h-headers: is the list of headers to be signed, as specified in 1473 the "h" parameter. 1475 D-SIG: is the canonicalized DKIM-Signature field without the 1476 signature value portion of the parameter, itself; that is, an 1477 empty parameter value. 1479 signature: is the signature value produced by the signing 1480 algorithm. 1482 sig-alg: is the signature algorithm specified by the "a" 1483 parameter. 1485 d-domain: is the domain name specified in the "d" parameter. 1487 selector: is the selector value specified in the "s" parameter. 1489 NOTE: Many digital signature APIs provide both hashing and 1490 application of the RSA private key using a single "sign()" 1491 primitive. When using such an API, the last two steps in the 1492 algorithm would probably be combined into a single call that would 1493 perform both the "a-hash-alg" and the "sig-alg". 1495 4.8. Input Requirements 1497 DKIM's design is predicated on valid input. Therefore, signers and 1498 verifiers SHOULD take reasonable steps to ensure that the messages 1499 they are processing are valid according to [RFC5322], [RFC2045], and 1500 any other relevant message format standards. See Section 9.15 for 1501 additional discussion and references. 1503 4.9. Signing by Parent Domains 1505 In some circumstances, it is desirable for a domain to apply a 1506 signature on behalf of any of its subdomains without the need to 1507 maintain separate selectors (key records) in each subdomain. By 1508 default, private keys corresponding to key records can be used to 1509 sign messages for any subdomain of the domain in which they reside; 1510 for example, a key record for the domain example.com can be used to 1511 verify messages where the AUID ("i=" tag of the signature) is 1512 sub.example.com, or even sub1.sub2.example.com. In order to limit 1513 the capability of such keys when this is not intended, the "s" flag 1514 MAY be set in the "t=" tag of the key record, to constrain the 1515 validity of the domain of the AUID. If the referenced key record 1516 contains the "s" flag as part of the "t=" tag, the domain of the AUID 1517 ("i=" flag) MUST be the same as that of the SDID (d=) domain. If 1518 this flag is absent, the domain of the AUID MUST be the same as, or a 1519 subdomain of, the SDID. 1521 4.10. Relationship between SDID and AUID 1523 DKIM's primary task is to communicate from the Signer to a recipient- 1524 side Identity Assessor a single Signing Domain Identifier (SDID) that 1525 refers to a responsible identity. DKIM MAY optionally provide a 1526 single responsible Agent or User Identifier (AUID). 1528 Hence, DKIM's mandatory output to a receive-side Identity Assessor is 1529 a single domain name. Within the scope of its use as DKIM output, 1530 the name has only basic domain name semantics; any possible owner- 1531 specific semantics are outside the scope of DKIM. That is, within 1532 its role as a DKIM identifier, additional semantics cannot be assumed 1533 by an Identity Assessor. 1535 Upon successfully verifying the signature, a receive-side DKIM 1536 verifier MUST communicate the Signing Domain Identifier (d=) to a 1537 consuming Identity Assessor module and MAY communicate the Agent or 1538 User Identifier (i=) if present. 1540 To the extent that a receiver attempts to intuit any structured 1541 semantics for either of the identifiers, this is a heuristic function 1542 that is outside the scope of DKIM's specification and semantics. 1543 Hence, it is relegated to a higher-level service, such as a delivery 1544 handling filter that integrates a variety of inputs and performs 1545 heuristic analysis of them. 1547 INFORMATIVE DISCUSSION: This document does not require the value 1548 of the SDID or AUID to match an identifier in any other message 1549 header field. This requirement is, instead, an assessor policy 1550 issue. The purpose of such a linkage would be to authenticate the 1551 value in that other header field. This, in turn, is the basis for 1552 applying a trust assessment based on the identifier value. Trust 1553 is a broad and complex topic and trust mechanisms are subject to 1554 highly creative attacks. The real-world efficacy of any but the 1555 most basic bindings between the SDID or AUID and other identities 1556 is not well established, nor is its vulnerability to subversion by 1557 an attacker. Hence, reliance on the use of such bindings should 1558 be strictly limited. In particular, it is not at all clear to 1559 what extent a typical end-user recipient can rely on any 1560 assurances that might be made by successful use of the SDID or 1561 AUID. 1563 5. Semantics of Multiple Signatures 1565 5.1. Example Scenarios 1567 There are many reasons why a message might have multiple signatures. 1568 For example, a given signer might sign multiple times, perhaps with 1569 different hashing or signing algorithms during a transition phase. 1571 INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be 1572 insufficiently strong, and DKIM usage transitions to SHA-1024. A 1573 signer might immediately sign using the newer algorithm, but 1574 continue to sign using the older algorithm for interoperability 1575 with verifiers that had not yet upgraded. The signer would do 1576 this by adding two DKIM-Signature header fields, one using each 1577 algorithm. Older verifiers that did not recognize SHA-1024 as an 1578 acceptable algorithm would skip that signature and use the older 1579 algorithm; newer verifiers could use either signature at their 1580 option, and all other things being equal might not even attempt to 1581 verify the other signature. 1583 Similarly, a signer might sign a message including all headers and no 1584 "l=" tag (to satisfy strict verifiers) and a second time with a 1585 limited set of headers and an "l=" tag (in anticipation of possible 1586 message modifications in route to other verifiers). Verifiers could 1587 then choose which signature they preferred. 1589 INFORMATIVE EXAMPLE: A verifier might receive a message with two 1590 signatures, one covering more of the message than the other. If 1591 the signature covering more of the message verified, then the 1592 verifier could make one set of policy decisions; if that signature 1593 failed but the signature covering less of the message verified, 1594 the verifier might make a different set of policy decisions. 1596 Of course, a message might also have multiple signatures because it 1597 passed through multiple signers. A common case is expected to be 1598 that of a signed message that passes through a mailing list that also 1599 signs all messages. Assuming both of those signatures verify, a 1600 recipient might choose to accept the message if either of those 1601 signatures were known to come from trusted sources. 1603 INFORMATIVE EXAMPLE: Recipients might choose to whitelist mailing 1604 lists to which they have subscribed and that have acceptable anti- 1605 abuse policies so as to accept messages sent to that list even 1606 from unknown authors. They might also subscribe to less trusted 1607 mailing lists (e.g., those without anti-abuse protection) and be 1608 willing to accept all messages from specific authors, but insist 1609 on doing additional abuse scanning for other messages. 1611 Another related example of multiple signers might be forwarding 1612 services, such as those commonly associated with academic alumni 1613 sites. 1615 INFORMATIVE EXAMPLE: A recipient might have an address at 1616 members.example.org, a site that has anti-abuse protection that is 1617 somewhat less effective than the recipient would prefer. Such a 1618 recipient might have specific authors whose messages would be 1619 trusted absolutely, but messages from unknown authors that had 1620 passed the forwarder's scrutiny would have only medium trust. 1622 5.2. Interpretation 1624 A signer that is adding a signature to a message merely creates a new 1625 DKIM-Signature header, using the usual semantics of the h= option. A 1626 signer MAY sign previously existing DKIM-Signature header fields 1627 using the method described in Section 6.4 to sign trace header 1628 fields. 1630 INFORMATIVE NOTE: Signers should be cognizant that signing DKIM- 1631 Signature header fields may result in signature failures with 1632 intermediaries that do not recognize that DKIM-Signature header 1633 fields are trace header fields and unwittingly reorder them, thus 1634 breaking such signatures. For this reason, signing existing DKIM- 1635 Signature header fields is unadvised, albeit legal. 1637 INFORMATIVE NOTE: If a header field with multiple instances is 1638 signed, those header fields are always signed from the bottom up. 1639 Thus, it is not possible to sign only specific DKIM-Signature 1640 header fields. For example, if the message being signed already 1641 contains three DKIM-Signature header fields A, B, and C, it is 1642 possible to sign all of them, B and C only, or C only, but not A 1643 only, B only, A and B only, or A and C only. 1645 A signer MAY add more than one DKIM-Signature header field using 1646 different parameters. For example, during a transition period a 1647 signer might want to produce signatures using two different hash 1648 algorithms. 1650 Signers SHOULD NOT remove any DKIM-Signature header fields from 1651 messages they are signing, even if they know that the signatures 1652 cannot be verified. 1654 When evaluating a message with multiple signatures, a verifier SHOULD 1655 evaluate signatures independently and on their own merits. For 1656 example, a verifier that by policy chooses not to accept signatures 1657 with deprecated cryptographic algorithms would consider such 1658 signatures invalid. Verifiers MAY process signatures in any order of 1659 their choice; for example, some verifiers might choose to process 1660 signatures corresponding to the From field in the message header 1661 before other signatures. See Section 7.1 for more information about 1662 signature choices. 1664 INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate 1665 valid signatures with invalid signatures in an attempt to guess 1666 why a signature failed are ill-advised. In particular, there is 1667 no general way that a verifier can determine that an invalid 1668 signature was ever valid. 1670 Verifiers SHOULD ignore failed signatures as though they were not 1671 present in the message. Verifiers SHOULD continue to check 1672 signatures until a signature successfully verifies to the 1673 satisfaction of the verifier. To limit potential denial-of-service 1674 attacks, verifiers MAY limit the total number of signatures they will 1675 attempt to verify. 1677 6. Signer Actions 1679 The following steps are performed in order by signers. 1681 6.1. Determine Whether the Email Should Be Signed and by Whom 1683 A signer can obviously only sign email for domains for which it has a 1684 private key and the necessary knowledge of the corresponding public 1685 key and selector information. However, there are a number of other 1686 reasons beyond the lack of a private key why a signer could choose 1687 not to sign an email. 1689 INFORMATIVE NOTE: Signing modules may be incorporated into any 1690 portion of the mail system as deemed appropriate, including an 1691 MUA, a SUBMISSION server, or an MTA. Wherever implemented, 1692 signers should beware of signing (and thereby asserting 1693 responsibility for) messages that may be problematic. In 1694 particular, within a trusted enclave the signing address might be 1695 derived from the header according to local policy; SUBMISSION 1696 servers might only sign messages from users that are properly 1697 authenticated and authorized. 1699 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign 1700 Received header fields if the outgoing gateway MTA obfuscates 1701 Received header fields, for example, to hide the details of 1702 internal topology. 1704 If an email cannot be signed for some reason, it is a local policy 1705 decision as to what to do with that email. 1707 6.2. Select a Private Key and Corresponding Selector Information 1709 This specification does not define the basis by which a signer should 1710 choose which private key and selector information to use. Currently, 1711 all selectors are equal as far as this specification is concerned, so 1712 the decision should largely be a matter of administrative 1713 convenience. Distribution and management of private keys is also 1714 outside the scope of this document. 1716 INFORMATIVE OPERATIONS ADVICE: A signer should not sign with a 1717 private key when the selector containing the corresponding public 1718 key is expected to be revoked or removed before the verifier has 1719 an opportunity to validate the signature. The signer should 1720 anticipate that verifiers may choose to defer validation, perhaps 1721 until the message is actually read by the final recipient. In 1722 particular, when rotating to a new key pair, signing should 1723 immediately commence with the new private key and the old public 1724 key should be retained for a reasonable validation interval before 1725 being removed from the key server. 1727 6.3. Normalize the Message to Prevent Transport Conversions 1729 Some messages, particularly those using 8-bit characters, are subject 1730 to modification during transit, notably conversion to 7-bit form. 1731 Such conversions will break DKIM signatures. In order to minimize 1732 the chances of such breakage, signers SHOULD convert the message to a 1733 suitable MIME content transfer encoding such as quoted-printable or 1734 base64 as described in [RFC2045] before signing. Such conversion is 1735 outside the scope of DKIM; the actual message SHOULD be converted to 1736 7-bit MIME by an MUA or MSA prior to presentation to the DKIM 1737 algorithm. 1739 Similarly, a message that is not compliant with RFC5322, RFC2045 and 1740 RFC2047 can be subject to attempts by intermediaries to correct or 1741 interpret such content. See Section 8 of [RFC4409] for examples of 1742 changes that are commonly made. Such "corrections" may break DKIM 1743 signatures or have other undesirable effects. Therefore, a verifier 1744 SHOULD NOT validate a message that is not compliant with those 1745 specifications. 1747 If the message is submitted to the signer with any local encoding 1748 that will be modified before transmission, that modification to 1749 canonical [RFC5322] form MUST be done before signing. In particular, 1750 bare CR or LF characters (used by some systems as a local line 1751 separator convention) MUST be converted to the SMTP-standard CRLF 1752 sequence before the message is signed. Any conversion of this sort 1753 SHOULD be applied to the message actually sent to the recipient(s), 1754 not just to the version presented to the signing algorithm. 1756 More generally, the signer MUST sign the message as it is expected to 1757 be received by the verifier rather than in some local or internal 1758 form. 1760 6.4. Determine the Header Fields to Sign 1762 The From header field MUST be signed (that is, included in the "h=" 1763 tag of the resulting DKIM-Signature header field). Signers SHOULD 1764 NOT sign an existing header field likely to be legitimately modified 1765 or removed in transit. In particular, [RFC5321] explicitly permits 1766 modification or removal of the Return-Path header field in transit. 1767 Signers MAY include any other header fields present at the time of 1768 signing at the discretion of the signer. 1770 INFORMATIVE OPERATIONS NOTE: The choice of which header fields to 1771 sign is non-obvious. One strategy is to sign all existing, non- 1772 repeatable header fields. An alternative strategy is to sign only 1773 header fields that are likely to be displayed to or otherwise be 1774 likely to affect the processing of the message at the receiver. A 1775 third strategy is to sign only "well known" headers. Note that 1776 verifiers may treat unsigned header fields with extreme 1777 skepticism, including refusing to display them to the end user or 1778 even ignoring the signature if it does not cover certain header 1779 fields. For this reason, signing fields present in the message 1780 such as Date, Subject, Reply-To, Sender, and all MIME header 1781 fields are highly advised. 1783 The DKIM-Signature header field is always implicitly signed and MUST 1784 NOT be included in the "h=" tag except to indicate that other 1785 preexisting signatures are also signed. 1787 Signers MAY claim to have signed header fields that do not exist 1788 (that is, signers MAY include the header field name in the "h=" tag 1789 even if that header field does not exist in the message). When 1790 computing the signature, the non-existing header field MUST be 1791 treated as the null string (including the header field name, header 1792 field value, all punctuation, and the trailing CRLF). 1794 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1795 the absence of a header field; if that header field is added later 1796 the signature will fail. 1798 INFORMATIVE NOTE: A header field name need only be listed once 1799 more than the actual number of that header field in a message at 1800 the time of signing in order to prevent any further additions. 1801 For example, if there is a single Comments header field at the 1802 time of signing, listing Comments twice in the "h=" tag is 1803 sufficient to prevent any number of Comments header fields from 1804 being appended; it is not necessary (but is legal) to list 1805 Comments three or more times in the "h=" tag. 1807 Signers choosing to sign an existing header field that occurs more 1808 than once in the message (such as Received) MUST sign the physically 1809 last instance of that header field in the header block. Signers 1810 wishing to sign multiple instances of such a header field MUST 1811 include the header field name multiple times in the h= tag of the 1812 DKIM-Signature header field, and MUST sign such header fields in 1813 order from the bottom of the header field block to the top. The 1814 signer MAY include more instances of a header field name in h= than 1815 there are actual corresponding header fields to indicate that 1816 additional header fields of that name SHOULD NOT be added. 1818 INFORMATIVE EXAMPLE: 1820 If the signer wishes to sign two existing Received header fields, 1821 and the existing header contains: 1822 Received: 1823 Received: 1824 Received: 1826 then the resulting DKIM-Signature header field should read: 1828 DKIM-Signature: ... h=Received : Received :... 1829 and Received header fields and will be signed in that 1830 order. 1832 Signers should be careful of signing header fields that might have 1833 additional instances added later in the delivery process, since such 1834 header fields might be inserted after the signed instance or 1835 otherwise reordered. Trace header fields (such as Received) and 1836 Resent-* blocks are the only fields prohibited by [RFC5322] from 1837 being reordered. In particular, since DKIM-Signature header fields 1838 may be reordered by some intermediate MTAs, signing existing DKIM- 1839 Signature header fields is error-prone. 1841 INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits 1842 header fields to be reordered (with the exception of Received 1843 header fields), reordering of signed header fields with multiple 1844 instances by intermediate MTAs will cause DKIM signatures to be 1845 broken; such anti-social behavior should be avoided. 1847 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1848 specification, all end-user visible header fields should be signed 1849 to avoid possible "indirect spamming". For example, if the 1850 Subject header field is not signed, a spammer can resend a 1851 previously signed mail, replacing the legitimate subject with a 1852 one-line spam. 1854 6.5. Recommended Signature Content 1856 {DKIM 20} 1858 The purpose of the DKIM cryptographic algorithm is to affix an 1859 identifier to the message in a way that is both robust against normal 1860 transit-related changes and resistant to kinds of replay attacks. An 1861 essential aspect of satisfying these requirements is choosing what 1862 header fields to include in the hash and what fields to exclude. 1864 The basic rule for choosing fields to include is to select those 1865 fields that constitute the "core" of the message content. Hence, any 1866 replay attack will have to include these in order to have the 1867 signature succeed; but with these included, the core of the message 1868 is valid, even if sent on to new recipients. 1870 Common examples of fields with addresses and fields with textual 1871 content related to the body are: 1873 o From (REQUIRED; see Section 6.4) 1875 o Reply-To 1877 o Subject 1879 o Date 1881 o To, Cc 1883 o Resent-Date, Resent-From, Resent-To, Resent-Cc 1884 o In-Reply-To, References 1886 o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, 1887 List-Owner, List-Archive 1889 If the "l=" signature tag is in use (see Section 4.5), the Content- 1890 Type field is also a candidate for being included as it could be 1891 replaced in a way that causes completely different content to be 1892 rendered to the receiving user. 1894 Another class of fields that may be of interest are those that convey 1895 security-related information about the message, such as 1896 Authentication-Results [RFC5451]. 1898 The basic rule for choosing field to exclude is to select those 1899 fields for which there are multiple fields with the same name, and 1900 fields that are modified in transit. Examples of these are: 1902 o Return-Path 1904 o Received 1906 o Comments, Keywords 1908 Note that the DKIM-Signature field is also excluded from the header 1909 hash, because its handling is specified separately. 1911 Typically, it is better to exclude other, optional fields because of 1912 the potential that additional fields of the same name will be 1913 legitimately added or re-ordered prior to verification. There are 1914 likely to be legitimate exceptions to this rule, because of the wide 1915 variety of application-specific header fields that might be applied 1916 to a message, some of which are unlikely to be duplicated, modified, 1917 or reordered. 1919 Signers SHOULD choose canonicalization algorithms based on the types 1920 of messages they process and their aversion to risk. For example, 1921 e-commerce sites sending primarily purchase receipts, which are not 1922 expected to be processed by mailing lists or other software likely to 1923 modify messages, will generally prefer "simple" canonicalization. 1924 Sites sending primarily person-to-person email will likely prefer to 1925 be more resilient to modification during transport by using "relaxed" 1926 canonicalization. 1928 Signers SHOULD NOT use "l=" unless they intend to accommodate 1929 intermediate mail processors that append text to a message. For 1930 example, many mailing list processors append "unsubscribe" 1931 information to message bodies. If signers use "l=", they SHOULD 1932 include the entire message body existing at the time of signing in 1933 computing the count. In particular, signers SHOULD NOT specify a 1934 body length of 0 since this may be interpreted as a meaningless 1935 signature by some verifiers. 1937 6.6. Compute the Message Hash and Signature 1939 The signer MUST compute the message hash as described in Section 4.7 1940 and then sign it using the selected public-key algorithm. This will 1941 result in a DKIM-Signature header field that will include the body 1942 hash and a signature of the header hash, where that header includes 1943 the DKIM-Signature header field itself. 1945 Entities such as mailing list managers that implement DKIM and that 1946 modify the message or a header field (for example, inserting 1947 unsubscribe information) before retransmitting the message SHOULD 1948 check any existing signature on input and MUST make such 1949 modifications before re-signing the message. 1951 The signer MAY elect to limit the number of bytes of the body that 1952 will be included in the hash and hence signed. The length actually 1953 hashed should be inserted in the "l=" tag of the DKIM-Signature 1954 header field. 1956 6.7. Insert the DKIM-Signature Header Field 1958 Finally, the signer MUST insert the DKIM-Signature header field 1959 created in the previous step prior to transmitting the email. The 1960 DKIM-Signature header field MUST be the same as used to compute the 1961 hash as described above, except that the value of the "b=" tag MUST 1962 be the appropriately signed hash computed in the previous step, 1963 signed using the algorithm specified in the "a=" tag of the DKIM- 1964 Signature header field and using the private key corresponding to the 1965 selector given in the "s=" tag of the DKIM-Signature header field, as 1966 chosen above in Section 6.2 1968 The DKIM-Signature header field MUST be inserted before any other 1969 DKIM-Signature fields in the header block. 1971 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1972 is to insert the DKIM-Signature header field at the beginning of 1973 the header block. In particular, it may be placed before any 1974 existing Received header fields. This is consistent with treating 1975 DKIM-Signature as a trace header field. 1977 7. Verifier Actions 1979 Since a signer MAY remove or revoke a public key at any time, it is 1980 recommended that verification occur in a timely manner. In many 1981 configurations, the most timely place is during acceptance by the 1982 border MTA or shortly thereafter. In particular, deferring 1983 verification until the message is accessed by the end user is 1984 discouraged. 1986 A border or intermediate MTA MAY verify the message signature(s). An 1987 MTA who has performed verification MAY communicate the result of that 1988 verification by adding a verification header field to incoming 1989 messages. This considerably simplifies things for the user, who can 1990 now use an existing mail user agent. Most MUAs have the ability to 1991 filter messages based on message header fields or content; these 1992 filters would be used to implement whatever policy the user wishes 1993 with respect to unsigned mail. 1995 A verifying MTA MAY implement a policy with respect to unverifiable 1996 mail, regardless of whether or not it applies the verification header 1997 field to signed messages. 1999 Verifiers MUST produce a result that is semantically equivalent to 2000 applying the following steps in the order listed. In practice, 2001 several of these steps can be performed in parallel in order to 2002 improve performance. 2004 7.1. Extract Signatures from the Message 2006 The order in which verifiers try DKIM-Signature header fields is not 2007 defined; verifiers MAY try signatures in any order they like. For 2008 example, one implementation might try the signatures in textual 2009 order, whereas another might try signatures by identities that match 2010 the contents of the From header field before trying other signatures. 2011 Verifiers MUST NOT attribute ultimate meaning to the order of 2012 multiple DKIM-Signature header fields. In particular, there is 2013 reason to believe that some relays will reorder the header fields in 2014 potentially arbitrary ways. 2016 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 2017 a clue to signing order in the absence of any other information. 2018 However, other clues as to the semantics of multiple signatures 2019 (such as correlating the signing host with Received header fields) 2020 may also be considered. 2022 A verifier SHOULD NOT treat a message that has one or more bad 2023 signatures and no good signatures differently from a message with no 2024 signature at all; such treatment is a matter of local policy and is 2025 beyond the scope of this document. 2027 When a signature successfully verifies, a verifier will either stop 2028 processing or attempt to verify any other signatures, at the 2029 discretion of the implementation. A verifier MAY limit the number of 2030 signatures it tries to avoid denial-of-service attacks. 2032 INFORMATIVE NOTE: An attacker could send messages with large 2033 numbers of faulty signatures, each of which would require a DNS 2034 lookup and corresponding CPU time to verify the message. This 2035 could be an attack on the domain that receives the message, by 2036 slowing down the verifier by requiring it to do a large number of 2037 DNS lookups and/or signature verifications. It could also be an 2038 attack against the domains listed in the signatures, essentially 2039 by enlisting innocent verifiers in launching an attack against the 2040 DNS servers of the actual victim. 2042 In the following description, text reading "return status 2043 (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") 2044 means that the verifier MUST immediately cease processing that 2045 signature. The verifier SHOULD proceed to the next signature, if any 2046 is present, and completely ignore the bad signature. If the status 2047 is "PERMFAIL", the signature failed and should not be reconsidered. 2048 If the status is "TEMPFAIL", the signature could not be verified at 2049 this time but may be tried again later. A verifier MAY either defer 2050 the message for later processing, perhaps by queueing it locally or 2051 issuing a 451/4.7.5 SMTP reply, or try another signature; if no good 2052 signature is found and any of the signatures resulted in a TEMPFAIL 2053 status, the verifier MAY save the message for later processing. The 2054 "(explanation)" is not normative text; it is provided solely for 2055 clarification. 2057 Verifiers SHOULD ignore any DKIM-Signature header fields where the 2058 signature does not validate. Verifiers that are prepared to validate 2059 multiple signature header fields SHOULD proceed to the next signature 2060 header field, should it exist. However, verifiers MAY make note of 2061 the fact that an invalid signature was present for consideration at a 2062 later step. 2064 INFORMATIVE NOTE: The rationale of this requirement is to permit 2065 messages that have invalid signatures but also a valid signature 2066 to work. For example, a mailing list exploder might opt to leave 2067 the original submitter signature in place even though the exploder 2068 knows that it is modifying the message in some way that will break 2069 that signature, and the exploder inserts its own signature. In 2070 this case, the message should succeed even in the presence of the 2071 known-broken signature. 2073 For each signature to be validated, the following steps should be 2074 performed in such a manner as to produce a result that is 2075 semantically equivalent to performing them in the indicated order. 2077 7.1.1. Validate the Signature Header Field 2079 Implementers MUST meticulously validate the format and values in the 2080 DKIM-Signature header field; any inconsistency or unexpected values 2081 MUST cause the header field to be completely ignored and the verifier 2082 to return PERMFAIL (signature syntax error). Being "liberal in what 2083 you accept" is definitely a bad strategy in this security context. 2084 Note however that this does not include the existence of unknown tags 2085 in a DKIM-Signature header field, which are explicitly permitted. 2086 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag 2087 that is inconsistent with this specification and return PERMFAIL 2088 (incompatible version). 2090 INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, 2091 choose to also verify signatures generated by older versions of 2092 this specification. 2094 If any tag listed as "required" in Section 4.5 is omitted from the 2095 DKIM-Signature header field, the verifier MUST ignore the DKIM- 2096 Signature header field and return PERMFAIL (signature missing 2097 required tag). 2099 INFORMATIONAL NOTE: The tags listed as required in Section 4.5 are 2100 "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a 2101 conflict between this note and Section 4.5, Section 4.5 is 2102 normative. 2104 If the DKIM-Signature header field does not contain the "i=" tag, the 2105 verifier MUST behave as though the value of that tag were "@d", where 2106 "d" is the value from the "d=" tag. 2108 Verifiers MUST confirm that the domain specified in the "d=" tag is 2109 the same as or a parent domain of the domain part of the "i=" tag. 2110 If not, the DKIM-Signature header field MUST be ignored and the 2111 verifier should return PERMFAIL (domain mismatch). 2113 If the "h=" tag does not include the From header field, the verifier 2114 MUST ignore the DKIM-Signature header field and return PERMFAIL (From 2115 field not signed). 2117 Verifiers MAY ignore the DKIM-Signature header field and return 2118 PERMFAIL (signature expired) if it contains an "x=" tag and the 2119 signature has expired. 2121 Verifiers MAY ignore the DKIM-Signature header field if the domain 2122 used by the signer in the "d=" tag is not associated with a valid 2123 signing entity. For example, signatures with "d=" values such as 2124 "com" and "co.uk" may be ignored. The list of unacceptable domains 2125 SHOULD be configurable. 2127 Verifiers MAY ignore the DKIM-Signature header field and return 2128 PERMFAIL (unacceptable signature header) for any other reason, for 2129 example, if the signature does not sign header fields that the 2130 verifier views to be essential. As a case in point, if MIME header 2131 fields are not signed, certain attacks may be possible that the 2132 verifier would prefer to avoid. 2134 7.1.2. Get the Public Key 2136 The public key for a signature is needed to complete the verification 2137 process. The process of retrieving the public key depends on the 2138 query type as defined by the "q=" tag in the DKIM-Signature header 2139 field. Obviously, a public key need only be retrieved if the process 2140 of extracting the signature information is completely successful. 2141 Details of key management and representation are described in 2142 Section 4.6. The verifier MUST validate the key record and MUST 2143 ignore any public key records that are malformed. 2145 NOTE: The use of a wildcard TXT record that covers a queried DKIM 2146 domain name will produce a response to a DKIM query that is 2147 unlikely to be valid DKIM key record. This problem is not 2148 specific to DKIM and applies to many other types of queries. 2149 Client software that processes DNS responses needs to take this 2150 problem into account. 2152 When validating a message, a verifier MUST perform the following 2153 steps in a manner that is semantically the same as performing them in 2154 the order indicated -- in some cases the implementation may 2155 parallelize or reorder these steps, as long as the semantics remain 2156 unchanged: 2158 1. Retrieve the public key as described in Section 4.6 using the 2159 algorithm in the "q=" tag, the domain from the "d=" tag, and the 2160 selector from the "s=" tag. 2162 2. If the query for the public key fails to respond, the verifier 2163 MAY defer acceptance of this email and return TEMPFAIL (key 2164 unavailable). If verification is occurring during the incoming 2165 SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply 2166 code. Alternatively, the verifier MAY store the message in the 2167 local queue for later trial or ignore the signature. Note that 2168 storing a message in the local queue is subject to denial-of- 2169 service attacks. 2171 3. If the query for the public key fails because the corresponding 2172 key record does not exist, the verifier MUST immediately return 2173 PERMFAIL (no key for signature). 2175 4. If the query for the public key returns multiple key records, the 2176 verifier may choose one of the key records or may cycle through 2177 the key records performing the remainder of these steps on each 2178 record at the discretion of the implementer. The order of the 2179 key records is unspecified. If the verifier chooses to cycle 2180 through the key records, then the "return ..." wording in the 2181 remainder of this section means "try the next key record, if any; 2182 if none, return to try another signature in the usual way". 2184 5. If the result returned from the query does not adhere to the 2185 format defined in this specification, the verifier MUST ignore 2186 the key record and return PERMFAIL (key syntax error). Verifiers 2187 are urged to validate the syntax of key records carefully to 2188 avoid attempted attacks. In particular, the verifier MUST ignore 2189 keys with a version code ("v=" tag) that they do not implement. 2191 6. If the "h=" tag exists in the public key record and the hash 2192 algorithm implied by the "a=" tag in the DKIM-Signature header 2193 field is not included in the contents of the "h=" tag, the 2194 verifier MUST ignore the key record and return PERMFAIL 2195 (inappropriate hash algorithm). 2197 7. If the public key data (the "p=" tag) is empty, then this key has 2198 been revoked and the verifier MUST treat this as a failed 2199 signature check and return PERMFAIL (key revoked). There is no 2200 defined semantic difference between a key that has been revoked 2201 and a key record that has been removed. 2203 8. If the public key data is not suitable for use with the algorithm 2204 and key types defined by the "a=" and "k=" tags in the DKIM- 2205 Signature header field, the verifier MUST immediately return 2206 PERMFAIL (inappropriate key algorithm). 2208 7.1.3. Compute the Verification 2210 Given a signer and a public key, verifying a signature consists of 2211 actions semantically equivalent to the following steps. 2213 1. Based on the algorithm defined in the "c=" tag, the body length 2214 specified in the "l=" tag, and the header field names in the "h=" 2215 tag, prepare a canonicalized version of the message as is 2216 described in Section 4.7 (note that this version does not 2217 actually need to be instantiated). When matching header field 2218 names in the "h=" tag against the actual message header field, 2219 comparisons MUST be case-insensitive. 2221 2. Based on the algorithm indicated in the "a=" tag, compute the 2222 message hashes from the canonical copy as described in 2223 Section 4.7. 2225 3. Verify that the hash of the canonicalized message body computed 2226 in the previous step matches the hash value conveyed in the "bh=" 2227 tag. If the hash does not match, the verifier SHOULD ignore the 2228 signature and return PERMFAIL (body hash did not verify). 2230 4. Using the signature conveyed in the "b=" tag, verify the 2231 signature against the header hash using the mechanism appropriate 2232 for the public key algorithm described in the "a=" tag. If the 2233 signature does not validate, the verifier SHOULD ignore the 2234 signature and return PERMFAIL (signature did not verify). 2236 5. Otherwise, the signature has correctly verified. 2238 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 2239 initiate the public-key query in parallel with calculating the 2240 hash as the public key is not needed until the final decryption is 2241 calculated. Implementations may also verify the signature on the 2242 message header before validating that the message hash listed in 2243 the "bh=" tag in the DKIM-Signature header field matches that of 2244 the actual message body; however, if the body hash does not match, 2245 the entire signature must be considered to have failed. 2247 A body length specified in the "l=" tag of the signature limits the 2248 number of bytes of the body passed to the verification algorithm. 2249 All data beyond that limit is not validated by DKIM. Hence, 2250 verifiers might treat a message that contains bytes beyond the 2251 indicated body length with suspicion, such as by declaring the 2252 signature invalid (e.g., by returning PERMFAIL (unsigned content)), 2253 or conveying the partial verification to the policy module. {DKIM 2} 2255 7.2. Communicate Verification Results 2257 Verifiers wishing to communicate the results of verification to other 2258 parts of the mail system may do so in whatever manner they see fit. 2259 For example, implementations might choose to add an email header 2260 field to the message before passing it on. Any such header field 2261 SHOULD be inserted before any existing DKIM-Signature or preexisting 2262 authentication status header fields in the header field block. The 2263 Authentication-Results: header field ([RFC5451]) MAY be used for this 2264 purpose. 2266 INFORMATIVE ADVICE to MUA filter writers: Patterns intended to 2267 search for results header fields to visibly mark authenticated 2268 mail for end users should verify that such header field was added 2269 by the appropriate verifying domain and that the verified identity 2270 matches the author identity that will be displayed by the MUA. In 2271 particular, MUA filters should not be influenced by bogus results 2272 header fields added by attackers. To circumvent this attack, 2273 verifiers may wish to delete existing results header fields after 2274 verification and before adding a new header field. 2276 7.3. Interpret Results/Apply Local Policy 2278 It is beyond the scope of this specification to describe what actions 2279 an Identity Assessor can make, but mail carrying a validated SDID 2280 presents an opportunity to an Identity Assessor that unauthenticated 2281 email does not. Specifically, an authenticated email creates a 2282 predictable identifier by which other decisions can reliably be 2283 managed, such as trust and reputation. Conversely, unauthenticated 2284 email lacks a reliable identifier that can be used to assign trust 2285 and reputation. It is reasonable to treat unauthenticated email as 2286 lacking any trust and having no positive reputation. 2288 In general, verifiers SHOULD NOT reject messages solely on the basis 2289 of a lack of signature or an unverifiable signature; such rejection 2290 would cause severe interoperability problems. However, if the 2291 verifier does opt to reject such messages (for example, when 2292 communicating with a peer who, by prior agreement, agrees to only 2293 send signed messages), and the verifier runs synchronously with the 2294 SMTP session and a signature is missing or does not verify, the MTA 2295 SHOULD use a 550/5.7.x reply code. 2297 If it is not possible to fetch the public key, perhaps because the 2298 key server is not available, a temporary failure message MAY be 2299 generated using a 451/4.7.5 reply code, such as: 2300 451 4.7.5 Unable to verify signature - key server unavailable 2302 Temporary failures such as inability to access the key server or 2303 other external service are the only conditions that SHOULD use a 4xx 2304 SMTP reply code. In particular, cryptographic signature verification 2305 failures MUST NOT return 4xx SMTP replies. 2307 Once the signature has been verified, that information MUST be 2308 conveyed to the Identity Assessor (such as an explicit allow/ 2309 whitelist and reputation system) and/or to the end user. If the SDID 2310 is not the same as the address in the From: header field, the mail 2311 system SHOULD take pains to ensure that the actual SDID is clear to 2312 the reader. 2314 While the symptoms of a failed verification are obvious -- the 2315 signature doesn't verify -- establishing the exact cause can be more 2316 difficult. If a selector cannot be found, is that because the 2317 selector has been removed, or was the value changed somehow in 2318 transit? If the signature line is missing, is that because it was 2319 never there, or was it removed by an overzealous filter? For 2320 diagnostic purposes, the exact reason why the verification fails 2321 SHOULD be made available to the policy module and possibly recorded 2322 in the system logs. If the email cannot be verified, then it SHOULD 2323 be treated {DKIM 2} the same as all unverified email regardless of 2324 whether or not it looks like it was signed. 2326 8. IANA Considerations 2328 DKIM has registered namespaces with IANA. In all cases, new values 2329 are assigned only for values that have been documented in a published 2330 RFC that has IETF Consensus [RFC5226]. 2332 This memo updates these registries as described below. Of note is 2333 the addition of a new "status" column. All registrations into these 2334 namespaces MUST include the name being registered, the document in 2335 which it was registered or updated, and an indication of its current 2336 status which MUST be one of "active" (in current use) or "historic" 2337 (no longer in current use). 2339 8.1. DKIM-Signature Tag Specifications 2341 A DKIM-Signature provides for a list of tag specifications. IANA has 2342 established the DKIM-Signature Tag Specification Registry for tag 2343 specifications that can be used in DKIM-Signature fields. 2345 The updated entries in the registry comprise: 2347 +------+-----------------+--------+ 2348 | TYPE | REFERENCE | STATUS | 2349 +------+-----------------+--------+ 2350 | v | (this document) | active | 2351 | a | (this document) | active | 2352 | b | (this document) | active | 2353 | bh | (this document) | active | 2354 | c | (this document) | active | 2355 | d | (this document) | active | 2356 | h | (this document) | active | 2357 | i | (this document) | active | 2358 | l | (this document) | active | 2359 | q | (this document) | active | 2360 | s | (this document) | active | 2361 | t | (this document) | active | 2362 | x | (this document) | active | 2363 | z | (this document) | active | 2364 +------+-----------------+--------+ 2366 Table 1: DKIM-Signature Tag Specification Registry Updated Values 2368 8.2. DKIM-Signature Query Method Registry 2370 The "q=" tag-spec (specified in Section 4.5) provides for a list of 2371 query methods. 2373 IANA has established the DKIM-Signature Query Method Registry for 2374 mechanisms that can be used to retrieve the key that will permit 2375 validation processing of a message signed using DKIM. 2377 The updated entry in the registry comprises: 2379 +------+--------+-----------------+--------+ 2380 | TYPE | OPTION | REFERENCE | STATUS | 2381 +------+--------+-----------------+--------+ 2382 | dns | txt | (this document) | active | 2383 +------+--------+-----------------+--------+ 2385 DKIM-Signature Query Method Registry Updated Values 2387 8.3. DKIM-Signature Canonicalization Registry 2389 The "c=" tag-spec (specified in Section 4.5) provides for a specifier 2390 for canonicalization algorithms for the header and body of the 2391 message. 2393 IANA has established the DKIM-Signature Canonicalization Algorithm 2394 Registry for algorithms for converting a message into a canonical 2395 form before signing or verifying using DKIM. 2397 The updated entries in the header registry comprise: 2399 +---------+-----------------+--------+ 2400 | TYPE | REFERENCE | STATUS | 2401 +---------+-----------------+--------+ 2402 | simple | (this document) | active | 2403 | relaxed | (this document) | active | 2404 +---------+-----------------+--------+ 2406 DKIM-Signature Header Canonicalization Algorithm Registry 2407 Updated Values 2409 The updated entries in the body registry comprise: 2411 +---------+-----------------+--------+ 2412 | TYPE | REFERENCE | STATUS | 2413 +---------+-----------------+--------+ 2414 | simple | (this document) | active | 2415 | relaxed | (this document) | active | 2416 +---------+-----------------+--------+ 2418 DKIM-Signature Body Canonicalization Algorithm Registry 2419 Updated Values 2421 8.4. _domainkey DNS TXT Record Tag Specifications 2423 A _domainkey DNS TXT record provides for a list of tag 2424 specifications. IANA has established the DKIM _domainkey DNS TXT Tag 2425 Specification Registry for tag specifications that can be used in DNS 2426 TXT Records. 2428 The updated entries in the registry comprise: 2430 +------+-----------------+----------+ 2431 | TYPE | REFERENCE | STATUS | 2432 +------+-----------------+----------+ 2433 | v | (this document) | active | 2434 | g | [RFC4871] | historic | 2435 | h | (this document) | active | 2436 | k | (this document) | active | 2437 | n | (this document) | active | 2438 | p | (this document) | active | 2439 | s | (this document) | active | 2440 | t | (this document) | active | 2441 +------+-----------------+----------+ 2443 DKIM _domainkey DNS TXT Record Tag Specification Registry 2444 Updated Values 2446 8.5. DKIM Key Type Registry 2448 The "k=" (specified in Section 4.6.1) and the "a=" (specified in Section 4.5) tags provide for a list of 2450 mechanisms that can be used to decode a DKIM signature. 2452 IANA has established the DKIM Key Type Registry for such mechanisms. 2454 The updated entry in the registry comprises: 2456 +------+-----------+--------+ 2457 | TYPE | REFERENCE | STATUS | 2458 +------+-----------+--------+ 2459 | rsa | [RFC3447] | active | 2460 +------+-----------+--------+ 2462 DKIM Key Type Updated Values 2464 8.6. DKIM Hash Algorithms Registry 2466 The "h=" (specified in Section 4.6.1) and the "a=" (specified in Section 4.5) tags provide for a list of 2468 mechanisms that can be used to produce a digest of message data. 2470 IANA has established the DKIM Hash Algorithms Registry for such 2471 mechanisms. 2473 The updated entries in the registry comprise: 2475 +--------+-------------------+--------+ 2476 | TYPE | REFERENCE | STATUS | 2477 +--------+-------------------+--------+ 2478 | sha1 | [FIPS-180-2-2002] | active | 2479 | sha256 | [FIPS-180-2-2002] | active | 2480 +--------+-------------------+--------+ 2482 DKIM Hash Algorithms Updated Values 2484 8.7. DKIM Service Types Registry 2486 The "s=" tag (specified in Section 4.6.1) provides for a 2487 list of service types to which this selector may apply. 2489 IANA has established the DKIM Service Types Registry for service 2490 types. 2492 The updated entries in the registry comprise: 2494 +-------+-----------------+--------+ 2495 | TYPE | REFERENCE | STATUS | 2496 +-------+-----------------+--------+ 2497 | email | (this document) | active | 2498 | * | (this document) | active | 2499 +-------+-----------------+--------+ 2501 DKIM Service Types Registry Updated Values 2503 8.8. DKIM Selector Flags Registry 2505 The "t=" tag (specified in Section 4.6.1) provides for a 2506 list of flags to modify interpretation of the selector. 2508 IANA has established the DKIM Selector Flags Registry for additional 2509 flags. 2511 The updated entries in the registry comprise: 2513 +------+-----------------+--------+ 2514 | TYPE | REFERENCE | STATUS | 2515 +------+-----------------+--------+ 2516 | y | (this document) | active | 2517 | s | (this document) | active | 2518 +------+-----------------+--------+ 2520 DKIM Selector Flags Registry Updated Values 2522 8.9. DKIM-Signature Header Field 2524 IANA has added DKIM-Signature to the "Permanent Message Header 2525 Fields" registry (see [RFC3864]) for the "mail" protocol, using this 2526 document as the reference. 2528 9. Security Considerations 2530 It has been observed that any mechanism that is introduced that 2531 attempts to stem the flow of spam is subject to intensive attack. 2532 DKIM needs to be carefully scrutinized to identify potential attack 2533 vectors and the vulnerability to each. See also [RFC4686]. 2535 9.1. Misuse of Body Length Limits ("l=" Tag) 2537 Body length limits (in the form of the "l=" tag) are subject to 2538 several potential attacks. 2540 9.1.1. Addition of New MIME Parts to Multipart/* 2542 If the body length limit does not cover a closing MIME multipart 2543 section (including the trailing "--CRLF" portion), then it is 2544 possible for an attacker to intercept a properly signed multipart 2545 message and add a new body part. Depending on the details of the 2546 MIME type and the implementation of the verifying MTA and the 2547 receiving MUA, this could allow an attacker to change the information 2548 displayed to an end user from an apparently trusted source. 2550 For example, if attackers can append information to a "text/html" 2551 body part, they may be able to exploit a bug in some MUAs that 2552 continue to read after a "" marker, and thus display HTML text 2553 on top of already displayed text. If a message has a "multipart/ 2554 alternative" body part, they might be able to add a new body part 2555 that is preferred by the displaying MUA. 2557 9.1.2. Addition of new HTML content to existing content 2559 Several receiving MUA implementations do not cease display after a 2560 """" tag. In particular, this allows attacks involving 2561 overlaying images on top of existing text. 2563 INFORMATIVE EXAMPLE: Appending the following text to an existing, 2564 properly closed message will in many MUAs result in inappropriate 2565 data being rendered on top of existing, correct data: 2567
2568
2571 9.2. Misappropriated Private Key 2573 If the private key for a user is resident on their computer and is 2574 not protected by an appropriately secure mechanism, it is possible 2575 for malware to send mail as that user and any other user sharing the 2576 same private key. The malware would not, however, be able to 2577 generate signed spoofs of other signers' addresses, which would aid 2578 in identification of the infected user and would limit the 2579 possibilities for certain types of attacks involving socially 2580 engineered messages. This threat applies mainly to MUA-based 2581 implementations; protection of private keys on servers can be easily 2582 achieved through the use of specialized cryptographic hardware. 2584 A larger problem occurs if malware on many users' computers obtains 2585 the private keys for those users and transmits them via a covert 2586 channel to a site where they can be shared. The compromised users 2587 would likely not know of the misappropriation until they receive 2588 "bounce" messages from messages they are purported to have sent. 2589 Many users might not understand the significance of these bounce 2590 messages and would not take action. 2592 One countermeasure is to use a user-entered passphrase to encrypt the 2593 private key, although users tend to choose weak passphrases and often 2594 reuse them for different purposes, possibly allowing an attack 2595 against DKIM to be extended into other domains. Nevertheless, the 2596 decoded private key might be briefly available to compromise by 2597 malware when it is entered, or might be discovered via keystroke 2598 logging. The added complexity of entering a passphrase each time one 2599 sends a message would also tend to discourage the use of a secure 2600 passphrase. 2602 A somewhat more effective countermeasure is to send messages through 2603 an outgoing MTA that can authenticate the submitter using existing 2604 techniques (e.g., SMTP Authentication), possibly validate the message 2605 itself (e.g., verify that the header is legitimate and that the 2606 content passes a spam content check), and sign the message using a 2607 key appropriate for the submitter address. Such an MTA can also 2608 apply controls on the volume of outgoing mail each user is permitted 2609 to originate in order to further limit the ability of malware to 2610 generate bulk email. 2612 9.3. Key Server Denial-of-Service Attacks 2614 Since the key servers are distributed (potentially separate for each 2615 domain), the number of servers that would need to be attacked to 2616 defeat this mechanism on an Internet-wide basis is very large. 2617 Nevertheless, key servers for individual domains could be attacked, 2618 impeding the verification of messages from that domain. This is not 2619 significantly different from the ability of an attacker to deny 2620 service to the mail exchangers for a given domain, although it 2621 affects outgoing, not incoming, mail. 2623 A variation on this attack is that if a very large amount of mail 2624 were to be sent using spoofed addresses from a given domain, the key 2625 servers for that domain could be overwhelmed with requests. However, 2626 given the low overhead of verification compared with handling of the 2627 email message itself, such an attack would be difficult to mount. 2629 9.4. Attacks Against the DNS 2631 Since the DNS is a required binding for key services, specific 2632 attacks against the DNS must be considered. 2634 While the DNS is currently insecure [RFC3833], these security 2635 problems are the motivation behind DNS Security (DNSSEC) [RFC4033], 2636 and all users of the DNS will reap the benefit of that work. 2638 DKIM is only intended as a "sufficient" method of proving 2639 authenticity. It is not intended to provide strong cryptographic 2640 proof about authorship or contents. Other technologies such as 2641 OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements. 2643 A second security issue related to the DNS revolves around the 2644 increased DNS traffic as a consequence of fetching selector-based 2645 data as well as fetching signing domain policy. Widespread 2646 deployment of DKIM will result in a significant increase in DNS 2647 queries to the claimed signing domain. In the case of forgeries on a 2648 large scale, DNS servers could see a substantial increase in queries. 2650 A specific DNS security issue that should be considered by DKIM 2651 verifiers is the name chaining attack described in Section 2.3 of 2652 [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header 2653 field, could be prompted to retrieve a key record of an attacker's 2654 choosing. This threat can be minimized by ensuring that name 2655 servers, including recursive name servers, used by the verifier 2656 enforce strict checking of "glue" and other additional information in 2657 DNS responses and are therefore not vulnerable to this attack. 2659 9.5. Replay Attacks 2661 In this attack, a spammer sends a message to be spammed to an 2662 accomplice, which results in the message being signed by the 2663 originating MTA. The accomplice resends the message, including the 2664 original signature, to a large number of recipients, possibly by 2665 sending the message to many compromised machines that act as MTAs. 2666 The messages, not having been modified by the accomplice, have valid 2667 signatures. 2669 Partial solutions to this problem involve the use of reputation 2670 services to convey the fact that the specific email address is being 2671 used for spam and that messages from that signer are likely to be 2672 spam. This requires a real-time detection mechanism in order to 2673 react quickly enough. However, such measures might be prone to 2674 abuse, if for example an attacker resent a large number of messages 2675 received from a victim in order to make them appear to be a spammer. 2677 Large verifiers might be able to detect unusually large volumes of 2678 mails with the same signature in a short time period. Smaller 2679 verifiers can get substantially the same volume of information via 2680 existing collaborative systems. 2682 9.6. Limits on Revoking Keys 2684 When a large domain detects undesirable behavior on the part of one 2685 of its users, it might wish to revoke the key used to sign that 2686 user's messages in order to disavow responsibility for messages that 2687 have not yet been verified or that are the subject of a replay 2688 attack. However, the ability of the domain to do so can be limited 2689 if the same key, for scalability reasons, is used to sign messages 2690 for many other users. Mechanisms for explicitly revoking keys on a 2691 per-address basis have been proposed but require further study as to 2692 their utility and the DNS load they represent. 2694 9.7. Intentionally Malformed Key Records 2696 It is possible for an attacker to publish key records in DNS that are 2697 intentionally malformed, with the intent of causing a denial-of- 2698 service attack on a non-robust verifier implementation. The attacker 2699 could then cause a verifier to read the malformed key record by 2700 sending a message to one of its users referencing the malformed 2701 record in a (not necessarily valid) signature. Verifiers MUST 2702 thoroughly verify all key records retrieved from the DNS and be 2703 robust against intentionally as well as unintentionally malformed key 2704 records. 2706 9.8. Intentionally Malformed DKIM-Signature Header Fields 2708 Verifiers MUST be prepared to receive messages with malformed DKIM- 2709 Signature header fields, and thoroughly verify the header field 2710 before depending on any of its contents. 2712 9.9. Information Leakage 2714 An attacker could determine when a particular signature was verified 2715 by using a per-message selector and then monitoring their DNS traffic 2716 for the key lookup. This would act as the equivalent of a "web bug" 2717 for verification time rather than when the message was read. 2719 9.10. Remote Timing Attacks 2721 In some cases it may be possible to extract private keys using a 2722 remote timing attack [BONEH03]. Implementations should consider 2723 obfuscating the timing to prevent such attacks. 2725 9.11. Reordered Header Fields 2727 Existing standards allow intermediate MTAs to reorder header fields. 2728 If a signer signs two or more header fields of the same name, this 2729 can cause spurious verification errors on otherwise legitimate 2730 messages. In particular, signers that sign any existing DKIM- 2731 Signature fields run the risk of having messages incorrectly fail to 2732 verify. 2734 9.12. RSA Attacks 2736 An attacker could create a large RSA signing key with a small 2737 exponent, thus requiring that the verification key have a large 2738 exponent. This will force verifiers to use considerable computing 2739 resources to verify the signature. Verifiers might avoid this attack 2740 by refusing to verify signatures that reference selectors with public 2741 keys having unreasonable exponents. 2743 In general, an attacker might try to overwhelm a verifier by flooding 2744 it with messages requiring verification. This is similar to other 2745 MTA denial-of-service attacks and should be dealt with in a similar 2746 fashion. 2748 9.13. Inappropriate Signing by Parent Domains 2750 The trust relationship described in Section 4.9 could conceivably be 2751 used by a parent domain to sign messages with identities in a 2752 subdomain not administratively related to the parent. For example, 2753 the ".com" registry could create messages with signatures using an 2754 "i=" value in the example.com domain. There is no general solution 2755 to this problem, since the administrative cut could occur anywhere in 2756 the domain name. For example, in the domain "example.podunk.ca.us" 2757 there are three administrative cuts (podunk.ca.us, ca.us, and us), 2758 any of which could create messages with an identity in the full 2759 domain. 2761 INFORMATIVE NOTE: This is considered an acceptable risk for the 2762 same reason that it is acceptable for domain delegation. For 2763 example, in the example above any of the domains could potentially 2764 simply delegate "example.podunk.ca.us" to a server of their choice 2765 and completely replace all DNS-served information. Note that a 2766 verifier MAY ignore signatures that come from an unlikely domain 2767 such as ".com", as discussed in Section 7.1.1. 2769 9.14. Attacks Involving Addition of Header Fields 2771 Many email implementations do not enforce [RFC5322] with strictness. 2772 As discussed in Section 6.3 DKIM processing is predicated on a valid 2773 mail message as its input. However, DKIM implementers should be 2774 aware of the potential effect of having loose enforcement by email 2775 components interacting with DKIM modules. 2777 For example, a message with multiple From: header fields violates 2778 Section 3.6 of [RFC5322]. With the intent of providing a better user 2779 experience, many agents tolerate these violations and deliver the 2780 message anyway. An MUA then might elect to render to the user the 2781 value of the first {DKIM 16}, or "top", From: field. This may also 2782 be done simply out of the expectation that there is only one, where a 2783 "find first" algorithm would have the same result. Such code in an 2784 MUA can be exploited to fool the user if it is also known that the 2785 other From: field is the one checked by arriving message filters. 2786 Such is the case with DKIM; although the From: field must be signed, 2787 a malformed message bearing more than one From: field might only have 2788 the first ("bottom") one signed, in an attempt to show the message 2789 with some "DKIM passed" annotation while also rendering the From: 2790 field that was not authenticated. (This can also be taken as a 2791 demonstration that DKIM is not designed to support author 2792 validation.) 2794 Note that the technique for using "h=...:from:from:...", described in 2795 Section 9.15 below, is of no effect in the case of an attacker that 2796 is also the signer. {DKIM 16} 2798 The From: field is used above to illustrate this issue, but it is 2799 only one of several fields that Section 3.6 of [RFC5322] constrains 2800 in this way. In reality any agent that forgives such malformations 2801 {DKIM 16}, or is careless about identifying which parts of a message 2802 were authenticated, is open to exploitation. 2804 9.15. Malformed Inputs 2806 DKIM allows additional header fields to be added to a signed message 2807 without breaking the signature. This tolerance can be abused, for 2808 example in a replay attack or a man-in-the-middle attack {DKIM 16}. 2809 The attack is accomplished by creating additional instances of header 2810 fields to an already signed message, without breaking the signature. 2811 These then might be displayed to the end user or are used as 2812 filtering input. Salient fields could include From: and Subject:, 2814 The resulting message violates section 3.6 of [RFC5322]. The way 2815 such input will be handled and displayed by an MUA is unpredictable, 2816 but it will commonly {DKIM 16} display the newly added header fields 2817 rather than those that are part of the originally signed message 2818 alongside some "valid DKIM signature" annotation. This might allow 2819 an attacker to replay a previously sent, signed message with a 2820 different Subject:, From: or To: field. 2822 However, [RFC5322] also tolerates obsolete message syntax, which does 2823 allow things like multiple From: fields on messages. The 2824 implementation of DKIM thus potentially creates a more stringent 2825 layer of expectation regarding the meaning of an identity, while that 2826 additional meaning is either obscured from or incorrectly presented 2827 to an end user in this context. 2829 Implementers need to consider this possibility when designing their 2830 input handling functions. Outright rejection of messages that 2831 violate the relevant standards such as [RFC5322], [RFC2045], etc. 2832 will interfere with delivery of {DKIM 16} legacy formats. Instead, 2833 given such input, a signing module could return an error rather than 2834 generate a signature; a verifying module might return a syntax error 2835 code or arrange not to return a positive result even if the signature 2836 technically validates. 2838 Senders concerned that their messages might be particularly 2839 vulnerable to this sort of attack and who do not wish to rely on 2840 receiver filtering of invalid messages can ensure that adding 2841 additional header fields will break the DKIM signature by including 2842 two copies of the header fields about which they are concerned in the 2843 signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See 2844 Sections 3.5 and 5.4 for further discussion of this mechanism. 2846 Specific validity rules for all known header fields can be gleaned 2847 from the IANA "Permanent Header Field Registry" and the reference 2848 documents it identifies. 2850 10. References 2852 10.1. Normative References 2854 [FIPS-180-2-2002] 2855 U.S. Department of Commerce, "Secure Hash Standard", FIPS 2856 PUB 180-2, August 2002. 2858 [ITU-X660-1997] 2859 "Information Technology - ASN.1 encoding rules: 2860 Specification of Basic Encoding Rules (BER), Canonical 2861 Encoding Rules (CER) and Distinguished Encoding Rules 2862 (DER)", 1997. 2864 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 2865 RFC 1034, November 1987. 2867 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2868 Extensions (MIME) Part One: Format of Internet Message 2869 Bodies", RFC 2045, November 1996. 2871 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2872 Extensions (MIME) Part Five: Conformance Criteria and 2873 Examples", RFC 2049, November 1996. 2875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2876 Requirement Levels", BCP 14, RFC 2119, March 1997. 2878 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2879 Standards (PKCS) #1: RSA Cryptography Specifications 2880 Version 2.1", RFC 3447, February 2003. 2882 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2883 Specifications: ABNF", RFC 5234, January 2008. 2885 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2886 October 2008. 2888 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2889 October 2008. 2891 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2892 July 2009. 2894 [RFC5890] Klensin, J., "Internationalizing Domain Names in 2895 Applications (IDNA): Definitions and Document Framework", 2896 RFC 5890, August 2010. 2898 10.2. Informative References 2900 [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th 2901 USENIX Security Symposium, 2003. 2903 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 2904 "Security Multiparts for MIME: Multipart/Signed and 2905 Multipart/Encrypted", RFC 1847, October 1995. 2907 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 2908 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 2909 RFC 3766, April 2004. 2911 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2912 Name System (DNS)", RFC 3833, August 2004. 2914 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2915 Procedures for Message Header Fields", BCP 90, RFC 3864, 2916 September 2004. 2918 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2919 Rose, "DNS Security Introduction and Requirements", 2920 RFC 4033, March 2005. 2922 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2923 RFC 4409, April 2006. 2925 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 2926 Identified Mail (DKIM)", RFC 4686, September 2006. 2928 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 2929 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 2930 May 2007. 2932 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 2933 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 2934 Signatures", RFC 4871, May 2007. 2936 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 2937 "OpenPGP Message Format", RFC 4880, November 2007. 2939 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2940 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2941 May 2008. 2943 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 2944 Message Authentication Status", RFC 5451, April 2009. 2946 [RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail 2947 Extensions (S/MIME) Version 3.1 Message Specification", 2948 RFC 5751, January 2010. 2950 Appendix A. Example of Use (INFORMATIVE) 2952 This section shows the complete flow of an email from submission to 2953 final delivery, demonstrating how the various components fit 2954 together. The key used in this example is shown in Appendix C. 2956 A.1. The User Composes an Email 2957 From: Joe SixPack 2958 To: Suzie Q 2959 Subject: Is dinner ready? 2960 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2961 Message-ID: <;20030712040037.46341.5F8J@football.example.com> 2963 Hi. 2965 We lost the game. Are you hungry yet? 2967 Joe. 2969 Figure 1: The User Composes an Email 2971 A.2. The Email is Signed 2973 This email is signed by the example.com outbound email server and now 2974 looks like this: 2975 DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; 2976 c=simple/simple; q=dns/txt; i=joe@football.example.com; 2977 h=Received : From : To : Subject : Date : Message-ID; 2978 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 2979 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 2980 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 2981 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 2982 4bmp/YzhwvcubU4=; 2983 Received: from client1.football.example.com [192.0.2.1] 2984 by submitserver.example.com with SUBMISSION; 2985 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2986 From: Joe SixPack 2987 To: Suzie Q 2988 Subject: Is dinner ready? 2989 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2990 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2992 Hi. 2994 We lost the game. Are you hungry yet? 2996 Joe. 2998 The Email is Signed 3000 The signing email server requires access to the private key 3001 associated with the "brisbane" selector to generate this signature. 3003 A.3. The Email Signature is Verified 3005 The signature is normally verified by an inbound SMTP server or 3006 possibly the final delivery agent. However, intervening MTAs can 3007 also perform this verification if they choose to do so. The 3008 verification process uses the domain "example.com" extracted from the 3009 "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- 3010 Signature header field to form the DNS DKIM query for: 3011 brisbane._domainkey.example.com 3013 Signature verification starts with the physically last Received 3014 header field, the From header field, and so forth, in the order 3015 listed in the "h=" tag. Verification follows with a single CRLF 3016 followed by the body (starting with "Hi."). The email is canonically 3017 prepared for verifying with the "simple" method. The result of the 3018 query and subsequent verification of the signature is stored (in this 3019 example) in the X-Authentication-Results header field line. After 3020 successful verification, the email looks like this: 3021 X-Authentication-Results: shopping.example.net 3022 header.from=joe@football.example.com; dkim=pass 3023 Received: from mout23.football.example.com (192.168.1.1) 3024 by shopping.example.net with SMTP; 3025 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 3026 DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; 3027 c=simple/simple; q=dns/txt; i=joe@football.example.com; 3028 h=Received : From : To : Subject : Date : Message-ID; 3029 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 3030 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 3031 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 3032 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 3033 4bmp/YzhwvcubU4=; 3034 Received: from client1.football.example.com [192.0.2.1] 3035 by submitserver.example.com with SUBMISSION; 3036 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 3037 From: Joe SixPack 3038 To: Suzie Q 3039 Subject: Is dinner ready? 3040 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 3041 Message-ID: <20030712040037.46341.5F8J@football.example.com> 3043 Hi. 3045 We lost the game. Are you hungry yet? 3047 Joe. 3049 Successful verification 3051 Appendix B. Usage Examples (INFORMATIVE) 3053 DKIM signing and validating can be used in different ways, for 3054 different operational scenarios. This Appendix discusses some common 3055 examples. 3057 NOTE: Descriptions in this Appendix are for informational purposes 3058 only. They describe various ways that DKIM can be used, given 3059 particular constraints and needs. In no case are these examples 3060 intended to be taken as providing explanation or guidance 3061 concerning DKIM specification details, when creating an 3062 implementation. 3064 B.1. Alternate Submission Scenarios 3066 In the most simple scenario, a user's MUA, MSA, and Internet 3067 (boundary) MTA are all within the same administrative environment, 3068 using the same domain name. Therefore, all of the components 3069 involved in submission and initial transfer are related. However, it 3070 is common for two or more of the components to be under independent 3071 administrative control. This creates challenges for choosing and 3072 administering the domain name to use for signing, and for its 3073 relationship to common email identity header fields. 3075 B.1.1. Delegated Business Functions 3077 Some organizations assign specific business functions to discrete 3078 groups, inside or outside the organization. The goal, then, is to 3079 authorize that group to sign some mail, but to constrain what 3080 signatures they can generate. DKIM selectors (the "s=" signature 3081 tag) facilitate this kind of restricted authorization. Examples of 3082 these outsourced business functions are legitimate email marketing 3083 providers and corporate benefits providers. 3085 Here, the delegated group needs to be able to send messages that are 3086 signed, using the email domain of the client company. At the same 3087 time, the client often is reluctant to register a key for the 3088 provider that grants the ability to send messages for arbitrary 3089 addresses in the domain. 3091 There are multiple ways to administer these usage scenarios. In one 3092 case, the client organization provides all of the public query 3093 service (for example, DNS) administration, and in another it uses DNS 3094 delegation to enable all ongoing administration of the DKIM key 3095 record by the delegated group. 3097 If the client organization retains responsibility for all of the DNS 3098 administration, the outsourcing company can generate a key pair, 3099 supplying the public key to the client company, which then registers 3100 it in the query service, using a unique selector. The client company 3101 retains control over the use of the delegated key because it retains 3102 the ability to revoke the key at any time. 3104 If the client wants the delegated group to do the DNS administration, 3105 it can have the domain name that is specified with the selector point 3106 to the provider's DNS server. The provider then creates and 3107 maintains all of the DKIM signature information for that selector. 3108 Hence, the client cannot provide constraints on the Local-part of 3109 addresses that get signed, but it can revoke the provider's signing 3110 rights by removing the DNS delegation record. 3112 B.1.2. PDAs and Similar Devices 3114 PDAs demonstrate the need for using multiple keys per domain. 3115 Suppose that John Doe wanted to be able to send messages using his 3116 corporate email address, jdoe@example.com, and his email device did 3117 not have the ability to make a Virtual Private Network (VPN) 3118 connection to the corporate network, either because the device is 3119 limited or because there are restrictions enforced by his Internet 3120 access provider. If the device was equipped with a private key 3121 registered for jdoe@example.com by the administrator of the 3122 example.com domain, and appropriate software to sign messages, John 3123 could sign the message on the device itself before transmission 3124 through the outgoing network of the access service provider. 3126 B.1.3. Roaming Users 3128 Roaming users often find themselves in circumstances where it is 3129 convenient or necessary to use an SMTP server other than their home 3130 server; examples are conferences and many hotels. In such 3131 circumstances, a signature that is added by the submission service 3132 will use an identity that is different from the user's home system. 3134 Ideally, roaming users would connect back to their home server using 3135 either a VPN or a SUBMISSION server running with SMTP AUTHentication 3136 on port 587. If the signing can be performed on the roaming user's 3137 laptop, then they can sign before submission, although the risk of 3138 further modification is high. If neither of these are possible, 3139 these roaming users will not be able to send mail signed using their 3140 own domain key. 3142 B.1.4. Independent (Kiosk) Message Submission 3144 Stand-alone services, such as walk-up kiosks and web-based 3145 information services, have no enduring email service relationship 3146 with the user, but users occasionally request that mail be sent on 3147 their behalf. For example, a website providing news often allows the 3148 reader to forward a copy of the article to a friend. This is 3149 typically done using the reader's own email address, to indicate who 3150 the author is. This is sometimes referred to as the "Evite problem", 3151 named after the website of the same name that allows a user to send 3152 invitations to friends. 3154 A common way this is handled is to continue to put the reader's email 3155 address in the From header field of the message, but put an address 3156 owned by the email posting site into the Sender header field. The 3157 posting site can then sign the message, using the domain that is in 3158 the Sender field. This provides useful information to the receiving 3159 email site, which is able to correlate the signing domain with the 3160 initial submission email role. 3162 Receiving sites often wish to provide their end users with 3163 information about mail that is mediated in this fashion. Although 3164 the real efficacy of different approaches is a subject for human 3165 factors usability research, one technique that is used is for the 3166 verifying system to rewrite the From header field, to indicate the 3167 address that was verified. For example: From: John Doe via 3168 news@news-site.com . (Note that such rewriting 3169 will break a signature, unless it is done after the verification pass 3170 is complete.) 3172 B.2. Alternate Delivery Scenarios 3174 Email is often received at a mailbox that has an address different 3175 from the one used during initial submission. In these cases, an 3176 intermediary mechanism operates at the address originally used and it 3177 then passes the message on to the final destination. This mediation 3178 process presents some challenges for DKIM signatures. 3180 B.2.1. Affinity Addresses 3182 "Affinity addresses" allow a user to have an email address that 3183 remains stable, even as the user moves among different email 3184 providers. They are typically associated with college alumni 3185 associations, professional organizations, and recreational 3186 organizations with which they expect to have a long-term 3187 relationship. These domains usually provide forwarding of incoming 3188 email, and they often have an associated Web application that 3189 authenticates the user and allows the forwarding address to be 3190 changed. However, these services usually depend on users sending 3191 outgoing messages through their own service providers' MTAs. Hence, 3192 mail that is signed with the domain of the affinity address is not 3193 signed by an entity that is administered by the organization owning 3194 that domain. 3196 With DKIM, affinity domains could use the Web application to allow 3197 users to register per-user keys to be used to sign messages on behalf 3198 of their affinity address. The user would take away the secret half 3199 of the key pair for signing, and the affinity domain would publish 3200 the public half in DNS for access by verifiers. 3202 This is another application that takes advantage of user-level 3203 keying, and domains used for affinity addresses would typically have 3204 a very large number of user-level keys. Alternatively, the affinity 3205 domain could handle outgoing mail, operating a mail submission agent 3206 that authenticates users before accepting and signing messages for 3207 them. This is of course dependent on the user's service provider not 3208 blocking the relevant TCP ports used for mail submission. 3210 B.2.2. Simple Address Aliasing (.forward) 3212 In some cases a recipient is allowed to configure an email address to 3213 cause automatic redirection of email messages from the original 3214 address to another, such as through the use of a Unix .forward file. 3215 In this case, messages are typically redirected by the mail handling 3216 service of the recipient's domain, without modification, except for 3217 the addition of a Received header field to the message and a change 3218 in the envelope recipient address. In this case, the recipient at 3219 the final address' mailbox is likely to be able to verify the 3220 original signature since the signed content has not changed, and DKIM 3221 is able to validate the message signature. 3223 B.2.3. Mailing Lists and Re-Posters 3225 There is a wide range of behaviors in services that take delivery of 3226 a message and then resubmit it. A primary example is with mailing 3227 lists (collectively called "forwarders" below), ranging from those 3228 that make no modification to the message itself, other than to add a 3229 Received header field and change the envelope information, to those 3230 that add header fields, change the Subject header field, add content 3231 to the body (typically at the end), or reformat the body in some 3232 manner. The simple ones produce messages that are quite similar to 3233 the automated alias services. More elaborate systems essentially 3234 create a new message. 3236 A Forwarder that does not modify the body or signed header fields of 3237 a message is likely to maintain the validity of the existing 3238 signature. It also could choose to add its own signature to the 3239 message. 3241 Forwarders which modify a message in a way that could make an 3242 existing signature invalid are particularly good candidates for 3243 adding their own signatures (e.g., mailing-list-name@example.net). 3245 Since (re-)signing is taking responsibility for the content of the 3246 message, these signing forwarders are likely to be selective, and 3247 forward or re-sign a message only if it is received with a valid 3248 signature or if they have some other basis for knowing that the 3249 message is not spoofed. 3251 A common practice among systems that are primarily redistributors of 3252 mail is to add a Sender header field to the message, to identify the 3253 address being used to sign the message. This practice will remove 3254 any preexisting Sender header field as required by [RFC5322]. The 3255 forwarder applies a new DKIM-Signature header field with the 3256 signature, public key, and related information of the forwarder. 3258 Appendix C. Creating a Public Key (INFORMATIVE) 3260 The default signature is an RSA signed SHA256 digest of the complete 3261 email. For ease of explanation, the openssl command is used to 3262 describe the mechanism by which keys and signatures are managed. One 3263 way to generate a 1024-bit, unencrypted private key suitable for DKIM 3264 is to use openssl like this: 3265 $ openssl genrsa -out rsa.private 1024 3266 For increased security, the "-passin" parameter can also be added to 3267 encrypt the private key. Use of this parameter will require entering 3268 a password for several of the following steps. Servers may prefer to 3269 use hardware cryptographic support. 3271 The "genrsa" step results in the file rsa.private containing the key 3272 information similar to this: 3273 -----BEGIN RSA PRIVATE KEY----- 3274 MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC 3275 jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb 3276 to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB 3277 AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX 3278 /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ 3279 gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO 3280 n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 3281 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ 3282 eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 3283 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA 3284 qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf 3285 eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX 3286 GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= 3287 -----END RSA PRIVATE KEY----- 3288 To extract the public-key component from the private key, use openssl 3289 like this: 3290 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM 3292 This results in the file rsa.public containing the key information 3293 similar to this: 3294 -----BEGIN PUBLIC KEY----- 3295 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM 3296 oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R 3297 tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI 3298 MmPSPDdQPNUYckcQ2QIDAQAB 3299 -----END PUBLIC KEY----- 3301 This public-key data (without the BEGIN and END tags) is placed in 3302 the DNS: 3303 $ORIGIN _domainkey.example.org. {DKIM 10} 3304 brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" 3305 "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" 3306 "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" 3307 "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" 3308 "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") 3310 C.1. Compatibility with DomainKeys Key Records 3312 DKIM key records were designed to be backwards-compatible in many 3313 cases with key records used by DomainKeys [RFC4870] (sometimes 3314 referred to as "selector records" in the DomainKeys context). One 3315 area of incompatibility warrants particular attention. The "g=" tag/ 3316 value may be used in DomainKeys and [RFC4871] key records to provide 3317 finer granularity of the validity of the key record to a specific 3318 local-part. A null "g=" value in DomainKeys is valid for all 3319 addresses in the domain. This differs from the usage in the original 3320 DKIM specification, where a null "g=" value is not valid for any 3321 address. In particular, the example public key record in Section 3322 3.2.3 of [RFC4870] with DKIM. 3324 Although the "g=" tag has been deprecated in this version of the DKIM 3325 specification, signers are advised not to include the "g=" tag in key 3326 records because some [RFC4871]-compliant verifiers will be in use for 3327 a considerable period to come. 3329 Appendix D. MUA Considerations 3331 When a DKIM signature is verified, the processing system sometimes 3332 makes the result available to the recipient user's MUA. How to 3333 present this information to the user in a way that helps them is a 3334 matter of continuing human factors usability research. The tendency 3335 is to have the MUA highlight the SDID, in an attempt to show the user 3336 the identity that is claiming responsibility for the message. An MUA 3337 might do this with visual cues such as graphics, or it might include 3338 the address in an alternate view, or it might even rewrite the 3339 original From address using the verified information. Some MUAs 3340 might indicate which header fields were protected by the validated 3341 DKIM signature. This could be done with a positive indication on the 3342 signed header fields, with a negative indication on the unsigned 3343 header fields, by visually hiding the unsigned header fields, or some 3344 combination of these. If an MUA uses visual indications for signed 3345 header fields, the MUA probably needs to be careful not to display 3346 unsigned header fields in a way that might be construed by the end 3347 user as having been signed. If the message has an l= tag whose value 3348 does not extend to the end of the message, the MUA might also hide or 3349 mark the portion of the message body that was not signed. 3351 The aforementioned information is not intended to be exhaustive. The 3352 MUA may choose to highlight, accentuate, hide, or otherwise display 3353 any other information that may, in the opinion of the MUA author, be 3354 deemed important to the end user. 3356 Appendix E. Acknowledgements 3358 The previous IETF version of DKIM [RFC4871] was edited by: Eric 3359 Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael 3360 Thomas. 3362 That specification was the result of an extended, collaborative 3363 effort, including participation by: Russ Allbery, Edwin Aoki, Claus 3364 Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve 3365 Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis 3366 Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark 3367 Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur 3368 Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, 3369 Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig 3370 Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. 3371 Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon 3372 Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, 3373 Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, 3374 Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, 3375 Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector 3376 Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert 3377 Sanders, Rand Wacker, Sam Weiler, and Dan Wing. 3379 The earlier DomainKeys was a primary source from which DKIM was 3380 derived. Further information about DomainKeys is at [RFC4870]. 3382 Authors' Addresses 3384 D. Crocker (editor) 3385 Brandenburg InternetWorking 3386 675 Spruce Dr. 3387 Sunnyvale 3388 USA 3390 Phone: +1.408.246.8253 3391 Email: dcrocker@bbiw.net 3392 URI: http://bbiw.net 3394 Tony Hansen (editor) 3395 AT&T Laboratories 3396 200 Laurel Ave. South 3397 Middletown, NJ 07748 3398 USA 3400 Email: tony+dkimov@maillennium.att.com 3402 M. Kucherawy (editor) 3403 Cloudmark 3404 128 King St., 2nd Floor 3405 San Francisco, CA 94107 3406 USA 3408 Email: msk@cloudmark.com