In September 2013, the Metadata Distribution Working Group submitted its Phase 1 Recommendations to the InCommon Technical Advisory Committee. This FAQ anticipates questions and concerns regarding a Phase 1 Implementation Plan that is currently taking shape.
Shibboleth IdP deployments in the InCommon Federation are least affected by this implementation plan.
Being a pure Java implementation, the Shibboleth IdP software will verify an XML signature based on a SHA-2 digest algorithm. Therefore Shibboleth IdP deployments should migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014). |
If you are running a supported version of the Shibboleth IdP, your software is compatible with SHA-2 and you can migrate to the new production metadata aggregate at your convenience (but no later than March 29, 2014). There are two modifications you need to make to your IdP’s metadata configuration:
metadataURL
XML attribute on the <MetadataProvider>
element should point to the HTTP location of the new production metadata aggregate.The second step above is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.
Shibboleth SP version 2.0 (or later) supports SHA-2 but whether or not it can deliver that support depends on the version of OpenSSL installed. Since OpenSSL is bundled with the Shibboleth SP software on the Windows platform, SHA-2 support on Windows is assured.
On the Windows platform, the Shibboleth SP software will verify an XML signature based on a SHA-2 digest algorithm. Therefore Windows-based Shibboleth SP deployments should migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014). |
If you're running the Shibboleth SP software on a non-Windows platform, the software depends on whatever version of OpenSSL is built into the underlying operating system. If Shibboleth is installed on top of an unsupported OS platform, it is likely you are running an old version of OpenSSL that doesn’t support SHA-2. For instance, RHEL 4 was built with OpenSSL version 0.9.7, which is known to be incompatible with SHA-2. In this case, you have no choice but to upgrade to a supported OS platform.
If your deployment depends on an old version of the OpenSSL crypto library, it may be unable to verify the signature on the new metadata aggregate. In particular, versions of OpenSSL prior to 0.9.8 are known to be incompatible with SHA-2 and therefore any platform that depends on OpenSSL 0.9.7 (or earlier) will not be able to verify an XML signature that uses a SHA-2 digest algorithm. |
If your Shibboleth SP deployment is installed on a system with OpenSSL version 0.9.8 or later, you should migrate to the new production metadata aggregate; otherwise you should migrate to the new fallback metadata aggregate. In either case, there are two modifications you need to make to your SP’s metadata configuration:
url
XML attribute on the <MetadataProvider>
element should point to the HTTP location of the new metadata aggregate.The second step above is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.
If your Shibboleth SP deployment is not compatible with SHA-2, and you migrate to the new fallback metadata aggregate, start planning now to upgrade your system and migrate to the new production metadata aggregate ASAP (but no later than June 30, 2014). |
The simpleSAMLphp metarefresh module will refresh and verify metadata automatically. Signature verification depends on the fingerprint of the signing certificate, so the fingerprint configured in the metarefresh module must be updated before migrating simpleSAMLphp to the new metadata aggregate.
It is known that versions of simpleSAMLphp prior to version 1.11 are incompatible with SHA-2. You will need to upgrade to simpleSAMLphp 1.11 (or later) before migrating to the new production metadata aggregate. |
If you're running simpleSAMLphp 1.11 (or later), your software is compatible with SHA-2 and you can migrate to the new production metadata aggregate at your convenience (but no later than March 29, 2014). There are two configuration changes you need to make to simpleSAMLphp's metarefresh module:
src
array element should point to the HTTP location of the new production metadata aggregate.validateFingerprint
array element must reflect the fingerprint of the new signing certificate.The second step is critical for simpleSAMLphp deployments (despite the fact that the new signing certificate contains the same key as the old signing certificate). See the Metadata Consumption wiki page for instructions how to securely obtain the fingerprint of the new metadata signing certificate.
Microsoft AD FS 2.0 is not able to consume the InCommon metadata aggregate, so the answer depends on the external process used to refresh and verify metadata on behalf of AD FS. Some deployments use a tool called FEMMA, which does not verify the signature on the metadata. In this case the XML signature on the new metadata aggregate will have no adverse effect. An AD FS deployment that uses FEMMA is advised to migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014).
If your AD FS deployment uses FEMMA alone to consume InCommon metadata, it is doing so insecurely. A secure metadata process will verify the signature on the metadata and check the |
An alternative to FEMMA called pysFEMMA will verify the signature on the metadata, however. Like the Shibboleth SP, an AD FS deployment that uses pysFEMMA will have difficulty migrating to the new metadata aggregate if the underlying crypto library is incompatible with SHA-2. See the AD FS Metadata Config wiki page for more detailed information about pysFEMMA.
AFAIK, no commercial product is able to consume the InCommon metadata aggregate, so the answer is more-or-less the same as it is for Microsoft AD FS 2.0: it depends on the tool chain used to refresh and verify metadata.