<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Tim -</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Pardon the top posting, and I'm only
speaking for myself, but your suggestion is unlikely to get any
traction. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Third, yes it is 80s technology or
earlier, but for better or worse, its what the infrastructure
supports.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">You could always build your own
provider classes to do what you want. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Later, Mike</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 5/4/2021 2:48 PM, Tim Bray wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHBU6isPxJNjJNY=w4aPEshT7Sr=mv80DbUuCdm7N2f-cfh_WQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">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): <a
href="https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity"
target="_blank" moz-do-not-send="true">https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity</a></div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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 <a
href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131"
target="_blank" moz-do-not-send="true">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131</a></div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">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?<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">So,
with an apology for possibly wasting your time, two
questions:</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">1.
Is there a principled Java 15 way to get the key
bytes that I'm not smart enough to have found?</div>
<div class="gmail_default" style="font-size:small">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?</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>