RFR 8171279: Support X25519 and X448 in TLS 1.3

[Adam Petcher]

Minor correction below.


On 9/6/2018 1:04 PM, Adam Petcher wrote:
>
>>
>>>
>>> In the latest webrev, I changed it so there is a single static 
>>> NamedGroupFunctions of each type, and the NamedGroup is passed in as 
>>> the first argument to each method that requires it (rather than 
>>> being a member of NamedGroupFunctions).
>>>
>> After the re-org, I guess you can put the inner classes in NamedGroup 
>> enum and declare them as private?  The getFunctions() method may be 
>> unnecessary then.
>
> I don't know if that works, exactly, due to the fact that I can't 
> reference static enum members in the body of an enum constructor. How 
> about this alternative? I can move the NamedGroup enum and all the 
> NamedGroupFunction classes into a separate class (in a separate file) 
> called NamedGroups. Then all the NamedGroupFunction classes can be 
> private in this class, but the NamedGroup enum can still have package 
> access. I would prefer to leave the getFunctions() method of 
> NamedGroup (and keep it private) because the functions object may be 
> missing and the Optional return type of getFunctions() forces me to 
> deal with this when I call it from within NamedGroup.
>
>
Actually, it does work. I just have to move the static members of each 
NamedGroupFunctions subclass into its subclass (e.g. make them 
singletons). Still, I like my proposed alternative better, because it 
allows us to simplify SupportedGroupsExtension. Let me know if you have 
a preference.