Dear Steve, Have you considered that their contribution may be of value to the next/future major version of the open source FIPS module (which would presumably involve a fresh submission under updated FIPS validation rules). This would obviously be a different code branch from maintenance/change letter updates to the current module. On 28/09/2015 16:17, Steve Marquess wrote: > On 09/28/2015 09:13 AM, John Foley wrote: >> On 09/23/2015 08:16 AM, Steve Marquess wrote: >>> John, let me elaborate on my comment above by noting that the Cisco >>> contribution includes a bunch of FIPS specific code for which there is >>> no counterpart on the master branch (i.e. no place to put it). A >>> version which worked on master with all the FIPS stuff stripped out >>> and with tests via evp_test would be a lot more interesting. -Steve M. >> Hi Steve, >> >> We can certainly submit a pull request on the master branch. It'll take >> a little time to prepare that. IMHO, there is value in accepting this >> pull request on the FIPS branch as well. There are OpenSSL users doing >> private label FIPS validations that would benefit. > Sure, value for the very small number of vendors with pockets deep > enough to pursue their own proprietary validations that will benefit no > one else. > > We're an open source organization with limited resources. We want to > apply those resources effectively to benefit the greater community. Even > though FIPS 140-2 is of significant interest to only part of the U.S. > market, and of minimal interest to the rest of the world, the open > source based validations see enough use[*] to justify the significant > effort those consume. We can't justify that impact for a handful of U.S. > vendors. > > Then there is the issue of code "ownership". We have dropped code for > platforms we can't access and test ourselves. The real "test" for FIPS > related code is whether the validation bureaucracy will approve it, and > we know from long experience that we can't assume said approval; the > "interop" test is a validation certificate. If we accept outside > contributions of FIPS related code we'll have no way of knowing if that > code will actually satisfy any particular attempt at validation. Your > response to that will be that you'll only give us code that *you* have > successfully validated, in a module that only you can use, but again we > know from long experience that the exact same module can be submitted > multiple times with very different results. Your successful private > closed source validation is of minimal use to anyone else. > > An open source based validation, that everyone can use either directly > or as the basis for copycat "private label" validations, is the correct > answer. I see no benefit to us or the vast majority of our user base in > committing speculative code that we can't verify and that most of our > users can't use. > >> Pull request 368 >> contains the FIPS vector processing utility for KDF. None of the FIPS >> vector processing utilities reside in master. The pull request we >> prepare for master isn't going to include the KDF vector processing utility. >> >> Please let me know whether we should proceed with preparing a pull >> request on master. > If it doesn't have any FIPS dependencies and is useful for the overall > OpenSSL community outside of any FIPS context, sure. > > Thanks, > > -Steve M. > > [*] Many hundreds of vendors, most but not all small companies you never > heard of. Those are the ones who use the #1747 validation directly, > still more do copycat validations. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
