[jira] Commented: (WSS-99) JCE provider ordering on solaris

["Fred Dushin (JIRA)" <ji...@apache.org>]

    [ 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org