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.




Reply via email to