Credential management

[kaczmarczyck]

New command for #106 . This PR contains all changes for reference, and will be split into smaller chunks. The commit 6724acf moves all changes to a separate file. While they belong to mod conceptually, this file has grown too large already and the commit is for opening discussion about if we want to split mod up like that.

[ia0]

I just reviewed the persistent storage change. It looks good to me.

[kaczmarczyck]

The implementation is heavily reworked after the rebase!

[ia0]

Overall looks good to me, but it's quite big. I have the feeling we need stronger testing strategy than review, unit tests, and test suite to get some confidence about the correctness.

[kaczmarczyck]

You mentioned a potential improvement / optimization of the storage API and RAM usage, PR size and testing. What do you think of the following plan:

For storage: I keep the storage in this PR as is for reference (see below), and work on improving RAM usage in a new PR.

For PR size: This PR is pretty old, and was blocked by the 2.1 spec to land. Therefore, it has some ballast. I need heavier code changes with #252 anyway, and wanted to split out some of the changes made here for some time. But, I wanted to finish the storage review with you first so you don't have to review it again. I'll keep this PR open for reference, and send out a few smaller PRs for crypto, storage etc.

For testing: I tested this PR with the latest Chrome, since it supports credential management. It works, when you add one little change: You remove the check for PIN permissions (not the PIN check, just the permissions). This is a new 2.1 feature that doesn't seem to be supported yet. Everything else (the crypto, the command and subcommands) works. If you have any other ideas, please let me know.

[ia0]

For storage: SGTM

For PR size: No problem, I wasn't saying we should split it. Just that I've most probably missed some stuff.

For testing: Ideally (is it even feasible?), we would have our implementation be a library with a thin wrapper for Tock and other side-effect dependency code, and we would have a Rust specification of CTAP (which should be very small and straight-forward code because there's no embedded-programming constraints or other performance constraints). We would then be able to fuzz our implementation against this specification (like for the persistent storage). The Rust specification could also be a reference specification for the community (including the configuration and scenario generator). We might at least want to start an issue to make our CTAP code a library, since it would enable simpler fuzzing (just crash-detection or other basic soundness properties, not correctness). And it might be easier to adapt to other backends as Tock.

[kaczmarczyck]

Closing this PR as #256 is the new, rebased command, minus #253 and #254.