<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 11/4/15 9:58 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:12D077F2-3B02-4938-8CF5-4BF3A473F93C@osu.edu"
type="cite">
<pre wrap="">On 11/4/15, 3:42 AM, "users on behalf of Jarno Huuskonen" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofjarno.huuskonen@uef.fi"><users-bounces@shibboleth.net on behalf of jarno.huuskonen@uef.fi></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">(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.).
</pre>
</blockquote>
</blockquote>
<br>
<br>
Thanks Jarno for looking into that.<br>
<br>
<blockquote cite="mid:12D077F2-3B02-4938-8CF5-4BF3A473F93C@osu.edu"
type="cite">
<pre wrap="">
I do seem to recall that from when I was looking at the Java code trying to understand how to implement mine.</pre>
</blockquote>
<br>
I hadn't gotten to looking at Santuario code yet, but now that I
have, the issue seems clear. <br>
<br>
(At least for the Redirect binding signature. I don't think
explains why the SP wouldn't validate the XML signature).<br>
<br>
<br>
<blockquote cite="mid:12D077F2-3B02-4938-8CF5-4BF3A473F93C@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:12D077F2-3B02-4938-8CF5-4BF3A473F93C@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:12D077F2-3B02-4938-8CF5-4BF3A473F93C@osu.edu"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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). <br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>