Hi Tim -
Pardon the top posting, and I'm only speaking for myself, but your
suggestion is unlikely to get any traction.
First and most importantly, sun.security.x509 et al are non-public
classes (e.g. not part of the JDK API, rather than a reference to their
java tagging), and generally align their public behaviors with the API,
and modify their private behaviors as necessary to make them more
efficient etc. E.g. you can't even count on X509Key to exist from JDK
to JDK as its possible that the plugin maintainer may completely
refactor those classes at any time.
Secondly, the API and the encoding of the public and private keys
generally reflects what the various RFCs and other standards documents
specify. Most of the key material has multiple ways to encode it, but
that's not the responsibility of either the JDK or the underlying
plugins - they all support a common PKIX encoding basis and expect that
"foreign" keys (e.g. keys originating outside of a given provider) will
be encoded in the common fashion when they enter or leave the
provider. It's left to the programmer to do whatever other encodings
are necessary and to do the translations to and from those. (I have
personal code for translating between raw EC keys and at least two
different forms of secure element native forms, as well as moving public
key material in and out of smart cards in various formats).
Third, yes it is 80s technology or earlier, but for better or worse, its
what the infrastructure supports.
You may find a better place to make this suggestion over with the
BouncyCastle folk. There are a host of utilities included with their
ASN1 libraries and crypto Providers that can be used to get what you
want - but I see you've already noted that.
You could always build your own provider classes to do what you want.
Later, Mike
On 5/4/2021 2:48 PM, Tim Bray wrote:
Pardon the interruption. I'm working on a social-media identity
federation project involving zero-knowledge proofs where you post
public-key/nonce/sig combinations to multiple places to prove the
poster identities' shared ownership of a private key. Details (not
really relevant to the following):
https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity
<https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity>
The representation of the public key needs to be textual. The most
straightforward way to do that is a one-liner like so:
Base64.getEncoder().encodeToString(key.getEncoded()) which gives you
Base64'ed PKIX.
Problem is, people are wondering why they need PKIX. They want to use
EdDSA and they don't see the need for algorithm agility (there's a
faction that thinks it's actively harmful) and point out that ed25119
keys are just 32 bytes worth of bits and don't see why they need to
use Eighties technologies to express them in ASCII and ask "why can't
I just base64 those bytes?" Which is straightforward in Go and JS and
so on.
It is however not straightforward in Java (unless I'm missing
something obvious, wouldn't be surprising)
because sun.security.x509.X509Key.getKey() is protected; see
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131
<https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131>
I have verified, via abuse of the reflection APIs, that the BitArray
that call returns does indeed represent the appropriate 32 ed25519
bytes. So, I have an object that has the data that I need inside but
for reasons of policy it is declining to reveal them. BTW you can do
this in BouncyCastle and friends.
Rather than changing protection on a long-established method, maybe a
new public byte[] getKeyBytes() would be the thing to do? Or maybe it
would be better to make this an EdDSA-specific operation? Maybe the
EdDSA classes already provide a way to do this that I couldn't find?
So, with an apology for possibly wasting your time, two questions:
1. Is there a principled Java 15 way to get the key bytes that I'm not
smart enough to have found?
2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA
key bytes be ruled out in principle for some good reason that I don't
know about?
