In message <[email protected]> on Fri, 1 Jun 2018 19:08:04 -0400, Viktor Dukhovni <[email protected]> said:
openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 6:47 PM, Richard Levitte <[email protected]> wrote: openssl-users> > openssl-users> > Ah, forgot one important detail: it is well understood that *all* openssl-users> > file based objects will get the same requirements, right? That goes openssl-users> > for anything protected through PKCS#5 as well (good ol' PEM openssl-users> > encryption, PKCS#8 objects and whatever else I forget...) openssl-users> openssl-users> Canonicalize when importing for use with the store API. Yup. openssl-users> Not sure whether wchar_t though, just octet string in UTF-8 seems saner. Dunno about that, really. The aim, to quote David W, is to make it *hard* for applications to get it wrong, and we all know that an octet string is merely an octet string... we cannot know with absolute certainty that it's UTF-8 encoded. The way I saw it is that UTF-8 really means Unicode, and a way to codify that is wchar_t. openssl-users> That is the password is an opaque byte string, not a character openssl-users> string in the platform's encoding of i18n strings. Here is, unfortunately, where standards differ. PKCS#12 has a requirement that makes the pass phrase anything but opaque. With that, the characters have meaning and need to be interpreted correctly to form a standard compliant BMPString. (it would have been smarter to have the PKCS12 routines take wchar_t strings rather than char strings... hindsight is what it is...) Cheers, Richard -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
