[
https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588795#action_12588795
]
Fred Dushin commented on WSS-99:
--------------------------------
(Similar comment as that on WSS-82)
In r644869, we added the ability to disable BouncyCastle and Juice registration
with the JCE, though this currently requires a call to a static operation,
introducing the standard problems you're likely to encounter with
multi-threaded apps.
Would this suffice, in the near term, for this bug? I'd like to be able to
handle the issue in the future, perhaps with a well-defined initialization
semantics, but I think that may need to wait for 2.0.
Thanks!
> JCE provider ordering on solaris
> --------------------------------
>
> Key: WSS-99
> URL: https://issues.apache.org/jira/browse/WSS-99
> Project: WSS4J
> Issue Type: Bug
> Environment: SUN JDK 1.5.0_11, Solaris 10 (SunOS 5.10), bcprov_15_136
> Reporter: Martin Blandau
> Assignee: Ruchith Udayanga Fernando
> Priority: Minor
>
> Your current implementation of the JCE provider insertion at position 2
> (WSSConfig.java) leads into the known ExceptionInInitializerError when using
> the ws encryption on solaris.
> As Werner wrote (see below), you need the BC provider to be inserted AFTER
> the SUN provider, an therefore you choosed the 2. position. But on Solaris
> with the SUN JDK, there is is an additional provider before the SUN provider
> (SunPKCS11-Solaris sun.security.pkcs11.SunPKCS11). So your BC provider insert
> is done at postion 2 BEFORE the SUN provider...
> So please change your code to retrieve the SUN provider position and insert
> the BC provider afterwards.
> BTW: You rely strongly on the BounyCastle provider. Why don't you use
> Cipher.getInstance(alg, provider) at least for the "strong" RSA operations?
> This could help eliminate jce order problems. And yes, there is a method to
> lookup providers with special attributes like "Keysize":
> Security.getProviders(String filter). Please correct me if i'm on the wrong
> way ;)
> >Well, the ordering of the JCE providers is an ongoing topic anyhow :-) .
> >
> > - The very first entry in the list is somehow reserved by SUN to be able to
> > do JCE verification (JAR verification). Thus we can't use that.
> > - Then we decided to register BC on the second place because
> > sometimes with some JDKs (also IBM's) we got an error when we need
> > the strong RSA algorithm.
> >
> > Let me explain:
> >
> > some JCE (name it JCE-1) includes a RSA algorithm and this RSA
> > supports keys up to 512 bits
> >
> > another JCE (name it JCE-2) includes a RSA algorithm and this RSA
> > supports keys up to 2048 bits
> >
> > JCE-1 is on the JCE provider list at position 2, JCE-2 at position 3.
> > Now you do a lookup for the RSA algorithm, you will get the JCE-1 RSA
> > class. But what happens if you need RSA keys with more than 521 bits?
> > No way out because there is no way to define the "key strength" during
> > lookup. This happend several times in the past - WSS4J requires strong
> > keys as defined by OASIS.
> >
> > Some JCE provider don't support bigger keys - that was the main reason
> > to have BC at position 2. Except for IBM's JDK this seems no problem
> > so far. The Sun JDK, the BEA JRockit and probably others work well
> > with this.
> >
> > As far as WSS4J is concerned, IBM's JDK had the most problems with
> > respect to JCE handling.
> >
> > Regards,
> > Werner
> >
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
