Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>Except that, because of the way PKCS12_gen_mac() works, this isn't
true.  If the input pass phrase looks like a UTF-8 encoded string
(because there are valid characters in other encodings that will like
like UTF-8 byte sequences), it will be used as if -passutf8 was given
instead.
  
Well, at least I started down the path.  I wonder if one of those flags should 
set the keygen to asc?

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


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Richard Levitte
In message 

 on Mon, 11 Jun 2018 16:17:33 +, Bernd Edlinger  
said:

bernd.edlinger> So in my opinion when entering new passwords it should be 
restricted to
bernd.edlinger> 7bit ASCII printable characters, except if advised otherwise by 
an
bernd.edlinger> option like -pass8bit.

That's Rich's intent, and I'm fine with that.  It's the fine print of
what message we tell with -pass8bit that's being disputed.

-- 
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] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Richard Levitte
In message <5ba62036-bd2e-41b7-adf9-25c6c116e...@akamai.com> on Mon, 11 Jun 
2018 16:03:48 +, "Salz, Rich"  said:

rsalz> >I have zero idea what the doc says, because I haven't seen the docs
rsalz> yet.  Did I miss the PR?
rsalz>   
rsalz> No.  It's posted here on the mailing list for discussion and reposted 
here:

Ah, found it in the archive...  I somehow glossed over it before,
sorry.

rsalz> +If B<-pass8bit> is given, the password is taken to be encoded in the 
current
rsalz> +locale, but is still used directly; note that
rsalz> +a future release might automatically convert the password to valid UTF-8
rsalz> +encoding if this flag is given.

Except that, because of the way PKCS12_gen_mac() works, this isn't
true.  If the input pass phrase looks like a UTF-8 encoded string
(because there are valid characters in other encodings that will like
like UTF-8 byte sequences), it will be used as if -passutf8 was given
instead.

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] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Bernd Edlinger
On 06/11/18 17:40, Richard Levitte wrote:
> In message <8ee45344-9bfc-44f9-9db2-c384f7645...@akamai.com> on Mon, 11 Jun 
> 2018 15:25:23 +, "Salz, Rich"  said:
> 
> rsalz> >*must* do when getting '-pass8bit' is to do a naïve UTF-8 encode 
> of
> rsalz> the input pass phrase string.  PKCS12_generate_mac() will then 
> decode
> rsalz>
> rsalz> I disagree.
> rsalz>
> rsalz> There are two reasons why users enter "illegal" passwords now,
> rsalz> and by now requiring them to make it explicit we can (a) check
> rsalz> only for ASCII on current inputs; (b) make them thing about
> rsalz> what they're doing and require them to specify; (c) set the
> rsalz> expectation that something will change in the future.
> 
> [btw, PKCS12_gen_mac(), not PKCS12_generate_mac()]
> 
> So wait, if the user enters this:
> 
>  openssl pkcs12 -export -in foo.pem -out foo.p12 \
>  -pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p`
> 
> ...  then it seems "natural" that the user would expect the resulting
> BMPString to become this set of bytes, right?
> 
>  0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00
> 
> However, what's going to happen is that PKCS12_gen_mac() will generate
> this for a BMPString:
> 
>  0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00
> 
> Why?  Because the input pass phrase can be interpreted as a UTF-8
> encoded string, and PKCS12_gen_mac() will decode it thusly.
> 
>  From a user interface point of view, I would fine such behavior very
> surprising, and not at all what I'd expect for a flag named '-pass8bit'
> 

I think there are many ways for the user to shoot into his own knee with
entering unicode glyphs accidentally, with are even invisible when
printed to the console, just think of the EM DASH U+2014: "—"
Or unicode non break space U+00A0 which looks like an ordinary space but
is something different

As a user, I would not be happy if one of these slipped into a password,
that's certainly sure.

So in my opinion when entering new passwords it should be restricted to
7bit ASCII printable characters, except if advised otherwise by an
option like -pass8bit.


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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>I have zero idea what the doc says, because I haven't seen the docs
yet.  Did I miss the PR?
  
No.  It's posted here on the mailing list for discussion and reposted here:


+=item B<-passutf8>, B<-pass8bit>
+
+These flags indicate the character set encoding on the password value.
+By default, non-ASCII characters are rejected. This is new behavior
+with OpenSSL 1.1.1,
+and is used to enforce compliance with the PKCS#12 standard.
+If B<-passutf8> is given, then the password is taken to be valid UTF-8 
encoding,
+and will be used directly.
+If B<-pass8bit> is given, the password is taken to be encoded in the current
+locale, but is still used directly; note that
+a future release might automatically convert the password to valid UTF-8
+encoding if this flag is given.
+


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


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Richard Levitte
In message <8ee45344-9bfc-44f9-9db2-c384f7645...@akamai.com> on Mon, 11 Jun 
2018 15:25:23 +, "Salz, Rich"  said:

rsalz> >*must* do when getting '-pass8bit' is to do a naïve UTF-8 encode of
rsalz> the input pass phrase string.  PKCS12_generate_mac() will then decode
rsalz>   
rsalz> I disagree.
rsalz> 
rsalz> There are two reasons why users enter "illegal" passwords now, and by 
now requiring them to make it explicit we can (a) check only for ASCII on 
current inputs; (b) make them thing about what they're doing and require them 
to specify; (c) set the expectation that something will change in the future.

A variant is to check if the 8bit string can be decoded as a UTF-8
string and warn the user that such string is going to get screwed.

-- 
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] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
>However, what's going to happen is that PKCS12_gen_mac() will generate
this for a BMPString:
  
Which is what we do now, right?

And the docs for this *new flag* explain that the behavior could change in the 
future.

To be "pass8bit" means "pass 8bit bytes through to lower layer"  But if we want 
to bikeshed about the name of the flag, fine.


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


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Richard Levitte
In message <8ee45344-9bfc-44f9-9db2-c384f7645...@akamai.com> on Mon, 11 Jun 
2018 15:25:23 +, "Salz, Rich"  said:

rsalz> >*must* do when getting '-pass8bit' is to do a naïve UTF-8 encode of
rsalz> the input pass phrase string.  PKCS12_generate_mac() will then decode
rsalz>   
rsalz> I disagree.
rsalz> 
rsalz> There are two reasons why users enter "illegal" passwords now,
rsalz> and by now requiring them to make it explicit we can (a) check
rsalz> only for ASCII on current inputs; (b) make them thing about
rsalz> what they're doing and require them to specify; (c) set the
rsalz> expectation that something will change in the future.

[btw, PKCS12_gen_mac(), not PKCS12_generate_mac()]

So wait, if the user enters this:

openssl pkcs12 -export -in foo.pem -out foo.p12 \
-pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p`

...  then it seems "natural" that the user would expect the resulting
BMPString to become this set of bytes, right?

0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00

However, what's going to happen is that PKCS12_gen_mac() will generate
this for a BMPString:

0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00

Why?  Because the input pass phrase can be interpreted as a UTF-8
encoded string, and PKCS12_gen_mac() will decode it thusly.

>From a user interface point of view, I would fine such behavior very
surprising, and not at all what I'd expect for a flag named '-pass8bit'

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] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Richard Levitte
In message  on Mon, 11 Jun 
2018 15:06:01 +, "Salz, Rich"  said:

rsalz> > If B<-pass8bit> is given, the password is taken to be encoded in 
the current
rsalz> > locale, but is still used directly.
rsalz> > A future release might automatically convert the password to valid 
UTF-8
rsalz> > encoding if this flag is given.
rsalz> 
rsalz> I would propose that "-pass8bit" means that each byte of the input is
rsalz> a unicode code point value (i.e. ASCII or LATIN1 supplement) and 
we'll
rsalz> convert to UCS-2 by prepending 0x00 to each one.  If so, I would 
expect
rsalz> this flag to NOT ever change its meaning.
rsalz> 
rsalz> I don't see the point of this.
rsalz> 
rsalz> My goal, with the two flags, was to allow users to make explicit what 
they want, and to warn them that *one* of the cases might/will change in the 
future.

Well, that is what's done in PKCS12_generate_mac(), so this isn't
something that should be done by the application.  What the appication
*must* do when getting '-pass8bit' is to do a naïve UTF-8 encode of
the input pass phrase string.  PKCS12_generate_mac() will then decode
it and zero extend every resulting byte to 16 bits.  If you *don't* do
this, you risk having any byte sequence that looks like UTF-8 in the
original input to be decoded and made into something other than what
the user intended.

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] [openssl-omc] stepping down from OMC

2018-06-11 Thread Salz, Rich
  *   I'm leaving the project.

https://www.youtube.com/watch?v=YtsZoIe3Czk

You have a great deal to be proud of, and OpenSSL is much better for the time 
you spent here.  We will miss you.  I will miss you.

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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-11 Thread Salz, Rich
> If B<-pass8bit> is given, the password is taken to be encoded in the 
current
> locale, but is still used directly.
> A future release might automatically convert the password to valid UTF-8
> encoding if this flag is given.

I would propose that "-pass8bit" means that each byte of the input is
a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll
convert to UCS-2 by prepending 0x00 to each one.  If so, I would expect
this flag to NOT ever change its meaning.

I don't see the point of this.

My goal, with the two flags, was to allow users to make explicit what they 
want, and to warn them that *one* of the cases might/will change in the future.


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