[openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance
Imran.Ali at enghouse.com
Tue Aug 23 07:18:23 UTC 2016
I cannot find any certificate that can use 2.0.12 under Windows Operating System which suggests to me that we will have to revert back to 2.0.10 which is listed under #1747 and use G.5 (user affirmation) to leverage new platforms.
Is there no plans to include Windows platforms for 2.0.12 and newer version?
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: 19 August 2016 14:31
To: openssl-users at openssl.org
Subject: Re: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance
On 08/19/2016 07:20 AM, Imran Ali wrote:
> Hi Guys,
> I need some help. I am looking for some evidence which I can provide
> to my auditor for FOM 2.0.12 is FIPS-140 compliance when compiled and
> used in Windows environment. When I look at the NIST web site under
> I cannot see 2.0.12 version.
> Is there something I am missing?
Yes, it's rather confusing.
The one and only OpenSSL FIPS module ("OpenSSL FIPS Object Module 2.0") is -- for perverse bureaucratic reasons[*] -- covered by three separate[**] FIPS-140 validations:
#1747 (revisions 2.0, 2.0.1, ..., 2.0.10)
#2389 (revisions 2.0.9, ..., 2.0.13)
#2473 (revisions 2.0.9, 2.0.10)
As always the latest revision (for a given validation) subsumes all tested platforms listed for that validation. So for instance, 2.0.13 can be used for all 33 platforms currently listed for validation #2398.
There are about 200 distinct platforms now across all validations.
So you need to look at the listed platforms for all validations[**], and find which of them cover your platform (possibly more than one). Then use the latest revision of the module for that validation.
If you only find your platform(s) of interest on a validation ending at revision 2.0.10 (#1747, #2473), then you're forced to use revision
2.0.10 even though 2.0.13 (and future revisions) are completely backward compatible. From a technical perspective 2.0.N is completely functionally equivalent to all previous revisions < N, but down in the
FIPS-140 rabbit hole you're limited to the latest revision for the relevant validation(s)[***].
The easy way to remember it is "one real-world module, multiple FIPS-land validations". Or as one of my colleagues would put it, "...multiple flavors of FIPS-140 magical pixie dust". The choice of validation certificate number is a paper-chase exercise.
[*] Obscenely perverse, I'm not even going to try and explain it. In fact IMHO no rational explanation is possible.
[**] Technically speaking more than three; validations #2391, #2422, #2454, #2575, #2631, #2676, and possibly others are "copycat" clones done by third parties that introduce yet more platforms. Since these validations are for the same OpenSSL FIPS module they are also accessible to all under the OpenSSL license.
[***] OTOH note the later revisions aren't "better" than the earlier ones in any meaningful sense, as we're not allowed to do feature enhancements or bug-fixes (not even vulnerability mitigations). With most software it's prudent to always use the latest revision to pick up bugfixes and refinements; for the FIPS module it doesn't matter.
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
More information about the openssl-users