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

2018-06-02 Thread Viktor Dukhovni



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

2018-06-02 Thread Kurt Roeckx
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?

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

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