[Info-vax] VSI has released 9.2-1

Wed Jul 5 16:33:10 EDT 2023

On 7/5/2023 2:23 PM, Simon Clubley wrote:
> On 2023-07-04, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> But it is all very generic and it does not require and special
>> HW or OS functionality. Traditional SYS$GETJPIW seems fine
>> (assuming all the documentation and test is done, but that is
>> also a requirement for HW or OS provided functionality).
> 
> At this point Arne, I don't know if you are trolling or if you really
> believe that because your use of highly-abstracted languages and
> associated APIs means you have lost touch with how those highly-abstracted
> languages and APIs are implemented.

I don't think my preference for programming languages are particular
relevant for whether your claims of:

#                                                        VMS systems
# _WILL_ be dropped in many areas if they are regarded as no longer being
# secure by today's standards.

# To put this another way, the previous solutions for generating entropy
# within user mode that I am aware of were not suitable by today's 
standards.

are correct or not.

> Every single OS vendor I am aware of, including now VSI, implements
> this stuff using a kernel module to supply the required level of quality
> to user programs.
> 
> No vendor I am aware of, including even Microsoft, does entropy generation
> for security purposes in purely user mode.

Using HW/OS is definitely what is being done for new OS versions.

But there is a difference from that and the old way not being
acceptable.

> Question: If SYS$GETJPIW was good enough, why didn't VSI just use that
> instead of going straight to designing and implementing an entropy engine,
> with all the work that involves ?

The question was not whether using HW/OS is good. I think everybody
agrees it is.

The question was whether not using HW/OS would cost VMS sales now
due to being not compliant.

It is hardly surprising that VSI is implementing new functionality
looking forward instead of backwards.

> They have not implemented many things that have been asked for due to
> resource limitations, but they have spent time implementing this because
> they clearly consider it to be vital.
> 
>  From https://docs.vmssoftware.com/docs/VSI_Webinar_March_2022.pdf in the
> OpenSSL section:
> 
> |Working on new entropy engine that will work with OpenSSL 3.0 to help
> |facilitate FIPS 140-x compliance
> 
> |SSL3 is also a key component of VSI's security roadmap to ensure that the
> |OpenVMS operating system and applications running on OpenVMS are able meet
> |relevant security requirements by supporting specific features such as FIPS.

That is actually interesting.

Per:

https://www.openssl.org/docs/fips.html
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282

then OpenSSL is FIPS 140-2 certified on:

<quote>
     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) 
without PAA
     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) 
without PAA
     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) 
without PAA
     macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
     macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA 
(single-user mode)
     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel 
i7(x64) with PAA
     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel 
i7(x64) without PAA
     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without PAA
</quote>

Maybe VSI want VMS on that list.

But that list is not the server market.

>> The relevant parts are actually quite easy to follow.
>>
>> They just don't say that current VMS methodology is unacceptable.
>>
> 
> Standards generally don't say that using "1234" as a combination or
> "password" as a password are unacceptable either. They instead focus
> on explaining _what_ is acceptable.

Yes.

But old practices seems to match the description of what is acceptable.

I actually copied the text in. You just omitted it when replying.

>> But this was about your claim that VMS could be dropped because
>> it was considered not secure by todays standards.
>>
>> #                                                        VMS systems
>> # _WILL_ be dropped in many areas if they are regarded as no longer being
>> # secure by today's standards.
>>
>> # To put this another way, the previous solutions for generating entropy
>> # within user mode that I am aware of were not suitable by today's
>> standards.
>>
>> I want to know where those standards are.
>>
>> It is certainly not the NIST 800-90A/B/C quoted above.
> 
> Are you sure about that ?

I quoted the text. You tell me what lines old OpenSSL does not match.

>> It is certainly not that Redhat article.
>>
>> Did you just make it up????
>>
> 
> VSI consider certifying VMS against FIPS to be important and they consider
> a kernel-based entropy engine to be a vital part of that. Are you saying
> VSI are wrong ?

If VSI believe they need FIPS certification and that they need the new
better entropy to get that, then it all makes sense.

But if you check the list above then FIPS certification does not
seem to be a requirements to sell servers today.

Among other things then Redhat Linux is not on the list.

(even though I believe they are in the process of getting certified)

Arne