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 
> <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?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210504/89edd926/attachment.htm>