Subject: [precis] Fwd: [http-auth] Allowed Characters in usernames and passwords

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 14 Nov 2014 19:00:54 -0700

FYI.

-------- Original Message --------
Subject: [http-auth] Allowed Characters in usernames and passwords
Date: Fri, 14 Nov 2014 15:59:00 -1000
From: Yoav Nir <[email-masked]>
To: IETF HTTP Auth <[email-masked]>

Hi

An issue that has been discussed on the list has been what characters 
are allowed for usernames and passwords in the Basic and Digest 
documents (this probably also applies to other specification, 
specifically MutualAuth, but that is not the issue in this message).

So the precis working group is creating the saslprepbis ([1]) document 
that should be published soon (as soon as the end of this year). That 
contains a profile for characters that are and aren’t recommended for 
use in username and passwords.

So the proposal that reflects the consensus of the people in today’s 
session is as follows:

Both the Basic and Digest drafts will mandate that supporting servers 
MUST support usernames and passwords that conform to the saslprepbis 
specification, and MAY support non-conforming ones. The rationale is 
that we have to have a MAY there, because we can’t prohibit stuff that 
works today. Both documents will add text with these MUST and MAY.

The room was unanimous in supporting this direction. If you disagree, 
please comment to the list by Monday 24-Nov-2014. Since we had a strong 
hum for in the room, we will take silence as consensus

Thanks

Matt & Yoav

[1] https://tools.ietf.org/html/draft-ietf-precis-saslprepbis-09
_______________________________________________
http-auth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-auth

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 15 Nov 2014 00:03:30 -0500

--On Friday, November 14, 2014 19:00 -0700 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> An issue that has been discussed on the list has been what
> characters are allowed for usernames and passwords in the
> Basic and Digest documents (this probably also applies to
> other specification, specifically MutualAuth, but that is not
> the issue in this message).
> 
> So the precis working group is creating the saslprepbis ([1])
> document that should be published soon (as soon as the end of
> this year). That contains a profile for characters that are
> and aren't recommended for use in username and passwords.
> 
> So the proposal that reflects the consensus of the people in
> today's session is as follows:
> 
> Both the Basic and Digest drafts will mandate that supporting
> servers MUST support usernames and passwords that conform to
> the saslprepbis specification, and MAY support non-conforming
> ones. The rationale is that we have to have a MAY there,
> because we can't prohibit stuff that works today. Both
> documents will add text with these MUST and MAY.
> 
> The room was unanimous in supporting this direction. If you
> disagree, please comment to the list by Monday 24-Nov-2014.
> Since we had a strong hum for in the room, we will take
> silence as consensus

Peter, Yoav,

Given my ongoing mini-campaign to reduce the number of profiles
and sets of rules to an absolute minimum because users won't be
able to keep track of different ones and will only be astonished
and confused, this is exceptionally good news.    Two comments:

(1) While the assertion that you "can't prohibit stuff that
works" is probably true, you are not thereby limited to MAY.  It
would be entirely consistent with IETF practices in the past to
say "MUST support ... that conform and SHOULD avoid
non-conforming ones except when the latter are justified by
compatibility with existing implementations".  That still
doesn't _prohibit_ the existing practices, but makes the desired
compatibility norm somewhat more clear.

(2) I assume there are recommendations coming out of WHATWG
and/or W3C that might interact with whatever HTTP-AUTH has to
say.  If that is the case, I expect that the HTTP-AUTH
recommendation will either be consistent with them or will
identify and explain the differences.

It would be reasonable for you to assume that both comments
above will, if necessary, be repeated during IETF Last Call.

best,
    john