PKCS #11 TC looks into OKP versus EC for CFRG support

[Anders Rundgren]

On 2017-08-04 21:33, Michael StJohns wrote:
> On 8/4/2017 3:05 PM, Anders Rundgren wrote:
>> https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html
>>
>> C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
>> Yeah, I know that open source <> open ideas but the world needs a
>> direction.
>>
>> Feel completely free dismissing OKP, it is the silence that's killing us.
>>
>> Cheers,
>> Anders
>> https://github.com/cyberphone/java-cfrg-spec
>>
> 
> Anders asked me to take a look at this a while back and I haven't
> actually had much time.  However, I think the approach he's crafted for
> OKP is probably wrong for Java.

"Wrong" is hardly the right word here; the proposals simply have quite different objectives.

I (FWIW) didn't give internal operations and structures much considerations; the emphasis was on clarity and conformance with other related specs.

Your proposal focuses on reuse by finding similar patterns which of course isn't "wrong" either.

In terms of code size I believe the difference will turn out to be insignificant but that's of course at this stage just a guess.

However, documentation- and support-wise OKP has a clear advantage.  Maybe Oracle should start there and see where it leads...

Anders

> 
> What I think I would do instead is create
> java.security.spec.ECFieldMontgomery and
> java.security.spec.ECFieldEdwards.   I'd place the indication of whether
> the curves are for Signature or Key Agreement at the field level - maybe
> as a sub interface or marker interface.
> 
>    For the ECPoint data I'd leave Y as a NULL - Y does exists and can be
> calculated, but all of these appear to use a compressed encoding.   I'd
> encode the public and private data as BigIntegers - this would mean
> converting from little endian to big endian and back again when doing
> the PKCS8 encoding stuff, but a lot easier than adding a whole new class
> of top level interfaces.
> 
> As far as I can tell, it should be possible to represent the four curves
> using the current API (minus the field info) and I'd suggest doing
> exactly that.  Tagging the ECField differently will isolate the changes
> without breaking previous implementations.   I think this is then also
> extensible as other curves come along.
> 
> My thoughts - Mike
> 
>