On 10/4/13 6:46 AM, Alexey Melnikov wrote:
> On 24/09/2013 22:17, Simon Josefsson wrote:
>> You wrote:
>>>>>>>> "Simon" == Simon Josefsson <[email protected]> writes:
>>> Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't
>>> Simon> believe any of that will happen, so we'll have to live with
>>> Simon> case sensitive usernames, and my take is that I18N
>>> Simon> documents should permit that.
>>>
>>> I'm not sure any of the above hase case sensitive usernames.
>>> They permit usernames to be case sensitive.
>>> However a lot of implementations treat the username as case
>>> insensitive.
>>>
>>> I do think this is an appropriate issue for an IETF an document, but I
>>> do think considering the impact on legacy systems is important.
>>> I don't think we need to require there be no impact, simply understand
>>> an accept it.
>> Agreed, but the devil is in the detail. For example, I would say that
>> any I18N effort that changes how ASCII usernames ([A-Za-z0-9...])
>> behave have gone too far down the road that causes damage to legacy
>> systems.
> Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a
> SHOULD, so I think you are Ok. I.e. compatibility with a legacy system
> is a good enough reason to violate the SHOULD.
Correct.
Here is proposed text for Section 4 on usernames. I've provided proposed
text for the entire section so that folks on both the PRECIS and KITTEN
lists have the complete context.
Please review this proposed text and provide comments.
###
4. Usernames
4.1. Definition
This document specifies that a username is a string of Unicode code
points [UNICODE], encoded using UTF-8 [RFC3629], and structured
either as an ordered sequence of "userparts" (where the complete
username can consist of a single userpart or a space-separated
sequence of userparts) or as a userpart@domainpart (where the
domainpart is an IP literal, an IPv4 address, or a fully-qualified
domain name).
The syntax for a username is defined as follows using the Augmented
Backus-Naur Form (ABNF) [RFC5234].
username = userpart [1*(1*SP userpart)]
/ userpart '@' domainpart
userpart = 1*(idpoint)
;
; an "idpoint" is a UTF-8 encoded Unicode code point
; that conforms to the PRECIS "IdentifierClass"
;
domainpart = IP-literal / IPv4address / ifqdn
;
; the "IPv4address" and "IP-literal" rules are
; defined in RFC 3986, and the first-match-wins
; (a.k.a. "greedy") algorithm described in RFC 3986
; applies
;
; reuse of the IP-literal rule from RFC 3986 implies
; that IPv6 addresses are enclosed in square brackets
; (i.e., beginning with '[' and ending with ']')
;
ifqdn = 1*1023(domainpoint)
;
; a "domainpoint" is a UTF-8 encoded Unicode code
; point that conforms to RFC 5890
;
All code points and blocks not explicitly allowed in the PRECIS
IdentifierClass are disallowed; this includes private use characters,
surrogate code points, and the other code points and blocks that were
defined as "Prohibited Output" in [RFC4013]. In addition, common
constructions such as "[email protected]" are allowed as usernames
under this specification, as they were under [RFC4013].
4.2. Preparation
Each userpart of a username MUST conform to the
"UsernameIdentifierClass" profile of the PRECIS IdentifierClass,
which is defined as follows:
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.
With regard to directionality, the "Bidi Rule" provided in [RFC5893]
applies.
A username MUST NOT be zero bytes in length. This rule is to be
enforced after any normalization and mapping of code points.
In protocols that provide usernames as input to a cryptographic
algorithm such as a hash function, the client will need to perform
proper preparation of the username before applying the algorithm.
4.2.1. Case Mapping
Case mapping is a matter for the application protocol, protocol
implementation, or end deployment. In general, this document
suggests that it is preferable to perform case mapping, since not
doing so can lead to false positives during authentication and
authorization (as described in [RFC6943]) and can result in confusion
among end users given the prevalence of case mapping in many existing
protocols and applications. However, there can be good reasons to
not perform case mapping, such as backward compatibility with
deployed infrastructure.
In particular:
o SASL mechanisms that directly re-use this profile MUST specify
whether and when case mapping is to be applied to authentication
identifiers. SASL mechanisms SHOULD delay any case mapping to the
last possible moment, such as when doing a lookup by username,
username comparisons, or generating a cryptographic salt from a
username. In keeping with RFC4422, SASL mechanisms are not to
apply this or any other profile to authorization identifiers.
o Application protocols that use SASL (such as IMAP [RFC3501] and
XMPP [RFC6120]) and that directly re-use this profile MUST specify
whether case mapping is to be applied to authorization
identifiers. Such "SASL application protocols" SHOULD delay any
case mapping of authorization identifiers to the last possible
moment, which happens to necessarily be on the server side. In
keeping with RFC4422, SASL application protocols are not to apply
this or any other profile to authentication identifiers.
o Application protocols that do not use SASL (such as HTTP
authentication with the Basic and Digest schemes [RFC2617]) MUST
specify whether and when case mapping is to be applied to
authentication identifiers and authorization identifiers. Such
"non-SASL application protocols" SHOULD delay any case mapping to
the last possible moment, such as when doing a lookup by username,
username comparisons, or generating a cryptographic salt from a
username.
If the specification for a SASL mechanism, SASL application protocol,
or non-SASL application protocol specifies the handling of case
mapping for strings that conform to the UsernameIdentifierClass, it
MUST clearly describe whether case mapping is required, recommended,
or optional at the level of the protocol itself, implementations
thereof, or service deployments.
###
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
