鉴于spki导出了EC公钥(底部代码),Chromium&co给出了一个理智的ObjectID,但Firefox给出了一个完全不同的ObjectID:
0 86: SEQUENCE { 2 16: SEQUENCE { 4 4: OBJECT IDENTIFIER '1 3 132 112'wat 10 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 20 66: BIT STRING : 04 EB F3 46 9A 56 19 D6 76 36 23 3B 57 D4 01 25 : CD DD A4 BF 72 DF 51 C7 E7 AA 81 B9 04 5F DF 6B : CA 02 E4 3E 02 D1 44 57 65 EB 9E 36 C4 79 A6 F8 : 51 BB 2D 8F DC C4 42 B3 DB 8B A3 AF 57 F0 BF 7B : 35 : }
作为参考,以下是摘自Chromium的内容:
0 89: SEQUENCE { 2 19: SEQUENCE { 4 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)yes thank you 13 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 23 66: BIT STRING : 04 9D 16 97 2F 89 6F 9B 87 4B 86 0E F7 8F BB 98 : 37 E2 BF 75 7C 8E AD 1C A7 B4 5F 6D 75 72 90 FC : 8F 30 AF 91 4B AA 96 71 F3 52 6B 58 8F E0 27 92 : 13 12 77 D1 17 76 F3 3A FD ED A9 B1 1A 64 5E 5F : B1 : }
(通过dumpasn1
生成的转储)
确实,继续使用OID ref Chromium的标识符似乎很好。
Firefox的OID似乎属于another group entirely,我什至找不到它。
问题是,不同的OID会使各种导入崩溃。从Firefox以这种方式导出的密钥必须先更改才能导入OpenSSL甚至Chromium。
因此
以下是快速生成导出的EC公钥的代码段:
(async () => {
const subtle = crypto.subtle
const eckp = await subtle.generateKey({
name: 'ECDSA',
namedCurve: 'P-256'
}, true, ['sign', 'verify'])
const exportedPubK = new Uint8Array(await subtle.exportKey('spki', eckp.publicKey))
console.log(exportedPubK.length) // 88 for the weird OID, 91 otherwise.
console.log(`[${exportedPubK.join(', ')}]`)
})();
自this Firefox bug的解决和结束以来,这个问题已经过时。 Firefox 72应该不再显示此问题。
答案 0 :(得分:2)
原因是Firefox错误,分别参见Bug 1410403和Bug 1514032。
根据{{3}},公共ECDSA(或ECDH)密钥的正确OID为1.2.840.10045.2.1
。未定义OID 1.3.132.112
(类似的OID 1.3.132.1.12
仅限于ECDH,另请参见RFC 5480, section 2.1.1和RFC 5480, section 2.1.2)。