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.
