Consider signing the catalouge.xml

[mikesteez]

As the registry and catalouge is analogous to the SAML 2 specification, there is advantages to use the same model. With SAML 2, the metadata file (catalouge.xml) is signed by the registry (metadata service in SAML). This ensures that the catalouge has not been tampered with. This might be a future requirement. See also http://blog.samlsecurity.com/2012/02/saml-metadata.html for more background.

[wrygiel]

I'm note sure if I understand. The clients verify the registry certificate's during the SSL handshake phase. What would be the added benefit of additional XML signature?

[mikesteez]

In the current model, the clients verify that the server is the correct one. The clients can't verify that the content has not been tampered with. The eduGAIN SAML federation uses hardware security modules to sign the information in the registry. See the architecture here, https://wiki.edugain.org/FaaS_toolbox_and_basic_usage_workflow

[wrygiel]

Me and @Awerin had a quick look at your links and talked a little. I'm afraid I still don't understand though.

The clients can't verify that the content has not been tampered with.

Tampered by whom? By the registry? Once the SSL handshake is complete and session keys are generated, data exchanged during the session cannot be tampered with. Are you considering the scenario of a hacked Registry server?

[georgschermann]

in respect to the latest events i wouldn't consider SSL 100% save a signed catalogue would add the benefit that no malicious catalogue could be distributed, be it by a man in the middle, hacked registry or hacked clients (since they most probably cache the catalogue to some extent) but i don't know if its currently neccesary

[wrygiel]

in respect to the latest events i wouldn't consider SSL 100% save

Are you referring to the vulnerabilities found in OpenSSL? Or are there any big problems with the TLS itself?

a signed catalogue would add the benefit that no malicious catalogue could be distributed, be it by a man in the middle, hacked registry or hacked clients (since they most probably cache the catalogue to some extent)

Would additional signing really protect us against hacked registry or clients? If I understand the scenario correctly, in both cases the hacker gets access to the private key (or both private keys) and can use them for signing.

[georgschermann]

i was referring to various attacks on SSL (POODLE, CRIME, BEAST, Heartbleed, etc.) which not all expose the private key like Heartbleed and also problems with rogue CAs and certificates. The impact of these attacks depends if we will only allow specific protocols, keysizes and certificates and compare e.g. the fingerprint of the certificate or if we just rely on the certificate chain to be trusted. in some attack scenarios signing the catalogue would't help, but in some it would.

[wrygiel]

but i don't know if its currently neccesary

I also don't think so. I believe even rogue CAs won't hurt us much until they also somehow manage to take control of the DNS network. All of the industry depends on this, I think we can too.

If you won't object, I propose to close this issue.

[mikesteez]

We can close this. For reference, this is the text from the SAML federation InCommon "InCommon signs the entire metadata file, securing the keys of its participants whether those keys are bound to self-signed certificates or certificates signed by a CA. The critical element in the certificate is the public key, which is associated with an entity via its entity ID."