Open mmartinv opened 4 months ago
We should consider: https://docs.rs/cose-rust/latest/cose/
@puiterwijk do you remember if there were specific features we needed as to why we chose aws-nitro-enclaves-cose crate when we implemented this?
@nullr0ute because we needed a cose library that uses OpenSSL for the crypto. And this was basically the only one that was at least somewhat mature at the time that I could find.
Good point @puiterwijk , at this point in time cose-rust
also uses rust-openssl
, so we should be good FIPS-compliance wise too.
We should consider: https://docs.rs/cose-rust/latest/cose/
So digging into "cose-rust" a little there seems to be two projects by the same name.
The first is here and is the one that comes up in crates.io here, I have concerns about that as the last release was 6 years ago and it uses NSS (not openssl).
The second is here and appears to be the one referenced above as they are both at release 0.1.7 (although not tagged in github). It seems it's a thesis project so I am not sure how responsive they will be on bugs and even if it will continue to be developed post thesis.
In both cases I have concerns about support looking forward, are there other possibilities?
@nullr0ute I've found this one from Google: coset, it might be more stable, but we'll need to investigate further to check if it suits our needs. I've seen references to EC and RSA keys in the code-
@7flying @nullr0ute If we are concerned about which Rust crate to use re: OpenSSL support, could we reach out to either the crypto team or the Rust team within Red Hat about this?
@7flying @nullr0ute If we are concerned about which Rust crate to use re: OpenSSL support, could we reach out to either the crypto team or the Rust team within Red Hat about this?
So we know from that team we need something that supports OpenSSL for the underlying crypto. The problem here is actually finding a COSE crate that 1) supports the features we need 2) has an active upstream community maintaining it.
So we know from that team we need something that supports OpenSSL for the underlying crypto. The problem here is actually finding a COSE crate that 1) supports the features we need 2) has an active upstream community maintaining it.
Right, I'm suggesting they may already know of one and could save us some research.
List of functions to change/refine:
COSE SignInner::new
COSESignInner::new_with_protected
COSESIgninner::serialize_data
COSESIgninner::verify_signature(SigningPublicKey)
COSESIgninner::get_payload
COSESIgninner::get_protected_and_payload
COSESIgninner::get_unprotected
on top of that serialize_data
needs to implement the low-level serde::Serialize
, but coset internally uses ciborium, so rather than implementing that trait, we need to switch from serde_cbor to ciborium.
Currently the library used to handle COSE signatures supports EC keys only, we need to support also RSA keys to be conformant with the FIDO specification.