<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 10/19/15 8:49 AM, Jarno Huuskonen
wrote:<br>
</div>
<blockquote cite="mid:20151019124956.GA17576@jjh.uef.fi" type="cite">
<pre wrap="">Hi,
Out of curiosity I created a (self-signed) ecdsa cert
(Signature Algorithm: ecdsa-with-SHA256
Public Key Algorithm: id-ecPublicKey
ASN1 OID: prime256v1)
and tried to use this cert/key in metadata between sp2.5.5 and idp3.1.2.
(idp has oracle jdk 1.8.0_51 (with unlimited jce)).
</pre>
</blockquote>
<br>
See below, but I think the relevant info for the SP is probably
going to be what version of OpenSSL is in use here on the SP. And
if it's supplied by the OS (RPM, etc) then what OS platform/version.<br>
<br>
<br>
<blockquote cite="mid:20151019124956.GA17576@jjh.uef.fi" type="cite">
<pre wrap="">
I modified SP(ApplicationDefaults) to use:
signingAlg=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256">"http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"</a>
(without this sp throws xmltools/xmlsec error). With SAML Tracer it
looks like that sp sends AuthnRequest with ecdsa-sha256
(BTW are there any tools to verify AuthnRequest signature?).</pre>
</blockquote>
<br>
From the use of SigningUtil below, looks like this is the SAML 2
Redirect binding? No, we don't really have any tools to directly
verify that outside of message processing, like we do for XML
signatures.<br>
<br>
<br>
<blockquote cite="mid:20151019124956.GA17576@jjh.uef.fi" type="cite">
<pre wrap="">
But idp fails with:
2015-10-16 14:41:37,355 - DEBUG [org.opensaml.saml.security.impl.MetadataCredentialResolver:354] - Found no cached credentials in KeyDescriptor object metadata, resolving from KeyInfo
2015-10-16 14:41:37,376 - ERROR [org.opensaml.security.crypto.SigningUtil:219] - Error during signature verification
java.security.SignatureException: Could not verify signature
at sun.security.ec.ECDSASignature.engineVerify(ECDSASignature.java:320)
Caused by: java.security.SignatureException: Could not decode signature
at sun.security.ec.ECDSASignature.decodeSignature(ECDSASignature.java:386)
Caused by: java.io.IOException: Sequence tag error
at sun.security.util.DerInputStream.getSequence(DerInputStream.java:297)
So it looks like idp doesn't find correct cert from metadata.
</pre>
</blockquote>
<br>
<br>
No, I don't think this has anything to do with metadata. The DEBUG
message from the MetadataCredentialResolver just means that no
processed creds were cached, so it has to actually parse and read
the KeyInfo data. That's normal if it's the first time since
starting the IdP that it has tried to resolve credentials for that
particular SP from that particular metadata.<br>
<br>
AFAIK, the IdP running under Java 8 should be able to handle parsing
EC certs just fine. IIRC we do have at least some unit tests that
exercise EC keys and certs.<br>
<br>
The ERROR message logged is from the actual signature verification
operation. So my guess would be that this is at the low level of
the crypto itself. So if there's an interop issue, I think it's
likely to be something between the signature generated by OpenSSL at
the SP and the signature validation at the Java JCA layer at the
IdP. Or possibly with the query param encoding/decoding for the
Redirec binging - but we know RSA works there, so I can't imagine
why EC would be different.<br>
<br>
<br>
</body>
</html>