[HDDS-10743] Turn the direct dependency on BouncyCastle to an optional one

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.4.0
• Component/s: Security
• Target Version/s: 2.0.0
• Epic Link: crypto-compliance
• Assignee: István Fajth
• Reporter: István Fajth
• Created: 23/Apr/24 13:32
• Updated: 21/Jun/24 14:51

Description

Our current system is statically linked wih the BouncyCastle JCE Provider and also we directly use some of its implementation details.

If we would like to allow crypto compliance on the long run, this is a bad practice.

This task aims to collect all small tasks that can help us to refactor this dependency to be an optional and replaceable one.

Issue Links

• is blocked by: HDDS-10889 Remove certificate revocation related code.
• is blocked by: HDDS-10744 Standardize byte array conversion to String for LiveFileMetaData in RocksDB
• relates to: HDDS-11047 Unify the creation of Certificate Sign Requests in CertificateClient implementations

Sub-Tasks

• Restrict X509CertificateHolder usage to the bare minimum required.: Resolved
• Create hdds-crypto-api and hdds-crypto-default modules: Resolved
• Create hdds-crypto-default module: Resolved
• Replace PKCS10CertificationRequest usage in CertificateClient: Resolved
• Replace PKCS10CertificationRequest usage in DefaultCAServer: Open
• Do not throw OperatorCreationException from CertificateApprover#sign: Resolved
• Merge BaseApprover abstract class with the DefaultApprover: Resolved
• Use Key/TrustManagers directly for TLS connection instead of factories: Resolved
• Replace HAUtils#buildCAX509List usages with other direct usages: Resolved
• Refactor SCMSecurityProtocol to return X509Certificates instead of Strings: Open