Subject: [Editorial Errata Reported] RFC4013 (1812)

From: RFC Errata System <[email-masked]>
Date: Sat, 18 Jul 2009 13:12:49 -0700 (PDT)

The following errata report has been submitted for RFC4013,
"SASLprep: Stringprep Profile for User Names and Passwords".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4013&eid=1812

--------------------------------------
Type: Editorial
Reported by: Alexey Melnikov <[email-masked]>

Section: 2.3

Original Text
-------------
Section title is "Prohibited Output"

Corrected Text
--------------
Section title should be "Prohibited Input"

Notes
-----
Section 2.3 is talking about prohibited input, not prohibited output.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4013 (draft-ietf-sasl-saslprep-10)
--------------------------------------
Title               : SASLprep: Stringprep Profile for User Names and Passwords
Publication Date    : February 2005
Author(s)           : K. Zeilenga
Category            : PROPOSED STANDARD
Source              : Simple Authentication and Security Layer
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Jul 2009 20:20:34 +0200

> Original Text

I'm not sure about this -- compare RFC 3454 section 5, the terminology
and design is about prohibiting code points in the _output_.

Testing for code points in the _output_ may be semantically different
from testing in the _input_.  Some other IDNA operation may modify code
points into one of the prohibited _output_ code points.  See RFC 3454
section 2, the map&normalize steps are taken before the prohibit step.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Jul 2009 16:44:34 -0400

> section 2, the map&normalize steps are taken before the prohibit step.

I agree with Simon here.  Prohibiting a code point in the output usually 
has the effect of making any input containing that code point result in a 
failure, but the point is that the _output_ will never contain that code 
point, even as the result of mapping and normalization -- the operation 
will fail instead.  This distinction was a conscious decision made in 
stringprep.

There is, however, an error -- the first sentence of this section does in 
fact claim to be specifying prohibited input characters.  The correct fix 
is to that text, not to the section title.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Jul 2009 22:47:54 +0200

Jeffrey Hutzelman wrote:

> I agree with Simon here.  Prohibiting a code point in the output 
> usually has the effect of making any input containing that code point 
> result in a failure, but the point is that the _output_ will never 
> contain that code point, even as the result of mapping and 
> normalization -- the operation will fail instead.  This distinction 
> was a conscious decision made in stringprep.

Agreed.

> There is, however, an error -- the first sentence of this section does 
> in fact claim to be specifying prohibited input characters.  The 
> correct fix is to that text, not to the section title.

My understanding is that prohibited characters are never generated 
during mapping.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Jul 2009 16:39:27 -0500

> My understanding is that prohibited characters are never generated 

Nonetheless, it's simpler to prohibit their output than it is to
prohibit them in the input _and_ check that all other mappings and
transformations cannot produce these codepoints in the output.

And it doesn't hurt to say that we prohibit their output even though in
practice it's best to think that we prohibit them as input.

At most a sentence, to say just that, would be appropriate ("by
prohibiting these codepoints in the output we effectively prohibit them
in the input").

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 23 Jul 2009 00:05:18 +0200

>prohibiting these codepoints in the output we effectively prohibit them
That would be fine with me.