Subject: Re: SASLPrep vs Full Stop code points

From: Ienup Sung <[email-masked]>
Date: Fri, 31 Oct 2003 11:48:48 -0800 (PST)

Actually, the IDNA specifies that out of the Stringprep and the Nameprep
profile; in the similar sense/reasons and to preserve the context of the various
full stops as much as possible, it seems the Kerberos extension also need to
specify the additional mappings at the extension not at the Stringprep profile
and only for the Internet domain-style names.

Please see the attached, esp., the issue-1.

With regards,

Ienup

] Date: Fri, 31 Oct 2003 13:49:31 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] 
] Over the last week I have realized that we may have overlooked a 
] necessary mapping for the SASLPrep: Full Stop code points.
] 
] The Full Stop code points
] 
]     U+002E (full stop)
]     U+3002 (ideographic full stop)
]     U+FF0E (fullwidth full stop)
]     U+FF61 (halfwidth ideographic full stop).
] 
] do not have mapping tables in StringPrep and are not mapped in NamePrep 
] because IDNA (RFC 3490) uses these characters as an equivalent class of 
] label separators.  Therefore, they cannot exist in any input to which 
] NamePrep would have been applied.
] 
] It is my belief that SASLPrep must specify a mapping requiring all Full 
] Stop code points to be mapped to U+002E (full stop).
] 
] Jeffrey Altman
] 
] 
] 
] 
]

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 31 Oct 2003 15:07:42 -0500

Ienup Sung wrote:

>and only for the Internet domain-style names
>  
>
I see no justification for while this should be specified at some level 
above the
application of SASLprep.  SASLprep is applied to Storage and Query 
strings for the
purpose of ensuring that the strings are equivalent when matching are 
performed
or that the one true form is used as input to cryptographic operations.

If the Full Stop must be mapped to U+002E before applying SASLprep, and 
both
operations must always be performed, then it follows that the Full Stop 
mapping
should be part of SASLprep.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 31 Oct 2003 16:50:59 -0500

On Friday, October 31, 2003 11:48:48 -0800 Ienup Sung 
<[email-masked]> wrote:

> profile; in the similar sense/reasons and to preserve the context of the
> various full stops as much as possible, it seems the Kerberos extension
> also need to specify the additional mappings at the extension not at the
> Stringprep profile and only for the Internet domain-style names.

Please bear in mind that when we discuss saslprep, we're not just talking 
about Kerberos; we're also talking about the whole range of SASL mechansims 
which also use the SASLprep profile for their authentication ID's or for 
other strings, and any SASL applications which use the SASLprep profile on 
authzids.

Also, since you're apparently not familiar with the history, I'll point out 
that there is a simple reason why Kerberos uses the SASLprep profile.  Both 
groups recently had need for stringprep profiles, and began to develop 
requirements and produce documents.  As things progressed, we noticed that 
we were essentially writing exactly the same profile twice.  So, after some 
investigation to determine that we had essentially the same needs, we 
agreed to combine the work and produce a single document.  The folks you've 
been discussing IDN issues with over in krb-wg were part of this process.

Further, I'll point out to the others reading the fundamental point that 
you try to make, which may have been missed -- it may be desirable to map 
U+3002, U+FF0E, and U+EE61 to U+002E _only_ in the context of domain names 
(where it is required), and not in other contexts.  Doing that would indeed 
require that the work of mapping be done other than in SASLprep.

Nameprep does not specify mapping for the full stop characters Jeff 
mentioned, not out of a desire to "preserve context", but because Nameprep 
applies to individual DNS labels, and the full stop characters are not 
permitted in such labels in order to avoid confusion when full domain names 
are represented as strings with "." separating the labels.

IDNA (specifically, RFC3490) has the following to say:

   1) Whenever dots are used as label separators, the following
      characters MUST be recognized as dots: U+002E (full stop), U+3002
      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
      (halfwidth ideographic full stop).

It also requires, in the following paragraph, that when dots are used as 
label separators in a domain name placed into an IDN-unaware domain name 
slot, the label separator MUST be U+002E, for the simple reason that none 
of the other possible choices are valid US-ASCII characters.  However, this 
is of relevance only as an indication of intent, since we are NOT presently 
talking about any domain name slots, IDN-aware or otherwise.

One legitimate way to accomplish these requiements is to insure that by the 
time anything is parsed out as a domain name, all of these characters have 
been mapped to U+002E (full stop).  That is what Jeff is proposing for 
SASLprep.  There are two significant advantages to this approach:

(a) It eliminates the need for "special processing" based on whether 
something is to be treated as a domain name.  This is particularly 
important in Kerberos, because even those strings in Kerberos which may be 
derived from domain names (certain realm names and principal name 
components) are _never_ treated as an independent sequence of labels; they 
are treated as single strings which do, in fact, contain periods.  In order 
for KDB lookups and other operations to succeed, the periods must be 
consistent.

(b) It provides for consistent behaviour over all strings of the relevant 
types (among them, Kerberos realm names and principal name components, plus 
the authentication ID's of several SASL mechanisms), rather than giving a 
different behavour for those strings or parts of strings which may contain 
or be derived from domain names.

However, there is also a disadvantage, which is that this is a mapping 
based primarily on visual similarity.  SASLprep does not presently contain 
any such mappings, other than the mapping of non-ASCII space characters to 
U+0020 (space).  I believe we came to the conclusion in the process of 
designing the (now abandoned) Kerberos stringprep profile that such 
mappings would lead down a vague and inconsistent path of attempting to 
second-guess the user, and would thus be counterproductive.  Section 1.2 of 
RFC3490 addresses this issue as well.

It may be the case that the special use of dots in domain names, combined 
with the recommendations of RFC3490 on processing certain other full stop 
characters as domain label separators, justifies special handling in 
SASLprep.  My first inclination was to agree with Jeff and Nico that this 
was obviously the right answer; after thinking about it for a few minutes, 
I'm not so sure.

In any case, including this mapping in SASLprep will not save us (or 
applications, or krb5_sname_to_principal, or whatever) from having to 
recognize and specially handle U+002E, U+3002, U+FF0E, and U+FF61 when 
constructing principal names or other strings from domain names.  This is 
because Nameprep may only be applied to individual labels, not entire 
domain names, and thus such names _must_ be split into separate labels at 
these characters, each label processed separately, and then the name 
reassembled, presumably using U+002E (full stop) as the label separator. 
This is effectively a separate processing step that is required any time 
nameprep is to be applied.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 31 Oct 2003 17:44:13 -0500

Jeffrey Hutzelman wrote:

> constructing principal names or other strings from domain names.  This 
> is because Nameprep may only be applied to individual labels, not 
> entire domain names, and thus such names _must_ be split into separate 
> labels at these characters, each label processed separately, and then 
> the name reassembled, presumably using U+002E (full stop) as the label 
> separator. This is effectively a separate processing step that is 
> required any time nameprep is to be applied.
>
> -- Jeff

The application of SASLprep produces a Storage string or a Query 
string.  These strings are
not appropriate for use as Display strings.  The distinction between the 
different forms
of "full stops" just like the distinction between "spaces" is important 
for display strings.
I just don't see how they can be important for query and storage strings. 

There is an on-going battle taking place on the [email-masked] 
mailing list.  It is a rehashing of all the arguments which have taken 
place over the last ten years on whether or
not internationalization is a good idea.  The argument is clearly 
pointless.  Internationalized
strings are not just a necessity but a desirable feature. 

The fundamental problems related to internationalizing protocols have been
caused by an attempt to allow the use of Storage Strings as Display 
Strings.  This
is wrong.  Storage and query strings are meant to be used within wire 
protocols.
Display strings are meant to be used in user interfaces.  Their use is 
different and
therefore so are the requirements.

I do not see any reason why protocols which rely on SASLprep must allow 
this misuse.
For example, in Kerberos the set/change password protocol and the kdb 
could very well
provide for both a storage string and a display string.  The KDC could 
have a query
function which allows any query string to be used to obtain the display 
string.  The
KDC would also utilize the display string in error messages when 
necessary.  The
purpose of this is to maintain the proper separation between the User 
Interface and
the Wire Protocols.  The one requirement is that the string prep'd 
Display String must
equal the string prep'd storage string when the principal is created.

- Jeff