Client-side, import a secret, encrypt it, and send the encrypted version to the server for storage.
Client-side, import a secret and send it in the clear to the server (then delete it locally). Server-side, encrypt it and store it in potentially untrusted storage.
Right now, the spec requires both of these to be import flows to be implemented for both types of secret (arbitrary secrets and signing keys). However, flow 2 doesn't really make sense for arbitrary secrets; the server doesn't have any operations it can perform other on arbitrary secrets other than retrieving them, and that operation is also supported by flow 1. To adhere to our principle of least-trust on the server side, fix the spec to not allow flow 2 for arbitrary secrets.
At time of writing, this is not implemented, so this change will not result in any implementation tickets.
There are two import flows defined in the spec:
Right now, the spec requires both of these to be import flows to be implemented for both types of secret (arbitrary secrets and signing keys). However, flow 2 doesn't really make sense for arbitrary secrets; the server doesn't have any operations it can perform other on arbitrary secrets other than retrieving them, and that operation is also supported by flow 1. To adhere to our principle of least-trust on the server side, fix the spec to not allow flow 2 for arbitrary secrets.
At time of writing, this is not implemented, so this change will not result in any implementation tickets.