You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As for now, keyhelper is limited to supporting only RSA2048 keys, while notation CLI and Vault's transit secret engine is supporting longer keys (3072 and 4096 bit).
I would appreciate it if keyhelper could detect the key length and use the right key length during importing key to transit engine
The text was updated successfully, but these errors were encountered:
can be updated to return another string or int corresponding to the key type+length (either in transit format or otherwise just the raw number of bits).
I don't know off the top of my head if Notary supports other types of keys (ECDSA?) but given the upcoming PQC standards, I'd imagine it'd want to start doing so... So perhaps returning the string would be most optimal and ECDSA/... support can be added more easily.
@cipherboy I was already working locally on support for this and in #21 is what I have implemented with mostly standard libraries.
There were a few differences in how Notation and Vault defines names for ie. hash algorithms, and I tried to cover this with maps.
Moreover, when I started, I haven't had bigger awareness of notation-go library, and I'm thinking if it's fine to leave it as is or maybe reimplement this with notation-go/signature parts instead?
My code was mostly written before your suggestion about contribution, so I decided to show it as it is, but I can rework it accordingly to your description in previous message :)
Hello!
As for now, keyhelper is limited to supporting only RSA2048 keys, while notation CLI and Vault's transit secret engine is supporting longer keys (3072 and 4096 bit).
I would appreciate it if keyhelper could detect the key length and use the right key length during importing key to transit engine
The text was updated successfully, but these errors were encountered: