[openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 4:51 PM, Andy Polyakov <appro at openssl.org> wrote:



>
> >> ??? So suggestion is leave it as it is? Well, given the presented
> >> evidence doing the right thing should break things for you. But does it
> >> mean that one can/should be excused from getting things right?
> >
> > https://tools.ietf.org/html/rfc7292#appendix-B.1 says:
> >
> >    In this specification, however, all passwords are created from
> >    BMPStrings with a NULL terminator.  This means that each character in
> >    the original BMPString is encoded in 2 bytes in big-endian format
> >    (most-significant byte first).  There are no Unicode byte order
> >    marks.  The 2 bytes produced from the last character in the BMPString
> >    are followed by 2 additional bytes with the value 0x00.
> >
> > As I understand the text herein before, there is no ultimate
> specification.
>
> Correct. At the same time it should be noted that there is explicit
> reference to 2-byte encoding and Unicode. Well, one can argue that when
> they mention Unicode they refer to [lack of] byte order mark, and byte
> order mark only, and it has nothing to do with what that 2nd byte is
> used for. [Or shall we say "1st" as we are looking at big-endian?] But
> at the same time they don't say that the additional byte has to be zero.
> The only sensible and natural thing to do is to use these 2 bytes for
> storing UTF-16 character, not to mechanically inject zeros into UTF-8
> encoded string as now... Of course one can say that latter, essentially
> unnatural way, is de-facto standard and we are stuck with it. But that
> would have to mean that it has to be harmonized on Windows. I refer to
> how OpenSSL pkcs12 works on Windows, not what somebody else does. In
> other words there is a dilemma. A. Choose what is right thing to do and
> act accordingly. B. Accept status quo with Unix as reference and
> harmonize Windows. Alternative to dilemma is to explicitly disclaim
> support for non-ASCII characters in pkcs12 utility.
>

There is a specification in Russian,
http://tk26.ru/methods/containers_v1/Addition_to_PKCS8&PKCS12_v1_0.pdf

It says:
"The password Psw should be represented in UTF-8 format without trailing
zero byte and passed as the P element of the PBKDF2 algorithm"

The test example was provide by the authors of specification. There are
also examples in the document. May be it will be useful.


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151120/7f6c718a/attachment-0001.html>