IdP assertions encryption issue
Guillaume Rousse
guillaume.rousse at renater.fr
Thu Feb 1 07:55:34 EST 2018
Le 31/01/2018 à 18:29, Cantor, Scott a écrit :
> On 1/31/18, 11:37 AM, "users on behalf of Guillaume Rousse" <users-bounces at shibboleth.net on behalf of guillaume.rousse at renater.fr> wrote:
>
>> Basically, when the same certificate/key pair is used both for
>> encryption and signature, you can't satisfy both migration constraints
>> at once (publishing before using for signature, using before publishing
>> for encryption).
>
> And you don't have to, as that wiki page demonstrates. It is perfectly possible to migrate one key used for both. That doesn't mean it's optimal, and what should be done now probably is just forgo signing entirely, which the SP generally doesn't need to do, and focus on encryption/decryption.
That's true when you control the way your metadata are generated, as you
can decide which usage is associated with your certificates. Our
federation (RENATER Education/Research federation) use a web application
to delegate metadata management to each SPs/IdPs admins, allowing to
declare two different certificate for an entity, but not their intended
usage, which is hardcoded into metadata generation algorithm.
This works when you know about this algorithm (the first certificate is
announced both for signature and encryption, the second for signature
only), as you can declare the new certificate in second position first,
then swap later, but this was just not explicit on the interface...
Regards.
--
Guillaume Rousse
Pôle SSI
Tel: +33 1 53 94 20 45
www.renater.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20180201/df63c619/attachment.p7s>
More information about the users
mailing list