Re: OpenSSL 3.0 and FIPS Update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+1 on the point: firm expiration date without firm replacement date ... really?!

We have to hope that the firm expiration date will actually move if the replacement isn't ready before then ... and that doesn't begin to account for the calendar time to get the new one certified....

Thanks,
Mark Ludwig

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Jakob Bohm via openssl-users
Sent: Thursday, February 14, 2019 10:34 AM
To: openssl-users@xxxxxxxxxxx
Subject: Re:  OpenSSL 3.0 and FIPS Update

On 13/02/2019 20:12, Matt Caswell wrote:
>
> On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote:
>> On 13/02/2019 12:26, Matt Caswell wrote:
>>> Please see my blog post for an OpenSSL 3.0 and FIPS Update:
>>>
>>> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
>>>
>>> Matt
>> Given this announcement, a few questions arise:
>>
>> - How will a FIPS provider in the main tarball ensure compliance
>>   with the strict code delivery and non-change requirements of the
>>   CMVP (what was previously satisfied by distributing physical
>>   copies of the FIPS canister source code, and sites compiling this
>>   in a highly controlled environment to produce a golden canister)?
> My understanding is that physical distribution is no longer a requirement.
And the other things in that question?

Integrity of validated source code when other parts of the tarball
get regular changes?

Building the validated source code in a controlled environment
separate from the full tarball?

(If there are answers in the FIPS 3.0.0 draft spec, they need repeating).

>> - Will there be a reasonable transition period where users of the
>>   old FIPS-validated module can transition to the new module (meaning
>>   that both modules are validated and usable with a supported
>>   FIPS-capable OpenSSL library)?  I imagine that applications relying
>>   on the existing FIPS canister will need some time to quality test
>>   their code with all the API changes from OpenSSL 1.0.x to OpenSSL
>>   3.0.x .  OS distributions will also need some time to roll out the
>>   resulting feature updates to end users.
> The old FIPS module will remain validated for some time to come, so both the old
> and new modules will be validated at the same time for a while. 1.0.2 will go
> EOL at the end of this year. The intention is that 3.0 will be available before
> that. It's not yet clear exactly when 3.0 will become available and what the
> overlap with 1.0.2 will be so I don't have an answer at this stage for
> transition period.
>
> Matt
>
So right now, FIPS-validated users are left hanging, with no date to
get a 3.0.0 code drop to start porting and a looming deadline for the
1.0.x API.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux