Enable OCSP revocation check for trusted CA

[kyberpunk]

Hello, based on issue #3588 I implemented OCSP revocation check support when using trusted CAs for device authentication in tenant.

PR contains following functionality:

• Enabling OCSP revocation check on configured trusted CA in tenant
• Configuring useful OCSP settings per CA - OCSP URI, OCSP CA, nonce, check end entities only
• Tried to keep and public methods and network methods stable where possible.

To reconsider:

• Implemented OCSP settings on trusted CA level for the best flexibility. It covers also cases when user needs to setup e.g. two CAs with different OCSP URLs. However, it implied more changes in code. Alternatively we could do it just on tenant level or using Java properties. But this will affect flexibility in cases there will be different CAs with different revocation options used at the same time.
• Instead of extending TrustAnchor can use new data class, but not sure if this API can be used by someone outside of Hono code.

I'm looking forward to your feedback what would you change. Once you confirm that code changes are ok, I will can also extend tests and documentation. Currently the changes were tested just manually.

closes #3588

[kyberpunk]

@sophokles73 I was also thinking about integration tests - we are using OpenSSL OCSP server functionality for testing, so I can imagine using Testcontainers to setup OCSP responder for JUnit tests. Do you think it is good idea to do it this way?

[kyberpunk]

Hi @sophokles73 , I've incorporated your remarks and implemented comprehensive unit and integration tests. Can you please check it?

There is currently just one remaining issue related to the decision of using just subject and public key for trust anchor. OCSP request defines issuerNameHash which is created from DER encoding of CA issuer name. We are storing subject just as string and by TrustAnchor it is interpreted internally as X500 name with UTF8String type, but in original certificate it can be (and usually is) PrintableString type. This leads to inconsistent hashes with original certificate. This can lead to incompatibility with some responders (e.g. OpenSSL implementation does not work properly).

Can I add new field in TrustedCertificateAuthority for storing also the binary form of subject (similarly as pub key)? This would ensure correct compatibility according to specification.

[sophokles73]

I hope to find the time to look into this more deeply next week. Sorry for the delay ...

[kyberpunk]

I've implemented also storing of DER encoded subject DN as mentioned, so now OCSP should work properly in most scenarios.

[kyberpunk]

Hi @sophokles73 , did you please have a chance to check it?

[sophokles73]

not yet, sorry for the delay

[kyberpunk]

@sophokles73 I described the OCSP revocation check experimental feature in the documentation as you requested on open call.