Revise stand-alone on-disk key format #309
Comments
This was referenced Dec 9, 2020
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Oct 16, 2023
This is in preparation for the removal of legacy key modules and formats, in favor of the new Signer API. It allows users to convert their old rsa, ed25519 and ecdsa key files, generated with the `interface` or `keys` module, and using an outdated standard or sslib proprietary format (see secure-systems-lab#309), to a consistent new standard format, which can be used with the file-based signer (`CryptoSigner`) of the new Signer API. NOTE: The script uses legacy code and should thus be removed with them, from the repo tree, while remaining available to users of securesystemslib for some time. We could keep pointing to it in docs after its removal (users would need to check-out the repo at a specified tag), or move it to a different place. *Change details* * Add cli script to convert key files. * Add private/private encrypted/public test key files for each supported algorithm in the legacy format. **The key pairs were generated with `interface`, minimally modified to allow writing an encrypted and non-encrypted version of the same private key. * Add comprehensive tests, includes backwards/forward compatibility of signatures. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
lukpueh
added
the
legacy
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of issue or feature request:
#251 discusses various consistency issues related to securesystemslib (TUF/in-toto) cryptographic keys. This issue splits out the concerns related to stand-alone on-disk key formats:
For some key types we support serialization and deserialization of standard formats, whereas for others we use a custom format (see 'Current behavior' for details), which results in an inconsistent API. E.g. the custom format includes a signing scheme, which may be assigned at key creation time, whereas standard format keys don't include that scheme and thus need to have it assigned on import.
Current behavior:
securesystemslibcurrently provides functions to...Expected behavior:
Make on-disk key formats consistent for all key types (standard vs. custom, signing scheme included vs. not included). Preferably we support standard formats for all types. This would allow end-users to generate keys out-of-band and use securesystemslib only to import public keys and convert them to the in-toto/tuf metadata format (see #308 ), and similarly to import private keys to generate signatures in the in-toto/tuf metadata format.
This has the advantage that users don't need to trust our key generation functionality (standard crypto is better than custom!).
Furthermore, if users don't depend on our key generation code, we could remove or limit it to very thin wrappers around well-established tools such as
openssh-keygen,openssl,gpg, etc. to be used mostly internally (e.g. for tests and demos), which would be a huge maintenance relief.The text was updated successfully, but these errors were encountered: