Re: Questions over Firefox's implementation

Hello all,

I'm Yoshikazu Nojima, the reporter of the Firefox bug ticket about the
web authentication assertion signature implementation.
(See https://bugzilla.mozilla.org/show_bug.cgi?id=1387820)

Thank you for your responses, which improved my understanding of this
issue, and let me explain my current concerns about the assertion
signature.
(#1 is specific to Firefox implementation, but #2, and #3 relate to
the web authentication specification.)

#1 The Assertion.Response.Signature field actually contains the flags
byte, the counter, and then the signature

Firefox Nightly with the FIDO-U2F soft token option fills
authenticatorAssertionResponse.signature with the concatenation of
the flags byte, the counter, and the signature, which is the full
block copy of FIDO U2F Raw Message Formats' "Authentication Response
Message: Success".
https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html#authentication-response-message-success

W3C Web Authenticaon specification doesn't instruct to prepend the
flags byte and the counter to the "assertion" signature.
Sepalate authenticatorAssertionResponse.authenticatorData field is
designed to store the flags byte and the counter.
It seems Firefox's current behavior doesn't conform the web
authentication spec. The web authentication spec doesn't need to be
changed regarding this #1.


#2 The signature is ASN.1 encoded rather than per RFC7518

- The assertion signature that Firefox returns is encorded in ASN.1
(ANSI X9.62 format)
- FIDO U2F Raw Message Formats defines that the assertion signature is
encorded in ANSI X9.62 format
- If we wish ECC curve agility, RFC7518 is not a good option because
it is "hard coded" to support three specific curves (P-256, P-384, and
P-521)

So, it seems ANSI X9.62 format is the right option. I suppose it would
be helpful that the assertion signature format is explicitly specified
in the web authentication spec.

#3. What data is to be signed over?

I'd like to raise another issue relating the assertion signature by
FIDO-U2F authenticators.

The web authentication spec defines that the signature is generated
over the concatenation of the authenticator data and the hash of the
serialized client data
(See https://w3c.github.io/webauthn/#op-get-assertion), but
FIDO U2F Raw Message Formats defines that the signature is generated
over the following source:
- The application parameter [32 bytes] from the authentication request message.
- The above user presence byte [1 byte].
- The above counter [4 bytes].
- The challenge parameter [32 bytes] from the authentication request message.
(See https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html#authentication-response-message-success)

Since the signature calculation takes place in an authenticator with
the help of its private key, the source cannot be changed,
if we use FIDO U2F authenticators, I suppose we need to use this signature,
and it is necessary to define separate assertion
generation/verification procedure for FIDO U2F authenticators in the
web authentication spec.
(One more little concern: If FIDO-U2F assertion signature is used, the
authenticator data and the client data will not be signed. Is it ok
with the web authentication security model?)

Regards,
Noji

Received on Wednesday, 9 August 2017 14:45:59 UTC