[Info-vax] New OpenSSL update from HP

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-15 00:22:00 +0000, RobertsonEricW said:
> 
>> On Sunday, June 14, 2015 at 7:47:10 PM UTC-4, Stephen Hoffman wrote:
>>> Then there's that more than a few folks don't really understand how 
>>> certificates and DH and the rest work, and there's absolutely no 
>>> integration with OpenVMS at present -- there are four different 
>>> certificate stores commonly encountered, if not more.  (CDSA, 
>>> OpenSSL, ssh and sshd, Apache, and probably some others.)
>>
>> Yes. This multiplication of certificate stores needs to start being 
>> constrained. This so that the maintenance of the software that  uses, 
>> stores, or originates certificates is simplified amongst all of the 
>> various software that routinely perform these certificate operations.
> 
> That, and to protect and manage the certificates.  And to be integrated 
> and much more transparently available throughout OpenVMS, preferably.
> 
>> As you point out this particular problem is not OpenVMS specific. 
>> Though, outside of OpenVMS, I am not aware of any other software of 
>> recent vintage that uses CDSA for certificate processing, storage or 
>> origination.
> 
> CDSA was effectively abandoned a ~decade ago AFAICT.
> 
>> So, at some point in the future of OpenVMS, CDSA will likely need to 
>> be deprecated to consolidate the state of software on OpenVMS as well 
>> as the software originated from the Open Source quarters.
> 
> CDSA is already toast, AFAICT.  The question becomes when it gets 
> deprecated and retired and replaced, and by what.  Which then leads to 
> when the existing dependencies on CDSA in the customer and third-party 
> code and within OpenVMS itself — with PCSI and VMSINSTAL amongst those, 
> for the CDSA-based kit signatures — are resolved and reworked.   This 
> also ties back to my earlier comments around the fundamental 
> incompatibility of upward compatibility while also making (some) 
> (somewhat expeditious) forward progress with security and substantial 
> new features.  You cannot and should not disrupt APIs and interfaces 
> arbitrarily or capriciously, but you can and will need to make some 
> (incompatible) changes.  Or you're stuck supporting and enhancing and 
> documenting a decade-outdated and dead-end framework that likely doesn't 
> really do all of what you really want, and that likely doesn't deal with 
> current standards and expectations.
> 
> 

Is that a bit like the guy that would not look at a problem with modems, 
because he didn't have a modem, or thought nobody still used modems?

:-)