Network Working Group S. Leonard Internet-Draft Penango, Inc. Intended status: Standards Track October 13, 2015 Expires: April 15, 2016 Alternative Local-Part Synthesis for DANE draft-seantek-dane-alps-00 Abstract This document describes how to synthesize alternative local-part productions when looking up email addresses with DANE for S/MIME and OpenPGP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 15, 2016. Copyright Notice Copyright (c) 2015 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. Leonard Expires April 15, 2016 [Page 1] Internet-Draft DANE ALPS October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The ALPR Resource Record . . . . . . . . . . . . . . . . . . 3 2.1. Rule Design and Operation . . . . . . . . . . . . . . . . 3 2.2. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Presentation Format . . . . . . . . . . . . . . . . . . . 6 3. Modifications to Domain Name Formulations . . . . . . . . . . 7 4. Initial Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. 0 Range: Common . . . . . . . . . . . . . . . . . . . . . 7 4.2. 256 Range: Normalization . . . . . . . . . . . . . . . . 10 4.3. 384 Range: Case Algorithms . . . . . . . . . . . . . . . 11 4.4. 512 Range: Various Unicode-Aware Algorithms . . . . . . . 11 4.5. 768 Range: PRECIS Framework Rules . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. ALPR RRtype . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction DNS-Based Authentication of Named Entities (DANE) [RFC6698] is used to store signed assertions about names related to domain names directly in the DNS. When storing assertions related to email addresses, [SMIMEA] and [OPENPGPKEY] transform the local-part into a terminal label that is stored in a DNS zone that is associated with the domain portion of email address. Tension exists because local-parts and DNS labels do not share the same syntax or semantics. The local-part production of [RFC5322] is formally case-sensitive and can technically represent any ASCII character, i.e., octets in the range 00-7F (although only a much smaller range is in common use, and only certain characters can be used to ensure deliverability via SMTP [RFC5321]). In contrast, DNS labels are comprised of up to 63 octets, but are compared case- insensitively in the ASCII range [RFC1035]. Several solutions have been proposed. These include constructing case-sensitive versus case-insensitive queries, each option exclusive of the other. [DNSMBOX] adds two proposals: online DNS servers for the zone that compute (and sign) responses on-the-fly, and regular expressions that can be converted into Deterministic Finite Automata (DFA), which are then stored piecemeal in DNS records. Leonard Expires April 15, 2016 [Page 2] Internet-Draft DANE ALPS October 2015 This document proposes a rule-based mechanism for clients to synthesize alternative local-parts (ALPs) that are likely to be used as inputs to the DNS-mailbox record lookup process, obviating the need for servers to compute (or precompute) every possible permutation of a domain's local-part mailbox strings. Readers should be familiar with [RFC6698], [SMIMEA], and [OPENPGPKEY]. Readers who plan on implementing email address internationalization [RFC6530] should also be familiar with equivalence issues in [UNICODE], such as case conversion, case folding, and normalization forms. 1.1. Terminology 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 RFC 2119 [RFC2119]. All integers are encoded in network byte order. The bare term _character_, without qualification, refers to a Unicode scalar value [UNICODE]. 2. The ALPR Resource Record The ALPR resource record (RR) is an ordered list of rules to synthesize alternative local-part (ALP) strings. This document uses the term "alternative" rather than "canonical" deliberately. There is no notion of a canonical mailbox form in [RFC5321] or [RFC5322]. If two different strings happen to deliver to the same mailbox, that is a fortunate coincidence but my no means a guaranteed outcome. Furthermore, email's recent foray into internationalization [RFC6530] means that many characters can be represented with different code points; choosing to which mailbox to deliver such addressed messages is firmly in the purview of the receiving mail server. The type value for the ALPR RRtype is defined in Section 6.1. The ALPR resource record is class independent. The ALPR resource record has no special TTL requirements. 2.1. Rule Design and Operation There are two purposes of this protocol. The first purpose is to generate _alternative_ local-parts, _not_ _equivalent_ ones. Local- parts are considered alternative to each other if they deliver to the same mailbox [RFC5322]. In contrast, local-parts are _equivalent_ to each other if they deliver to the same place and represent the same recipient. In conforming mail systems, postMaster@example.com and Leonard Expires April 15, 2016 [Page 3] Internet-Draft DANE ALPS October 2015 POSTmaster@example.com are equivalent: mail systems are expected to treat them exactly the same [RFC5321]. In contrast, postmaster.john@example.com and postmaster.george@example.com _might_ be alternatives to postmaster@example.com, but even if they deliver to the same mailbox, mail may not end up at the same place or be read by the same recipient. (George and John may share a mailbox, but have different folders, even though they are jointly responsible for postmaster mail.) [[NB: this definition really needs more discussion. Specifically shouldn't DANE suggest that two local-parts are the same or very similar if they share the same PUBLIC KEY?]] The second purpose is to ease implementation of DANE mailbox-related technologies such as SMIMEA and OPENPGPKEY, by making it more convenient for DNS operators to publish static lists in their zones. "Convenience" for DNS operators necessarily implies more work for clients. Without a protocol such as the one described in this document, the onus would be on the DNS server to provide matching public key records for diverse inputs on the fly (see [DNSMBOX]). Conformance is as follows: 1. A rule takes as input a local-part string, which is a well-formed Unicode string. 2. A rule is comprised of a rule identifier and optional rule parameters. If present, the parameters can be Unicode strings, 32-bit signed integers, or a handful of special values: true, false, null, etc. Although a fairly elaborate syntax is given below, a rule SHOULD be defined to minimize the quantity and complexity of parameters--preferably, by not having parameters at all. 3. A rule outputs exactly one string, which is also a well-formed Unicode string. 4. If the output is the same as the input, the rule has not produced an alternative local-part. 5. If the output differs from the input, then the rule has produced an alternative local-part. 6. The alternative is to be queried as part of the DANE mailbox lookup protocols, at a lower priority order than the input. 7. A rule is applied to every input that is output from the application of prior rules. Leonard Expires April 15, 2016 [Page 4] Internet-Draft DANE ALPS October 2015 8. Up to _2^n_ local-parts might be produced for _n_ rules. Query priority is determined in rule order. Therefore, subsequent application of rules produces interleaved results when the output is conceptualized as a stack. 9. A client that encounters an unrecognized rule or malformed rule parameters SHALL ignore the rule and continue processing the next rule. An implementation MAY optimize network retrieval by querying for the highest-priority item first, i.e., the original local-part. (Due to interleaving, the priority order of the ALPs is not determined until all rules are applied.) The results of the DANE mailbox lookup protocols are considered to be in the ALP priority order. The "best" (most faithful) association is the one that most closely matches the input, and the "worst" (least faithful) association is the one that least closely matches the input, i.e., the ALP derived from the application of the greatest number of rules. Whether an application accepts, rejects, or takes other action (e.g., presents the inaccuracy to the user) is implementation-defined. However, to the extent that public key results differ in the priority order, an application SHOULD consider the public keys to be "better" at the top of the priority order. For example, if 3 ALPs produce 8 local-parts and 8 different public keys, encrypting a message to all 8 public keys will increase the attack surface (as some keys may be compromised) but is very unlikely to increase readability, for a well-maintained DNS zone. For example, if a user refers to two addresses: user+topsecret@example.com, and user@example.com, and uses separate public keys for each address, the user's security intent would be thwarted if all mail encrypted to the key at user+topsecret@example.com were also encrypted to user@example.com. Perhaps the user only wishes to expose his or her private key for user+topsecret@example.com to trustworthy computing devices, thus making a convenience tradeoff that is up to the user-- not the protocol--to dictate. 2.2. Wire Format The ALPR wire format is comprised of a 16-bit unsigned integer indicating the number of rules, followed by a sequence of rules. Each rule is comprised of: a 16-bit unsigned integer for the rule identifier; a 16-bit specifier for the rule parameters, including the length of the rule parameters (if any); a variable number of octets comprising the rule parameters. Leonard Expires April 15, 2016 [Page 5] Internet-Draft DANE ALPS October 2015 Rule identifiers are registered with IANA in a sub-registry for this RRtype. The specifier has the following meanings: When the high-order bit is 0, the specifier is a 16-bit unsigned integer indicating the length of the octets of the subsequent rule parameters. Therefore, the parameters cannot exceed 32767 octets. The rule parameters are well- formed UTF-8 sequences, delimited by the octet 0xFF (0b11111111). Conveniently, 0xFF does not appear in UTF-8. When the high-order quartet is 0x4 (0b1000), the specifier is a 12-bit unsigned integer comprised of the remaining three quartets, representing the number of 32-bit signed integers present in the subsequent rule parameters. (Therefore, each incremental value represents an additional four octets in the rule parameters.) The rule parameters are 32-bit signed integers. When the three high-order quartets are 0xFFF (0b111111111111), the specifier is the rule parameter itself, as indicated by the low-order quartet. There are no octets that follow that comprise the rule parameter. The following special values are defined: 0xC (0b1100) means false, or =0. 0xD (0b1101) means true, or >0. 0xE (0b1110) means null, or <0. Additionally: 0xF (0b1111) means undefined or "no parameters given". All other bit combinations are reserved. 2.3. Presentation Format The ALPR presentation format is an ordered sequence of rules. Rules are delimited by one or more newlines. Each rule is comprised of: o The rule identifier, which is a 16-bit unsigned integer. o The rule parameters, which may be one of the following: * absent (i.e., undefined or not given). * The special values: "true", "t", or ">"; "false", "f", or "="; or, "null", "n", or "<". Leonard Expires April 15, 2016 [Page 6] Internet-Draft DANE ALPS October 2015 * A sequence of one or more 32-bit signed integers. * A sequence of one or more character strings, which MUST be quoted. 3. Modifications to Domain Name Formulations The algorithms for formulating the domain names for the records are modified under this document, compared to the SMIMEA and OPENPGPKEY records, as follows: 1. After determining the local-part production, the local-part is converted to a well-formed Unicode string (if it is not already in Unicode). 2. The local-part is unescaped. 3. The ALPR record is looked up in the DNS for the domain. This is the same domain query as for the MX records for the domain. 4. Alternative local-parts are generated with the algorithm in this document, and fed to the hashing step described in [SMIMEA] and [OPENPGPKEY]. The remainder of those documents' algorithms are executed. 5. The application decides which public key results to use based on the principles of this document. 4. Initial Rules The following rules are the initial rules that ALP implementations MUST implement. If the rule or rule range make no remarks about parameters, then parameters MUST NOT be given. 4.1. 0 Range: Common 4.1.1. (0) (Reserved) The rule identifier (0) is reserved; assignment requires future Standards Action. Otherwise, it has no special meaning. 4.1.2. (1) ASCII Lowercase Mapping This rule makes a local-part case-insensitive by mapping the uppercase ASCII range (41-5A) into the lowercase ASCII range (61-7A). Only ASCII characters are affected. Leonard Expires April 15, 2016 [Page 7] Internet-Draft DANE ALPS October 2015 4.1.3. (2) ASCII Uppercase Mapping This rule makes a local-part case-insensitive by mapping the lowercase ASCII range (61-7A) into the uppercase ASCII range (41-5A). Only ASCII characters are affected. 4.1.4. (3) Character Removal This rule facilitates "dot removal" and the removal of other characters more generally. The single parameter is a string containing a list of characters to be removed. 4.1.5. (4) Range Removal This rule eliminates ranges of irrelevant characters. The single parameter is a string containing pairs of characters; each pair is inclusive and is comprised of the first (lowest valued), followed by the last (highest valued), characters to be removed. If the first character has a code point value greater than the last character, the pair has no effect. If the string has an odd number of characters, then the last character is paired with U+10FFFF, i.e., the end of the Unicode range. 4.1.6. (5) Sub-Addressing, Eliminate Separator This rule eliminates sub-addresses. The single parameter is a string containing a list of characters that delimit the sub-address. The first character from the list that appears in the local-part delimits the sub-address portion; both that character and all subsequent characters are removed. 4.1.7. (6) Sub-Addressing, Preserve Separator This rule eliminates sub-addresses. The single parameter is a string containing a list of characters that delimit the sub-address. The first character from the list that appears in the local-part delimits the sub-address portion; that character is kept but all subsequent characters are removed. 4.1.8. (7) First Name Contraction, Eliminate Separator This rule contracts the first substring in a local-part to one character, prior to the delimiter. For example, it takes input of "john.smith" and outputs "jsmith". The single parameter is a string containing a list of characters that delimit the name. The first character from the list that appears in the local-part delimits names; both that character and all prior characters, except for the first character, are removed. (Beware that this rule operates on Leonard Expires April 15, 2016 [Page 8] Internet-Draft DANE ALPS October 2015 "characters", i.e., Unicode scalar values. It will eliminate combining characters ([UNICODE] Conformance Clause D52) that follow the first character/code point.) 4.1.9. (8) First Name Contraction, Preserve Separator This rule is identical to (7) except that the delimiter is preserved. For example, it takes input of "john.smith" and outputs "j.smith". 4.1.10. (9) First Name Contraction (ECCS), Eliminate Separator This rule contracts the first substring in a local-part to one abstract character, prior to the delimiter. For example, it takes input of "A'_l_m_o_s_.K=u=r=t=a'=g=" and outputs "A'_K=u=r=t=a'=g=". (In this example, ' is U+0301 COMBINING ACUTE ACCENT, _ is U+0332 COMBINING LOW LINE, and = is U+0333 COMBINING DOUBLE LOW LINE.) The single parameter is a string containing a list of characters that delimit the name. The first character from the list that appears in the local-part delimits names; both that character and all prior characters, except for the first extended combining character sequence ([UNICODE] Conformance Clause D56a), are removed. 4.1.11. (10) First Name Contraction (EECS), Preserve Separator This rule is identical to (9) except that the delimiter is preserved. For example, it takes input of "A'_l_m_o_s_.K=u=r=t=a'=g=" and outputs "A'_.K=u=r=t=a'=g=". 4.1.12. (11) Preserve First n Characters This rule preserves the first characters. The single parameter is a positive integer indicating the number of characters from the beginning of the input to preserve. 4.1.13. (12) Preserve Last n Characters This rule preserves the last characters. The single parameter is a positive integer indicating the number of characters from the end of the input to preserve. 4.1.14. (13) Preserve First n EECSes This rule preserves the first extended combining character sequences. The single parameter is a positive integer indicating the number of extended combining character sequences from the beginning of the input to preserve. Leonard Expires April 15, 2016 [Page 9] Internet-Draft DANE ALPS October 2015 4.1.15. (14) Preserve Last n EECSes This rule preserves the last extended combining character sequences. The single parameter is a positive integer indicating the number of extended combining character sequences from the end of the input to preserve. 4.1.16. (14) Preserve Prefix Only If a prefix string appears in the input, then the output of this rule is just that prefix. The parameters are strings that are the prefixes. Prefix matching is performed in parameter order; the first match wins. This rule faciliates the variable envelope return path (VERP) technique. 4.1.17. (15) Preserve Suffix Only If a suffix string appears in the input, then the output of this rule is just that suffix. The parameters are strings that are the suffixes. Suffix matching is performed in parameter order; the first match wins. This rule faciliates the variable envelope return path (VERP) technique. 4.2. 256 Range: Normalization 4.2.1. (256) Unicode Normalization Form C This rule applies Unicode Normalization Form C to the input: toNFC(X). 4.2.2. (257) Unicode Normalization Form D This rule applies Unicode Normalization Form D to the input: toNFD(X). 4.2.3. (258) Unicode Normalization Form KC This rule applies Unicode Normalization Form KC to the input: toNFKC(X). 4.2.4. (259) Unicode Normalization Form KD This rule applies Unicode Normalization Form KD to the input: toNFKD(X). Leonard Expires April 15, 2016 [Page 10] Internet-Draft DANE ALPS October 2015 4.3. 384 Range: Case Algorithms These rules apply the various case algorithms defined in [UNICODE]. All rules in this section take a single parameter, which is a string identifying the language [BCP47] for tailored operations. The parameter is REQUIRED (i.e., it MUST NOT be omitted). The default casing algorithm is accessed with the empty string parameter "". A conformant implementation MUST implement the default casing algorithm, as well as the casing algorithm for "en" (which [UNICODE] defines as the same thing). Other tailored operations are OPTIONAL. 4.3.1. (384) Unicode Uppercase This rule applies Unicode Uppercase Mapping to the input: toLowercase(X). 4.3.2. (385) Unicode Lowercase This rule applies Unicode Uppercase Mapping to the input: toLowercase(X). 4.3.3. (386) Unicode Titlecase This rule applies Unicode Titlecase Mapping to the input: toTitlecase(X). A conformant implementation MAY implement this rule. 4.3.4. (387) Unicode Case Folding This rule applies Unicode Case Folding to the input: toCasefold(X). 4.3.5. (388) Unicode NFKC Case Folding This rule applies Unicode NFKC Case Folding to the input: toNFKC_Casefold(X). The Unicode Standard recommends using this algorithm "when doing caseless matching of strings interpreted as identifiers." See Section 3.13 of [UNICODE] and [UAX31]. The purpose of this rule is to facilitate "identifier caseless matching": toNFKC_Casefold(NFD(X)). See Conformance Clause D147 of [UNICODE]. To implement identifier caseless matching, specify rule 257 (Section 4.2.2) followed immediately by rule 388 (this rule). 4.4. 512 Range: Various Unicode-Aware Algorithms This rule range is meant for miscellaneous standardized algorithms that apply to characters beyond ASCII. [[TODO: Complete.]] Leonard Expires April 15, 2016 [Page 11] Internet-Draft DANE ALPS October 2015 4.4.1. (512) IDNA Dot Folding This rule maps the following characters in the input to "." U+002E FULL STOP: o U+FF0E FULLWIDTH FULL STOP o U+3002 IDEOGRAPHIC FULL STOP o U+FF61 HALFWIDTH IDEOGRAPHIC FULL STOP The purpose of this rule is to implement similar behavior on the local-part side as on the domain side of an address, by treating "label-separators" similarly. See Section 6 of [UTS46]. 4.5. 768 Range: PRECIS Framework Rules [[TODO: complete. This section is meant for PRECIS-related rules that do not fall in the rules listed above.]] 5. Example "helOMy.wo\"rld+top\!seCreT"@example.com The C in "seCret" actually refers to the Unicode code points U+0043 LATIN CAPITAL LETTER C, and U+0327 COMBINING CEDILLA. Figure 1: Example Email Addresss (addr-spec) An example address is provided above. The UTF-8 encoding of the abstract character represented by "C" is 43 CC A7. example.com. IN ALPR ( 1 5 "+-" 3 "." 4 33 47 258 ) This record is stored at example.com. Figure 2: Example ALPR Record In Figure 2, the first rule is ASCII lowercase mapping, the second rule is subaddress truncation with + and - as delimiters, the third rule is character removal of the period U+002E, the fourth rule Leonard Expires April 15, 2016 [Page 12] Internet-Draft DANE ALPS October 2015 ostensibly is range removal, and the fifth rule is Unicode normalization to Form KC. From the input, the local-part string is "helOMy.wo"rld+top!seCreT" (note the single embedded U+0022 QUOTATION MARK). Rules 1, 5, 3, and 258 will be applied to it in that order; Rule 4 will not be applied because the parameter data is malformed (Rule 4 only accepts a single string parameter). Rule 1 Rule 5 Rule 3 Rule 4 Rule 258 helOMy.wo"rld+top!seCreT ------+------------------+----------------> \ \ \ \ \ \ \ helOMy.wo"rld+top!se[C]reT --> \ \ \ (C3 87) \ \ helOMywo"rld+top!seCret ---+----------------> \ \ \ \ \ helOMywo"rld+top!se[C]reT --> \ \ \ helOMy.wo"rld --+-----------------------------------> \ \ \ helOMywo"rld ----------------------------> \ helomy.wo"rld+top!secret -+------------------+----------------> \ (63 CC A7) \ \ \ \ helomy.wo"rld+top!se[c]ret --> \ \ (C3 A7) \ helomywo"rld+top!secret -----+----------------> \ \ \ helomywo"rld+top!se[c]ret --> \ \ helomy.wo"rld --+-----------------------------------> \ helomywo"rld -------------------------> Alternative Local-Part Synthesis Tree, producing 12 results out of 32 theoretically possible results (16 possible results after eliminating Rule 4). ALPS Tree Rule 1 outputs lowercase in the ASCII range: O becomes o, M becomes m, T becomes t, and C with cedilla combining character becomes c with cedilla combining character (UTF-8: 63 CC A7). Note that if "C" were the precomposed character U+00C7 LATIN CAPITAL LETTER C WITH CEDILLA, it would not have been affected by Rule 1. Rules 1 and 2 do not distinguish combining character sequences. Leonard Expires April 15, 2016 [Page 13] Internet-Draft DANE ALPS October 2015 Rule 5 chops off the sub-address after the + plus sign. Now we have 4 local-parts (the maximum possible). Rule 3 removes the dot. Now we have 8 local-parts (the maximum possible). Rule 4 is skipped because it is malformed. Rule 258 normalizes the local-parts, converting the C or c with cedilla respectively to U+00C7 LATIN CAPITAL LETTER C WITH CEDILLA (UTF-8: C3 87) or U+00E7 LATIN SMALL LETTER C WITH CEDILLA (UTF-8: C3 A7). Because Rule 5 chopped off that sequence in its alternatives, now we have only 4 additional local-parts--12 total. 6. IANA Considerations 6.1. ALPR RRtype This document uses a new DNS RRtype, ALPR, whose value will be allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry. Leonard Expires April 15, 2016 [Page 14] Internet-Draft DANE ALPS October 2015 A. Submission Date: 2015-10-10 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter: Name: Sean Leonard Email Address: dev+ietf@seantek.com International telephone number: Other contact handles: D. Motivation for the new RRTYPE application? Support for the document draft-seantek-dane-alps. E. Description of the proposed RR type. See draft-ietf-dane-alps for a complete description. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? None. G. What mnemonic is requested for the new RRTYPE (optional)? ALPR H. Does the requested RRTYPE make use of any existing IANA Registry or require the creation of a new IANA sub-registry in DNS Parameters? Yes: a sub-registry for rules. [[TBD.]] I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: The document is an Internet-Draft for discussion in the DANE WG. 7. Security Considerations DNS zones that are signed with DNSSEC can be used to authenticate the ALPR resource records. For auditability purposes, an auditor needs to include both the key-mailbox association records (e.g., SMIMEA and OPENPGPKEY), and ALPR resource records. Leonard Expires April 15, 2016 [Page 15] Internet-Draft DANE ALPS October 2015 8. References 8.1. Normative References [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 8.0.0", ISBN 978-1-936213-10-8, August 2015. Mountain View, CA: The Unicode Consortium. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [BCP47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [SMIMEA] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", draft-ietf-dane-smime-09 (work in progress), August 2015. [OPENPGPKEY] Wouters, P., "Using DANE to Associate OpenPGP public keys with email addresses", draft-ietf-dane-openpgpkey-05 (work in progress), August 2015. 8.2. Informative References [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, . Leonard Expires April 15, 2016 [Page 16] Internet-Draft DANE ALPS October 2015 [DNSMBOX] Levine, J., "Encoding mailbox local-parts in the DNS", draft-levine-dns-mailbox-01 (work in progress), September 2015. [UAX31] Davis, M., "Unicode Identifier and Pattern Syntax", UAX #31, June 2015, . [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility Processing", UTS #46, June 2015, . Author's Address Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 USA Email: dev+ietf@seantek.com URI: http://www.penango.com/ Leonard Expires April 15, 2016 [Page 17]