upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-06-10 17:50:00 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

updates

Browse source
This commit is contained in:
Mark Andrews 2001-12-04 02:06:09 +00:00
parent 41e50ece38
commit 772ef7e815
3 changed files with 1133 additions and 299 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

228
doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt → doc/draft/draft-ietf-dnsext-dhcid-rr-04.txt
View file

@ -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)
<draft-ietf-dnsext-dhcid-rr-03.txt>
<draft-ietf-dnsext-dhcid-rr-04.txt>
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]

829
doc/draft/draft-ietf-dnsext-ecc-key-01.txt Normal file
View file

@ -0,0 +1,829 @@
INTERNET-DRAFT ECC Keys in the DNS
Expires: May 2002 November 2001
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-01.txt>
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 <namedroppers@internic.com> 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]

375
doc/draft/draft-ietf-idn-requirements-05.txt → doc/draft/draft-ietf-idn-requirements-09.txt
View file

@ -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 <majordomo@ops.ietf.org> 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 <ADRAPER@altera.com>
Martin Duerst <duerst@w3.org>
Patrik Faltstrom <paf@swip.net>
Ned Freed <ned.freed@innosoft.com>
Olafur Gudmundsson <ogud@tislabs.com>
Olafur Gudmundsson <ogud@ogud.com>
Paul Hoffman <phoffman@imc.org>
Simon Josefsson <jas+idn@pdc.kth.se>
Kent Karlsson <keka@im.se>
@ -647,4 +652,4 @@ Dongman Lee <dlee@icu.ac.kr>
Bill Manning <bmanning@ISI.EDU>
Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu>
Yoshiro Yoneda <<yone@nic.ad.jp>
Yoshiro Yoneda <yone@nic.ad.jp>