<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font color="#ff0000">Answers below....<br>
</font><br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div><span class="gmail-ui-provider gmail-brj gmail-brk gmail-c
gmail-d gmail-e gmail-f gmail-g gmail-h gmail-i gmail-j
gmail-k gmail-l gmail-m gmail-n gmail-o gmail-p gmail-q
gmail-r gmail-s gmail-t gmail-brl gmail-brm gmail-w gmail-x
gmail-y gmail-z gmail-ab gmail-ac gmail-ae gmail-af gmail-ag
gmail-ah gmail-ai gmail-aj gmail-ak" dir="ltr">1) Is there a
way to static link FIPS? I see at many places that fips
cannot be statically linked but would like to know if we
have any other ways to do that.</span></div>
</div>
</blockquote>
<br>
<font color="#ff0000">No. This was a design goal/limitation from
the start. Statically linking the FIPS provider would have been a
major source of pain. We managed it for 1.0.2 with some
inspirational assembly coding but that approach wouldn't have
worked for 3.0.</font><br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div><span class="gmail-ui-provider gmail-brj gmail-brk gmail-c
gmail-d gmail-e gmail-f gmail-g gmail-h gmail-i gmail-j
gmail-k gmail-l gmail-m gmail-n gmail-o gmail-p gmail-q
gmail-r gmail-s gmail-t gmail-brl gmail-brm gmail-w gmail-x
gmail-y gmail-z gmail-ab gmail-ac gmail-ae gmail-af gmail-ag
gmail-ah gmail-ai gmail-aj gmail-ak" dir="ltr">2) If it is
dynamic linking then does FIPS has any integrity check to
make sure <a href="http://fips.so/fips.dll"
moz-do-not-send="true">fips.so/fips.dll</a> is the right
one? </span>and not some thing tampered by some body(as per
my findings we have some check in configuration file as
mentioned in the below attached snapshot 3rd line)</div>
</div>
</blockquote>
<br>
<font color="#ff0000">Yes it does do an integrity check on load.
This was the main reason to limit the FIPS provider to being a
loadable module. The approach taken in the 1.0.2 FOM wasn't
viable with the re-architecture.</font><br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div>3) can both legacy and fips providers be loaded and used?
<br>
</div>
</div>
</blockquote>
<br>
<font color="#ff0000">Technically yes, but you'll not be FIPS
compliant unless you are <b>extremely</b> careful.<br>
Which means talking to your FIPS labs and getting official
resolutions on the specifics.<br>
The OpenSSL developers are **<b>not</b>** FIPS experts. Only a
FIPS lab can definitively answer questions like this.<br>
</font><br>
<br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div>
<div>4) Is it possible If i have built openssl with no-module
configure option (to statically link legacy provider) and
also wanted to use openssl-3.0.8 built fips module here? If
yes then in what way can it be done?</div>
</div>
</div>
</blockquote>
<br>
<font color="#ff0000">Honestly not sure here. You <b>must</b> load
the FIPS provider dynamically to be compliant.<br>
If that's possible with the <font face="monospace">no-module</font>
option, you should be okay. I suspect it isn't. Try it and see.<br>
<br>
If you don't get a definitive result, this means talking to your
FIPS labs and getting official resolutions on the specifics.<br>
The OpenSSL developers are **<b>not</b>** FIPS experts. </font><font
color="#ff0000"><font color="#ff0000">Only a FIPS lab can
definitively answer questions like this.<br>
</font>
</font><br>
<br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div>
<div>5) Is it possible to load multiple providers like
default, leacy and also fips programmatically using <span
style="font-family:Menlo,Monaco,"Andale
Mono","lucida console","Courier
New",monospace;font-style:inherit;font-variant-ligatures:inherit;font-variant-caps:inherit;font-weight:inherit;background-color:rgb(0,43,54);color:rgb(0,255,0);font-size:13px">OSSL_PROVIDER_load</span> function
?<br>
</div>
</div>
</div>
</blockquote>
<br>
<font color="#ff0000">Absolutely it is possible. However, meeting
FIPS requirements afterwards could be problematic.<br>
This means talking to your FIPS labs and getting official
resolutions on the specifics.</font><br>
<font color="#ff0000"><font color="#ff0000">
The OpenSSL developers are **<b>not</b>** FIPS experts. </font><font
color="#ff0000"><font color="#ff0000">Only a FIPS lab can
definitively answer questions like this.<br>
<br>
Having several library contexts with each having different
providers loaded might be a way to circumvent the strict
interpretation of the requirements. </font></font></font><font
color="#ff0000">This means talking to your FIPS labs and getting
official resolutions on the specifics.</font><br>
<font color="#ff0000"><font color="#ff0000">
The OpenSSL developers are **<b>not</b>** FIPS experts. </font><font
color="#ff0000"><font color="#ff0000">Only a FIPS lab can
definitively answer questions like this.</font></font></font><br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKn5YzyFA-OTsg3MrtqsSO9QBMSb8F2n30+H+6epGKLB4AQt5w@mail.gmail.com">
<div dir="ltr">
<div>
<div>6) When multiple providers like for ex: FIPS and default
provider are enabled and when an encryption function is
called, then algorithm from which provider is picked(from my
findings it can use any of the loaded provider
implementations )? assumption that we have <b>not</b> used
property query string during algorithm fetches to specify
which implementation to be used.<br>
</div>
</div>
</div>
</blockquote>
<br>
<font color="#ff0000">The OpenSSL project <b>deliberately</b> makes
<b>no guarantee</b> about which provider is used in such cases.
It is deterministic currently, but there is no guarantee that
we'll not change the order of resolution or making it randomly
non-deterministic in any future releases. Honestly, expect that <b>we
will</b> make changes to the resolution order in the future.
Such a change is not considered breaking and doesn't have to
adhere to our stable release policy.<br>
<br>
Our best recommendation is to not mix providers in library
contexts. Seek resolution from you FIPS lab.<br>
<br>
<br>
Dr Paul Dale</font><br>
<br>
</body>
</html>