Change digest algorithm to sha256 for EncryptedKey

[Cantor, Scott]

On 4/18/12 12:38 PM, "Marc Thornton" <marc.thornton at gmail.com> wrote:
>
>Our SP and the IDP to which we are connecting are currently required to
>XML-encrypt anything sensitive going out over the front channel.  This
>includes the Assertion and the NameID, which is why you see our
>front-channel logout request with the encrypted
> NameID.

Sure. But you do understand that AES-CBC is effectively broken now?
Signing the messages is a defense, but only against untrusted attackers,
and it assumes the signature is required, which is not the case right now
in the SP (you can sign only the assertion). That feature is implemented
in 2.5.

>I believe your previous description of the limited benefits of going
>beyond SHA1 in the case of the EncryptedKey will be good enough... I had
>checked the XML Encryption spec before following up here to see if SHA256
>"mapped", but I also understand it's
> not always that easy.

Some IdPs will not actually decrypt PKCS 2.0 + SHA-2, whatever you manage
to generate. It was allowed by the spec, but was somewhat unclear to
implementers apparently. And nobody used it, so most things just defaulted
to SHA-1.

Santuario on the SP side only supported this on the decryption side as of
1.6.0.

-- Scott