Chrome 中的 crypto.subtle.importKey 抛出 DOMException，而 Firefox 运行良好答案

【问题标题】：crypto.subtle.importKey in Chrome throws a DOMException, while Firefox works wellChrome 中的 crypto.subtle.importKey 抛出 DOMException，而 Firefox 运行良好
【发布时间】：2017-08-25 02:24:08
【问题描述】：

我正在尝试按如下方式导入 ECDSA 公钥：

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"] );

在 Firefox 中，这很好用，但在 Chrome 中我得到一个 DOMException。

我希望它在两种浏览器中都能正常工作。我该如何解决？

【问题讨论】：

感谢您编辑文本。我不是一个好的英语作家。

标签： javascript google-chrome cryptography domexception

【解决方案1】：

根据the Chromium WebCrypto documentation：

Chromium 的 WebCrypto 实现支持所有密钥格式 - “raw”、“spki”、“pkcs8”、“jwk”，但有以下注意事项：

Web Crypto 实现之间的 DER 密钥格式处理存在差异。在可能的情况下，最好使用具有更好互操作性的“原始”密钥或“jwk”。

导入/导出“spki”和“pkcs8”格式时，Chromium 支持的唯一 OID 是 OpenSSL/BoringSSL 可识别的 OID。

特别是，它说：

正在导入 ECDH 密钥 does not accept id-ecDH。 OID 必须改为 id-ecPublicKey（这可能会导致导入 Firefox 生成的密钥出现问题；使用“原始”EC 密钥作为解决方法；在这种情况下，Chromium 不符合规范）

^{（错误跟踪链接显示 500 Internal Server Error，但这可能是暂时的。）}

Looking at your key in an ASN.1 decoder，它包含以下数据：

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…

对象标识符 1.3.132.112 正是 Chrome 无法识别的“id-ecDH”标识符。值得一提的是，a key exported from Chrome 的 OID 为 1.2.840.10045.2.1（“ecPublicKey”）。

正如链接文档页面所建议的那样，作为一种解决方法，您可能希望从“spki”格式切换到“raw”（或基于 JSON 的 "jwk"）。

【讨论】：