PowerShell PKI Module v3.4.2 and upcoming plans

I’m glad to announce that a new version of PowerShell PKI (PSPKI) module is released. It is available for installation from PowerShell Gallery: https://www.powershellgallery.com/packages/PSPKI/

PSPKI was in stable development for last year and most changes are bug fixes and usability improvements. Release notes for v3.4.2: https://dev-pki-solutions-old.pantheonsite.io//tools/release-notes-for-pspki-v342/.

However, it doesn’t mean that the module is done or dead. Oppositely, there is a lot of work to do! At PKI Solutions I received more time on open source tool development. In regards to PSPKI module there are two major development paths I’m going to work on:

1. Online Responder management cmdlet development
2. Underlying API library move towards .NET Standard/.NET Core

Online Responder management cmdlets

Online Responder (OCSP server) management cmdlet development was planned years ago and the lack of time didn’t allow me to progress in it. Now, I can get to desk board and draw cmdlet design.

Move to .NET Standard/.NET Core

This is another priority direction I’m moving to. PSPKI heavily relies on a set of libraries I developed in C# to support module functionality. Unfortunately, many parts of libraries were written in a really poor way with a lot of bad choices, decisions, naming conventions and other mess. This makes API library unusable in .NET Core projects.

Years ago I moved ASN.1 parser to separate DLL and now it is fully cross-platform and compatible with .NET Standard. Need to finish few things before I will be able to push it to NuGet. About a year ago, I continued API library decomposition in parts. Most hand-written managed implementations of cryptographic objects and operations are subject for decomposition and move to .NET Standard code base. This decomposition is done in separate branch: SysadminsLV.PKI.Cryptography project. This project will contain platform independent cryptography objects, primitives and operations. OCSP client functionality will go to separate pluggable project. I see it a “PKI Extensions for .NET” project that will find its niche. I’m not going to compete with .NET or BouncyCastle, the intention of my work is to EXTEND them by providing valuable cryptographic functionality.

.NET Standard branch will be in development state (won’t be officially released) and will be developed in parallel with old library until I can extract all cryptography primitives and operations from old library.

Eventually, I see the usage of libraries as follows:

ASN.1 parser (.NET Core) will be on top of all. PKI.dll (new “PKI Extensions for .NET” built on .NET Core) depends on ASN.1 parser. The rest isolated libraries like new OCSP client API set (.NET Core), legacy PKI library (.NET Framework) and whatever else will depend on new PKI library. This is my current vision of how it should look like and is the direction I’m working in. Since it is going to be a new project, I’m not concerning about compatibility with older API. If you have any suggestions, recommendations, ideas, please file them on GitHub: https://github.com/PKISolutions/pkix.net/issues

Move to PowerShell Core

PowerShell Core is meant to be a platform-independent PS engine and like .NET Core, this is top priority direction in PS development. There are significant changes between PS5 (Windows-only) and PS6 (Core) and thus are not interchangeable. Certain code parts worked in PS5 won’t work in PS6 and code working in PS6 may not run on PS5.

PSPKI is Windows-only module, because it heavily relies on Windows-specific things like COM, DCOM, CryptoAPI unmanaged functions. There is no chance that PSPKI will work on anything but Windows and the only work here is to provide syntaxial compatibility for both, PS5 and PS6, so you can run PSPKI on PS Core (when installed on Windows) like it does on PS5.

Estimated schedule for each item is under internal triage.