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 >>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 >>> , 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 validation attempts. > > #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 web site. 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 >> http://openssl.com/fips/verify.html). > > 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. Kinda-sorta... > ... > 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. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 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
