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

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

From: Simon Josefsson <jas@extundo.com>
Date: Thu, 17 Apr 2003 00:09:44 +0200
To: Martin Duerst <duerst@w3.org>
Cc: public-iri@w3.org
Message-ID: <iluvfxert5j.fsf@latte.josefsson.org>

Martin Duerst <duerst@w3.org> writes:

> 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.

Section 2.4 says "IRIs SHOULD be created using Normalization Form C
(NFC)."  I don't interprete that to only apply to the scenarios you
mention, rather it seem to imply that whenever a IRI is created, by
whatever process, NFC should be used.  Perhaps it can be clarified?

> 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.

If this is so, I believe the IRI security considerations should
mention this so that people can be aware of it, and abstain from
deploying IRIs in systems that behave in this way, since doing so
would introduce problems.  Perhaps some properly worded text could
be derived from the following strawman?

   Whenever fields of an IRI are normalized, the octet representation
   is modified.  While this is unavoidable if ambiguities are to be
   resolved, it can raise security issues in some situations.  In
   particular, if a iuserinfo field is normalized, a security protocol
   expecting a certain byte sequence as a username may receive a
   different one.  This can lead to interoperability failures, but
   also more serious failures in systems, e.g. when the system
   performs authorization based on the username.

Received on Wednesday, 16 April 2003 18:09:49 UTC

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