<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11/3/16 3:44 PM, Brent Putman wrote:<br>
</div>
<blockquote
cite="mid:559133c2-bdd3-7fc8-dea9-ca6362c40770@georgetown.edu"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11/3/16 3:36 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A8303E@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">I'm not in front of my IDE right now.. But that's my recollection as
well. We support the DEREncoded element and (I think) the ECKeyValue
with a NamedCurve, but not the style where all the curve parameters are
expressed individually.
</pre>
</blockquote>
<pre wrap="">I think we support the XMLObject bits for that, </pre>
</blockquote>
<br>
Yes, I think so too.<br>
</blockquote>
<br>
Actually, turns out we don't have the XMLObject support at all for
the ECParameters child, or its child elements. Only the NamedCurve
child, and of course the mandatory PublicKey child. <br>
<br>
The issue was JST-92 and subtasks. Although not much info there as
to why. Probably because it didn't make sense to implement all the
objects if we weren't (yet) going to be able to process them. I
vaguely remember talking about it with you on a call. You actually
did all that original work in java-xmltooling.<br>
<br>
<br>
<blockquote
cite="mid:559133c2-bdd3-7fc8-dea9-ca6362c40770@georgetown.edu"
type="cite"> <br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A8303E@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">but I don't think we have the code to turn an ECKeyValue into a key, and I think there was a technical limitation involved.</pre>
</blockquote>
<br>
Maybe, per the other note I just sent. If there was an issue with
Java 7, it might have changed with Java 8, so needs some
investigation.<br>
</blockquote>
<br>
Not sure yet if there's an issue with the straight up JCA stuff. If
you can build an ECParameterSpec from whatever inputs you have
(named curve or raw parameters), you can then generate a PublicKey
from it (really an instance of ECPublicKey).<br>
<br>
But even if there's JDK limitations there: We do have a compile
dependency on BC, used for other things. So I'm sure one way or
another they will have a way to do that and can then convert to a
standard Java PublicKey. So I'm 99.9% sure it's doable.<br>
<br>
<br>
<br>
</body>
</html>