You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Martin Blandau (JIRA)" <ji...@apache.org> on 2008/01/25 15:10:35 UTC
[jira] Created: (WSS-99) JCE provider ordering on solaris
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 implentation 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 BS 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
[jira] Updated: (WSS-99) JCE provider ordering on solaris
Posted by "Martin Blandau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Blandau updated WSS-99:
------------------------------
Description:
Your current implentation 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
>
was:
Your current implentation 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 BS 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
>
> 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 implentation 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
[jira] Assigned: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh reassigned WSS-99:
--------------------------------------
Assignee: Colm O hEigeartaigh (was: Ruchith Udayanga Fernando)
> 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: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.6
>
>
> 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
[jira] Updated: (WSS-99) JCE provider ordering on solaris
Posted by "Martin Blandau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Blandau updated WSS-99:
------------------------------
Description:
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
>
was:
Your current implentation 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
>
> 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
[jira] Issue Comment Edited: (WSS-99) JCE provider ordering on
solaris
Posted by "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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "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 ]
Martin Blandau commented on WSS-99:
-----------------------------------
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
[jira] Resolved: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-99.
------------------------------------
Resolution: Fixed
> JCE provider ordering on solaris
> --------------------------------
>
> Key: WSS-99
> URL: https://issues.apache.org/jira/browse/WSS-99
> Project: WSS4J
> Issue Type: Bug
> Affects Versions: 1.5.6
> Environment: SUN JDK 1.5.0_11, Solaris 10 (SunOS 5.10), bcprov_15_136
> Reporter: Martin Blandau
> Assignee: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.5.7, 1.6
>
>
> 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
[jira] Updated: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-99:
-----------------------------------
Fix Version/s: 1.6
> 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
> Fix For: 1.6
>
>
> 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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "Michael Schick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569844#action_12569844 ]
Michael Schick commented on WSS-99:
-----------------------------------
Martin,
thanks for the hints. I have added the bcprov* now at the last position in the java.security files (e.g. 8) and
added bcprov to jre/lib/ext and to axis2/webapps/WEB-INF/lib, which works now (axis-1.2/rampart-1.2, but bcproc-15 instead of bcprov-13).
It was blocking problem for us in the moment.
I have now time to consider your suggestion, regarding the registration at application level.
thanks,
Michael
> 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
[jira] Resolved: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-99.
------------------------------------
Resolution: Fixed
> 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: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.6
>
>
> 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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694457#action_12694457 ]
Colm O hEigeartaigh commented on WSS-99:
----------------------------------------
Remove the dormant Apache Juice provider from WSS4J code as part of this refactor.
> 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: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.6
>
>
> 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
[jira] Closed: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-99.
----------------------------------
> JCE provider ordering on solaris
> --------------------------------
>
> Key: WSS-99
> URL: https://issues.apache.org/jira/browse/WSS-99
> Project: WSS4J
> Issue Type: Bug
> Affects Versions: 1.5.6
> Environment: SUN JDK 1.5.0_11, Solaris 10 (SunOS 5.10), bcprov_15_136
> Reporter: Martin Blandau
> Assignee: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.5.7, 1.6
>
>
> 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
[jira] Reopened: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh reopened WSS-99:
------------------------------------
The solution I commited is causing interop tests to fail with WCF so reverting it for now.
> 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: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.6
>
>
> 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
[jira] Closed: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-99.
----------------------------------
> 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: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.6
>
>
> 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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "Michael Schick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569424#action_12569424 ]
Michael Schick commented on WSS-99:
-----------------------------------
I'm having the same problem on Solaris 10 using SUN JDK 1.5.0_11 (axis2-1.2, rampart1.2 and bcprov_13).
Editing the java.security file and moving the BC to the 2nd place, does not solve my problem.
With a standalone program using KeyGenerator.getInstance("AES") without BC in the classpath works.
With BC in the classpath is the result below. When my webservice is called then the encryption fails with
exactly the same error below.
$ java -classpath $AXIS2_CLASSPATH org/eumetsat/umarf/AEStest
Exception in thread "main" java.lang.ExceptionInInitializerError
at javax.crypto.KeyGenerator.a(DashoA12275)
at javax.crypto.KeyGenerator.<init>(DashoA12275)
at javax.crypto.KeyGenerator.getInstance(DashoA12275)
at org.eumetsat.umarf.AEStest.main(AEStest.java:42)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.<clinit>(DashoA12275)
... 4 more
Caused by: java.security.PrivilegedActionException: java.security.InvalidKeyException: Public key presented not for certificate signature
at java.security.AccessController.doPrivileged(Native Method)
... 5 more
Caused by: java.security.InvalidKeyException: Public key presented not for certificate signature
at org.bouncycastle.jce.provider.X509CertificateObject.verify(Unknown Source)
at javax.crypto.SunJCE_b.d(DashoA12275)
at javax.crypto.SunJCE_b.c(DashoA12275)
at javax.crypto.SunJCE_r.run(DashoA12275)
... 6 more
Any workarounds ?
> 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
[jira] Commented: (WSS-99) JCE provider ordering on solaris
Posted by "Marcel Ammerlaan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563180#action_12563180 ]
Marcel Ammerlaan commented on WSS-99:
-------------------------------------
Alternatively: most JCE api calls allow an extra argument which takes the name of the provider to use, this way BC doesn't need to be added at all. Is this an option as well?
> 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
[jira] Issue Comment Edited: (WSS-99) JCE provider ordering on
solaris
Posted by "Marcel Ammerlaan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563180#action_12563180 ]
mammerlaan edited comment on WSS-99 at 1/28/08 8:08 AM:
--------------------------------------------------------------
Alternatively: most JCE api calls allow an extra argument which takes the name of the provider to use, this way BC doesn't need to be added at all. Is this an option as well?
Clarification: "BC doesn't need to be added at all" means: doesn't need to be added to the list of providers as one is select up-front.
was (Author: mammerlaan):
Alternatively: most JCE api calls allow an extra argument which takes the name of the provider to use, this way BC doesn't need to be added at all. Is this an option as well?
> 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
[jira] Updated: (WSS-99) JCE provider ordering on solaris
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-99:
-----------------------------------
Affects Version/s: 1.5.6
Fix Version/s: 1.5.7
> JCE provider ordering on solaris
> --------------------------------
>
> Key: WSS-99
> URL: https://issues.apache.org/jira/browse/WSS-99
> Project: WSS4J
> Issue Type: Bug
> Affects Versions: 1.5.6
> Environment: SUN JDK 1.5.0_11, Solaris 10 (SunOS 5.10), bcprov_15_136
> Reporter: Martin Blandau
> Assignee: Colm O hEigeartaigh
> Priority: Minor
> Fix For: 1.5.7, 1.6
>
>
> 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