I believe this is a duplicate of Bug 4933

(In reply to comment #1)
> I believe this is a duplicate of Bug 4933
> 

Cheers, it is indeed. I had missed that. I think your solution is a good
workaround. However, expecting X509Certificate.getSubjectDN() to return an
org.bouncycastle.jce.X509Principal is really far fetch.
Either the methods in BouncyCastleCertProcessingFactory should take
org.bouncycastle.jce.provider.X509CertificateObject for arguments or otherwise
they should stick to the API defined by java.security.cert.X509Certificate. I
must say I'd prefer the latter, but this doesn't really matter.

*** This bug has been marked as a duplicate of 4933 ***

Sorry, I had marked it as a duplicate, which it is indeed. However, the
original bug wasn't assigned to the CoG kit but to GSI, so it's probably better
if it stays visible for the CoG team.

Please include this fix for the next release.

This has been fixed using the patch provided in Bug 4933. There are assumptions
in CoG library about BC provider and the class itself seems to be based on
BouncyCastle. It seems best to use the decode trick to set it up using BC in
the context of CoG and has least impact on other assumptions in the code.

Tom tested the changes http://bugzilla.globus.org/globus/show_bug.cgi?id=6220
 - thanks! 

Fix committed to CVS.

Cheers, that's good news. I haven't tried yet, but I suspect the patch I
provided in bug #5888 is likely to work with this. I'll try to test this
shortly.

What I don't understand is why you haven't changed that line, which was the
only dependency on BC in that method. The result is that this API is still
incorrect. Re-encoding and decoding something that has already been decoded
seems like a long way to solve this.

The method is meant to expect any instance of
java.security.cert.X509Certificate as the issuerCert_ argument, but in fact it
really expects an instance of
org.bouncycastle.jce.provider.X509CertificateObject (since it will eventually
throw a runtime exception if it's not the case).

Either the argument type should be changed to the BC X509CertificateObject or
that line should be fixed... I reckon the latter makes more sense.

I don't have design documents for code and I am not sure what was intended -
but I am willing to bet there are BC dependencies in the CoG code in other
places too. I agree with you that the API is incorrect for all the BC
dependencies, but I don't want to change the API and break any compatibility.
The decode happens only if the passed object is not a BC object - so it
shouldn't be a performance issue. With this patch I don't expect a
RuntimeException to occur with other providers, given the certificate object
will be fixed. Do you still see the issue? The fix is not perfect, but without
changing API, I think it should allow for supporting different providers. 

(In reply to comment #6)
> I don't want to change the API and break any compatibility.
> The decode happens only if the passed object is not a BC object - so it
> shouldn't be a performance issue.

I agree with your rationale, Rachana.  This is perhaps the safest way to fix
the problem.  I've tested your patch against a completely separate batch of
unit tests, and everything works just fine for me.  Thanks for looking into
this.

(In reply to comment #7)
> (In reply to comment #6)
> > I don't want to change the API and break any compatibility.
> > The decode happens only if the passed object is not a BC object - so it
> > shouldn't be a performance issue.
> 
> I agree with your rationale, Rachana. 

I too agree with this principle. However, the patch I suggested both (a) keeps
the existing API and (b) fixes the implementation of this particular method. I
never said the API ought to be changed, I just said it was currently broken and
didn't match the current behaviour of the method. Another fix could be
something like this:

X509Name issuerDN;
if (issuerCert.getSubjectDN() instanceof X509Name) {
    issuerDN = (X509Name)issuerCert.getSubjectDN();
} else {
    issuerDN = new
X509Name(true,issuerCert.getSubjectX500Principal().getName());
}

With the current patch committed to CVS, does use of other provider fail for
you? Does the call to issuerCert.getSubjectDN() fail?

I am "normailizing" the ceritificate object to be something most of the CoG s/w
expects and once that is done the isserCert.getSubjectDN() will be an
instanceof X509Name. This not only fixes the single broken API in that class,
but also fixes the certificate object to be something that I think is overall
expected in CoG - I don't think all of CoG API is shielded from provider
specific calls. 

Fair enough. I haven't tried my patch to grid-proxy-init on this yet, but I
presume it will work. I guess you can close this bug and I'll reopen it if it
really doesn't work. Cheers.

Hello,

yesterday I tried to create a proxy / credential with 1.7.0, but I failed
because of 

java.lang.ClassCastException: org.bouncycastle.jce.X509Principal cannot be cast
to org.bouncycastle.asn1.x509.X509Name
    at
org.globus.gsi.bc.BouncyCastleCertProcessingFactory.createProxyCertificate(BouncyCastleCertProcessingFactory.java:671)
...

After switching line 671 (X509Name issuerDN =
(X509Name)issuerCert.getSubjectDN();) with Brunos suggestion from comment #8,
it worked. May it be that the bug is still there? (BC still returns Principal)

Kind regards
Benny