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

[Brent Putman]

On 10/19/15 8:49 AM, Jarno Huuskonen wrote:
> 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)).

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.


> I modified SP(ApplicationDefaults) to use:
> signingAlg="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"
>
> (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?).

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


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


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.

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.

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.


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