New issue
Advanced search Search tips
Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 389400
Owner:
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Chrome cannot import public ECDH key generated in Firefox exported via SPKI

Reported by renthra...@gmail.com, Sep 17 2015 Back to list

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36

Steps to reproduce the problem:
gen.htm is the code used to generate the keys

import.htm is the test to import, with embedded ECDH public keys generated in Firefox Nightly (43.0a1 (2015-09-16))

What is the expected behavior?
Successfully import the key.

What went wrong?
Uncaught (in promise) DOMException 

Did this work before? No 

Chrome version: 46.0.2486.0   Channel: dev
OS Version: Ubuntu 15.04
Flash Version:
 
import.htm
1.5 KB View Download
gen.htm
615 bytes View Download
Cc: davidben@chromium.org eroman@chromium.org
Labels: Cr-Blink-WebCrypto

Comment 2 by eroman@chromium.org, Sep 17 2015

Owner: eroman@chromium.org
Status: Assigned

Comment 3 by eroman@chromium.org, Sep 17 2015

Thanks for the report.

BoringSSL does not recognize OID id-ecDH, which is what Firefox uses for its exported ECDH keys (and is also what the WebCrypto spec says to do, so they are correct to do so).

Chromium however will only recognize id-ecPublicKey.

I have bugs on file talking about this equivalent issue for RSA algorithms, and this limitation was discussed when writing the code.

This is something I need to address.

In the meantime as a workaround you may need to use JWK.

There are ways as well to do a manual transformation of the key exported from Firefox to get it to import in Chrome. It isn't as simple as just a string replace, since the length of the two OIDs is different.
Yeah, as I discovered. Hance the thought that raw exports would be more compatible.

Am using a fixed binary message format, as have multiple ECDH public keys per message.

There are other issues preventing cross browser crypto atm anyways. The only common KDF implementation between Firefox and Chrome is PBKDF2, which seems ill suited for deriving keys from DH/ECDH shared secrets. 

Will probably just implement a raw export/import shim for Chrome, as exporting the same ASN.1 data for each key makes little sense.




Comment 5 by eroman@chromium.org, Sep 17 2015

If you run into other compatibility bugs between browsers please file them as that feedback is helpful.

Comment 6 by tkent@chromium.org, Sep 18 2015

Labels: -Cr-Blink-JavaScript
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

-Anthony
Labels: -OS-Linux -Hotlist-Recharge OS-All

Comment 9 by mmi...@gmail.com, Mar 21 2016

I opened a related bug for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1258330

There seems to be a big of confusion about which OID to really use:

https://bugzilla.mozilla.org/show_bug.cgi?id=1250810
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29539

Does Chromium (BoringSSL) maybe support 1.3.132.1.12 as an OID? That one is defined in the RFC 5480 standard.

Anyway, this bug is really problematic. At https://github.com/RocketChat/Rocket.Chat we hit it when we were implementing our OTR implementation. It is really complicated to do cross-browser compatible crypto.
No, Chromium only supports id-ecPublicKey.

The support for ASN.1 key formats is being discussed by the working group, since these sorts of compatibility issues are definitely a problem.

My best recommendation to you right now is to use the JWK key format if you want cross browser compatibility.

Comment 11 by mmi...@gmail.com, Mar 21 2016

Problem is that other tools (like OpenSSL) do not really support JWK.

Comment 12 by mmi...@gmail.com, Mar 21 2016

> The support for ASN.1 key formats is being discussed by the working group

Hm, but 1.3.132.1(.)12 is clearly specified in current web crypto standard as one to be used? Not sure what further discussion are you referencing here? To add even more OIDs? Like support the id-ecPublicKey?

As a matter of fact, Firefox supports both standard 1.3.132.1(.)12 and id-ecPublicKey. So in some way it is lenient in the output (reads both) but strict in the output (outputs based on the current standard).

I think Chromium should do the same.
Support for ASN.1 key formats has been suggested to be removed. As Eric mentioned, the best recommendation for interoperability is to use JWK, until these issues can be resolved and the proper direction for implementations decided. Until that's decided in the WG, there are no plans to change Chromium's implementation.
> Problem is that other tools (like OpenSSL) do not really support JWK.

OpenSSL doesn't support id-ecDH (1.3.132.1.12) either, by the way. That's actually where BoringSSL not supporting it comes from. Support for id-ecDH is rather rare. We could probably add it, though, as Ryan mentioned, this is kind of up in the air at the WG right now.
Mergedinto: 389400
Status: Duplicate (was: Assigned)

Sign in to add a comment