Dear Andy, On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov <[email protected]> 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
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
