Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

[Peter Saint-Andre <[e-mail]>]

On 9/18/17 7:21 AM, Peter Saint-Andre wrote:
> On 9/17/17 9:32 PM, Sam Whited wrote:
>> On Sun, Sep 17, 2017, at 21:56, Peter Saint-Andre wrote:
>>> It's true that a nickname / handle / display name is not a solid basis
>>> on which to make authentication or authorization decisions. So don't do
>>> that. :-)
>>>
>>> Should we add a sentence about this to 7700bis?
>>
>> I suppose it couldn't hurt, but I'm not sure that it's necessary either.
> 
> I thought about it more overnight and I will look more closely at the
> security considerations and introduction later today. I do think a
> sentence or two would help.

Here is some proposed text to address part of Sam's concern.

First, in the Introduction...

OLD

   The rules specified in this document can be applied in all of the
   foregoing contexts.

   To increase the likelihood that memorable, human-friendly names will
   work in ways that make sense for typical users throughout the world,
   this document defines rules for handling nicknames in terms of the
   preparation, enforcement, and comparison of internationalized strings
   (PRECIS) framework specification [RFC8264].

NEW

   The rules specified in this document can be applied in all of the
   foregoing contexts.

   It is important to understand that a nickname is a personally
   memorable name or handle for something that has a more stable,
   underlying identity, such as a URI or a file path. To ensure secure
   operation of applications that use nicknames, authentication and
   authorization decisions MUST be made on the basis of the thing's
   identity, not its nickname.

   To increase the likelihood that memorable, human-friendly names will
   work in ways that make sense for typical users throughout the world,
   this document defines rules for handling nicknames in terms of the
   preparation, enforcement, and comparison of internationalized strings
   (PRECIS) framework specification [RFC8264].

Second, we might repeat that paragraph in a new subsection of the
Security Considerations, too.

Third, I suggest that we move the following paragraph from the end of
Section 4 to the end of Section 2.1:

   Implementation experience has shown that applying the rules for the
   Nickname profile is not an idempotent procedure for all code points.
   Therefore, an implementation SHOULD apply the rules repeatedly until
   the output string is stable; if the output string does not stabilize
   after reapplying the rules three (3) additional times after the first
   application, the implementation SHOULD terminate application of the
   rules and reject the input string as invalid.

Peter