Design OnDisk->SQLite KIM migration script.

[MattDavis00]

Design the OnDisk->SQLite KIM migration script.

This script could have a config file for setting required fields such as the authenticator_id & provider_name. provider_uuid, key_name & application_name can be inferred from the values held within the OnDisk KIM.

Design considerations:

• Within the OnDisk KIM it is possible to create two keys with the same name on different providers. The namespace for the keys held in the SQLiteKIM does not support this, keys are not separated by provider type. For example My Key 🔑 can exist within an MbedCrypto and TrustedServices provider at the same time, for the same client; this is not the case for the SQLiteKeyInfoManager. Some method for dealing with duplicate key names should be thought of. This could be an explicit mapping from old to new like Figure. 1.
• The original data held within the OnDisk key info manager should not be altered. This data can serve as a backup if the migration fails.
• We should think about how much data should be inferred/defaulted from the original OnDisk mappings. For example, provider_uuid can be inferred from the provider_id of the original KeyTriple. Likewise, application_name can be inferred from the original application name, an authenticator_id just needs appending. Could the authenticator_id be inferred from the new Parsec config.toml if there is only one? Could the provider_name be inferred from the config.toml if there is only one provider of each type?

# Generic rules to handle non-duplicate cases.
[config]
  authenticator_type = "UnixPeerCredentials"

##############################################################

# Explicit mapping to handle duplicate cases.
[[key_mapping]]

  # The old key_triple identifier information.
  [key_mapping.old]
    application_name = "1523"
    provider_type = "MbedCrypto"
    key_name = "My Key 🔑"

  # What this should be mapped to.
  [key_mapping.new]
    key_name = "My MbedCrypto Key 🔑"
    [key_mapping.new.application_identity]
      authenticator_type = "UnixPeerCredentials" # Could accept either authenticator_id (int) or authenticator_type (AuthType).
      application_name = "1523"
    [key_mapping.new.provider_identity]
      provider_uuid = "1c1139dc-ad7c-47dc-ad6b-db6fdb466552" # Could accept either provider_uuid (str) or provider_type (ProviderId).
      provider_name = "mbed-crypto-provider-3"

Figure. 1

[paulhowardarm]

We probably want to ask some more "existential" questions before diving into lots of detail here, for example:

• Do we need a migration process at all? Or, more specifically, should we wait until it is requested? Parsec is still quite a young project and its install base is quite small as far as we know. It could be a case of YAGNI, especially given that implementing it properly (without introducing security issues) could be quite fraught when you consider some of the details in the analysis above.
• If we do need migration, then does this gate the introduction of the new KIM itself? Could we, for example, release the new KIM (as a "preview" feature) in 0.9.0, but defer any migration process for later?
• If we do need migration, should it be explicit or implicit? Is it a one-off process that is executed by an admin (as this issue seems to pre-assume), or could the new KIM simply be given a reference to the old one (as an optional config entry) and do the migration within the internals of service execution?
• What constraints/limitations should we put on migration? Should we limit it to only work on single-provider/single-authenticator deployments, so that there is no ambiguity in terms of populating the fields in the new schema?
• If it's an explicit "script", then how would that be implemented? We probably don't want to leak knowledge of the internals into some completely independent tool. It would be good for the KIMs themselves to be the only chunks of code that transact with their corresponding data stores. But the KIMs are all inside the parsec binary crate. Would the script be a Rust program that imports parsec as a library (which might be possible, but quite irregular). Or would it be the parsec executable itself, with special command-line arguments to run it in migration mode rather than starting the service?