Re: Questions over Firefox's implementation

Thank you for pointing out, I'll take a look into it.

Regards,
Noji

2017-08-10 0:44 GMT+09:00 Mike Jones <Michael.Jones@microsoft.com>:
> RFC7518 is not "hard coded" to support three specific curves (P-256, P-384,
> and P-521). It uses the IANA JOSE Algorithms and Curves registries to enable
> algorithm ability. For instance, you’ll also find the 25519 and 448 curves
> there.
>
>
>
> – Mike
>
>
>
>
>
> From: Yoshikazu Nojima
> Sent: Wednesday, August 9, 2017 7:46 AM
> To: public-webauthn@w3.org
> Subject: 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 Thursday, 10 August 2017 15:45:44 UTC