Improvements in DiskSigner and DiskVerifier and refactors for the use of signing certificate chains.

[maxlambrecht]

Pull request check list

• Proper tests/regressions included?
• Documentation updated?

Description of change

This PR introduces several enhancements to the DiskSigner and DiskVerifier. Key changes include the addition of support for intermediate CAs and the signing certificate chain. Two new configuration properties have been added to the DiskSigner: trust_bundle_path which is required when the ca_cert_path contains a non root CA, and signing_cert_ttl which allows to configure the TTL of the signing certificate to align it with the expiration time of the SPIRE bundle.

Test coverage has been expanded to ensure these new features perform as expected.

The API has also been updated to accurately reflect that the signing certificate is now a certificate chain, ensuring consistency between the implementation and the APIs.

Corresponding updates have also been made to the DB schema names storing the signing certificate chain.

Finally, the related documentation has been updated.

Which issue this pull requests fixes

[Victorblsilveira]

@maxlambrecht good work here, nice abstraction and good config explanations, just some minors to improve code's readability

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

No Coverage information
0.0% Duplication

[Victorblsilveira]

Well, I really don't know why you are so reluctant in changing a name to meet the real implementation. Again, even if you plan to change in the future, the current implementation is using SHA256, so make it clear. The implementation itself will not change, just the name, the flexibility that you mention will not be affected by the name, nor any of the encapsulation and functionality.

[maxlambrecht]

Well, I really don't know why you are so reluctant in changing a name to meet the real implementation. Again, even if you plan to change in the future, the current implementation is using SHA256, so make it clear. The implementation itself will not change, just the name, the flexibility that you mention will not be affected by the name, nor any of the encapsulation and functionality.

My reluctance to change the name to reflect the current implementation is due to the following reasons:

• This DiskSigner struct is not being introduced in this PR; it already exists in the codebase. Modifying the name will also impact all dependencies that use this struct, which increases the scope and complexity of this PR.

• We will expand the functionality of this struct, specifically to enable configuration of both the hashing and signing algorithms. Changing the name now to reflect the current implementation, only to revert it back when the updates are implemented, would introduce unnecessary changes.

• The proposed name DiskSignerSHA256 only reflects the hashing algorithm, but does not account for the signing algorithm. This is a partial representation of the real implementation.

I hope this helps in understanding my standpoint.