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
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
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
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
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 <
>
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.
> 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
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...)
> 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
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
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
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
> 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
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>
> 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
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
> 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,
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.
> >
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
>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 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
>
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
22 matches
Mail list logo
