1 Network Working Group P. Hoffman
2 Request for Comments: 3491 IMC & VPNC
3 Category: Standards Track M. Blanchet
4 Viagenie
5 March 2003
6
7
8 Nameprep: A Stringprep Profile for
9 Internationalized Domain Names (IDN)
10
11 Status of this Memo
12
13 This document specifies an Internet standards track protocol for the
14 Internet community, and requests discussion and suggestions for
15 improvements. Please refer to the current edition of the "Internet
16 Official Protocol Standards" (STD 1) for the standardization state
17 and status of this protocol. Distribution of this memo is unlimited.
18
19 Copyright Notice
20
21 Copyright (C) The Internet Society (2003). All Rights Reserved.
22
23 Abstract
24
25 This document describes how to prepare internationalized domain name
26 (IDN) labels in order to increase the likelihood that name input and
27 name comparison work in ways that make sense for typical users
28 throughout the world. This profile of the stringprep protocol is
29 used as part of a suite of on-the-wire protocols for
30 internationalizing the Domain Name System (DNS).
31
32 1. Introduction
33
34 This document specifies processing rules that will allow users to
35 enter internationalized domain names (IDNs) into applications and
36 have the highest chance of getting the content of the strings
37 correct. It is a profile of stringprep [STRINGPREP]. These
38 processing rules are only intended for internationalized domain
39 names, not for arbitrary text.
40
41 This profile defines the following, as required by [STRINGPREP].
42
43 - The intended applicability of the profile: internationalized
44 domain names processed by IDNA.
45
46 - The character repertoire that is the input and output to
47 stringprep: Unicode 3.2, specified in section 2.
48
49
50
51
52 Hoffman & Blanchet Standards Track [Page 1]
53 RFC 3491 IDN Nameprep March 2003
54
55
56 - The mappings used: specified in section 3.
57
58 - The Unicode normalization used: specified in section 4.
59
60 - The characters that are prohibited as output: specified in section
61 5.
62
63 - Bidirectional character handling: specified in section 6.
64
65 1.1 Interaction of protocol parts
66
67 Nameprep is used by the IDNA [IDNA] protocol for preparing domain
68 names; it is not designed for any other purpose. It is explicitly
69 not designed for processing arbitrary free text and SHOULD NOT be
70 used for that purpose. Nameprep is a profile of Stringprep
71 [STRINGPREP]. Implementations of Nameprep MUST fully implement
72 Stringprep.
73
74 Nameprep is used to process domain name labels, not domain names.
75 IDNA calls nameprep for each label in a domain name, not for the
76 whole domain name.
77
78 1.2 Terminology
79
80 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
81 in this document are to be interpreted as described in BCP 14, RFC
82 2119 [RFC2119].
83
84 2. Character Repertoire
85
86 This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
87
88 3. Mapping
89
90 This profile specifies mapping using the following tables from
91 [STRINGPREP]:
92
93 Table B.1
94 Table B.2
95
96 4. Normalization
97
98 This profile specifies using Unicode normalization form KC, as
99 described in [STRINGPREP].
100
101
102
103
104
105
106
107 Hoffman & Blanchet Standards Track [Page 2]
108 RFC 3491 IDN Nameprep March 2003
109
110
111 5. Prohibited Output
112
113 This profile specifies prohibiting using the following tables from
114 [STRINGPREP]:
115
116 Table C.1.2
117 Table C.2.2
118 Table C.3
119 Table C.4
120 Table C.5
121 Table C.6
122 Table C.7
123 Table C.8
124 Table C.9
125
126 IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
127 The IDNA protocol has additional prohibitions that are checked
128 outside of this profile.
129
130 6. Bidirectional characters
131
132 This profile specifies checking bidirectional strings as described in
133 [STRINGPREP] section 6.
134
135 7. Unassigned Code Points in Internationalized Domain Names
136
137 If the processing in [IDNA] specifies that a list of unassigned code
138 points be used, the system uses table A.1 from [STRINGPREP] as its
139 list of unassigned code points.
140
141 8. References
142
143 8.1 Normative References
144
145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
146 Requirement Levels", BCP 14, RFC 2119, March 1997.
147
148 [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
149 Internationalized Strings ("stringprep")", RFC 3454,
150 December 2002.
151
152 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
153 "Internationalizing Domain Names in Applications
154 (IDNA)", RFC 3490, March 2003.
155
156
157
158
159
160
161
162 Hoffman & Blanchet Standards Track [Page 3]
163 RFC 3491 IDN Nameprep March 2003
164
165
166 8.2 Informative references
167
168 [STD13] Mockapetris, P., "Domain names - concepts and
169 facilities", STD 13, RFC 1034, and "Domain names -
170 implementation and specification", STD 13, RFC 1035,
171 November 1987.
172
173 9. Security Considerations
174
175 The Unicode and ISO/IEC 10646 repertoires have many characters that
176 look similar. In many cases, users of security protocols might do
177 visual matching, such as when comparing the names of trusted third
178 parties. Because it is impossible to map similar-looking characters
179 without a great deal of context such as knowing the fonts used,
180 stringprep does nothing to map similar-looking characters together
181 nor to prohibit some characters because they look like others.
182
183 Security on the Internet partly relies on the DNS. Thus, any change
184 to the characteristics of the DNS can change the security of much of
185 the Internet.
186
187 Domain names are used by users to connect to Internet servers. The
188 security of the Internet would be compromised if a user entering a
189 single internationalized name could be connected to different servers
190 based on different interpretations of the internationalized domain
191 name.
192
193 Current applications might assume that the characters allowed in
194 domain names will always be the same as they are in [STD13]. This
195 document vastly increases the number of characters available in
196 domain names. Every program that uses "special" characters in
197 conjunction with domain names may be vulnerable to attack based on
198 the new characters allowed by this specification.
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217 Hoffman & Blanchet Standards Track [Page 4]
218 RFC 3491 IDN Nameprep March 2003
219
220
221 10. IANA Considerations
222
223 This is a profile of stringprep. It has been registered by the IANA
224 in the stringprep profile registry
225 (www.iana.org/assignments/stringprep-profiles).
226
227 Name of this profile:
228 Nameprep
229
230 RFC in which the profile is defined:
231 This document.
232
233 Indicator whether or not this is the newest version of the
234 profile:
235 This is the first version of Nameprep.
236
237 11. Acknowledgements
238
239 Many people from the IETF IDN Working Group and the Unicode Technical
240 Committee contributed ideas that went into this document.
241
242 The IDN Nameprep design team made many useful changes to the
243 document. That team and its advisors include:
244
245 Asmus Freytag
246 Cathy Wissink
247 Francois Yergeau
248 James Seng
249 Marc Blanchet
250 Mark Davis
251 Martin Duerst
252 Patrik Faltstrom
253 Paul Hoffman
254
255 Additional significant improvements were proposed by:
256
257 Jonathan Rosenne
258 Kent Karlsson
259 Scott Hollenbeck
260 Dave Crocker
261 Erik Nordmark
262 Matitiahu Allouche
263
264
265
266
267
268
269
270
271
272 Hoffman & Blanchet Standards Track [Page 5]
273 RFC 3491 IDN Nameprep March 2003
274
275
276 12. Authors' Addresses
277
278 Paul Hoffman
279 Internet Mail Consortium and VPN Consortium
280 127 Segre Place
281 Santa Cruz, CA 95060 USA
282
283 EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
284
285
286 Marc Blanchet
287 Viagenie inc.
288 2875 boul. Laurier, bur. 300
289 Ste-Foy, Quebec, Canada, G1V 2M2
290
291 EMail: Marc.Blanchet@viagenie.qc.ca
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Hoffman & Blanchet Standards Track [Page 6]
328 RFC 3491 IDN Nameprep March 2003
329
330
331 13. Full Copyright Statement
332
333 Copyright (C) The Internet Society (2003). All Rights Reserved.
334
335 This document and translations of it may be copied and furnished to
336 others, and derivative works that comment on or otherwise explain it
337 or assist in its implementation may be prepared, copied, published
338 and distributed, in whole or in part, without restriction of any
339 kind, provided that the above copyright notice and this paragraph are
340 included on all such copies and derivative works. However, this
341 document itself may not be modified in any way, such as by removing
342 the copyright notice or references to the Internet Society or other
343 Internet organizations, except as needed for the purpose of
344 developing Internet standards in which case the procedures for
345 copyrights defined in the Internet Standards process must be
346 followed, or as required to translate it into languages other than
347 English.
348
349 The limited permissions granted above are perpetual and will not be
350 revoked by the Internet Society or its successors or assigns.
351
352 This document and the information contained herein is provided on an
353 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
354 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
355 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
356 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
357 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
358
359 Acknowledgement
360
361 Funding for the RFC Editor function is currently provided by the
362 Internet Society.
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Hoffman & Blanchet Standards Track [Page 7]
383
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.