Trouble with signature filter skipping
guillaume.rousse at renater.fr
Mon Sep 17 03:59:13 EDT 2018
Le 14/09/2018 à 19:25, Cantor, Scott a écrit :
> On 9/14/18, 10:55 AM, "users on behalf of Guillaume Rousse" <users-bounces at shibboleth.net on behalf of guillaume.rousse at renater.fr> wrote:
>> This would achieve caching in addition to backup. If such a change is
>> considered favorable, I'd be ready to contribute it myself.
> The problem isn't downloading the file, it's parsing it, and fixing that would be a massive change, and risky, and it solves a problem you're creating yourself by doing something the SP absolutely doesn't want you do to. Metadata is meant to be loaded globally, not per-override, and something of this size makes no sense to load any other way.
Loading metadata in application-specific context just make the issue
worst, because of potential duplication, but is not the root cause. Even
loading this 23Mb metadata file in global context requires a systematic
120s delay at each startup. Hence the interest of caching.
>> Is it a design decision, or merely an implementation issue ?
>> Because that's quite counter-intuitive, and also prevents to exchange signature
>> checking in favor of metadata source authentication, which doesn't
>> suffer from CPU usage bottleneck.
> Both. The trust model is inherently based on signed metadata that can't be modified in transit or by network proxies, and even if it weren't, a model based on a key that has to be exposed to a web server has very different risks. I realize that people are doing dynamic metadata by doing online signing too, but they don't have to, it's possible to segregate the signing operations with a key that is very far from wide exposure to network access.
> You're suggesting putting a CA online. That is a bad idea.
No, I'm just suggesting allowing usage of standard transport layer
security model, by honouring server certificate instead of silently
ignoring it. Either in addition to signature checking, or as replacement.
Tel: +33 1 53 94 20 45
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
More information about the users