Tentative suggestion: Make X509Key.getKey() non-protected
Tim Bray
tbray at textuality.com
Tue May 4 18:48:44 UTC 2021
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
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210504/0fa08c73/attachment.htm>
More information about the security-dev
mailing list