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