<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2021-01-25 17:53, Zeke Evans wrote:<br>
<blockquote type="cite"
cite="mid:CY4PR18MB1526D4403A56910E52D95AF2F3BD9@CY4PR18MB1526.namprd18.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Many of the PKCS12 APIs (ie: PKCS12_create,
PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0
when using the fips provider. It looks like that is because
they try to load PKCS12KDF which is not implemented in the
fips provider. These were all working in 1.0.2 with the fips
2.0 module. Will they be supported in 3.0 with fips? If not,
is there a way for applications running in fips approved mode
to support the same functionality and use existing
stores/files that contain PKCS12 objects?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<o:p></o:p>
</div>
</blockquote>
Th<tt>is is an even larger issue: Is OpenSSL 3.x so badly designed <br>
that the "providers" need to separately implement every standard <br>
or non-standard combination of algorithm invocations?<br>
<br>
In a properly abstracted design PKCS12KDF would be implemented by
<br>
invoking general EVP functions for underlying algorithms, which <br>
would in turn invoke the provider versions of those algorithms.<br>
<br>
The only exception would be if FIPS allowed implementing PKCS12KDF
<br>
using an otherwise unapproved algorithm such as SHA1. In that <br>
particular case, it would make sense to check if a provider
offered <br>
such as PKCS12KDF variant before trying (and failing) to run <br>
provider-independent code that invokes the provider implementation
<br>
of a FIPS-unapproved algorithm.<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded</pre>
</body>
</html>