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
This line of code makes it impossible to use this with any PrivateKey implementation from providers that do not allow you to access the key material, e.g. the AndroidKeyStore, Azure key vault, or AWS KMS providers.
However, since you are using the ASN.1 sequence from PrivateKey.getEncoded() to get information about the private key such as the algorithm etc that would have to be done in some other way since the method returns null for such private keys. PrivateKey.getFormat() also returns null for such keys as it refers to the format of the encoded key. PrivateKey.getAlgorithm() (link) will return one of the standard algorithm names as defined here.
I think this would be a nice feature to have. But I don't understand this code base enough and the features it needs to have if it is feasible to support this for the generic case, right now I have a workaround where I have implemented signing using unexportable private keys myself.
The text was updated successfully, but these errors were encountered:
COSE-JAVA/src/main/java/COSE/OneKey.java
Line 144 in e461e5e
This line of code makes it impossible to use this with any PrivateKey implementation from providers that do not allow you to access the key material, e.g. the AndroidKeyStore, Azure key vault, or AWS KMS providers.
However, since you are using the ASN.1 sequence from
PrivateKey.getEncoded()
to get information about the private key such as the algorithm etc that would have to be done in some other way since the method returns null for such private keys.PrivateKey.getFormat()
also returns null for such keys as it refers to the format of the encoded key.PrivateKey.getAlgorithm()
(link) will return one of the standard algorithm names as defined here.I think this would be a nice feature to have. But I don't understand this code base enough and the features it needs to have if it is feasible to support this for the generic case, right now I have a workaround where I have implemented signing using unexportable private keys myself.
The text was updated successfully, but these errors were encountered: