Productionalization of public and private keys for an IdP

Kirill ks.grishin at gmail.com
Mon Mar 28 05:02:09 EDT 2016


Nate,

Thanks for the explanation. I apologize for the late response (it just
takes me some time to actually understand things). Thank you very much.

Thanks,
Kirill

On Tue, Mar 22, 2016 at 2:51 PM, Nate Klingenstein <
nate.klingenstein at utah.edu> wrote:

> Kirill,
>
> You probably don’t need to generate new encryption keys unless you have a
> use case where the IdP will be receiving inbound encrypted messages.  It’s
> rare.
>
> The only other recommendation is that you keep your keys in version
> control along with your configuration files, with appropriately strong
> boundaries between your environments.
>
> Other than that, I think you have the process right.  In particular, you
> wouldn’t want to designate a key as signing-only if you do intend to use
> encryption, and you wouldn’t make new encryption keys if you’re just
> signing.
>
> Take care,
> Nate.
>
> On Mar 21, 2016, at 23:47, Kirill <ks.grishin at gmail.com> wrote:
>
> 1. The production team generates there own public and private key pairs
> and puts them in the
> following files (as defined int the idp.properties):
>
> %{idp.home}/credentials/idp-signing.key (private / signing)
> %{idp.home}/credentials/idp-signing.crt (public / signing)
> %{idp.home}/credentials/idp-encryption.key (private / encryption)
> %{idp.home}/credentials/idp-encryption.crt (public / encryption)
>
> 2. Then they put the public keys to <KeyDescriptor use="signing" /> and
> <KeyDescriptor use="signing" /> elements of metadata and give this updated
> metadata to SP.
>
>
>
> --
> 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/20160328/97cfdc14/attachment.html>


More information about the users mailing list