[openssl-users] Validation status of openssl-fips-2.0.11?
marquess at openssl.com
Sat Feb 13 18:15:29 UTC 2016
On 02/13/2016 04:58 AM, Kyle Hamilton wrote:
> On 2/12/2016 2:03 PM, Steve Marquess wrote:
>> On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
>>> I'm not seeing anything about openssl-fips-2.0.11 in
>>> , so I'm not quite certain what its validation/certificate status is?
>> Ok, this is complex, insanely so.
>> [concise explanation of insanely complex and incredibly messy situation trimmed]
>> Yeah, it's a mess.
> Thank you for explaining it. It feels to me like they're intentionally
> making it as difficult as possible for OpenSSL to maintain its validations.
It does tend to look that way. Whether or not that is the deliberate
intent those obstructions have had the effect of discouraging any new
> #2398 has the correct version that I'm looking for, so that's what I'm
> documenting. However, it also suggests that there's a 2.0.12 that was
> validated as of 02/08/2016? This is not yet distributed on the website.
You've reminded me that we need to upload the 2.0.12 tarball and latest
revisions of the Security Policy docs to openssl.org.
>>> Also, is a new Security Policy in the works integrating the new HMAC
>>> digests for the new versions of -fips and -fips-ecp?
>> I don't understand this question.
> https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf points to
> SecurityPolicy-2.0.9.pdf; this is the version that I got, which did not
> have the new HMAC values for openssl-fips-ecp-2.0.11.tar.gz. I was
> wondering if there was a SecurityPolicy-2.0.11.pdf. It appears there
> is, but the "official" link to 140sp2398.pdf points to a
> SecurityPolicy-2.0.12.pdf. So, I can't quite manage to figure out if
> I'm getting my security policy through a secure path (please see the end
> of this email for more on what I mean, and why I say this).
Well, first of all the Security Policy document doesn't have to come
from a "secure path"; you can download it directly from the NIST CMVP
You can always use the latest version of the Security policy for any
given OpenSSL FIPS module validation; each successive revision always
subsumes all prior revisions. So the 2.0.11 revision of the Security
Policy for validation #2398 is now of historical interest only; use the
current revision which is for 2.0.12 (but which also still covers
2.0.11, 2.0.10, ...). The NIST CMVP web site links to the current
revision of that document for each validation.
>>> (Also, would the mandatory HMAC calculation of the original tarball be
>>> okay if it were done using a FIPS-validated version of Mozilla's NSS?)
>> You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
>> the OpenSSL FIPS user guide
>> (https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
>> question is why we're still snail-mailing CDs (see
> My understanding of this requirement is: A secure path can only be
> established via mail/courier, or via some series of FIPS-validated
> cryptographic modules.
> I suspect the answer depends on whether openssl.org's TLS stack is using
> OpenSSL in FIPS mode.
It doesn't and it won't. I spent many weeks exploring options with the
NIST CMVP at the time (in 2012), with the eventual conclusion that there
was no configuration of open source software for "secure" network file
delivery that would satisfy their rather exacting requirements. For
instance, use of any prior validated version of the OpenSSL FIPS module
(e.g. #1051) for that purpose was specifically rejected.
Long story short, that rabbit hole goes so deep we can't reach the
bottom. The CMVP accepts snail-mailed CDs (regular USPS first class
mail) as "secure", so we go with that as something everyone can
understand and utilize.
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
More information about the openssl-users