Subject: [newprep] proposal

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Feb 2010 08:30:00 +0100

I didn't see this reflect in the proposed charter that Peter posted, so
I wanted to float this idea to see if there is any uptake.

My perception of SASLprep (and to some extent also the XMPP
Nodeprep/Resourceprep) profiles is that they have at least one different
requirement than in the IDNA environment: Backwards and forwards
compatibility is critical to achieve secure name comparisons.

To be precise, with backwards/forwards compatibility I mean the property
that an input sequence of code points A must result in the same output
sequence B for both the existing specification and the new
specification, for all code point sequences.

The IDNA update breaks backwards compatibility for some code point
sequences, and also chose to relax the requirements to allow
compatibility to be broken by registrars.  That likely makes sense for
that environment, but I believe it doesn't for this environment.

Note that this unassigned code points can be handled in a future-safe
way, and this is how the current StringPrep/SASLprep is written.

If this is a requirement that others share, my idea on how to achieve
this is to take the current set of StringPrep/SASLprep specifications,
update it for Unicode 5.2 and release it.  If we are careful to not
introduce any backwards incompatible change (which can be verified by a
program), this should allow Unicode 5.2 code points in SASLprep/XMPP/etc
identifiers.

To be clear, I'm not opposed to an inclusion-based approach.  I just
haven't seen how it can be implemented while meeting the requirements
that I perceive are important.  In any way, I'll be following the
progress here with interest.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 15:15:44 -0700

> I wanted to float this idea to see if there is any uptake.

The intent of the BoF is not to push forward with an inclusion approach,
but to figure out what makes sense. Your proposal of upgrading to
Unicode 5.2 is a helpful contribution to that discussion.

> compatibility is critical to achieve secure name comparisons.

Yes, you want your existing password or username to still work. :)

(BTW this does not apply to the XMPP Resourceprep profile in any
significant way, although it does apply to Nodeprep.)

> sequences, 

It's not clear to me that we need complete backward and forward
compatibility for *all* code points in usernames and passwords. Ideally
it would be achieved, but IMHO that is something to be discussed.

> and also chose to relax the requirements to allow
> compatibility to be broken by registrars.  

In the apps world (say, the XMPP network), there are no registrars. I
suppose you could see each service provider as a registrar of sorts
within its address space. The lack of an analogy between more formal
registrars and less formal services might have implications for our
discussion. In my experience with XMPP services, they are either quite
laissez-faire about usernames and passwords, or they lock down usernames
to be the same as existing email addresses and use credentials from LDAP
or some other data store. I've not seen anything in between those two
deployment approaches.

> That likely makes sense for

TBD.

> program), this should allow Unicode 5.2 code points in SASLprep/XMPP/etc

Yes, that is an alternate approach. I wonder if there is a way to do
that without issuing updated RFCs each time a new Unicode version is
published (essentially referencing the tables from core specs that are
more stable and then separating the tables off into a separate spec that
changes more frequently, or even into a registry of some kind).

> progress here with interest.

Thanks for the input!

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Feb 2010 14:51:33 -0800

>Yes, you want your existing password or username to still work. :)

Maybe. Seriously, I do not think that should be a given for the Newprep work, given the massively easier implementation that an IDNA2008-like algorithm would have versus a Stringprep-like algorithm.

>it would be achieved, but IMHO that is something to be discussed.

Fully agree.