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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
