This takes half the time of the signature validation process, and we
trust the key we're providing, so we shouldn't need to do this.
Plus, PK11_VerifyWithMechanism verifies the key again
(see bug 1770921).
Differential Revision: https://phabricator.services.mozilla.com/D147171
id-ecPublicKey is defined as the OID {iso(1) member-body(2) us(840)
ansi-x962(10045) keyType(2) ecPublicKey(1)}, and is the NSS default, so
remove the override code from CryptoKey.cpp that forced it to the legacy
id-ecDH code.
Differential Revision: https://phabricator.services.mozilla.com/D52570
--HG--
extra : moz-landing-system : lando
Bug 1034856 added support for DH algorithms to WebCrypto, however the final
specification did not choose to include them, making Firefox the only browser
with support.
Bug 1539578 added telemetry to show usage, and it is extremely low (not
appearing on the graphs), which could be expected as Firefox is the only
supporting browser.
Since DH is an ongoing maintenance burden -- and overall cryptanalysis of DH
is progressing -- let's remove it.
Notice to unship went to dev-platform on 29 March 2019 with no objections. [0]
[0] https://groups.google.com/d/msg/mozilla.dev.platform/Ut3-eQmUdWg/O9w1et1aBgAJ
Differential Revision: https://phabricator.services.mozilla.com/D50865
--HG--
extra : moz-landing-system : lando
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
The std::unique_ptr based UniqueX types provide better safety over managing raw
pointers.
MozReview-Commit-ID: EwwOfs6RHqy
--HG--
extra : rebase_source : 7fbfca837c09b641bfffcba854d46b3f79645c0d
ScopedAutoSECItem is useful for getting rid of this pattern:
> ScopedSECItem item(SECITEM_AllocItem(nullptr, nullptr, 0));
While this pattern works, ScopedAutoSECItem is slightly superior in that it
doesn't unnecessarily cause a SECItem to be allocated from the heap. Moreover,
this moves us further away from Scoped.h, which is deprecated.
MozReview-Commit-ID: B30MNTHzzTc
--HG--
extra : rebase_source : 8d6dea205fc8800a46104b48c670eff250a4731a
enum classes are in general safer than plain enums, and as such should be
preferred.
MozReview-Commit-ID: 1FK89SNhdk4
--HG--
extra : rebase_source : 764c4855026c02d8c9e33ca33637fec54ea5ca31
To import private keys, WebCrypto creates a generic PKCS#11 object with a chosen
key ID with PK11_CreateGenericObject and then looks up that object as a
SECKEYPrivateKey using PK11_FindKeyByKeyID. It turns out that this is only safe
to do as long as the ID is unique. If another SECKEYPrivateKey exists that has
the same key ID (realistically this will only happen if an identical key is
imported again), PK11_FindKeyByKeyID may return the other key. Since
SECKEYPrivateKey objects are unique and not meant to be shared, this causes
problems in that when one key is destroyed, the resources backing the other key
are no longer valid, and any cryptographic operations using that key will fail.
The solution is to use random IDs and check for preexisting keys. NSS doesn't
yet expose an elegant API for this, but this patch implements a workaround.
MozReview-Commit-ID: EvYMZxnBxTv
--HG--
extra : rebase_source : 50408e1af9eb3934b51a0f01e02aa4890e57ed03
Before this patch, CreateECPublicKey would create a SECKEYPublicKey allocated on
a scoped arena. It would then call CryptoKey::PublicKeyValid, which has the
side-effect of importing the key to the internal PKCS#11 slot. When the arena
went out of scope, the memory for the key would be released, but the reference
to the slot wouldn't, causing a leak.
This patch fixes the leak by making the SECKEYPublicKey a ScopedSECKEYPublicKey
(which ensures that the type-specific "destructor" SECKEY_DestroyPublicKey is
called, which releases the reference to the PKCS#11 slot).
--HG--
extra : rebase_source : 10ef3c0e6ade78ab8ec4c95464224ba2e38aa17b