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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 22 Oct 2014 20:38:38 -0600

[ Old thread alert! ]

On 3/25/14, 12:52 AM, Yutaka OIWA wrote:
> Dear Peter,
>
> I have a side question: looking into saslprepbis spec,
>
>   username   = userpart [1*(1*SP userpart)]
>                / userpart ’@’ domainpart
>
>     userpart   = 1*(idpoint)
>
>     domainpart = IP-literal / IPv4address / ifqdn
>
>     ifqdn      = 1*1023(domainpoint)
>
> Is the set of strings generated by "userpart '@' domainpart"
> the proper subset of the set generated by userpart rule?

Yes, I think so.

(Compare the derived property calculation rules in RFC 5892 against 
draft-ietf-precis-framework.)

> If so, I will be more-than-80% happy by just removing the
> redundant second line from the username rule.

Do you mind if we explain in the text that it is possible to create such 
a construct? See also:

https://tools.ietf.org/html/draft-ietf-precis-framework-18#section-4.2

> We (from HTTP side) do not want any rule which may
> even *seem* to handle any characters (here, the @ mark)
> specially than others. It's up to the application's own definition.

Yes, and that's what the PRECIS framework says.

> We're aware of some use case for which
> the application defines a meaningful semantics
> for strings with 2 @ marks.
> (user@domain style identifier used for roaming accesses,
>   appended with another @provider-domain suffix.
>   So, the result is user@internal-domain@external-domain.)
>
> (Exception: the colon is special in HTTP Basic and Digest,
>   but I see it as a known technical issue of these and
>   should not be generalized for every HTTP authentication.)
>
> I have to (and will) dig in to the original Unicode table for
> more analysis, but the thing I intuitively want seems to be
> something between IdentifierClass and FreeFormClass.

I think you want a username, if we adjust the saslprepbis definition 
slightly.

> My answers to the Peter's questions:
>
>> "Y                     u            taka  O   i    w     a"
>
> Current HTTP allows it, and we don't need to reject that mostly.

Does the HTTPAUTH WG want to support everything that HTTP currently 
supports, or is it open to restricting things a bit more?

Usernames like that don't make sense to me. However, I don't think I 
have a strong reason for disliking them, other than UX concerns. So I'm 
open to loosening the saslprepbis rules here, if only to prevent forking 
(or another profile just for HTTPAUTH).

> (and saslprepbis's username acutally allows it except the last spaces.)
>
>> "♖♘♗♕♔♗♘♖" (i.e., the back line of white chess pieces)
>
> I have a 50-50 feeling on this, little bit offseted to accept.
> It's really weired, *I* will never use this, but it's still harmless, I think.
> Someone may be using this as a funny identifier.

IMHO it's appropriate as a nickname but not as a username. But perhaps 
I'm being too strict.

Note: if we allow those characters, then we're far beyond the PRECIS 
IdentifierClass (which forbids symbols). So if the HTTPAUTH WG wants to 
support symbols, it needs to profile the PRECIS FreeformClass.

> I think I have to convince HTTP people that it's harmful.

Well, it would require another profile, since we're not going to allow 
symbols into the PRECIS IdentifierClass.

>> "mycatisa       bby" (where those spaces are actually a tab)
>
> I think this should be either rejected or replaced with a single space.

So no control characters. That's something. :-)

> The support: most text input field of modern applications accepts
> the top two, but for the last case some apps are rejecting TAB.
> At least, almost all applications explicitly filter CR and LF out.

OK.

> I think we can declare that "CR, LF, TAB, SHY and NBSP are harmful
> so we should handle it as a part of I18N string handling".
> It's the purpose of PRECIS, I agree.
> (and that's why I am strongly opposing against "just UTF-8" in HTTPAUTH WG).

Has there been further discussion about this in the HTTPAUTH WG? I'm on 
that mailing list and I haven't seen much discussion on this topic.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 26 Oct 2014 12:36:08 +0900

Hello Peter,

> supports, or is it open to restricting things a bit more?

I think the main question here would be deployability. The server is 
under control of the person who decides what to allow, and clients get 
eventually updated. But introducing restrictions like this might mean 
upgrading *users*.

Essentially, the server operator will have to mechanically check which 
user names won't work anymore in the new protocol, and then contact 
these users and ask them to change their user name or tell them that 
their user name was modified. Not all users might like that.

> that mailing list and I haven't seen much discussion on this topic.

Me neither.

Regards,   Martin.

---

From: Yutaka OIWA <[email-masked]>
Date: Sun, 26 Oct 2014 13:44:56 +0900

Hello Martin,

> I think the main question here would be deployability. The server is under control of the person who decides what to allow, and clients get eventually updated. But introducing restrictions like this might mean upgrading *users*.

Yes. However, at the same time, the character set which is currently
officially allowed on HTTP spec is ISO-8859-1 only, the ad-hoc handling of
non-ISO-8859-1 characters on HTTP authentication at this moment
is anyway not guaranteed to be interoperable.
(And because of ad-hoc handling of non-ISO-8859-1 characters,
 The latter half of ISO-8859-1 is also not well interoperable in reality.)

The HTTP community is going to adopt use of UTF-8 (with explicit
flag for using that), and it will anyway break backward compatibility
with non-ASCII usernames/passwords. (It will explicitly change
encoding of non-ASCII, ISO-8859-1 characters.)

It means that, at this moment, we CAN define the proper way of
handling for non-ASCII UTF-8 strings (with possible smallest
incompatibility with existing ad-hoc implementations),
and it is the last possible moment to do that
without severely breaking backward compatibility with
spec-conformant implementations.

Of course, it should not break any compatibility with existing
ASCII printable username/passwords.

2014-10-26 12:36 GMT+09:00 "Martin J. Dürst" <[email-masked]>:
> I think the main question here would be deployability. The server is under
> control of the person who decides what to allow, and clients get eventually
> updated. But introducing restrictions like this might mean upgrading
> *users*.
>
> Essentially, the server operator will have to mechanically check which user
> names won't work anymore in the new protocol, and then contact these users
> and ask them to change their user name or tell them that their user name was
> modified. Not all users might like that.
>
>

---

From: "Black, David" <[email-masked]>
Date: Sun, 26 Oct 2014 16:11:11 +0000

> updated. But introducing restrictions like this might mean upgrading *users*.
>

+1 on getting off of 8859-* being a good thing to do (IMHO).  Among other
items, I'd be concerned about non-ASCII characters being interpreted and
rendered in the wrong 8859 charset when the locale uses an 8859 charset
other than 8859-1.  At a minimum, Unicode doesn't have that problem ;-).

Thanks,
--David

> -----Original Message-----
> From: precis [mailto:[email-masked]] On Behalf Of Yutaka OIWA
> Sent: Sunday, October 26, 2014 12:45 AM
> To: Martin J. Dürst
> Cc: [email-masked]
> Subject: Re: [precis] usernames in PRECIS and http-auth
> 
> Hello Martin,
> 
> updated. But introducing restrictions like this might mean upgrading *users*.
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 27 Oct 2014 09:25:31 -0600

> ASCII printable username/passwords.

I think it's probably best to have this discussion on the HTTPAUTH list. 
I will start a thread there.

Peter

-- 
Peter Saint-Andre
https://andyet.com/