I'm getting private queries about the status of the OpenSSL FIPS Object Module v2.0 (the "OpenSSL FIPS module") which I'll answer here for everyone. As always, if you don't know or care what I'm talking about then run for high ground lest you trip and fall down the rabbit hole... The OpenSSL FIPS module is (very confusingly) covered by three nominally separate validations, #1747, #2398, #2473. It used to be that validations lived forever. Recently the CMVP has introduced two policy changes that can kill extant validations (see http://csrc.nist.gov/groups/STM/cmvp/notices.html, under headings "validation sunsetting policy" and "X9.31 RNG transition". One is expiration of validations that haven't been updated in five years, beginning in 2017; not a factor for any validation yet and moot for the OpenSSL FIPS module validations for a few years still (as those tend to be updated frequently). The other is the "RNG transition" of a large class of validations, including all the OpenSSL and OpenSSL derived ones, that will kill (has killed) validations not updated by a week ago. Those deceased validations can be found at: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm Note there are a lot of them, including the older OpenSSL open source based validations (#1051 and prior). What about the current OpenSSL FIPS module, which is validation(s) #1747/#2398/#2473? Well, the paperwork for updating those three validations (said update consisting of wordsmithing only, no software changes) was submitted at the same time. But, as so frequently happens those very similar submissions encountered different receptions. Two of the submissions have been approved, for #1747 and #2473. The one for #2398 is still pending. The CMVP has left that validation in the active validation list, with the notation "This module is in process for the RNG transition.". So the #2398 validation is in limbo at present, waiting for CMVP action. Since the OpenSSL FIPS module is represented by all three validations, it is in a limbo of sorts too. The practical effect is probably minimal, though, as there is no reason to expect the CMVP won't eventually approve the third submission. That validation has a lot of company in limbo status, too. That's short term. There are implications for the long term too. Note that the five year expiration will for all practical purposes impose an upper limit on the usable lifespan of any current or future open source based validations (such as #1051, #1747, etc.). That is because those collaborative validations are only possible with support from multiple separate sponsors (several dozen so far for the #1747/#2398/#2473 module). That collaborative support results in many platforms ("OE"s) for the one shared validation(s); over 120 platforms for the latest module. That collaborative support makes these validations economically feasible (barely...) and also makes the collaborative validations valuable to a very wide range of end users. However, the concentration of so many platforms for one validation makes that validation(s) very vulnerable to forced changes (as will be required to avoid the five year termination). Any forced change that requires retesting of all the platforms is economically infeasible (I estimate retesting of the 120+ platforms for the #1747+ validation(s) would cost over $800K even if we could spare the time and manpower, which we can't). Note such a forced change impact has effectively happened already, in 2015[1], with a financially ruinous outcome for the OpenSSL FIPS business. What vendors can do, and are doing, is obtaining separate "clone" ("Alternative Scenario 1A/1B") or "private label" ("5SUB") validations based on the OpenSSL FIPS module. That works well for those specific vendors, as long as they have an open source based module to copy from, but those copycat validations don't do the rest of the OpenSSL user community any good and don't contribute to the support of the open source based validations. Without sharing costs among many sponsors the open source validations aren't possible. So the collaborative open source based FIPS validation model that brought us five successive OpenSSL FIPS modules, culminating in the #1747/#2398/#2473 validation, is dead[2]. If there's any viable opportunity to pursue a new validation I haven't seen it yet. -Steve M. [1] Tediously documented in the "hostage/ransom/aftermath" trilogy at http://openssl.com/fips/ [2] See https://openssl.org/blog/blog/2015/09/29/fips/ -- 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
