Assertion signatures: raw or ASN.1 wrapped?

[dagnelies]

Currently, according to the specs https://w3c.github.io/webauthn/#sctn-signature-attestation-types , some authentication signatures are provided "raw" while others are "ASN.1" wrapped. This caused some difficulties, for example https://gist.github.com/philholden/50120652bfe0498958fd5926694ba354 because it is both unexpected and rather hidden in the specs.

6.5.6. Signature Formats for Packed Attestation, FIDO U2F Attestation, and Assertion Signatures

[...] For COSEAlgorithmIdentifier -7 (ES256) [...] the sig value MUST be encoded as an ASN.1 [...]
[...] For COSEAlgorithmIdentifier -257 (RS256) [...] The signature is not ASN.1 wrapped.
[...] For COSEAlgorithmIdentifier -37 (PS256) [...] The signature is not ASN.1 wrapped.

Moreover, what about the -8 algo that is also recommended? Is it provided ASN.1 wrapped or Raw?

Ideally, this information should also be cross referenced in some other sections, since it is critical for a proper verification of the signature. For example, either of https://w3c.github.io/webauthn/#sctn-op-get-assertion or https://w3c.github.io/webauthn/#sctn-verifying-assertion

Thanks

[MasterKale]

For what it's worth I just finished a big refactor of my SimpleWebAuthn library to use the WebCrypto JS API for signature verification. Testing against FIDO Conformance and the test cases that I'd accumulated using real responses, it was always responses with public keys with kty: 2 (EC2) that required the unwrapping of the raw signature bytes from an ASN.1 structure. Public keys that mapped to kty: 1 (OKP, almost always with alg -8 [Ed25519]) and kty: 3 required no such manipulation. For kty: 2 the unwrapping has needed to occur regardless of the key's alg.

[ve7jtb]

ES256 is inherited from U2F for backward compatibility. We can't change the wrapping for that alg.
It is already noted in the spec.

[MasterKale]

Turns out the ASN.1 wrapping for ECDSA signatures is for historical U2F reasons. The spec calls this out as such:

Note: As CTAP1/U2F authenticators are already producing signatures values in this format, CTAP2 authenticators will also produce signatures values in the same format, for consistency reasons.

Given this context, there's not really anything to be done here without risking breaking compatibility with U2F authenticators.