JCA design for RFC 7748

[Adam Petcher]

On 8/10/2017 12:25 PM, Michael StJohns wrote:

> On 8/10/2017 9:44 AM, Adam Petcher wrote:
>> Does anyone know of a particular use case (that we haven't discuss 
>> already) that would require a provider to support arbitrary curves? 
>> Any other arguments for or against this feature? 
>
> There are uses for changing out the base point.  PAKE and SPAKE use 
> similar math (e.g. G^s*sharedSecret is the equivalent of a new base 
> point).
>
> There are uses for private curves - e.g. when you want to actually be 
> sure that the curve was randomly generated (sort of the same argument 
> that got us to Curve25519 in the first place).
>
> There are the whole set of Edwards curves that are mostly not included 
> in any provider (except possible Microsoft's) as of yet.
>
> Basically, you're trying to argue that there are no better curves (for 
> the 'new' math) than have already been specified and there never will 
> be.  I think that's a very shortsighted argument.

I expect that new curves will be developed in the future, and the API 
should absolutely be designed in such a way that that support for new 
curves can be easily added to applications and providers. What I 
attempted to argue (I apologize if this was not clear) was that we don't 
necessarily need support for arbitrary curve parameters in the initial 
API design because:

1) When new, better curves are developed, they will eventually get 
names, and then they can be used in exactly the same way as the curves 
that exist today.
2) If there is a desire to allow arbitrary curve parameters for 
Montgomery/Edwards curves over the API, then we can consider this in the 
future as a separate feature. We should ensure that the initial API 
design accommodates the addition of this API in the future.


>
> Later, Mike
>
>