Add import-key subcommand

[miroheikkonenabb]

It should be possible to import keys trough Parsec-tool with an import-key command as that functionality exists in Parsec. This should support at least Mbed-crypto. It shoud take the key or key pair we want to import as an input and at least EccKeyPair should be supported.

[ionut-arm]

Hi @miroheikkonenabb, thanks for the request. We're happy to get this integrated into the tool and we'd be grateful if you contribute it - we can offer guidance for navigating the code and feedback on the PR.

In terms of interface design, we'll need to settle a few questions before comitting to an implementation:

• What types of keys do we need to support? You mention EccKeyPair, so no RSA keys for now, but are there specific elliptic curve families that you need supported, e.g., SECP-R1? (this might be irrelevant, depending on how we select or default the attributes for the key we're importing, or if we pick them up from a file, see below)
• What format should the keys be in? Is PEM sufficiently comprehensive in what it contains? This MbedTLS article seems to imply that, for RSA keys at least, there are multiple encodings. For ECC keys, though, I assume PKCS#8 will apply.
• How should the parameters for the keys be passed to the tool? Will they be included in the encoding used within the PEM file, for example? The subjectPublicKeyInfo and ECPrivateKey definitions seem to include everything we'd need, but this depends on what you expect to be available.
• Should the interface be tailored to resemble creating keys? At the moment we have create-rsa-key and create-ecc-key, but that was for ease of defaulting arguments, so if the key attributes are available some other way then a simple import-key might work reasonably well

[miroheikkonenabb]

HI!

We are not using RSA so it's enough for us to get import-ecc-key subcommand which has support for SECP256-R1 EccKeyPair.

As a parameter PEM private key with PKCS#8 encryption would be used. Export-public-key and create-csr create PEM so I'm guessing it should have all the necessary information.

As a suggestion: there could be flags the same way that create-key commands have: "--for-crypt" and "--for-signing"

[paulhowardarm]

I think that ECC keys are universally used for signing, so we could probably default to that and not need a switch. (RSA keys default to encryption, and support "--for-signing" to override the default. The create-ecc-key function always creates a signing key, and I think import-ecc-key should probably do the same.

PEM PKCS#8 as input makes sense, although we might want to think ahead to how the CLI commands should process multiple input types. At the moment, export-public-key produces PEM PKCS#8, but that's because we see that as being the most useful default, and the tool tries to always do the most useful thing with minimal typing. We could add switches later to override and output different formats, if there is a need for that. So we want to make sure that any new import commands have some kind of protocol associated with them so that we can be more flexible on file formats in the future, possibly accepting DER for instance. I would suggest that we just assume PEM PKCS#8 for now. Future evolution can either be done by adding a switch parameter or by auto-detecting the format if that's feasible and reliable.

@miroheikkonenabb would you be interested in contributing this as a PR? We would love to work on this with you collaboratively, and we can provide as much guidance and help as needed. We are actively seeking to grow the Parsec community and have PRs coming in from a diverse set of participants and organisations. This helps with the health of a project from a CNCF growth standpoint as well.

[paulhowardarm]

I'm currently adding an encrypt command to parsec-tool, which will allow plaintext to be encrypted using a public key or the public part of a key pair. The current test case for this command is limited to round-tripping an asymmetric encrypt/decrypt operation using just the parsec-tool. Better practice would be to cross-test against openssl, but we can't do this yet until it becomes possible to import public keys. So when this PR is contributed, it will also be possible to improve our cross-testing of the encrypt function.