Open bwesterb opened 2 months ago
We were just having this conversation earlier today about how "requirements-aware" the API should be and to what extent it should enforce them.
The policy to specify is a really interesting idea.
As of this moment, the open-mpic API allows for specification of any value for the quorum, with the value of 0 effectively rendering it a logging-only service that interprets all outcomes as passing. I am thinking of proposing a change to that, and have a pull request that's under review which nudges validation logic more towards the requirements-aware side of things.
At the same time, the quorum count is currently an optional parameter. In its absence, the default can either be fully configurable by whoever owns the services (i.e. set it to something like 5 in a config file) or it can be programmatically derived based on the count of remote perspectives being interrogated (i.e. perspective_count - 1
or perspective_count - 2
depending on whether that count is <6 or not.)
Anyway in the interest of making fast progress on this, here's my current thinking and what I'm considering implementing in the coming days, though I'm 100% OK with changing completely if my reasoning is faulty.
I propose that quorum count remain an optional parameter to specify to the service, to allow for a higher-than-minimum-allowed-by-the-requirements threshold. If you want a quorum of 100%, that should be possible.
I also propose that the default quorum is requirements-aware (programmatically derived). The logic used for deriving it can be policy-specific... that's something I hadn't thought of. I don't have a strong opinion on whether that should be how the service applies logic (i.e., it can apply a non-current policy) or whether it should just always be updated to reflect the current policy, and versioned accordingly. Perhaps the latter?
I also propose that the quorum count in the API request (assuming it's a whole number) is allowed to be below the required minimum only if the API is run in a diagnostics/dev mode with value validation (as opposed to request structure validation) disabled. That, or include a warning in the response that the quorum count used is below the required threshold and therefore cannot actually be used to support cert issuance. Not sure if the latter is really a useful use case to support, though.
There are two points to this conversation I would bring up.
I am still thinking a bit more on this. I like auto quorum (so if you don't specify a quorum we go with what the CAB Forum says). I am still now sure how much the API should yell at you if you do something not CAB F compliant.
What about two options:
balance
(default) Let the MPIC service choose. This allows the MPIC service to loosen or tighten requirements with more insight. Of course needs to meet current CA/B guidelines.baseline
Follows the current minimum CA/B minimum requirements, and nothing more.I thought about adding a third strict
option but I'm not quite sure how to define it.
And of course we add an optional-to-implement API for the exact count.
I like the balance, baseline options as long as it coexists with a way to specify the exact count. I do like the idea of also having a strict option which I think should be defined are requiring a success from all perspectives used. Another name could be "full" for the option.
Should we allow the client to specify the details of the quorum? Eg. min 2 out of 10. Or just a policy? Eg. CA/B 2026. Or leave it completely to the service.