Refactor Voucher Persistence Interfaces

[ben-krieger]

Fixes #140

[ben-krieger]

TinyGo tests are failing. Once tinygo-org/tinygo#5058 is merged, the container hash in .github/workflows/test.yml should be updated.

[runcom]

TinyGo tests are failing. Once tinygo-org/tinygo#5058 is merged, the container hash in .github/workflows/test.yml should be updated.

is that a requirement for this PR? or we can go ahead and review/merge this one?

[ben-krieger]

TinyGo tests are failing. Once tinygo-org/tinygo#5058 is merged, the container hash in .github/workflows/test.yml should be updated.

is that a requirement for this PR? or we can go ahead and review/merge this one?

Let's start reviewing. The TinyGo fix can be separate.

One thing about this PR is that it doesn't actually track onboarded state, because that's a bit nebulous.

One concrete example we might wonder about is how might an owner service know to stop TO0 when using the Credential Reuse Protocol?

[runcom]

One concrete example we might wonder about is how might an owner service know to stop TO0 when using the Credential Reuse Protocol?

I think there are specific things to look for in https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#credreuse in order to make the right call (however complex).
But also, I guess at the Owner services, we can also just say "if you're using credential reuse, then you must hit this API endpoint to trigger to0 manually again".
Meaning:

• first onboard, we stop to0 but we know it's a credential reuse case as per the spec
• second onboard, we allow hitting the to0 endpoint because we know (internal state) that the voucher can do it again because of reuse protocol

Something like the above, the implementation can decide what to support anyway right? here we need to make sure we can tell we're in these cases I guess (or provide useful callback to inspect where we're at)

[runcom]

I guess it's totally our call in the Owner service implementation to decide to actually support the reuse protocol at all (via a knob for instance)

The intended use case for this protocol is to support demos and testing scenarios where the onboarding can be run repeatedly and quickly without having to change the Ownership Voucher or resetting the system after each onboarding. Since credential reuse can permit the previous Owner unlimited access to the device, it is NOT recommended for use in the normal device supply chain.

[kgiusti]

Just for my own education - not requesting a change or anything like that - but won't this fail if the GUIDs are the same rather than add an additional voucher with the same GUID? I'm no expert on sqlite but I thought that an INSERT would fail by default if there's already a record present with the same key.

[kgiusti]

nm - I missed the fact that the passed guid is the guid of the voucher to be replaced (d'oh!) and is not the same guid used in the AddVoucher call. So yeah - this LGTM.

[runcom]

LGTM

[runcom]

test was an hiccup, re-run and now it's green, merging