Codepointing the Executables Bucket

AR4SI's State of Art and CCA mappings

Currently, the Executables bucket defines 5 codepoints:

• two affirming
• two warnings
• one contraindicated

While mapping AR4SI to CCA, we identified a few problems with the current state of affairs in the Executable bucket:

• the codepoints are not sufficient to cover the cases we need to potentially describe,
• the conflation of boostrap and runtime executables complicates the expression of intent

Verifier Statements about Executables

Starting from first principles, the verifier needs to make the following statements to a RP (or a downstream verifier):

• ✅ : "checks done, all components are known-good"
• ❌ : "checks done, at least one component is known-bad"
• ❓ : "checks done, at least one component is unrecognized"

To these three, we need to add a fourth "➖", meaning "no checks done" - either because no executables pop up in evidence, or because the verifier is not authoritative for the executable bits of that piece of evidence.

The possible combinations of the three main "checks done" statements are:

Keeping all the eggs in one bucket

If the Executables bucket needs to carry statements about boot and runtime executables, since there are 4 possible of them, it means their cross-product will burn a good chunk of the standard available codepoints. This is not ideal.

The table below tries to capture all combined boot+runtime statements and assign them a codepoint¹.
Note that we also need to cater for Runtime not being checked, which adds 4 other codepoints, for a total of 20.
That looks like a lot, especially considering that the Contraindicated space is smaller than the Warning space (30 vs 60).

Splitting the Executable bucket in two

If instead we split the Executables bucket into separate Boot and Runtime buckets, the codepoints pressure drops dramatically:

In this scenario, the ➖ (not checked) condition, would result in the corresponding bucket being missing or 0-scored.