Permit client CA and infra CA to use UUID serial numbers

[jcpunk]

Pull Request (PR) description

Permit client CA and infra CA to use UUID serial numbers

Assisted-by: Claude noreply@anthropic.com
Assisted-by: Qwen noreply@litellm.ai

While I'm not a clojure programmer, the code looks sane to me.

This Pull Request (PR) fixes the following issues

Fixes #284

[corporate-gadfly]

@jcpunk : Could you feed the LLM this error on your feature branch please?

Syntax error compiling at (puppetlabs/services/ca/ca_testutils.clj:121:22).
No such namespace: str

[jcpunk]

I fed the linting and compiler errors into the tooling. Hopefully this looks better.

[corporate-gadfly]

Also, some linting errors:

test/unit/puppetlabs/puppetserver/certificate_authority_test.clj:2565:7: warning: Redundant let expression. [:redundant-let]
test/unit/puppetlabs/puppetserver/certificate_authority_test.clj:2585:7: warning: Redundant let expression. [:redundant-let]
test/unit/puppetlabs/puppetserver/certificate_authority_test.clj:2601:8: warning: Redundant let expression. [:redundant-let]
test/unit/puppetlabs/puppetserver/certificate_authority_test.clj:2892:7: warning: Redundant let expression. [:redundant-let]

[nmburgan]

This needs some very careful human inspection. Please don't merge until we can do some due diligence on reviewing and testing, since this is a critical foundational piece of the whole OpenVox infrastructure.

[corporate-gadfly]

This needs some very careful human inspection. Please don't merge until we can do some due diligence on reviewing and testing, since this is a critical foundational piece of the whole OpenVox infrastructure.

Agreed. Converted to draft.

[nmburgan]

Moving to UUIDs is definitely a good move. But this may be a really tricky change.

1. Need a Clojure expert to review this (@austb ?)
2. Need to test upgrades and ensure that existing installs that are using sequential serial numbers combined with new certs that have UUIDs work seamlessly.
3. Need to audit all OpenVox code (agent, server, db, what else?) to ensure they handle certs with UUIDs correctly.
4. Not only OpenVox uses the certs. Apps like Foreman also do. So we have to make sure we don't break those critical apps as well.
5. We've also talked about either ripping out the CA entirely or leaving the current one as legacy and helping people migrate to an off-the-shelf CA. I don't know that we necessarily have to decide that now, but this change has the potential to cause chaos, so if we end up with chaos either way, perhaps moving to a different CA is the useful chaos. Or maybe not.

[corporate-gadfly]

With 2 failures, 12 errors., it would have to be a clean run before we can attempt to look at the changes introduced in the src tree.

Personally, I'm inclined to defer, for now.

[jcpunk]

I wouldn't necessarily mind an external CA only on OpenVox9, but I'm heavily dependent on my custom autosign.rb for getting clients registered.

[jcpunk]

Regretfully, this is as far as I can get fixing up the tests. The LLMs seem to get stuck in a loop where they insist the tests are right and my runtime is wrong...

[Sharpie]

I started looking through this and one thing that jumped out immediately is that the first chunk of diff is changing a bunch of type signatures and defaults that seem unrelated to toggling the type of serial number that is used.

These might be good changes, but when mixed into a single commit there just isn't the context to understand why lines are being changed.

At a minimum, this PR needs to be narrowed in focus and broken up into logical commits that provide context as to why changes are being made. The Certificate Authority is the single most critical load-bearing structure in an OpenVox installation, so having well-presented context on what is changing and why is a hard requirement for me to 👍 any changes here.

[Sharpie]

I don't think we want to use v4 "random" UUIDs. For example, something that has namespaces, like UUID v5, allows us to definitively run separate issuing CA instances guaranteed to produce separate identifiers rather than just relying on a collision in v4 being "statistically improbable".

I took a look at the Boulder CA used by Let's Encrypt and they are using a namespaced identifier, but also not a UUID variant.

Moving away from a sequential integer is very likely a choice we will only be able to easily make once. So, the choice of algorithm should start off with a survey of what existing CA implementations use, recommendations from RFCs and CA/B standards, and then an algorithm chosen from a group of identified alternatives based on weighing the pros and cons.

[Sharpie]

Also, we should carefully consider if there are any alternatives that fit into the 64-bit size provided by the existing Int. I suspect a change that preserved compatibility with Int would dramatically reduce the amount of churn in test cases and code paths outside of serial number generation, which would be a very weighty "pro" when compared to other alternatives.