In message <20180602.004350.1602483119932820478.levi...@openssl.org> on Sat, 02 Jun 2018 00:43:50 +0200 (CEST), Richard Levitte <levi...@openssl.org> said:
levitte> 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: levitte> levitte> openssl-users> levitte> openssl-users> levitte> openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte <levi...@openssl.org> 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
