[glue-wg] Endpoint.TrustedCA and ComputingEndpoint.TrustedCA Inconsistency in GFD147

[stephen.burke at stfc.ac.uk]

Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
> However I recently heard of France filtering out Iranian CAs on some clusters,
> and I am quite sure in the US are picky about who to trust either.
> 
> Did you hear about that so far? I don't know how they solved it.

I have sometimes heard suggestions that people might do it, but I've never seen it raised as an actual problem, and I imagine it would be much discussed at a policy level before there was any question about technical implementation. My initial suggestion would probably be to publish a negative DN, i.e. explicitly publish that a certain IGTF CA is not supported, e.g. by prefixing the DN with "DENY:".

> And the answer was YES from different sites because of special training CAs
> that are put in place during training session for those who do not have a grid
> certificate and should just use selected clusters.

In EGI and EGEE I think that's normally been done by using a special VO - no doubt there are many ways.

> In principle in such scenario one could have both the IGTF string AND a list of
> allowed CAs in TrustedCA.

Indeed. 

> I am, however, still puzzled on how a client should find out what are the CAs
> allowed on that cluster by just reading a plain string and not a DN...

A Grid UI or WN should have (at least) all the IGTF certificates installed on it, otherwise it can't authenticate services, so it should be relatively easy for a client to determine the CA DNs. For WNs that's monitored and enforced by SAM tests. For example:

grep access_id_CA $X509_CERT_DIR/*.signing_policy | cut -d\' -f2

(That's certainly not the correct way to do it, I would take advice from the security people about the best method, but it illustrates the point.) It's probably also possible to get the information by downloading from the web, but you would still want to cache it locally.

Stephen