From 772ef7e81553e7c1fd76fd40ea2d0044ae278492 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 4 Dec 2001 02:06:09 +0000 Subject: [PATCH] updates --- ....txt => draft-ietf-dnsext-dhcid-rr-04.txt} | 228 ++--- doc/draft/draft-ietf-dnsext-ecc-key-01.txt | 829 ++++++++++++++++++ ...txt => draft-ietf-idn-requirements-09.txt} | 375 ++++---- 3 files changed, 1133 insertions(+), 299 deletions(-) rename doc/draft/{draft-ietf-dnsext-dhcid-rr-03.txt => draft-ietf-dnsext-dhcid-rr-04.txt} (78%) create mode 100644 doc/draft/draft-ietf-dnsext-ecc-key-01.txt rename doc/draft/{draft-ietf-idn-requirements-05.txt => draft-ietf-idn-requirements-09.txt} (63%) diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-04.txt similarity index 78% rename from doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt rename to doc/draft/draft-ietf-dnsext-dhcid-rr-04.txt index 1ae89ddb6e..e5aae97cef 100644 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-04.txt @@ -2,14 +2,14 @@ DNSEXT Working Group M. Stapp Internet-Draft Cisco Systems, Inc. -Expires: January 18, 2002 T. Lemon +Expires: May 22, 2002 T. Lemon A. Gustafsson Nominum, Inc. - July 20, 2001 + November 21, 2001 A DNS RR for Encoding DHCP Information (DHCID RR) - + Status of this Memo @@ -32,7 +32,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 18, 2002. + This Internet-Draft will expire on May 22, 2002. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Stapp, et. al. Expires January 18, 2002 [Page 1] +Stapp, et. al. Expires May 22, 2002 [Page 1] -Internet-Draft The DHCID RR July 2001 +Internet-Draft The DHCID RR November 2001 Table of Contents @@ -62,17 +62,17 @@ Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 4 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 4 - 3.5 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5 - 3.6 Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 5 - 3.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 @@ -108,9 +108,9 @@ Table of Contents -Stapp, et. al. Expires January 18, 2002 [Page 2] +Stapp, et. al. Expires May 22, 2002 [Page 2] -Internet-Draft The DHCID RR July 2001 +Internet-Draft The DHCID RR November 2001 1. Terminology @@ -157,18 +157,21 @@ Internet-Draft The DHCID RR July 2001 3. The DHCID RR - The DHCID RR is defined with mnemonic DHCID and type code [TBD]. + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The + DHCID RR is only defined in the IN class. DHCID RRs cause no + additional section processing. The DHCID RR is not a singleton type. + + + + +Stapp, et. al. Expires May 22, 2002 [Page 3] + +Internet-Draft The DHCID RR November 2001 + 3.1 DHCID RDATA format The RDATA section of a DHCID RR in transmission contains RDLENGTH - - -Stapp, et. al. Expires January 18, 2002 [Page 3] - -Internet-Draft The DHCID RR July 2001 - - bytes of binary data. The format of this data and its interpretation by DHCP servers and clients are described below. @@ -186,11 +189,11 @@ Internet-Draft The DHCID RR July 2001 3.2 DHCID Presentation Format In DNS master files, the RDATA is represented as a single block in - base 64 encoding and may be divided up into any number of white + base 64 encoding identical to that used for representing binary data + in RFC2535[7]. The data may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to form the complete RDATA. These substrings can span - lines using the standard parentheses. This format is identical to - that used for representing binary data in RFC2535[7]. + lines using the standard parentheses. 3.3 The DHCID RR Type Codes @@ -213,23 +216,41 @@ Internet-Draft The DHCID RR July 2001 3.4 Computation of the RDATA - The data following the type code (for type codes other than 0xFFFF) - is derived by running the MD5 hash algorithm across a buffer - containing the identifying information. The identifying information - includes some data from the DHCP client's DHCPREQUEST message, and - the FQDN which is the target of the update. + The DHCID RDATA is formed by concatenating the two type bytes with + some variable-length identifying data. -Stapp, et. al. Expires January 18, 2002 [Page 4] +Stapp, et. al. Expires May 22, 2002 [Page 4] -Internet-Draft The DHCID RR July 2001 +Internet-Draft The DHCID RR November 2001 - The domain name is represented in the buffer in dns wire-format as - described in RFC1035[5], section 3.1. The domain name MUST NOT be - compressed as described in RFC1035[5], section 4.1.4. Any uppercase - alphabetic ASCII character in a label MUST be converted to lowercase - before being used to compute the hash. + < type > < data > + + The RDATA for all type codes other than 0xffff, which is reserved + for future expansion, is formed by concatenating the two type bytes + and a 16-byte MD5 hash value. The input to the hash function is + defined to be: + + data = MD5(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC2535[7], section 8.1. The type code and the + identifier are related as specified in Section 3.3: the type code + describes the source of the identifier. + + type code identifier + + 0x0000 htype,hlen,chaddr from the client's DHCPREQUEST + + 0x0001- 'data' portion of a DHCP option from the + 0xfffe client's DHCPREQUEST + + 0xffff RESERVED + + The "Resolution of DNS Name Conflicts"[1] specification describes + the selection process that updaters follow to choose an identifier + from the information presented in a client's DHCPREQUEST message. When the updater is using the client's link-layer address as the identifier, the first two bytes of the DHCID RDATA MUST be zero. To @@ -253,13 +274,47 @@ Internet-Draft The DHCID RR July 2001 decimal. The rest of the DHCID RR MUST contain the results of computing an MD5 hash across the payload of the option being used, followed by the FQDN. The payload of a DHCP option consists of the + + +Stapp, et. al. Expires May 22, 2002 [Page 5] + +Internet-Draft The DHCID RR November 2001 + + bytes of the option following the option code and length. - The "Resolution of DNS Name Conflicts"[1] specification describes - the selection process that updaters follow to choose an identifier - from the information presented in a client's DHCPREQUEST message. +3.5 Examples -3.5 Use of the DHCID RR +3.5.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.example.com" uses the client's link-layer address to + identify the client. The DHCID RDATA is composed by setting the two + type bytes to zero, and performing an MD5 hash computation across a + buffer containing the Ethernet MAC type byte, 0x01, the six bytes of + MAC address, and the domain name (represented as specified in + Section 3.4). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + +3.5.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client + which included the DHCP client-identifier option data + 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the + name "chi.example.com" on the client's behalf, and uses the DHCP + client identifier option data as input in forming a DHCID RR. The + DHCID RDATA is formed by setting the two type bytes to the option + code, 0x003d, and performing an MD5 hash computation across a buffer + containing the seven bytes from the client-id option and the FQDN + (represented as specified in Section 3.4). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID AD3dquu0xNqYn/4zw2FXy8X3 + +4. Use of the DHCID RR This RR MUST NOT be used for any purpose other than that detailed in "Resolution of DNS Name Conflicts"[1]. Although this RR contains @@ -268,7 +323,7 @@ Internet-Draft The DHCID RR July 2001 Therefore, new data formats may only be defined through actions of the DHC Working Group, as a result of revising [1]. -3.6 Updater Behavior +5. Updater Behavior The data in the DHCID RR allows updaters to determine whether more than one DHCP client desires to use a particular FQDN. This allows @@ -276,9 +331,10 @@ Internet-Draft The DHCID RR July 2001 RR does not establish any policy itself. -Stapp, et. al. Expires January 18, 2002 [Page 5] + +Stapp, et. al. Expires May 22, 2002 [Page 6] -Internet-Draft The DHCID RR July 2001 +Internet-Draft The DHCID RR November 2001 Updaters use data from a DHCP client's request and the domain name @@ -292,51 +348,13 @@ Internet-Draft The DHCID RR July 2001 administrative policy. That policy might dictate that a different name be selected, or it might permit the updater to continue. -3.7 Examples - -3.7.1 Example 1 - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client with - Ethernet MAC address 01:02:03:04:05:06 using domain name - "client.org.nil" uses the client's link-layer address to identify - the client. The DHCID RDATA is composed by setting the two type - bytes to zero, and performing an MD5 hash computation across a - buffer containing the Ethernet MAC type byte, 0x01, the six bytes of - MAC address, and the domain name (represented as specified in - Section 3.4). - - client.org.nil. A 10.0.0.1 - client.org.nil. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU - -3.7.2 Example 2 - - A DHCP server allocates the IPv4 address 10.0.12.99 to a client - which included the DHCP client-identifier option data - 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the - name "chi.org.nil" on the client's behalf, and uses the DHCP client - identifier option data as input in forming a DHCID RR. The DHCID - RDATA is formed by setting the two type bytes to the option code, - 0x003d, and performing an MD5 hash computation across a buffer - containing the seven bytes from the client-id option and the FQDN - (represented as specified in Section 3.4). - - chi.org.nil. A 10.0.12.99 - chi.org.nil. DHCID AD3dquu0xNqYn/4zw2FXy8X3 - -4. Security Considerations +6. Security Considerations The DHCID record as such does not introduce any new security problems into the DNS. In order to avoid exposing private information about DHCP clients to public scrutiny, a one-way hash is used to obscure all client information. In order to make it difficult to 'track' a client by examining the names associated with - - -Stapp, et. al. Expires January 18, 2002 [Page 6] - -Internet-Draft The DHCID RR July 2001 - - a particular hash value, the FQDN is included in the hash computation. Thus, the RDATA is dependent on both the DHCP client identification data and on each FQDN associated with the client. @@ -346,7 +364,7 @@ Internet-Draft The DHCID RR July 2001 and servers SHOULD use some form of update authentication (e.g., TSIG[9]) when performing DNS updates. -5. IANA Considerations +7. IANA Considerations IANA is requested to allocate an RR type number for the DHCID record type. @@ -368,6 +386,13 @@ References [5] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, Nov 1987. + + +Stapp, et. al. Expires May 22, 2002 [Page 7] + +Internet-Draft The DHCID RR November 2001 + + [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992. @@ -382,17 +407,6 @@ References 2845, May 2000. - - - - - - -Stapp, et. al. Expires January 18, 2002 [Page 7] - -Internet-Draft The DHCID RR July 2001 - - Authors' Addresses Mark Stapp @@ -430,23 +444,9 @@ Authors' Addresses - - - - - - - - - - - - - - -Stapp, et. al. Expires January 18, 2002 [Page 8] +Stapp, et. al. Expires May 22, 2002 [Page 8] -Internet-Draft The DHCID RR July 2001 +Internet-Draft The DHCID RR November 2001 Full Copyright Statement @@ -500,5 +500,5 @@ Acknowledgement -Stapp, et. al. Expires January 18, 2002 [Page 9] +Stapp, et. al. Expires May 22, 2002 [Page 9] diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-01.txt b/doc/draft/draft-ietf-dnsext-ecc-key-01.txt new file mode 100644 index 0000000000..9aea879dc4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-01.txt @@ -0,0 +1,829 @@ + +INTERNET-DRAFT ECC Keys in the DNS +Expires: May 2002 November 2001 + + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list or to the + authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + A standard method for storing elliptic curve cryptographic keys in + the Domain Name System is described which utilizes DNS KEY resource + record. + + + + + + + + + + +R. Schroeppel, et al [Page 1] + + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve KEY Resource Records.....................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Performance Considerations.............................11 + 6. Security Considerations................................11 + 7. IANA Considerations....................................11 + + References................................................13 + + Authors' Addresses........................................14 + Expiration and File Name..................................14 + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 2535]. Thus + the DNS can now be secured and used for key distribution. + + This document describes how to store elliptic curve cryptographic + (ECC) keys in the DNS so they can be used for a variety of security + purposes. A DNS elliptic curve SIG resource record is not defined. + Familiarity with ECC cryptography is assumed [Menezes]. + + 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]. + + + +2. Elliptic Curve KEY Resource Records + + Elliptic curve public keys are stored in the DNS as KEY RRs using + algorithm number 4 (see [RFC 2535]). The structure of the RDATA + portion of this RR is as shown below. The first 4 octets, including + the flags, protocol, and algorithm fields are common to all KEY RRs. + The remainder is the "public key" part of the KEY RR. + + The period of key validity is not in the KEY RR but is indicated by + the SIG RR(s) which signs and authenticates the KEY RR(s) at that + domain name and class. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, we have defined + representations for every type of finite field, and every type of + elliptic curve. The reader should be aware that there is a unique + finite field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + +R. Schroeppel, et al [Page 3] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + + +R. Schroeppel, et al [Page 4] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + +R. Schroeppel, et al [Page 5] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of KEY RR and MUST + be ignored when processing a KEY RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range [0,P- + 1]. The coefficients are packed into fixed-width fields, from higher + order to lower order. All coefficients must be present, including + any 0s and also the leading coefficient (which is required to be 1). + The coefficients are right justified into the octet string of length + specified by LF, with the low-order "constant" coefficient at the + right end. As a concession to storage efficiency, the higher order + bits of the leading coefficient may be elided, discarding high-order + 0 octets and reducing LF. The degree is calculated by determining + + +R. Schroeppel, et al [Page 6] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + the bit position of the left most 1-bit in the F data (counting the + right most bit as position 0), and dividing by ceiling(log2 P). The + division must be exact, with no remainder. In this format, all of + the other degree and field parameters are omitted. The next + parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial + of degree D is X^D (which is not irreducible). The next is X^D+1, + which is sometimes irreducible, followed by X^D-1, which isn't. + Assuming odd P, this series continues to X^D - (P-1)/2, and then goes + to X^D + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than RSA + and DSA. Creation of a curve is slow, but not done very often. Key + generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of KEY RR sets stored within the DNS + consistent with adequate security. Keep in mind that in a secure + zone, an authenticating SIG RRset will also be returned. + + + +6. Security Considerations + + Many of the general security consideration in [RFC 2535] apply. Some + specific key generation considerations are given above. Of course, + the elliptic curve key stored in the DNS for an entity should not be + trusted unless it has been obtain via a trusted DNS resolver that + vouches for its security or unless the application using the key has + done a similar authentication. + + + +7. IANA Considerations + + Assignment of meaning to the remaining ECC KEY flag bits or to values + of ECC fields outside the ranges for which meaning in defined in this + document requires an IETF consensus as defined in [RFC 2434]. + + This specification uses algorithm number 4 for DNS elliptic curve KEY + + +R. Schroeppel, et al [Page 11] + + + +INTERNET-DRAFT ECC Keys in the DNS + + + RRs that was reserved for this purpose in RFC 2535. An elliptic + curve (algorithm = 4) SIG RR is not defined and is reserved. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 12] + + + +INTERNET-DRAFT ECC Keys in the DNS + + +References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", + March 1999. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", + 1986, Springer Graduate Texts in mathematics #106. + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 13] + + + +INTERNET-DRAFT ECC Keys in the DNS + + +Authors' Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: 1-801-423-7998(h) + 1-505-844-9079(w) + Email: rcs@cs.arizona.edu + rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-634-2066(h) + +1 508-261-5434(w) + FAX: +1 508-261-4447(w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in May 2002. + + Its file name is draft-ietf-dnsext-ecc-key-01.txt. + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + + + + diff --git a/doc/draft/draft-ietf-idn-requirements-05.txt b/doc/draft/draft-ietf-idn-requirements-09.txt similarity index 63% rename from doc/draft/draft-ietf-idn-requirements-05.txt rename to doc/draft/draft-ietf-idn-requirements-09.txt index 9bac79e018..ad6e18d494 100644 --- a/doc/draft/draft-ietf-idn-requirements-05.txt +++ b/doc/draft/draft-ietf-idn-requirements-09.txt @@ -1,13 +1,13 @@ IETF IDN Working Group Editors Zita Wenzel, James Seng -Internet Draft draft-ietf-idn-requirements-05.txt -24 April 2001 Expires 24 October 2001 +Internet Draft draft-ietf-idn-requirements-09.txt +21 November 2001 Expires 21 May 2002 Requirements of Internationalized Domain Names Status of this Memo This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. +all provisions of Section 10 of RFC 2026 [8]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -15,7 +15,7 @@ other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six -months and may be updated, replaced, or obsoleted by other +months and may be updated, replaced, or made obsolete 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." @@ -34,7 +34,7 @@ intended to document user requirements. It is recommended that solutions not necessarily be within the DNS itself, but could be a layer interjected between the application and the DNS. Proposals SHOULD fulfill most, if not all, of the requirements. This document MAY be -updated based on clinical trials. +updated based on actual trials. Abstract @@ -46,11 +46,15 @@ developing protocols for internationalized domain names. At present, the encoding of Internet domain names is restricted to a subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many -other text based items on the Internet have already been at least +other text based protocols on the Internet have already been at least partially internationalized. It is important for domain names to be similarly internationalized or for an equivalent solution to be found. This document assumes that the most effective solution involves putting -non-ASCII names inside some parts of the overall DNS system. +non-ASCII names inside some parts of the overall DNS system although +this assumption may not be the consensus of the IETF community. +However, several sections of this document, including "Definitions and +Conventions" should be useful in any case. A reasonable familiarity +with DNS terminology is assumed in this document. This document is being discussed on the "idn" mailing list. To join the list, send a message to with the words @@ -59,7 +63,7 @@ list can also be found at ftp://ops.ietf.org/pub/lists/idn*. 1.1 Definitions and Conventions -A language is a way that humans interact. In computerised form, a text +A language is a way that humans interact. In computerized form, a text in a written language can be expressed as a string of characters. The same set of characters can often be used for many written languages, and many written languages can be expressed using different scripts. @@ -68,37 +72,40 @@ The same characters are often shown with somewhat different glyphs automatic shaping applied, or the automatic formation of ligatures. In addition, the same characters can be shown with somewhat different glyphs (shapes) for display of a text depending on the language being -used, even within the same font or trough automatic font change. +used, even within the same font or through automatic font change. -A character is a member of a set of elements used for organization, -control, or representation of textual data. +Character: A character is a member of a set of elements used for +organization, control, or representation of textual data. -A graphic character is a character, other than a control function, -that has a visual representation normally handwritten, printed, or -displayed. +Graphic character: A graphic character is a character, other than a +control function, that has a visual representation normally +handwritten, printed, or displayed. Characters mentioned in this document are identified by their position -in the Unicode [UNICODE] character set. This character set is also -known as the UCS [ISO10646]. The notation U+12AB, for example, indicates -the character at position 12AB (hexadecimal) in the Unicode character -set. Note that the use of this notation is not an indication of a -requirement to use Unicode. +in the Unicode character set. This character set is also +known as the UCS (ISO 10646) [19]. The notation U+12AB, for example, +indicates the character at position 12AB (hexadecimal) in the Unicode +character set. Note that the use of this notation is not an +indication of a requirement to use Unicode. Examples quoted in this document should be considered as a method to further explain the meanings and principles adopted by the document. It is not a requirement for the protocol to satisfy the examples. -Unicode Technical Report 17 [UTR17] defines a character encoding +Unicode Technical Report #17 [24] defines a character encoding model in several levels (much of the text below is quoted from -Unicode Technical Report 17 [UTR17]): +Unicode Technical Report #17). + +[N.B. Sections 1-6 below to be unpacked and and reworded to be +independent of the Unicode Technical Report #17.] 1. A abstract character repertoire (ACR) is defined as the set of abstract characters to be encoded, normally a familiar alphabet or symbol set. The word abstract just means that these objects are defined by convention (such as the 26 letters of the English alphabet, uppercase and lowercase forms). Examples: the ASCII - repertoire, the Latin-15 repertoire, the JIS X 0208 repertoire, - the UCS repertiore (of a particular version). + repertoire, the Latin 9 repertoire, the JIS X 0208 repertoire, + the UCS repertoire (of a particular version). 2. A coded character set (CCS) is defined to be a mapping from a set of abstract characters to the set of non-negative integers. @@ -124,17 +131,16 @@ Unicode Technical Report 17 [UTR17]): into the byte polarity canonical for a particular platform. The CES may involve two or more CCS's, and may include code units - (e.g. single shifts, SI/SO, or escape sequences) that are not part + (e.g., single shifts, SI/SO, or escape sequences) that are not part of the CCS per se, but which are defined by the character encoding architecture and which may require an external registry of particular values (as for the ISO 2022 escape sequences). In such a case, the CES is called a compound CES. (A CES that only involves a single - CCS is called a simple CES.) - - Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8. + CCS is called a simple CES.) Examples: ASCII, Latin-15, Shift-JIS, + UTF-16BE, UTF-16LE, UTF-8. 5. The mapping from an abstract character repertoire (ACR) to a - serialised sequence of octets is called a Character Map (CM). A simple + serialized sequence of octets is called a Character Map (CM). A simple character map thus implicitly includes a CCS, a CEF, and a CES, mapping from abstract characters to code units to octets. A compound character map includes a compound CES, and thus includes more than one @@ -142,48 +148,48 @@ Unicode Technical Report 17 [UTR17]): character map is the union of the repertoires covered by the coded character sets involved. - Character Maps are the things that in the IAB architecture get IANA - charset identifiers. A sequence of encoded characters must be - unambiguously mapped onto a sequence of octets by the charset. The - charset must be specified in all instances, as in Internet - protocols, where textual content is treated as a ordered sequence - of octets, and where the textual content must be reconstructible - from that sequence of octets. Charset names are registered by the - IANA according to procedures documented in [RFC2278]. In many cases, - the same name is used for both a character map and for a character - encoding scheme, such as UTF-16BE. Typically this is done for simple - character maps when such usage is clear from context. + A sequence of encoded characters must be unambiguously + mapped onto a sequence of octets by the charset. The charset must be + specified in all instances, as in Internet protocols, where textual + content is treated as an ordered sequence of octets, and where the + textual content must be reconstructible from that sequence of + octets. Charset names are registered by the IANA according to + procedures documented in RFC 2278 [12]. In many cases, the same + name is used for both a character map and for a character encoding + scheme, such as UTF-16BE. Typically this is done for simple + character maps when such usage is clear from context. 6. A transfer encoding syntax (TES) is a reversible transform of encoded data which may (or may not) include textual data represented in - one or more character encoding schemes. Examples: 8bit, - Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE). + one or more character encoding schemes. Examples: 8bit, + Quoted-Printable, BASE64, UTF-7 (defunct), UTF-5, and RACE. 1.2 Description of the Domain Name System -The Domain Name System is defined by [RFC1034] and [RFC1035], with -clarifications, extensions and modifications given in [RFC1123], -[RFC1996], [RFC2181], and others. Of special importance here is the -security extensions described in [RFC2535] and companions. +The Domain Name System is defined by RFC 1034 [4] and RFC 1035 [5], with +clarifications, extensions and modifications given in RFC 1123 [6], +RFC 1996 [7], RFC 2181 [10], and others. Of special importance here are the +security extensions described in RFC 2535 [14] and related RFCs. Over the years, many different words have been used to describe the components of resource naming on the Internet (e.g., URI, URN); to make certain that the set of terms used in this document are well-defined and non-ambiguous, the definitions are given here. -A master server for a zone holds the main copy of that zone. This copy -is sometimes stored in a zone file. A slave server for a zone holds a -complete copy of the records for that zone. Slave servers MAY be either -authorized by the zone owner (secondary servers) or unauthorized -(so-called "stealth secondaries"). Master and authorized slave servers -are listed in the NS records for the zone, and are termed -"authoritative" servers. In many contexts, outside this document the -term "primary" is used interchangeably with "master" and "secondary" is -used interchangeably with "slave". +Master server: A master server for a zone holds the main copy of that +zone. This copy is sometimes stored in a zone file. A slave server for +a zone holds a complete copy of the records for that zone. Slave +servers MAY be either authorized by the zone owner (secondary servers) +or unauthorized (sometimes called "stealth secondaries"). Master and +authorized slave servers are listed in the NS records for the zone, +and are termed "authoritative" servers. In many contexts outside this +document, the term "primary" is used interchangeably with "master" and +"secondary" is used interchangeably with "slave". -A caching server holds temporary copies of DNS records; it uses records -to answer queries about domain names. Further explanation of these terms -can be found in [RFC1034] and [RFC1996]. +Caching server: A caching server holds temporary copies of DNS +records; it uses records to answer queries about domain names. Further +explanation of these terms can be found in RFC 1034 [4] and RFC 1996 +[7]. DNS names can be represented in multiple forms, with different properties for internationalization. The most important ones are: @@ -195,39 +201,42 @@ properties for internationalization. The most important ones are: - Master file format domain name: This is a representation of the name as a sequence of characters in some character sets; the common - convention (derived from [RFC1035] section 5.1) is to represent the + convention (derived from RFC 1035 [5] section 5.1) is to represent the octets of the name as ASCII characters where the octet is in the set - corresponding to the ASCII values for [a-zA-Z0-9-], using an escape + corresponding to the ASCII values for [a-z,A-Z,0-9,-], using an escape mechanism (\x or \NNN) where not, and separating the components of the name by the dot character ("."). The form specified for most protocols using the DNS is a limited form of the master file format domain name. This limited form is defined in -[RFC1034] Section 3.5 and [RFC1123]. In most implementations of +RFC 1034 [4] Section 3.5 and RFC 1123 [6]. In most implementations of applications today, domain names in the Internet have been limited to -the much more restricted forms used, e.g., in email. Those names are -limited to the upper- and lower-case letters a-z (interpreted in a -case-independent fashion), the digits, and the hyphen-minus, all in -ASCII. +the much more restricted forms used, e.g., in email, which defines its +own rules. Those names are limited to the upper- and lower-case +letters a-z (interpreted in a case-independent fashion), the digits, +and the hyphen-minus, all in ASCII. 1.3 Definition of "hostname" and "Internationalized Domain Name" +Hostname: + In the DNS protocols, a name is referred to as a sequence of octets. However, when discussing requirements for internationalized domain names, what we are looking for are ways to represent characters that are meaningful for humans. -In this document, this is referred to as a "hostname". While this term -has been used for many different purposes over the years, it is used -here in the sense of sequence of characters (not octets) representing a -domain name conforming to the limited hostname syntax [RFC952]. +Internationalized Domain Name: -This document attempts to define the requirements for an -"Internationalized Domain Name" (IDN). This is defined as a sequence of -characters that can be used in the context of functions where a hostname -is used today, but contains one or more characters that are outside the -set of characters specified as legal characters for host names -[RFC1123]. +In this document, this representation is referred to as a +"hostname". While this term has been used for many different purposes +over the years, it is used here in the sense of sequence of characters +(not octets) representing a domain name conforming to the limited +hostname syntax specified in RFC 952 [3]. This document attempts to +define the requirements for an "Internationalized Domain Name" +(IDN). IDN is defined as a sequence of characters that can be used in +the context of functions where a hostname is used today, but contains +one or more characters that are outside the set of characters +specified as legal characters for host names RFC 1123 [6]. 1.4 A multilayer model of the DNS function @@ -240,16 +249,16 @@ The DNS can be seen as a multilayer function: - Above that is the "DNS service", created by an infrastructure of DNS servers, NS records that point to those DNS servers, that is pointed to by the root servers (listed in the "root cache file" on - each DNS server, often called "named.cache". It is at this level - that the statement "the DNS has a single root" [RFC2826] makes - sense, but still, what are being transferred are octets, not + each DNS server often called "named.cache"). It is at this level + that the statement "the DNS has a single root" RFC 2826 [17] makes + sense, but still, what is being transferred are octets, not characters. - Interfacing to the user is a service layer, often called "the resolver - library", and often embedded in the operating system or system + library". It is often embedded in the operating system or system libraries of the client machines. It is at the top of this layer that the API calls commonly known as "gethostbyname" and "gethostbyaddress" - reside. These calls are modified to support IPv6 [RFC2553]. A + reside. These calls are modified to support IPv6 RFC 2553 [15]. A conceptually similar layer exists in authoritative DNS servers, comprising the parts that generate "meaningful" strings in DNS files. Due to the popularity of the "master file" format, this layer often @@ -299,27 +308,27 @@ The most used ones in the current DNS are: - Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get back an IPv4 or IPv6 address. -- Hostname-to-Mail server service (MX): As above, but the expected +- Hostname-to-mail server service (MX): As above, but the expected return value is a hostname and a priority for SMTP servers. - Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in - in-addr.arpa or ip6.int form respectively) and get back a hostname. + in-addr.arpa. or ip6.arpa form respectively) and get back a hostname. - Domain delegation service (NS). Enter a domain name and get back - nameserver records (designated hosts who provides authoritive + nameserver records (designated hosts which provide authoritive nameservice) for the domain. New services are being defined, either as entirely new services (IPv6 to hostname mapping using binary labels) or as embellishments to other -services (DNSSEC returning information about whether a given DNS service -is performed securely or not). +services such as DNS Security (DNSSEC) [14], returning information +about whether a given DNS service is performed securely or not). These services exist, conceptually, at the Application/Resolver interface, NOT at the DNS-service interface. This document attempts to set requirements for an equivalent of the "used services" given above, where "hostname" is replaced by "Internationalized Domain Name". This -doesn't preclude the fact that IDN should work with any kind of DNS -queries. IDN is a new service. Since existing protocols like SMTP or +does not preclude the fact that IDN should work with any kind of DNS +queries. IDN is a new service. Since existing protocols like SMTP or HTTP use the old service, it is a matter of great concern how the new and old services work together, and how other protocols can take advantage of the new service. @@ -339,21 +348,21 @@ is believed to constrain the possible implementation. [1] The DNS is essential to the entire Internet. Therefore, the service MUST NOT damage present DNS protocol interoperability. It MUST make the minimum number of changes to existing protocols on all layers of the -stack. It MUST continue to allow any system anywhere to resolve any -internationalized domain name. +stack. It MUST continue to allow any system anywhere that implements +the IDN specification to resolve any internationalized domain name. [2] The service MUST preserve the basic concept and facilities of domain -names as described in [RFC1034]. It MUST maintain a single, global, +names as described in RFC 1034 [4]. It MUST maintain a single, global, universal, and consistent hierarchical namespace. [3] The DNS protocol (the packet formats that go on the wire) MUST -NOT limit the codepoints that can be used. A service defined on top of +NOT limit the codepoints that can be used. A service defined on top of the DNS, for instance the IDN-to-address function, MAY limit the -codepoints that can be used. The service descriptions MUST describe +codepoints that can be used. The service descriptions MUST describe what limitations are imposed. [4] The protocol MUST work for all features of DNS, IPv4, and -IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor +IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor that requests the IP-to-(old)-domain-name mapping service. [5] The same name resolution request MUST generate the same response, @@ -362,7 +371,7 @@ the master server, and in any slave servers involved in the resolution process. [6] The protocol MUST NOT require that the current DNS cache -servers be modified to support IDN. If a cache server can have +servers be modified to support IDN. If a cache server can have additional functionality to support IDN better, this additional functionality MUST NOT cause problems for resolving correctly functioning current domain names. @@ -375,10 +384,10 @@ authoritative server. This applies fully for the cases when: - The caching server implements the whole specification - The caching server implements a valid subset of the specification -[8] The service MAY modify the DNS protocol [RFC1035] and other related -work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as -small as possible and any changes SHOULD be coordinated with the -[DNSEXT] WG. +[8] The service MAY modify the DNS protocol RFC 1035 [5] and other related +work undertaken by the DNS Extensions (DNSEXT) [2] working group. However, +these changes SHOULD be as small as possible and any changes SHOULD be +coordinated with the DNSEXT working group. [9] The protocol supporting the service SHOULD be as simple as possible from the user's perspective. Ideally, users SHOULD NOT realize that IDN @@ -390,7 +399,7 @@ requirements in this document. [11] The protocol should handle with care new revisions of the CCS. Undefined codepoints should not be allowed unless a new revision of -the protocol can handle it. Protocol revisions should be tagged. +the protocol can handle it. Protocol revisions should be tagged. 2.2 Internationalization @@ -400,22 +409,23 @@ used when resolving domain names and how characters are encoded in DNS records. [13] Codepoints SHOULD be from the Universal Set as defined in -ISO-10646 or Unicode. The specifics of versions MUST be defined in the -proposed solution. If multiple charsets are allowed, each charset MUST -be tagged and conform to [RFC2277]. +ISO-10646 or Unicode. The specifics of versions MUST be defined in the +proposed solution. If multiple charsets are allowed, each charset MUST +be tagged and conform to RFC 2277 [11]. [14] The protocol MUST NOT reject any non-IDN characters (to be -defined) in any queries or responses. +defined) in any DNS queries or responses. [15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN -only and SHOULD use existing CES. The charset(s) chosen SHOULD also be +only and SHOULD use an existing CES. The charset(s) chosen SHOULD also be non-ambiguous. [16] The protocol SHOULD NOT make any assumptions about the location -in a domain name where internationalization might appear. In other +in a domain name where internationalization might appear. In other words, it SHOULD NOT differentiate between any part of a domain name because this MAY impose restrictions on future internationalization -efforts. For example, the TLDs can be internationalized. +efforts. For example, the Top-Level Domains (TLDs) can be +internationalized. [17] The protocol also SHOULD NOT make any localized restrictions in the protocol. For example, an IDN implementation which only allows domain @@ -428,11 +438,12 @@ domain name input and display, IDN is only concerned with the protocol. Therefore, there MUST be a single way of encoding an internationalized domain name within the DNS. -2.4 Canonicalization +2.3 Canonicalization Matching rules are a complicated process for IDN. Canonicalization of characters MUST follow precise and predictable rules to ensure -consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization. +consistency. "Requirements for String Identity Matching and String +Indexing" is RECOMMENDED as a guide on canonicalization. The DNS has to match a host name in a request with a host name held in one or more zones. It also needs to sort names into order. It is @@ -441,7 +452,7 @@ the first step of this process. This section discusses some of the properties which will be REQUIRED of that algorithm. [19] To achieve interoperability, canonicalization MUST be done at a -single well-defined place in the DNS resolution process. The protocol +single well-defined place in the DNS resolution process. The protocol MUST specify canonicalization; it MUST specify exactly where in the DNS that canonicalization happens and does not happen; it MUST specify how additions to ISO 10646 will affect the stability of the DNS and @@ -450,12 +461,13 @@ the amount of work done on the root DNS servers. [20] The canonicalization algorithm MAY specify operations for case, ligature, and punctuation folding. -[21] In order to retain backwards compatibility with the current DNS, -the service MUST retain the case-insensitive comparison for [US-ASCII] -as specified in [RFC1035]. For example, Latin capital letter A (U+0041) -MUST match Latin small letter a (U+0061). [UTR21] describes some of -the issues with case mapping. Case-insensitivity for non [US-ASCII] -MUST be discussed in the protocol proposal. +[21] In order to retain backward compatibility with the current DNS, +the service MUST retain the case-insensitive comparison for US-ASCII +as specified in RFC 1035 [5]. For example, Latin capital letter A +(U+0041) MUST match Latin small letter a (U+0061). Unicode Technical +Report #21 [25] describes some of the issues with case +mapping. Case-insensitivity for non US-ASCII MUST be discussed in the +protocol proposal. [22] Case folding MUST be locale independent. If it were locale-dependent, then different clients would get different results. @@ -473,18 +485,19 @@ from what the user enters into a client to what the client asks for resolution MUST be done identically on any request from any client. [25] If the charset can be normalized, then it SHOULD be normalized -before it is used in IDN. Normalization SHOULD follow [UTR15]. +before it is used in IDN. Normalization SHOULD follow Unicode +Technical Report #15 [23]. [26] The protocol SHOULD avoid inventing a new normalization form provided a technically sufficient one is available. -2.5 Operational Issues +2.4 Operational Issues [27] Zone files SHOULD remain easily editable. [28] An IDN-capable resolver or server SHALL NOT generate more traffic than a non-IDN-capable resolver or server would when resolving an -ASCII-only domain name. The amount of traffic generated when resolving +ASCII-only domain name. The amount of traffic generated when resolving an IDN SHALL be similar to that generated when resolving an ASCII-only name. @@ -492,15 +505,7 @@ name. DNS. A domain administrator SHOULD be able to create internationalized names as easily as adding current domain names. -[30] Within a single zone, the zone manager MUST be able to define -equivalence rules that suit the purpose of the zone, such as, but not -limited to, and not necessarily, non-ASCII case folding, Unicode -normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or -traditional/simplified Chinese equivalence. Such defined equivalences -MUST NOT remove equivalences that are assumed by (old or -local-rule-ignorant) caches. - -[31] The protocol MUST work with DNSSEC. The protocol MAY break +[30] The protocol MUST work with DNSSEC. The protocol MAY break language sort order. 3. Security Considerations @@ -521,86 +526,86 @@ MUST be throughly understood. 4. References -[CHARREQ] "Requirements for string identity matching and String - Indexing", http://www.w3.org/TR/WD-charreq, July 1998, - World Wide Web Consortium. +[1] World Wide Web Consortium, "Requirements for string identity +matching and String Indexing", http://www.w3.org/TR/WD-charreq, July +1998. -[DNSEXT] "IETF DNS Extensions Working Group", - namedroppers@ops.ietf.org, Olafur Gudmundson, Randy Bush. +[2] Olafur Gudmundson, Randy Bush, "IETF DNS Extensions Working Group" +(DNSEXT), namedroppers@ops.ietf.org. -[RFC952] "DoD Internet Host Table Specification", rfc952.txt, - October 1985, K. Harrenstien, M.K. Stahl, E.J. Feinler. +[3] K. Harrenstien, M.K. Stahl, E.J. Feinler, "DoD Internet Host Table +Specification", RFC 952, October 1985. -[RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt, - November 1987, P. Mockapetris. +[4] P. Mockapetris, "Domain Names - Concepts and Facilities", +RFC 1034, November 1987. -[RFC1035] "Domain Names - Implementation and Specification", - rfc1035.txt, November 1987, P. Mockapetris. +[5] P. Mockapetris, "Domain Names - Implementation and +Specification", RFC 1035, November 1987. -[RFC1123] "Requirements for Internet Hosts -- Application and - Support", rfc1123.txt, October 1989, R. Braden. +[6] R. Braden, "Requirements for Internet Hosts -- Application and +Support", RFC 1123, October 1989. -[RFC1996] "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie. +[7] P. Vixie, "A Mechanism for Prompt Notification of Zone Changes +(DNS NOTIFY)", RFC 1996, August 1996. -[RFC2119] "Key words for use in RFCs to Indicate Requirement - Levels", rfc2119.txt, March 1997, S. Bradner. +[8] S. Bradner, "The Internet Standards Process -- Revision 3", RFC +2026, October 1996. -[RFC2181] "Clarifications to the DNS Specification", rfc2181.txt, - July 1997, R. Elz, R. Bush. +[9] S. Bradner, "Key words for use in RFCs to Indicate Requirement +Levels", RFC 2119, March 1997. -[RFC2277] "IETF Policy on Character Sets and Languages", - rfc2277.txt, January 1998, H. Alvestrand. +[10] R. Elz, R. Bush, "Clarifications to the DNS Specification", +RFC 2181, July 1997. -[RFC2278] "IANA Charset Registration Procedures", rfc2278.txt, - January 1998, N. Freed and J. Postel. +[11] H. Alvestrand, "IETF Policy on Character Sets and Languages", RFC +2277, January 1998. -[RFC2279] "UTF-8, a transformation format of ISO 10646", - rfc2279.txt, F. Yergeau, January 1998. +[12] N. Freed and J. Postel, "IANA Charset Registration Procedures", +RFC 2278, January 1998. -[RFC2535] "Domain Name System Security Extensions", rfc2535.txt, - March 1999, D. Eastlake. +[13] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC +2279, January 1998. -[RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt, - March 1999, R. Gilligan et al. +[14] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, +March 1999. -[RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the - Other Internet protocols", rfc2825.txt, May 2000, - L. Daigle et al. +[15] R. Gilligan et al, "Basic Socket Interface Extensions for IPv6", +RFC 2553, March 1999. -[RFC2826] "IAB Technical Comment on the Unique DNS Root", - rfc2826.txt, May 2000, Internet Architecture Board. +[16] L. Daigle et al, "A Tangled Web: Issues of I18N, Domain Names, +and the Other Internet protocols", RFC 2825, May 2000. -[IDNCOMP] "Comparison of Internationalized Domain Name Proposals", - draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman. +[17] Internet Architecture Board, "IAB Technical Comment on the Unique DNS +Root", RFC 2826, May 2000. -[ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in - preparation), ISO/IEC 10646-2 (in preparation), plus - corrigenda and amendments to these standards. +[18] P. Hoffman, "Comparison of Internationalized Domain Name +Proposals", draft-ietf-idn-compare-00.txt, June 2000. -[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at - http://www.unicode.org/unicode/standard/versions/. +[19] ISO/IEC 10646-1:2000 (note that an amendment 1 is in +preparation), ISO/IEC 10646-2 (in preparation), plus corrigenda and +amendments to these standards. -[UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version - 3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC - 10646-1:2000. Described at http://www.unicode.org/unicode/ - standard/versions/Unicode3.0.html. +[20] The Unicode Consortium, "The Unicode Standard". Described at +http://www.unicode.org/unicode/standard/versions/. -[US-ASCII] Coded Character Set -- 7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986; also: ISO/IEC - 646 (IRV). +[21] The Unicode Consortium, "The Unicode Standard -- Version 3.0", +ISBN 0-201-61633-5. Same repertoire as ISO/IEC 10646-1:2000. Described +at http://www.unicode.org/unicode/standard/versions/Unicode3.0.html. -[UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15, - http://www.unicode.org/unicode/reports/tr15/, 2000-08-31, - M. Davis and M. Duerst, Unicode Consortium. +[22] Coded Character Set -- 7-bit American Standard Code for +Information Interchange, ANSI X3.4-1986; also: ISO/IEC 646 (IRV). -[UTR17] "Character Encoding Model", Unicode Technical Report #17, - http://www.unicode.org/unicode/reports/tr17/, 2000-08-31, - K. Whistler and M. Davis, Unicode Consortium. +[23] M. Davis and M. Duerst, Unicode Consortium, "Unicode +Normalization Forms", Unicode Standard Annex #15, +http://www.unicode.org/unicode/reports/tr15/, 2000-08-31. + +[24] K. Whistler and M. Davis, Unicode Consortium, "Character Encoding +Model", Unicode Technical Report #17, +http://www.unicode.org/unicode/reports/tr17/, 2000-08-31. + +[25] M. Davis, Unicode Consortium, "Case Mappings", Unicode Technical +Report #21, http://www.unicode.org/unicode/reports/tr21/, 2000-09-12. -[UTR21] "Case Mappings", Unicode Technical Report #21, - http://www.unicode.org/unicode/reports/tr21/, 2000-09-12, - M. Davis, Unicode Consortium. 5. Editors' Contact @@ -637,7 +642,7 @@ Andrew Draper Martin Duerst Patrik Faltstrom Ned Freed -Olafur Gudmundsson +Olafur Gudmundsson Paul Hoffman Simon Josefsson Kent Karlsson @@ -647,4 +652,4 @@ Dongman Lee Bill Manning Dan Oscarsson J. William Semich -Yoshiro Yoneda < +Yoshiro Yoneda