[openssl-users] FIPS Certification

[Imran Ali]

Thanks Steve - for the explanation. 

We are using these libraries for Windows 2012 R2 which is 6.3 and  certificate #1747 mentions Windows 7 which is 6.1. I am hoping based on below that we are OK to use it under Windows 2012 R2 

https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx

Regards,
Imran

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: 27 January 2016 16:55
To: openssl-users at openssl.org
Subject: Re: [openssl-users] FIPS Certification

On 01/27/2016 11:34 AM, Imran Ali wrote:
> I might be asking asking a very basic question so do apologies upfront 
> but I need to have  a clear understanding on this.
> 
> The platforms mentioned under #1747 and #2473 does not contain the 
> latest versions of Operating System e.g. Windows 2012 R2 and Windows 
> 10. Does this have any impact on the certification or these libraries 
> can now be used on any OS.

That's actually a rather tricky question.

First off, the one OpenSSL FIPS module (for a significant overlap of
revisions) is covered by three validations; #1747, #2398, and #2473. The set of formally tested platforms (Operational Environments or "OEs") for that module is the union of the platforms listed for each of those three validations.

Roughly speaking, your platform of interest matches one of those "OEs" if:

1) The OS name matches to the first two "dot-rev" levels of the revision number. For instance, "AcmeOS 1.2", "AcmeOS 1.2.3", "AcmeOS 1.2.3.4" are all the same OS.

2) ...and the virtualization environment (ESXi, Hyper-V, Xenserver, etc.), if any, matches to two dot-rev levels.

3) ...and the "processor architecture" is the same. Roughly speaking, that means the binary FIPS module built for the specific OE processor runs as-is on our platform, with the same "code path". So for instance all x86 processors without AES-NI are equivalent to one another, as are all x86 processors with AES-NI.  Ditto ARMv7 with/without NEON.

Lacking such a direct match, you still have "user affirmation" per FIPS
140-2 scripture (section G.5 of the Implementation Guidance document).
That basically says that you as a vendor can "affirm" the use of the FIPS module on your platform of interest assuming you can build it per the mandated process (which in particular means *no* source code tweaks).

As with everything FIPS 140-2, there are no "bright line" rules here.
My usual advice is that you ask your customers what their expectations are. Some customers don't like user affirmation, and some (in DoD for
instance) impose additional requirements. On the other hand, some customers are fine with liberal use of user affirmation.

As a last resort, if you determine that an important customer requires a specific "OE" match (or if source code tweaks are necessary), you can fund addition of your platform(s) of interest to one of the validations.
That is how the list of formally tested platforms has over time grown to more than 120 "OEs", more than any other validated module.

-Steve M.

--
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+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