Open eighty4 opened 1 year ago
Maybe our pem decoder (https://github.com/Keats/jsonwebtoken/blob/master/src/pem/decoder.rs) doesn't work well in some cases? I don't know, I haven't touched that part in years
I have a similiar problem with the error message Error(InvalidKeyFormat)
I found this function with the comment:
/// Can only be PKCS8
pub fn as_ec_public_key(&self) -> Result<&[u8]> {
match self.standard {
Standard::Pkcs1 => Err(ErrorKind::InvalidKeyFormat.into()),
Standard::Pkcs8 => match self.pem_type {
PemType::EcPublic => extract_first_bitstring(&self.asn1),
_ => Err(ErrorKind::InvalidKeyFormat.into()),
},
}
}
As far as I know I can't convert a ec public key to the pkcs8
format. This seems to be a bug?
I believe I'm having a similar issue. I'm following basically the exact same steps as the above but the library is telling me InvalidEcdsaKey
when I try to sign a token. Did OpenSSL change the structure recently and now it's breaking the decoder?
I tried to use an ECDSA key generated by pulumi's privatekey resource and couldn't get it to work. Then I found that the library refuses to parse ECDSA keys in the PKCS#1 format, which apparently is what pulumi generates, as far as I understand it. There's this comment in the code:
// No "EC PRIVATE KEY"
// https://security.stackexchange.com/questions/84327/converting-ecc-private-key-to-pkcs1-format
// "there is no such thing as a "PKCS#1 format" for elliptic curve (EC) keys"
As I understand it, the PKCS#1 format was meant exclusively for RSA keys, and the library author has therefore decided not to support it for ECDSA keys. At the same time, I was able to parse the same key in .NET with no issues, so it seems that at least some other libraries/frameworks allow this format to be used for ECDSA keys.
Given that this format appears to be used for ECDSA keys out in the wild, and that other libraries support it, wouldn't it make sense to support it in jsonwebtoken as well?
@p-lindberg that sounds like a separate issue. My error was fixed by changing the elliptic curve and not the container.
Deep down in
ring::io::der::expect_tag_and_get_value
I always get an error bubbling up to an InvalidEcdsaKey. I think my brain melted trying to figure out the problem.This is how I'm generating keys:
Here's the private key:
Here's the key you use in tests:
I adapted your test and ran the test using the same curve your key uses and the curve I used based on a guide on Akamai and the test worked once I switched to prime256v1. I started typing this issue after an hour of debugging but found the fix while collecting all the details. Is there a reason one curve would work but not another? With the right info I'd like to document it so it doesn't trip up someone else.