Open chrysn opened 3 years ago
I agree that this is a necessary addition to the CoseKey
API, I'm just not sure how I should handle the SymmetricKey
case (if we want to add this function to the general CoseKey
API).
Should the function just return None
for a COSE SymmetricKey
?
Having seen that generate_key
is only part of the EC2Key and OKPKey objects (and not the CoseKey), it may make sense to only provide the split for these.
(I'm unsure as to whether there is any value in declaring the functions in an intermediate asymmetric ABC, or whether the duck typing that just now works for EC2Key and OKPKey will still be sufficient there).
There is a function to randomly generate COSE keys, but no way to programmatically split out the private key part.
As a workaround, I'm generating keys and then remove the
d
(which at least works the same way in OKP and EC2 keys), but for the general case (RSA having been recently added, albeit irrelevant to my EDHOC use case) the key type would need to know how to strip the private parts out of this.The function could have a signature
def public_part(self: CoseKey) -> CoseKey
, and could raise ValueError if key does not contain any public information (seems one can construct an OKP from ad
alone, not sure if thex
can be derived then).Relatedly, it may also make sense to remove any unneeded public parts from a key -- but I don't know if that has any practical applications (in local storage it's probably fine to keep the public parts around, Python systems are typically not constrained).