Investigate a SignClient for just-in-time key creation

[hug-dev]

For use-cases where you just want to sign data easily and securely without having to care about the signing algorithm chosen and the name of the key (because maybe you will only use one), it might be useful to create a new abstract client which:

• is based on the BasicClient: automatic authenticator and provider selection
• automatically choose the asymmetric signing algorithm which is going to be used and the key properties: RSA or ECC? Which curve (if ECC)? Which key length? PKCS#1 v1.5 or PSS (if RSA)?
• generate a key pair (if it does not exist) with those properties with a fixed named (sign-client-key)
• provides the following methods:
  • the Signer trait from RustCrypto returning an enumeration of all possible signature types (wrapper around other types implementing Signature like ecdsa::Signature)
  • verify_key (similar to this) returning the public part of the key generated as a wrapper enum of possible public key (like ecdsa::verify::VerifyingKey)

The methods leverage the RustCrypto traits and types so that the client is idiomatic and can easily be used in contexts where other implementations of those traits are used, but with Parsec. Fix #6

A possible simplification of this, is not to abstract over all possible signature/public key types but only focus on one, let's say ecdsa using the ecdsa crate. SignClient could be EcdsaSignClient or we hide this to the developper. Maybe in the future we will want RsaSignClient though (but the RustCrypto rsa crate does not yet support integration with the signature traits).

Testing

A good way to test this would be to find dependent crates of the signature traits and ecdsa (here) and replace their signature::Signer implementation with the Parsec Client's one and see if it works.

[hug-dev]

Ok maybe it's too soon to look at implementing the RustCrypto traits for now. Or not at this step. The signature traits do not define key management operations so they can not be used that easily in all contexts. If there is demand and it makes integration with existing crates easier, we can implement them on some abstracted structures. But it could happen that it's as easy as using our crate with the existing types/methods than the signature traits ones.

To focus on the SignClient (and also EncryptClient) for now, I propose to create a new AutomaticClient based on BasicClient.
It will have those methods:

• generating key pairs (for as. signing and as. encryption) with automatic selection of: key type (RSA or ECC with automatic selection of curve), key length, algorithm to use with it
• signing: with no argument use a key automatically generated just-in-time with a hardcoded name, otherwise use the generated key with method above
• decrypting: same behaviour than above
• exporting public key: same behaviour, maybe returning an abstracted type and add methods to change its format.

parsec-tool could be based on top of that client for ease of use.

[hug-dev]

See also the discussion here on Slack

[hug-dev]

The initial investigation was done.