idnits 2.17.1 draft-kucherawy-dkim-atps-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2012) is 4494 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 330, but not defined == Missing Reference: 'THIS MEMO' is mentioned on line 508, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark, Inc. 4 Intended status: Experimental January 5, 2012 5 Expires: July 8, 2012 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-16 10 Abstract 12 This experimental specification proposes a modification to Domain 13 Keys Identified Mail (DKIM) allowing advertisement of third-party 14 signature authorizations that are to be interpreted as equivalent to 15 a signature added by the administrative domain of the message's 16 author. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 8, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . 3 56 3. Roles and Scope . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Queries and Replies . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Hash Selection . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Extension to DKIM . . . . . . . . . . . . . . . . . . . . 5 60 4.3. ATPS Query Details . . . . . . . . . . . . . . . . . . . . 5 61 4.4. ATPS Reply Details . . . . . . . . . . . . . . . . . . . . 7 62 5. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 8 64 7. Experiment Process . . . . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 9 67 8.2. Email Authentication Method Name Registry Update . . . . . 10 68 8.3. Email Authentication Result Name Registry Update . . . . . 10 69 8.4. DKIM-Signature Tag Specification Registry . . . . . . . . 11 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9.1. Hash Selection . . . . . . . . . . . . . . . . . . . . . . 12 72 9.2. False Privacy . . . . . . . . . . . . . . . . . . . . . . 12 73 9.3. Transient Security Failures . . . . . . . . . . . . . . . 12 74 9.4. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 13 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 78 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 14 79 Appendix B. Choice of DNS RR Type . . . . . . . . . . . . . . . . 15 80 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 [DKIM] defines a mechanism for transparent domain-level signing of 85 messages for the purpose of declaring that a particular 86 Administrative Mail Domain (ADMD) takes some responsibility for a 87 message. 89 DKIM, however, deliberately makes no binding between the DNS domain 90 of the signer and any other identity found in the message. Despite 91 this, there is an automatic human perception that an author domain 92 signature (one for which the RFC5322.From domain matches the DNS 93 domain of the signer) is more valuable or trustworthy than any other. 95 To enable a third party to apply DKIM signatures to messages, the 96 DKIM specification suggests delegation to a third party of either 97 subdomains or private keys, so that the third party can add DKIM 98 signatures that appear to have been added by the Author ADMD. Absent 99 is a protocol by which an Author ADMD can announce that messages 100 bearing specific valid DKIM signatures on its mail, which are added 101 by other ADMDs, are to be treated as if they were signed by the 102 Author ADMD itself. This memo presents an experimental mechanism for 103 doing so, called Authorized Third-Party Signers (ATPS). 105 ATPS augments the semantics of DKIM by providing to the verifier 106 multiple identifiers rather than one. Specifically, it validates the 107 identifier found in the DKIM signature, and then provides the 108 RFC5322.From domain for evaluation. 110 This memo also registers, per [AUTHRES], the means to indicate to 111 agents downstream of the Verifier that a third-party signature 112 verification occurred. 114 2. Definitions 116 2.1. Keywords 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [KEYWORDS]. 122 2.2. E-Mail Architecture Terminology 124 Readers are advised to be familiar with the material and terminology 125 discussed in [MAIL] and [EMAIL-ARCH]. 127 3. Roles and Scope 129 The context of this protocol involves the following roles: 131 o ADministrative Mail Domain (ADMD)s, whose DNS domain name(s) 132 appear in the RFC5322.From field of a [MAIL] message; 134 o ATPS Signers, which apply [DKIM] signatures using their own 135 domains, but on behalf of the message Author's ADMD; and 137 o the Verifier, who implements the signature validation procedures 138 described in [DKIM]. 140 An ADMD implements this protocol if it wishes to announce that a 141 signature from any in a set of specified DNS domains is to be 142 considered equivalent to one from the ADMD itself. One might, for 143 example, wish to delegate signing authority for its DNS domain to an 144 approved messaging service provider without doing the work of key 145 transfer described in Appendix B.1.1 of [DKIM]. An authorized ATPS 146 Signer makes a claim of this relationship via new tags in the DKIM 147 signature, and the ADMD confirms this claim by publishing a specific 148 TXT record in its DNS. 150 A Verifier implements this protocol if it wishes to ensure that a 151 message bears one or more signatures from sources authorized to sign 152 mail on behalf of the ADMD, and identify for special treatment mail 153 that meets (or does not meet) that criterion. It will do so by 154 treating the signer's authorization on behalf of the author's ADMD to 155 mean that the signer's signature is equivalent to one affixed by the 156 author's ADMD. 158 4. Queries and Replies 160 This section describes in detail the queries issued, the replies 161 received, and how they should be interpreted and applied. 163 4.1. Hash Selection 165 The author's ADMD will indicate authorization of a third party to 166 sign its mail via the presence of a DNS TXT record that contains an 167 encoding of the third party's DNS domain name. There are two 168 supported methods for doing so, one that involves a plain copy of the 169 third party's DNS domain name, and one that involves an encoded 170 version of the name. The encoding mechanism is provided so that any 171 domain name can be added to the DNS in a fixed length, so that longer 172 third-party domain names are not excluded from participation because 173 of the overall length limit on a DNS query. 175 If selected, the encoding mechanism requires constructing a digest of 176 the third party's DNS domain name. The author ADMD MUST select a 177 digest ("hash") method currently supported by DKIM (see Section 7.7 178 of [DKIM]), and this selection needs to be communicated to the ATPS 179 Signer as it is used in generation of its the third party signatures. 181 Where the encoding mechanism is not used, the ATPS Signer MUST use a 182 hash name of "none". 184 The full DNS mechanism is specified in Section 4.3. 186 4.2. Extension to DKIM 188 [DKIM] signatures contain a "tag=value" sequence. This protocol will 189 add additional tags called "atps" and "atpsh". 191 When the ATPS Signer generates a DKIM signature for another ADMD, it 192 MUST put its own domain in the signature's "d" tag, and include an 193 "atps" tag that has as its value the domain name of the ADMD on whose 194 behalf it is signing. 196 The tag name that carries the name of the selected hash algorithm is 197 "atpsh". This tag MUST also be included, as it is required as part 198 of the algorithm that will be enacted by the Verifier. 200 The formal syntax definition, per [ABNF]: 202 dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name 204 dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP 205 ( "none" / key-h-tag-alg ) 207 "domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that 208 according to [DKIM], internationalized domain names are to be encoded 209 as A-labels, as described in Section 2.3 of [IDNA]. 211 The registration for these tags can be found in Section 8. 213 4.3. ATPS Query Details 215 When a [DKIM] signature including an "atps" tag is successfully 216 verified, and is considered acceptable to the Verifier according to 217 any local policy requirements (which are not discussed here or in 218 [DKIM]), the Verifier compares the domain name in the value of that 219 tag with the one found in the RFC5322.From field of the message. The 220 match MUST be done in a case-insensitive manner. 222 If they do not match, the "atps" tag MUST be ignored. 224 If they do match, the Verifier issues a DNS TXT query, as specified 225 below, looking for confirmation by the Author ADMD that the ATPS 226 Signer is authorized by that ADMD to sign mail on its behalf. Where 227 multiple DKIM signatures are present including valid "atps" tags, 228 these queries MAY be done in any order or MAY be done in parallel. 230 Where the RFC5322.From field contains multiple addresses, this 231 process SHOULD be applied if the "atps" tag's value matches any of 232 the domains found in that field. These MAY be done in any order. 234 Note that the algorithm uses hashing, but this is not a security 235 mechanism. See Section 9.2 for discussion. 237 The name for the query is constructed as follows: 239 1. Select the hash algorithm from the "atpsh" tag in the signature. 240 If the hash algorithm specified does not appear in the list 241 registered with IANA as one valid for use with DKIM (see Section 242 7.7 of [DKIM]), and is not the reserved name "none" as described 243 above, abort the query. 245 2. Extract the value of the "d=" tag from the signature. 247 3. Convert any upper-case characters in that string to their lower- 248 case equivalents. 250 4. If the selected hash algorithm is not "none", apply the following 251 additional steps: 253 A. Feed the resulting string to the selected hash algorithm. 255 B. Convert the output of the hash to a string of printable ASCII 256 characters by applying base32 encoding as defined in Section 257 6 of [BASE32]. The base32 encoding is used because its 258 output is restricted to characters that are legal for use in 259 labels in the DNS, and evaluates the same way in the DNS 260 whether encoded using uppercase or lowercase characters. 262 5. Append the string "._atps." 264 6. Append the domain name found in the "atps" tag of the validated 265 signature. 267 The query's formal syntax definition, per [ABNF]: 269 atps-query = ( 1*63BASE32 / domain-name ) 270 %x2e.5f.61.74.70.73.2e domain-name 272 BASE32 = ( ALPHA / %x32-37 ) 274 The width limit of 63 on the base32 encoding is based on the maximum 275 label limit found in Section 2.3.4 of [DNS]. 277 See Appendix A for an example of a query construction. 279 4.4. ATPS Reply Details 281 In the descriptions below, the label NOERROR symbolizes DNS response 282 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 283 of [DNS] for further details. 285 At this time, only three possibilities need to be identified in this 286 specification: 288 o An answer is returned (i.e. [DNS] reply code NOERROR with at 289 least one answer) containing a valid ATPS reply. In this case, 290 the protocol has been satisfied and the Verifier can conclude that 291 the signing domain is authorized by the ADMD to sign its mail. 292 Further queries SHOULD NOT be initiated. 294 o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR 295 with no answers), or one or more answers have been returned as 296 described above but none contain a valid ATPS reply. In this 297 case, the Signer has not been authorized to act as a third-party 298 signer for this ADMD, and thus the Verifier MUST continue to the 299 next query, if any. 301 o An error is returned (i.e. any other [DNS] reply code). It is no 302 longer possible to determine whether or not this message satisfies 303 the ADMD's list of authorized third-party signers. The Verifier 304 SHOULD stop processing and defer the message for later processing, 305 such as requesting temporary failure code from the MTA. 307 If all queries are completed and return either NXDOMAIN or NOERROR 308 with no answers, then the Signer was not authorized by the ADMD. 310 A valid ATPS reply consists of a sequence of tag-value pairs as 311 described in Section 3.2 of [DKIM]. The following tags and values 312 are currently supported in ATPS records: 314 d: Domain (plain-text; RECOMMENDED) This tag includes a plain-text 315 copy of the DNS domain being authorized as an ATPS Signer. This 316 is included to assist with collision detections; for example, if 317 the base32 encoding of this name is not the same as the base32 318 portion of the query, or more simply if this name is not the same 319 as that found in the "atps" tag, a hash collision could have 320 occurred. Its use where no name hashing has occurred is 321 redundant. ABNF: 323 atps-d-tag = %x64 [FWS] "=" [FWS] domain-name 324 ; FWS is defined in [DKIM] 326 v: Version (plain-text; REQUIRED) This tag defines the version of 327 this specification that applies to the ATPS record. The record 328 MUST be ignored if the value is not "ATPS1". ABNF: 330 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 331 ; FWS is defined in [DKIM] 333 5. Interpretation 335 For each DKIM signature that verifies (see Section 6 of [DKIM]), if a 336 Verifier succeeds in confirming that the Author's ADMD authorized the 337 ATPS Signer using this protocol, then the Verifier SHOULD evaluate 338 the message as though it contained a valid signature from the 339 Author's ADMD. It MAY also independently evaluate the ATPS Signer 340 when determining message disposition. 342 This assertion is based on the fact that the ADMD explicitly endorsed 343 the ATPS Signer. Therefore, a module assessing reputation that is 344 based on DKIM signature verification SHOULD apply the reputation of 345 the Author's ADMD domain instead of, or in addition to, that of the 346 ATPS Signer domain. 348 6. Relationship to ADSP 350 [ADSP] defined a protocol by which the owner of an Author Domain can 351 advertise a request to message receivers that messages bearing no 352 valid author signature be treated with suspicion or even discarded. 354 A Verifier implementing both ADSP and ATPS MUST test ATPS first. If 355 ATPS indicates a valid delegation, the verifier MUST act, with 356 respect to ADSP, as though the message has a valid Author Domain 357 Signature (because that's what the delegation means), and no ADSP 358 test is required. 360 7. Experiment Process 362 The working group that developed DKIM considered a third-party 363 mechanism such as this one to be controversial, in terms of need and 364 practicality, and decided that an alternative mechanism was suffient. 365 However, this was not based on actual experience as there is no 366 specific history on this question. Thus, this experiment was 367 devised. 369 The experimental protocol described here has been implemented as an 370 extension to DKIM in two software products, one of which is open 371 source and seeing increasingly wide use. It is included there to 372 allow customers of those systems to make use of it if they believe 373 such third party assertions are useful to the overall DKIM mechanism. 374 Further adoption as part of the experiment is welcome and encouraged. 376 Use of the protocol and anecdotes of how it affects the overall DKIM 377 experience will be collected by those implementers and the author of 378 this memo. Those participating in the experiment are also advised to 379 observe and report the impact of what is discussed in Section 9.4, 380 especially with respect to MTA latency that may be introduced. 382 If the response is substantial and positive, advancement along the 383 Standards Track might be warranted. 385 8. IANA Considerations 387 This section enumerates requested IANA actions. 389 8.1. ATPS Tag Registry 391 IANA is directed to create an Authorized Third Party Signature (ATPS) 392 Tag Registry, under the DomainKeys Identified Mail (DKIM) Parameters 393 group, to enumerate the tags that are valid for use in ATPS records. 395 New registrations or updates MUST be published in accordance with the 396 "Specification Required" guidelines described in [IANA]. Such 397 registry changes MUST contain the following information: 399 1. Name of the tag being registered or updated 401 2. The document where the specification is created or updated 403 3. The status of the tag, one of "current" (tag is in current use), 404 "deprecated" (tag is in current use but its use is discouraged), 405 or "historic" (tag is no longer in use) 407 The registry's sole initial entry is: 409 +-----+--------------+---------+ 410 | Tag | Specified In | Status | 411 +-----+--------------+---------+ 412 | v | [this memo] | current | 413 +-----+--------------+---------+ 415 8.2. Email Authentication Method Name Registry Update 417 The following is to be added to the Email Authentication Methods 418 Registry (in the Email Authentication Parameters group) established 419 by [AUTHRES] as per [IANA]: 421 Method: dkim-atps 423 Defined In: [THIS MEMO] 425 ptype: header 427 property: from 429 value: contents of the [MAIL] From: header field, with comments 430 removed 432 8.3. Email Authentication Result Name Registry Update 434 The following are to be added to the Email Authentication Result 435 Names Registry (in the Email Authentication Parameters group) 436 established by [AUTHRES] as per [IANA]: 438 Code: none 440 Existing/New Code: existing 442 Defined In: [AUTHRES] 444 Auth Method: dkim-atps 446 Meaning: No valid DKIM signatures were found on the message bearing 447 "atps" tags. 449 Code: pass 451 Existing/New Code: existing 453 Defined In: [AUTHRES] 455 Auth Method: dkim-atps 457 Meaning: An ATPS evaluation was performed and a valid signature from 458 an authorized third-party was found on the message. 460 Code: fail 462 Existing/New Code: existing 464 Defined In: [AUTHRES] 466 Auth Method: dkim-atps 468 Meaning: All valid DKIM signatures bearing an "atps" tag either did 469 not reference a domain name found in the RFC5322.From field, or 470 the ATPS test(s) performed failed to confirm a third-party 471 authorization. 473 Code: temperror 475 Existing/New Code: existing 477 Defined In: [AUTHRES] 479 Auth Method: dkim-atps 481 Meaning: An ATPS evaluation could not be completed due to some error 482 that is likely transient in nature, such as a temporary DNS error. 483 A later attempt might produce a final result. 485 Code: permerror 487 Existing/New Code: existing 489 Defined In: [AUTHRES] 491 Auth Method: dkim-atps 493 Meaning: An ATPS evaluation could not be completed due to some error 494 that is not likely transient in nature, such as a permanent DNS 495 error. A later attempt is unlikely to produce a final result. 497 8.4. DKIM-Signature Tag Specification Registry 499 The following are to be added to the DKIM-Signature Tag Speficication 500 Registry (in the DomainKeys Identifie Mail (DKIM) Parameters group) 501 established by [DKIM] as per [IANA]: 503 +-------+-------------+---------+ 504 | TYPE | REFERENCE | STATUS | 505 +-------+-------------+---------+ 506 | atps | [THIS MEMO] | current | 507 +-------+-------------+---------+ 508 | atpsh | [THIS MEMO] | current | 509 +-------+-------------+---------+ 511 9. Security Considerations 513 This section discusses potential security issues related to this 514 experimental protocol. 516 9.1. Hash Selection 518 The selection of the hash algorithm to be used (see Section 4.1) has 519 security implications, as weaker algorithms have more risk of 520 collision, meaning a second DNS domain name could in theory be 521 constructed to appear to have been authorized by the Author ADMD. 523 At the time of publication of [DKIM], use of SHA256 was preferred 524 over SHA1 for this reason, though support for both has been 525 maintained. See Section 3.3 of [DKIM] for additional discussion. 527 9.2. False Privacy 529 The fact that the authorized third-party domain name is hashed and 530 then encoded with base32 might give some the false sense that the 531 relationship between the two parties is somehow protected. This is 532 not the case. Indeed, the very purpose of this protocol is to make 533 it possible for such relationships to be discovered, so such an 534 obscuration would make that process more difficult without a shared 535 secret delivered out-of-band to message verifiers (which also adds 536 further complexity. Rather, the hash and encode steps are done 537 merely to convert any third-party domain name to a fixed width in the 538 construction of the DNS query. 540 9.3. Transient Security Failures 542 Approving a third party signer exposes the ADMD to the risk that the 543 third party signer becomes compromised and then begins to sign 544 malicious or nuisance messages on behalf of the ADMD. This can 545 obviously reflect negatively on the ADMD, and the impact of this can 546 become more severe as automated domain reputation systems are 547 developed and deployed. Thorough vetting and monitoring practices by 548 ADMDs of third party signers will likely need to become the norm. 550 9.4. Load on the DNS 552 A Verifier participating in DKIM, ADSP and ATPS will now issue a 553 number of TXT queries to the DNS equal to as many as one (for the 554 ADSP query) plus the number of signatures on the message (one for 555 each key that is to be verified) plus the number of signatures that 556 validated which also bear an "atps" tag. This is in addition to any 557 PTR and A queries the MTA might issue at the time the actual message 558 relaying or delivery is initiated. Obviously this can be burdensome 559 on the DNS at both ends, and waiting for that number of queries to 560 return when they are issued in parallel could trigger timeouts in the 561 MTA. 563 An alternative to this that has not yet been explored is the storage 564 of the ATPS data at a specific URL tied to the Author's domain name. 565 This would alleviate pressure on the DNS at the expense of requiring 566 the ADMD to operate a web server (which has its own security 567 implications) and the addition of the establishment of a TCP 568 connection. Moreover, the Verifier would be well advised to 569 implement caching of this data to prevent ATPS from being used as a 570 denial-of-service vector. 572 See Section 8.5 of [DKIM] for further discussion of DNS-related 573 issues. 575 10. References 577 10.1. Normative References 579 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 580 Specifications: ABNF", STD 68, RFC 5234, January 2008. 582 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating 583 Message Authentication Status", RFC 5451, April 2009. 585 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data 586 Encodings", RFC 4648, October 2006. 588 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, 589 Ed., "DomainKeys Identified Mail (DKIM) Signatures", 590 RFC 6376, September 2011. 592 [DNS] Mockapetris, P., "Domain names - implementation and 593 specification", STD 13, RFC 1035, November 1987. 595 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 596 October 2008. 598 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 602 October 2008. 604 10.2. Informative References 606 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, 607 "DomainKeys Identified Mail (DKIM) Author Domain 608 Signing Practices (ADSP)", RFC 5617, August 2009. 610 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing 611 an IANA Considerations Section in RFCs", BCP 26, 612 RFC 5226, May 2008. 614 [IDNA] Klensin, J., "Internationalized Domain Names for 615 Applications (IDNA): Definitions and Document 616 Framework", RFC 5890, August 2010. 618 Appendix A. Example Query and Reply 620 This section presents an example of the use of this protocol to query 621 for a third-party authorization and discusses the interpretation of 622 the result. 624 Presume a message for which the RFC5322.From domain is "example.com", 625 and it bears two valid signatures, from "one.example.net" and from 626 "two.example.net", each with an "atps" tag whose value is 627 "example.com", and no "atpsh" tag is present in either. The 628 following actions are taken: 630 1. A SHA1 hash of "one.example.net" is computed and then converted 631 to printable form using base32 encoding, resulting in the string 632 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 634 2. A TXT query is issued to 635 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 637 3. If a valid reply arrives, the algorithm stops with [AUTHRES] 638 result "pass". If a DNS error code other than NXDOMAIN is 639 returned, the algorithm stops with a result of "temperror" or 640 "permerror" as appropriate. 642 4. A SHA1 hash of "two.example.net" is computed and then converted 643 to printable form using base32 encoding, resulting in the string 644 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 646 5. A TXT query is issued to 647 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 649 6. If a valid reply arrives, the algorithm stops with [AUTHRES] 650 result "pass". If a DNS error code other than NXDOMAIN is 651 returned, the algorithm stops with a result of "temperror" or 652 "permerror" as appropriate. 654 7. As there are no valid signatures left to test, the algorithm 655 stops with an "unknown" result. 657 Appendix B. Choice of DNS RR Type 659 It was proposed that this work appear within the DNS under a new 660 Resource Record (RR) Type. Although this is possibly an appropriate 661 thing to do, consideration was also given to the fact that major 662 portions of DKIM already use an ASCII-based "tag=value" syntax, and 663 store key and ADSP data in the DNS using TXT resource records. To 664 enable re-use of existing DKIM code, it was decided to re-use the TXT 665 message scheme. 667 Appendix C. Acknowledgements 669 The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark 670 Martinec and Phil Pennock for their review and constructive criticism 671 of this proposal. 673 The author also wishes to acknowledge Doug Otis and Daniel Black for 674 their original draft upon which this work was based. 676 Author's Address 678 Murray S. Kucherawy 679 Cloudmark, Inc. 680 128 King St., 2nd Floor 681 San Francisco, CA 94107 682 US 684 Phone: +1 415 946 3800 685 EMail: msk@cloudmark.com