Re: [openssl-users] Validation status of openssl-fips-2.0.11?
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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Validation status of openssl-fips-2.0.11?
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 marqu...@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
[openssl-users] pkcs12 oddity
hi list, we just ran into an "openssl pkcs12" oddity with various versions of openssl (e.g. 1.0.1e from Fedora): $ cat usercert.pem userkey.pem | openssl pkcs12 -export -out blah.p12 Enter pass phrase: unable to load certificates i.e. fails, but this works: $ cat userkey.pem usercert.pem | openssl pkcs12 -export -out blah.p12 Enter pass phrase: Enter Export Password: Verifying - Enter Export Password: this works: it seems the private key must always be listed first! However, the man page for pkcs12 states: -in filename The filename to read certificates and private keys from, standard input by default. They must all be in PEM format. The order doesn't matter but one private key and its corresponding certificate should be present. If additional certificates are present they will also be included in the PKCS#12 file. so, what am I doing wrong here? (the command listed above is not the actual command we want to use, but it does bring out the problem very nicely) thanks for any help and pointers, JJK / Jan Just Keijser -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
