This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26741 - Reject invalid EC public keys
Summary: Reject invalid EC public keys
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-05 20:03 UTC by Richard Barnes
Modified: 2014-10-30 23:20 UTC (History)
3 users (show)

See Also:

Attachments

Description Richard Barnes 2014-09-05 20:03:16 UTC 
The specification for import of EC public keys (in ECDH and ECDSA) should require that the implementation return DataError if the point provided is not on the specified curve.
Comment 1 Mark Watson 2014-09-20 00:35:48 UTC 
Is this another one where the error may be detected in a library which does not return sufficiently granular error information, so this just becomes OperationError ?
Comment 2 Mark Watson 2014-09-25 23:11:40 UTC 
Could someone more familiar with the cryptographic libraries browsers are using (or might use) comment on whether APIs are available to check whether a supplied point is valid ?

Or might this only be discovered when you try to perform an operation with the key ?
Comment 3 vijaybh 2014-09-29 07:34:46 UTC 
Speaking for Microsoft's CNG implementations - ECC keys are validated on import unless the caller explicitly requests that they not be. So assuming a UA used our crypto implementation, and performed a CNG import when WebCrypto import was called, they would know at that point if the key was invalid.

I looked up the standards just now - the NIST standards for ECDSA and ECDH require validation of keys on import. X9.62 describes a key validation procedure but marks it optional.
Comment 4 Ryan Sleevi 2014-10-07 02:38:17 UTC 
NSS historically did not validate public keys on import, but would instead defer until their cryptographic use (which, due to API layering, was the _actual_ time that import into the cryptographic module was performed). In this case, the error would surface during the operational usage.

BoringSSL and OpenSSL both validate on input.

However, Richard recently fixed NSS (IIRC) to validate the public key on import. Richard, can you confirm?

Note that I have no clue for Safari's case, as they have a few different ECC implementations last I checked.
Comment 5 Mark Watson 2014-10-22 21:45:20 UTC 
Import is normalized to returning DataError. Since it was Richard who asked for this, presumably he knows NSS can do this check on import. I suggest we make the change as proposed.
Comment 6 Mark Watson 2014-10-30 16:31:25 UTC 
Agreed at f2f that we should validate EC public keys on import.
Comment 7 Richard Barnes 2014-10-30 16:32:08 UTC 
NSS does support this, and Firefox throws if you try to import an invalid key.