XMLDSIG and XMLDSIG11

[Brent Putman]

On 11/3/16 3:44 PM, Brent Putman wrote:
>
>
>
> On 11/3/16 3:36 PM, Cantor, Scott wrote:
>>> 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.
>> I think we support the XMLObject bits for that, 
>
> Yes, I think so too.

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. 

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.


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

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).

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161103/c68a0df2/attachment.html>