-
Notifications
You must be signed in to change notification settings - Fork 27
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
base: main
Are you sure you want to change the base?
Conversation
* 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
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:
|
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. |
I'm thinking about a change of plan here. See my comment in Issue #50. |
[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()
andpsa_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.