JCA design for RFC 7748

[Xuelei Fan]

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.

On 8/15/2017 4:05 PM, Michael StJohns wrote:
 > Here's what I think should happen:
 >
 > 1) ECPoint gets a document modification to handle compressed points. The
 > X is the X value, the Y is -1, 0 or 1 depending on positive negative or
 > don't care for the sign of the Y value.   (This means that the byte
 > array public key gets handled as a BigInteger). Any value other than 0,
 > -1 or 1 for Y indicates a normal X Y point.
 >
 > 2) EllipticCurve gets a document modification to describe the mappings
 > for Edwards and Montgomery curves as discussed previously.
 >
 > 3) Two classes are added to java.security.spec:
 > java.security.spec.ECFieldEdwards and
 > java.security.spec.ECFieldMontgomery - both of which implement ECField.
 >
 > 4) The ECFieldEdwards/Montgomery classes contain an indication of
 > whether the curve is signature only, key agreement only or both. They
 > also contain any parameters that can't be mapped in EllipticCurve
 >
 > 5) Using the above, someone specifies the curve sets for the four new
 > curves as ECParameterSpec's and we iterate until we're satisfied we've
 > got a standard public representation that can be used for other than
 > the 4 curves.
 >
 > 6) Until the JCA is updated, a provider for the new curves can use its
 > own concrete ECField classes and later make them be subclasses of the
 > java.security.spec.ECFieldMontgomery etc.  It's not ideal, but it does
 > let the guys who are chomping at the bit do an implementation while
 > waiting for the JCA to be updated.
 >
 > 7) No other changes to the JCA are made.  The providers implement
 > SubjectPublicKeyInfo and PKCS8 as the standard encodings  using the
 > definitions in
 > https://tools.ietf.org/html/draft-ietf-curdle-pkix-newcurves-00 and
 > RFC5480.
 >
 > 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).

There is an example in my August 10 reply:
 
http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html

Xuelei