[openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Dear Andy,

On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov <appro at openssl.org> wrote:
>
> > I understand that there should be problems with Windows.
>
> To eliminate possibility of misunderstanding. Claim is not limited to
> problems with Windows, but that OpenSSL handles non-ASCII characters in
> apparently non-interoperable way. On all systems. I referred to Windows
> as complicating factor in the problem, not whole/separate problem.


Yes, I understand it.

>
>
> > So the test PKCS12 object was created using Windows using a
> > GOST-providing CSP.
> >
> > I do not know whether the authors of the CSP have implemented their own
> > mechanism of transforming the password or used any provided by the
> > Windows system default.
>
> What are chances that they too used same formally incorrect approach?


I think that they use the system method, if any, because it means they do
not increase their work :-)

>
> > But in fact the openssl being built without defining the PBE_UNICODE
> > macros was able to parse the test PKCS12.
>
> Right. Doing otherwise will put burden of big-endian UTF-16 conversion
> on caller and chances that caller gets it right are low.


Ok.

>
>
> > Thank you!
>
> ??? 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:

The underlying password-based encryption methods in PKCS #5 v2.1 view
   passwords (and salt) as being simple byte strings.
...
What's left unspecified in the above paragraph is precisely where the
   byte string representing a password comes from.  (This is not an
   issue with salt strings, since they are supplied as a password-based
   encryption (or authentication) parameter.)  PKCS #5 v2.1 says: "[...]
   a password is considered to be an octet string of arbitrary length
   whose interpretation as a text string is unspecified.  In the
   interest of interoperability, however, it is recommended that
   applications follow some common text encoding rules.  ASCII and UTF-8
   are two possibilities."

   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.

So I would prefer a set of options be specified by the caller with a
reasonable default value.
But as I do not have enough PKCS#12 from real-life sources, I can't predict
this default value.

Currently the openssl is in "works for me" state. To propose changes, I
need to have a set of mismatching PKCS#12 files.

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