AES256-CBC for encryption?

[Wessel, Keith]

Thanks, Scott. I'm still not getting this to work, though. I've added the encryption algorithm to the metadata inside the encryption key descriptor block:

   <KeyDescriptor use="encryption">
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
     <X509Data>
      <X509Certificate>Cert here</X509Certificate>
     </X509Data>
    </KeyInfo>
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
   </KeyDescriptor>

I see no global definitions of encryptionWhitelist or encryptionBlacklist So, I'm using defaults (presumably from the libraries). And yes, I remembered to reload the metadata source after adding the encryptionMethod element.

But looking at the response, it's still showing AES128-CBC.

Any other possibilities you can think of? Is it correct the <KeyDescriptor> and <EncryptionMethod> are in the same XML schema namespace? I don't need to prefix EncryptionMethod with anything if I'm not prefixing KeyDescriptor, correct?

Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, May 10, 2019 5:25 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: AES256-CBC for encryption?

On 5/10/19, 6:12 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

> Thanks, Scott. That explains why my encrypted assertion is still going as AES128. Yes, we do control the metadata. Is it as
> simple as just adding this to their metadata?

Yes.

> I don't have to make mention of any signing algorithms or anything else as long as they're good with our defaults,
> correct?

Yes, the algorithm extension overrides individual types of behavior by intersecting the IdP supported methods with the metadata, and no metadata just implies no preference and leaves the default behavior.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net