SASLprep200x

[John C Klensin]

--On Friday, 05 January, 2007 10:45 -0800 Paul Hoffman
<phoffman at imc.org> wrote:

> At 10:06 AM -0500 1/5/07, John C Klensin wrote:
>> I think we are not disagreeing, but not communicating.
> 
> Fully disagree. Fortunately, you made that easy to see in the
> next sentence.
> 
>> In our
>> end result, we need to, somehow, accommodate at least three
>> different applications and whatever requirements they produce:
>> 
>>	(i) IDNs
>>	(ii) Identifiers to be used to name certificates and
>>	other security credentials
>>	(iii) Passwords and other strings that benefit from high
>>	entropy.
> 
> We have no such "need".
> 
> We need (i), of course.
> 
> We also need (ii) but only insofar as domain names used in
> those certs and credentials. To be explicit: we do not need to
> do anything to let "Johnson&Johnson" use their name in the
> issuer name or subject name fields of PKIX certificates. That
> is out of scope for StringPrep. If the security community
> wants an interoperable way to handle free-text strings, they
> can invent it themselves. (Yes, I will be a stuckee with the
> giant target on his chest for this one; I'll live with that.
> Fortunately, Simon will be standing next to me.)
> 
> We should not even consider (iii). The fast that the SASL
> community wanted to use StringPrep2003 for their needs then,
> and now may regret that decision, is Not Our Problem,
> particularly because they can fix their problem themselves
> with a lot less effort than it would take us to accommodate
> them.

Now I am suitably confused.

The abstract of Stringprep (RFC3454) says:

#  This document describes a framework for preparing Unicode
#  text strings in order to increase the likelihood that string
#  input and string comparison work in ways that make sense for
#  typical users throughout the world.  The stringprep protocol
#  is useful for protocol identifier values, company and
#  personal names, internationalized domain names, and other
#  text strings.

#  This document does not specify how protocols should prepare
#  text strings.  Protocols must create profiles of stringprep in
#  order to fully specify the processing options.

I infer from this that Stringprep is intended to serve several
protocols, not just IDNA.  I cannot read the text in any other
way. To the extent to which we propose to change Stringprep, I
think it is incumbent upon us to not make changes that adversely
and unintentionally impact other Stringprep-user protocols, at
least without being confident that someone is worrying about the
issues. I don't believe we can retroactively say "the text
quoted above it irrelevant -- Stringprep belongs to IDNA and, if
anything else decides to use it, good for them... but at their
risk".    

"We" --and perhaps it is the vagueness of that reference that is
causing some of the problem-- do not need to do that work as
part of the IDNAbis effort, but we must, IMO, take some
responsibility for being sure that _someone_ does it.  If it is
not done, then a revision to Stringprep will certainly not
survive IETF Last Call... and should not do so.

The "end result" I was referring to above as needing to reflect
the needs of several protocols and uses was such a hypothetical
revision of Stringprep.   I do not see any need --or
desirability-- to change what is permitted in IDNA one bit to
accommodate the perceived needs of other protocols (and thought
I had been saying that).  

But, ultimately, we have three options: 

	(1) We cut Nameprep loose from Stringprep and make it a
	stand-alone specification rather than a profile.
	
	(2) We develop a new Nameprep profile that relies on the
	current Stringprep.  I don't see any way to do that
	which does not result in a set of rules more convoluted
	(to use your description) than I can imagine being
	implementable.
	
	(3) We change Stringprep.  We might do that by adding
	one or more new tables and have Nameprep reference them,
	leaving everything else unaffected.  Or we might make
	other changes, in which case we need to be aware --or be
	sure that someone is aware and deals with-- their
	implications to anything else that references
	Stringprep.  As one variation on this, we move IDNA to
	some hypothetical and drastically different
	Stringprep200X but leave SASL and other Stringprep users
	at Stringprep2003 for as long as it takes, essentially
	forking the specification.  I don't think that would be
	an especially good outcome for the community --it would
	certainly violate the multi-protocol principle that
	motivated Stringprep and the above quoted text-- but it
	is a plausible outcome.

I consider those options to be matters of implementation style
and mechanism, not, at least at this stage, of substance.  That
is why I'm finding this discussion a bit strange and,
apparently, have become sufficiently inarticulate about it that
others are sensing disagreement where I don't.   As an "IDNA
update" effort, I don't think there is any value at all in
considering the perceived needs of other protocols in figuring
out what is needed for IDNs.  In that sense, I am in complete
agreement with what I think you and Vint are saying.  

I took Simon as saying only that, if and when we start messing
with Stringprep, we shouldn't do anything that inadvertently
restricts character choices for those "other text strings",
particularly as they might be used in SASL (or that would
prevent those protocols from migrating to the new version with
only a reasonable level of pain).  I agree with that.  If,
instead, he really meant that we should somehow permit things in
IDNs that would not otherwise be desirable because they would be
convenient in passwords, I very strongly disagree with that
position.  I always have disagreed with it, any confusion I may
have introduced notwithstanding.

   john