Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The webauthn spec mandates that relying party identifiers (RP IDs) are valid
domain strings. This enforces that by ensuring that any passed-in RP IDs parse
correctly when set as the host portion of a URL.
https://w3c.github.io/webauthn/#relying-party-identifier
--HG--
extra : rebase_source : 6be22c9be660db3062f4e8119051cd122bc24a12
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
Late-breaking rename pre-CR in Web Authentication [1] renamed a dictionary. It's
not an interop issue, really, which must be why it was let through. This is a
WebIDL and Web Platform Tests-only issue. (The WPT updates are happening at
Github [2])
[1] https://github.com/w3c/webauthn/pull/779/files
[2] https://github.com/w3c/web-platform-tests/pull/9237
MozReview-Commit-ID: KEIlqIYbzKp
--HG--
extra : rebase_source : 4204ea62a41f374a6731a9367552af122d354145
The Web Authentication CollectedClientData is missing the type field, which
is just a simple string. (The editor's draft also removes hashAlgorithm, but
let's not get ahead of ourselves...)
Add in that simple string. This was found at interop testing.
MozReview-Commit-ID: DlawLyHTYhB
--HG--
extra : rebase_source : 6cdd8e14161dc4aea5bfd1baf60c7384219ba951
The WebAuthn spec lets RPs ask to specifically get direct attestation certificates
during credential creation using the "Attestation Conveyance Preference" [1].
This change adds that field into the WebIDL and ignores it for now. This is
pre-work to Bug #1430150 which will make this useful (which in turn requires
Bug #1416056's support for anonymizing those attestation certificates).
[1] https://www.w3.org/TR/webauthn/#attestation-convey
MozReview-Commit-ID: 763vaAMv48z
--HG--
extra : rebase_source : 7fb7c64a0ee3167032485378af6074a7366295a4
Summary:
Add support for PublicKeyCredentialRequestOptions.userVerification. For now
this basically means that we'll abort the operation with NotAllowed, as we
don't support user verification yet.
Pass PublicKeyCredentialDescriptor.transports through to the token manager
implementations. The softoken will ignore those and pretend to support all
transports defined by the spec. The USB HID token will check for the "usb"
transport and either ignore credentials accordingly, or abort the operation.
Note: The `UserVerificationRequirement` in WebIDL is defined at https://w3c.github.io/webauthn/#assertion-options
Reviewers: jcj, smaug
Reviewed By: jcj, smaug
Bug #: 1406467
Differential Revision: https://phabricator.services.mozilla.com/D338
--HG--
extra : amend_source : 314cadb3bc40bbbee2a414bc5f13caed55f9d720
Summary: We can probably abstract more stuff in the future, but this seems like a good start.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1396907
Differential Revision: https://phabricator.services.mozilla.com/D323
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
Summary:
We currently call ChildActor.send__delete() when clearing an active transaction
and thereby destroy the child actor. If that happens, e.g. due to a tab switch,
while a message is in the IPC buffer waiting to be delivered, we crash.
This patch creates the child actor lazily as before, but keeps it around until
the WebAuthnManager goes away, which will be at process shutdown.
Each transaction now has a unique id, that the parent process will include in
any of the ConfirmRegister, ConfirmSign, or Abort messages. That way we can
easily ignore stale messages that were in the buffer while we started a new
transaction or cancelled the current one.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1403818
Differential Revision: https://phabricator.services.mozilla.com/D149
Summary:
With both managers storing transaction infos in `Maybe<Info> mTransaction` now,
it occurred to me that we can't actually assert that
`mTransaction.isSome() == true` when we receive a message.
At least with the U2F API the request could be cancelled (and mTransaction
cleared) while there's a pending completion message. For WebAuthn it probably
doesn't hurt to handle this properly either.
(As a bonus, I snuck in the removal of an unused enum.)
Reviewers: jcj
Reviewed By: jcj
Bug #: 1410428
Differential Revision: https://phabricator.services.mozilla.com/D145
Summary:
This patch aims to clean up the WebAuthnManager's state machine, especially
to make cancellation of transactions clearer. To fix bug 1403818, we'll have to
later introduce a unique id that is forwarded to the U2FTokenManager.
There are multiple stages of cancellation/cleanup after a transaction was
started. All of the places where we previously called Cancel() or
MaybeClearTransaction() are listed below:
[stage 1] ClearTransaction
This is the most basic stage, we only clean up what information we have about
the current transaction. This means that the request was completed successfully.
It is used at the end of FinishMakeCredential() and FinishGetAssertion().
[stage 2] RejectTransaction
The second stage will reject the transaction promise we returned to the caller.
Then it will call ClearTransaction, i.e. stage 1. It is used when one of the
two Finish*() functions aborts before completion, or when the parent process
sends a RequestAborted message.
[stage 2b] MaybeRejectTransaction
This is the same as stage 2, but will only run if there's an active transaction.
It is used by ~WebAuthnManager() to reject and clean up when we the manager
goes away.
[stage 3] CancelTransaction
The third stage sends a "Cancel" message to the parent process before rejecting
the transaction promise (stage 2) and cleaning up (stage 1). It's used by
HandleEvent(), i.e. the document becomes inactive.
[stage 3b] MaybeCancelTransaction
This is the same as stage 3, but will only run if there's an active transaction.
it is used at the top of MakeCredential() and GetAssertion() so that any
active transaction is cancelled before we handle a new request.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409434
Differential Revision: https://phabricator.services.mozilla.com/D132
Summary:
We can simplify and reduce the {WebAuthn,U2F}Manager code by removing these
methods and sending messages directly from closures.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1409357
Differential Revision: https://phabricator.services.mozilla.com/D131
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
This covers these renames:
* In CollectedClientData, hashAlg => hashAlgorithm
* In CollectedClientData, tokenBinding => tokenBindingId
* In MakePublicKeyCredentialOptions, parameters => pubKeyCredParams
* In MakePublicKeyCredentialOptions, excludeList => excludeCredentials
* In PublicKeyCredentialRequestOptions, allowList => allowCredentials
* Transport (WebAuthnTransport in Gecko) => AuthenticatorTransport
MozReview-Commit-ID: 3FdRnkosy83
--HG--
extra : rebase_source : 22f124c781b03837ad0cd4be4edf34527e3b9d38
This covers these renames:
* In PublicKeyCredentialParameters, algorithm => alg
* MakeCredentialOptions => MakePublicKeyCredentialOptions
* PublicKeyCredentialEntity => PublicKeyCredentialRpEntity
* Attachment => AuthenticatorAttachment
It sets a default excludeList and allowList for the make / get options.
It adds the method isPlatformAuthenticatorAvailable which is incomplete and
not callable, to be completed in Bug 1406468.
Adds type PublicKeyCredentialRpEntity.
Adds "userId" to AuthenticatorAssertionResponse.
Adds "id" as a buffer source to PublicKeyCredentialUserEntity and as a
DOMString to PublicKeyCredentialRpEntity, refactoring out the "id" field
from the parent PublicKeyCredentialEntity.
It also adds a simple enforcement per spec 4.4.3 "User Account Parameters for
Credential Generation" that the new user ID buffer, if set, be no more than
64 bytes long. I mostly added it here so I could adjust the tests all at once
in this commit.
MozReview-Commit-ID: IHUdGVoWocq
--HG--
extra : rebase_source : bc1793f74700b2785d2bf2099c0dba068f717a59
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
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: 6vgQiU8zN3o
--HG--
extra : rebase_source : 1b536b92ef43f610db057ace6f108620e8d8b4d5
extra : source : 336e21386d5eeb16f1c9893c29377f23b67cc4b0
The algorithm names provided to the WebAuthn methods have to either be a
string, or (potentially) a WebCrypto object. Right now we only work with
strings, but there's no good reason to assert that, we can just let the
action fail.
This patch removes the assert to help out the fuzzing team.
MozReview-Commit-ID: 9dc8m0a2gZK
--HG--
extra : rebase_source : 649a7f4928679405fe445ac533eee2cfccaedd25
- This patch reworks the U2F module to asynchronously call U2FManager,
which in turn handles constructing and managing the U2FTokenManager
via IPC.
- Add U2FTransaction{Parent,Child} implementations to mirror similar ones for
WebAuthn
- Rewrite all tests to compensate for U2F executing asynchronously now.
- Used async tasks, used the manifest parameters for scheme, and generally
made these cleaner.
- The mochitest "pref =" functionality from Bug 1328830 doesn't support Android
yet, causing breakage on Android. Rework the tests to go back to the old way
of using iframes to test U2F.
NOTE TO REVIEWERS:
Since this is huge, I recommend the following:
keeler - please review U2F.cpp/h, the tests, and the security-prefs.js. Most
of the U2F logic is still in U2F.cpp like before, but there's been
some reworking of how it is called.
ttaubert - please review U2FManager, the Transaction classes, build changes,
and the changes to nsGlobalWindow. All of these should be very
similar to the WebAuthn code it's patterned off.
MozReview-Commit-ID: C1ZN2ch66Rm
--HG--
extra : rebase_source : 5a2c52b0340c13f471af5040b998eb7e661b1981
In Bug 1380421 we reverted some behavior that required Web Authentication's
RP ID to be domain string to permit it to be an origin, too, for interop
testing. That is no longer needed, so this patch resumes enforcement that
RP ID be a domain string.
It also adds a needed test that the RP ID hash is calculated correctly.
MozReview-Commit-ID: 8dDjzo5kQKP
--HG--
extra : rebase_source : 65cd7b9f3a6ecfc58805daf102f33966c9b19b98
