- From: Ryan Sleevi <sleevi@google.com>
- Date: Fri, 28 Nov 2014 12:01:16 +0100
- To: Richard Barnes <rlb@ipv.sx>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CACvaWvZcVpqFVVhSf83tm739aG=DAwT94xjW+HnDufb0v+WvxA@mail.gmail.com>
On Fri, Aug 15, 2014 at 9:01 PM, Richard Barnes <rlb@ipv.sx> wrote: > Couple of questions about the "raw" import format for EC keys. > > 1. Is there a better / more free reference than X9.62 available? It would > really be better if every implementor didn't have to purchase a copy from > ANSI. > http://www.secg.org/ e.g. ECDH is Section 3.3 of SEC1 > > 2. The specification currently does not require validation that the > provided octet string actually represents a point on the curve. If X9.62 > does such a check (not having a copy, I don't know), then it seems like > there should be spec language on what to do if the check fails. > > --Richard > > That requires that the input be valid. Section 3.2.2 describes the "Full Validation" algorithm. Considering that Section 3.3 dictates the parameters are valid, then an implementation that accepts keys which it does not know are valid apriori should execute the Section 3.2.2 algorithm to validate the parameters. As far as spec language, are you suggesting that the spec needs to explicitly incorporate a validate step? It would seem unnecessarily overkill given the language of 3.3 requiring the points be valid, which implicitly (and, at least in SEC1, is spelled out as necessary) incorporates validation as part of the "success or failure" of the algorithm.
Received on Friday, 28 November 2014 11:01:43 UTC