You would need to trust the CA for the bad_guys.org certificate with positive
signing rights.  Unless they have stolen the keys of a CA trusted by the client
and created a certificate thusly, I don't think this is a problem.

The certificate is still checked for validity against accepted CAs.  This does
obviate a check for a strictly matching hostname (cert<->target).  It also
brings g-u-c in line with most other Globus/grid tools in terms of service name
checking.

This is not to say it is the best method, or the worst.  I feel it's an
appropriate amount of give and take, however, for the convenience it adds.  Also
note that this is client-based, so developers can still write code that does
strict checking if they wish to.

> ------- Additional Comments From kcm@psc.edu  2004-05-25 11:16 -------
> You would need to trust the CA for the bad_guys.org certificate with positive
> signing rights.  Unless they have stolen the keys of a CA trusted by the 
client
> and created a certificate thusly, I don't think this is a problem.

The bad guys would have no problem obtaining a certificate from their
national CA, which may very well be in the list of CAs trusted by the
duped client (it can even be the same as that of the good guys).

> The certificate is still checked for validity against accepted CAs.  This 
does
> obviate a check for a strictly matching hostname (cert<->target).  It also
> brings g-u-c in line with most other Globus/grid tools in terms of service 
name
> checking.

There ought to be a way to prevent the scenario I sketched earlier, while
still allowing for sensible alias resolution.  Might the problem be solved
by separating host certificates from service certificates?  If so, are there
any plans to make Globus ready for that?

> This is not to say it is the best method, or the worst.  I feel it's an
> appropriate amount of give and take, however, for the convenience it adds.  
Also
> note that this is client-based, so developers can still write code that does
> strict checking if they wish to.

Yes, it is not a showstopper right now, but I think the problem *must* be
addressed eventually...

What about having more than one host certificate for a single machine?
(As far as I know, that's not currently possible.)

Suppose I have a machine called foo.good_guys.net, and I want users 
to be able to refer to it by any of several names:

    foo.good_guys.net
    foobar.good_guys.net
    foo.good_guys.big_grid.org
    foobar.good_guys.big_grid.org
    
Currently, one of those (say, foo.good_guys.net) is going to be the 
primary name (the result of a reverse lookup on the IP address), and
the host certificate has to refer to that name.  With the resolution
for bug 318, DNS handles everything (which is much more convenient 
for users) -- but a bad guy could hijack DNS and cause clients to
accept a certificate for bar.bad_guys.org.

If the machine has certificates for all 4 valid names, the client can
check for a certificate that matches the name given on its command
line, and needn't do the reverse lookup.  The bad guy's machine 
would have to have a host key for one of the valid names to be able
to hijack it.

(If a user on "buford.good_guys.net" refers to "foo", that needs to
resolve to "foo.good_guys.net" for certificate verification purposes.)

This would mean some extra work for the system's administrators
(generating extra host keys and keeping them in sync with the desired
DNS aliases).  It would also mean backing out the resolution for
bug 318.  Getting from here to there could be non-trivial.

The work for bug #6331 adds an environment variable to disable DNS lookups in
the GSI code, as well as code to handle certs which can have multiple DNS names
in subjectAltName extension. A similar implementation is planned for GSI Java.