I'm opening this issue to discuss the Key design before cutting v1.2.0 @setrofim (I've removed the tag and release you just created).
Extracted from #146 (review):
The Key struct, implemented in #146, contains all known key parameters, that is, from EC2, OKP and Symmetric Keys. This doesn't scale well, as in the future we might want to support new keys that, for example, defines D as a tstr instead of bstr, in which case it will be hard to retrofit the new key. In fact, this already seems to happen with EC2 y-coordinate, we only support bstr but the spec also supports bool.
IMO it would have been better to define key parameters in separate structs, one for each key type, and have Key just contain a property like Params any, which could contain the specialized parameters struct.
@shizhMSFT
I'm opening this issue to discuss the
Keydesign before cuttingv1.2.0@setrofim (I've removed the tag and release you just created).Extracted from #146 (review):
The
Keystruct, implemented in #146, contains all known key parameters, that is, from EC2, OKP and Symmetric Keys. This doesn't scale well, as in the future we might want to support new keys that, for example, defines D as atstrinstead ofbstr, in which case it will be hard to retrofit the new key. In fact, this already seems to happen with EC2 y-coordinate, we only supportbstrbut the spec also supports bool.IMO it would have been better to define key parameters in separate structs, one for each key type, and have
Keyjust contain a property like Params any, which could contain the specialized parameters struct.@shizhMSFT