Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
> On Jun 2, 2018, at 2:36 AM, Richard Levitte wrote: > >> Canonicalize when importing for use with the store API. > > Yup. > >> 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... Octet strings are by *defintion* not wide characters, they are an opaque string of *octets* (an array of uint8). The purpose of whchar_t and friends is to process non-ascii *character strings*, with the wide versions of strlen(), strchr(), ... We do none of this. We pass the opaque input to a key-derivation function that treats it as a opaque octet-string. > We cannot know with absolute certainty that it's UTF-8 encoded. Indeed someone could pass us an octet string that is not derived from the UTF-8 encoding of some actual character string entered by a user. That does not matter. What matters is that all user input is canonically encoded, in a *platform-independent* way. And for that the application is responsible for converting user input to UTF-8. If the application does not do it right, it will get incorrect (fail to decrypt) or non-portable (fail to decrypt in the future on other platforms) behaviour. > The way I saw it is that UTF-8 > really means Unicode, and a way to codify that is wchar_t. NO. That's not the point. UTF-8 yields a canonical encoding of what the user typed to an opaque octet string. That encoding is the application's responsibility. We must not treat the password as a character string, that's not portable. > 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. OK, looking at: https://tools.ietf.org/html/rfc7292#appendix-B.1 we see that PKCS#5 v2.1 sensibly defines passwords as opaque strings in some unspecified standard encoding (ASCII or UTF-8 for example). PKCS#12 however, is sadly requiring a 16-bit BMPString encoding (instead of UTF-8), presumably for backwards compatibility. > With that, the characters have meaning and need to be interpreted > correctly to form a standard compliant BMPString. Well, in that case for PKCS#12 we must require a well-formed UTF-8 input, which we can convert to BMPString without any need for locale-specific information. The ASN.1 library presumably can convert from UTF-8 to BMP, or code can be added to do that if missing. > (it would have been smarter to have the PKCS12 routines take wchar_t > strings rather than char strings... hindsight is what it is...) No, wchar_t is not defined to be a 16-bit BMPString compatible encoding. It is AFAIK a platform-specific string representation that is not canonical. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
On Fri, Jun 01, 2018 at 07:08:04PM -0400, Viktor Dukhovni wrote: > > > > On Jun 1, 2018, at 6:47 PM, Richard Levitte 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
Re: [openssl-project] Is Mac a supported platform?
https://github.com/openssl/openssl/pull/6404 On 6/1/18, 5:33 PM, "Richard Levitte" wrote: In message <1bd96940-3b3b-4758-938a-01e576306...@akamai.com> on Fri, 1 Jun 2018 21:26:12 +, "Salz, Rich" said: rsalz> >Regarding the original question, it's "supported" insofar that we have rsalz> osx among the Travis builds (at least usually... there have been rsalz> times when the osx backlog has been so great that we've temporarly rsalz> disabled it). rsalz> rsalz> So maybe I should just create a PR to update INSTALL with the Mac recipe? I don't understand why. In this regard, OS X is Unix. In other words, the quick recipe is what you already see in INSTALL: $ ./config $ make $ make test $ make install Are you telling me that this isn't understood? The only reason why VMS and Windows are mentioned specially, is that the commands on those platforms are syntactically different. Not so for OS X. But hey, if that helps, we can always do this: diff --git a/INSTALL b/INSTALL index 52e3f2ae6c..851093ec01 100644 --- a/INSTALL +++ b/INSTALL @@ -76,7 +76,7 @@ If you want to just get on with it, do: - on Unix: + on Unix (including Mac OS/X): $ ./config $ make Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
In message on Fri, 1 Jun 2018 19:08:04 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 6:47 PM, Richard Levitte 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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project