Add and prefer fully-specified COSE algorithm identifers in test vectors

[emlun]

(This meta-PR would merge into #2283, not directly to main)

As requested in #2283 (comment), this updates the test vectors section to primarily use fully-specified COSEAlgorithmIdentifiers (but still include examples of polymorphic ones). This also adds an Ed448 case since that was not previously expressible.

This relies on an unofficial version of python-fido2 since its latest official version (1.2.0) does not include support for the new fully-specified COSEAlgorithmIdentifiers.

---

Preview | Diff

[zacknewman]

Unfortunately, the ESP256 self attestation test is wrong. The signature is using ES256 and not ESP256:

attestationObject = h'a363666d74667061636b65646761747453746d74a263616c67266373696758473045022043e4bd627e3fd9bd97693afe46170224f2d32315d10c201224bcedadfd4dbf8e022100c912e38555682b78dabe8fa0bc7e5ca1d9a6a5eb09f3e04ccc2be5549b8d5dcd68617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5590000000073afadd5f7b1506f5634c8143fa1927a00203159ac06a08a84a3e9ce7df31b30bcdf9a5c0bea1012adfb639019f70b949b63a5010203282001215820fc174b413cfce26e45b8d9c7644eff7295ccf649ec88d6e93ef16a0763121555225820ff9848e0890d6efcda16145035e74d04d8eb088f27b213d0da5c27109d124ffb'

When we decode above, we get:

\xa3cfmtfpackedgattStmt\xa2calg&…

where non-ASCII is escaped with a leading \x and ASCII is left as is for readability. & corresponds to ASCII code point 38 (in decimal) that is the same value as CBOR -7 which is ES256. The header should instead look like:

\xa3cfmtfpackedgattStmt\xa2calg( where ( corresponds to the ASCII code point 40 (in decimal) which is the same value as CBOR -9 (i.e., ESP256).

I haven't checked the rest of the tests, but it wouldn't surprise me if some of them are also incorrect.

Making the above change leads to

attestationObject = h'a363666d74667061636b65646761747453746d74a263616c67286373696758473045022043e4bd627e3fd9bd97693afe46170224f2d32315d10c201224bcedadfd4dbf8e022100c912e38555682b78dabe8fa0bc7e5ca1d9a6a5eb09f3e04ccc2be5549b8d5dcd68617574684461746158a4bfabc37432958b063360d3ad6461c9c4735ae7f8edd46592a5e0f01452b2e4b5590000000073afadd5f7b1506f5634c8143fa1927a00203159ac06a08a84a3e9ce7df31b30bcdf9a5c0bea1012adfb639019f70b949b63a5010203282001215820fc174b413cfce26e45b8d9c7644eff7295ccf649ec88d6e93ef16a0763121555225820ff9848e0890d6efcda16145035e74d04d8eb088f27b213d0da5c27109d124ffb'

which leads to successful parsing and ceremony validation for both registration and authentication ceremonies from my library.

Specifically, the 25th byte (0-based index) needs to be 0x28 instead of 0x26 (i.e., the 51st (0-based index) hex character needs to be 8 instead of 6).

[emlun]

Thanks @zacknewman, good catch! It certainly makes sense that the self attestation case should use the same alg for the attestation object as in the credential key. But note that in general, the alg attribute of the attestation (when present) may be different from the alg of the credential public key. For example, all attestation statements in these test vectors use ESP256 (previously ES256) regardless of the credential key algorithm (this is mostly because EC keys are much easier to generate than RSA keys).

[zacknewman]

But note that in general, the alg attribute of the attestation (when present) may be different from the alg of the credential public key.

Of course. I was referring to self attestation specifically since the private key used to sign the payload is the same as the credential private key thus should use the same identifier (and the spec mandates that the identifier used be the same as the identifier used in the COSE key portion of the attested credential data). Thanks for the additional tests!

[emlun]

This is a meta-PR that doesn't merge directly to main, so now with PR #2289 merged I'll merge this into PR #2283.