Firefox 146 supports compressed ECC key point format #28497
Conversation
github-actions
bot
added
data:api
| "description": "ECDSA or ECDH key data can contain compressed elliptic curve points.", | ||
| "support": { | ||
| "chrome": { | ||
| "version_added": "≤80" |
There was a problem hiding this comment.
80 is the earliest version of chrome the the test I am using works for https://wpt.live/WebCryptoAPI/import_export/ec_importKey.https.any.html
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
| "opera": "mirror", | ||
| "opera_android": "mirror", | ||
| "safari": { | ||
| "version_added": false |
There was a problem hiding this comment.
Ran on latest safari 26 https://wpt.live/WebCryptoAPI/import_export/ec_importKey.https.any.html - the particular tests show up as optional and fail.
| }, | ||
| "chrome_android": "mirror", | ||
| "deno": { | ||
| "version_added": false |
There was a problem hiding this comment.
Can't find information on node or deno so have set as false.
| "description": "ECDSA or ECDH key data can contain compressed elliptic curve points.", | ||
| "support": { |
There was a problem hiding this comment.
Isn't there any spec section that we could link?
There was a problem hiding this comment.
It seems that support for compressed points is not mandatory, see: https://w3c.github.io/webcrypto/#:~:text=The%20uncompressed%20point%20format%20MUST%20be%20supported%2E
From BCD's point of view, this would warrant setting standard_track: false.
There was a problem hiding this comment.
Really? That makes no sense to me.
There was a problem hiding this comment.
@hamishwillee If you come to the same conclusion as me looking at the phrasing in the spec, would you like to file a spec issue asking for clarification?
There was a problem hiding this comment.
@caugner Sorry for the delay - went away for a few days.
Yes, support for compressed points is not mandatory - I don't think there is any doubt about that and I wouldn't request clarification.
The bit I don't understand is this:
From BCD's point of view, this would warrant setting standard_track: false.
It doesn't make sense to me that something not being mandatory means that it is "not on the standards track" - in particular because the behaviour when EC uncompressed points are discovered is explicitly and clearly documented in the spec at the point you linked.
There was a problem hiding this comment.
So assuming you agree and I just wasn't clear about my confusion originally, I added the spec url in a380a85
There was a problem hiding this comment.
Let's get a second opinion from @ddbeck here.
My understanding is we treat non-mandatory and non-normative features in BCD as non-standard, as if it wasn't described at all. The most recent case might have been this input picker UI behavior.
However, we only mention "mandatory specified behavior" in the partial implementation guidelines.
There was a problem hiding this comment.
Thank you. Obviously whatever the rules are we will follow.
There was a problem hiding this comment.
I read this bit of the spec:
If the implementation does not support the compressed point format and a compressed point is provided, throw a DataError.
to mean that a browser may support compressed points, but doesn't have to (unlike the uncompressed points). Therefore this is optional normative behavior and it's fine if this has a spec URL and "standard_track": true.
I'd expect these support scenarios for this feature:
- Accepts a compressed point → supported
- Throws a
DataError→ unsupported - Does anything else → partial implementation
| }, | ||
| "status": { | ||
| "experimental": false, | ||
| "standard_track": true, |
There was a problem hiding this comment.
To set standard_track: true, we should add a spec_url.
caugner
changed the title
Co-authored-by: Claas Augner <[email protected]>
| "deprecated": false | ||
| } | ||
| }, | ||
| "compressed_elliptic_curve_points": { |
There was a problem hiding this comment.
I was asked to respond to the spec question below, but I'm -0 on adding this subfeature. Speaking as a consumer of BCD (i.e., for web-features), this makes the data even harder to work with and, as written, is not something we can use to generate a status in web-features.
In a better world, this data would be represented as api.SubtleCrypto.importKey.ecdsa.compressed_elliptic_curve_points and api.SubtleCrypto.importKey.ecdh.compressed_elliptic_curve_points. But we don't have keys for ecdsa and ecdh, we just have notes in importKey feature. This makes the problem worse by creating a named subfeature to notes of the parent feature, not the parent feature itself.
I won't block on merging this—I do not have the time this month to do a rounds of follow up and re-review—but I think the addition of this subfeature makes the problem described in #27669 worse and I would like you to reconsider.
| "description": "ECDSA or ECDH key data can contain compressed elliptic curve points.", | ||
| "support": { |
There was a problem hiding this comment.
I read this bit of the spec:
If the implementation does not support the compressed point format and a compressed point is provided, throw a DataError.
to mean that a browser may support compressed points, but doesn't have to (unlike the uncompressed points). Therefore this is optional normative behavior and it's fine if this has a spec URL and "standard_track": true.
I'd expect these support scenarios for this feature:
- Accepts a compressed point → supported
- Throws a
DataError→ unsupported - Does anything else → partial implementation
3 participants
FF146 supports WebCrypto import of EC keys in compressed format in https://bugzilla.mozilla.org/show_bug.cgi?id=1971499
I've added as a subfeature of importKey
Related docs work can be tracked in mdn/content#41870