>> > 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 there are couple of ways to do it with "system methods", and as far as I can tell neither should be interoperable with what OpenSSL pkcs12 command-line utility does... >> ??? 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. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
