>> The way I read PKCS12 the string should be big-endian UTF-16 one. > [...] >> Correct procedure should be to convert it to wchar_t and >> then ensure correct endianness. > > Please note that wchar_t itself might not have any relation with > UTF. You should explictly convert from the locale charmap to > UTF16-BE.
Right, it was kind of sloppy formulation. > Depending on the OS, there are functions available to ask what the > current encoding is and convert between encodings. And question also is who should be responsible for the conversion. For example in order to make it work you might have to mess up locale, and a library in general is hardly the right place, and libcrypto in particular is terrible place to do that. Nor does one want to create dependency on library like iconv, not in libcrypto. In other words I'd say that it's not unreasonable to specify which input do we expect in libcrypto and put whole responsibility to ensure that input is right on caller. Formally one can say nothing needs to be changed in libcrypto, indeed there is _asc and _uni, i.e. ASCII and verbatim implying big-endian UTF-16. Though this is not an excuse for not doing anything about pkcs12 command-line utility... At the same time one can still argue that since there is a convenience _asc interface, there ought to be convenience utf8 one (and as already implied not dependent on current locale?)... _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
