<div dir="ltr">Arguably the vendor is ignoring encryption; they do not consume encrypted SAML assertions, and the cert is explicitly designated for use as signing cert.<div><br></div><div>David Bantz</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 11:09 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> A vended SP is upgrading their signing cert to one signed with<br>
> sha512WithRSAEncryption . Adding the new cert as a second signing cert into<br>
> their SP metadata seems the seamless way to ease the transition, eventually<br>
> removing the old SHA1 signed cert after the transition is complete. I'm<br>
> assuming/hoping IdP v2 will verify their SAML assertion which ever of the<br>
> two certs they use to sign the assertion. Or is this more complex than I've<br>
> assumed?<br>
<br>
</span>That's how it works, but it is much more complex than that because you're ignoring encryption. I don't know if you're talking about a signing key or a dual use key being used to encrypt data under. Both cases are discussed at length in the wiki and I think InCommon has additional material on it.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>