Re: Tentative suggestion: Make X509Key.getKey() non-protected

[Michael StJohns]

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 



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?

Tentative suggestion: Make X509Key.getKey() non-protected

[Tim Bray]

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?