From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6541.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc6541.txt (limited to 'doc/rfc/rfc6541.txt') diff --git a/doc/rfc/rfc6541.txt b/doc/rfc/rfc6541.txt new file mode 100644 index 0000000..9533aba --- /dev/null +++ b/doc/rfc/rfc6541.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Kucherawy +Request for Comments: 6541 Cloudmark, Inc. +Category: Experimental February 2012 +ISSN: 2070-1721 + + + DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures + +Abstract + + This experimental specification proposes a modification to DomainKeys + Identified Mail (DKIM) allowing advertisement of third-party + signature authorizations that are to be interpreted as equivalent to + a signature added by the administrative domain of the message's + author. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6541. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Kucherawy Experimental [Page 1] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Definitions .....................................................3 + 2.1. Key Words ..................................................3 + 2.2. Email Architecture Terminology .............................3 + 3. Roles and Scope .................................................3 + 4. Queries and Replies .............................................4 + 4.1. Hash Selection .............................................4 + 4.2. Extension to DKIM ..........................................5 + 4.3. ATPS Query Details .........................................5 + 4.4. ATPS Reply Details .........................................7 + 5. Interpretation ..................................................8 + 6. Relationship to ADSP ............................................8 + 7. Experiment Process ..............................................8 + 8. IANA Considerations .............................................9 + 8.1. ATPS Tag Registry ..........................................9 + 8.2. Email Authentication Methods Registry Update ..............10 + 8.3. Email Authentication Result Names Registry Update .........10 + 8.4. DKIM Signature Tag Specifications Registry ................12 + 9. Security Considerations ........................................12 + 9.1. Hash Selection ............................................12 + 9.2. False Privacy .............................................12 + 9.3. Transient Security Failures ...............................13 + 9.4. Load on the DNS ...........................................13 + 10. References ....................................................13 + 10.1. Normative References .....................................13 + 10.2. Informative References ...................................14 + Appendix A. Example Query and Reply ...............................15 + Appendix B. Choice of DNS RR Type .................................15 + Appendix C. Acknowledgements ......................................16 + +1. Introduction + + [DKIM] defines a mechanism for transparent domain-level signing of + messages for the purpose of declaring that a particular + ADministrative Management Domain (ADMD) takes some responsibility for + a message. + + DKIM, however, deliberately makes no binding between the DNS domain + of the Signer and any other identity found in the message. Despite + this, there is an automatic human perception that an Author Domain + Signature (one for which the RFC5322.From domain matches the DNS + domain of the Signer) is more valuable or trustworthy than any other. + + To enable a third party to apply DKIM signatures to messages, the + DKIM specification suggests delegation to a third party of either + subdomains or private keys, so that the third party can add DKIM + + + +Kucherawy Experimental [Page 2] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + signatures that appear to have been added by the Author ADMD. Absent + is a protocol by which an Author ADMD can announce that messages + bearing specific valid DKIM signatures on its mail, which are added + by other ADMDs, are to be treated as if they were signed by the + Author ADMD itself. This memo presents an experimental mechanism for + doing so, called Authorized Third-Party Signatures (ATPS). + + ATPS augments the semantics of DKIM by providing to the Verifier + multiple identifiers rather than one. Specifically, it validates the + identifier found in the DKIM signature, and then provides the + RFC5322.From domain for evaluation. + + This memo also registers, per [AUTHRES], the means to indicate to + agents downstream of the Verifier that a third-party signature + verification occurred. + +2. Definitions + +2.1. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + +2.2. Email Architecture Terminology + + Readers are advised to be familiar with the material and terminology + discussed in [MAIL] and [EMAIL-ARCH]. + +3. Roles and Scope + + The context of this protocol involves the following roles: + + o ADministrative Management Domains (ADMDs), whose DNS domain + name(s) appear in the RFC5322.From field of a [MAIL] message; + + o ATPS Signers, which apply [DKIM] signatures using their own + domains, but on behalf of the message Author's ADMD; and + + o the Verifier, who implements the signature validation procedures + described in [DKIM]. + + An ADMD implements this protocol if it wishes to announce that a + signature from any in a set of specified DNS domains is to be + considered equivalent to one from the ADMD itself. For example, an + ADMD might wish to delegate signing authority for its DNS domain to + an approved messaging service provider without doing the work of key + transfer described in Appendix B.1.1 of [DKIM]. An authorized ATPS + + + +Kucherawy Experimental [Page 3] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + Signer makes a claim of this relationship via new tags in the DKIM + signature, and the ADMD confirms this claim by publishing a specific + TXT record in its DNS. + + A Verifier implements this protocol if it wishes to ensure that a + message bears one or more signatures from sources authorized to sign + mail on behalf of the ADMD, and identify for special treatment mail + that meets (or does not meet) that criterion. It will do so by + treating the Signer's authorization on behalf of the Author's ADMD to + mean that the Signer's signature is equivalent to one affixed by the + Author's ADMD. + +4. Queries and Replies + + This section describes in detail the queries issued, the replies + received, and how they should be interpreted and applied. + +4.1. Hash Selection + + The Author's ADMD will indicate authorization of a third party to + sign its mail via the presence of a DNS TXT record that contains an + encoding of the third party's DNS domain name. There are two + supported methods for doing so -- one that involves a plain copy of + the third party's DNS domain name, and one that involves an encoded + version of the name. The encoding mechanism is provided so that any + domain name can be added to the DNS in a fixed length, so that longer + third-party domain names are not excluded from participation because + of the overall length limit on a DNS query. + + If selected, the encoding mechanism requires constructing a digest of + the third party's DNS domain name. The Author ADMD MUST select a + digest ("hash") method currently supported by DKIM (see Section 7.7 + of [DKIM]), and this selection needs to be communicated to the ATPS + Signer, as it is used in generation of the third-party signatures. + + Where the encoding mechanism is not used, the ATPS Signer MUST use a + hash name of "none". + + The full DNS mechanism is specified in Section 4.3. + + + + + + + + + + + + +Kucherawy Experimental [Page 4] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +4.2. Extension to DKIM + + [DKIM] signatures contain a "tag=value" sequence. This protocol will + add additional tags called "atps" and "atpsh". + + When the ATPS Signer generates a DKIM signature for another ADMD, it + MUST put its own domain in the signature's "d" tag, and include an + "atps" tag that has as its value the domain name of the ADMD on whose + behalf it is signing. + + The tag name that carries the name of the selected hash algorithm is + "atpsh". This tag MUST also be included, as it is required as part + of the algorithm that will be enacted by the Verifier. + + The formal syntax definition, per [ABNF], is as follows: + + dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name + + dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP + ( "none" / key-h-tag-alg ) + + "domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that + according to [DKIM], internationalized domain names are to be encoded + as A-labels, as described in Section 2.3 of [IDNA]. + + The registration for these tags can be found in Section 8. + +4.3. ATPS Query Details + + When a [DKIM] signature including an "atps" tag is successfully + verified, and is considered acceptable to the Verifier according to + any local policy requirements (which are not discussed here or in + [DKIM]), the Verifier compares the domain name in the value of that + tag with the one found in the RFC5322.From field of the message. The + match MUST be done in a case-insensitive manner. + + If they do not match, the "atps" tag MUST be ignored. + + If they do match, the Verifier issues a DNS TXT query, as specified + below, looking for confirmation by the Author ADMD that the ATPS + Signer is authorized by that ADMD to sign mail on its behalf. Where + multiple DKIM signatures including valid "atps" tags are present, + these queries MAY be done in any order or MAY be done in parallel. + + Where the RFC5322.From field contains multiple addresses, this + process SHOULD be applied if the "atps" tag's value matches any of + the domains found in that field. These MAY be done in any order. + + + + +Kucherawy Experimental [Page 5] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + Note that the algorithm uses hashing, but this is not a security + mechanism. See Section 9.2 for discussion. + + The name for the query is constructed as follows: + + 1. Select the hash algorithm from the "atpsh" tag in the signature. + If the hash algorithm specified does not appear in the list + registered with IANA as one valid for use with DKIM (see + Section 7.7 of [DKIM]), and is not the reserved name "none" as + described above, abort the query. + + 2. Extract the value of the "d=" tag from the signature. + + 3. Convert any uppercase characters in that string to their + lowercase equivalents. + + 4. If the selected hash algorithm is not "none", apply the following + additional steps: + + A. Feed the resulting string to the selected hash algorithm. + + B. Convert the output of the hash to a string of printable ASCII + characters by applying base32 encoding as defined in + Section 6 of [BASE32]. The base32 encoding is used because + its output is restricted to characters that are legal for use + in labels in the DNS, and it is evaluated the same way in the + DNS whether encoded using uppercase or lowercase characters. + + 5. Append the string "._atps." + + 6. Append the domain name found in the "atps" tag of the validated + signature. + + The query's formal syntax definition, per [ABNF], is as follows: + + atps-query = ( 1*63BASE32 / domain-name ) + %x2e.5f.61.74.70.73.2e domain-name + + BASE32 = ( ALPHA / %x32-37 ) + + The width limit of 63 on the base32 encoding is based on the maximum + label limit as defined in Section 2.3.4 of [DNS]. + + See Appendix A for an example of a query construction. + + + + + + + +Kucherawy Experimental [Page 6] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +4.4. ATPS Reply Details + + In the descriptions below, the label NOERROR symbolizes DNS response + code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 + of [DNS] for further details. + + At this time, only three possibilities need to be identified in this + specification: + + o An answer is returned (i.e., [DNS] reply code NOERROR with at + least one answer) containing a valid ATPS reply. In this case, + the protocol has been satisfied and the Verifier can conclude that + the signing domain is authorized by the ADMD to sign its mail. + Further queries SHOULD NOT be initiated. + + o No answer is returned (i.e., [DNS] reply code NXDOMAIN, or NOERROR + with no answers), or one or more answers have been returned as + described above but none contain a valid ATPS reply. In this + case, the Signer has not been authorized to act as a third-party + Signer for this ADMD, and thus the Verifier MUST continue to the + next query, if any. + + o An error is returned (i.e., any other [DNS] reply code). It is no + longer possible to determine whether or not this message satisfies + the ADMD's list of authorized third-party Signers. The Verifier + SHOULD stop processing and defer the message for later processing, + such as requesting a temporary failure code from the Mail Transfer + Agent (MTA). + + If all queries are completed and return either NXDOMAIN or NOERROR + with no answers, then the Signer was not authorized by the ADMD. + + A valid ATPS reply consists of a sequence of tag=value pairs as + described in Section 3.2 of [DKIM]. The following tags and values + are currently supported in ATPS records: + + d: Domain (plain-text; RECOMMENDED). This tag includes a plain-text + copy of the DNS domain being authorized as an ATPS Signer. This + is included to assist with collision detections; for example, if + the base32 encoding of this name is not the same as the base32 + portion of the query, or more simply if this name is not the same + as that found in the "atps" tag, a hash collision could have + occurred. Its use where no name hashing has occurred is + redundant. The ABNF is as follows: + + atps-d-tag = %x64 [FWS] "=" [FWS] domain-name + ; FWS is defined in [DKIM] + + + + +Kucherawy Experimental [Page 7] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + v: Version (plain-text; REQUIRED). This tag indicates the version of + the ATPS specification to which the record complies. The record + MUST be ignored if the value is not "ATPS1". The ABNF is as + follows: + + atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 + ; FWS is defined in [DKIM] + +5. Interpretation + + For each DKIM signature that verifies (see Section 6 of [DKIM]), if a + Verifier succeeds in confirming that the Author's ADMD authorized the + ATPS Signer using this protocol, then the Verifier SHOULD evaluate + the message as though it contained a valid signature from the + Author's ADMD. It MAY also independently evaluate the ATPS Signer + when determining message disposition. + + This assertion is based on the fact that the ADMD explicitly endorsed + the ATPS Signer. Therefore, a module assessing reputation that is + based on DKIM signature verification SHOULD apply the reputation of + the Author's ADMD domain instead of, or in addition to, that of the + ATPS Signer domain. + +6. Relationship to ADSP + + [ADSP] defined a protocol by which the owner of an Author Domain can + advertise a request to message receivers that messages bearing no + valid author signature be treated with suspicion or even discarded. + + A Verifier implementing both Author Domain Signing Practices (ADSP) + and ATPS MUST test ATPS first. If ATPS indicates a valid delegation, + the Verifier MUST act, with respect to ADSP, as though the message + has a valid Author Domain Signature (because that's what the + delegation means), and no ADSP test is required. + +7. Experiment Process + + The working group that developed DKIM considered a third-party + mechanism such as this one to be controversial, in terms of need and + practicality, and decided that an alternative mechanism was + sufficient. However, this was not based on actual experience, as + there is no specific history on this question. Thus, this experiment + was devised. + + + + + + + + +Kucherawy Experimental [Page 8] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + The experimental protocol described here has been implemented as an + extension to DKIM in two software products, one of which is open + source and seeing increasingly wide use. It is included there to + allow customers of those systems to make use of it if they believe + such third-party assertions are useful to the overall DKIM mechanism. + Further adoption as part of the experiment is welcome and encouraged. + + Use of the protocol and anecdotes of how it affects the overall DKIM + experience will be collected by those implementers and the author of + this memo. Those participating in the experiment are also advised to + observe and report the impact of what is discussed in Section 9.4, + especially with respect to MTA latency that may be introduced. + + If the response is substantial and positive, advancement along the + Standards Track might be warranted. + +8. IANA Considerations + + This section enumerates requested IANA actions. + +8.1. ATPS Tag Registry + + IANA has created an Authorized Third-Party Signature (ATPS) Tag + Registry, under the DomainKeys Identified Mail (DKIM) Parameters + group, to enumerate the tags that are valid for use in ATPS records. + + New registrations or updates MUST be made in accordance with the + "Specification Required" guidelines described in [IANA]. Such + registry changes MUST contain the following information: + + 1. Name of the tag being registered or updated + + 2. The document where the specification is created or updated + + 3. The status of the tag, one of "active" (tag is in current use), + "deprecated" (tag is in current use but its use is discouraged), + or "historic" (tag is no longer in use) + + The registry's initial entries are below: + + +-----+------------+--------+ + | Tag | Reference | Status | + +-----+------------+--------+ + | d | [RFC6541] | active | + +-----+------------+--------+ + | v | [RFC6541] | active | + +-----+------------+--------+ + + + + +Kucherawy Experimental [Page 9] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +8.2. Email Authentication Methods Registry Update + + The following has been added to the Email Authentication Methods + registry (in the Email Authentication Parameters group) established + by [AUTHRES] as per [IANA]: + + Method: dkim-atps + + Defined In: [RFC6541] + + ptype: header + + property: from + + value: contents of the [MAIL] From: header field, with comments + removed + +8.3. Email Authentication Result Names Registry Update + + The following have been added to the Email Authentication Result + Names registry (in the Email Authentication Parameters group) + established by [AUTHRES] as per [IANA]: + + Code: none + + Existing/New Code: existing + + Defined In: [AUTHRES] + + Auth Method: dkim-atps + + Meaning: No valid DKIM signatures were found on the message bearing + "atps" tags. + + + Code: pass + + Existing/New Code: existing + + Defined In: [AUTHRES] + + Auth Method: dkim-atps + + Meaning: An ATPS evaluation was performed, and a valid signature + from an authorized third party was found on the message. + + + + + + +Kucherawy Experimental [Page 10] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + Code: fail + + Existing/New Code: existing + + Defined In: [AUTHRES] + + Auth Method: dkim-atps + + Meaning: All valid DKIM signatures bearing an "atps" tag either did + not reference a domain name found in the RFC5322.From field, or + the ATPS test(s) performed failed to confirm a third-party + authorization. + + + Code: temperror + + Existing/New Code: existing + + Defined In: [AUTHRES] + + Auth Method: dkim-atps + + Meaning: An ATPS evaluation could not be completed due to some error + that is likely transient in nature, such as a temporary DNS error. + A later attempt might produce a final result. + + + Code: permerror + + Existing/New Code: existing + + Defined In: [AUTHRES] + + Auth Method: dkim-atps + + Meaning: An ATPS evaluation could not be completed due to some error + that is not likely transient in nature, such as a permanent DNS + error. A later attempt is unlikely to produce a final result. + + + + + + + + + + + + + +Kucherawy Experimental [Page 11] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +8.4. DKIM Signature Tag Specifications Registry + + The following have been added to the DKIM Signature Tag + Specifications registry (in the DomainKeys Identified Mail (DKIM) + Parameters group) established by [DKIM] as per [IANA]: + + +-------+-----------+--------+ + | Type | Reference | Status | + +-------+-----------+--------+ + | atps | [RFC6541] | active | + +-------+-----------+--------+ + | atpsh | [RFC6541] | active | + +-------+-----------+--------+ + +9. Security Considerations + + This section discusses potential security issues related to this + experimental protocol. + +9.1. Hash Selection + + The selection of the hash algorithm to be used (see Section 4.1) has + security implications, as weaker algorithms have more risk of + collision, meaning a second DNS domain name could in theory be + constructed to appear to have been authorized by the Author ADMD. + + At the time of publication of [DKIM], use of SHA256 was preferred + over SHA1 for this reason, though support for both has been + maintained. See Section 3.3 of [DKIM] for additional discussion. + +9.2. False Privacy + + The fact that the authorized third-party domain name is hashed and + then encoded with base32 might give some the false sense that the + relationship between the two parties is somehow protected. This is + not the case. Indeed, the very purpose of this protocol is to make + it possible for such relationships to be discovered, so such an + obscuration would make that process more difficult without a shared + secret delivered out-of-band to message verifiers (which also adds + further complexity). Rather, the hash and encode steps are done + merely to convert any third-party domain name to a fixed width in the + construction of the DNS query. + + + + + + + + + +Kucherawy Experimental [Page 12] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +9.3. Transient Security Failures + + Approving a third-party Signer exposes the ADMD to the risk that the + third-party Signer becomes compromised and then begins to sign + malicious or nuisance messages on behalf of the ADMD. This can + obviously reflect negatively on the ADMD, and the impact of this can + become more severe as automated domain reputation systems are + developed and deployed. Thorough vetting and monitoring practices by + ADMDs of third-party Signers will likely need to become the norm. + +9.4. Load on the DNS + + A Verifier participating in DKIM, ADSP, and ATPS will now issue a + number of TXT queries to the DNS equal to as many as one (for the + ADSP query) plus the number of signatures on the message (one for + each key that is to be verified) plus the number of signatures that + validated and that also bear an "atps" tag. This is in addition to + any PTR and A queries the MTA might issue at the time the actual + message relaying or delivery is initiated. Obviously, this can be + burdensome on the DNS at both ends, and waiting for that number of + queries to return when they are issued in parallel could trigger + timeouts in the MTA. + + An alternative that has not yet been explored is the storage of the + ATPS data at a specific URL tied to the Author's domain name. This + would alleviate pressure on the DNS at the expense of requiring the + ADMD to operate a web server (which has its own security + implications) and the addition of the establishment of a TCP + connection. Moreover, the Verifier would be well advised to + implement caching of this data to prevent ATPS from being used as a + denial-of-service vector. + + See Section 8.5 of [DKIM] for further discussion of DNS-related + issues. + +10. References + +10.1. Normative References + + [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [AUTHRES] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 5451, April 2009. + + [BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + + +Kucherawy Experimental [Page 13] + +RFC 6541 DKIM ATPS Experiment February 2012 + + + [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, + Ed., "DomainKeys Identified Mail (DKIM) Signatures", + RFC 6376, September 2011. + + [DNS] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, + July 2009. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + +10.2. Informative References + + [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, + "DomainKeys Identified Mail (DKIM) Author Domain Signing + Practices (ADSP)", RFC 5617, August 2009. + + [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [IDNA] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document + Framework", RFC 5890, August 2010. + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Experimental [Page 14] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +Appendix A. Example Query and Reply + + This section presents an example of the use of this protocol to query + for a third-party authorization and discusses the interpretation of + the result. + + Presume a message for which the RFC5322.From domain is "example.com", + and it bears two valid signatures, from "one.example.net" and from + "two.example.net", each with an "atps" tag whose value is + "example.com", and an "atpsh" tag whose value is "sha1". The + following actions are taken: + + 1. A SHA1 hash of "one.example.net" is computed and then converted + to printable form using base32 encoding, resulting in the string + "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". + + 2. A TXT query is issued to + "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". + + 3. If a valid reply arrives, the algorithm stops with [AUTHRES] + result "pass". If a DNS error code other than NXDOMAIN is + returned, the algorithm stops with a result of "temperror" or + "permerror" as appropriate. + + 4. A SHA1 hash of "two.example.net" is computed and then converted + to printable form using base32 encoding, resulting in the string + "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". + + 5. A TXT query is issued to + "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". + + 6. If a valid reply arrives, the algorithm stops with [AUTHRES] + result "pass". If a DNS error code other than NXDOMAIN is + returned, the algorithm stops with a result of "temperror" or + "permerror" as appropriate. + + 7. As there are no valid signatures left to test, the algorithm + stops with an "unknown" result. + +Appendix B. Choice of DNS RR Type + + It was proposed that this work appear within the DNS under a new + Resource Record (RR) Type. Although this is possibly an appropriate + thing to do, consideration was also given to the fact that major + portions of DKIM already use an ASCII-based "tag=value" syntax, and + store key and ADSP data in the DNS using TXT resource records. To + enable re-use of existing DKIM code, it was decided to re-use the TXT + message scheme. + + + +Kucherawy Experimental [Page 15] + +RFC 6541 DKIM ATPS Experiment February 2012 + + +Appendix C. Acknowledgements + + The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark + Martinec, and Phil Pennock for their review and constructive + criticism of this proposal. + + The author also wishes to acknowledge Doug Otis and Daniel Black for + their original document, upon which this work was based. + +Author's Address + + Murray S. Kucherawy + Cloudmark, Inc. + 128 King St., 2nd Floor + San Francisco, CA 94107 + US + + Phone: +1 415 946 3800 + EMail: msk@cloudmark.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kucherawy Experimental [Page 16] + -- cgit v1.2.3