EncryptionMethod in Metadata

[Cantor, Scott]

> This is not a Shibboleth question but a more general SAML/metadata one.
> I'm working with a (non-Shib) IdP integrated with a (non-Shib) SP and was
> getting errors encrypting assertions. The issue is a mismatch between the IdP
> metadata and the SP metadata.

If neither is Shibboleth, then there's not a lot I can tell you, but the use of EncryptionMethod in the original standard is essentially undefined. It's profiled in an extension spec, but nothing but Shibboleth supports that, so it has nothing to do with your observations.

> In the IdP Metadata (the local metadata read by the IdP), the encryption key
> section contains:

Do you have some reason to think it's reading that metadata? That would be very unusual (Shibboleth shouldn't even be doing it).

> When trying to send an assertion between these two, I get "Data encryption
> algorithm and strength mismatch" errors. I was able to fix the error two
> different ways: (a) adding the 128 KeySize child element to the SP's
> EncyptionMethod tag, or (b) removing the EncryptionMethod element
> altogether. Note that I did not change the SP's actual configuration in any
> way, just edited my IdP's local copy of the SP's metadata.

Well, I doubt the IdP's metadata mattered here. Whatever the IdP is doing is odd, but you're not going to find any explanation of it in the standard, sorry.

I suppose there might be reason to deduce that if it generates metadata containing KeySize, it must have some strict requirement for that. (That is not required by the extension, but this isn't using the extension spec, so that's irrelevant.)
 
> 1) Is this (declaring the encryption methods to be incompatible) correct or
> buggy behavior on the part of my IdP? (I can believe either answer)

It's not incorrect, but is not justified or sensible.

> 2) Given that I don't see any entries in the InCommon Metadata that contain
> an EncryptionMethod element, I'd guess that best practice is to just omit
> these entries from metadata. Are there any reasons to include this
> information?

https://wiki.oasis-open.org/security/SAML2MetadataAlgSupport

The near term use case is for SPs to indicate they support AES-GCM, or perhaps don't support RSA-PKCS1 padding on key transport, but there are no IdPs in the world at present that would do anything with the information until V3 is released.

I can readily believe that EncryptionMethod is going to break some badly implemented code, and if I had it to do over, I would not have profiled it for that extension, and just left it as a legacy element to avoid using.

-- Scott