JCA design for RFC 7748

[Adam Petcher]

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();
}

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.