Subject: [precis] draft evaluation of Resourceprep (RFC 3920)

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Dec 2010 10:27:01 -0700

This message evaluates the Resourceprep profile of stringprep in
accordance with the template established by the PRECIS WG:

http://trac.tools.ietf.org/wg/precis/trac/wiki/StringprepReviewTemplate

###

Specification:

   RFC 3920

Brief Description:

   - Resourcepart of JabberID ("JID"), as in:
     <localpart@domainpart/resourcepart>
   - Typically free-form text

How It's Used:

   - Device / session names (e.g., [email-masked]/Home)
   - Nicknames (e.g., [email-masked]/StPeter)

Who Generates It:

   - Often human users via an XMPP client
   - Often generated in an automated fashion by client or server

User Input Methods:

   - Typed by user
   - Copy-and-paste
   - Perhaps voice input

Enforcement:

   - Rules enforced by server / add-on service (e.g., chatroom
     service) on account login, joining a chatroom, etc.

Comparison Method:

   "Type 1" (byte-for-byte)

   (see http://tools.ietf.org/html/draft-ietf-precis-problem-statement )

Case Folding, Sensitivity, Preservation:

   - Strings are never folded
   - Case is preserved

Impact of Comparison:

   False positives:
     - interact with wrong device (e.g., for file transfer or voice call)
     - interact with wrong chatroom participant
     - improperly grant privileges (e.g., chatroom moderator)
     - allow communication with blocked entity

   False negatives:
     - unable to choose desired chatroom nick
     - unable to use granted privileges (e.g., chatroom moderator)
     - disallow communication with unblocked entity

Normalization:

   NFKC

Mapping:

   Spaces are mapped to nothing

Disallowed Characters:

   None

String Classes:

   - Basically a free-form identifier

Internal Structure:

   None

User Output:

   - text of message (e.g., in a chatroom)
   - device names often not exposed to human users

Operations:

  - Sometimes concatenated with other data and then
    used as input to a cryptographic hash function

###

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 13 Dec 2010 11:02:50 -0700

>    - Perhaps voice input

Is clicking on a URI a different form of input?  If so, then it applies to
localpart as well.

>    (see http://tools.ietf.org/html/draft-ietf-precis-problem-statement )

Does this mean byte-for-byte *after* canonicalization?  Or is the
canonicalization an algorithm?  That's not clear to me from 3.1.1.
Resourceparts are prep'd, just less so than other things.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Dec 2010 11:05:24 -0700

> Is clicking on a URI a different form of input?  If so, then it applies to

Yes, will add that as a method. We're iteratively improving the template
and evaluations as we go along.

> Resourceparts are prep'd, just less so than other things.

Yes, I struggled over that one, but I think you're right that
resourcepart comparison is "Type 2", just not as involved as prepping of
XMPP localparts.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/