Add RSA mechanisms and key serialization format

[sosthene-nitrokey]

We will port the RSA implementation to a custom backend. While backends can have extensions, they can't have custom Mechanisms and Serialization for the normal APIs. This patch adds them so that they can be implemented by the custom backend.

[robin-nitrokey]

I think we also need some changes to the constants in config, right?

main...Nitrokey:trussed:main#diff-cba64c21ab992eaad29fce147a08f4560a4769bc14682b8a96081a5fd02dbecd

[sosthene-nitrokey]

Yes probably. I'm making the migration to a custom Backend in parallel and I will keep this as draft until I'm sure everything is enough.

[sosthene-nitrokey]

This branch works with https://github.com/Nitrokey/trussed-rsa-backend

[sosthene-nitrokey]

Looks like the CI has some issues downloading stuff to setup the docker image

[sosthene-nitrokey]

I don't really understand why the CI fails

[daringer]

Yeah that's weird, especially those are all urls within Azure that fail, maybe some patience will help here. On a first glance this doesn't look like something we can debug...

[sosthene-nitrokey]

There are similar errors with #71

[daringer]

yup yup, good indication that we should give it like 24h or something

[sosthene-nitrokey]

Looks like the CI is fixed

[robin-nitrokey]

The comment implies that the value changed, but we still use 1024. Which one is correct?

[sosthene-nitrokey]

This was a remnant of the original PRs for RSA. I removed it.

[nickray]

How about calling this Serde or PostcardSerde to make it potentially reusable?

[sosthene-nitrokey]

I want to keep it generic and let the backend decide on the actual data format (for now at least)

[nickray]

Internal or Private then? You could also re-use Raw if this is an internal implementation detail. The motivation is to keep serialization formats few and stable, as this concerns both the long-term API and the long-term storage of keys.

[sosthene-nitrokey]

and the long-term storage of keys

The serialization format doesn't affect how they're stored.

I don't want to reuse Raw as it feels misleading. Unlike ECC, there is no standard "raw" byte representation of RSA keys.

The "Parts" is in contrast to the PKCS format. The PKCS format is defined, but the "Parts" formats contains each element of a public key separately. The "part" name is more representative than "Internal" or "Private". "Serde" feels out of place. The use of postcard and serde is more of a workaround that the actual goal of the API. If you look at the traits in trussed-rsa-backend, they provide APIs directly over the structures, and hide away the parsing/serializing with postcard and serde (when possible):

fn unsafe_inject_rsa4096<'c>(
    &'c mut self,
    key_parts: RsaImportFormat,
    attributes: StorageAttributes,
) -> ClientResult<'c, reply::UnsafeInjectKey, Self>;

fn deserialize_rsa4096_public_key<'c>(
    &'c mut self,
    key_parts: RsaPublicParts,
    attributes: StorageAttributes,
) -> ClientResult<'c, reply::DeserializeKey, Self>;

Ideally I would even merge the RsaImportFormat an RsaPublicParts structures into Trussed proper but I want to be sure we can have something that fits all backends and use-cases first.

Maybe we should have mechanism extensions? That would mean more generics though.

[nickray]

Yeah I understand. My point is just that Pkcs8Der is an obviously valid general purpose format to upstream, while RsaParts is not. So can I'd like to merge this without this RsaParts. I believe you can use Raw (or we add something generic but general-purpose like Experimental) for your current work, and once it's set in stone, do a follow-up PR?

[nickray]

Or what about Parts :) That way you have your specific format to use, but unrelated algorithms might find a use too.

[sosthene-nitrokey]

My point is just that Pkcs8Der is an obviously valid general purpose format to upstream, while RsaParts is not

I disagree. Whatever we do we will need a way to access specific parts of RSA keys. Both PIV and OpenPGP need that (OpenPGP needs it for both public and private keys, PIV at least for public keys). Pkcs8Der will also be incompatible with the SE050.

Or what about Parts :) That way you have your specific format to use, but unrelated algorithms might find a use too.

I'm not a fan of loosing readability for more flexibility when there are no obvious benefits to it. Do you know of any other algorithm that would use this?