This is why I would prefer an open list of criteria rather than a few classes gathering rigidly a few of them. Special needs would be more easily addressed. jfc
2011/10/31, "Martin J. Dürst" <[email protected]>: > On 2011/10/29 5:43, Peter Saint-Andre wrote: >> On 10/18/11 1:20 PM, Patrik Fältström wrote: >>> >>> On 18 okt 2011, at 20:15, Peter Saint-Andre wrote: >>> >>>>>> However, we might want to provide some text in the security >>>>>> considerations about the desirability (or not) of full-Unicode >>>>>> passwords. > > For the record, there are other issues which make using full Unicode > passwords a problem. They mainly stem from the fact that you can't see a > password when you type it. This for example makes it very difficult to > e.g. use passwords with Han characters, because they are usually input > by using a phonetic method and then verifying/tweaking the converted result. > > [I don't think there's a need for this fact to go into the document.] > > Regards, Martin. > > >>>>> I'm slow, but what's the security consideration? There are >>>>> interoperability considerations: if two applications want to >>>>> co-operate in authentication, then they're going to need to use >>>>> Unicode or make up their own protocol. >>>> >>>> Right, it's text about interoperability. Where exactly that belongs is >>>> another matter. I'm happy to add a section about interoperability. >>> >>> Please separate the question on what charset (including encoding) is used >>> in the protocol with how comparisons (etc) is done. What is the >>> responsibility on the "client" and "server", etc. >> >> Here is proposed text. >> >> ### >> >> Although strings that are consumed in PRECIS-based application >> protocols are often encoded using UTF-8 [RFC3629], the exact encoding >> is a matter for the using protocol, not the PRECIS framework. >> >> It is known that some existing systems are unable to support the full >> Unicode character set, or even any characters outside the US-ASCII >> range. If two (or more) applications need to interoperate when >> exchanging data (e.g., for the purpose of authenticating a username >> or password), they will naturally need have in common at least one >> coded character set (as defined by [RFC6365]). Establishing such a >> baseline is a matter for the using protocol, not the PRECIS >> framework. >> >> ### >> >> _______________________________________________ >> precis mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
