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

2018-06-01 Thread Dr Paul Dale
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)

2018-06-01 Thread Viktor Dukhovni



> 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)

2018-06-01 Thread Richard Levitte
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)

2018-06-01 Thread Viktor Dukhovni



> 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)

2018-06-01 Thread Richard Levitte
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)

2018-06-01 Thread Viktor Dukhovni



> 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)

2018-06-01 Thread Kurt Roeckx
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] Is Mac a supported platform?

2018-06-01 Thread Viktor Dukhovni



> On Jun 1, 2018, at 5:26 PM, Salz, Rich  wrote:
> 
> So maybe I should just create a PR to update INSTALL with the Mac recipe?

I just use:

./Configure --prefix=/some/where [options] shared darwin64-x86_64-cc

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Richard Levitte
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


Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Salz, Rich
>Regarding the original question, it's "supported" insofar that we have
osx among the Travis builds (at least usually...  there have been
times when the osx backlog has been so great that we've temporarly
disabled it).
  
So maybe I should just create a PR to update INSTALL with the Mac recipe?

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Benjamin Kaduk
On Fri, Jun 01, 2018 at 06:52:21PM +, Salz, Rich wrote:
> Our INSTALL doesn’t mention it.  We have config’s for it.  I think we should 
> say we support it and update the various docs.  Thoughts?

The PR associated with the thread around
https://mta.openssl.org/pipermail/openssl-project/2018-January/68.html
seems likely to be relevant, though I don't think I have a link
handy.

-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)

2018-06-01 Thread Benjamin Kaduk
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)

2018-06-01 Thread Salz, Rich
>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)

2018-06-01 Thread Andy Polyakov
> 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)

2018-06-01 Thread Richard Levitte
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