CODEWITHSUNDEEP
javascriptgoogle-chromecryptographydomexception
saintthor
saintthor

Reputation: 41

crypto.subtle.importKey in Chrome throws a DOMException, while Firefox works well

I'm trying to import an ECDSA public key as follows:

ua8 = new Uint8Array( [48, 86, 48, 16, 6, 4, 43, 129, 4, 112, 6, 8, 42, 134, 72, 206, 61, 3, 1, 7, 3, 66, 0, 4, 124, 78, 186, 4, 136, 215, 226, 113, 200, 80, 93, 199, 105, 63, 47, 60, 193, 162, 180, 226, 160, 164, 9, 183, 122, 42, 97, 201, 99, 128, 54, 227, 193, 220, 229, 75, 186, 223, 201, 227, 229, 159, 159, 67, 205, 3, 126, 74, 211, 202, 122, 66, 185, 150, 74, 152, 192, 177, 81, 155, 106, 237, 212, 146] );
crypto.subtle.importKey( "spki", ua8, { name: "ECDSA", namedCurve: "P-256", }, false, ["verify"] );

In Firefox, this works well, but in Chrome I get a DOMException.

I want it to work in both browsers. How can I fix it?

Upvotes: 2

Views: 2410

Answers (2)

oliverrr
oliverrr

Reputation: 11

Setting the keyUsages to [] should solve your problem. From my understanding, only the private key should have a 'usage'.

Upvotes: 0

Ilmari Karonen
Ilmari Karonen

Reputation: 50328

According to the Chromium WebCrypto documentation:

Chromium's WebCrypto implementation supports all of the key formats - "raw", "spki", "pkcs8", "jwk", with the following caveats:

  • There are differences in DER key format handling between Web Crypto implementations. Where possible for compatibility prefer using "raw" keys or "jwk" which have better interoperability.
  • When importing/exporting "spki" and "pkcs8" formats, the only OIDs supported by Chromiumare those recognized by OpenSSL/BoringSSL.

in particular, it says that:

  • Importing ECDH keys does not accept id-ecDH. The OID must instead be id-ecPublicKey (This can cause problems importing keys generated by Firefox; use "raw" EC keys as a workaround; Chromium in this case is not spec compliant)

(The bug tracker link is giving me a 500 Internal Server Error, but that might be temporary.)

Looking at your key in an ASN.1 decoder, it contains the following data:

SEQUENCE (2 elem)
    SEQUENCE (2 elem)
        OBJECT IDENTIFIER 1.3.132.112
        OBJECT IDENTIFIER 1.2.840.10045.3.1.7 prime256v1 (ANSI X9.62 named elliptic curve)
    BIT STRING (520 bit) 0000010001111100010011101011101000000100100010001101011111100010011100…

The object identifier 1.3.132.112 is precisely the "id-ecDH" identifier that Chrome does not recognize. For what it's worth, a key exported from Chrome instead has the OID 1.2.840.10045.2.1 ("ecPublicKey").

As the linked documentation page suggests, as a workaround you may wish to switch from the "spki" format to "raw" (or to "jwk", which is JSON-based).

Upvotes: 4

Related Questions