[openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[Andy Polyakov]

> So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
> and the locale (not that it *should* matter) is ISO8859-2.

When it comes to locale in *this* case you should rather wonder what
does your terminal emulator program do and how does it interact with
your shell. Because these two are responsible for composing the string
that OPENSSL_[asc|utf8]2uni gets.

> The correct rendition is 01 02 01 7b.

Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as
argument or console input under an UTF-8 locale. Otherwise it would have
been passed as 'c3 af'.

> The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
> to *convert* to ISO8859-2 (giving c3 af).

No, no conversion from UTF-8 to ISO8859-x or any other conversion was
*ever* performed. Nor is it performed now. It was and still is all about
how string is composed by *somebody else*. That's why I said that "we
assume that you don't change locale when you upgrade OpenSSL".

> Then to interpret those bytes
> as ISO8859-1 (in which they would mean "ï") and convert *that* to
> UTF16LE to give 00 c3 00 af

Previously OpenSSL would convert 'c4 82 c5 bb' to '00 c4 00 82 00 c5 00
bb'. Now it converts it to '01 02 01 7b', but attempts even '00 c4 00 82
00 c5 00 bb' for "old times sake". And for 'c3 af' question is if it's
valid UTF-8 encoding. If it is (it is in this example), then it would
attempt '00 ef' (in this example) and then '00 c3 00 af', and if not,
then it would go straight to '00 c3 00 af'.