Fix #95, correct key ordering for CBOR encoding

[AlfioEmanueleFresta]

See #95 for more context.

CTAP canonical CBOR encoding requires map keys to be sorted from shorter key-length, to longer key-lenght.

No trivial root-cause fix due to serde_cbor, but thankfully the CBOR data structures with string keys in libwebauthn are limited.

Added tests to prevent regressions.

Test vectors

As decoded by cbor.me.

Ctap2CredentialType

A2                         # map(2)
   63                      # text(3)
      616C67               # "alg"
   26                      # negative(6)
   64                      # text(4)
      74797065             # "type"
   6A                      # text(10)
      7075626C69632D6B6579 # "public-key"

Ctap2PublicKeyCredentialDescriptor

A2                         # map(2)
   62                      # text(2)
      6964                 # "id"
   41                      # bytes(1)
      42                   # "B"
   64                      # text(4)
      74797065             # "type"
   6A                      # text(10)
      7075626C69632D6B6579 # "public-key"

[Copilot]

Pull Request Overview

This PR fixes issue #95 by adjusting the serialization order of map keys to meet CTAP canonical CBOR encoding requirements.

• Reorders fields in Ctap2CredentialType and Ctap2PublicKeyCredentialDescriptor so that keys are sorted by string length.
• Adds regression tests to validate proper CBOR serialization.
• Updates the hex dependency version in Cargo.toml.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
libwebauthn/src/proto/ctap2/model.rs	Reordered struct fields and added tests to enforce canonical CBOR ordering.
libwebauthn/Cargo.toml	Bumped the hex dependency version from 0.4.2 to 0.4.3.

Comments suppressed due to low confidence (1)

libwebauthn/Cargo.toml:44

• The hex dependency update to version 0.4.3 should be verified for compatibility with the rest of the dependency graph.

+hex = "0.4.3"

[AlfioEmanueleFresta]

Sadly this is nonsense, the change does exactly what the comment states, and the code suggestion reverses it.

[msirringhaus]

LGTM!