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