On 8/17/2017 8:25 AM, Michael StJohns wrote:
On 8/16/2017 12:31 PM, Xuelei Fan wrote:
On 8/16/2017 8:18 AM, Adam Petcher wrote:
I don't worry about this issue any more. At present, each
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a format
The format could be "X.509", and could be "RAW" (like
ByteArrayValue.getValue()). I would suggest have the named curve
in the algorithm characters, and use "RAW" as the encode format.
If X.509 encoding is required, KeyFactory.getKeySpec​() could do it.
Um... I think that doesn't make a lot of sense. The default
contract for public keys is X.509 and the default for private keys
is PKCS#8. Almost all uses of the encoded formats are related to
PKIX related functions. (See for info the javadoc for PublicKey).
I'm concerned about this, too. Ideally, we want PKI code to handle
these new keys without modification. The javadoc wording makes it a
little unclear whether public keys *must* use X.509 encoding, but
using other encodings for public keys would probably be surprising.
I have not had a conclusion, but I was wondering if almost all uses of
the encoded formats are related to PKIX related functions, whether it
is still a priority to support encoding other than X.509?
So far, I think our proposal works. The concern is mainly about how
to *simplify* the transaction between two formats (Raw, PKIX, XML and
JSON) in applications. I don't worry about the transaction too much
as it is doable with our current proposal, but just not as
straightforward as exposing the RAW public key.
If we want to simplify the transaction, I see your concerns of my
proposal above. We may keep using "X.509" for default, and define a
new key spec. The encoded form for X.509 is as:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The new encoded form could be just the subjectPublicKey field in the
SubjectPublicKeyInfo above.
However, I'm not very sure of how common the transaction is required
and whether it is beyond the threshold to be a public API in JRE.
There's a proposed defined format for PKIX keys on the new curves - the
IETF CURDLE working group is working through that. JCA should use that
and not invent something new.
>
> The new keys remain tagged as ECKeys. Old code won't notice (because
> old code is using old curves). New code (new providers) will have to
> pay attention to EllipticCurve and ECField information if its handling
> both types of curves. As is the case now, no provider need support
> every curve or even every field type.
>
My concern is about the case to use old provider and new provider all
together at the same time. JDK is a multiple providers coexisting
environment. We cannot grant that old code only uses old curves (old
providers) and new code only uses new curves (new providers).
I did see this email and commented on it. I think you're still missing
the point that not every provider implements (or is required to
implement) every curve. And in fact I argued that it was somewhat
stupid that the underlying C code in the SunEC provider was at odds with
the code in the SunEC java side with respect to known curves and how
they were handled. (Subject was RFR 8182999: SunEC throws
ProviderException on invalid curves).
Consider - currently if I don't specify a provider, and there are two
providers, and the lower priority provider implements "curveFoobar" but
the higher priority provider does not, and I use an ECGenParameterSpec
of "curveFoobar" to try and generate a key, I get a failure because I
got the higher priority provider (which gets selected because JCA
doesn't yet know that I want curveFoobar ) that doesn't do that curve. I
need to specify the same provider throughout the entire process to make
sure things work as expected AND I need to specify the provider that
implements the curve I want.
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.
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
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.
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.
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
