IdP Signing Certificate question

[Brian Biggs]

"they have an IDP signing certificate that was issued by the old CA, and
either the signing cert or the CA cert (or both) used an MD5 signature.  Is
that correct?"

Our IdP signing cert has an sha1 signature, but was signed by an
internal CA with an MD5 signature.

"Is it possible to generate a new, self-signed cert using a modern signing
algorithm such as SHA-256 from the same private key?  If so, won't data
signed/encrypted with the private key still be able to be
validated/decrypted by the SP which has the new cert?"

I'm sure SPs that have the new cert generated from the original private key
will work, but what I was hoping for is that SPs that have the *old* cert
would also continue to work.
And I guess the answer is maybe? Depends on the SP software being used and
the processes in place at the SP...

Thanks,
-Brian

On Thu, Jan 21, 2021 at 11:14 AM Andrew Jason Morgan <morgan at oregonstate.edu>
wrote:

> I want to understand this better...
>
> I think Brian says that they have an IDP signing certificate that was
> issued by the old CA, and either the signing cert or the CA cert (or both)
> used an MD5 signature.  Is that correct?
>
> Is it possible to generate a new, self-signed cert using a modern signing
> algorithm such as SHA-256 from the same private key?  If so, won't data
> signed/encrypted with the private key still be able to be
> validated/decrypted by the SP which has the new cert?
>
> Thanks,
> Andy
>
> ------------------------------
> *From:* users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <
> cantor.2 at osu.edu>
> *Sent:* Thursday, January 21, 2021 9:58 AM
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* Re: IdP Signing Certificate question
>
> [This email originated from outside of OSU. Use caution with links and
> attachments.]
>
> On 1/21/21, 12:52 PM, "users on behalf of Brian Biggs" <
> users-bounces at shibboleth.net on behalf of biggsb at sonoma.edu> wrote:
>
> >    Just to be clear, what I'm hearing is that keeping our private key
> and changing our public key doesn't buy us anything as
> > far as keeping SPs working during a transition. Is that right?
>
> You can't change one and not the other. You're confusing a new certificate
> with a new public key, that's not how it works. The keypair is a unit.
> Issuing a new certificate for the same public key is what you're talking
> about.
>
> It buys a lot, but nothing is universal. Whether that's enough is
> subjective. I have never been faced with the question but no, you cannot
> just reissue it. That's going to break plenty of stuff. Just much less than
> changing the key.
>
> >    So we might as well generate new public and private keys and work on
> a coordinated cutover with all our SPs...
>
> If you're going to do that, then the result at the end should be:
>
> - A key protected in such a way that the chances of anything short of
> outright compromise of server memory should not cause it to be at risk. To
> me that means it should not be accessible on disk at runtime or ever backed
> up outside of a very controlled process.
>
> - A tagging/metadata-based strategy for controlling the key used by all
> broken services so that a future change can be automated for all the
> non-broken services and the broken ones controlled on an individual basis.
>
> Such a nightmarish task has to lead to very tangible benefits to be
> worthwhile.
>
> -- 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
> --
> 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
>


-- 
Lead Identity Mgmt/Systems Integration
Information Technology
Sonoma State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210121/d2c17061/attachment.htm>