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

[Cantor, Scott]

On 10/21/15, 1:06 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:



>Caused by: java.io.IOException: Sequence tag error
>        at sun.security.util.DerInputStream.getSequence(DerInputStream.java:297)
>I guess there's something that's ASN.1 here?  Not clear to me what that would be, other than the PublicKey.  Is there ASN.1 in the actual signature bytes? The cert/publicKey is not even sent by the SP in this binding, it's coming from metadata.  And if there
> were an issue there, I'd think it would fail when it parses the KeyInfo data into the PublicKey, not a verify time.

Yeah, that's interesting.

>I took a quick look and SAML 2 Bindings doesn't really seem to say anything about the particulars of the crypto padding or other details.  Just covers the construction of the string to be signed.  Since RSA works, I wouldn't think the issue would be there.
> But who knows...  

Well, from having fixed the ECDSA code last year, the problem was that I didn't read all the detailed rules for how the padding works and how to combine the R and S values to make up the final signature, none of which OpenSSL does for you. And XML Signature says either directly or by reference how that's done to produce the octets you base64-encode into the SignatureValue element.

If SAML says nothing, that's somewhat loose I think. I'd have to review how RSA works, whether any sort of implicit behavior was left unspecified because RSA is simpler than DSA and that's now causing issues.

It was lots of fun being the supposed authority on the SAML TC on what language we needed when I'd never implemented a line of crypto in my life, and am still in the "knows enough to get it wrong consistently" stage.

Anyway, I guess bottom line it's a post-3.2 work item at this point to give this all a lookover.

-- Scott