Mark Phalan wrote:
...
> As you noted the incorporation of fipscanister.o in a FIPS capable
> OpenSSL displaces the corresponding FIPS allowed algorithms of the
> latter. While we retain functional equivalence (goal 1 above) any
> platform optimizations or other improvements of the newer
> implementations are lost. The nature of this interface is such
> that we can't easily avoid this displacement within the constraints
> of the existing fipscanister.o interface and 0.9.8 versioning
> rules.
Do you think delivering two versions of libcrypto in this case is a
reasonable workaround?
It's the simplest solution in your case, even though it's the outcome
our design hoped to avoid.
> I should also note that developments in FIPS 140-2 testing
> requirements for 2010 mean that even the existing v1.2 module will
> no longer be compliant. The commercial vendors who have been
> obtaining "private label" validations based on v1.2 will find that
> those validations will no longer be rubber stamp formalities as is
> the case today.
Can you point me to more information about this? Does this mean that
delivering a FIPS Capable OpenSSL (v1.2) as part of an OS will be
essentially worthless to users of that OS in 2010?
Well, I have a mixed track record in forecasting future CMVP actions so
take my speculations accordingly.
The CMVP typically does not revoke or invalidate extant validations
simply because the criteria for new validations have changed (though I
should note past OpenSSL FIPS Object Module validations have been
effectively revoked). So presumably the current #1051 validation will
remain in effect through 2010 for those electing to use it directly.
Emphasis on presumably, as the OpenSSL open source based validations are
*not* typical. So assuming you base your deliverables on already
awarded validated products you *should* be OK.
However, it has been common practice for vendors to take the same v1.2
source code and documentation and obtain their own copy-cat or "private
label" validation. There are a number of practical and marketing
reasons why such duplicate validations are desirable (minimizing the
risk of exposure to the fate of validations #642 and #733 being first
and foremost). Those copy-cat validations will no longer be possible
with the as-is v1.2 source.
At one point in time we thought that we would have, though sponsorships
brokered by the Open Source Software Institute, long term funding for an
ongoing series of periodic (annual or semi-annual) "rolling"
validations. That would have maintained availability of a reasonably
current product for direct use or as a model for private label use, and
would also have allowed us to work in the desired architectural changes
over several validations. Unfortunately that prospect fell through and
at this point we have no plans for any future validations.
Private label validations will continue but will require increasing
amounts of modification to the v1.2 source code and documentation as the
validation requirements are extended. We could merge those changes back
into the shared baseline code and docs, but to date we have received
very few contributions of that sort. So what is currently a community
resource will gradually revert back to a roll-your-own situation, same
as it was before the first open source based validation.
-Steve M.
--
Steve Marquess
The OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877-673-6775
marqu...@opensslfoundation.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
