Bug 6029 - Ability to use BouncyCastleCertProcessingFactory using default security provider
: Ability to use BouncyCastleCertProcessingFactory using default security provider
Status: RESOLVED FIXED
: CoG jglobus
utils
: unspecified
: All All
: P3 major
: 1.6
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-04-21 11:42 by
Modified: 2014-04-15 18:01 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-04-21 11:42:32
Hello,

I've included this fix for bug #5888, but this is a problem that is showing up
for us in another application too.

BouncyCastleCertProcessingFactory expects not only an X509Certificate, but one
that has been created by the BC provider. This assumption triggers a
ClassCastException when trying to pass an X509Certificate that has been loaded
from another provider (such as the Sun provider). It happens at line 651 (in
the CVS tree, line 616 in 1.4):

   X509Name issuerDN = (X509Name)issuerCert.getSubjectDN();

Changing it to this removes the directed dependency to BC and fixes the
problem:

   X509Name issuerDN = new
X509Name(true,issuerCert.getSubjectX500Principal().getName());

(It might be worth noting that getSubjectDN() is now marked as "Denigrated".)


Best wishes.
------- Comment #1 From 2008-04-21 11:48:14 -------
I believe this is a duplicate of Bug 4933
------- Comment #2 From 2008-04-21 12:27:13 -------
(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 ***
------- Comment #3 From 2008-05-15 11:18:22 -------
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.
------- Comment #4 From 2008-07-16 11:06:47 -------
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.
------- Comment #5 From 2008-07-16 11:34:15 -------
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.
------- Comment #6 From 2008-07-16 12:35:07 -------
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. 
------- Comment #7 From 2008-07-16 16:44:27 -------
(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.
------- Comment #8 From 2008-07-17 07:57:16 -------
(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());
}
------- Comment #9 From 2008-07-17 08:19:48 -------
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. 
------- Comment #10 From 2008-07-17 08:25:03 -------
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.
------- Comment #11 From 2009-07-28 01:45:24 -------
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
------- Comment #12 From 2014-04-15 18:01:13 -------
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/lesbian-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.