generated metadata should include cryptographic algorithms
Description
Environment
Activity
Former user August 7, 2012 at 2:56 PM
Sure - filed SSPCPP-492.
Scott Cantor August 7, 2012 at 1:58 PM
Can you please file a bug on it? There's no way I'll remember it with everything I have to work on right now.
Former user August 7, 2012 at 11:22 AM
The changes for the final 2.5.0 release in
http://svn.shibboleth.net/view/cpp-sp?view=revision&revision=3744
break builds with xml-security-c prior < 1.7.0. Applying the following patch did the trick for me:
--- shibboleth-sp-2.5.0.orig/shibsp/handler/impl/MetadataGenerator.cpp 2012-08-07 09:55:27.000000000 +0200
+++ shibboleth-sp-2.5.0/shibsp/handler/impl/MetadataGenerator.cpp 2012-08-07 09:58:54.000000000 +0200
@@ -109,8 +109,11 @@
em->setAlgorithm(alg);
m_encryptions.push_back(em);
- if (XMLString::equals(alg, DSIGConstants::s_unicodeStrURIRSA_OAEP) ||
- XMLString::equals(alg, DSIGConstants::s_unicodeStrURIRSA_OAEP_MGFP1)) {
+ if (
+#ifdef URI_ID_RSA_OAEP
+ XMLString::equals(alg, DSIGConstants::s_unicodeStrURIRSA_OAEP) ||
+#endif
+ XMLString::equals(alg, DSIGConstants::s_unicodeStrURIRSA_OAEP_MGFP1)) {
// Check for non-support of SHA-256. This is a reasonable guess as to whether
// "all" standard digests and MGF variants will be supported or not, and if not, we
// explicitly advertise only SHA-1.
@@ -118,12 +121,14 @@
if (!m_digestBuilder)
m_digestBuilder = XMLObjectBuilder::getBuilder(xmltooling::QName(samlconstants::SAML20MD_ALGSUPPORT_NS, DigestMethod::LOCAL_NAME));
+#ifdef URI_ID_RSA_OAEP
// Add MGF for new OAEP variant.
if (XMLString::equals(alg, DSIGConstants::s_unicodeStrURIRSA_OAEP)) {
MGF* mgf = MGFBuilder::buildMGF();
mgf->setAlgorithm(DSIGConstants::s_unicodeStrURIMGF1_SHA1);
em->getUnknownXMLObjects().push_back(mgf);
}
+#endif
DigestMethod* dm = dynamic_cast<DigestMethod*>(
m_digestBuilder->buildObject(xmlconstants::XMLSIG_NS, DigestMethod::LOCAL_NAME, xmlconstants::XMLSIG_PREFIX)Scott Cantor August 1, 2012 at 4:14 AM
Latest check-in refines the EncryptionMethod elements for OAEP with DigestMethod and MGF content if SHA-256 is unavailable (implying that probably all but SHA-1 are unsupported).
e.g.
<md:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep">
<xenc11:MGF xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" Algorithm="http://www.w3.org/2009/xmlenc11#mgf1sha1"/>
<ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
</md:EncryptionMethod>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
</md:EncryptionMethod>
Ian Young July 8, 2012 at 1:37 PM
Right, having convinced myself that you're not allowed to use multiple RSA operations in a signature (the signature has to be the same length as the RSA modulus, in other words) the potentially problematic case is an SP which supports and prioritises SHA-512 in its metadata, and an IdP which supports SHA-512 and determines that's what it should try and do even if its RSA signing key is (say) 512 bits. The hash plus the required additional gubbins won't fit into the RSA operation, so the signature will fail at the IdP side (the SP won't see it) and it would look like that was caused by the SP's metadata.
I suppose the "right" approach is going to be that the IdP implementation will have to have enough smarts not to select a hash algorithm whose output is too large relative to the length of the RSA modulus. In other words, this is something to be looked at in the IdP implementation that hasn't been written yet and not something we need to worry about on the SP side.
The less friendly approach would of course be to decide that people who are still using 512-bit RSA are in need of a wake-up call. I don't know how common it still is; obviously some federations insist on longer keys but I can't speak for all of them.
The service provider should generate metadata describing the cryptographic algorithms supported, per the SAML v2.0 Metadata Profile for Algorithm Support Version 1.0.
This should include alg:SigningMethod and alg:DigestMethod, as they are the ones we're most likely to need in the shorter term as MD5 and potentially SHA-1 go beyond their useful life.
There's a note in the wiki that there are problems with OpenSAML-C 2.0 with respect to adding EncryptionMethod elements to KeyDescriptor elements. If this problem is isolated to IdP metadata, we should probably include EncryptionMethod elements as well. If the problem occurs even if EncryptionMethod is present in the metadata for another SP, there's an argument that the SP should not generate EncryptionMethod metadata until we really need it. I'd actually be interested in that clarification myself as at present UK federation checks preclude using EncryptionMethod on both SPs and IdPs, just to be on the safe side.