Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
On Wed, Jun 06, 2018 at 09:45:10AM +0200, Richard Levitte wrote: > Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some > point The only thing that evolved from UCS-2 to UTF-16 that I know of is Microsoft Windows. NT used UCS-2, 2000 changed that to UTF-16. Kurt ___ 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 Wed, Jun 06, 2018 at 11:23:55AM -0400, David Benjamin wrote: > > Is there a spec citation for this, or some documented experiments against > other implementations' behavior? (What do Microsoft and NSS do here?) I was > pondering something similar recently, but things do seem to point at UCS-2 > right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: I'm not sure which code I was looking at recently, probably NNS or gnutls, but it really restricted it to UCS-2. Kurt ___ 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)
Oh, I didn't realize that document existed. Although it doesn't say that it is overriding the BMPString restrictions. It says it "does not add any *further* restrictions to the input passwords of these methods, however it is RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as saying you should use UTF-16 NFC form, but only the subset that still satisfies the existing BMPString restrictions. It even recommends that "applications which restricted the MacData password to BMPString set" fail in some cases. If the intent was otherwise, probably worth some rewording. On Wed, Jun 6, 2018 at 11:36 AM Viktor Dukhovni wrote: > > https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4 > > https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2 > > > On Jun 6, 2018, at 11:23 AM, David Benjamin wrote: > > > > Is there a spec citation for this, or some documented experiments > against other implementations' behavior? (What do Microsoft and NSS do > here?) I was pondering something similar recently, but things do seem to > point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart, > but X.680 says: > > > > > BMPString is a subtype of UniversalString that has its own unique tag > and contains only the characters in the Basic Multilingual Plane (those > corresponding to the first 64K-2 cells, less cells whose encoding is used > to address characters outside the Basic Multilingual Plane) of ISO/IEC > 10646. > > > > RFC 7292 just says to use a BMPString. That doesn't suggest anyone has > actually updated it for UTF-16. This is fine for X.509 where BMPString is > one of many possible string types and folks can use UTF8String for this > anyway. For PKCS#12, yeah, this introduces limitations that may be worth > resolving, UTF-16 being the obvious fix. But if it's not in a spec, we > should get it into one and also be clear on if this is OpenSSL inventing a > behavior or following de facto behavior established elsewhere. > > -- > Viktor. > > ___ > 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)
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4 https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2 > On Jun 6, 2018, at 11:23 AM, David Benjamin wrote: > > Is there a spec citation for this, or some documented experiments against > other implementations' behavior? (What do Microsoft and NSS do here?) I was > pondering something similar recently, but things do seem to point at UCS-2 > right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: > > > BMPString is a subtype of UniversalString that has its own unique tag and > > contains only the characters in the Basic Multilingual Plane (those > > corresponding to the first 64K-2 cells, less cells whose encoding is used > > to address characters outside the Basic Multilingual Plane) of ISO/IEC > > 10646. > > RFC 7292 just says to use a BMPString. That doesn't suggest anyone has > actually updated it for UTF-16. This is fine for X.509 where BMPString is one > of many possible string types and folks can use UTF8String for this anyway. > For PKCS#12, yeah, this introduces limitations that may be worth resolving, > UTF-16 being the obvious fix. But if it's not in a spec, we should get it > into one and also be clear on if this is OpenSSL inventing a behavior or > following de facto behavior established elsewhere. -- 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 Wed, Jun 6, 2018 at 3:45 AM Richard Levitte wrote: > In message <4dca9a91-1487-4bfc-8a4e-b79fad473...@dukhovni.org> on Tue, 5 > Jun 2018 18:37:21 -0400, Viktor Dukhovni > said: > > openssl-users> > openssl-users> > openssl-users> > On Jun 3, 2018, at 4:45 AM, Richard Levitte < > levi...@openssl.org> wrote: > openssl-users> > > openssl-users> > Yeah, I just learned that myself. Somehow, I thought > wchar_t would be > openssl-users> > Unicode characters. So ok, with this information, UTF-8 > makes > openssl-users> > sense... > openssl-users> > openssl-users> Nico has convinced me that the mapping from UTF-8 to > BMPString should > openssl-users> be UTF-16, which is agrees with the BMP representation on > the code > openssl-users> points in the Basic Multinational Plane, but also supports > surrogate > openssl-users> pairs for code points outside the plane, so that if someone > wanted > openssl-users> to use "emoji" (or more traditional glyph outside the BMP) > for their > openssl-users> password, they could. This is a strict superset of UCS-2 > and avoids > openssl-users> having to reject some UTF-8 codepoints. > > Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some > point, and that evolution affected PKCS#12 objects... > Is there a spec citation for this, or some documented experiments against other implementations' behavior? (What do Microsoft and NSS do here?) I was pondering something similar recently, but things do seem to point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says: > BMPString is a subtype of UniversalString that has its own unique tag and contains only the characters in the Basic Multilingual Plane (those corresponding to the first 64K-2 cells, less cells whose encoding is used to address characters outside the Basic Multilingual Plane) of ISO/IEC 10646. RFC 7292 just says to use a BMPString. That doesn't suggest anyone has actually updated it for UTF-16. This is fine for X.509 where BMPString is one of many possible string types and folks can use UTF8String for this anyway. For PKCS#12, yeah, this introduces limitations that may be worth resolving, UTF-16 being the obvious fix. But if it's not in a spec, we should get it into one and also be clear on if this is OpenSSL inventing a behavior or following de facto behavior established elsewhere. ___ 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 <4dca9a91-1487-4bfc-8a4e-b79fad473...@dukhovni.org> on Tue, 5 Jun 2018 18:37:21 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote: openssl-users> > openssl-users> > Yeah, I just learned that myself. Somehow, I thought wchar_t would be openssl-users> > Unicode characters. So ok, with this information, UTF-8 makes openssl-users> > sense... openssl-users> openssl-users> Nico has convinced me that the mapping from UTF-8 to BMPString should openssl-users> be UTF-16, which is agrees with the BMP representation on the code openssl-users> points in the Basic Multinational Plane, but also supports surrogate openssl-users> pairs for code points outside the plane, so that if someone wanted openssl-users> to use "emoji" (or more traditional glyph outside the BMP) for their openssl-users> password, they could. This is a strict superset of UCS-2 and avoids openssl-users> having to reject some UTF-8 codepoints. Yup. It seems that BMPString evolved from UCS-2 into UTF-16 at some point, and that evolution affected PKCS#12 objects... 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
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
> On Jun 3, 2018, at 4:45 AM, Richard Levitte wrote: > > Yeah, I just learned that myself. Somehow, I thought wchar_t would be > Unicode characters. So ok, with this information, UTF-8 makes > sense... Nico has convinced me that the mapping from UTF-8 to BMPString should be UTF-16, which is agrees with the BMP representation on the code points in the Basic Multinational Plane, but also supports surrogate pairs for code points outside the plane, so that if someone wanted to use "emoji" (or more traditional glyph outside the BMP) for their password, they could. This is a strict superset of UCS-2 and avoids having to reject some UTF-8 codepoints. -- 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)
In message <04337360-c1db-4f02-ab85-cb1d679fc...@dukhovni.org> on Sat, 2 Jun 2018 14:27:42 -0400, Viktor Dukhovni said: openssl-users> > (it would have been smarter to have the PKCS12 routines take wchar_t openssl-users> > strings rather than char strings... hindsight is what it is...) openssl-users> openssl-users> No, wchar_t is not defined to be a 16-bit BMPString compatible openssl-users> encoding. It is AFAIK a platform-specific string representation openssl-users> that is not canonical. Yeah, I just learned that myself. Somehow, I thought wchar_t would be Unicode characters. So ok, with this information, UTF-8 makes sense... 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
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] 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
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
I also believe that we shouldn’t be relying on locale, it is a Pandora’s box we don’t want to open. Even claiming that OpenSSL is UTF-8 compliant is probably a stretch (e.g. the isXXX functions aren’t). Saying we accept unsigned eight bit byte inputs and process them unmodified is as far as I’d like to commit to. Pauli > On 2 Jun 2018, at 9:08 am, 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. > > -- > Viktor. > > ___ > 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)
> 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. -- 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)
In message <20180602.004350.1602483119932820478.levi...@openssl.org> on Sat, 02 Jun 2018 00:43:50 +0200 (CEST), Richard Levitte said: levitte> In message <7c04edbc-9d70-42ea-9ec9-6e6c4fbb8...@dukhovni.org> on Fri, 1 Jun 2018 18:23:48 -0400, Viktor Dukhovni said: levitte> levitte> openssl-users> levitte> openssl-users> levitte> openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote: levitte> openssl-users> > levitte> openssl-users> > (I'm currently looking into alternatives where a UI_METHOD can present levitte> openssl-users> > several variants of the same pass phrase, thus making it possible for levitte> openssl-users> > the application to virtually say "hey, try one of these" instead of levitte> openssl-users> > "hey, try this one"... that would be a way to have the application levitte> openssl-users> > provide the variants rather than libcrypto, and still only have to levitte> openssl-users> > know the bare minimum of what the URI represents (preferably nothing levitte> openssl-users> > at all)) levitte> openssl-users> levitte> openssl-users> If they're using a new API with a new store abstraction, I rather levitte> openssl-users> think it'd be better for the PKCS#12 data to be re-built with levitte> openssl-users> a UTF-8 password before it is exposed as a store URI. levitte> openssl-users> levitte> openssl-users> They should be able to decode the old file using legacy tooling, levitte> openssl-users> but the new tools should simply require canonical data. levitte> levitte> Ok, yeah, I can deal with that. In that case, though, it might make levitte> sense to extend the UI API with wchar_t capable functionality and levitte> require that functionality in the 'file' scheme loader, would it not? levitte> The application will then be forced to provide something that can be levitte> used directly or is easy to convert to UTF-8, as needed. 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...) -- 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
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
> On Jun 1, 2018, at 6:16 PM, Richard Levitte wrote: > > (I'm currently looking into alternatives where a UI_METHOD can present > several variants of the same pass phrase, thus making it possible for > the application to virtually say "hey, try one of these" instead of > "hey, try this one"... that would be a way to have the application > provide the variants rather than libcrypto, and still only have to > know the bare minimum of what the URI represents (preferably nothing > at all)) If they're using a new API with a new store abstraction, I rather think it'd be better for the PKCS#12 data to be re-built with a UTF-8 password before it is exposed as a store URI. They should be able to decode the old file using legacy tooling, but the new tools should simply require canonical data. Please DO NOT implement password variants. -- 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)
In message <14b35465-b944-492f-9c09-4a243d1aa...@dukhovni.org> on Fri, 1 Jun 2018 17:57:46 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote: openssl-users> > openssl-users> > That would then just mean that the apps need to do the correct openssl-users> > thing and convert it to UTF-8. openssl-users> openssl-users> Module legacy files, with a passphrase in some other encoding. openssl-users> For those the applications will have to provide the right openssl-users> non-UTF8 octet string, and I assume we'll just use that openssl-users> verbatim. Trouble is that OSSL_STORE is designed so the application doesn't have to know what type of object the URI represents. "provide the right string" requires that knowledge. (I'm currently looking into alternatives where a UI_METHOD can present several variants of the same pass phrase, thus making it possible for the application to virtually say "hey, try one of these" instead of "hey, try this one"... that would be a way to have the application provide the variants rather than libcrypto, and still only have to know the bare minimum of what the URI represents (preferably nothing at all)) -- 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
Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
> On Jun 1, 2018, at 5:51 PM, Kurt Roeckx wrote: > > That would then just mean that the apps need to do the correct > thing and convert it to UTF-8. Module legacy files, with a passphrase in some other encoding. For those the applications will have to provide the right non-UTF8 octet string, and I assume we'll just use that verbatim. -- -- 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 01:20:17PM -0500, Benjamin Kaduk wrote: > On Fri, Jun 01, 2018 at 12:23:39PM +, Salz, Rich wrote: > > >I think that the gist of the difference of opinion is whether it's OK > > to use locale dependent functions such as mbstowcs in libcrypto or > > not. > > > > > > Thanks for the summary. > > > > I am against use locale-dependent functions in libcrypto. > > I think it's pretty clear (at least to me), that such functions do > not belong in the normal path. I'd be open to considering them as a > fallback attempt to read existing data (as opposed to generating new > encrypted data), but find Andy's argument about nonpredictability > (combined with David Woodhouse's enumeration of the various cases > and the minimal utility of such conversions) to be fairly > compelling. That is, I am also against the use of functions that > depend on the current process's locale in libcrypto. (I phrase this > slightly differently, in that functions which take an explicit > locale to use might still be okay, but are not really portable > enough for us to use, AIUI.) So it's my understanding that the library functionw will always work in UTF-8 then, that's just fine for me. That would then just mean that the apps need to do the correct thing and convert it to UTF-8. Kurt ___ 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 12:23:39PM +, Salz, Rich wrote: > >I think that the gist of the difference of opinion is whether it's OK > to use locale dependent functions such as mbstowcs in libcrypto or > not. > > > Thanks for the summary. > > I am against use locale-dependent functions in libcrypto. I think it's pretty clear (at least to me), that such functions do not belong in the normal path. I'd be open to considering them as a fallback attempt to read existing data (as opposed to generating new encrypted data), but find Andy's argument about nonpredictability (combined with David Woodhouse's enumeration of the various cases and the minimal utility of such conversions) to be fairly compelling. That is, I am also against the use of functions that depend on the current process's locale in libcrypto. (I phrase this slightly differently, in that functions which take an explicit locale to use might still be okay, but are not really portable enough for us to use, AIUI.) -Ben ___ 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)
>I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. Thanks for the summary. I am against use locale-dependent functions in libcrypto. ___ 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)
> I think that the gist of the difference of opinion is whether it's OK > to use locale dependent functions such as mbstowcs in libcrypto or > not. > > The main arguments against allowing such functions in libcrypto is > that we should push applications to run with an UTF-8 input method > (whether that's provided by the terminal driver, or the process > holding the terminal, or the application itself...) rather than have > them call setlocale() with appropriate arguments (which is needed for > mbstowcs to work right). Assertion is rather that we can't/shouldn't rely on application to call setlocale and with argument suitable for specific purpose [of accessing PKCS#12 in this case]. And since we can't do that, we would be better off not calling mbstowcs. Because it adds a variable we have no control over. Given some specific input it would be more honest/appropriate to return error to application than to make outcome conditional on whether or not application called setlocale and with which argument. One can also view it as following: all applications get exactly same treatment. Pushing applications and users toward UTF-8 input method is merely a consequence of the suggestion to give all applications same treatment, it's not alternative by itself. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)
Hi, PR #6341 (https://github.com/openssl/openssl/pull/6341) is stuck in a battle of opinions that doesn't seem to get anywhere, so for all practical purposes, it's currently blocked. I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. The main arguments against allowing such functions in libcrypto is that we should push applications to run with an UTF-8 input method (whether that's provided by the terminal driver, or the process holding the terminal, or the application itself...) rather than have them call setlocale() with appropriate arguments (which is needed for mbstowcs to work right). The main argument for allowing such functions, in this case, is to make it easy for applications to load what PKCS#12 objects there are in the wild, no matter what program generated them, rather than force them to do all the conversion work (locale->UTF-8) and force the users to regenerate non-compliant PKCS#12 objects (i.e. PKCS#12 objects previously generated by libcrypto with passphrases encoded in anything other than ISO-8859-1 or UTF-8). (to be precise, mbstowcs is needed to convert the passphrase from a non-UTF-8 encoding to UTF-8, to allow reading of compliant PKCS#12 when run with a non-UTF-8 input method... running with a UTF-8 input method is the easy answer, except that this may make some PKCS#12 objects generated with libcrypto unreadable) Please help settle this (it's possible that this will become implicit policy) 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
