[jira] Issue Comment Edited: (WSS-99) JCE provider ordering on solaris

["Martin Blandau (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569791#action_12569791 ] 

mbl edited comment on WSS-99 at 2/17/08 11:17 PM:
-------------------------------------------------------------

Michael,
1. do not insert the "BC" provider at the second position. On Solaris, there is an additional provider ("SunPKCS11") before the "SUN" provider. Ensure the "BC" provider will be inserted AFTER the "SUN" provider immediately. Iterate the provider list and get the "SUN" provider postion...
2. WSS4J has already registered the "BC" provider at the wrong position (see my description on the issue above). It is a workaround to register the BC provider yourself (maybe at application startup, init servlet...) BEFORE WSS4J will do it, as Security.insertProviderAt and Security.addProvider don't do anything if the provider is registered already. Or remove the "BC" provider add insert it after the "SUN" provider immediately...
This way you don't need to add the "BC" provider to the java.security file. So it's enough to add the bcprov-*.jar to the application classpath.
HTH,
Martin

      was (Author: mbl):
    Michael,
1. do not insert the "BC" provider at the second position. On Solaris, there is an additional provider ("SunPKCS11") before the "SUN" provider. Ensure the "BC" provider will be inserted AFTER the "SUN" provider immediately. Iterate the provider list and get the "SUN" provider postion...
2. WSS4J has already registered the "BC" provider at the wrong position (see my description on the issue above). It is a workaround to register the BC provider yourself BEFORE WSS4J will do it (maybe at application startup, init servlet...), as Security.insertProviderAt and Security.addProvider don't do anything if the provider is registered already. Or remove the "BC" provider add insert it after the "SUN" provider immediately...
This way you don't need to add the "BC" provider to the java.security file. So it's enough to add the bcprov-*.jar to the application classpath.
HTH,
Martin
  
> 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