perfsonar development work

[Cándido Rodríguez Montes <>]

Hi Jeff,

you're right when you said we have some degree of freedom in using other certificates for deployment. As I read in the AS specification document, we're going to use certificates issued by the eduGAIN CA or by one of the subordinate CAs but also it's open to include others CAs.

But all perfSONAR components SHOULD have all root certs. It makes sense when you have a few root certs, not when every organization has its own root cert. In our scenary, we have one for eduGAIN CA and one for subordinate CAs, and I suppose organizations from Internet2 have the same root cert. In the worst case, I guess we would have 5-10 root certs, wouldn't we?

In this scenary, we have resolved all trust problems in SSL communication.

Regards

El 06/03/2007, a las 16:24, Jeff W. Boote escribió:

Hi Diego, Candido,

I have a question about this.

In our model, the client first talks with the H-BE to get authenticated. Since both the client, and the H-BE are from the same domain, it is easy for me to see how they can speak SSL with no problems - they will each accept the root-cert of the same organization.

Where I get confused is in the case of federation for the SSL communication.

Can we examine the case where the client then attempts to speak with a resource from a different domain? It was my understanding that the client would be getting a certificate from the SASL-CA as part of authenticating. I assumed it would be using that certificate for the SSL communication with the resource. And, I assumed it would be necessary to do that - because this short-term certificate would somehow have its X.509 root based at something the resource could accept as a valid root. The resource might need to contact the AS to determine it is valid of course. (Perhaps this is my confusion - does the act of federating require all organizations in the federation to exchange root certificates? Or is this what is really stored in the federated metadata service?)

In any case, this interaction makes me wonder how the client could accept the certificate of the resource. I guess we just do the same thing that web browsers do when they can't validate a root? Prompt the user? Or do we need an interaction back to the H-BE (or a metadata service) to allow the client to validate the cert of the resource? The H-BE (or something - not the client) should somehow know the root certs of federated domains, right? Just like the AS of the resource (and therefore the R-BE) knows something about the root cert of the domain of the user.

Hopefully my question is clear... What brought this up for me is when you said we would have some degree of freedom in using other certificates for deployment. I'm not sure I see how that could work - unless you are saying we do not worry at all about the authentication provided by the SSL connection. But, in this case, I would be worried about man-in-the-middle attacks. If it is just a random certificate used for the communication, then you have no way of knowing if you are talking to an intermediary, right?

Thanks,

jeff

--

Cándido Rodríguez Montes E-mail: 

Red.ES/RedIRIS Tel:+34 955 05 66 13

Edificio CICA

Avenida Reina Mercedes, s/n

41012 Sevilla

SPAIN