On Fri, Jun 01, 2018 at 07:08:04PM -0400, Viktor Dukhovni wrote: > > > > On Jun 1, 2018, at 6:47 PM, Richard Levitte <levi...@openssl.org> wrote: > > > > Ah, forgot one important detail: it is well understood that *all* > > file based objects will get the same requirements, right? That goes > > for anything protected through PKCS#5 as well (good ol' PEM > > encryption, PKCS#8 objects and whatever else I forget...) > > Canonicalize when importing for use with the store API. Not sure > whether wchar_t though, just octet string in UTF-8 seems saner. > That is the password is an opaque byte string, not a character > string in the platform's encoding of i18n strings.
Whatever we do, it should be clear that we expect the application to give us the password in a standardized way, so that we can do with it what is needed. If it's something the user types, a password really contains characters, and so whar_t is really a natural way to pass this. It would at least be very clear to the application what it needs to do. whar_t is part of C89, which is still what we target, so it should be supported. But then we actually have targets that will most likely not support this and never will. So the other solution is that this gets passed in a fixed charset like UTF-8 or UTF-16. Kurt _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
