[openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

[Richard Levitte]

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> 
openssl-users> 
openssl-users> > On Jun 1, 2018, at 6:47 PM, Richard Levitte <levitte at openssl.org> 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/