feat: CL Anoncreds KMS extension #3329
Conversation
kgoncharov
changed the title
Codecov Report
@@ Coverage Diff @@
## main #3329 +/- ##
==========================================
- Coverage 88.05% 87.98% -0.08%
==========================================
Files 327 329 +2
Lines 45221 45261 +40
==========================================
+ Hits 39819 39821 +2
- Misses 3987 4024 +37
- Partials 1415 1416 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
kgoncharov
requested review from
fqutishat,
troyronda,
baha-ai,
ashcherbakov and
sudeshrshetty
kgoncharov
force-pushed
the
cl-kms-extension
branch
from
c2f7407 to
b915d58
Compare
| ) | ||
|
|
||
| // getKeyTemplate returns tink KeyTemplate associated with the provided keyType. | ||
| func getKeyTemplate(keyType kms.KeyType, opts ...kms.KeyOpts) (*tinkpb.KeyTemplate, error) { |
There was a problem hiding this comment.
Shouldn't Ursa build complement normal build instead of replacing it? It seems Ursa build only supports CL keys and nothing else.
There was a problem hiding this comment.
it'll fallback to keyTemplate which contains switch statement for all other keys, if passed keyType isn't one of ursas
default:
return keyTemplate(keyType, opts...)
| @@ -168,6 +176,10 @@ const ( | |||
| X25519ECDHKWType = KeyType(X25519ECDHKW) | |||
| // BLS12381G2Type BBS+ key type value. | |||
| BLS12381G2Type = KeyType(BLS12381G2) | |||
| // CLCredDefType type value. | |||
| CLCredDefType = KeyType(CLCredDef) | |||
| // CLMasterSecretType key type value. | |||
There was a problem hiding this comment.
CL keyType is exposed to non Ursa build, but creating a key with this type is only available in ursa build. Do we want this behaviour?
There was a problem hiding this comment.
I guess it's ok, if there are no direct build dependencies to ursa lib, which is true for most of kms, localkms and remotekms methods/code.
The only part is ursa-dependent - is creating key templates - which was splited to by ursa and non-ursa source files.
So, for non-ursa build CL keys would be simply not created.
Also, later on, CL keys could be created with other lib or be incorporated inside af-go
There was a problem hiding this comment.
Also, later on, CL keys could be created with other lib or be incorporated inside af-go
sounds good, let's keep this in mind for future support of CL and afgo in general
kgoncharov
force-pushed
the
cl-kms-extension
branch
2 times, most recently
from
0f3623b to
d9b521a
Compare
* extended kms API key create/rotate/export with extra options * added CL CredDef and MasterSecret keys to localkms * implemented CredDef pubkey export * refactored keytemplate resolving * added unit tests for CL keys * re-generated kms's mock Signed-off-by: konstantin.goncharov <konstantin.goncharov@avast.com>
kgoncharov
force-pushed
the
cl-kms-extension
branch
from
d9b521a to
ffd26bc
Compare
Title:
CL Anoncreds KMS extension
Description:
af-go#180remotekmsandremotecryptochanges will be implemented in the next PR in bothaf-goandtrustbloc/kmsSummary: