package for platform identity trust anchors

[flihp]

These live in the evidence room as PEM encoded x.509 certs. This package should be something like the packages of trust anchors / ca-certs for HTTPS in linux distros.

[citrus-it]

The pkg:/web/ca-bundle package in helios that delivers CA certs is built from https://github.com/oxidecomputer/helios-omnios-build/tree/helios2/build/ca-bundle, which includes a packaged combined /etc/ssl/cacert.pem file.

Do we need the oxide anchors in that file, or do we just need the individual certificates and hash links to them?

If they should be in the consolidated file, the easiest thing would be to extend the package in helios-omnios-build. An alternative approach would be to restructure things and introduce a new SMF service for building the combined file from fragments delivered by packages.

I have a slight preference for not adding any more things into compactor but I can see the argument for keeping the oxide anchors separate.

[flihp]

Thanks for all of this data. I'm pretty ignorant of the helios stuff so this is super useful. My current thinking / assumptions are this: Certs for PKIs related to web / HTTPS stuff typically live in the 'ca cert' packages. This is an assumption but after scanning through the ca-bundle package you've linked it looks like it's just repackaging the Mozilla CA Cert Store(tm) so I think it's a reasonable one.

The certs we're talking about packaging in this case are for the PKI used to bind a public key unique to a platform with the platforms assigned barcode / serial number. If we were to add these PKI roots to the ca-bundle package you mention my understanding is that this would cause various parts of helios to include them in the set of trust anchor for HTTPS traffic. This would include general web traffic from a browser but possibly other tools as well. This is IMO not what we want.

An even less desirable outcome of packaging our platform identity root certs in this way would be the impact on the components that evaluate the trustworthiness of assertions made about a platforms identity. We should trust only our PKI roots for this purpose which means that if bundled together these tools will need to specifically ignore the other certs from the bundle. This feels like a "red flag" to me as a bug in this code may cause us to accept platform identity assertions from CAs in the Mozilla CA Cert Store. This would be undesirable.

My current approach / design goals are:

• a separate package for each group of trust anchors, currently staging & production - this is required because we anticipate that systems in a rack will only trust a single set of CA certs (production for customers, staging for stuff like the colo rack etc) while the manufacturing stations will need to have both installed so that they can manufacture systems for production or staging selectively. NOTE: the roots aren't required to manufacture the platform but after we've programmed the platforms identity we need to evaluate an attestation from the platform to ensure that it was programmed with the identity & PKI that we expect.
• each package must produce a self contained collection of trust anchors (in their own unique directory or pem file) - this goal is additionally designed to make it easy to distinguish between the two collections of trust anchors on systems where both are installed (limited to mfg system currently).

I'm currently working up scripts to build packages that meet these goals. Whether this lives in the garbage-compactor or elsewhere isn't something I have strong feelings about.

[jclulow]

I have no such preference for keeping Oxide specifics out of the compactor, FWIW. I find it substantially easier to reason about.