IdP Signing Certificate question

[Andrew Jason Morgan]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210121/097afe25/attachment.htm>