sp(2.5.5) <-> idp(3.1.2) and ecdsa certs

[Brent Putman]

On 11/4/15 9:58 AM, Cantor, Scott wrote:
> On 11/4/15, 3:42 AM, "users on behalf of Jarno Huuskonen" <users-bounces at shibboleth.net on behalf of jarno.huuskonen at uef.fi> wrote:
>
>
>
>> (from xmlsec-2.0.5 SignatureECDSA.java it looks like:
>> - The JAVA JCE ECDSA Signature algorithm creates ASN.1 encoded (r,s)
>> - the XML Signature requires the core BigInteger values.).


Thanks Jarno for looking into that.

> I do seem to recall that from when I was looking at the Java code trying to understand how to implement mine.

I hadn't gotten to looking at Santuario code yet, but now that I have,
the issue seems clear. 

(At least for the Redirect binding signature.  I don't think explains
why the SP wouldn't validate the XML signature).


>
>> So maybe java-opensaml (org.opensaml.security.crypto.SigningUtil) should
>> wrap the bare signature with ASN.1 sequence (convertXMLDSIGtoASN1) before
>> trying to verify the signature.
> The question is what the spec actually says. I'm not sure that it's clear at all on this, again out of either omission or because everybody only cared about RSA or whatever.

I didn't see that it said anything at all.  Unless I missed, I think
SAML genuinely has an ambiguity here for Redirect binding (and also
POST SimpleSign), and it needs to get clarified and then an errata done.


> It's up to Brent, I guess, but I would probably hold off trying to rush a fix in for 3.2 that we end up having to reverse since that gets confusing. We can always issue a patch later once we figure out who's actually wrong.

Yeah, no way would I rush this for 3.2.0.  We weren't even planning to
look at this in detail until after 3.2.0,  and I'd say that's still the
plan.  We also still need to solve the mystery of XML response IdP ->
SP failing.  That might change some of what we think we know at this point.


>
> But I believe that the best reading is probably yours, i.e. that the redirect signature ought to use the same encoding mandated by XML Signature's use of a given algorithm. That is, the same encoding rules specified for the SignatureValue element.

Off-hand that's what I initially think as well. Probably the simplest.
(Although a little sucky for java-opensaml, since I'll have to use
Santuario code for this "no-XML" case). 

However, I would really like to know why the Java JCA people chose the
ASN.1 route (and why XML Signature chose the other), and whether
there's something significant here that we shouldn't miss.

It certainly could just be a little/big endian type of thing: there's
no right or wrong way, you just have to pick something.  And the 2
camps chose differently for ECDSA.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151104/2d433880/attachment-0001.html>