summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6541.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6541.txt')
-rw-r--r--doc/rfc/rfc6541.txt899
1 files changed, 899 insertions, 0 deletions
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]
+