JCA design for RFC 7748

[Xuelei Fan]

On 8/11/2017 7:57 AM, Adam Petcher wrote:
> On 8/10/2017 9:46 PM, Michael StJohns wrote:
> 
>> On 8/10/2017 7:36 PM, Xuelei Fan wrote:
>>>> Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) 
>>>> and at least 4 major representational domains (Raw, PKIX, XML and 
>>>> JSON).  In the current situation, I can take a JCA EC Public key and 
>>>> convert it to pretty much any of the other APIs or representations. 
>>>> For much of the hardware based stuff (ie, smart cards), I go 
>>>> straight from JCA into raw and vice versa. Assuming you left the 
>>>> "getEncoded()" stuff in the API and the encoding was PKIX, I'd have 
>>>> to encode to PKIX, decode the PKIX to extract the actual raw key or 
>>>> encode a PKIX blob and hope that the KeyFactory stuff actually worked.
>>>>
>>>> It's not just support of arbitrary keys, but the ability to convert 
>>>> things without having to do multiple steps or stages.
>>>>
>>> Good point!  It would be nice if transaction between two formats 
>>> could be done simply.  Using X.509 encoding is doable as you said 
>>> above, but maybe there are spaces to get improvements.
>>>
>>> I need more time to think about it.  Please let me know if any one 
>>> have a solution to simplify the transaction if keeping use the 
>>> proposed named curves solution.
>>>
> 
> I'm also coming to the conclusion that using X.509 encoding for this 
> sort of interoperability is too onerous, and we should come up with 
> something better. Maybe we should add a new general-purpose interface 
> that exposes some structure in an algorithm-independent way. Something 
> like this:
> 
> package java.security.interfaces;
> public interface ByteArrayValue {
> 
>      String getAlgorithm();
>      AlgorithmParameterSpec getParams();
>      byte[] getValue();
> }
> 
I'm not sure how to use the above interface in an application.

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.

Xuelei

> The actual value is encoded, but the parameters are exposed, so this 
> interface would work well for any value that is generally represented 
> using a single encoded value (like public/private keys in RFC 7748, and 
> 8032). This could be used with the new NamedParameterSpec class to 
> identify the parameters by name. It could also be used with other 
> parameter specs to specify curve coefficients.
> 
> Of course, you may still need to look up curve name/OID/coefficients 
> based on the parameters, but at least this solution provides direct 
> access to the parameters and raw value, and you wouldn't need to go 
> through X.509. Though perhaps this is less appropriate for SEC1 types 
> and XML/JSON, because you would need to parse the value to extract the x 
> and y coordinates. So using the existing ECKey for those types may make 
> more sense.
> 
> 
> 
>