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

[Richard Levitte]

In message <20180602.004350.1602483119932820478.levitte at openssl.org> on Sat, 02 Jun 2018 00:43:50 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

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