Subject: [Enum] [ticket.frobbit.se #873] Character Set, Case Sensitivity, and NAPTR fields

From: "lconroy via RT" <[email-masked]>
Date: Sun, 26 Mar 2006 16:12:52 +0200 (CEST)

Sun Mar 26 16:12:52 2006: Request 873 was acted upon.
Transaction: Ticket created by [email-masked]
       Queue: 3761bis
     Subject: Character Set, Case Sensitivity, and NAPTR fields
       Owner: Nobody
  Requestors: [email-masked]
      Status: new
 Ticket <URL: http://ticket.frobbit.se/Ticket/Display.html?id=873 >

Character Set, Case Sensitivity, and NAPTR fields.
NOTE - This is really three inter-related topics. As they are so  
closely tied together I have requested a single ticket.

[a]  use of non-ASCII (and non-printable characters) in SED/POSIX  
REGEXP field.
      I18N has been specified for DDDS, with UTF-8 encoding.
      However, there is no guidance on how this fits with SED/POSIX  
REGEXP and the characters that can be used.
-    All of the string fields can have valid characters that are not  
printable.
      Some may be 'difficult' or 'dangerous', such as NULL (0x00).
      Guidance or even prohibition would be useful.
-    Even when generating an IRI from the REGEXP field, there is a  
risk that the IRI, if presented to the end user (or used to open a  
web page, for example) can risk the end user being sent to a web page  
that is not the same as the one he or she expects.
      For example, the IRI may look like www.paypal.com but actually  
be constructed using some Cyrillic characters (e.g. www.xn-- 
pypal-4ve.com).
      This is a similar problem to the one raised for IDNs and domain  
registration, and works with punycode as well as standard UTF-8  
encoding.
      At least advice on the presentation of mixed character IRIs  
should be covered in the security section.

[b]  Does allowing characters with multi-byte UTF-8 encoding in the  
services and flags fields help?
      For the services (and flags) field contents, permitting strings  
that are not in the US-ASCII equivalent range adds a requirement for  
multi-byte string matching to implementations with no obvious benefit.
-    We often have to register these strings with IANA (potentially  
for flags, and definitely for DDDS Application tags and for  
Enumservices).
      Non-ASCII registry data with IANA is not easy/possible.

[c]  Case Sensitivity is unclear for the flags and service field.
      We have **Assumed** that the flags and services field content  
is US-ASCII equivalent, and so we can choose whether or not these  
fields are case sensitive or not.
      However, if characters that are not in the US-ASCII equivalent  
range are used, it is unclear what exactly case sensitivity means -  
some of the mapped character sets do not have a concept of case  
sensitivity (what does case sensitivity mean in Klingon?)

Options/Suggestions:
(i-1)  Add a Clear security issue stating that IRIs that contain  
mixed character sets SHOULD be indicated as such to end users when  
presented and used.
        (This one is a 'can of worms', but if we are to permit IRIs  
then we have exactly the same troubles as ICANN with IDN registrations).
     -  Give guidance that if non-ASCII equivalent characters are  
used in the match sub-field of the REGEXP, then this MAY not work  
with some implementations of REGEXP processing.
     -  Finally, state that only US-ASCII equivalent 'printable'  
characters should be used as delimiters and/or escape characters  
within the REGEXP.
or
(i-2)  Remove reference to UTF-8 and require everything to be US- 
ASCII only, within the 'printable' range, and bar the use of IRIs  
(specifically the use of punycode).

and

(ii)  Require that all characters in the flags and services fields  
MUST be US-ASCII only, and SHOULD be within the 'printable' range.
       I would suggest that NULL (0x00) be barred from use.
and

(iii) State Explicitly that the flags and services field contents are  
case insensitive.

Of the first options, I hope that we can avoid the second one.  
Barring anything that is not ASCII would be a severe limitation.

See also separate ticket for the REGEXP 'i' flag.

all the best,
   Lawrence

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum