sha256 : derived from RE: Metadata Aggregator - Issues with XMLSignatureSigningStage

[Peter Williams]

I've found there to be significant interoperability issues with defaulting to sha256, for metadata signatures specifically. Its simply due to older software suites, not upgraded assuming the older community profile (sha1, which fixed the responsible NSA's team's broken sha"0" attempt) to match with the strength profile of 3DES.

We have no intention of upgrading our SAML2 servers for example, simply to deal with SHA256. They will be SHA1 until they are removed from service. Similarly, we will not be processing 8000 bit RSA keys...just because some open source software suite starts manufacturing them.

As always, it's a tough call on when to make makes the newer profile the default. One has to trade the future against interworking with what is out there. If shib only ever really talks to shib (or other academically-supported SAML libraries), it's a moot point. The onus is obviously on the future, in such cases. Shib is shib, and should be distinguished from the opensaml libraries (which many vendors use). Shib might default to X-future, whereas the libraries default to Y-older.

-----Original Message-----
From: dev-b...@shibboleth.net [mailto:dev-b...@shibboleth.net] On Behalf Of Chad La Joie
Sent: Wednesday, November 02, 2011 8:39 AM
To: Shib Dev
Subject: Re: Metadata Aggregator - Issues with XMLSignatureSigningStage

No, I don't think that'll have any impact here.

On Wed, Nov 2, 2011 at 11:29, Tom Poage <tfp...@ucdavis.edu> wrote:
> Missing JCE Unlimited Strength Policy files, perhaps?
>
> On Nov 2, 2011, at 8:04 AM, Krug, Jeff wrote:
>
>> I did have one question regarding signing algorithm.  Using the xmlsectool-1.1.4 I tweaked it to default to SHA256 signatures (and it uses Apache's digital signature classes to do this).  This worked fine.  The aggregator defaults to SHA256 (although conveniently configurable via a property) using the javax.crypto libraries, but for this I get the following error:
>>
>> 2011-11-02 10:52:30,398 - ERROR [net.shibboleth.metadata.dom.XMLSignatureSigningStage:644] - Unable to create signature method http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
>> java.security.NoSuchAlgorithmException: unsupported algorithm
>>        at org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory.newSignatureMethod(Unknown Source) ~[na:1.6.0_16]
>>        at net.shibboleth.metadata.dom.XMLSignatureSigningStage.buildSignedInfo(XMLSignatureSigningStage.java:641) [aggregator-pipeline-0.6.1.jar:na]
>>
>> I can set it to use SHA1 via the property and it works fine, but I feel like there is something obvious I'm overlooking that needs to be done to support SHA256 (and better, the same type of error shows up for SHA384 and SHA512).
>
> --
> To unsubscribe from this list send an email to dev-uns...@shibboleth.net
>

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net

[Krug, Jeff]

I have had trouble with sha256 as well, but part of why I'm excited about the metadata aggregator tool (and getting all signature algorithms working) is that it will become much easier to publish the metadata in different formats for different consumers, to make the management side of the slow trek to newer algorithms easier.

________________________________________
From: dev-b...@shibboleth.net [dev-b...@shibboleth.net] on behalf of Peter Williams [pwil...@rapattoni.com]
Sent: Wednesday, November 02, 2011 11:47 AM
To: Shib Dev
Subject: sha256 : derived from RE: Metadata Aggregator - Issues with XMLSignatureSigningStage

[Chad La Joie]

I hadn't thought of using the aggregator to handle that specific
problem. If you have other use cases in mind, please feed them back.