On 8/15/2017 7:05 PM, Michael StJohns wrote:
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
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.
This is sort of the moral equivalent of using the TXT RR record in DNS
and the arguments are similar.
This is a bad idea.
I'm not a DNS expert, so I apologize in advance if I misunderstood your
argument. What I think you are saying is that it is bad to store
something in a string or byte array which has no semantics, and it is
better to store information in a more structured way that has a clear
semantics. I agree with this.
My intention with this ByteArrayValue is to only use it for information
that has a clear semantics when represented as a byte array, and a byte
array is a convenient and appropriate representation for the algorithms
involved (so there isn't a lot of unnecessary conversion). This is the
case for public/private keys in RFC 7748/8032:
1) RFC 8032: "An EdDSA private key is a b-bit string k." "The EdDSA
public key is ENC(A)." (ENC is a function from integers to little-endian
bit strings.
2) RFC 7748: "Alice generates 32 random bytes in a[0] to a[31] and
transmits K_A =X25519(a, 9) to Bob..." The X25519 and X448 functions, as
described in the RFC, take bit strings as input and produce bit strings
as output.
So I think that a byte array is the correct representation for
public/private keys in these two RFCs.
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.
To be JCA compliant you need all of: <snip>
Are you describing hard compliance requirements or more informal
expectations? If it's the former, where are these requirements documented?
