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. #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. >> 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). >> (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. As a result, I cannot use any non-validated openssl to bootstrap to a validated openssl-fips, because the chain of FIPS-validated cryptographic verification must not be broken. If I have another FIPS-validated module which is validated for SHA1-HMAC, I can use it in accordance with its security policy to perform the HMAC verification. If I already have a FIPS-validated openssl, I can use it. Otherwise, I must obtain the CD from OpenSSL Foundation (most likely via registered mail -- not even certified mail, but registered mail). There do exist other FIPS-validated modules, like the FIPS-validated NSS: I've already set all of the cryptography in my Firefox installation to be through the NSS FIPS module (using cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2 -- compliant with the FIPS TLS implementation guidance). Since I'm using a FIPS-validated NSS to perform the cryptography to download from https://openssl.org/source/openssl-fips-ecp-2.0.11.tar.gz, would that pass the "secure path" challenge, or would I still need to write something to perform the HMAC test specified in Appendix B of the Security Policy using the NSS FIPS module? I suspect the answer depends on whether openssl.org's TLS stack is using OpenSSL in FIPS mode. Because I do not know if it is (and the site itself does not mention it), I think I should assume that the TLS stack of openssl.org does NOT operate in FIPS mode, and thus I shouldn't rely on it as being part of the necessary trusted path. Because of this, I think I should assume that HMAC verification in accordance with Appendix B is still compelled. I hope that this insight might be helpful, though. -Kyle H
