On 1/16/16, 09:52, "openssl-dev on behalf of Douglas E Engert" <openssl-dev-boun...@openssl.org on behalf of deeng...@gmail.com> wrote:
>Yes, #548 is similar but for the pkeyutl.c > >I would have changed: > >{"keyform", OPT_KEYFORM, 'F', "Private key format - default PEM"}, >to >{"keyform", OPT_KEYFORM, 'f', "Private key format - default PEM"}, Will do, thanks. >The patch also adds an additional parameter, >{"engine_impl", OPT_ENGINE_IMPL, '-', "Also use engine given by -engine >for crypto operations"}, > >I would ask the author about the engine_impl . I’m not sure I understand. I’m the author of this addition (including addition of “-engine_impl” option, which was added exclusively to make sure the previous/original behavior is available if somebody would want it), and it’s made upon suggestion by Steve Henson. Or do you mean the author of the original pkeyutl.c? He can’t know anything about the flag I’m adding. Also note that this patch is a copy (as close as the difference in the source base allowed) of the one accepted for OpenSSL_1_0_2-stable. >It looks to me that to keep the previous behavior of the command >one would need to add this option if an engine is used. IMHO it (the previous behavior) could never work with real keys on a real hardware token the way it was written (perhaps it could work with other kinds of engines). As always, I’d be happy to learn any evidence to the contrary. :-) And I’ve accumulated plenty of experience using OpenSSL with a few different PIV tokens (PKCS11-accessible via OpenSC). So far I’ve done plenty of RSA signing/verifying and encrypting/decrypting, and ECDSA signing. ECDH derivation works only when the public key is on the token - because engine_pkcs11 doesn’t support ec_derive yet. >IIt could also be an issue with the ordering >of the parameters, or to try and not use the engine when the public key >is used. >(I could be wrong on this.) Yes, parameter ordering is strict at the moment. I don’t want to mess with the code too much to make the it work regardless of the parameter order. For right now I’d be happy if the mainstream code would just work - and this patch accomplishes exactly that. >The author is also active on the OpenSC list trying to use EC with the >OpenSC engine. Are we talking about Michael? BTW, on a separate issue - I’m rather concerned about the apparent circular dependency between OpenSSL and OpenSC. This makes it problematic to use OpenSC with another software library like Botan or Crypto++. But that’s for a different message thread. >On 1/15/2016 5:24 PM, Blumenthal, Uri - 0553 - MITLL via RT wrote: >> Doug, could you please take a look at PR #548 (or is it #549)? It also >>addresses this KEY_FORM issue. >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>network. >> Original Message >> From:deeng...@gmail.com via RT >> Sent: Friday, January 15, 2016 17:10 >> Reply To:r...@openssl.org >> Cc:openssl-dev@openssl.org >> Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl >>req fails to use engine >> >> req.c (and many of the other apps) appear to have lost the ability to >>use an engine. >> The attached diff is against the github.com verison using Tag >>OpenSSL_1_1-pre2 >> In the req_options[] table: >> OPT_KEY is set to "S" so pre- checking of the parameters does not drop >>the string passed to the engine. >> OPT_KEY_FORM is set to "f" so pre-checking will allow engine >> >> The engine is saved: >> e = setup_engine(opt_arg(), 1); >> >> (I turned on debug, may want that off. ) >> >> to allow the theOPT_KEY_FORM to be an engine: >> if (!opt_format(opt_arg(), OPT_FMT_PEMDER|OPT_FMT_ENGINE, &keyform)) >> >> This was tested with a modified version of OpenSC using ECDSA key on >>card to generate a self signed certificate. >> >> openssl req -config /tmp/genreq.6156.openssl.conf -engine pkcs11 >>-keyform e -sha256 -new -key slot_1-id_2 -out /tmp/selfsigned.pem -x509 >>-text >> >> >> P.S. The EC_KEY_* functions appear to be working too (#4225) Have not >>tried the ECDH yet. >> >> -- Douglas E. Engert<deeng...@gmail.com> >> >> >> >> > >-- > > Douglas E. Engert<deeng...@gmail.com> > > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev