This bug applies to both the C and Java sides of Globus. I assigned it to GSI C
arbitrarily. 

There have been successful attacks recently against X.509 certificates signed
using MD5 hash algorithms (see http://www.win.tue.nl/hashclash/rogue-ca/).
While GT should move away from MD5 hashes (see Bug 6613), another thing that
would help against this attack and other future similar attacks would be is if
GT proxy certificates had contents that were unpredictable by the attacker.

More details can be found in the following thread:
http://www.imc.org/ietf-pkix/mail-archive/msg05174.html

It appears today that GT does indeed use a hash of the public key, meaning the
serial number is total predictable by the attacker. A resonance improvement
would seem to be introducing randomness into the serial number of the proxy
certificate, hence make these type of hash collision attacks harder or
impossible.

RFC 3820 gives a good deal of flexibility in this regard:
   The serial number of a Proxy Certificate (PC) SHOULD be unique
   amongst all Proxy Certificates issued by a particular Proxy Issuer.
   However, a Proxy Issuer MAY use an approach to assigning serial
   numbers that merely ensures a high probability of uniqueness.
   For example, a Proxy Issuer MAY use a sequentially assigned integer
   or a UUID to assign a unique serial number to a PC it issues.  Or a
   Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a
   serial number with a high probability of uniqueness.

Questions to be answered:

1) Does anything depend on the current predictability of the serial numbers
today? AFAIK, nothing does.

2) How should the randomness be introduced? Keeping some guarantee of
uniqueness would seem to be a good thing. RFC 3280 and RFC 5280 indicate serial
numbers of up to 20 octets are acceptable, so we would seem to have plenty of
room to work with here and we could use a 16-byte random UUID (e.g. a version 4
UUID as defined by RFC 4122 - http://tools.ietf.org/html/rfc4122).