Summary:
Always replace attestation statements with a "none" attestation.
Bug 1430150 will introduce a prompt that asks the user for permission whenever
the RP requests "direct" attestation. Only if the user opts in we will forward
the attestation statement with the token's certificate and signature.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1416056
Differential Revision: https://phabricator.services.mozilla.com/D567
webauthn says[1] that public keys are encoded as COSE keys. I find the COSE
RFC quite circuitous in many respects and so any reviews should check whether
they agree with my understanding of what should be in a COSE key.
The webauthn spec says that the key:
“MUST contain the "alg" parameter and MUST NOT contain
any other optional parameters.”
I don't believe that any of the parameters included are optional but, again, I
don't think the RFC is completely clear.
[1] https://www.w3.org/TR/webauthn/#sec-attested-credential-data
MozReview-Commit-ID: 2023mW3yVWU
--HG--
extra : rebase_source : 21d84d67f19d1885b73473a4d77d15f6c4cd80c2
The WD-06 (and later) WebAuthn specs choose to move to integer algorithm
identifiers for the signatures [1], with a handful of algorithms identified [2].
U2F devices only support ES256 (e.g., COSE ID "-7"), so that's all that is
implemented here.
Note that the spec also now requires that we accept empty lists of parameters,
and in that case, the RP says they aren't picky, so this changes what happens
when the parameter list is empty (but still aborts when the list is non-empty
but doesn't have anything we can use) [3].
There's a follow-on to move parameter-validation logic into the U2FTokenManager
in Bug 1409220.
[1] https://w3c.github.io/webauthn/#dictdef-publickeycredentialparameters
[2] https://w3c.github.io/webauthn/#alg-identifier
[3] https://w3c.github.io/webauthn/#createCredential bullet #12
MozReview-Commit-ID: KgL7mQ9u1uq
--HG--
extra : rebase_source : 2a1767805779a9f8049102723011193f113f0713
WebAuthn has added a flag UV to indicate the user was biometrically verified. We
have to make sure not to set that flag for U2F. Turns out we already do that,
but let's add the constant and such.
Ref: https://w3c.github.io/webauthn/#authenticator-data
MozReview-Commit-ID: 6Qtjdkverls
--HG--
extra : rebase_source : 660348596b917d8f461b19298e01dbe19410b63f
There's an intermittent which might be spurious because ASN.1 signatures might
sometimes be less than 70 bytes, but the actual floor is probably 68 (32 + 32
+ 4).
It's a sanity check, so I've adjusted it down and also am now emitting the
offending key bytes if this triggers again.
MozReview-Commit-ID: 1wwU9Q3BUPF
--HG--
extra : rebase_source : 2877deb770f8bf4bcf31dae40f75016892dc9d53
The Web Authentication types, by spec, return ArrayBuffer objects, while we
were returning a concrete Uint8Array. This is a fairly straightforward change
to add functionality to CryptoBuffer and the WebIDL types, however it's a
substantial change to the tests.
Frankly, the tests just could use another pass of clean-up now, since this is
a lot of relative ugliness added in. I refactored tab_webauthn_success.html
pretty heavily -- since it was also fairly ugly to start -- but I decided to go
with a lighter touch on the other tests.
MozReview-Commit-ID: 9vb1wdLo3SI
--HG--
rename : dom/webauthn/tests/browser/frame_webauthn_success.html => dom/webauthn/tests/browser/tab_webauthn_success.html
extra : rebase_source : bd2bc326c6bb5e00929b14c7aae66eba335c0605
Mark Banner
Victor Porof
J.C. Jones
Tim Taubert
Adam Langley
Kyle Machulis