Create public high-level interface for securesystemslib.keys

[lukpueh]

Currently securesystemslib.keys provides PEM import functions for public and private ecdsa and rsa keys.
Let's also support ed25519 and add JSON import functions for all three protocols.

UPDATE:
Below discussion has moved the focus of this issue to add/factor out securesystemslib high-level functions from the lower-level securesystemslib.keys module, i.e. what goes into securesystemslib.keys and what goes into securesystemslib.interface.

[vladimir-v-diaz]

I'm confused about exactly what you want. Let's use the import function for RSA keys as an example...
import_rsakey_from_private_pem(pem, password=None)

The above function accepts a PEM argument and returns JSON:

https://github.com/secure-systems-lab/securesystemslib/blob/master/securesystemslib/keys.py#L1061-L1109

Do you want to accept a JSON argument and return what?

[lukpueh]

First of all I want to add three functions:

• import_ed25519_from_pem
• import_ed25519_from_private_pem
• import_ed25519_from_public_pem

which should return python dictionaries compliant to formats.ANYKEY_SCHEMA, like import_rsakey_from_private_pem does (unless we say, we never store ed25519 keys in PEM format).

Additionally I want to add or rather move functions to import ed25519, ecdsa and RSA keys, JSON serialized in above format and returning Python dictionaries in above format, like tuf.repository_lib.import_ed25519_publickey_from_file or securesystemslib.import_ed25519_publickey_from_file (which btw. are copy-pasted)

The rationale is, to provide all key loading functions in securesystemslib.keys, which IMHO was why we separated securesystemslib from TUF in the first place.

[lukpueh]

I think we should add all functions from securesystemslib.interface and relevant functions from tuf.repository_lib to securesystemslib.keys, which according to its docstring is an "easy-to-use public interface" for "(RSA, ECDSA and Ed25519)-related function".

[vladimir-v-diaz]

The reason why I originally only added a function to import RSA keys in PEM format was because not all our supported external crypto libraries might recognize the other key types (e.g., Ed25519 keys in PEM format). It was only recently added to OpenSSL.

What I tried explaining before is that the filepath argument in the function below might not necessarily be JSON across different projects. Some project might want to store key files in a custom format. For example, the Go implementation of TUF stores it in a different format.
https://github.com/lukpueh/tuf/blob/develop/tuf/repository_lib.py#L1131

[lukpueh]

(1) Okay, let's not add PEM import functions for Ed25519, I'm fine with that.
(2) I see what you mean, but the Go implementation will probably not use the securesystemslib Python package, right? What do you think of my #35 (comment), i.e. merging securesystemslib.interface and parts of tuf.repository_lib into the keys module?

[lukpueh]

I just want to avoid having redundant implementations of the same thing (tuf, securesystemslib) or having different modules addressing the same logical domain (interface, keys)

[lukpueh]

Card sorting

which of the following functions make more sense in a high-level securesystemslib.interface and which in a low level securesystemslib.keys:

_get_keyid(keytype, key_value, hash_algorithm = 'sha256')
_get_password(prompt='Password ', confirm=False)
_prompt(message, result_type=str)
check_crypto_libraries(required_libraries)
create_rsa_encrypted_pem(private_key, passphrase)
create_signature(key_dict, data)
decrypt_key(encrypted_key, passphrase)
encrypt_key(key_object, password)
extract_pem(pem, private_pem=False)
format_keyval_to_metadata(keytype, key_value, private=False)
format_metadata_to_key(key_metadata)
generate_and_write_ecdsa_keypair(filepath, password=None)
generate_and_write_ed25519_keypair(filepath, password=None)
generate_and_write_rsa_keypair(filepath, bits=DEFAULT_RSA_KEY_BITS,
generate_ecdsa_key(algorithm='ecdsa-sha2-nistp256')
generate_ed25519_key()
generate_rsa_key(bits=_DEFAULT_RSA_KEY_BITS)
import_ecdsa_privatekey_from_file(filepath, password=None)
import_ecdsa_publickey_from_file(filepath)
import_ecdsakey_from_pem(pem)
import_ecdsakey_from_private_pem(pem, password=None)
import_ecdsakey_from_public_pem(pem)
import_ed25519_privatekey_from_file(filepath, password=None)
import_ed25519_publickey_from_file(filepath)
import_rsa_privatekey_from_file(filepath, password=None)
import_rsa_publickey_from_file(filepath)
import_rsakey_from_pem(pem)
import_rsakey_from_private_pem(pem, password=None)
import_rsakey_from_public_pem(pem)
is_pem_private(pem, keytype='rsa')
is_pem_public(pem)
verify_signature(key_dict, signature, data)

[lukpueh]

Maybe we should rename/rededicate this issue into something like:
Create public high-level interface for securesystemslib.keys

[vladimir-v-diaz]

Sounds good to me.

[lukpueh]

@vladimir-v-diaz, I understand your thoughts behind separating keys and interface better now. I still think that a revision of those modules and rethinking what goes where would not hurt. :)