(In reply to Adam Langley from comment #0) > Using the Nightly build, below is a dump of the response.attestationObject > from a webauthn enrollment. As specified, it's a CBOR map. However the first > key is 686175746844617461 (i.e. "authData") which is followed by 63666d74 > ("fmt"). > > However, the CTAP2 spec says that "If two keys have different lengths, > the shorter one sorts earlier". The spec also says that "Sorting is performed on the bytes of the representation of the key data items". And later: "If the major types are different, the one with the lower value in numerical order sorts earlier." "fmt" is of major type 3 == "text string". "authData" is of major type 2 == "byte string". So, isn't it correct that "authData" sorts earlier than "fmt"? Our "attStmt" map isn't sorted correctly, IIUIC. The byte string(2) "sig" should sort earlier than the array(4) "x5c".
Sorry, disregard what I said. I didn't realize one is supposed to compare the whole map item and its entire length. So you're of course right and "fmt" needs to be sorted earlier in the above example. Our CBOR encoder is rather simple and we'd have to sort maps ourselves. We'll have to swap it out and extend/use our Rust library.
> I didn't realize one is supposed to compare the whole map item and its entire length. The spec for the CBOR canonicalisation is here: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd-20170927.html#message-encoding (It's similar, but not the same, as the RFC rules: https://tools.ietf.org/html/rfc7049#section-3.9) The CTAP2 document says to sort *keys* by major type, then length, then lexically. So I believe that this list of keys would be considered to be correctly ordered: 1 256 -1 -256 "z" "abc" The CBOR RFC rules say "Sorting is performed on the bytes of the representation of the key data items without paying attention to the 3/5 bit splitting for major types." I think that's saying that you only consider the serialised keys, not the whole key+data pair, same as the CTAP2 document. (I.e. it's "key data-items", not "key-data items".) Unfortunately the CTAP2 sort order is different(!) because the RFC sorts by length before (implicitly) sorting by major type. Thus I think the items above would be in this order under the RFC rules: 1 -1 -256 "z" 256 "abc" (I mention the RFC rules only for completeness. I believe the CTAP2 rules control here.) There is an added complication if one considers that keys in a CBOR map may have one or more optional tags preceding them. I'm just assuming that tags aren't going to be used in webauthn CBOR to keep things simple.
Comment on attachment 8939264 [details] Bug 1420760 - order webauthn CBOR map keys; https://reviewboard.mozilla.org/r/209692/#review215414 Simple; that works. Thanks!
Attachment #8939264 - Flags: review?(jjones) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/f94505f76fa4 Order webauthn CBOR map keys. r=jcj
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox59: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.