Feature Request: Simplify REST API Endpoints for Blob Upload and Download Using Key Pair IDs

[MGTheTrain]

Is your feature request related to a problem? Please describe.

Currently, the REST API endpoints for blob upload and download require direct handling of encryption, decryption, signing, and verification operations. This can be cumbersome, especially when dealing with asymmetric keys, where specific operations need to refer to different keys (public or private). The current implementation could be simplified by abstracting key management into a more straightforward reference mechanism, such as using key pair IDs, which would enable us to refer directly to the appropriate key pair for operations.

Describe the solution you'd like

To simplify the process, we propose enhancing the blob upload and download API endpoints to allow referencing encryption and signing keys via a key pair ID. Specifically, for asymmetric encryption or signing operations, instead of manually specifying the keys (public or private), the API would allow users to specify a keyPairId, which internally resolves to the correct public or private key. This would make the API easier to use and remove the complexity of key selection.

The API endpoints should allow:

• Uploading a blob with a specified keyPairId for encryption.
• Downloading a blob with a specified keyPairId for decryption.
• Signing a blob using a specified keyPairId for the signing key.
• Verifying a blob using a specified keyPairId for the verification key.

By doing this, the API can automatically handle the correct selection of the public or private key based on the operation (encryption, decryption, sign, verify), ensuring better security practices and reducing the potential for errors in key management.

Describe alternatives you've considered

One alternative could be to continue manually specifying the keys for each operation, but this increases the complexity and possibility for human error. Another alternative could be creating separate endpoints for encrypting, decrypting, signing, and verifying with key pair IDs, but this would lead to a fragmented and harder-to-manage API design. Therefore, centralizing key management via keyPairId references seems like the best approach.

Additional context

By implementing this feature, we would streamline key management in the API and improve the overall user experience. Additionally, users would be able to switch keys more easily for different operations without needing to manage individual keys directly, improving maintainability and reducing potential security risks.