ct_monitor: Hardcoded CT log key and nil log_id in STH result

[fghanmi]

When testing ct_monitor against a freshly initialized custom CT log (and also against the public good instance https://ctfe.sigstore.dev/2022), there are two issues observed:

• In getCTLogVerifier(), the ctfe2022KeyID is hardcoded. This causes the monitor to always use the Sigstore public good instance log key instead of the actual CT log being monitored (a custom CT log).
• The generated STH does not populate the log_id field correctly. The log_id field is 32 bytes of zero (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= in base64) (ie: null). I believe this can cause issues since the log_id should be SHA256(DER-encoded public key).

Example STH:
{"sth_version":0,"tree_size":1,"timestamp":1764709491415,"sha256_root_hash":"DrRmmJyXZ/ohIyh5wHjAUYww+nO2yVXoXBHFP6voMIw=","tree_head_signature":"BAMARzBFAiEA+l8wzaH1ZS50rUJv6RcddzRsz1LXP4RddmGGFGK7ErcCIBTPnvQEvzw+fneBebiuGM0BtPs09GDfuuXlYzg71t67","log_id":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="}

Expected Behavior:

• ct_monitor should use the public key ID of the CT log being monitored, not a hardcoded ctfe2022KeyID.
• The log_id in the STH should correctly reflect the SHA-256 of the DER-encoded CT log public key, if this is really intended.

Proposed Solution:
Introduce a new optional CLI flag for ct_monitor:
--ct_public_key=<PATH_TO_PEM>

CC @ret2libc

[ret2libc]

Related to the public key, what about getting the public key based on the URL in the trusted root? We already have the ct log URL.

[fghanmi]

@ret2libc Yes, it can also solve both issues. Would you like that I prepare a PR for that ?

[ret2libc]

cc @haydentherapper what do you think about the proposed approach?

[fghanmi]

I've prepared a PR to give more details about the discussed solution: #830