In message <7c04edbc-9d70-42ea-9ec9-6e6c4fbb8...@dukhovni.org> on Fri, 1 Jun 2018 18:23:48 -0400, Viktor Dukhovni <openssl-us...@dukhovni.org> said:
openssl-users> openssl-users> openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte <levi...@openssl.org> wrote: openssl-users> > openssl-users> > (I'm currently looking into alternatives where a UI_METHOD can present openssl-users> > several variants of the same pass phrase, thus making it possible for openssl-users> > the application to virtually say "hey, try one of these" instead of openssl-users> > "hey, try this one"... that would be a way to have the application openssl-users> > provide the variants rather than libcrypto, and still only have to openssl-users> > know the bare minimum of what the URI represents (preferably nothing openssl-users> > at all)) openssl-users> openssl-users> If they're using a new API with a new store abstraction, I rather openssl-users> think it'd be better for the PKCS#12 data to be re-built with openssl-users> a UTF-8 password before it is exposed as a store URI. openssl-users> openssl-users> They should be able to decode the old file using legacy tooling, openssl-users> but the new tools should simply require canonical data. Ok, yeah, I can deal with that. In that case, though, it might make sense to extend the UI API with wchar_t capable functionality and require that functionality in the 'file' scheme loader, would it not? The application will then be forced to provide something that can be used directly or is easy to convert to UTF-8, as needed. openssl-users> Please DO NOT implement password variants. Frankly, I'm rather glad not to have to... Cheers, Richard ( g'night ) -- 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
