<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 8/17/2017 1:28 PM, Xuelei Fan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com">
<blockquote type="cite" style="color: #000000;">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.
<br>
<br>
</blockquote>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com">
<br>
<br>
<blockquote type="cite" style="color: #000000;">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.
<br>
<br>
</blockquote>
I happened to have a real-world example. See
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8064330"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8064330</a></blockquote>
<br>
I'm not sure how this applies to the current question of whether or
not its possible to integrate new EC curves?<br>
<br>
<blockquote type="cite"
cite="mid:878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com">
<br>
<br>
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.</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com">
<br>
<br>
<blockquote type="cite" style="color: #000000;">Treat these simply
as new curves and let's move forward with very minimal changes
to the public API.
<br>
<br>
</blockquote>
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.
<br>
<br>
</blockquote>
<br>
I'm not sure why you think this (the example in [1]) can't be done?<br>
<br>
I gave the example elsewhere, but let me expand it with my comment
above (possibly faking the hash key names - sorry):<br>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap"> HashMap<String,String> neededAlgs = new HashMap<>();
neededAlgs.put("Signature.EdDSA", "");
neededAlgs.put("AlgorithmParameters.EC SupportedCurves", "ed25519")
</pre>
</blockquote>
<br>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap">Provider[] p = Security.getProviders(neededAlgs);
if (p == null) throw new Exception ("Oops");
</pre>
</blockquote>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap">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));
</pre>
</blockquote>
<br>
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.:<br>
<br>
package java.security.spec;<br>
public class NamedECParameterSpec extends ECParameterSpec {<br>
<br>
private Collection<String> names;<br>
private Collection<Oid> oids;<br>
public NamedECParameterSpec (EllipticCurve curve, ECPoint g,
BigInteger n, int h, Collection<String> names,
Collection<Oid> oids) {<br>
super (curve, g, n, h);<br>
if (names != null) {<br>
this.names = new ArrayList<String>(names);<br>
}<br>
if (oids != null) {<br>
this.oids = new ArrayList<Oid>(oids);<br>
}<br>
}<br>
<br>
public Collection<String> getNames() {<br>
if (names == null) <br>
return
(Collection<String>)Collections.EMPTY_LIST;<br>
else<br>
return Collections.unmodifiableList(names);<br>
}<br>
<br>
etc....<br>
<br>
This makes it easier to get exactly what you want from a key.
Assuming the provider implements it.<br>
<br>
Mike<br>
<br>
<br>
<blockquote type="cite"
cite="mid:878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com">Xuelei
<br>
<br>
[1]: <a class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html"
moz-do-not-send="true">http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html</a>
<br>
<br>
<blockquote type="cite" style="color: #000000;">
<br>
Mike
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite" style="color: #000000;">
<br>
There is an example in my August 10 reply:
<br>
<br>
<a class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html"
moz-do-not-send="true">http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html</a>
<br>
<br>
Xuelei
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<p><br>
</p>
</body>
</html>