Update PSA_WANT spec for new KEY_PAIR scheme
#7774
Conversation
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
mpg
added
needs-review
|
|
||
| For asymmetric cryptography, `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` determines whether private-key operations are desired, and `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY` determines whether public-key operations are desired. `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` implicitly enables `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY`: there is no way to only include private-key operations (which typically saves little code). | ||
| As an exception, starting in Mbed TLS 3.5.0, for `KEY_PAIR` types (that is, private keys for asymmetric cryptography), the feature selection is more fine-grained, with an additional suffix: | ||
| * `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_USE` enables support for operations with a key of that type (for enabled algorithms). This is automatically enabled if any key creation method (`IMPORT`, `GENERATE` or `DERIVE`) is enabled. |
There was a problem hiding this comment.
This is automatically enabled if any key creation method (
IMPORT,GENERATEorDERIVE) is enabled.
Actually I think I'm enabling USE even for the EXPORT case. It makes sense in my opinion: also exporting requires some sort of support, i.e. USE. Wdyt?
There was a problem hiding this comment.
Yes, in my mind any KEY_PAIR_xxx should auto-enable KEY_PAIR_USE. I stole this text from @gilles-peskine-arm and failed to notice EXPORT was excluded.
There was a problem hiding this comment.
I think that when I wrote this, my thinking was: we auto-enable USE whenever there's any way to get a key into the system. EXPORT doesn't factor into that. But “whenever there's any way to get a key into the system” not exactly “if any creation method is enabled”: a system could have a built-in key (provisioned by proprietary means) and no way to create a new one.
I think what bothers me is that USE is not exactly about using keys. It includes using keys, but it's also about knowing that at least some aspect of the key type is supported. For example, it's a promise that metadata function/macros (e.g. xxx_MAX_SIZE) take that key type into account. (Although I don't think we currently have any relevant macro that's unambiguously in the public API (either they're tied to export or they're tied to public-key support or they're tied to curve/group support or they're tied to algorithm support.)
So I'm now thinking that USE isn't a good name. @mpg originally proposed BASIC, which I think is a better name. I don't remember why we changed that name to USE. With the name BASIC, it's more intuitive that any form of support automatically enables BASIC.
There was a problem hiding this comment.
Yes, I tend to agree that the actual meaning of what we currently call USE is not just about using the key to perform operations, it's more generally "the PSA system knows about this key type".
I have nothing against switching to name that better reflects this, such as BASIC. I'm adding a note about this in the original discussion, and if nobody objects, I'll update this PR.
There was a problem hiding this comment.
It makes sense to me as well, so I'll update #7641 accordingly
per Mbed-TLS#7439 (comment) and Mbed-TLS#7774 (comment) State that EXPORT implies BASIC. Also fix missing `WANT_` parts. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There was a problem hiding this comment.
Looks good to me, and aligned with what we're doing in #7641.
|
|
||
| For asymmetric cryptography, `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_BASIC` determines whether private-key operations are desired, and `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY` determines whether public-key operations are desired. `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_BASIC` implicitly enables `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY`, as well as support for `psa_export_public_key` on the private key: there is no way to only include private-key operations (which typically saves little code). | ||
|
|
||
| Note: the implementation is always free to include support for more than what was explicitly requested. (For example, as of Mbed TLS 3.5.0, `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_BASIC` implicitly enables import and export support for that key type, but this may not be the case in future versions.) Applications should always request support for all operations they need, rather than rely on them being implicitly enabled by the implementation. The only thing that is documented and guaranteed in the future is as follows: `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_yyy` -> `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR_BASIC` -> `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY`. |
There was a problem hiding this comment.
Minor: a bare > is fragile. I'd prefer to write “implies”, or at least use an actual arrow character →.
gilles-peskine-arm
added
approved
Description
Resolves #7744. Part of the text shamelessly stolen from #7766.
Context: #7439 (comment) (and preceding + following discussion).
Implementation: #7641 and follow-up issues #7771, #7772 and #7773.
PR checklist