> On Jun 1, 2018, at 6:16 PM, Richard Levitte <[email protected]> wrote:
>
> (I'm currently looking into alternatives where a UI_METHOD can present
> several variants of the same pass phrase, thus making it possible for
> the application to virtually say "hey, try one of these" instead of
> "hey, try this one"... that would be a way to have the application
> provide the variants rather than libcrypto, and still only have to
> know the bare minimum of what the URI represents (preferably nothing
> at all))
If they're using a new API with a new store abstraction, I rather
think it'd be better for the PKCS#12 data to be re-built with
a UTF-8 password before it is exposed as a store URI.
They should be able to decode the old file using legacy tooling,
but the new tools should simply require canonical data. Please
DO NOT implement password variants.
--
Viktor.
_______________________________________________
openssl-project mailing list
[email protected]
https://mta.openssl.org/mailman/listinfo/openssl-project
