[openssl-users] Key Deriviation Function Tests for TLS

[Jakob Bohm]

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