[openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
levitte at openssl.org
Sat Jun 2 06:36:09 UTC 2018
In message <E496AFEE-8109-40FD-AA8F-7E710775E13E at dukhovni.org> on Fri, 1 Jun 2018 19:08:04 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:
openssl-users> > On Jun 1, 2018, at 6:47 PM, Richard Levitte <levitte at openssl.org> wrote:
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> Canonicalize when importing for use with the store API.
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...)
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project