Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT: Support for key wrapping #215

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

athoelke
Copy link
Contributor

@athoelke athoelke commented Sep 10, 2024

[Added 24/10/24] Superseded by #224 - which provides just the simplified key wrapping and unwrapping functionality. The wrapped-key format support will be represented in a later PR.


Building on the key formats in #207, this PR defines an API for wrapping and unwrapping keys.

The first attempt explores an approach which extends the psa_import_formatted_key() and psa_export_formatted_key() APIs, and adds a key wrapping key and algorithm to the process. The idea is that it could support wrapping keys using a general key-wrapping algorithm (such as AES-KW) with existing clear-text key formats, and wrapping keys in wrapped-key data formats, such as EncryptedPrivateKeyInfo.

I am publishing this as an initial draft to provoke discussion around the challenges and undecided issues with this approach, including the policy integration issue that affects import of formatted keys.

The first commit specific to this PR (not in #207) is 192eb55

Fixes #50.

* Decided to do public key export via a dedicated function
* Removed ECPoint as a format
* Required public keys in key pair formats
* Added options for domain parameters
* Individual boolean options override defaults instead of providing both option elements
* Added references for everything
* Defined new terms for ASN.1, DER and PEM
* Open issue regarding handling of encoded policy in key data
@athoelke athoelke added enhancement New feature or request API design Related the design of the API Crypto API Issue or PR related to the Cryptography API DO NOT MERGE labels Sep 10, 2024
@athoelke
Copy link
Contributor Author

This approach does not handle non-standard approaches for wrapping keys: e.g. using an application-specific format for key meta-data with a standard AEAD algorithm. Ideas for handling such scenarios:

  1. Left to the application: export the key data and drive AEAD from the application. This has the key material in plaintext (for a time) in the application memory.
  2. Handled as a custom wrapped-key format: the implementation has to provide built-in support for the application design.
  3. Use a different (or additional) Crypto API design. For example, add an input function to an AEAD multi-part operation that updates the operation with a formatted key.

@athoelke
Copy link
Contributor Author

I think we need to identify a representative set of use cases to cover the important ways in which the API needs to support key wrapping. And ensure we consider agility for future key types (PAKE, PQC, etc.) as part of the process.

It may be that we need more than one API to handle standard wrapped-key formats that are self-describing (in terms of wrapping algorithm(s)); general purpose key wrapping algorithms (typically specialized AEAD algorithms); and applications that use AEAD algorithms to create non-standard key-wrapping schemes.

@athoelke
Copy link
Contributor Author

athoelke commented Oct 9, 2024

I'm thinking about a change of plan here. See my comment in Issue #50.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API design Related the design of the API Crypto API Issue or PR related to the Cryptography API DO NOT MERGE enhancement New feature or request
Projects
Development

Successfully merging this pull request may close these issues.

Add APIs to support wrapped keys
1 participant