Preparation and Comparison of Internationalized Strings (precis)

Nico Williams | 3 May 2013 21:39

Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-01.txt

Please forgive my apparent apathy.  I lost track of this due to business travel.

I'm not sure where the case mapping requirement for usernames came
from.  I guess it has something to do with the Turkish I and such.  I
can't say I'm excited about this case mapping requirement; if anything
it strikes as silly.

Why would we apply mappings to usernames (which are sent on the wire)
that we don't apply to passwords (which servers generally don't get
the plaintext of)?  We need mappings for passwords to make password
entry reliable.  The same does NOT apply to usernames.

Also, looking at SASLprep and PRECIS, I see no mention of query
strings vs. display vs. storage.  These distinctions matter.  But
maybe I'm just failing to search for the right terms.  Heck, we're not
even told whether these rules should be applied by the client, the
server, or both.

Anyways, I'm for applying as few transformations as possible to
usernames on the *client* side and leaving the server to apply
RECOMMENDED, and a few REQUIRED rules for matching.  I don't see room
for case folding in general, but I do for specific cases (e.g.,
Turkish I handling).

If this review is too late to make a difference, well, c'est la vie.
But do give the above some thought before rejecting my comments for
being late.  Once more, I'm sorry I let this slip.

Nico
--

(Continue reading)

headers

Black, David | 3 May 2013 21:19

More on mappings (iSCSI perspective)

I've taken a look at the mappings draft from an iSCSI perspective.
The iSCSI entities that use Unicode are iSCSI names, so I'll start
with some background on them.

iSCSI names are somewhat restrictive in allowed characters.  For
ASCII characters, only the following are allowed:
   -  ASCII dash character ('-' = U+002d)
   -  ASCII dot character ('.' = U+002e)
   -  ASCII colon character (':' = U+003a)
   -  ASCII lower-case characters ('a'..'z' = U+0061..U+007a)
   -  ASCII digit characters ('0'..'9' = U+0030..U+0039)
All other ASCII characters are prohibited, including U=0020; SPACE.
The Unicode support generalizes from this.

The iSCSI protocol design kept Unicode functionality outside the
protocol; stringprep is used on iSCSI names *before* the protocol
sees them so that the protocol can do binary comparison for equality
of iSCSI names that are communicated "on the wire".  Hence whatever
we do here should not affect the specification of the "on the wire"
iSCSI protocol.

For context, the iSCSI stringprep profile stuck fairly close to
stringprep (RFC 3454) with the following items of note:

	- whitespace is prohibited in output.
		Prohibition in input is probably the best approach here.
	- U+3002; ideographic full stop is prohibited in output.
		Mapping that to U+002E; FULL STOP would be user-friendly.
	- NFKC was used as it was the only reasonable option in
		RFC 3454.

(Continue reading)

headers

internet-drafts | 26 Apr 2013 05:06

I-D Action: draft-ietf-precis-saslprepbis-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of
the IETF.

	Title           : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords
	Author(s)       : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-ietf-precis-saslprepbis-02.txt
	Pages           : 13
	Date            : 2013-04-25

Abstract:
   This document describes how to handle Unicode strings representing
   simple user names and passwords, primarily for purposes of
   comparison.  This profile is intended to be used by Simple
   Authentication and Security Layer (SASL) mechanisms (such as PLAIN
   and SCRAM-SHA-1), as well as other protocols that exchange simple
   user names or passwords.  This document obsoletes RFC 4013.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-02

Internet-Drafts are also available by anonymous FTP at:

(Continue reading)

headers

Peter Saint-Andre | 12 Apr 2013 23:18

mappings

As promised at IETF 86 (and probably IETF 85!), I've reviewed the
issues raised by draft-ietf-precis-mappings. I will also send some
editorial feedback directly to the authors of that document.

1. Width mapping has now been moved to the framework document, so I
think Section 2 and Section 3 of the mappings document can be removed.

2. I think it would be helpful to mention some examples of delimiters
other than FULL STOP.

3. This text is a bit confusing:

   One of the most useful case of delimiter mapping is when FULL STOP
   character (U+002E) is a delimiter as well as domain name.

I am not a DNS expert, but my understanding is that FULL STOP is not
part of the domain name but is a delimiter between the labels of a
domain name. I think the sentence quoted above means that in certain
protocols FULL STOP is used as a delimiter within protocol strings (such
as identifiers) in addition to being used as a delimiter between domain
name labels.

4. I think we can just mention RFCs 3748, 4013, 4314, and 4518 in
Section 4.2 and then remove Appendix B, since it is the responsibility
of other specifications to actually define the special mappings (e.g.,
this is done in draft-ietf-precis-saslprepbis).

5. I think Appendix C could be moved into Section 4.3.

6. The big open issue here is the order of mappings. RFC 5895 defines an

(Continue reading)

headers

internet-drafts | 28 Mar 2013 04:39

I-D Action: draft-ietf-precis-saslprepbis-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of
the IETF.

	Title           : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords
	Author(s)       : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-ietf-precis-saslprepbis-01.txt
	Pages           : 13
	Date            : 2013-03-27

Abstract:
   This document describes how to handle Unicode strings representing
   simple user names and passwords, primarily for purposes of
   comparison.  This profile is intended to be used by Simple
   Authentication and Security Layer (SASL) mechanisms (such as PLAIN
   and SCRAM-SHA-1), as well as other protocols that exchange simple
   user names or passwords.  This document obsoletes RFC 4013.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-saslprepbis-01

Internet-Drafts are also available by anonymous FTP at:

(Continue reading)

headers

internet-drafts | 27 Mar 2013 05:01

I-D Action: draft-ietf-precis-framework-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of
the IETF.

	Title           : PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols
	Author(s)       : Peter Saint-Andre
                          Marc Blanchet
	Filename        : draft-ietf-precis-framework-07.txt
	Pages           : 70
	Date            : 2013-03-26

Abstract:
   Application protocols using Unicode code points in protocol strings
   need to properly prepare such strings in order to perform valid
   comparison operations (e.g., for purposes of authentication or
   authorization).  This document defines a framework enabling
   application protocols to perform the preparation and comparison of
   internationalized strings (a.k.a.  "PRECIS") in a way that depends on
   the properties of Unicode code points and thus is agile with respect
   to versions of Unicode.  As a result, this framework provides a more
   sustainable approach to the handling of internationalized strings
   than the previous framework, known as Stringprep (RFC 3454).  A
   specification that reuses this framework can either directly use the
   PRECIS string classes or subclass the PRECIS string classes as
   needed.  This framework takes an approach similar to the revised
   internationalized domain names (IDNs) in applications (IDNA)
   technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and
   thus adheres to the high-level design goals described in the IAB's
   recommendations regarding IDNs (RFC 4690), albeit for application

(Continue reading)

headers

Peter Saint-Andre | 18 Mar 2013 18:18

NameClass considered misleading


During the WG session last week, I got the sense that people find the
term "NameClass" misleading ("why can't I represent my name using the
NameClass?!"). Thus I propose changing it to "SafeClass". Any objections?

Peter

--

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

headers

Marc Blanchet | 14 Mar 2013 19:55

ietf86 precis meeting minutes

hello,
 minutes of our today meeting posted. Thanks for everybody who contributed the minutes.

http://www.ietf.org/proceedings/86/minutes/minutes-86-precis

Please send any mods to the wg chairs (precis-chairs <at> tools.ietf.org)

Marc&Yoneya.

headers

Yoshiro YONEYA | 26 Feb 2013 05:55

IETF86 Orlando draft agenda

Dear all,

Following is draft agenda for IETF 86 Orlando.
Please send comments/additions/changes to the chairs.

1. Administrativia

2. Document updates / Discussion
  2.1 WG I-Ds
    (1) Framework
      https://datatracker.ietf.org/doc/draft-ietf-precis-framework/

    (2) Preparation and Comparison of Nicknames
      https://datatracker.ietf.org/doc/draft-ietf-precis-nickname/

    (3) Mapping characters for precis classes
      http://datatracker.ietf.org/doc/draft-ietf-precis-mappings/

    (4) Preparation and Comparison of Internationalized Strings Representing 
        Simple User Names and Passwords
      http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

  2.2 Individual Documents
    (1) precis implementation report
      https://datatracker.ietf.org/doc/draft-nemoto-precis-framework-implement-report/

3. Next steps

Marc & Yoneya, co-chairs

(Continue reading)

headers

Peter Saint-Andre | 18 Feb 2013 22:20

Re: [kitten] Fwd: I-D Action: draft-ietf-precis-saslprepbis-00.txt


[ + precis <at> ietf.org ]

On 2/18/13 11:04 AM, Chris Newman wrote:
> --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre 
> <stpeter <at> stpeter.im> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 2/14/13 2:12 PM, Peter Saint-Andre wrote:
>>> Hi Chris, thank you for the review.
>>> 
>>> On 2/14/13 12:37 PM, Chris Newman wrote:
>>>> A common construction for user names on the Internet is the
>>>> form "user <at> example.com", specifically, a subset of
>>>> email-address syntax with an embedded domain name is commonly
>>>> used for login identity strings (although theses login
>>>> identity strings may or may not be usable as actual email
>>>> addresses).
>>> 
>>>> As a result, the character class used for user names used
>>>> for authentication needs to be a superset of the character
>>>> class used for domain names. I was not able to tell from the 
>>>> specification if that was the case. If it isn't, I believe
>>>> that should be fixed.
>>> 
>>> It is the case, because all characters in the ASCII range are 
>>> grandfathered into the PRECIS NameClass. Thus some examples
>>> are definitely in order! We'll add those to the next version.
>> 
>> I propose adding the second paragraph shown below to the end of

(Continue reading)

headers

Takahiro Nemoto | 17 Feb 2013 03:40

Mappings document's open issues

Dear all,

Yoneya-san and I listed open issues for draft-ietf-precis-mappings.

Please read and give your comments/suggestions.

Followings are current mappings document's open issues.

  1. Whether is local case mapping belong in additional mappings in precis framework?
  2. If local case mapping belong in precis framework, it's necessary to specify mapping order
      as local case mapping then case mapping.
      Because it makes no sense to perform local case mapping after case mapping.
  3. Handling order of precis framework and precis mappings is ambiguous.
      It's necessary to define the order in precis framework or in this document or in both documents.

And followings are authors’ recommended solutions.

  1. Additional mapping should be mappings which are not included in Mappings document.
  2. Handling order is Mappings document then processes in precis framework document.
  3. The order should be defined in both documents.

Regards,
Nemo

Takahiro Nemoto

t.nemo10 <at> kmd.keio.ac.jp

<div>
<div>
<div>Dear all,</div>
<div><br></div>Yoneya-san and I&nbsp;listed open issues for&nbsp;draft-ietf-precis-mappings.</div>
<div>Please read and give your comments/suggestions.</div>
<div><br></div>Followings are current&nbsp;mappings document's&nbsp;open issues.<br><br>&nbsp;&nbsp;1. &nbsp;Whether is local case mapping belong in additional mappings in precis framework?<br>&nbsp;&nbsp;2. &nbsp;If local case mapping belong in precis framework, it's necessary to specify mapping order&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;as local case mapping then case mapping.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Because it makes no sense to perform local case mapping after case mapping.<br>&nbsp;&nbsp;3. &nbsp;Handling order of precis framework and precis mappings is ambiguous. &nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;It's necessary to define the order in precis framework or in this document or in both documents.<br><br>And followings are authors&rsquo; recommended solutions.<br><br>&nbsp;&nbsp;1. &nbsp;Additional mapping should be mappings which are not included in Mappings document.<br>&nbsp;&nbsp;2. &nbsp;Handling order is Mappings document then processes in precis framework document.<br>&nbsp;&nbsp;3. &nbsp;The order should be defined in both documents.<br><br>Regards,<br>Nemo<div>
<br><div apple-content-edited="true">
<span class="Apple-style-span"><div>
<div>--</div>
<div>Takahiro Nemoto</div>
<div><a href="mailto:t.nemo10 <at> kmd.keio.ac.jp">t.nemo10 <at> kmd.keio.ac.jp</a></div>
<div><br></div>
</div></span><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br>
</div>
</div>

4	May 2013
6	April 2013
18	March 2013
14	February 2013
7	January 2013
2	December 2012
18	November 2012
18	October 2012
39	September 2012
23	August 2012
18	July 2012
1	June 2012
18	May 2012
14	April 2012
30	March 2012
2	February 2012
2	January 2012
10	November 2011
23	October 2011
1	September 2011
6	August 2011
28	July 2011
5	June 2011

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31