<div dir="ltr">Dear Francesco,<div><br></div><div>I think this link is relevant:</div><div><a href="https://github.com/OpenSC/libp11/blob/master/src/eng_front.c">https://github.com/OpenSC/libp11/blob/master/src/eng_front.c</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 24, 2020 at 1:45 PM Francesco Pretto <<a href="mailto:ceztko@gmail.com">ceztko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dmitry,<br>
<br>
thank you for the prompt answer. Are you able to provide me with a<br>
link to an example of creating such engines that will fit this use<br>
case? On my searches I was able to find staff like EVP_PKEY_METHOD[1]<br>
but I wasn't able to use them for my purpose. Not assuming how stuff<br>
works today, ideally for me such engine should work like this:<br>
- I prepare an engine that is able to deal with private keys only, and<br>
just for encryption;<br>
- I create a fake EVP_PKEY* that will use this engine;<br>
- I supply this private key to CMS_add1_signer(), together with the<br>
usual/regular X509 certificate, parsed for example from DER/PEM.<br>
<br>
Even if CMS_add1_signer()[2] is currently performing a validation of<br>
the EVP_PKEY passed, it shouldn't be hard to patch to avoid doing such<br>
a check, for example by supplying a newly created flag that specifies<br>
to not do it.<br>
<br>
If engines can't be operated this way, then I'm afraid they will still<br>
require more boilerplate code than really necessary.<br>
<br>
Cheers,<br>
Francesco<br>
<br>
[1] <a href="https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_METHOD.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_METHOD.html</a><br>
[2] <a href="https://github.com/openssl/openssl/blob/d1fb6b481b1d70932a1435f83eae10cc68edbe36/crypto/cms/cms_sd.c#L269" rel="noreferrer" target="_blank">https://github.com/openssl/openssl/blob/d1fb6b481b1d70932a1435f83eae10cc68edbe36/crypto/cms/cms_sd.c#L269</a><br>
<br>
<br>
On Sat, 24 Oct 2020 at 12:12, Dmitry Belyavsky <<a href="mailto:beldmit@gmail.com" target="_blank">beldmit@gmail.com</a>> wrote:<br>
><br>
> Dear Francesco,<br>
><br>
> On Sat, Oct 24, 2020 at 1:06 PM Francesco Pretto <<a href="mailto:ceztko@gmail.com" target="_blank">ceztko@gmail.com</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> I'm trying to create a CMS context for subsequent export using<br>
>> CMS_sign(). I add a signer using CMS_add1_signer() that allows me to<br>
>> specify a X509 certificate and a hash function. I would like the CMS<br>
>> context to perform hash computation and ANS1 structure filling, but I<br>
>> want to delegate encryption to an external service, for example an<br>
>> hardware encryption token (I'm assuming this is a very common use<br>
>> case). At this point I'm in a stalemate since CMS_add1_signer() asks<br>
>> me for a private EVP_PKEY that is compatible with the public key<br>
>> present in the X509 certificate. No other function seems to exist to<br>
>> create a CMS_SignerInfo by providing an external mechanism for<br>
>> encryption.<br>
>><br>
>> My hacky solution was to add a signer CMS_add1_signer() supplying the<br>
>> public key stored in the X509 certificate in the place of the private<br>
>> one. This passes internal checks of the function and allows me to<br>
>> subsequently handle (manually) all the ANS1 structure filling and hash<br>
>> computations. This is barely doable with public openssl API and still<br>
>> requires a big rip-off of private openssl code (attached as a<br>
>> standalone C++ class, if it can be useful for someone).<br>
>><br>
>> My question is: is there an easier mechanism to plug a separate<br>
>> encryption method when creating the CMS_SignerInfo structure and have<br>
>> openssl do all the other dirty work for me? If so, is it possible to<br>
>> do with openssl 1.1.0/1.1.1?<br>
><br>
><br>
> Engines allow operating by private keys in such a manner.<br>
> You have to reimplement all the callbacks dealing with private keys. Also, it's possible you have to write some wrappers for the functions dealing with public keys.<br>
><br>
> For 3.0, the providers should do the same trick, I think.<br>
><br>
> --<br>
> SY, Dmitry Belyavsky<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div>