...
In sp800-131A, published in January 2011, NIST updated its recommendations for use of several cryptographic algorithms and key lengths for use in the US Federal government. In particular, it calls for discontinuing use of the SHA-1 digest function or hash algorithm in digital signatures effective January 1, 2014 and recommends using any of the digest functions known collectively as SHA-2 for use in digital signatures.
There are two federation use cases in which SHA-1 is or might currently be used for digital signatures.
- Many SAML protocol messages and assertions are digitally signed. All releases to date of the Shibboleth IdP use SHA-1 as the digest function and for RSA signatures.
- InCommon metadata is signed using SHA-1 as the digest function and for RSA signatures.
Although NIST recommendations need not be binding outside of the US Government, InCommon must pay attention for two reasons. The first is that the InCommon Identity Assurance program references NIST recommendations with regard to cryptographic algorithms. Basically, crypto algorithms used in a Bronze or Silver compliant implementation either must be approved by NIST or be covered by an InCommon-approved Alternative Means (AM). So , campuses wanting Silver or Bronze must either use SHA-2 or InCommon must approve an alternative they can use. So , unless an AM would say "it's ok to continue using SHA-1 for digital signatures", some change to widely deployed behavior is needed, and for that appropriate testing and validation needs to be done to ascertain how it will work and how to advise deployers accordingly.
...
The second reason InCommon should pay attention to sp800-131A is that, as a matter of best practice, NIST has moved the bar up a notch. InCommon should implement best practices to continue to earn the trust of its members; that is its essential reason for being. InCommon should adapt its metadata distribution operations accordingly, and it should enable participants wishing to achieve Bronze or Silver to likewise observe achieve best practice.
What needs to be done?
...
Cf. a more detailed page on testing.
Design and implement an enhancement to InCommon's metadata distribution that enables use of SHA-2
Perhaps this can simply be publishing two signed metadata files, one using SHA-1 and the other SHA-2, so that participants wanting or needing to use SHA-1 have that option available to them. The primary aggregate should be migrated to SHA-2 in order to move the federation forward.
Who should do what?
The SHA-2 Shibboleth IdP extension would best be one that exists in a single, established code namespace, so that each deployment does not need to deal with namespace issues. It would also be simplest if the resulting extension and corresponding wiki doc exist on the shibboleth.net site in suitable locations. Perhaps this is best done by the Shibboleth developers.
A TAC subcommittee should quickly be chartered and spun up to do the testing. Liaison with the InCommon Assurance Advisory Group would be desirable so that they can monitor and see whatever the result will be at the earliest opportunity. We should aim for the testing to be done and analysis and follow ups complete by end of August 2013. A fun summer project for a couple of inspired techies! Also, we can ask technical leads affiliated with common SAML implementations to help us.Another TAC subcommittee, perhaps the Metadata Distribution Working Group, should take on the task of metadata distribution.