Transitional version

[tomicnenad]

Dear EJBCA developers,

Is it possible for you to release a transitional version of ejbca-ce that includes algorithms such as Dilithium and ML-DSA, similar to what BouncyCastle has done with its 1.78 or 1.79 and even 1.80 version? This would be extremely helpful for us due to our large user base. In this way, it would also make it much easier for us to transition our users from Dilithium to ML-DSA. The current version is causing us significant difficulties, as our users are already using Dilithium, which complicates the migration process from Dilithium to ML-DSA.

Thank you very much in advance for your consideration.

Kind regards,

[primetomas]

No that is not possible. It was always stated that if you test Dilithium, you must be prepared to delete that installation once the standards were out. It is not a reasonable effort to support a smooth migration from Dilithium to ML-DSA. Set up a new system with ML-DSA and delete everything Dilithium when suitable.

[p-barabas]

@primetomas Thank you for your response. It was a very rapid update to remove existing algorithms without releasing a version which marks these as deprecated. The preferred way would be to release e.g. v9.1.1 with Dilithium and ML-DSA together with deprecating Dilithium and in v9.1.2 remove Dilithium. However bouncycastle still supports both of them. And yes, you are right, we prepared to delete Dilithium after ML-DSA is released, but it should now be a very mandatory update for clients, which are currently using Dilithium now and they cannot work anymore when we upgrade EJBCA to 9.1.1 since algorithm is missing. It was a very bad decision not to support both versions together at least in 1 version, and you could make it easy way.

[primetomas]

I'm sorry that you have difficulties with this. The approach you outline would definitely be the norm for production level algorithms. With Dilithium the issue you encounter is probably that the soft crypto tokens (PKCS#12 files) are not interoperable to read between versions, the key format has changed several times during the standardization phase. It was actually not finalized until april, where BC 1.81 will be interoperable with OpenSSL 3.5 finally for full interoperability.
As a note, we never remove functionality in patch releases, so a deprecation scheme is always for feature releases. In this case we didn't anticipate that anyone would deploy Dilithium in production, and this case was not mentioned to us (as we wrote in the documentation that Dilithium would be removed).
Now the train for Dilithium has passed, and my best suggestion is to run parallel PKIs for this during the transition and then retire the old Dilithium PKI. Going back would bear unreasonable time costs for a free open source product.