> On Jun 6, 2018, at 12:52 PM, David Benjamin <[email protected]> wrote:
>
> Oh, I didn't realize that document existed. Although it doesn't say that it
> is overriding the BMPString restrictions. It says it "does not add any
> further restrictions to the input passwords of these methods, however it is
> RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as saying
> you should use UTF-16 NFC form, but only the subset that still satisfies the
> existing BMPString restrictions. It even recommends that "applications which
> restricted the MacData password to BMPString set" fail in some cases.
>
> If the intent was otherwise, probably worth some rewording.
The point is that instead of failing we should use UTF-16 for non-BMP code
points.
Worst case we'll still fail. We can document a warning that passwords outside
the BMP are non-portable. The responsibility for ensuring NFC form will be
placed
on the application feeding us the UTF-8 data. We should just convert from
UTF-8 to
UTF-16.
I don't read the draft as forbidding non-BMP UTF-16. The two agree on the UCS-2
subset of UTF-16 (i.e. the BMP code points). If the intent is to forbind
non-BMP
passwords, we should ask the authors to change that, with a portability warning.
Such passwords might not work everywhere, but forbidding them is unwise.
--
Viktor.
_______________________________________________
openssl-project mailing list
[email protected]
https://mta.openssl.org/mailman/listinfo/openssl-project
