Subject: Re: [iucg] [precis] passwords as octet strings

From: JFC Morfin <[email-masked]>
Date: Mon, 31 Oct 2011 11:48:19 +0100

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-masked]>:
> 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-masked]
>> https://www.ietf.org/mailman/listinfo/precis
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
>