W3C home > Mailing lists > Public > public-iri@w3.org > April 2003

Re: Some issues with the IRI document [NFCsecurity-09]

From: Martin Duerst <duerst@w3.org>
Date: Wed, 16 Apr 2003 17:05:16 -0400
Message-Id: <>
To: Simon Josefsson <jas@extundo.com>
Cc: public-iri@w3.org

Hello Simon,

At 22:21 03/04/16 +0200, Simon Josefsson wrote:
>Martin Duerst <duerst@w3.org> writes:
> > IRIs in general require only NFC, or even less. So it should not
> > be the case that IRIs use stronger normalization than e.g.
> > SASL or Kerberos.
> >
> > As far as I understand, security problems would arise if IRIs
> > use stronger normalization, but not the other way around. Is
> > this correct?
>Note that it is possible that some security protocol, even i18n'ed
>using stringprep, do not use normalization.  So if IRIs used NFC for
>iuserinfo, it appears as IRIs would use stronger normalization than
>the security protocol, and there might be problems.  Normalization
>isn't required by stringprep, nor is it used by legacy systems out
>there that supports i18n but not Unicode nor NFC of usernames, of
>which there many even including SASL and Kerberos.
>If you want deployed examples, see RFC 2595 which defines a SASL
>mechanism that uses unnormalized UTF-8 for usernames.  It is commonly
>used for IMAP, and there even exists (two) experimental approaches to
>using it in HTTP.

Hello Simon,

NFC is only required in the current draft when encoding something
from e.g. the side of a bus, or when transcoding it from a non-
Unicode encoding. This is only to provide a base level of
predictability. Still indeed this could lead to security
problems with the mechanisms you describe above, if there
are two users that have user names that only differ in
normalization. But it would seem to me that in this case,
the security issue comes from these mechanisms (or the
actual use with these specific user names) rather than
from IRIs.

Regards,    Martin.
Received on Wednesday, 16 April 2003 17:06:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:29 UTC