Internet DRAFT - draft-seantek-dane-alps
draft-seantek-dane-alps
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, <http://www.rfc-editor.org/info/rfc1035>.
[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,
<http://www.rfc-editor.org/info/rfc5321>.
[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, <http://www.rfc-editor.org/info/rfc5646>.
[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, <http://www.rfc-editor.org/info/rfc6698>.
[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, <http://www.rfc-editor.org/info/rfc6530>.
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, <http://unicode.org/reports/tr31/>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", UTS #46, June 2015,
<http://www.unicode.org/reports/tr46/>.
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]