Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
>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
> 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
Re: [openssl-project] [openssl-omc] stepping down from OMC
* 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
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] To use or not use the iconv API, and to use or not use other libraries
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
>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
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
>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
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
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
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
