[
https://issues.apache.org/jira/browse/WSS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588983#action_12588983
]
Dittmann, Werner commented on WSS-82:
-------------------------------------
The current handling of JCE in WSS4J was driven by some
requirements and/or contraints given by xmlsec. IMHO when
changing this handling we have to be careful with respect
to these contraints. Also at that point in time we need to
support Java 1.3 that had constraints in JCE provider handling
I can remember discussions that lead to this specific handling
of JCE providers. We had problems when using specific algorithms
and key length, for example RSA-1024.
During the first time we simply added BC without giving a position.
Now, if WSS4J required an algorithm _and_ a specific key length
(RSA-1024 instead of RSA-512) this caused problems: AFAIK you may
perform a lookup for a specific algorithm, but not for a specific
key length for this algo.
If some JCE provider that was in front of BC in the list of JCE
providers and this provider implements RSA then you get this provider.
If this JCE provider only supports key lengths up to 512 and not
1024 then you are in trouble :-) .
Adapating the handling of JCE providers need to be tested carefully,
taking backward compatibility into consideration (still supporting
Java 1.3? Just lately I've seen a mail regarding Java 1.3 support
on the list).
Werner
> Add the ability to use a custom-loaded JCE provider instance instead of using
> the system-provided one
> -----------------------------------------------------------------------------------------------------
>
> Key: WSS-82
> URL: https://issues.apache.org/jira/browse/WSS-82
> Project: WSS4J
> Issue Type: Bug
> Reporter: George Stanchev
>
> Currently WSS4J loads the BouncyCastle JCE (see WSSConfig.java). However, it
> uses the JCE Security class to then register the JCE in the
> java.security.Security registry. The problem is, that it uses the context
> classloader which might or might not be available for other parties. The JCE
> providers loaded via java.security.Secruity must be installed in the system
> classloader since it loads the JCE.
> JCE 1.4 and onwards provides a way to use an instance of a JCE provider
> supplied by the caller instead of the classes requesting one from the
> Security registry.
> For example to get a cypher, one can write
> Class clazz = myClassloader.loadClass("my.custom.JCEProvider");
> java.security.Provider myprov = (java.security.Provider) clazz.getInstance();
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation,
> myprov);
> instead of
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation);
> or
> javax.crypto.Cypher = javax.crypto.Cypher.getInstance(myTransofrmation,
> "myprov");
> This way WSS4J will stay trully independent of any system-provider JCE
> providers.
> Same needs to be done for XML-Security library
--
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]
