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)
> On Jun 6, 2018, at 12:52 PM, David Benjamin wrote: > > 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. The point is that instead of failing we should use UTF-16 for non-BMP code points. Worst case we'll still fail. We can document a warning that passwords outside the BMP are non-portable. The responsibility for ensuring NFC form will be placed on the application feeding us the UTF-8 data. We should just convert from UTF-8 to UTF-16. I don't read the draft as forbidding non-BMP UTF-16. The two agree on the UCS-2 subset of UTF-16 (i.e. the BMP code points). If the intent is to forbind non-BMP passwords, we should ask the authors to change that, with a portability warning. Such passwords might not work everywhere, but forbidding them is unwise. -- 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)
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
