W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2017

Re: Questions over Firefox's implementation

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Mon, 7 Aug 2017 18:48:21 -0700
To: "J.C. Jones" <jc@mozilla.com>, W3C Web Authn WG <public-webauthn@w3.org>
Message-ID: <6b046dc3-a8e4-fe9f-fb0b-4a02d5947161@KingsMountain.com>
On 8/7/17, 8:44 AM, "J.C. Jones" <jc@mozilla.com> wrote:
 >
 > Firefox had a bug filed against our WebAuthn U2F Attestation mode
 > over the weekend (Bug 1387820) [0] about the assertion signature. It
 > notes two issues:>
 > 1.	The Assertion.Response.Signature field actually contains the
 >       flags byte, the counter, and then the signature, and
 >
 > 2.	The signature is ASN.1 encoded rather than per RFC7518
 >
 > Regarding #1:
 >
 > Reading Section 7.6 of WD-05,

[ note: your link to WD-05 [1] is actually to the "currrent" webauthn 
spec and so will point to WD-06 rather than WD-05 real soon now... ]


 > the signing procedure says we should generate a signature per the
 > FIDO U2F formats and set that to sig.

S 7.6 of WD-05 is the U2F attestation signing procedure for webauthn. 
However, the submitted bug [0] is regarding the assertion signature (as 
the submitter has subsequently pointed out).


 > Regarding #2:
 >
 > Even when changing to COSE-derived algorithm names, I guess we'd run
 > the confusion of what format this gets encoded in.

yeah, unless we clearly document what's going on.


 >  I'm guessing we still want it to be ASN.1?

Perhaps, if we wish ECC curve agility (the sizes of the signature value 
components vary according to curve and signature hash alg). In 
comparison, RFC7518 is "hard coded" to support three specific curves 
(P-256, P-384, and P-521) and the length of the signature value 
components is pre-calculated in the spec, so that spec just relies on 
encoding the signature value as a concatenation of known-length sig 
value components {r,s} (no DER required).

so if one wants to have curve agility for any given curve in the future 
(I'm not advocating that here), one likely needs a sig value encoding 
that is self-describing wrt component lengths. DER-encoded ASN.1 seems 
to be commonly used for this [4] (tho a more compact encoding could be 
devised).

 > I'm asking before opening issues because I could absolutely just be
 > in the wrong here. Let me know what you think, and feel free to open
 > issues if you agree we should make changes to the spec.

In looking into this, it seems that webauthn is under-specified WRT the 
assertion format returned by an underlying U2F authenticator (note: i'm 
not referring to attestation format, and verification thereof, here -- 
that's nominally specified).  So at least one issue indicating that we 
ought to flesh this out (or is/was it supposed to be in a separate 
spec?) may be good to submit, if I'm understanding this correctly.
HTH,

=JeffH

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1387820

[1] webauthn WD-05
     https://www.w3.org/TR/2017/WD-webauthn-20170505/

[2] https://www.w3.org/TR/2017/WD-webauthn-20170505/#fido-u2f-attestation

[3] https://tools.ietf.org/html/rfc7518#section-3

[4] 
<https://crypto.stackexchange.com/questions/1795/how-can-i-convert-a-der-ecdsa-signature-to-asn-1#1797>
Received on Tuesday, 8 August 2017 01:49:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:26 UTC