Re: [precis] usernames in PRECIS and http-auth

[John C Klensin <[e-mail]>]

FWIW, this seems about right to me.
    john


--On Friday, 07 March, 2014 11:02 -0700 Peter Saint-Andre
<[e-mail]> wrote:

> As promised at IETF 89, I have compared the username
> definitions from draft-oiwa-precis-httpauthprep-00 and
> draft-ietf-precis-saslprepbis-06, with the purpose of perhaps
> harmonizing the two approaches so that we can avoid
> multiplying PRECIS profiles beyond necessity.
> 
> (I am writing this email on the flight home, and I neglected
> to load up the meeting minutes before leaving, so I might not
> address all of the relevant points in this message.)
> 
> First, let's look at the syntax definitions.
> 
> draft-ietf-precis-saslprepbis-06 states that a username can
> (a) consist of one of more userparts, or (b) can be of the
> form userpart@domainpart. The ABNF definition is:
> 
>     username   = userpart [1*(1*SP userpart)]
>                / userpart '@' domainpart
> 
>     userpart   = 1*(idpoint)
> 
>     domainpart = IP-literal / IPv4address / ifqdn
> 
>     ifqdn      = 1*1023(domainpoint)
> 
> Where:
> 
> * an "idpoint" is a UTF-8 encoded Unicode code point that
> conforms to the PRECIS "IdentifierClass"
> * an "IPv4address" is as defined in RFC 3986
> * an "IP-literal" is as defined in RFC 3986
> * a "domainpoint" is a UTF-8 encoded Unicode code point that
> conforms to RFC 5890
> 
> By contrast, draft-oiwa-precis-httpauthprep states that a
> username consists of one or more UTF-8 encoded Unicode code
> points that conform to the PRECIS "IdentifierClass". The ABNF
> definition is:
> 
>     userpart   = 1*(idpoint)
> 
> We quickly see that an http-auth username is a legal PRECIS
> username, since 1*(idpoint) is simply a userpart as defined in
> draft-ietf-precis-saslprepbis-06, and a PRECIS username can
> consist of only one userpart. Therefore, in this respect, I
> think the httpauthprep text (whether it appears in a
> standalone document or elsewhere) can simply state that for
> purposes of HTTP authentication a username is a userpart as
> defined in draft-ietf-precis-saslprepbis.
> 
> Second, let's look at the string preparation method.
> 
> Here, too, draft-oiwa-precis-httpauthprep-00 is a subset of
> draft-ietf-precis-saslprepbis-06. The preparation method in
> draft-ietf-precis-saslprepbis-06 is:
> 
>     1.  The base string class is the "IdentifierClass"
> specified in
>         [I-D.ietf-precis-framework].
>     2.  Fullwidth and halfwidth characters MUST be mapped to
> their
>         decomposition equivalents.
>     3.  So-called additional mappings MAY be applied, such as
> those
>         defined in [I-D.ietf-precis-mappings].
>     4.  Uppercase and titlecase characters might be mapped to
> their
>         lowercase equivalents (see Section 4.2.1 below).
>     5.  Unicode Normalization Form C (NFC) MUST be applied to
> all
>         characters.
> 
> By contrast, the preparation method in
> draft-oiwa-precis-httpauthprep-00 is:
> 
>     1.  Fullwidth and halfwidth characters MUST be mapped to
> their
>         decomposition equivalents.
>     2.  Additional mappings SHOULD NOT be applied, such as
> those defined
>         in [I-D.ietf-precis-mappings], unless there are
> implementation-
>         dependent reasons to do so, or these are exceptionally
> required
>         by specific authentication schemes.
>     3.  Case mapping is not applied.
>     4.  Unicode Normalization Form C (NFC) MUST be applied to
> all
>         characters.o
> 
> These two defnitions agree on the width mapping and
> normalization rules described in the PRECIS framework. They
> appear to differ slightly with regard to the additional
> mapping and case mapping rules. However,
> draft-oiwa-precis-httpauthprep-00 is merely a bit more
> restrictive with regard to matters that are purely optional
> according to draft-ietf-precis-saslprepbis-06. For example,
> the option of saying that "case mapping is not applied" is
> allowed by the text "uppercase and titlecase characters might
> be mapped to their lowercase equivalents".
> 
> To make this clearer, I suggest that we modify the advice in
> draft-oiwa-precis-httpauthprep-00 so that it no longer defines
> its own PRECIS profile. Instead, I suggest that we phrase the
> httpauthprep text in terms of the username profile in
> draft-ietf-precis-saslprepbis-06. To my mind, something like
> this would work:
> 
>### 
> 
> For the purposes of HTTP authentication, a username conforms
> to the syntax definition and preparation methods specified in
> [I.D-draft-ietf-precis-saslprepbis], with the following
> limitations:
> 
> * a username conforms to the "userpart" construction from
> [I-D.draft-ietf-precis-saslprepbis]
> * case mapping is not applied
> * delimiter mappings, special mappings, and other so-called
> additional mappings [I-D.draft-ietf-precis-mappings] are not
> applied
> 
>### 
> 
> As far as I can see, this simplifies the httpautheprep text
> quite a bit.
> 
> (By the way, draft-oiwa-precis-httpauthprep-00 also seems to
> copy the password profile verbatim from
> draft-ietf-precis-saslprepbis. I think this text can be
> removed entirely, so that the httpauthprep text can simply
> reference draft-ietf-precis-saslprepbis.)
> 
> Yutaka and Alexey (and others), let me know what you think
> about what I have written here.
> 
> Thanks,
> 
> Peter
> 
> _______________________________________________
> precis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/precis