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

[Richard Levitte]

In message <7C04EDBC-9D70-42EA-9EC9-6E6C4FBB8322 at dukhovni.org> on Fri, 1 Jun 2018 18:23:48 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> 
openssl-users> 
openssl-users> > On Jun 1, 2018, at 6:16 PM, Richard Levitte <levitte at 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/