JCA design for RFC 7748

[Michael StJohns]

On 8/17/2017 1:28 PM, Xuelei Fan wrote:
>> This is the same for ANY current publicly known curve - different 
>> providers may implement all some or none of them.  So extending this 
>> model for the curve25519 stuff isn't going to be any different old 
>> provider and new provider wise than is currently the case.   If you 
>> want the new curves, you have to specify the new providers. If the 
>> new and old providers don't implement the same curves, you may need 
>> to deal with two different providers simultaneously - and that's not 
>> something that just happens.
>>
> I see your points.  Not-binding to a provider cause problems; binding 
> to a provider cause other problems.  There are a few complains on the 
> problems, and impact the real world applications in practice.

Basically, this is a failing of imagination when the various 
getInstance() methods were defined.  Now its possible to use 
Security.getProvider(Map<String,String>)  to good effect (but more work) 
to find appropriate providers for appropriate signature/key agreement 
algorithms and curves.


>
>
>> I don't think your concerns are valid.  I may still be missing 
>> something here - but would ask for a real-world example that actually 
>> shows breakage.
>>
> I happened to have a real-world example.  See
> https://bugs.openjdk.java.net/browse/JDK-8064330

I'm not sure how this applies to the current question of whether or not 
its possible to integrate new EC curves?

>
>
> This is an interesting bug.  At first it is requested to support 
> SHA224 in JSSE implementation. And, SHA224 is added as the supported 
> hash algorithm for TLS.  However, because SunMSCAPI does not support 
> SHA224 signature, compatibility issues comes.  So we removed SHA224 if 
> the SunMSCAPI is presented.  Later, one found the code is unusual as 
> SHA224 and the related signature algorithms are supported by the 
> underlying providers, look like no reason to limit the use of SHA224.  
> So, SHA224 is added back and then the compatibility issues come back 
> again.  Then we removed SHA224 again if the SunMSCAPI is presented.  
> However, at the same time, another request is asking to support SHA224 
> on Windows.  The API design itself put me in a either-or situation.  I 
> would try to avoid it if possible for new design.

This appears to be an MSCAPI issue vice a JSSE issue.  And the JCA 
specifically disclaims the guaranteed ability to use cryptographic 
objects from one provider in another provider.   Secondary users like 
the JSSE probably need to stick to a single provider for a given connection.

>
>
>> Treat these simply as new curves and let's move forward with very 
>> minimal changes to the public API.
>>
> I would like to treat it as two things.  One is to support new curves 
> for new forms.  The other one is to support named curves [1].  For the 
> support of new forms,  there are still significant problems to solve. 
> For the support of named curves (including the current EC form), looks 
> like we are in a not-that-bad situation right now.  Will the named 
> curves solution impacts the support of new curves APIs in the future?  
> I don't see the impact yet.  I may missing something, but I see no 
> reason to option out the named curves support.
>

I'm not sure why you think this (the example in [1]) can't be done?

I gave the example elsewhere, but let me expand it with my comment above 
(possibly faking the hash key names - sorry):

>         HashMap<String,String> neededAlgs = new HashMap<>();
> 	neededAlgs.put("Signature.EdDSA", "");
>          neededAlgs.put("AlgorithmParameters.EC SupportedCurves", "ed25519")


> Provider[] p = Security.getProviders(neededAlgs);
> if (p == null) throw new Exception ("Oops");

> AlgorithmParameters parameters = AlgorithmParameters.getInstance("EC", p[0]);
>          parameters.init(new ECGenParameterSpec("ed25519"));
>          ECParameterSpec ecParameters = parameters.getParameterSpec(ECParameterSpec.class);
>
>          return KeyFactory.getInstance("EC", p[0]).generatePublic(new ECPublicKeySpec(new ECPoint(x, y), ecParameters));

If you're talking more generally, NamedCurves should be a form of 
ECParameterSpec so you can read the name from the key, but there's no 
support for adding names to that spec.  Maybe extend it?  E.g.:

package java.security.spec;
public class NamedECParameterSpec extends ECParameterSpec {

    private Collection<String> names;
    private Collection<Oid> oids;
    public NamedECParameterSpec (EllipticCurve curve, ECPoint g, 
BigInteger n, int h, Collection<String> names, Collection<Oid> oids) {
         super (curve, g, n, h);
         if (names != null) {
             this.names = new ArrayList<String>(names);
         }
         if (oids != null) {
             this.oids = new ArrayList<Oid>(oids);
        }
   }

    public Collection<String> getNames() {
         if (names == null)
              return (Collection<String>)Collections.EMPTY_LIST;
          else
             return Collections.unmodifiableList(names);
     }

     etc....

    This makes it easier to get exactly what you want from a key. 
Assuming the provider implements it.

Mike


> Xuelei
>
> [1]: 
> http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html 
>
>
>>
>> Mike
>>
>>
>>
>>
>>
>>>
>>> There is an example in my August 10 reply:
>>>
>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html 
>>>
>>>
>>> Xuelei
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170817/e95cd88f/attachment.htm>