COSE key deserialization assumes map order

[robin-nitrokey]

The Deserialize implementations for the types in the cose module assume a specific order of the elements of the map.

Minimal example:

const DATA: &str = "a42001215820babc05993673d3d9745712333373cc6da964b4814d0cd666ce97c5ffef8befa522582029ebc161c05e3ba0f702a4cf1df30aca224ae3cf7b9478f4a811726976908ef00102";

use ciborium::de::from_reader;
use ctap_types::cose::EcdhEsHkdf256PublicKey;

fn main() {
    let data = hex::decode(DATA).unwrap();
    println!("{:?}", from_reader::<EcdhEsHkdf256PublicKey, _>(data.as_slice()));
}

Expected:

Ok(_)

Actual:

Err(Semantic(None, "missing field `kty`"))

Side note: Why are the traits implemented manually and not derived?

[nickray]

Same comment as in #8, CTAP2 canonical CBOR encoding form is required by the standard. Although the implementation may or may not be wrong for specific types.